Securing Active Directory Certificate Services (AD CS): Configuration and Management Tips

Active Directory Certificate Services Configuration Tips

Whenever an identity obtains an authentication-based certificate, it allows them to authenticate themselves as the entity specified in the Subject Alternative Name (SAN), typically identified by a UPN or DNS name. This certificate is used instead of a password for initial authentication and remains valid until expiry or revocation. Consequently, security strategies that seek to thwart malicious actors by resetting a password would be fruitless, as an attacker who holds an authentication-based certificate would still have persistent access to the account unless the certificate was also revoked.

Below are some of the most common certificate template settings that can lead to AD CS misconfigurations.

Authentication Based EKUs

It is crucial to identify the Enhanced Key Usages (EKUs) that support domain-level authentication. Examples of EKUs that provide this feature include:

• Any Purpose (2.5.29.37.0)
• SubCA (None)
• Client Authentication (1.3.6.1.5.5.7.3.2)
• PKINIT Client Authentication (1.3.6.1.5.2.3.4)
• Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

One way to locate the certificate templates that enable this feature is by accessing the Certificate Authority MMC Snap-in, connecting to the Certificate Authority, and scanning the Intended Purpose Column for any of these authentication EKUs. Bear in mind that normal certificates can still be misused. For instance, PoshADCS’s Get-SmartCardCertificate capability can manipulate a template, request certificates for it, and then restore the template to its original state.

“Enrollee Supplies Subject” Flag

If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is found in the mspki-certificate-name-flag attribute, the certificate enrollee can provide an alternate Subject Name when requesting the certificate. This means that any authorized user can request a certificate on behalf of any other user in the network, even if they are a privileged user. To verify this flag, you can check the Certificate Template console and select the “Supply in the request” radio option under the Subject Name tab. Alternatively, you can use a PowerShell command to retrieve templates from AD and check if the flag is set for the certificate. To manage certificate issuance, consider using the recommended options in addition to fixing any misconfigurations.

CA Certificate Manager Approval or Authorized Signatures

It is important to check the Issuance Requirements tab of each certificate to determine whether it necessitates authorization from the Certificate Authority (CA) manager. Implementing one or both of these configurations can significantly lower the likelihood of risks by mandating verification before certificate issuance. Even if you are unsure about the need for approved signatures, it is advisable to mandate approval from the CA certificate manager. This will ensure that whenever a certificate is requested, it undergoes a manual review by the Certificate Authority prior to being issued.

Enrollment Permissions

Examine the enrollment permissions included in each template, which are located on the Security tab. Misconfigurations can be highly problematic if they allow large groups (with generic principals) to use these permissions. It’s essential to check for groups such as Authenticated Users, Domain Users, or any large group of users that shouldn’t have the capability to request certificates. If such groups are identified, it’s recommended to revoke their Enroll or AutoEnroll permissions.

EDITF_ATTRIBUTESUBJECTALTNAME2 Registry Key

Examine the registry entry EDITF_ATTRIBUTESUBJECALTNAME2. This particular setting is noteworthy in that, when activated on the CA, it allows for personalized user-defined data to be added to the SAN of any authenticated certificate that is issued (even certificates with subjects that are automatically generated from Active Directory).

Checking for Risky Settings using PSPKIAudit

To audit your PKI infrastructure, use the PSPKIAudit tool. You can obtain the tool from GitHub and import the module to use. Execute the Invoke-PKIAudit command to enumerate the Active Directory Certificate Authority, followed by querying for the default options.

Conclusion

It is highly likely that we will see an increase in the number of attacks on Active Directory Certificate Services. Consequently, it is crucial to immediately and periodically examine your settings for any misconfigurations and rectify them without delay. Additionally, by following the best practices of certificate management, such as maintaining an efficient PKI hierarchy, implementing secure authentication protocols and monitoring the environment for threats, you can mitigate potential security risks and prevent unauthorized access to your systems.

If you’d like to see how the Lepide Data Security Platform can help you monitor AD CS configuration changes to prevent damaging security breaches, schedule a demo with one of our engineers.