Security of an Active Directory (AD) infrastructure can be significantly increased by deploying Active Directory Certificate Services (AD CS) and installing certificates on domain controllers (DC). AD CS plays a foundational role for enabling certificate-based security across a range of services in AD. Some notable security enhancements are as follows:
- Securing AD communication between domain joined machines.
- Allow for securing LDAP traffic, which by default is not encrypted. This means that credentials can be sent in clear text over the network, allowing bad actors to intercept authentication traffic to impersonate a legitimate user or initiate a man-in-the-middle attack. Enabling LDAP signing is one of the most significant security enhancements an organization should implement as part of securing an AD infrastructure.
This blog focuses on how certificates are maintained on DCs when AD CS is deployed. This is the first step to using certificate services to secure AD and, for example, take the steps necessary to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not request signing, or to reject LDAP simple binds that are performed in clear text (non-SSL/TLS-encrypted) connections.
DCs are hard-coded to auto-enroll for certificates when a Microsoft enterprise (AD integrated) certificate authority (CA) is introduced into the forest. A default deployment of AD CS provides four templates that DCs can use to request a certificate:
- Domain Controller. This is the original certificate used by the early versions of AD to secure domain traffic. A DC template is used if a default deployment is performed for an enterprise CA.
- Domain Controller Authentication. Superseded the Domain Controller template.
- Directory Email Replication. This is an obsolete template that was initially used by DCs that replicated via SMTP rather than the more common RPC.
- Kerberos. This template is the most recent version that is used for securing AD traffic, which offers the most extensions to support all modern authentication methods. This is backwards compatible and should be used going forward.
With this, all DCs will auto-enroll for certificates when an enterprise CA is initially deployed (using default settings). With certificates, AD will leverage them to further secure domain traffic. More specifically, the DCs will enable SSL/TLS for both LDAPS (Port 636) and the global catalog server over port 3269. In general, this is a positive thing. However, there are some important considerations that should be addressed as the default settings Microsoft has deployed may not be appropriate for all AD forests.
As mentioned, DCs are hard coded to enroll for certificates when an enterprise CA is available. A default deployment results in all DCs in the forest auto-enrolling for a certificate based on the original Domain Controller template. The certificate will be automatically renewed once it expires. The certificate will also be placed into the computer’s personal certificate store (also known as the computer’s MY certificate store). Microsoft recommends that only a single certificate for the purpose of server authentication exist in this store. This basic configuration ensures that AD security is enhanced and provides an automated approach for doing so. However, if configuration changes are made, the default behavior changes, and it is important to understand what those are. The two most common ones are somewhat related.
Organizations want to leverage auto-enrollment on certificates that are used for other purposes than domain controllers such as users, machines, web servers, etc. This is done via group policy and can be applied to user and computer objects. The settings are as follows: Computer / User Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificates Services Client – Auto-Enrollment policy. Set this to enabled and select both checkboxes: Renew expired certificates, update pending certificates, and remove revoked certificates; and Update certificates that use certificate templates.
If the computer setting is applied to domain controllers, the behavior of the hard coded auto enrollment changes. Now, instead of using the Domain Controller template, each DC can use any template that is available for DC purposes. If multiple templates are available, the DC will end up with multiple certificates, which is a scenario that Microsoft advices against. This is a problem because when a DC is first starting, it will look in this store for a suitable certificate to bind to Active Directory. If multiple certificates are available, the intended cert that the server binds to AD may not be the one that is most preferred.
Alternatively, the certificate can be placed in the Service account / Active Directory Domain Services > NTDS\Personal store. Putting the certificate in this store has two primary benefits:
- AD preferentially looks for certificates in this store over the local machine's This makes it easier to configure AD to use the desired certificate if there is a requirement to maintain multiple certificates on a server.
- Active Directory detects when a new certificate is placed into its certificate store and then triggers an SSL certificate update without having to restart AD DS or restart the domain controller.
The downside to placing certificates in the AD services store is that certificates need to be manually placed into this store and auto-enrollment is not available for certificates that reside in this store. As such, maintaining certificates becomes a manual process if this store is used.
The case for using this store is if there is a legitimate need to have multiple certs for server authentication on a given DC. Unless this need exists, it is best to leave the certificate in the personal store.
The other common change is that organizations want to use the Kerberos template or a customized version of the Kerberos template to support modern authentication methods and secure LDAP traffic. This requires removing the three older templates or manually installing certificates on the domain controllers. Either way, this breaks the default behavior mentioned above, and requires an organization to properly plan for how certificates will be managed on domain controllers.
So, what is a common-sense path for deploying an enterprise CA? There are several recommendations that should be performed when deploying an enterprise CA. These recommendations will ensure that DCs can auto enroll and auto update certificates that expire:
- Remove the three older templates (Domain Controller, Domain controller Authentication, and Directory Email Replication) from each issuing certificate authority server. Alternatively, remove these templates from Active Directory so they are no longer available at all to an enterprise CA.
To remove templates from a server open the Certificate Authority Admin Console > Expand the Certificate Authority name > click on Certificate Templates. Highlight the certificate template(s) to delete and press the Del key. Removing a certificate template from the CA means it is not available for the CA to issue a certificate based on that template. The template itself is stored in Active Directory and could be re-added to the CA if needed.
- Make sure only the Kerberos template (or a customized template) remains available for DC certificate enrollment. There should not be more than certificate template that allows for domain controller auto enrollment. If a customized template is created, make sure to set the security settings to allow Domain Controllers to auto enroll if there is a desire for DCs to automatically maintain certificates.
- Enable certificate auto-enrollment via GPO. At a minimum place this in the Default Domain Controllers GPO. Based on the needs of the organization, it may make sense to enable this at on a broader scale.
- Enable advanced logging for auto-enrollment of certificates by adding the following registry key:
- HKLM/Software/Microsoft/Cryptology/Autoenrollment: DWORD > AEEventLogLevel = 0
- Additional detail for certificate enrollment is shown in the Application log.
If the domain controllers have already pulled certificates based on the older templates, simply open the certificate store, delete the certificate(s), and reboot. The DCs will request a new certificate on startup and use the template that was configured. Should this process fail manually requesting a certificate can be performed.