What happened to Directory Services?

On Twitter a few days ago, a tweet from @jwildeboer caught my attention:

OATH, OAUTH, OpenID - this is all getting too complicated. We need simple identification for the future.

The reason it caught my attention was not because I agree with him (I do), but because the idea of simple authentication, especially among disparate systems, has been the Holy Grail of IT, and every time we think we have it solved, the solution seems to fall apart in our hands. In fact, OpenID/OAUTH/OATH is only the most recent attempt at solving the authentication problem. The last attempt was a little standard called X.500, and Jan's tweet this morning reminded me, not only of x.500 and its promises, but how far the standard has failed, because of its complexity.

I have not really thought about Directory Services lately because I have been in so many shops where it has been so badly implemented (or not) that it is almost not worth thinking about, even though millions of users use it, or rather its baby brother, LDAP, every single day, most notably in the form of Active Directory, but also Novell Directory Services, Oracle Directory Services, Fedora Directory Services and other LDAP systems, too numerous to mention, most depending on some form of the OpenLDAP project.

But Directory Services were, themselves, an attempt to solve the user virus problem of large, disparate, interconnected networks where tools like NIS and NIS+ were functionally running out of gas, while providing access to other, more secure authentication features as this thing we call the Internet was really beginning to take off. The X.500 standards were designed to make it easier to interconnect systems using a standard lookup mechanism. It was, of course, a hideous disaster, as anyone who has had to work with a pure X.500-based system can tell you, at least from a functional standpoint, but from a theoretical standpoint, it was the right direction.

In the 1990s, companies like Oracle and Novell both posited that there needed to be some form of interconnected directory service that would facilitate the ability to prove you were who you were without having to register with each and every web site and system that you needed to connect to, whether you were on your private intranet or the public Internet. And like simple authentication, the idea of single sign on has been a snipe most of us have spent our careers chasing.

For example, I worked at an organization where Microsoft's Active Directory was the law of the land. It controlled everything from how your desktop looked and performed (if you were running Windows of course) to how you accessed your email, to how you accessed the VPN. But when you connected to the education and training system, you had to have a completely different set of credentials. And since most people only connected to the system yearly for those mandatory sessions we all have to take in the corporate world, there would be a huge flush of trouble tickets at the beginning of the year for password resets (the system did not have an automated password reset system either - that was for security reasons...yeah, yeah, I know, I did not design the system, I just had to use it, but I digress). The point here is that when the system was being designed, there were discussions about how to integrate authentication with the Active Directory structure and the powers at large decided that it would be a bad idea to do that. This was not some antique mainframe that could not be connected without a Herculean effort, this was a simple web site, running on Microsoft software.

If you use LDAP, you know how much of a challenge it can be to not only set up, but integrate and manage. Creating a usable LDIF file is almost an arcane science (and a hold over from the X.500 days), and integrating LDAP authentication with some systems is easier than with others. It has gotten better than in the early part of the century, but it is still not as easy or as seamless as we would like it to be, especially when you are going across platforms to some that are less LDAP aware or even support a different implementation of LDAP.

Several years ago, I actually signed up for an OpenID. Between then and now, something in the OpenID standard must have changed, because my OpenID credentials from then no longer work now, which really defeats the purpose.

The point here, though, is that in 2010 we are still looking for a method to connect to systems without having to register with all of them. And with all our current solutions, we still have not quite got that problem solved. And if someone mentions web of trust I might scream. Because, after all, that is the root of the problem, or at least one of them.


David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Nice post, I have been

Mufti's picture

Nice post, I have been creating facebook apps using facebook API


Excellent post.I want to

samanta's picture

Excellent post.I want to thank you for this informative read, I really appreciate sharing this great post. Keep up your work.

tarot gratuit , Voyante


Anonymous's picture


Anonymous's picture

Please ...

Hannes Tschofenig's picture

... take the time to read into the subject before publishing an article about it.

OAUTH, OpenID, and LDAP are protocols; each fulfilling a different need. In fact, they can also be used in combination, depending on your use case.

OATH, see http://www.openauthentication.org/ is an organization and not a technology. The technology itself is developed in the IETF, in the KEYPROV working group http://datatracker.ietf.org/wg/keyprov/, and I co-chair that group. It is primarily focused on provisioning symmetric keying material (often needed for authentication systems).

OpenID is a protocol for Web SSO. OAuth is a protocol for delegated authentication. LDAP is as the name says a directory access protocol and it does not address the cross-domain authentication problem. There are other protocols, such as Diameter, RADIUS or Kerberos, that could also be mentioned. Etc. etc.

It is fashionable to say that 'X is too complex' but you have to say WHY you think so since otherwise the statement is mood. Maybe there are sometimes reasons for the complexity -- namely the use cases that people want to address? Maybe those are not the use cases you primarily care about but that's how standardization works.

Let's not mix things

Dipesh Sharma's picture

I think we are mixing two different things here. Directory/X.500/LDAP and OpenID are different kinds of systems solving different classes of problems.

Direcory/X.500/LDAP is about storing the information of resources (both human and non-human) for efficient retrieval. Authentication comes as a side effect of bind operation.

OpenID is about SSO/Federation of the identities which have already been authenticated. It is not necessary for authentication to be done against a directory for it to be SSOed or federated. The system that authenticates interacts with system that is accessed using techniques which are independent of the back end.

We are going in right direction with directories becoming internal to the organizations and identity exchange being done through SSO/Federation.

