The General Answer
Generally speaking, yes, barring any networking related configurations such as firewall access for the LDAPS protocol (:636) versus the LDAP protocol (:389).
In a standard Active Directory integrated Certificate Authority installation your domain controllers will be issued a certificate based on the Domain Controller certificate template which includes the Server Authentication OID as an Intended Purpose. Any valid certificate containing this OID will automatically get picked up and bound for LDAPS (:636) by the Schannel service.
Removing this certificate, or lacking a proper Server Authentication certificate, will cause Warning events to get logged within the Event Viewer's Security log each second under the Schannel source.
Subject Alternate Name Support
A common caveat is needing proper Subject Alternate Name support for LDAPS certificates. The default Domain Controller certificate template does not include certificate SAN names. If you have domain.com with domain controllers named dc1.domain.com and dc2.domain.com, then LDAPS (:636) calls to domain.com will be returned using the certificate of the responding domain controller (dc1.domain.com or dc2.domain.com). Many applications and protocols will treat this as a security threat and error out.
Enabling SAN Support for LDAPS
- Revoking and removing the standard issued Domain Controller certificate on the domain controllers.
- Ensuring the Domain Controller template's Security is marked to allow the Read permission, but remove the Enroll and/or Autoenroll permissions for Domain Controllers, Enterprise Domain Controllers, and Read Only Domain Controllers.
- Duplicate the Kerberos Authentication template, which contains Server Authentication OID among others.
- Make sure this template allows the key to be exported and that the Subject Name is not built from Active Directory, but is marked to be supplied within the request.
- Ensure that certificate template's Security allows Domain Controllers, Enterprise Domain Controllers, and Read Only Domain Controllers to both Read and Enroll.
- Publish your newly created certificate template.
- Logon to each domain controller, request a new certificate from your template, and set the following as the naming information (example is for dc1.domain.com):
- Common Name: dc1.domain.com
- SANs: dc1.domain.com, dc1, domain.com, and domain.
- Restart each domain controller (not always required, but for good measure) and verify that Event Viewer's Security channel is no longer throwing Warnings about not finding a suitable certificate.
Bonus Information
How Can I Quickly Verify LDAPS Connectivity Internally?
- Logon to a domain controller.
- Launch LDP.exe.
- Open a new connection to a domain controller name, IP address, or the domain name itself.
- The results will let you know if you've connected and to what domain controller's context.
How Can I Quickly See My Current Schannel/LDAPS Certificate?
- Download and/or gain access to OpenSSL.
openssl.exe -s_client domain.com:636
- If the connection opened successfully the beginning portioning of the log will show the connection details.
- Copy the entire
-----BEGIN CERTIFICATE...
through ...END CERTIFICATE-----
section.
- Paste this into Notepad and save it as certificate.cer.
- Open certificate.cer to see the certificate Schannel/LDAPS is presenting.
If I Use LDAPS (:636) Can I Block All LDAP (:389) Traffic?
Yes and no. Yes; you can block LDAP (:389) on all North-South traffic (between internal and external). No; you cannot block LDAP (:389) on East-West traffic (between internal and internal). LDAP (:389) is crucial to certain replication functions in Active Directory. These activities are secured using Kerberos' Signed and Sealed.
Apologies for a lack of precise steps or screenshots. I'm not in an environment from which to supply them at this moment.