The Myth of the Publish Certificate in Active Directory Setting

Certificate templates in Microsoft Active Directory Certificate Services (AD CS) provide powerful, preconfigured settings that enable administrators to issue certificates tailored for specific purposes. For example, a certificate template could allow a user to authenticate to a Wi-Fi network or VPN gateway. Another template might control policies for enrolling for web server certificates in the enterprise. Templates define settings such as cryptographic parameters (key algorithm and length), validity period, application policies, enrollment requirements, and more. While there are myriad settings to choose from, one in particular is often enabled unnecessarily. And while it works without issue, there can be some hidden downsides to enabling this setting.

Publish Certificate in Active Directory

When creating a certificate template, there’s an option on the General tab called Publish certificate in Active Directory. From experience, this is one of the most misunderstood settings for certificate templates.

Intuitively, it would make sense to check this box on all published certificate templates. After all, I want the users or devices targeted by this certificate template to find them in Active Directory (AD) so they can enroll. Many administrators believe that enabling this setting is required to ‘see’ the published certificate template on the endpoint, as shown here.

However, enabling the Publish certificate in Active Directory option is not required for enrollment. To ‘see’ certificates available for enrollment, the user or device must only have the Enroll permission on the template.

What Is It For?

So, what does the Publish certificate in Active Directory setting do? When this option is enabled, the issuing CA adds the certificate to the requesting principal’s Active Directory account. There are two common scenarios where this is required.

S/MIME

Adding a user’s certificate to their AD account makes the public key centrally discoverable, allowing Outlook and other S/MIME-enabled clients to automatically find recipients’ certificates for secure email encryption and signature validation. Without the certificate published in AD, users must manually exchange certificates, breaking seamless S/MIME encryption in most enterprise environments.

Encrypting File System (EFS)

Publishing a user’s EFS certificate to their Active Directory account allows Windows to locate the correct public key automatically when encrypting files. It ensures recovery agents and key archival processes function properly. Without the certificate in AD, EFS can fail to encrypt data consistently across machines or prevent access to encrypted files when users roam or recover profiles.

Drawbacks

There are very few scenarios outside of S/MIME and EFS that require the Publish certificate in Active Directory option to be enabled. However, enabling it doesn’t necessarily break anything, and this setting is often enabled by default (or carried over from the source template when duplicating), so administrators may miss this option. Issuing certificates in this way introduces some potential problems.

AD Database Bloat

Adding a certificate to each principal’s AD object increases the size of each object, thereby increasing the total size of the AD database. For organizations with large directories with hundreds of thousands or even millions of accounts, adding unnecessary data to each account can be very expensive in terms of database size, replication traffic, backup storage, and overall domain performance. Making matters worse, certificates published to AD live perpetually. They are not removed automatically when certificates are revoked or expire.

Service Accounts

Service accounts used for certificate enrollment, such as the Microsoft Intune Certificate connector, can be especially challenging. Here, if the Publish certificate in Active Directory setting is enabled on the Intune certificate template, the CA will add a certificate to the service account for every certificate it issues. While you can have many certificates associated with a single account, there is an upper limit, approximately 1250, based on my testing. After that, certificates will continue to be issued, but adding them to AD will fail.

Remediation

The following recommendations can help administrators correct this misconfiguration and limit its impact in their environment.

Disable Unnecessary Certificate Publishing

Administrators should clear the Publish certificate in Active Directory setting on all certificate templates that do not explicitly require it, such as those used for S/MIME or Encrypting File System (EFS). This prevents new certificates from being written to user or computer objects and does not require certificates to be reissued.

Remove Published Certificates

Administrators can remove unnecessary certificates from user, computer, and service account objects in AD to reduce object and overall AD database sizes. Perform the following steps to remove unneeded certificates.

  1. Open the Active Directory Users and Computers management console (dsa.msc) and double-click the target principal.
  2. Select the Published Certificates tab.
  3. Select a certificate (or all certificates) and click Remove.

Important Note: Use extreme caution when deleting certificates! Do not delete any certificates unless you are certain they are not required.

Managed Service Accounts

Managed Service Accounts in AD do not have a Published Certificates tab. Administrators can use the Attribute Editor to remove individual certificates from the userCertificate attribute on the account.

Managed Service Account Attribute Editor

Managed Service Account userCertificate Entries

Unfortunately, there is no option to view the certificate in the UI for Managed Service Accounts. To view detailed certificate information, see the PowerShell section below.

Existing Certificates Are Not Removed Automatically

Disabling the Publish certificate in Active Directory setting only stops future certificates from being published in AD. Certificates already written to Active Directory are never removed automatically, even after they expire or are revoked. In environments where this setting has been enabled for an extended period, large numbers of stale certificates often accumulate and continue to increase the AD database size.

