Slashdot Mirror
A Standardized Open Source Network Authentication
JigSaw writes "The open source community has mastered many challenges and has been successful in numerous areas. However, there is one glaring weakness that needs to be remedied. Without progress in this area, open source in the enterprise will always play second fiddle to Microsoft, Novell, and other corporate computing entities."
Imagine if, instead of saying "works as an NT server" you say "just install this little driver on windows and you get and open standards domain".
I think most sysadmins would not mind having to install an OSS network driver on windows if it could solve thier domain woes, which of course it could if......
And if you thought that was boring you obviously havn't read my Journal ;-)
What about PAM?
Substitution of the above with a few blanks;
I'm not saying Van Emery is wrong. I'm saying that reading these types of comments makes me loose both interest and confidence in the message.
(*BLANK* substituted for ______ because of /. filters not liking _______.)
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
... it's the poor sap that doesn't have a standard openly documented distributed login system. It's also quite difficult to implement one given that Microsoft knows damn well how crucial it is to possess this part of the infrastructure; otherwise they could have done like apple (OpenLDAP + Kerberos5). They chose to break the stadard (or at least attach undisclosed extensions) in order to remain in it's current 'rabbit' status and make pretty damn shure nobody breaks free of the straglehold (making the authentication interface poorly documented and rather mpossible to substitute without dramatic loss of functionality) Would it be difficult to write a fully working LDAP + Krb5 auth plugin for Windows? I've never seen one... except for the Novell one, and it's not free...
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
So why not make NDS more freely available?
Now that Novell has invested in SuSE and Ximian, go full steam ahead in the Linux market, why not bring out Novell Directory Service across platform?
IIRC, Novell had NDS ready years ago but were pre-empted by a vaporware announcement of AD from Microsoft. Corporate clients were wary of buying NDS, even if it was a nice product, just because they knew that in a year or two MS would come out with their own brand of directory service that would be tightly integrated into other MS products.
Either do that, or have Samba 4 include more of these combined directory authentication services, hopefully using standardized components such as LDAP and kerberos.
"Provided by the management for your protection."
Virtualy all non-trivial server products I have ever laid my sights on supports Kerberos authentication. Most of them even have fairly good docs on how to configure it to use Kerberos... Out of the box, many server packages (and linux distros) "just work" with kerberos.
Apparently. I have never, ever, seen a site that has a kerberos server installed. All mailing list traffic that I have seen mentioning Kerberos is about it not working with $ml_topic. And I fail to see the advantage of using Kerberos over, say SASL with an LDAP backend... Kerberos is the network service equivelent of a GUI desktop calculator: something you need to have, even though no one ever uses it.
I have to second this.
I was setting up LDAP for internal use so I could do local user accounts, FTP, IMAP, SMTP Auth, web auth, VPN all with one account. Everything seemed to want different named fields for the same thing, and different management tools used different fields, had different requirements, or were not complete enough. This meant that I had to build my own management tool - NOT what I was looking for.
The LDAP docs for linux are also pathetic. Nothing actually has complete working examples beyond the most simplistic level.
LDAP doesn't just give you enough rope to hang yourself, you actually have to braid your own rope using the hemp you grew yourself, build a chair, plant your own tree and wait for it to grow enough to throw the rope over before you can hang yourself. THIS is what needs to change.
I've been wanting to do something like this for quite some time. I've gotten OpenLDAP and Kerberos 5 working, and it's a solution, but far from an elegant solution. It is difficult to figure out how to get everything working the first time, and I have a few gripes about things (perticularly with OpenLDAP and using authentication through it).
First of all, OpenLDAP lacks 3 major things to make it a viable enterprise directory service. First off, OpenLDAP needs online shcema and indexing changes. This is not a dealbreaker, but it would make things easier, not having to down the server for the occasional index or schema changes. Next, ACLs must be editable online somehow. This is a must! Things like delegation of access to certian ou's requires this. Third, and most important, is data inheritance. There should be the ability to inherit data onto an object, if it is specified as such, from it's parent. The whole point of creating ou's is to seperate users based on a common attribute. Being able to inherit information from the parent is a must here.
There are a few other things that are needed. A caching daemon is needed for disconnect capabilities, and gui and text mode utilities are needed for easy administration of the directory.
Now, I've gone and grabbed the domain opendas.org, and I'm going to think this over a bit, and over the next few days I'm going to put something up there. If anyone is interested in this, drop me a line at mike [at] tuxnami [dot] org.
---
Mike Crawford
Whoops!
I should have made it clear that ``back when I worked at MIT'', we were setting up kerberos 4 realms, since kerberos 5 (mostly) didn't exist yet.
As far ``why isn't it used?'', I've seen kerberos deployed in a number of small, medium, and large installations, corporate and educational, but it's far from ubiquitous. AFS and DCE installations are almost certain to be using kerberos, for example.
I would suggest a two-part reason for the lack of widespread kerberos adoption: lack of client support in closed-source software, and reliance on old, insecure tools, especially in mixed-platform environments. Basically, if you were using Windows or Macintosh computers, adding kerberos support was extra effort, and quite often your commercial software (one big reason that you'd be using those platforms) wouldn't support kerberos (why not? Export restrictions certainly helped). This meant that you'd either have to use something else in addition to kerberos (NFS, SMB, AppleTalk, for example), and that often required that you firewall your local network and simply trust it. At that point, the value/hardship tradeoff of kerberos leans strongly against, so people either don't take the extra effort to install and maintain it, or they bypass and eventually ignore it.