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."

Comments

OSS it's own worst enemy

[MrIrwin]

The problem is not just authorization. There is a tendency to plug for compatibility with the others rather than establish it's own standard.

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

[Anonytroll]

What about PAM?

Re:Dumb question

[dcowart]

PAM is for sorting/utilizing multiple local authentication & authorization schemes. The article is refering to a server-side application that has all of the authorization and authentication information stored on it(and even more info, groups, printers, servers, services, etc). The OpenDAS would allow people to setup directory and group info independant of local machines, and this information would be used enterprise wide. OpenDAS is a really good idea and working in the enterprise for several years now, I realize it is a very much needed feature of linux.

Re:Dumb question

[noselasd]

What about it ?
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 ....

Re:Dumb question

[Anonytroll]

I see. Thank you for explaining it. I feel enlightenened. :)

Re:Dumb question

[noselasd]

>OpenDAS is a really good idea and working in the enterprise for several
>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 ;)

Formula

[Spoing]

1. IT managers want to be able to install servers and desktop client machines on their network that securely authenticate users against a centralized database. This should be a straightforward procedure. Until there is a standardized, interoperable, community and industry supported network authentication system included with most open source operating systems, Microsoft will continue to rule the enterprise.

Substitution of the above with a few blanks;

1. *BLANK* want to be able to *BLANK* on their *BLANK* that *BLANK*. This should be a straightforward procedure. Until there is a standardized, interoperable, community and industry supported *BLANK* included with most open source operating systems, Microsoft will continue to rule *BLANK*.

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 _______.)

The problem is for windows...

[curious.corn]

... 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...

Re:The problem is for windows...

[duffbeer703]

That's a non-problem. Windows comes bundled with an robust, easy to use if not "standardized" directory and kerberos implementation.

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.

Re:The problem is for windows...

[hattmoward]

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. 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 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

[Twylite]

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:

• Transparent channel setup, including exchange of credentials and initialisation of security parameters for integrity and/or confidentiality
• A message-oriented protocol. Message-orientation can provide huge benefits in terms of security, especially if you have a standard daemon/service that handles message receipt and verification before passing it to "third party" code. Such a service can act as a first line of defense against buffer overflows and other data corruption attacks.
• Allow the service end to impersonate the credentials of the client (temporarily drop permissions), so that there should be no need or excuse for any application to have to invent or implement its own access control system.
• Provide sufficient hooks and feedback to allow the user to offer alternative authentication, prevent authentication (force anonimity), or reject the authentication of the server end.
• Is extensible without being ridiculous. The need of certain frameworks to support 10 or 20 cryptographic mechanisms on the server is ridiculous. It makes servers bloated and difficult to develop. At any point in time only one well-considered mechanism is required per desired outcome (e.g. one sign-on and symmetric key negotiation protocol, one symmetric encryption and message authentication protocol).
• Is easy to use in development. Complex frameworks, as a rule, are complex to use. Thus developers have a preference for reinventing the wheel, because a wheel is easy to understand, whereas a pneumatically endowed polybutadiene sheath of configurable pressure attached to a transverse axis situated at the vertical midpoint of the supporting plane and the bottom of the cart isn't quite so clear.

But that's just my 2c.

I agree.

[torpor]

Continuously playing 'second fiddle' to Microsoft is no way to develop software. They're counting on this factor, so why should we give it to them?

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.

[Spoing]

1. Continuously playing 'second fiddle' to Microsoft is no way to develop software. They're counting on this factor, so why should we give it to them?

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.

1. 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.

There are plenty of booring things...depending on the person. I no longer describe in detail what I do for a living. People don't get as excited as I am unless it's a peer -- and many of my peers think it's booring too. 1 or 2 phrases or a short sentence would be a tome these days.

NDS

[4of12]

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

[T-Ranger]

why not bring out Novell Directory Service across platform?
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

[Wesley Felter]

Isn't NDS mostly just an LDAP server? We already have LDAP servers. The hard part (as the article says) is making all the parts that we already have just work, especially on the client side and across all the various distributions.

standard

[kwoff]

Yeah, let's make all the security systems the same so that it's more convenient - not only for the sysadmin, but for those trying to attack the system...

Re:standard

[walt-sjc]

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.

Re:standard

[shaitand]

"or worse, use the same password on everything)????"

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?

Setting up kerberos

[yandros]

This suggestion (that kerb5 is so hard to set up) makes me sad.. Is it the kerberos side that's the trouble, or the ldap part (or both, I guess)?

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

[beegle]

The problem is the flexibility.

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 to set things up. That means that they're all set up the same way.

Re:Setting up kerberos

[T-Ranger]

Being a Linux Admin, working mainly in ISPish companies for 5 years, a recurring problem has been user/account management. Every job that I've had, they have wanted me to build something like Plesk/ensim/cpanel. Anyway; beh... One of my personal holy grails has been a common, centerlized, user/account DB.

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.

Re:Setting up kerberos

[walt-sjc]

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.

Re:Setting up kerberos

[duffbeer703]

If it's so easy, why doesn't anybody write it down?

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 environment and it sounds absolutely amazing. I'm just speaking from my experience.

Re:Setting up kerberos

[yandros]

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.

Already Solved

[DrSkwid]

Lucent's Factotum and Secstore and provide the solution to quite a few network password and secure document storage tasks.

I've had this idea for quite some time.

[mewyn]

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