I agree that a serious effort needs to be done on standardizing the SSO and Federation domain. Projects like Liberty Alliance and OASIS are doing great work in this direction.

By the way, LDIF no longer needs to be written by hand. Lots of tools are available for commissioning and decommissioning. Tools can be written in high level languages using LDAP APIs, obviating the need of writing LDIF.


Khürt L Williams's picture

Facebook and Twitter solved the authentication problem on the web. Users use Facebook and Twitter to login to others sites because it's something they already have (a twitter or facebook account) and it's easy to use.

I don't know of any solution for the desktop. Perhaps Facebook and Twitter can offer software tokens.


mattcen's picture

This is not a solution.

Firstly, you can't log into Facebook with your Twitter credentials, or vice-versa, so at the very least, you need two distinct authentication credentials to access these two services.

Secondly, this implies that you need to use one or both of these services in order to simplify your access to the rest of the web. Would you honestly trust Facebook or Twitter with the keys to your life? As an extreme example, would you log into your bank's website using your Facebook details, knowing that if someone cracked into Facebook, or the company decided to be malicious, they could get access to all your money?

What if Facebook/Twitter were inaccessible for the day, and you needed access to the sites for which you used one of these services to authenticate. What would you do then? Granted, this problem exists with *any* centralised directory service, but with these two services in particular, I don't think their primary concern would be that you can access your other sites.

No, I think that as part of the solution, you need a more trustworthy party (such as a well-known security firm) to take care of your personal details, and a decentralised system such as that provided by LDAP. Even the company for which you work might be more trustworthy than Facebook when it comes to your data.

Matthew Cengia

People are using it even if you don't trust it.

Khürt L Williams's picture

None of your arguments appear to matter to consumers. Facebook has 500 million active accounts and Twitter had 100 million. OpenID, OAuth etc are already winning this. Geeks wants some elegant technical solution while consumers will just use what works - right now.

Never a truer word

mattcen's picture

Overall I agree with you David. I am trying to think of security issues with using LDAP auth for everything, but with my limited LDAP experience, I haven't thought of anything yet. For a long time (over a year now) I've been trying to configure my own LDAP server, to (at least) consolidate authentication between Windows, Linux, and HTTP auth, but have yet to find good LDAP management tools, that preferably work from the command line. One day I may understand LDAP well enough to consider how it could be implemented as a global distributed auth system, but I think that's quite a way off yet.

Matthew Cengia

LDAP with Linux, Windows and HTTP

Jan Christoph Ebersbach's picture

Hi Matthew,

I totally relate. It's a really big challenge to integrate LDAP with everything else smoothly. Univention, a German OSS company, built a Linux distribution called UCS that heavily relies on LDAP. The basics like Windows-, Linux- and web-authentication against LDAP are built-in. Within a company this should solve the issues you described. It also offers command line applications that take away the pain from modifying LDAP (hint: command line app is called "udm" alias "univention-directory-manager")

At http://www.univention.de/en/download/ an online demo and even ISO images are available.


Jan Christoph


mattcen's picture

Hi Jan,

Thanks for the information, I'll definitely check that out, though I'm currently in the process of building a Debian server to do the same thing. I've been trying to decommission my Fedora 8 box for over a year (and replace it with Debian), but learning an efficient way to configure and manage LDAP is holding up the entire project.

I should perhaps point out that this particular deployment is for my home network of 4 users and perhaps 5-6 desktops, so the gain of LDAP isn't really there given the effort it is requiring, but my mentality is that I'd like to learn LDAP *anyway* so that I can make use of it more in the workplace.

Given that I've been using Debian, I've found a reasonable guide at http://techpubs.spinlocksolutions.com/dklar/ldap.html, which also has other pages on integration with Kerberos (another technology I'd be interested to deploy) and RADIUS.

At my workplace we've deployed a couple of Ubuntu boxes which we've got a procedure to configure LDAP with Samba etc. on, but I feel like a bit of a purist and inexplicably would like to use Debian instead.

Thanks again.

Matthew Cengia

Free for personal use

Jan Christoph Ebersbach's picture

Hi Matthew,

Since Univention makes a living on this product, companies have buy a maintenance license (although everything is 100% OSS). But for private use they provide a free for personal use edition for 5 users. If you need more, you can contact them for a bigger license.

I just found this facts page that gives a rough overview of what's part of the distro: http://www.univention.de/en/products/ucs/components/


Jan Christoph

I only skimmed the article

Anonymous's picture

I only skimmed the article but it seems like you should look at freeipa

keep it simple

MikeFM's picture

I don't care for systems that require complex backend systems to authenticate the users, share settings, etc. A simple algorithm that generates a unique key per user per service from a simple personal key the user enters once per computing session is the way I usually go. e.g. I prompt for a user email address and a pass phrase which I combine into the personal key and take the hostname and service ID of the system being connected to and use it as a salt for the personal key. Then I give that to the server as the authentication key. The system can generate the key for everything the user is doing in their session so they aren't constantly pestered and having the key from system A doesn't give you access to the user's stuff on system B so untrusted systems aren't a danger to everything. It's simple so setting things up is easy and there isn't a lot of room for failure.

Who are We

Adam Sommer's picture

I guess it's the age old question of determining who someone is. Making sure that they are who they say they are.

Maybe we haven't solved the user authentication problem yet, because we each spend so much time trying to figure out who we are as a person?

Like a wise man once said: "I am whoever I say I am!"

Party on!