Windows Active Directory – Is LDAPS Automatically Enabled with Certificate Services?

active-directoryad-certificate-serviceswindowswindows-server-2012-r2

reading this article: https://www.petri.com/enable-secure-ldap-windows-server-2008-2012-dc

The first method is the easiest: LDAPS is automatically enabled when
you install an Enterprise Root CA on a Domain Controller. If you
install the AD-CS role and specify the type of setup as “Enterprise”
on a DC, all DCs in the forest will be automatically be configured to
accept LDAPS.

Is that true? If I install certificate services on a single DC all DCs in the domain accept LDAPS? Do they all automatically enroll for certificates or are all LDAPS requests directed back to the DC with the root ca installed? What happens if I uninstall the root ca from the DC?

I have to enable ldaps, if I just install a root CA on a DC am I done?

I understand the security implications but for my small environment this would be the preferable path.

Best Answer

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

  1. Revoking and removing the standard issued Domain Controller certificate on the domain controllers.
  2. 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.
  3. 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.
  4. Publish your newly created certificate template.
  5. 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.
  6. 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?

  1. Logon to a domain controller.
  2. Launch LDP.exe.
  3. Open a new connection to a domain controller name, IP address, or the domain name itself.
    • Port: 636
    • SSL: Check
  4. 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?

  1. Download and/or gain access to OpenSSL.
  2. openssl.exe -s_client domain.com:636
  3. If the connection opened successfully the beginning portioning of the log will show the connection details.
  4. Copy the entire -----BEGIN CERTIFICATE... through ...END CERTIFICATE----- section.
  5. Paste this into Notepad and save it as certificate.cer.
  6. 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.

Related Topic