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

Windows Server 2016 End of Life January 2027: Plan Your AD CS Migration Now

Happy New Year, everyone! As the calendar rolls over to 2026, it’s time to start planning the migration of workloads hosted on Windows Server 2016. Mainstream support ended for Windows Server 2016 on January 11, 2022, after which it entered extended support. However, extended support for Windows Server 2016 ends on January 12, 2027, at which point it will be end of life and no longer supported. Running production workloads on Windows Server 2016 beyond this date exposes organizations to significant security risk, as it no longer receives security updates, leaving these systems vulnerable to exploits.

Active Directory Certificate Services

Many organizations are still running critical infrastructure on Windows Server 2016. Administrators often delay upgrading Microsoft Active Directory Certificate Services (AD CS) due to its complexity. However, a well-planned AD CS migration not only reduces risk but also provides an opportunity to modernize cryptography, certificate templates, and operational practices.

Certificate Authorities

Administrators must carefully migrate Certificate Authorities (CAs) running on Windows Server 2016 to minimize downtime. In environments where ongoing CA maintenance has been limited, migrating the CA database can be especially challenging. If the CA is installed on a domain controller, now is a good time to consider separating these services to ensure reliable operation. Also, it’s a good idea to evaluate the CA’s configuration and security posture during migration to enhance security and improve service resilience.

NDES Servers

Microsoft Network Device Enrollment Services (NDES) servers, commonly deployed to facilitate certificate enrollment via Microsoft Intune, pose a unique challenge during migration. Unfortunately, configuring NDES is exceedingly complex and error-prone. NDES relies on a delicate combination of specialized IIS configuration, AD service accounts, custom certificate templates, and CA permissions, making even minor changes risky without proper planning. Not surprisingly, administrators are often hesitant to touch these systems as they are notoriously difficult to troubleshoot when problems arise.

Pro Tip: We spend an entire day covering NDES configuration in the Mastering Enterprise PKI Certificates with Microsoft Intune training course. The next session is March 10-12, 2026. Register now!

Intune Certificate Connectors

Don’t overlook Windows Server 2016 servers with the Intune Certificate Connector installed. Fortunately, this is one of the more manageable workloads to migrate. All that’s required is to install new connectors on supported servers and delete the old ones.

Summary

With extended support for Windows Server 2016 ending on January 12, 2027, organizations running production workloads—especially critical infrastructure such as Active Directory Certificate Services (AD CS), Certificate Authorities (CAs), and NDES servers—face significant security risks from unpatched vulnerabilities once the OS reaches end-of-life. Careful migration planning to newer versions such as Windows Server 2022 or 2025 is essential to minimize downtime, improve security posture, and ensure long-term resilience.

Start Planning Now

Don’t leave these mission-critical infrastructure services to the last minute! Begin planning your migration today. If you’d like expert guidance, I have many years of experience migrating these workloads. I have developed specialized tools and techniques to ensure a smooth, secure, and successful transition. Fill out the form below to schedule a free one-hour consultation to assess your Windows Server 2016 AD CS workloads, identify migration risks, and outline next steps.

Additional Information

Windows Server 2016 Lifecycle Policy

PKI Fundamentals with Microsoft Active Directory Certificate Services (AD CS) Online Training Course

Mastering Enterprise PKI Certificates with Microsoft Intune Online Training Course

Resolving PKCS Certificate Mapping Issues in Windows Autopilot Hybrid Join Deployments

Microsoft Windows Autopilot streamlines device provisioning through Intune, allowing IT administrators to preconfigure new Windows devices with minimal hands-on effort. However, when combined with Hybrid Entra Join and PKCS certificate deployment, specific challenges arise—particularly with certificate mapping and authentication.

Hybrid Entra Join

During autopilot provisioning, administrators may also choose to join the device to their on-premises Active Directory domain, a deployment model called Hybrid Entra join. Hybrid Entra join presents some unique challenges when using Autopilot to remotely provision devices. Specifically, the user must have connectivity to a domain controller to perform the first logon, as they do not have a user profile on the endpoint.

Device Tunnel

To support offline Hybrid Entra join during Autopilot provisioning, administrators can deploy the Always On VPN device tunnel to provide pre-logon connectivity to domain controllers. A device tunnel connection enables users to log on to their newly provisioned device remotely.

Requirements

