LDAP/Active Directory Server SAN


I have noticed that while many customers were using integration to Active Directory, many were using LDAP not LDAPS. One customer in particular said it didn't work. I noticed an internal BMC system was only LDAP enabled, and not to our corporate AD. But I knew *some* customers environments were able to use LDAPS against AD.


I had set up my own LDAP server some time ago, based on 389 Directory Server, but had never got round to adding LDAPS for security. In the end it was pretty uneventful: I just created some suitable certificates with my own CA, and loaded them up through the 389 DS Console UI.


Then, the normal configuration of LDAPS in the Discovery UI can be done - again, rather uninterestingly straightforward. So, time to check out AD: I pointed to our AD Prod alias and...




just like the customer who had told me it didn't work. A simple bit of checking with revealed that the DNS entry I was using for AD was an alias that resolved to multiple servers - not unsurprising in a large enterprise. Each of the AD servers supplied a certificate with a CN based on their own DNS A record, not the CNAME of the cluster of machines. There were no Subject Alternative Names, so the client (Discovery Appliance) failed to validate the AD servers' certificates.


Solution: Ensure the certificates have SANs for the hostname you are connecting with.




Now in the old days, ldapsearch was an invaluable tool in testing/checking LDAP configuration and structure from the appliance. In later versions, it is less so, as the UI has been improved. However, for completeness I though I would check it.


Non-secure LDAP worked as expected:


$ ldapsearch -W -H ldap:// -D "cn=Directory Manager" -s sub -b "ou=Security,dc=tideway,dc=com"  "(description=Staff Members)"


But when I tried to run it over a secure connection, I got a TLS error:


$ ldapsearch -W -H ldaps:// -D "cn=Directory Manager" -s sub -b "ou=Security,dc=tideway,dc=com"  "(description=Staff Members)"

Enter LDAP Password:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)


because ldapsearch does not know about the LDAPS server's CA certificates. The client configuration file for ldapseatch and other OpenLdap client tools is in /etc/openldap/ldap.conf, and by default has a pointer to a directory containing CA certificates:


TLS_CACERTDIR   /etc/openldap/certs


I thought initially we could just copy/link the Discovery LDAP CA file (/usr/tideway/etc/ldap_cacert.pem) here, but, it's not that simple: this directory doesn't hold simple PEM files, it contains a mini database of NSS certificates. What you have to do is add those PEM format CA certs into the NSS database, like this:


$ certutil -d /etc/openldap/certs -A -n "LDAPS CA Certificates" -t "C,," -a -i /usr/tideway/etc/ldap_cacert.pem


You can check it loaded thus:


$ certutil -d /etc/openldap/certs -L

Certificate Nickname                                         Trust Attributes



LDAPS CA Certificates                                        C,,


If you need to, you can delete with the -D flag, referencing the same Nickname:


certutil -d /etc/openldap/certs -n "LDAPS CA Certificates" -D


Anyway, now ldapsearch returns results over a secure TLS connection:


$ ldapsearch -W -H ldaps:// -D "cn=Directory Manager" -s sub -b "ou=Security,dc=tideway,dc=com"  "(description=Staff Members)"

Enter LDAP Password:

# extended LDIF


# LDAPv3

# base <ou=Security,dc=tideway,dc=com> with scope subtree

# filter: (description=Staff Members)

# requesting: ALL



# Staff, Groups, Security,

dn: cn=Staff,ou=Groups,ou=Security,dc=tideway,dc=com

description: Staff Members

objectClass: top

objectClass: groupofuniquenames

cn: Staff

uniqueMember: uid=ENoether,ou=People,ou=Security,dc=tideway,dc=com

uniqueMember: uid=ALovelace,ou=People,ou=Security,dc=tideway,dc=com

uniqueMember: uid=JWatson,ou=People,ou=Security,dc=tideway,dc=com

uniqueMember: uid=HPoincare,ou=People,ou=Security,dc=tideway,dc=com


# search result

search: 2

result: 0 Success


# numResponses: 2

# numEntries: 1