LDAPS (636) Query - New Domain Controller

Question

I have a situation where a coworker trying to change a system to issue LDAPS queries to a new domain controller (RODC) rather than to an old 2008 server that is being removed from the environment. This system is internal, on the same subnet, and has full connectivity to the domain controllers.

When he changes the system settings to point to the new DC, it reports that it cannot connect.

The system is asking for the following fields:

AD Domain

AD Host Name (The domain controller)

username \ password

Protocol (We had to choose LDAPS)

Port (We chose 636)

I am not sure how to get the server to 'respond' to LDAPS queries.

Can anyone tell me what the requirements are, particularly related to SSL Certificates?

I believe this coworker created an internal CA on another domain controller.

But, how is this supposed to work? I am looking for advice on what kind of certificate is needed, and how to do this without requiring a cert from a CA if at all possible.

Thanks!

P

Answer 1

Hello Phil,

Thank you for your question and for reaching out with your question today.

To enable LDAPS (LDAP over SSL) on a new domain controller, you will need to obtain and configure an SSL certificate for LDAPS communication. In an Active Directory environment, LDAPS requires a valid SSL certificate to secure the communication between the client and the domain controller.

Here are the steps to enable LDAPS and obtain an SSL certificate:

1. Install Active Directory Certificate Services (AD CS):

If your coworker has already set up an internal CA on another domain controller, it's likely that AD CS is installed and operational. AD CS is used to issue SSL certificates within your domain, which can be used for LDAPS.

2. Request an LDAPS Certificate:

To obtain an SSL certificate for LDAPS, you need to request a certificate with the following attributes:

• Subject Name: The FQDN (fully qualified domain name) of the domain controller. For example, dc1.example.com.
• Subject Alternative Name (SAN): Add the FQDNs of all domain controllers that will be listening for LDAPS requests. Include both the new RODC and the old 2008 server being replaced.

3. Export and Import the Certificate:

Once the certificate is issued by your internal CA, export it (including the private key) from the CA's certificate store. Import the certificate into the "Personal" certificate store of the new domain controller.

4. Assign the Certificate to LDAPS Service:

Open the "Certificates" snap-in on the new domain controller, locate the imported certificate, and then assign it to the LDAPS service. You can do this by using the "certutil" command in PowerShell or Command Prompt. The command looks like this:

   certutil -dspublish -f "<path_to_LDAPS_certificate_file>" NTDS\Personal

5. Restart Active Directory Domain Services: After assigning the certificate, restart the Active Directory Domain Services (NTDS) service on the domain controller.
6. Configure the System to use LDAPS:

On the system that needs to issue LDAPS queries, ensure the following:

• AD Domain: Specify the domain name (e.g., example.com).
• AD Host Name: Enter the FQDN of the new domain controller that now has the LDAPS certificate.
• Username/Password: Provide the credentials of an account with appropriate permissions in the Active Directory.
• Protocol: Choose LDAPS.
• Port: Set it to 636.

With the proper SSL certificate installed on the new domain controller, it should now respond to LDAPS queries from the system, and the communication will be secured.

Note: It's essential to ensure that the root certificate of the internal CA that issued the LDAPS certificate is trusted on the system from which LDAPS queries are being made. Otherwise, the SSL handshake might fail due to an untrusted certificate chain.

I used AI provided by ChatGPT to formulate part of this response. I have verified that the information is accurate before sharing it with you.

If the reply was helpful, please don’t forget to upvote or accept as answer.

Answer 2

Hi Limitless! It looks like coworker set up a certificate authority on 'DC01'. I can launch 'certsrv' and I see the 'Certification Authority (Local). I'm not sure why they chose DC01. I guess they just randomly chose a DC, which I guess is fine.

The actual server that he wants to 'respond' to the LDAPS queries, we'll call 'RODC' since it is a read only DC.

For step #2, I'm a bit confused (I'm not good at certificates).

I found an article that may or may not go into detail about what you're describing: https://intranetssl.net/how-to-enable-ldap-over-ssl-with-a-private-ca/

Is this a good article to follow, or can you elaborate on how to generate the request, on 'RODC'?

Answer 3

Hi,

Not sure if you have resolved your issue or not, have a look at this post, which provides instructions on how to test that the LDAPS connection is working correctly - https://nettools.net/howto-troubleshoot-ad-ldaps-connection-issues/

Gary.

Answer 4

Hi everyone, thanks so much for your help.

It turns out that the already-installed enterprise CA was working well.

The reason that we could not connect via LDAPS was as follows:

When you launch the certificate MMC on the server and choose a 'SERVICE' of ACTIVE DIRECTORY DOMAIN SERVICES, I saw a certificate there that was wrong. (an old 3rd party CA that was not working).

We removed that and rebooted. Then, LDAPS was working.

My assumption is that AD was attempting to use the incorrect, old 3rd party CA.

I'm not sure how AD chooses which cert to use, but that's apparently important.

Thanks!