Home > Tech > Downgrading LDAP

Downgrading LDAP

March 25th, 2009

About a month ago, this gem was posted in IRC;

Now, if LDAP (and in particular OpenLDAP) wasn’t such a stinking pile of crap we’d have used that instead, but unfortunately it is. Perhaps we should move the passwd file into Hesiod some day too…

The author explains, in essence, why he ended up storing user/groups in DNS. This is a completely horrible hack, but somewhat understandable. Having fought with OpenLDAP in the past, I can see how this kind of thing happens. It is possible to bludgeon OpenLDAP into some resemblance of usefulness, and get it to perform satisfactorily once you’ve twiddled the indexes in just the right way. It might even update it’s slaves if you ask it nicely and sacrifice a chicken under a blue moon…

And then you upgrade and it falls over again and you have to relearn and rewrite all the configuration files and reimport all the data. Meanwhile, the Kerberos server that you built four years ago is still ticking along without a hint of problems, and all you really want to do is keep the account information for twenty odd users and groups on your local LAN in concurrent state across a bunch of servers and workstations. How hard should that be?

The solution I’m pushing around in my ~/play directory is called Suds (Simple Unix/User Directory Service). In essence, it’s a telnet interface to a cdb database that returns records that look very similar to what you find in /etc/passwd and /etc/group with the addition of a realm and timestamp field. There is no authentication, except some basic options to limit access via subnet. Write access is via the filesystem on the server. To facilitate the easy creation of slaves, sending UPDATE:timestamp to the server will return all the records changed since that update.

The system won’t support storing passwords, since Kerberos, RADIUS, and ssh keys already do a much better job. The idea isn’t to replace LDAP, but to provide a simpler alternative for administrators of small networks with between about five and fifty users/hosts.

The prototype server code is about 40 lines of bad python, and I’m currently trying to hack together an NSS module, which will hopefully support SRV records to simplify deployment.


Categories: Tech Tags: , , ,
  1. March 25th, 2009 at 12:12 | #1

    Isn’t broadcasting password hashes to the LAN a bit in the opposite direction of the shadow file? Passwords suck and as a result even salted hashes of them are easily reversible.

  2. edward
    March 25th, 2009 at 12:23 | #2

    As mentioned (and then discussed); “The system won’t support storing passwords, since Kerberos, RADIUS, and ssh keys already do a much better job.”

  3. March 25th, 2009 at 15:09 | #3

    That sounds neat. I’d be happy to provide some Python cleanup if you like.

  4. martin langhoff
    March 26th, 2009 at 01:14 | #4


    I was the resident ldap expert for a few seasons @ 150 Willis Street, and I spent most of the time moving people away from it. Lockups, dataloss, bad performance and general opaqueness… some of it we can blame on OpenLDAP being a bad implementation, but some of it is because LDAP sucks as a modern protocol.

    In other words, I agree with you 200% :-)

    Now, what to do? For user/group auth in a small network… I say: pam_postgres, pam_mysql. If you are running any other app in your office that has an account for each user, make a VIEW that exports the user data in a way that pam_postgres likes, and – blam! – done!

    All the hard bits of infra are done. A howto, plus a few scripts to automate the setup, and you could have something that works almost out of the box easily…

  5. edward
    March 26th, 2009 at 11:06 | #5

    @martin langhoff I’m glad someone else sees that LDAP doesn’t really work! I have played with *SQL as directory servers. My impression is that while it does lower the barrier to entry, it’s still a bit of a square peg in a round hole. SQL services are a bit too heavy, replication is non-trivial (and you really do need replication), and authentication should really not be done via SQL, since almost everyone fails to encrypt anything – plus, the overhead seems to be quite high for a simple text record lookup.

    I want this to be as simple as possible, so it will keep running when everything else is dead. (The server will probably be eventually rewritten in C with minimal library requirements). Also, I’d like to add automagic SRV record discovery, and that’s not really possible without rewriting the nss plugins anyway…

  6. martin langhoff
    March 26th, 2009 at 19:58 | #6

    Reasonable points.

    You said it’s for a small/midsized network, so I wonder: replication or caching? And Postgres libraries have been doing the ssl thing pretty well for a while now, so I suspect you could do it fairly well…

    In any case, for cheap replication, and avoiding SQL, could git be an alternative?… ;-)

  7. Edward
    March 27th, 2009 at 13:43 | #7

    @martin langhoff
    “Replication or caching?”: Both! It’s the exact same mechanism.

    As for git… let’s not even go there – even in jest.

Comments are closed.