So for our applications with LDAP configuration (like Nextcloud) we’d like to encrypt the LDAP connection because without it, it’s just plain text.
For Microsoft Active Directory Domain Controllers this can be done by adding a certificate to the Domain services. This can be done with mmc.exe and adding in the certificate to the service account for the Domain services:
After that import a certificate from the NTDS\Personal tree:
We’d like to add a wildcard public domain certificate (like *.thegood.cloud) but you could use your own CA or SAN certs or Let’s Encrypt. If you want to know more about this, you can duck it.
Testing if the LDAP connection works can be done with LDP.exe, which should be installed with AD tools from your server manager:
You have to fill in a FQDN so the LDP tool can check the certificate, so something like server1.thegood.cloud (Which means you also need to have your dns in order off-course).
When a LDP connection fails, it returns this:
And a whole bunch other info if you have a successful connection, which I won’t screenshot due to all the delicate information in the screenshot. But I will refer you to the Kemp support which has a nice article about troubleshooting with LDP.exe if you want to see an example.
To check the certificates on the LDAPS service I used the openssl tool with bash with the command:
:~$ openssl s_client -connect IPADDRESS:PORT
This is particular useful as the ldp.exe does not show any certificate information (I had to censor a lot of the sensitive content, sorry about that). Also, the DC’s cache their requests, so restart the Active Directory Domain services in your services.msc before you test your connections.
But as these are Windows Servers, you probably have some downtime at least once a month while updating the servers. As we have Kemp Loadbalancers in place already, we could make this a HA service with just adding an entry to the Kemp so that your LDAP enabled applications don’t experience any downtime when one of the DC’s are down.
It’s funny that you getting your first Kemp Loadbalancers is hard (explaining why you need them, get your boss to invest, writing business cases, etc.), but when you have them in place, you can use them for virtually every service in your network! ;-). They even have a free edition, which would be perfect for this implementation as it allows for 20Mbit of traffic!
But on with the technical details: we use a generic configuration for the VIP:
You could not enable “use SSL acceleration” and “re-encryption”, but you would still need a certificate on the DC servers. The Health check leaves something to be desired, as I would like to have a LDAPS health check. The current health check just checks if port 636 is reachable, which it is, even without a certificate and a failing ldp.exe connection. I guess you could do it with the Kemp adaptive agent but I want to finish this blogpost today, so that’s for the future I guess.
So there you have it: a nice HA LDAPS service for all your applications.
Or.. is there more…?
I found this:
- server01 = had an expired certificate
- server02 = had an active certificate
- VIP on the Kemp with a valid certificate, SSL acceleration and re-encryption enabled, let’s call it vip01.thegood.cloud. Vip01 has server02 disabled so the only active server is server01.
I used ldp.exe op port 636 and found:
- on vip01.thegood.cloud the ldp connect succeeded. Ldp.exe showed it had a successful connection to server01.
- on server01.thegood.cloud is failed.
So whats happening here? Basically the ldp.exe tool verifies if the certificate is valid and if not, it won’t setup a SSL connection. But the Kemp does have a valid certificate in place so the tool connects. On the backend you might expect the realserver connection to fail, but the Kemp actually does not verify the SSL connection. This is done for performance reasons, but in this case it could be a security issue. So it can be turned on and was introduced with version 7.2.37.1 under 13.2:
Allow explicitly trusting of self-signed or untrusted Real Server certificates.
And it’s located under System Configuration > Miscellaneous Options > Network Options; you’ll see a new Force Real Server Certificate Checking option, which is disabled by default. Enabling this checkbox turns on RS Certificate Checking for all Virtual Services.
Also be aware for this:
This feature checks against installed certificates on the LoadMaster. We currently do not check against a public database. In order for the check to work the Root, Intermediate, and Server certificates must be add the the certificate store on LoadMaster.
So basically the ldp.exe tools checks the client certificate and won’t make a connection if it there is no valid certificate. But as the Kemp does not bother to check the validity of the connection, the connection from the Kemp to the real server still succeeds (even with an expired certificate). Ldp.exe does not know what’s behind the vip01.thegood.cloud so it just checks that certificate, which is valid and further sets up the connection.
So..
- If you don’t enable SSL Acceleration you need valid certificates on the DC servers.
- If you enable SSL Acceleration and Re-encryption on the VIP, you only need a certificate on the AD servers, which even can be an expired certificate. On the Kemp VIP you still would need an active certificate. This is useful as you still want LDAP to be secured, if you want to manage your certificates on one location.
- If you have security concerns about not checking the validity of the certificate, you could set the LB up with checking the certificates but you would need to update the Kemp to at least 7.2.37.1 and import the CA stores of the certificate being used. You would also need to have valid certificates on both the Kemp and the DC Servers.
While the last option looks to be the most secure, it’s also the most work intensive and requires you to monitor and alert expiring certificates on both the DC’s and the Kemp. For the smaller environments, I would opt to use the second option as it centralizes your certificate management. It’s a shame Kemp hasn’t implemented Let’s encrypt yet (please vote!)