Intune Certificate Connector Considerations

This issue is especially problematic for high-volume enrollment scenarios that use service accounts, such as the Microsoft Intune Certificate Connector. When publishing is enabled for Intune certificate templates, certificates issued on behalf of users are added to the service account, quickly leading to excessive certificate accumulation and potential attribute limits.

ADPrincipalCertificate PowerShell Module

Manually performing this cleanup at scale is impractical. To assist administrators with cleaning up unnecessarily published certificates, I’ve created the ADPrincipalCertificate PowerShell module. This module includes functions to enumerate AD accounts that include certificates, show and optionally export certificates for AD accounts, and remove published certificates. The module also includes a function to enumerate published certificate templates that include the Publish certificate in Active Directory option enabled. You can install the ADPrincipalCertificate PowerShell module from the PowerShell gallery by running the following command.

Install-Module -Name ADPrincipalCertificate -Scope CurrentUser

See the ADPrincipalCertificate GitHub repository for detailed usage information.

Summary

While the Publish certificate in Active Directory option is helpful for S/MIME and EFS deployments, it is unnecessary for most other scenarios and is often enabled when it isn’t needed. This results in the unnecessary addition of certificates to AD accounts, causing individual objects and the entire AD database to grow without benefit. Sadly, many vendor guides indicate that this setting is required when it often isn’t, so many environments suffer from this misconfiguration. Administrators should review the certificate template configuration and disable this setting when it isn’t needed. Additionally, use the ADPrincipalCertificate PowerShell module to perform cleanup, if required.

Additional Information

ADPrincipalCertificate PowerShell Module on GitHub

ADPrincipalCertificate PowerShell Module in the PowerShell Gallery

Always On VPN Intermittent 13801 Error

Always On VPN error 13801 is common when establishing an IKEv2 VPN connection. Typically, the issue is related to a configuration error or a problem with certificate deployment. However, administrators may encounter the 13801, an IKE authentication error, intermittently. Configuration errors are binary. If there is a misconfiguration, IKEv2 never works at all. However, a configuration error seems unlikely since the connection works occasionally yet fails at other times.

Client Authentication

The minimum application policy (Enhanced Key Usage, or EKU) requirement for the device authentication certificate for IKEv2 is Client Authentication (1.3.6.1.5.5.7.3.2). When intermittent 13801 errors occur, administrators may find multiple certificates in the local computer certificate store with the Client Authentication EKU issued by different certificate authorities. Commonly, Intune-managed Windows devices may include several certificates with Client Authentication.

Certificate Selection

When Windows attempts to establish an Always On VPN IKEv2 connection, and there are multiple certificates in the local computer certificate with Client Authentication defined, Windows must choose one certificate to use for the connection. If Windows chooses incorrectly, you will receive the 13801 IKE authentication failure error. If Windows selects the right one, the connection succeeds.

Resolution

There are several ways to resolve this issue. The best way is to update the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). When Windows encounters multiple client authentication certificates in the local computer certificate store, it will prefer any certificate with the IP security IKE intermediate application policy for IKEv2 VPN connections. Including the IP security IKE intermediate application policy on the Always On VPN device authentication certificate ensures proper certificate selection when multiple client authentication certificates are present.

Note: This change must be made to the Intune certificate enrollment template when using Intune with PKCS or SCEP.

Certificate Template

To update an existing Always On VPN device authentication certificate to include the IP security IKE intermediate application policy, open the certificate templates management console (certtmpl.msc) and perform the following steps.

  1. Right-click the VPN device authentication certificate template and choose Properties.
  2. Select the Extensions tab.
  3. Click on Application Policies.
  4. Click Edit.
  5. Click Add.
  6. Select the IP security IKE intermediate application policy.
  7. Click Ok.
  8. Click Ok.
  9. Click Ok.

Once complete, any certificates issued after this change is applied will now include the IP security Ike intermediate application policy.

Force Renewal

Administrators may wish to update all certificates immediately rather than wait until they renew to receive the new setting. The course of action depends on how certificates are issued.

On-Premises

When issuing certificates using Active Directory Certificate Services (AD CS) on-premises, right-click the Always On VPN device authentication certificate template and choose Reenroll All Certificate Holders. This will force all domain-joined clients with Autoenroll permissions on the template to renew their certificate on their next enrollment cycle, regardless of the certificate’s lifetime.

Intune

Follow the steps below to force re-enrollment for all certificate holders when deploying certificates using Intune.

SCEP Add the IP Security IKE Intermediate application policy to the Intune VPN policy. After this change is applied, Intune will reenroll all endpoints.

PKCS – A new Intune device configuration policy must be created that includes the IP security IKE intermediate application policy. Assign the new policy and remove the old one to replace all certificates.

