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?
... 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
The problem goes deeper than authentication. Those familiar with Win32 service development should be aware that pipe communication (including SMB used for file sharing) "transparently" communicates the security principal of the caller, so that the service can impersonate the calling (temporarily reducing its effective permissions to those of the caller).
This is incredibly powerful, as it allows a service to seamlessly integrate with operating system (and by extension enterprise) security, without the service developer needing to reimplement access controls, or implement a new access control system.
What we need is a generic communication layer that includes:
But that's just my 2c.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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."
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.
So you are saying that instead of doing intense security audits and maintaining one system, a system everyone can know well, we should do half-assed audits on dozens of authentication systems and try to maintain them all? The hell with single signon, go maintain dozens of different passwords (or worse, use the same password on everything)???? I don't see how having many disparate systems helps security other than being security through obscurity.
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