Protecting LDAP traffic with SSL is a good idea, especially if in network environment some applications are (ab)using LDAP as authentication protocol.
Some explanation of abusing word – LDAP never was designed as authentication protocol (like Kerberos is). Its name states it clear “DIRECTORY ACCESS PROTOCOL”. However because it is simple to use and effective it is often used as such. Because it wasn’t designed to be an authentication protocol it lacks features which would protect credentials etc. which might expose authentication data for different threats which are common for every important information sent in a clear text over a network. To say it in simple word – when you are doing simple LDAP bind over non secure connection you are just exposing your credentials to others. For proof see see screenshot from network trace below:
So I think this screenshot itself should be enough to start to think about securing LDAP traffic with SSL (convincing developers to use different protocol or to enforce SSL connection in an app might be on the other hand tough task).
Getting back to the topic – good news is that Active Directory infrastructure makes it pretty easy to enable SSL on LDAP protocol. Just give DC proper certificate and it will start to accept LDAP over SSL connections. “Proper” means that it has to meet some criteria, one of them is that its purpose statement should contain Server Authentication (18.104.22.168.22.214.171.124.1) OID on a list.
Deploying certificates in environment with Enterprise CA based on Windows Server integrated with AD is also easy – you can take advantage of auto enrollment feature and DCs will request and install certificates on their own. It is also possible to use third party certificates. Procedure for requesting and installing such certificates on DCs in described in KB321051. In both cases (auto enrollment and KB manual procedure) certificate is being installed in Personal store of local system.
This store has this disadvantage that it might contain many different certs installed by other services and applications if required. If it will contain many certificates meeting requirements for DC to use this cert to protect LDAP traffic it will just pick one. We don’t have real control which one.
Since Windows 2008 there is a way to have more control on this behavior and select certificate which will be used to protect LDAP traffic. If certificate will be put in NTDSA\Personal store instead of default Local system store it will be picked up by directory service in first place and used for LDAP traffic protection.
If there will not be any of certificates in NTDSA\Personal store DC will fall back to old behavior and search for certificate in Local system store
Looks easy … one problem I have with this solution is that I can’t find a way to use auto enrollment mechanism to enroll certificate for DC and put it directly in NTDSA store. If there is anyone who have idea how to do this … comments are open :).