About the "Build this from Active Directory information" option for certificate templates

When configuring a certificate template, one must decide on the intended certificate content, i.e., among other things, which identities are confirmed by the certificates and how they are mapped.

In the "Subject Name" tab of the certificate template configuration dialog, you can configure how the identity confirmed by the certificate is mapped.

Here are the following two options:

Supply in the request

The identity is determined by the requester. This option is latently insecure if there is no check of such a certificate request by a certificate manager, since no restriction of the requested identities can be made with on-board means (for this, the TameMyCerts Policy Module an).

Build from Active Directory information

The identity is determined by the certification authority. When the requester submits the certificate request, the associated account in Active Directory is determined based on the requester's credentials and the defined attributes are included in the certificate content.

Depending on the configuration, the following Active Directory attributes of an account are transferred to the issued certificates:

Certificate template optionCertificate attribute/extensionRDN or SAN typeActive Directory Attribute
Common nameSubjectcommonNamecn respectively name
(for user accounts) dNSHostName
(for computer accounts)
Fully distinguished nameSubject commonNamedistinguishedName
NoneSubject {empty}{none}
Include e-mail name in subject nameSubject commonNamemail
E-mail nameSubject Alternative Namerfc822Namemail
DNS NameSubject Alternative Name dNSNamedNSHostName
(only available for computer accounts)
User principal name (UPN)Subject Alternative Name otherName:
(only available for user accounts)
Service principal name (SPN)Subject Alternative Name servicePrincipalNameservicePrincipalName

Microsoft introduced a proprietary certificate extension with the May 2022 cumulative update, which allows the objectSid ("Security Identifier") Active Directory attribute. See article "Changes to Certificate Issuance and Certificate-Based Logon to Active Directory with the May 10, 2022 Patch for Windows Server (KB5014754)„.


Overlaps between attributes lead to misconfiguration

In some companies, the Active Directory attributes "cn", "name" and "samAccountName" are filled with identical values, so that misunderstandings can arise here. For example, when applying for a certificate via Mobile Device Management (MDM), the samAccountName is used for the commonName, or the authentication server in turn maps the content of the commonName attribute to the samAccountName attribute in Active Directory in order to find an account.

Active Directory attribute not present

If an empty Active Directory attribute is to be entered (i.e. a user requests a certificate that requires an attribute that is not populated with a value on their account), the certificate request will fail (the certificate authority will not accept the Event no. 53 log with one of the error codes below).

Error codeMissing Active Directory attribute

Supposedly unnecessary non-existent attribute in the certificate leads to its rejection

RFC 2818 (from 2000) states that the commonName should no longer be used to identify Web sites, and that the Subject Alternative Name in the form of a dNSName should be used instead. This logic will also be applied to related use cases such as LDAP over SSL (in the case of Domain controller certificates) is applied. Therefore, the default certificate templates for domain controllers no longer include commonName.

For compatibility reasons, however, it may make sense to continue to fill the commonName. For example, if a network policy server (NPS) is also installed on a domain controller, which should also use the domain controller certificate, or for legacy applications that do not work according to RFC 2818.

Renaming the user locks him out

Please note that the certificate client integrated in Windows has no way of detecting changes to the user name. If a user account is renamed, e.g. due to marriage, existing user certificates must be deleted so that the autoenrollment process can reapply for them.

Renaming the domain suffix locks out all users

For example, if a company changes its name, the domain suffix and the userPrincipalName attributes of the users may change. If the associated certificate attributes are used to link to the user account, all user certificates must be reissued. The same applies to certificates in which a dNSHostName or a servicePrincipalName is entered.

Special case domain controller

See article "Certificates for domain controllers do not contain the domain name in the Subject Alternative Name (SAN)„.

Related links: