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 option | Certificate attribute/extension | RDN or SAN type | Active Directory Attribute |
|---|---|---|---|
| Common name | Subject | commonName | cn respectively name (for user accounts) dNSHostName (for computer accounts) |
| Fully distinguished name | Subject | commonName | distinguishedName |
| None | Subject | {empty} | {none} |
| Include e-mail name in subject name | Subject | commonName | |
| E-mail name | Subject Alternative Name | rfc822Name | |
| DNS Name | Subject Alternative Name | dNSName | dNSHostName (only available for computer accounts) |
| User principal name (UPN) | Subject Alternative Name | otherName: userPrincipalName | userPrincipalName (only available for user accounts) |
| Service principal name (SPN) | Subject Alternative Name | servicePrincipalName | servicePrincipalName |
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)„.
Interactions
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 code | Missing Active Directory attribute |
|---|---|
| CERTSRV_E_SUBJECT_DNS_REQUIRED | dNSHostName |
| CERTSRV_E_SUBJECT_EMAIL_REQUIRED | |
| CERTSRV_E_SUBJECT_UPN_REQUIRED | userPrincipalName |
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:
- Use of undefined Relative Distinguished Names (RDN) in issued certificates
- Change the order of the Relative Distinguished Names (RDNs) in the subject of issued certificates.
- Allowed Relative Distinguished Names (RDNs) in the Subject of Issued Certificates
- Basics: Name Constraints
- Configuring a Certificate Template for Domain Controllers
English 
Deutsch
4 thoughts on “Zur Option „Build this from Active Directory information“ bei Zertifikatvorlagen”
Comments are closed.