A Standardized Open Source Network Authentication 27
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."
OSS it's own worst enemy (Score:4, Interesting)
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......
Dumb question (Score:4, Interesting)
Re:Dumb question (Score:2, Informative)
Re:Dumb question (Score:1)
Re:Dumb question (Score:4, Informative)
>years now, I realize it is a very much needed feature of linux.
It is. And it already works nice. I've got an OpenLDAP and a MIT kerberos server working nicely together. It almost sounds like there
is no such thing yet by your post
Re:Dumb question (Score:2)
You use a pam module for kerberos if that's what you're using
to authenticate. Or a pam module if you authenticate to an LDAP server. Or a pam module for
Formula (Score:3, Interesting)
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 _______.)
I agree. (Score:2, Insightful)
Its the age-old argument though. People write code they want to write, in the OSS world, and face it: Networked User Authentication is booo-oooring.
(But then, I don't see why we don't all use RADIUS and be done with it
Re:I agree. (Score:2)
Not my point. The rough formula to rouse the troops -- 'if EVENT is not ACTION, BAD_THING occurs' -- is ineffective to me. I've heard it for years and it's ineffective.
That said, the rest of the article makes a point so I won't ding him for being passionate about it.
The problem is for windows... (Score:4, Interesting)
Re:The problem is for windows... (Score:5, Insightful)
If you want to use a "standard" implementation, you can buy identity management software or use something like this http://pgina.xpasystems.com/.
In any case, the problem with "standard" LDAP/Kerberos implementations is that they are nearly undocumented.
Ask a skilled NT admin to setup a test domain and he'll be back before lunchtime. Ask most skilled Linux admins to setup a test LDAP/Kerberos5 domain, and he'll be back in two weeks with the project half-done.
Setting up kerberos (Score:3, Insightful)
Back when I worked at MIT, we used to joke about setting up test kerberos realms while holding our breath, it was so easy. I know at least two people who did it, just to prove the point.
Re:Setting up kerberos (Score:3, Insightful)
Kerberos is built-in to most modern linux distros. So is OpenLDAP. Unfortunately, the exact LDAP setup is left to the site. I've yet to see a large LDAP implementation that didn't do a few things with custom fields. I've also not yet seen a site that clearly documents their setup and customizations. The attitude is usually "the next guy can reverse-engineer my work, and that won't be a problem if he's a -real- sysadmin."
The Windows domain jackboots only give you one way
Re:Setting up kerberos (Score:4, Interesting)
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.
Re:Setting up kerberos (Score:3, Interesting)
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, ma
Re:Setting up kerberos (Score:2)
A better question is: why doesn't anyone use it?
I've been to alot of large, medium and small unix sites and have never seen a major Kerberos setup. The lone exception was a Tivoli Framework deployment where they used the kerberos implementation that comes with Tivoli in a development environment.
My best guess is that by not documenting anything, it attacts consulting business for the authors.
I'm not trying to flame here -- I've read about the MIT IT env
Re:Setting up kerberos (Score:3, Interesting)
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
Re:The problem is for windows... (Score:4, Interesting)
If your OpenLDAP/Kerb5 kit was put together right, you could use the LDAPv3 setup for authenticating more standard clients, and use pGINA for Windows [xpasystems.com]. It won't kerberize you (yet), but SSL should provide your basic security. Samba servers using the LDAP backend should fit quite nicely.
Another idea is to configure LDAPv3, and set up a Samba server(with the LDAP backend) as a Domain Logon server. If these are all on one server, you've pretty much built the same thing Microsoft does on an AD PDC, but without the tight integration. LDAP clients get the full benefit, and Windows clients will work out of the box. Think of it like half-assed AD. :)
What would be nice is to see something like Apache Toolbox [apachetoolbox.com] for OpenLDAP and Kerberos. LDAPv3 is quite a task to get set up, and I think the huge learning curve for the system is it's largest flaw. Seriously, Microsoft only needs to know your dns domain to get everything configured, why can't it be that easy? :>
Deeper problem (Score:5, Insightful)
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.
NDS (Score:5, Interesting)
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.
Re:NDS (Score:4, Insightful)
NDS/eDirectory currently runs on: Netware, Windows NT 4, Win 2k, 2003, Linux RH 7.3+, SuSE, Solaris 8, 9, AIX and HP-UX. I have to think prety hard to come up with a commercial product that runs on more platforms.
Novell had NDS ready years ago.... But? "Did not ship it?" "others diddnt use it?"... What?. First, it did ship (and is shipping). Many places use it. After Win95 came out and made file and print sharing easy enough for small networks, Novells market has been Very Large orginizations: health care, government, educational instituions. Large corprate clients bought (and still buy) Novell products. Small sites did not stop buying Novell, they stopped buying any dedicated server things.
Netware 4 (and thus, NDS) was released in 1993. Microsoft server products were (being Very kind) a compleate joke untill NT 4.0, which was released in 1996. AD was not even on the drawing board untill then, and came with Windows 2000, which shipped at least three years late.
NDS cooperates with Windows just fine (in fact, it can compleatly replace the domain-based security systems). The choice was never Novell servers OR Microsoft servers.... Im sure that a lot of sites looked at it like that, and perhaps you meant to preface you post with "while true or not, a lot of people looked at NDS v. AD as:", I cant allow you to spew off historical FUD.
Anyway, now to agree with you.. NDS is cool. NDS is very cool. And as much as I like NDS, NDS isnt the answer... The answer is LDAP, NDS is just one of the possible systems that can implement that.
And NDS is, all things consitered, prety cheep. Current list price is $2.00 per end user... Unlimited installs of the product itself. (MS stuff would be more like $300 per server, plus per-client costs)
Re:NDS (Score:2)
standard (Score:1)
Re:standard (Score:4, Insightful)
Re:standard (Score:2)
Umm single signon IS using the same password for everything, except instead of some or even most users, EVERY user is doing so including the administrator?
Already Solved (Score:2)
Lucent's Factotum and Secstore [dotgeek.org] and provide the solution to quite a few network password and secure document storage tasks.
I've had this idea for quite some time. (Score:4, Interesting)
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