Zur Option "Build this from Active Directory information" bei Zertifikatvorlagen

Bei der Konfiguration einer Zertifikatvorlage muss man über den beabsichtigten Zertifikatinhalt entscheiden, d.h. unter Anderen, welche Identitäten durch die Zertifikate bestätigt werden, und wie diese abgebildet werden.

In der Karteikarte "Subject Name" des Konfigurationsdialogs für Zertifikatvorlagen kann konfiguriert werden, wie die durch das Zertifikat bestätigte Identität abgebildet wird.

Hier gibt es die folgenden beiden Möglichkeiten:

Supply in the request

Die Identität wird durch den Antragsteller bestimmt. Diese Option ist latent unsicher, wenn keine Prüfung einer solchen Zertifikatanforderung durch einen Zertifikatmanager erfolgt, da mit Bordmitteln nicht keine Einschränkung der beantragten Identitäten vorgenommen werden kann (hierfür bietet sich das TameMyCerts Policy Modul an).

Build from Active Directory information

Die Identität wird durch die Zertifizierungsstelle bestimmt. Wenn der Antragsteller die Zertifikatanforderung einreicht, wird anhand dessen Anmeldedaten das dazugehörige Konto im Active Directory ermittelt und die definierten Attribute werden in den Zertifikatinhalt übernommen.

Je nach Konfiguration werden die folgenden Active Directory Attribute eines Kontos in die ausgestellten Zertifikate übertragen:

Option Zertifikatvorlage	Zertifikat-Attribut/Erweiterung	RDN bzw. SAN-Typ	Active Directory Attribut
Common name	Subject	commonName	cn bzw. name (bei Benutzerkonten) dNSHostName (bei Computerkonten)
Fully distinguished name	Subject	commonName	distinguishedName
None	Subject	{leer}	{keines}
Include e-mail name in subject name	Subject	commonName	mail
E-Mail name	Subject Alternative Name	rfc822Name	mail
DNS Name	Subject Alternative Name	dNSName	dNSHostName (nur bei Computerkonten vorhanden)
User principal name (UPN)	Subject Alternative Name	otherName: userPrincipalName	userPrincipalName (nur bei Benutzerkonten vorhanden)
Service principal name (SPN)	Subject Alternative Name	servicePrincipalName	servicePrincipalName

Microsoft hat mit dem kumulativen Update vom Mai 2022 eine proprietäre Zertifikaterweiterung eingeführt, welche das objectSid ("Security Identifier") Active Directory Attribut beinhaltet. Siehe hierzu Artikel "Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)".

Wechselwirkungen

Überschneidungen zwischen Attributen führen zu Fehlkonfiguration

In manchen Unternehmen sind die Active Directory Attribute "cn", "name" und "samAccountName" mit identischen Werten befüllt, sodass es hier zu Missverständnissen kommen kann. Beispielsweise wird bei der Zertifikatbeantragung per Mobile Device Management (MDM) das samAccountName für den commonName verwendet, oder der Authentisierungs-Server ordnet den Inhalt des commonName Attributes wiederum dem samAccountName Attribut im Active Directory zu, um ein Konto zu finden.

Active Directory Atttribut nicht vorhanden

Soll ein leeres Active Directory Attribut eingetragen werden (d.h. ein Benutzer beantragt ein Zertifikat, welches ein Attribut verlangt, das auf seinem Konto nicht mit einem Wert befüllt ist), wird die Zertifikatbeantragung fehlschlagen (Die Zertifizierungsstelle wird das Ereignis Nr. 53 mit einem der untenstehenden Fehlercodes protokollieren).

Fehlercode	Fehlendes Active Directory Attribut
CERTSRV_E_SUBJECT_DNS_REQUIRED	dNSHostName
CERTSRV_E_SUBJECT_EMAIL_REQUIRED	mail
CERTSRV_E_SUBJECT_UPN_REQUIRED	userPrincipalName

Vermeintlich unnötiges nicht vorhandenes Attribut im Zertifikat führt zu dessen Ablehnung

RFC 2818 (aus dem Jahr 2000) besagt, dass der commonName nicht mehr für die Identifikation von Websites verwendet werden soll, und stattdessen der Subject Alternative Name in Form eines dNSName zu verwenden ist. Diese Logik wird auch auch artverwandte Anwendungsfälle wie LDAP über SSL (im Falle von Domänencontroller-Zertifikaten) angewendet. Die Standard-Zertifikatvorlagen für Domänencontroller beinhalten daher keinen commonName mehr.

Aus Kompatibilitätsgründen kann es allerdings sinnvoll sein, den commonName weiterhin zu befüllen. Beispielsweise, wenn auf einem Domänencontroller auch ein Netzwerkrichtliniendienst (engl. Network Policy Server, NPS) installiert ist, welcher das Domänencontroller-Zertifikat mit benutzen soll, oder für Legacy-Anwendungen, die nicht gemäß RFC 2818 arbeiten.

Umbenennung des Benutzers sperrt diesen aus

Bitte beachten, dass der in Windows integrierte Zertifikatclient keine Möglichkeit hat, Änderungen des Benutzernamens zu erkennen. Wird ein Benutzerkonto z.B. wegen Eheschließung umbenannt, müssen vorhandene Benutzerzertifikate gelöscht werden, damit der Autoenrollment-Prozess diese neu beantragt.

Umbenennung des Domänensuffix sperrt alle Benutzer aus

Firmiert ein Unternehmen beispielsweise um, kann es vorkommen dass sich der Domänensuffix und entsprechend auch die userPrincipalName Attribute der Benutzer ändern. Werden die dazugehörigen Zertifikatattribute verwendet um eine Verknüpfung zum Benutzerkonto herzustellen, müssen alle Benutzerzertifikate neu ausgestellt werden. Das gleiche gilt für Zertifikate, in denen ein dNSHostName oder ein servicePrincipalName eingetragen wird.

Sonderfall Domänencontroller

Siehe Artikel "Zertifikate für Domänencontroller enthalten nicht den Domänennamen im Subject Alternative Name (SAN)".