PowerShell

It’s also possible to resolve this issue using PowerShell. Administrators can use the Set-VpnConnection PowerShell cmdlet to select a certificate based on the root certification authority (CA) or a specific custom application policy defined on the Always On VPN device authentication certificate. Be sure to add the -AllUserConnection switch when working with the device tunnel.

Root CA

Open a PowerShell command window and run the following command.

$RootCA = Get-Child-Item -Path Cert:\LocalMachine\My\<thumbprint of root CA certificate>
Set-VpnConnection -Name <name of VPN profile> -MachineCertificateIssuerFilter $RootCA

Application Policy

Open a PowerShell command window and run the following command.

Set-VpnConnection -Name <name of VPN profile> -MachineCertificateEKUFilter <OID>

Note: When using a custom application policy Windows will return a warning message stating the EKU could not be validated. You can safely disregard this warning.

Intune Remediation

While running PowerShell commands locally might be helpful for troubleshooting and targeted evaluation testing, deploying settings via PowerShell at scale is challenging. For those organizations managing their devices using Microsoft Intune, I’ve published a few detection and remediation scripts on GitHub to perform these tasks.

Summary

The intermittent Always On VPN 13801 IKE authentication credentials are unacceptable error message is best resolved by updating the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). Although using PowerShell also works, it doesn’t scale effectively. SCCM or Intune remediations can help, but I’d encourage you to update the certificate template as best practice instead.

Additional Information

Troubleshooting Always On VPN Error 13801

Troubleshooting Always On VPN Error 13806

Troubleshooting Always On VPN Error 13868

November Microsoft Security Updates and AD CS

As I do each month on Patch Tuesday, I look through the list of published vulnerabilities in search of things that might interest Always On VPN Administrators. Frequently there are updates for things like Routing and Remote Access Service (RRAS) or various VPN protocols. The good news is that the November 2024 security updates include NO such vulnerabilities! However, a vulnerability has been disclosed that affects Active Directory Certificate Services (AD CS) on which Always On VPN often relies on for user and device authentication.

Certificate Templates

AD CS Enterprise certificate authorities are closely integrated with Active Directory and use certificate templates that administrators can publish for users and devices to enroll. These templates control properties of the issued certificates, such as the subject name, usage, key length, enrollment policies, and much more. There are several different template versions available, versions 1 through 4. Version 1 templates are legacy templates that don’t provide many capabilities. Later versions include more features and capabilities.

CVE-2024-49019

The November 2024 Microsoft security updates include CVE-2024-49019, a privilege escalation vulnerability recently discovered in AD CS. Specifically, this vulnerability affects only legacy schema version 1 certificate templates published on a certificate authority (CA) server that include the option to supply the subject name in the certificate request. A typical example of this would be the default Web Server template.

Exploitation

The Web Server template does not include the Client Authentication Enhanced Key Usage (EKU) by default, which is required to authenticate to Active Directory. However, this vulnerability allows an attacker with enrollment privileges on this template to supply additional EKUs in the request and the certificate issued will include those capabilities. This allows a non-privileged attacker to quickly elevate to a domain or enterprise administrator by supplying a known administrator’s User Principal Name (UPN) along with the Client Authentication EKU in the certificate request. As version 1 templates cannot enforce CA manager approval for enrollment, an attacker can easily leverage this vulnerability if permissions allow, leading to complete domain compromise.

Note: This applies to any schema version 1 certificate template published with the subject name supplied in the request, not just the Web Server template.

Complications

Making matters worse, the Web Server template is one of the default certificate templates published automatically when a Windows Server CA is deployed. The best practice is to disable the publishing of any certificate templates by default when a new CA is provisioned. However, it requires additional configuration that is often overlooked. In addition, many administrators use overly broad enrollment permissions for this template, such as Domain Users, Domain Computers, or Authenticated Users, further broadening the attack surface.

Mitigation

Administrators should update their CA servers as soon as possible. If you cannot deploy this update immediately, consider replacing any schema version 1 templates with version 2 templates, which are not vulnerable. Also, as best practice, ensure that any certificate templates that allow the subject name to be supplied in the request also requires CA manager approval or additional authorized signatures for enrollment.

Investigation

Administrators should review enrollment privileges for all published certificate templates to ensure the least privileged access. In addition, administrators should audit all valid certificates issued with schema version 1 certificate templates that allow the subject name to be supplied in the request immediately to look for indicators of compromise. Review issued certificates for unauthorized EKUs or unusual subject names, especially those with a UPN.

Additional Information

Microsoft November 2024 Security Updates

CVE-2024-49019 – AD CS Elevation of Privilege Vulnerability

EKUwu: Not Just Another AD CS ESC – TrustedSec