Results tagged “LDAP” from ILikeJam

LDAP Headfuck

| | Comments (1)

LDAP: Largely Dangerous And Painful. Let me describe why. (Normal people can give this one a miss. Fellow sysadmins can revel in the ridiculousness).

I'm in the middle of putting an LDAP infrastructure together, and rolling it out to 40-odd Solaris boxes for user authentication, NFS auto mounts, sudo and all that good stuff. Our consultant/contractor/architect worships at the alter of the Sun gods, so OpenDS 1.2.0 was his choice of LDAP server. Not a bad choice, to be honest - it's a piece of piss to set up and get multiple servers multi-master replicating, and it's Free.
All was tickety-boo until a week ago.

First up, all 4 replicating LDAP servers hung overnight. This locked out the admin team from half of our machines until I got into work and poked them back into life. No errors in the logs, nothing weird going on, just hung Java processes and no logins. Brought down 2 of the instances and upgraded the other two to OpenDS 2.0 so hopefully that should be the end of that. Hopefully. Maybe.

Then today, I'm happily LDAPing away when I ran an ldapmodify to change the UID of the user that runs out monitoring software. LDIF imported, no problem, except I'd run the ldapmodify binding as the user I was modifying, not the Directory Manager. Alarm bells went off in my head - users shouldn't be able to modify their own UID numbers. I tried it again, using 0 as the UID, and sure enough it turns out that anyone that could authenticate to LDAP could also change their UID so that they were running as root. Fuck me very hard indeed. A very swift google tipped up an ACL to add to stop this, as well as a whole load of other possible nightmares.

Next, while messing with the ACLs for the UID problem, it occurred to me that the 'proxy' user could see everyone's passwords in the directory. This is by design, since we're using proxy authentication on our Solaris hosts (which means user passwords aren't sent over the network in plaintext), but it also means that anyone logged into any LDAP-enabled Sun box can search for and list everyone in the directory's passwords with a simple 'ldaplist -l passwd'. The passwords are encrypted, but the old-skool Unix 'crypt' isn't exactly what you'd call military grade protection. Shit.
To get round this, I'm currently beating my head against the brick wall of TLS/SSL so we can remove the need for a proxy user. The tools supplied with OpenDS work fine, but the native Solaris stuff won't go near the self-signed certificates we're using (either that or I'm Doing It Wrong, I'm not entirely sure yet). I've given up for the night, but it looks like I'm going to have to generate CA certificates, then regenerate and sign all the certs for the LDAP servers, then import them, then import the CA and server certs into the LDAP config on the clients, then see if the native Solaris stuff works with them, then re-run ldapclient on all the clients. Arse.

I don't get paid enough for this.