Orphan Templates: A Hidden Surprise

Active Directory Certificate Services (AD CS) is commonly used to issue certificates for users, computers, VPN clients, Wi-Fi authentication, smart cards, and internal applications. Because certificate-based authentication is deeply integrated with Active Directory, PKI configuration must remain accurate and consistent.

This is not always the case.

A CA can continue to publish a certificate-template reference even when the corresponding template object no longer exists in Active Directory.

The result is an orphaned AD CS certificate-template reference: the CA claims to publish a template that cannot be resolved in the directory.

By itself, an orphaned publication reference does not grant an attacker certificate-enrollment or domain-compromise capability. However, it can become security-relevant if an attacker has delegated rights to recreate or control the missing template and its supporting PKI objects. In that case, they may be able to introduce a malicious template configuration that the CA already publishes.

This article explains why that happens, what risks it creates, and how the NetExec module detects it. AnBapDan/nxc-adcs-orphans

The problem

For a Certificate template to successfully exist, it relies on two separate pieces of configuration:

1. The certificate-template object stored in Active Directory.
2. The CA’s list of published templates.

Certificate templates are stored in Active Directory under the Configuration partition:

CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com

Enterprise CAs have their own objects under the Enrollment Services container. Their certificateTemplates attribute contains the names of the certificate templates they publish. These values normally correspond to the template objects’ cn attribute, not necessarily their displayName.

Publishing a template updates the CA’s publication list. However, it does not move the template into the CA. Consequently, the two sides can become inconsistent.

For example, the CA may contain:

certificateTemplates:
    UserAuthentication
    MachineAuthentication
    LegacySmartcard

while Active Directory contains only:

UserAuthentication
MachineAuthentication

LegacySmartcard is an orphaned reference.

The CA still advertises the template name, but Active Directory no longer provides the corresponding template object and its configuration for directory-based lookup and management.

An orphaned publication reference exists when a CA continues to publish a template name, but the corresponding template object no longer exists or cannot be found.

This is usually caused by configuration drift, but it can reveal serious weaknesses in how an organization manages its PKI.

Root Causes

The most common cause is incomplete administrative cleanup: a template object is deleted from Active Directory before it is unpublished from each Enterprise CA that references it. Inconsistent CA migration, recovery, decommissioning, or Configuration-partition cleanup can produce the same mismatch.

Replication issues can also create an apparent orphan. Because certificate-template objects reside in the forest-wide Configuration naming context, results can vary temporarily when querying different domain controllers during replication failures or delays. Automation that only partially completes a publication, migration, or cleanup workflow can create similar inconsistencies.

An attacker with sufficient delegated rights over AD CS-related objects could intentionally create this state or exploit the same weak permissions to introduce a replacement template. The orphaned reference alone is not evidence of compromise, but unexplained PKI changes warrant investigation.

NetExec ADCS Orphans module

To detect this AD CS misalignment, I created a NetExec module available at AnBapDan/nxc-adcs-orphans

The module performs three main checks:

1. Queries CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com for certificateTemplates values published by Enterprise CA objects.
2. Queries CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com for existing pKICertificateTemplate objects.
3. Compares both lists and reports templates that are published but missing from the template container.

For a basic enumeration:

nxc ldap <DC_IP> -u <USERNAME> -p '<PASSWORD>' -M adcs_orphans

A useful result might look like this:

Orphaned published templates:
    OldCertificateTemplate

The result should be treated as a configuration anomaly requiring validation, not automatically as an exploitable AD CS vulnerability.

The module can also generate LDIF files by using the GENERATE_FILES option:

nxc ldap <DC_IP> -u <USERNAME> -p '<PASSWORD>' -M adcs_orphans -o GENERATE_FILES=TRUE

The module uses the detected orphaned template names to generate a set of LDIF files.

When GENERATE_FILES=TRUE is used, the module generates LDIF files intended to help reproduce the missing PKI objects for authorized testing or controlled recovery. Recreating a template requires appropriate permissions in the Configuration partition and may require creating both a certificate-template object and a corresponding enterprise OID object.

Creating an object does not inherently grant the creator Full Control over it. Effective permissions depend on the container ACL, inherited permissions, ownership behavior, and any explicit ACEs applied to the new object.

In a security assessment, the ability of a low-privileged or delegated identity to create and configure these objects can indicate a serious AD CS permission issue.

From NetExec, the desired output should resemble:

Orphaned published templates:
    OldCertificateTemplate

Base enterprise OID: 1.3.6.1.4.1.311.21.8.1234567

LDIF written to oid_ldif_OldCertificateTemplate.ldif
LDIF written to template_ldif_OldCertificateTemplate.ldif

To Check for ACLs that allow for OID creation, use:
impacket-dacledit -target-dn 'CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com' 'example.com/user' -dc-ip 10.10.10.10

To Check for ACLs that allow for Template creation, use:
impacket-dacledit -target-dn 'CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com' 'example.com/user' -dc-ip 10.10.10.10

Validation matters

Before making changes, query multiple domain controllers that host replicas of the Configuration naming context and confirm that the template is absent from each of them.

There are three important outcomes:

• Confirmed orphan: the publication reference exists, but no matching template exists on the relevant domain controllers.
• Replication discrepancy: the template exists on some DCs but not others.
• Query failure: the object could not be retrieved because of an LDAP, permissions, or connectivity problem.

These conditions should not be conflated. Reporting a replication failure as a deleted template can lead to unnecessary and potentially harmful PKI changes.

The investigation should also establish whether the CA is active, whether the template was historically used, whether certificate enrollment is failing, and whether directory auditing shows an unauthorized deletion or modification.

Mitigation

The correct lifecycle for retiring a template is to unpublish it from every CA first, verify that no applications or devices depend on it, and only then delete or retain the template according to organizational policy.

Just remember:

Unpublish first. Delete later.

Organizations should also monitor changes to certificate-template objects, template security descriptors, CA certificateTemplates attributes, and Enrollment Services objects. Access to these objects should be restricted to approved PKI and directory administrators, with changes logged and reviewed.

After a CA migration, restoration, or decommissioning, administrators should verify that the CA publication list matches the available templates and test certificate enrollment and renewal. These checks should be performed against multiple domain controllers, especially in environments with complex sites or a history of replication issues.

Conclusion

An orphaned AD CS template reference is usually caused by configuration drift or incomplete PKI maintenance. Replication failures can create an apparent orphan and must be ruled out before treating the condition as persistent.

The NetExec module provides a simple way to identify this mismatch by comparing CA publication metadata with the certificate-template objects actually present in Active Directory. Used alongside replication checks, permission reviews, and directory auditing, it helps defenders find PKI inconsistencies before they become outages or conceal more serious AD CS security issues.