EKM

Having spent far too long trying to work out to make PHP 5 create usable password hashes for OpenLDAP from examples on the Internet (hint, comments on the md5() function on php.net are dangerously wrong), I resorted to reading the RFCs and writing the code myself. This is posted below for other people who might have the same problem.

# This will generate an MD5 sum hash.
$encrypted_password = ‘{MD5}’ . base64_encode(md5( $newpassword,TRUE)) ;

# This will generate a SHA-1 hashed password.
$encrypted_password = '{SHA}' . base64_encode(sha1( $newpassword, TRUE ));

# This will generate a SHA-1 hashed password with a salt.
$encrypted_password = '{SSHA}' . base64_encode(sha1( $newpassword.$salt, TRUE ). $salt);

References:
RFC 2307
RFC 3112
OpenLDAP Faq-O-Matic

Versions:
PHP: 5.2.10 (Ubuntu Karmic/9.10)
OpenLDAP (Ubuntu Lucid/10.4)

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.

Thoughts?