The following prerequisites must be met to support the Always On VPN device tunnel.

  • The endpoint must be running Windows Enterprise edition.
  • An Always On VPN device tunnel profile must be assigned to the device.
  • A machine certificate must be deployed to the endpoint that includes the Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2).

Note: If you plan to use the subscription step-up upgrade from Windows Professional to Windows Enterprise, the device tunnel will not connect automatically after provisioning is complete, which prevents the user from logging in. More details and a workaround for this issue can be found here.

Strong Certificate Mapping

Microsoft knowledge base article KB5014754, released in May of 2022, introduced changes to domain controllers to require strong certificate mapping when using certificates to authenticate to Active Directory (AD). It was initially deployed in compatibility mode, only warning administrators when certificates are used for authentication that aren’t strongly mapped. However, full enforcement is mandatory beginning with the September 2025 security updates. This requirement introduces some challenges when issuing certificates to the device using PKCS during Autopilot provisioning.

Intune PKCS Certificates

When using PKCS certificates and the Intune Certificate Connector, the endpoint’s on-premises AD security identifier (SID) is not added to the issued certificate during Autopilot. Interestingly, this does not happen when using SCEP certificates. If the device certificate is not strongly mapped, the Always On VPN device tunnel will still authenticate successfully because Always On VPN does not use AD to authenticate device connections. Instead, Always On VPN simply verifies the certificate (e.g., that it is not expired or revoked) and allows authentication if the certificate passes the validation.

However, enterprise Wi-Fi access may fail without strongly mapped certificates if device authentication is required. Also, there may be other scenarios where a device authentication certificate without strong mapping may cause authentication to fail.

Workarounds

There are a few ways to work around this limitation. Consider the following options.

Native Entra ID Join

The simplest way to avoid the challenges of PKCS certificates and Hybrid Entra join is to avoid it altogether in favor of native Entra join. However, this may not be an option for everyone.

Use SCEP

For some reason, certificates issued with SCEP do not suffer from this limitation. In my testing, SCEP certificates are always strongly mapped. However, deploying SCEP certificates is much more complex than using PKCS. (Pro tip: Cloud PKI for Intune uses SCEP and requires no configuration! It’s definitely something to consider.)

Short-Lived Certificates

Another option is to deploy temporary, short-lived certificates (valid for only a few days) using PKCS to ensure the Always On VPN device tunnel works, and then deploy a permanent, long-term certificate post-deployment that includes the strong mapping. To do this, administrators can leverage dynamic group assignments in Intune. For example, the administrator can assign the short-lived certificate to an Autopilot Provisioning devices group and later assign a long-term certificate to the Hybrid Joined devices group.

Here’s an example of the dynamic group membership configuration.

Autopilot Provisioning Devices:

(device.devicePhysicalIDs -any (_ -contains “[ZTDId]”)) -and (device.deviceTrustType -ne “ServerAD”)

Hybrid Entra Join Devices:

(device.deviceTrustType -eq “ServerAD”)

In this configuration, the initial PKCS certificate is deployed without the strong mapping when the endpoint is enrolled to Autopilot but has not yet joined the domain. During this time, the endpoint will only be a member of the Autopilot Provisioning Devices group and will receive the short-lived, temporary certificate. Later, once the endpoint has successfully joined the domain, the device will move from the provisioning group to the Hybrid Entra Join Devices group. When this happens, a permanent, strongly mapped long-term certificate is enrolled on the device.

Manual Certificate Mapping

Certificates can be manually mapped via the altSecurityIdentities property of the computer object in AD. Obviously, this doesn’t scale well, so my good friend Steve Prentice published a PowerShell script to automate this process. You can find more details and the script here.

Summary

Windows Autopilot streamlines device provisioning with Intune, but Hybrid Entra Join introduces challenges when PKCS certificates lack strong mapping during initial deployment, potentially disrupting VPN and Wi-Fi authentication. Administrators can avoid this by switching to native Entra join or by using workarounds such as switching to SCEP, using short-lived certificates, or manually mapping certificates.

Additional Information

KB5014754 – Certificate-based authentication changes on Windows domain controllers

How To: Map a user to a certificate via all methods available in the altSecurityIdentities attribute

Hybrid Autopilot: Automating altSecurityIdentities

Configure Microsoft Entra hybrid join

Overview: Cloud PKI for Microsoft Intune