As some are probably aware, Microsoft were planning on releasing a patch in March 2020 that will make some changes to LDAP. Since that announcecment MS have admitted that they have had a lot of feedback on this upcoming change and so have scaled back their plans. Thier blog article is pretty good and worth a read just to understand what is coming. You can read it here.
I will admit that even though this article is a few months old, (I assume that the date is in US format, so 4th Nov 2019 - People, please use dates that the whole world recognises), I wasn't aware of the planned changes to LDAP until a few weeks ago.

It is worth having a read though the MS article and checking to see if your AD environment uses LDAP for any services. If it does, it is a very good idea to move over to LDAPS because LDAP does not use any encryption. If it's being used in AD then passwords will be going over the wire in plain text.

Fortunately, enabling LDAPS on AD servers is not a difficult task. All it needs is a cert that supports server authentication and that is it.

If you run a Windows CA environment then the chances are that you already have the necessary certs in place as the Windows CA can do these for you. If not, it is very easy to add them using a different CA host.

The first thing to do is to test LDAP and LDAPS just to confirm the current status. I really like the LDAP browser application for this. It is free and you can download it from here (just make sure you click on the LDAP Browser tab as that is the free one).

Once downloaded, install the app, launch it and create a profile, add in the name of one of your AD servers then click on the 'credentials' tab and either select "Currently logged in user" or select "other credentials" and then "GSS negotiate" from the drop down. LDAP on Active Directory does require an authenticated user, it cannot work with an anonymous user.

Once complete, hit OK and you should get a connection to the LDAP server.

That means that everything is working on port 389 and this should be the same for all your AD servers. LDAP should work right out of the box.

The next thing to do is test the connection against LDAPS and to do this, it is just a matter of changing the profile to use a secure connection:

When I run this test against one of my lab AD servers I get a com error:

This means that my server is not able to talk LDAPS. Fortunately, enabling it is pretty simple.

To get LDAPS working, I need to install a cert on that server. For LDAPS to work, I need a cert that supports "Server Authentication" as a cert function and fortunately, my personal internal CA of choice (pfsense) supports this type of cert so all I need to do in PFSense is create a cert. I could create one cert for each domain controller or I could just create a wildcard cert but I am not a fan of either option so what I will do is create a single cert that can support both AD servers.

In my PFSense internal CA, all I have to do is create a server certificate and name my two AD servers in the Alternative Names section as this will ensure that the cert will work against both servers

Once that has been done, I can download the private key and the cert from PFSense, now, windows being windows, I need to convert the public and private key files into a pfx file as that is what windows prefers and to do this I just use the online tool at https://www.sslshopper.com/ssl-converter.html

At this point, a few people might be horrified that the CA holds the private key and that I am using an online service to do the cert conversion especially as I will have to hand over my private key. Well, two things to remember - the CA is under my control so I am not too bothered about it hosting the private key and the second thing is that these certs are internal only. To get my internal clients to trust the CA I need to push out the CA public key to their trusted cert stores. If this was an external site I would not be as happy to give up the public key as I am with my internal CA.

Once I've got my PFX file, all I need do is copy it over to the domain controller and add it into the local machine cert store. It must be the local machine as LDAPS is "owned" by the server itself and not any admin who logs into the server:

And you should now be able to connect to the server using LDAPS.

Ben Hooper covers this process on the Windows CA and Let's encrypt side plus he has some very handy powershell commands for interrogating your AD servers for LDAPS. His blog article is worth a read and it can be found here