So I spent the weekend moving stuff at work over to use LDAP, and I’ve discovered something about a lot of stuff that uses LDAP for a data storage backend: namely, they all have issues with SSL/TLS. To start, OpenLDAP has four different transports:
- UNIX socket (ldapi://)
- Plaintext on port 389 (ldap://)
- Plaintext on port 389 that “upgrades” to TLS (ldap:// + StartTLS)
- TLS from the start on port 636 (ldaps://)
PowerDNS and DHCPd+LDAP only support 2 and 3, and neither seems to allow for certificate checking with a custom CA when using #3. Which sucks, as I’d like to replicate the primary LDAP server’s stuff to the machines running daemons which use LDAP (DNS, DHCP), and it’d be nice to have the secondary machines’ daemons use UNIX sockets only, but that’s just me being anal about it.
James Cape 
Heh, another problem is some stuff tries to authenticate by retrieving password hashes and comparing the SSHA hash or whatever client-side, instead of just doing a bind(). I think pure or proftpd did that….some LDAP servers don’t even let you retrieve the password hash itself (although OpenLDAP does…) for security reasons.
Also – did you verify that PowerDNS / DHCPd don’t simply use the OpenSSL certificate stores and CAs? Some apps use that, instead of handling the certificates themselves.