Here at the Crossed Wires Campus I’ve had LDAP at the centre of most of what the network does for quite some time now. User-id management, telephone directory (integrated into the phone system), automount maps, Samba domain database; I even had DHCP running with LDAP as a backend for a while. Most boxes in the house touch LDAP in some way every time they boot. To demonstrate the multi-platform portability of that kind of configuration, I even had the Macs in the house able to log on user-ids that existed only in LDAP. Until recently.
I don’t know the details of it, because it was something I only did occasionally to show that it still worked. Now it’s stopped working, presumably after a Mac OS X update or other. When I try and log on with an LDAP user, I get the wobbling password box. That’s it. The system logs tell little on the Mac, but on the LDAP server I get an error message about a failed SASL bind.
I’ve only ever set up SASL enough to support IMAPd, and even then it’s just talking to LDAP to do the work. I use LDAP to store passwords, and for my purposes that’s always worked. It used to work on the Mac too, but I can’t get him to stop trying to do a SASL bind to LDAP.
At about the same time as this, I was playing with a Jabber bot. I read the instructions, configured appropriately, and it completely failed to function — its logon to the Jabber server was rejected. Wireshark to the rescue — it was trying to use SASL to log on the the Jabber server. Sure enough, my Jabber server was advertising SASL authmechs. I removed the SASL settings (well, just the available authmechs) and the bot was able to log on.
So I started thinking if these issues were the kick I needed to set up a proper SASL and Kerberos system. My ideal would be to get saslauthd to provide authentication service without having to go all the way to GSSAPI/Kerberos, something that should be possible… except we’re talking about security systems here, so it seems that “The Right Way” is the only way.
The OpenLDAP documentation doesn’t discuss the SASL mechs PLAIN and LOGIN, since in their opinion they’re no different from LDAP simple bind. Be that as it may, it would be nice to know how to do it!
DIGEST-MD5 is next, but the way it works you have to store user passwords in clear-text in LDAP (yes, clear-text passwords!) or use SASLDB2 to store passwords. The former is unattractive, since I’m not so confident in getting an LDAP ACL right that would protect the password field from undesirable reading while still allowing it to be used, and the latter means I’d have to move everything to SASL auth unless I want to have password synchronisation problems (the very thing that moving everything into LDAP was meant to avoid).
Next comes Kerberos… If I’m doing a heap of work to cut things to the DIGEST-MD5 SASL mech, might as well go all the way to GSSAPI, right? That means more work, and again possible password sync issues between the Kerberos DB and those things still getting their passy from LDAP (although it looks as though using SASL you can tell OpenLDAP to consult Kerberos for password validation, so things using LDAP for password checking would actually get handled by Kerberos anyway).
One thing I thought to try was to rebuild OpenLDAP without SASL support — I’ve got a nasty feeling that since the last time the LDAP login worked on the Mac, I added “sasl” to the USE flags on the server. Being built with SASL support means that slapd is offering it, even if it’s not set up (an ldapsearch for supportedSASLmechs verified this), and the Mac is seeing SASL auth advertised by the LDAP server and demanding to use it… While a good theory, it’s not the problem. The only difference in the log now is that there’s no message complaining about a failed SASL connection.
So after all that waffle about SASL, it looks like there’s something else happening. Likely something to do with the strange posixGroup entries it’s looking for called “ffffeeee-dddd-cccc-bbbb-aaaa-0000003c” and so on…
Back to the drawing board.
Crossed Wires 