Schwaches Zertifikatmapping in AD CS

Was ist schwaches Zertifikatmapping?

Schwaches Zertifikatmapping ist ein Risiko der zertifikatbasierten Authentifizierung in Active Directory, bei dem ein Zertifikat einem Konto über wiederverwendbare Namensdaten statt über eine starke, nicht wiederverwendbare Kontobindung zugeordnet werden kann. In konkreten AD CS-Begriffen tritt das Problem auf, wenn die Kerberos-Zertifikatanmeldung oder die Schannel-Client-Zertifikatauthentifizierung Zuordnungen basierend auf Namen wie UPN, DNS-Name, E-Mail-Adresse, Antragstellername oder Aussteller- und Antragstellername akzeptiert.

Das Risiko besteht nicht darin, dass Zertifikate von Natur aus unsicher sind. Zertifikatbasierte Authentifizierung ist eine legitime Windows-Identitätsfunktion. Das Risiko besteht darin, dass namensbasierte Zuordnungen mehrdeutig oder wiederverwendbar sein können, insbesondere wenn Zertifikate, Kontonamen, UPNs, alternative Antragstellernamen oder Legacy-Zuordnungen das Zertifikat nicht eindeutig an das beabsichtigte Konto binden. Microsoft hat diese Problemklasse durch Änderungen der zertifikatbasierten Authentifizierung auf Windows-Domänencontrollern behandelt, einschließlich der Durchsetzung starker Zertifikatzuordnung und Überwachungsereignissen für Zertifikate, die mit dem Full-Enforcement-Modus nicht kompatibel sind.

Dieser Artikel konzentriert sich auf das von Microsoft dokumentierte Zertifikatzuordnungsverhalten: die Stärke der Kerberos-KDC-Zuordnung, altSecurityIdentities, StrongCertificateBindingEnforcement, die Schannel-CertificateMappingMethods und die operativen Ereignisse, die schwache oder fehlgeschlagene Zuordnungen anzeigen. Er behandelt nicht jedes AD CS-Problem als dasselbe Problem. Vorlagenfehlkonfigurationen wie beliebige SAN-Registrierung sind verwandt, aber schwaches Zertifikatmapping betrifft speziell, wie das Zertifikat während der Authentifizierung an ein Konto gebunden wird.

Für die breitere AD CS-Angriffsfläche siehe ADCS-Zertifikatangriffe: Wie ESC1 bis ESC8 zu Domain Admin führen. Für einen verwandten, aber unterschiedlichen schlüsselbasierten Authentifizierungspfad siehe Shadow Credentials: Missbrauch von msDS-KeyCredentialLink in Active Directory.

Wie Zertifikatmapping funktioniert

Kerberos-Zertifikatanmeldung

Bei der Kerberos-zertifikatbasierten Authentifizierung erhält das Key Distribution Center (KDC) eine zertifikatbasierte Authentifizierungsanfrage und muss bestimmen, welches Konto das Zertifikat repräsentiert. Die Microsoft-PKCA-Dokumentation definiert die Zertifikatzuordnungsstärke und klassifiziert Zuordnungsmethoden als schwach oder stark. Schwache Zuordnungen hängen von Namensdaten ab. Starke Zuordnungen hängen von Identifikatoren ab, die schwerer wiederzuverwenden oder direkt an das Konto gebunden sind.

Microsoft listet schwache KDC-Zuordnungen wie SAN UPNName, SAN DNSName, altSecurityIdentities Aussteller und Antragsteller, altSecurityIdentities nur Antragsteller und das 822-Feld von altSecurityIdentities auf. Microsoft listet starke Zuordnungen wie SID, Key Trust, altSecurityIdentities Aussteller und Seriennummer, Subject Key Identifier, SHA1-Hash des öffentlichen Schlüssels sowie Aussteller und SID auf. Der operative Unterschied ist direkt: Wenn der KDC ein Zertifikat über eine schwache Methode zuordnet, sollte er weiter nach einer stärkeren Zuordnung suchen und kann die Authentifizierungsanfrage ablehnen, wenn er keine findet.

Diese Unterscheidung erklärt, warum starke Bindung zählt. Ein Zertifikat, das einen wiederverwendbaren Namen enthält, ist nicht so stark wie ein Zertifikat, das eine SID-Erweiterung trägt oder explizit über Aussteller und Seriennummer, SKI oder SHA1-Hash des öffentlichen Schlüssels zugeordnet ist. Die Aufgabe des Verteidigers besteht darin, vermeidbare schwache Zuordnungen zu entfernen und sicherzustellen, dass die zertifikatbasierte Authentifizierung nur über starke Zuordnungen erfolgreich ist.

Schannel-Client-Zertifikatzuordnung

Kerberos ist nicht die einzige Windows-Komponente, die Zertifikate Konten zuordnet. Microsoft dokumentiert, dass Schannel ein Client-Zertifikat, das einer Serveranwendung bereitgestellt wird, einem Windows-Benutzerkonto zuordnen kann. Der Registrierungswert CertificateMappingMethods steuert, welche Zuordnungsmethoden Schannel verwenden kann. Microsoft gibt an, dass Subject/Issuer-, Issuer- und UPN-Zertifikatzuordnungen schwach und im aktualisierten Verhalten standardmäßig deaktiviert sind, während S4U2Self und S4U2Self explizit stark sind.

Das ist wichtig, weil zertifikatbasierte Authentifizierung an mehr als einer Stelle auftreten kann: Smartcard-Anmeldung, PKINIT, Client-TLS-Authentifizierung, Legacy-Webanwendungen, VPN-Portale, NPS/RADIUS-Flüsse und interne Verwaltungsdienste. Eine Domäne kann einen gehärteten KDC haben, während ein Anwendungspfad noch von schwacher Schannel-Zuordnung abhängt. Behandeln Sie Kerberos und Schannel als verwandte, aber unterschiedliche Kontrollflächen.

Die Rolle von AD CS-Vorlagen

AD CS-Zertifikatvorlagen beeinflussen, welche Zertifikate ausgestellt werden können und welche Identitätsdaten sie enthalten. Die Microsoft-Defender-for-Identity-Dokumentation beschreibt riskante Zertifikatvorlagen, bei denen Benutzer je nach Vorlageneinstellungen Zertifikate anfordern können, die für beliebige Benutzer gültig sind. Sie hebt speziell die Option Supply in the request, Authentifizierungs-EKUs wie Client Authentication oder Smartcard Logon, übermäßig freizügige Registrierungsberechtigungen, fehlende Manager-Genehmigung und von einer CA veröffentlichte Vorlagen hervor.

Vorlagenmissbrauch und schwache Zuordnung sind nicht identisch. Ein Vorlagenproblem bestimmt, ob ein Benutzer ein Zertifikat mit gefährlichen Identitätsansprüchen erhalten kann. Ein Zuordnungsproblem bestimmt, ob die Domäne oder Anwendung dieses Zertifikat als bestimmtes Konto akzeptiert. In realen Umgebungen kombinieren sich die beiden Probleme oft: Eine Vorlage lässt einen nicht privilegierten Benutzer ein Zertifikat mit vom Angreifer kontrollierten Identitätsdaten anfordern, und schwache Zuordnung lässt diese Daten auf ein privilegiertes Konto auflösen.

Warum schwaches Mapping nach Microsofts Durchsetzungsänderungen weiterhin wichtig ist

Microsofts KB5014754 dokumentiert Änderungen der zertifikatbasierten Authentifizierung für Windows-Domänencontroller. Die Änderungen beheben Schwachstellen zur Rechteausweitung, die auftreten können, wenn der Kerberos-KDC zertifikatbasierte Authentifizierungsanfragen bedient. Microsoft erklärt, dass vor dem Sicherheitsupdate vom 10. Mai 2022 die zertifikatbasierte Authentifizierung ein Dollarzeichen am Ende eines Maschinennamens nicht berücksichtigte und dass Konflikte zwischen UPNs und sAMAccountName Spoofing-Schwachstellen einführten.

Die wichtigen operativen Daten sind bereits vergangen. Microsoft hat dokumentiert, dass Domänencontroller mit dem Windows-Sicherheitsupdate vom Februar 2025 in den Full-Enforcement-Modus wechselten, sofern Administratoren nicht bereits den Registrierungsschlüssel StrongCertificateBindingEnforcement konfiguriert hatten. Microsoft hat auch dokumentiert, dass dieser Registrierungsschlüssel nach dem Windows-Sicherheitsupdate vom 9. September 2025 nicht mehr unterstützt wird. Im Full-Enforcement-Modus wird die Authentifizierung verweigert, wenn ein Zertifikat nicht stark zugeordnet werden kann.

Das macht das Thema nicht obsolet. Es ändert, was Verteidiger prüfen sollten. In einer gepatchten Umgebung werden schwache Zuordnungsabhängigkeiten zu operativen Ausfällen, Sicherheitsschulden oder einem Zeichen dafür, dass jemand Kompatibilitätseinstellungen beibehalten hat, die entfernt werden sollten. In weniger konsistenten Umgebungen können gemischte Patch-Stände von Domänencontrollern, Legacy-Client-Zertifikatnutzung, Schannel-basierte Anwendungen, Nicht-Microsoft-CA-Bereitstellungen und manuelle altSecurityIdentities-Zuordnungen weiterhin reale Exposition schaffen.

Eine ausgereifte Prüfung sollte drei Fragen beantworten:

Sind alle Domänencontroller und AD CS-Server mit den relevanten Microsoft-Sicherheitsupdates gepatcht?
Gelingen Zertifikatanmeldungen über starke Zuordnungen statt über namensbasierte schwache Zuordnungen?
Hängen Anwendungen oder Domänencontroller noch von Kompatibilitätsverhalten, schwachen Schannel-Methoden oder manuellen Legacy-Zuordnungen ab?

Die Angriffskette

Ein sicheres defensives Angriffskettenmodell sieht so aus:

Phase	Was passiert	Was Verteidiger überprüfen sollten
1. Gelegenheit zur Zertifikatausstellung	Eine Vorlage, CA-Einstellung oder ein Registrierungspfad lässt einen Benutzer ein Zertifikat mit Identitätsdaten erhalten, die die Authentifizierung beeinflussen können.	Authentifizierungs-EKUs, `Supply in the request`, Registrierungsberechtigungen, Manager-Genehmigung, autorisierte Signaturen und ob die Vorlage veröffentlicht ist, überprüfen.
2. Schwache Kontozuordnung	Das Zertifikat wird einem Konto über wiederverwendbare Namensdaten oder eine Legacy-`altSecurityIdentities`-Zuordnung statt über eine starke Kontobindung zugeordnet.	Schwache Zuordnungsmethoden, manuelle Zuordnungen, Schannel-Einstellungen und KDC-Überwachungsereignisse inventarisieren.
3. Zertifikatbasierte Authentifizierung	Das Zertifikat wird für Kerberos-PKINIT, Smartcard-Anmeldung oder einen Schannel-Client-Authentifizierungspfad vorgelegt.	KDC-Ereignisse, Schannel-Verhalten, CA-Ausstellung und Empfindlichkeit des Zielkontos korrelieren.
4. Auswirkung auf Berechtigungen	Das zugeordnete Konto ist privilegiert, hat Rechte zur seitlichen Bewegung oder kann sensible Dienste erreichen.	Privilegierte Konten, Dienstzugriff und nachgelagerte Nutzung nach der Zertifikatauthentifizierung überprüfen.
5. Persistenz- oder Wiederholungsrisiko	Das Zertifikat bleibt bis zum Ablauf oder Widerruf gültig, selbst bei einem Passwort-Reset.	Zertifikate gegebenenfalls widerrufen, schwache Zuordnungen entfernen und starke Bindung nach der Bereinigung überprüfen.

Der Artikel vermeidet absichtlich offensive Tool-Syntax. Der technische Fehler ist auch ohne einen Copy-Paste-Exploit-Pfad klar: Ein Zertifikat wird mit Identitätsdaten ausgestellt oder akzeptiert, die nicht ausreichen sollten, um das Zielkonto zu repräsentieren.

Dieser Pfad steht neben anderen Active-Directory-Eskalationspfaden. Für Objektberechtigungspfade siehe ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen. Für Kerberos-Persistenz, die nicht auf Zertifikaten beruht, vergleichen Sie Golden-Ticket-Angriff: Der Schlüssel zu Ihrer Domäne und Silver-Ticket-Angriff: Gefälschte Kerberos-Service-Tickets in Active Directory.

Erkennung

Die Erkennung von schwachem Zertifikatmapping ist ein Korrelationsproblem. Ein einzelnes Ereignis kann eine schwache oder fehlgeschlagene Zertifikatzuordnung zeigen, erklärt aber für sich genommen nicht, wie das Zertifikat ausgestellt wurde, ob das Konto privilegiert ist oder ob ein Legacy-Anwendungspfad noch von schwachem Verhalten abhängt.

Signal	Quelle	Worauf zu achten ist	Einschränkung
Schwache oder fehlgeschlagene KDC-Zuordnungsereignisse	Systemprotokoll des Domänencontrollers nach relevanten Updates	Von KB5014754 dokumentierte Ereignisse für Zertifikate ohne starke Zuordnung oder mit fehlgeschlagenen Full-Enforcement-Kriterien.	Erfordert aktualisierte Domänencontroller und relevante Zertifikatauthentifizierungsversuche.
Zertifikatausstellung an sensible Identitäten	AD CS CA-Sicherheitsprotokolle	Ausgestellte Zertifikate mit Authentifizierungs-EKUs, Antragstelleridentität, Vorlagenname, SAN- oder Antragstellerdaten, sofern protokolliert.	CA-Protokollierung muss aktiviert und aufbewahrt werden; Ausstellung allein beweist keine erfolgreiche Authentifizierung.
Schwache `altSecurityIdentities`-Werte	Active-Directory-Inventar	Namensbasierte manuelle Zuordnungen wie Aussteller/Antragsteller, nur Antragsteller oder RFC822/E-Mail-artige Zuordnungen.	Manuelle Zuordnung kann Legacy-Geschäftslogik sein; vor der Entfernung validieren.
Schwache Schannel-Zuordnungskonfiguration	Registrierung des Domänencontrollers und Anwendungsverhalten	`CertificateMappingMethods`-Werte, die schwache Zuordnungsmethoden reaktivieren.	Schannel-Fehler können Anwendungen betreffen; vor Änderungen an Produktionseinstellungen testen.
Vorlagenrisiko	AD CS-Vorlagenüberprüfung oder Defender-for-Identity-Bewertung	`Supply in the request`, Authentifizierungs-EKUs, breite Registrierungsberechtigungen, keine Genehmigung, veröffentlichte Vorlagen.	Vorlagenrisiko und Zuordnungsrisiko sind verwandt, aber nicht identisch.

KDC-Ereignisse und Full-Enforcement-Signale

Microsofts KB5014754 fügte Überwachungsereignisse hinzu, um Zertifikate zu identifizieren, die mit dem Full-Enforcement-Modus nicht kompatibel sind. Es dokumentiert auch, dass im Full-Enforcement-Modus die Authentifizierung verweigert wird, wenn ein Zertifikat nicht stark zugeordnet werden kann. Domänencontroller, die diese Ereignisse protokollieren, teilen Ihnen entweder mit, dass ein Zertifikatauthentifizierungsversuch mit starker Bindung nicht kompatibel ist, oder dass in einem Pfad, den Sie verstehen müssen, noch eine Legacy-Zertifikatzuordnung existiert.

Behandeln Sie diese Ereignisse nicht als Rauschen. Eine Warnung vor schwacher Zuordnung kann ein Geschäftskompatibilitätsproblem, eine Migrationsaufgabe oder eine Sicherheitsuntersuchung sein. Priorisieren Sie Ereignisse, die privilegierte Benutzer, Dienstkonten, Domänencontroller, administrative Arbeitsstationen, VPN/NPS-Dienste und von authentifizierungsfähigen Vorlagen ausgestellte Zertifikate betreffen.

AD CS-Ausstellungs- und Vorlagentelemetrie

Die AD CS-Ausstellungstelemetrie beantwortet eine andere Frage: Woher kam das Zertifikat? Überprüfen Sie CA-Protokolle auf ausgestellte Zertifikate, abgelehnte Anfragen, Vorlagennamen, Antragstellerkonten und Zertifikateigenschaften. Wenn die Zertifizierungsdienstüberwachung aktiviert ist, liefern Ereignisse wie 4886, 4887, 4888, 4870, 4871, 4872, 4891, 4892 und 4898 konkrete Telemetrie zu Anfrage, Ausstellung, Ablehnung, Widerruf, CRL-Veröffentlichung, Konfigurationsänderung und Vorlagenladung. Kombinieren Sie dies mit der Vorlagenkonfiguration: Authentifizierungs-EKUs, vom Antragsteller bereitgestellter Antragsteller oder SAN, Registrierungsberechtigungen, Genehmigungsanforderungen, autorisierte Signaturen und ob die Vorlage auf einer CA veröffentlicht ist.

Microsoft-Defender-for-Identity-Sicherheitslagebewertungen können helfen, Vorlagen zu identifizieren, die es Benutzern ermöglichen, Zertifikate anzufordern, die für beliebige Benutzer gültig sind, sowie Vorlagen, die durch CVE-2024-49019-Bedingungen exponiert sind. Defender for Identity empfiehlt speziell, nicht privilegierte Registrierungsberechtigungen zu entfernen, Supply in the request zu deaktivieren, relevante Patches für anfällige AD CS-Server anzuwenden und Abhilfemaßnahmen wie Manager-Genehmigung oder Signaturanforderungen zu verwenden, wo angemessen.

Inventarisierung manueller Zuordnungen

Inventarisieren Sie altSecurityIdentities bei Benutzern, privilegierten Konten und Dienstkonten. Microsoft dokumentiert mehrere unterstützte Werte und klassifiziert Zuordnungen nach ihrer Stärke. Die schwachen sind namensbasiert. Die starken verwenden Aussteller und Seriennummer, SKI, SHA1-Hash des öffentlichen Schlüssels, SID-bezogene Zuordnung oder Key Trust.

Seien Sie bei der Bereinigung vorsichtig. Eine schwache Zuordnung bei einem risikoarmen Legacy-Benutzer kann eine operative Abhängigkeit sein, während eine schwache Zuordnung bei einem privilegierten Konto ein wesentlich höheres Risiko darstellt. Der Sanierungsplan sollte schwache Zuordnungen durch starke Zuordnungen ersetzen, nicht einfach Produktionsauthentifizierungspfade ohne Migration löschen.

Für eine breitere Protokollabdeckung rund um die Aktivität von Domänencontrollern und AD-Objekten kombinieren Sie diesen Artikel mit Active-Directory-Überwachung: Sicherheitsereignis-IDs, die zählen.

Sanierung

Die Sanierung muss sowohl die Zertifikatausstellung als auch die Zertifikatzuordnung angehen. Nur eine Seite zu beheben, lässt Lücken. Ein sicherer Plan entfernt unnötige schwache Zuordnungen, aktualisiert Zertifikatausstellungspraktiken, validiert die Durchsetzung auf Domänencontroller-Ebene und testet Anwendungspfade, die von Client-Zertifikaten abhängen.

Starke Zertifikatbindung durchsetzen

Beginnen Sie mit den Domänencontrollern. Stellen Sie sicher, dass alle Domänencontroller, die zertifikatbasierte Authentifizierung bedienen, mit den relevanten Microsoft-Updates gepatcht sind. In modernen gepatchten Umgebungen ist Full Enforcement der erwartete Zustand. Wenn ein Domänencontroller noch eine Kompatibilitätskonfiguration oder einen Ausnahmepfad hat, dokumentieren Sie, warum er existiert, welche Zertifikate davon abhängen, und den genauen Rückzugsplan.

⚠️

⚠️ Achtung: Microsofts Vorgaben sind klar — der Full-Enforcement-Modus verweigert die Authentifizierung, wenn ein Zertifikat die Kriterien für starke Zuordnung nicht erfüllt. Microsoft gibt auch an, dass schwache Schannel-Methoden im aktualisierten Verhalten standardmäßig deaktiviert sind und dass das Zurücksetzen von CertificateMappingMethods auf den früheren breiten Wert schwache Zertifikatzuordnungsmethoden wieder aktiviert. Behandeln Sie diese Registrierungsänderung als Kompatibilitätsausnahme, nicht als normalen Härtungszustand.

Schwache Zuordnungen ersetzen

Ersetzen Sie bei manuellen Zuordnungen in altSecurityIdentities schwache Zuordnungen durch starke Zuordnungen, wenn das Geschäft noch eine explizite Zuordnung benötigt. Microsoft empfiehlt starke Zuordnungen wie Aussteller und Seriennummer, wenn Zertifikate nicht mit der neuen SID-Erweiterung neu ausgestellt werden können. Weitere starke Zuordnungsoptionen umfassen SKI und den SHA1-Hash des öffentlichen Schlüssels gemäß der Microsoft-Dokumentation zur Zuordnungsstärke.

Lassen Sie privilegierte Konten nicht über wiederverwendbare Namen zugeordnet. Domänenadministratoren, Zertifikatadministratoren, Registrierungsagenten, Dienstkonten, Notfallidentitäten (Break-Glass) und Benutzer administrativer Arbeitsstationen sollten sich nicht auf schwache Identitätsbindung verlassen. Wenn ein privilegierter Zertifikat-Workflow existiert, sollte er starke Zuordnung, dokumentierte Ausstellung, gegebenenfalls kurze Zertifikatlebensdauern und explizite Überwachung verwenden.

Zertifikatvorlagen und CA-Einstellungen korrigieren

Überprüfen Sie Vorlagen, die authentifizierungsfähige Zertifikate ausstellen können. Die Empfehlungen von Microsoft Defender for Identity heben mehrere konkrete Abhilfemaßnahmen für Vorlagen hervor, die Zertifikatanfragen für beliebige Benutzer ermöglichen: Supply in the request deaktivieren, EKUs entfernen, die Benutzerauthentifizierung ermöglichen, wenn nicht erforderlich, übermäßig freizügige Registrierungsberechtigungen entfernen, Manager-Genehmigung verlangen, autorisierte Signaturen verlangen oder Vorlagen von CAs zurückziehen, wenn sie nicht benötigt werden.

Überprüfen Sie auch CA-Einstellungen wie EDITF_ATTRIBUTESUBJECTALTNAME2. Microsoft Defender for Identity gibt an, dass ein Angreifer, wenn dieses Flag aktiviert und eine Vorlage für die Authentifizierung gültig ist, ein Zertifikat registrieren kann, das beliebige Konten imitieren kann. Dies ist nicht dasselbe wie schwache Zuordnung, wirkt sich aber direkt darauf aus, ob gefährliche Identitätsansprüche in ausgestellten Zertifikaten erscheinen können.

Schannel- und Anwendungsabhängigkeiten testen

Bevor Sie Schannel-Zuordnungseinstellungen ändern, identifizieren Sie Anwendungen, die Client-Zertifikatauthentifizierung verwenden: IIS-Anwendungen, VPN, NPS/RADIUS, interne Admin-Portale, Geräteauthentifizierungsflüsse und Legacy-Middleware. Testen Sie sie mit starken Zuordnungspfaden. Wenn ein Dienst nur ausfällt, wenn schwache Zuordnung deaktiviert wird, besteht die Lösung nicht darin, schwache Zuordnung unbegrenzt beizubehalten. Die Lösung besteht darin, Zertifikatausstellung und Kontozuordnung so zu aktualisieren, dass sich der Dienst über eine starke Bindung authentifiziert.

Widerrufen und neu ausstellen, wo nötig

Wenn verdächtige Zertifikate ausgestellt oder schwach zugeordnet wurden, widerrufen Sie die betroffenen Zertifikate, veröffentlichen Sie gegebenenfalls aktualisierte CRLs und validieren Sie, dass abhängige Systeme den Widerruf prüfen. Stellen Sie Zertifikate mit Unterstützung für starke Zuordnung oder mit expliziter starker manueller Zuordnung neu aus. Wenn das Konto nach der Zertifikatauthentifizierung verwendet wurde, behandeln Sie die Untersuchung wie eine Identitätskompromittierung: Überprüfen Sie Gruppenänderungen, Dienstzugriff, seitliche Bewegung und nachgelagerte administrative Aktionen.

Validierung nach der Härtung

Die Validierung sollte beweisen, dass die Authentifizierung für legitime Benutzer weiterhin funktioniert und für schwach gebundene Zertifikate fehlschlägt.

Validierungsschritt	Erfolgskriterium
Überprüfung der Domänencontroller-Patches	Alle Domänencontroller, die zertifikatbasierte Authentifizierung bedienen, sind aktualisiert und arbeiten im erwarteten Durchsetzungszustand.
Überprüfung der KDC-Ereignisse	Nach der Migration bestehen keine wiederkehrenden Warnungen vor schwacher Zuordnung für legitime Authentifizierungsflüsse mehr.
Test der starken Zuordnung	Benutzer- und Maschinenzertifikatanmeldungen gelingen über SID-Erweiterung, Key Trust oder explizite starke Zuordnungen.
Test der schwachen Zuordnung	Zertifikate, die sich nur über schwache namensbasierte Methoden zuordnen, schlagen unter Durchsetzungsbedingungen fehl.
Vorlagenüberprüfung	Authentifizierungsfähige Vorlagen erlauben keine beliebigen Identitätsansprüche ohne kompensierende Kontrollen.
Schannel-Überprüfung	Anwendungen, die Client-Zertifikate verwenden, hängen nicht von schwachen Subject/Issuer-, Issuer- oder UPN-Zuordnungsmethoden ab.
Vorfallvalidierung	Widerrufene oder ersetzte Zertifikate authentifizieren sich nicht mehr, und die nachgelagerte Kontoaktivität wurde überprüft.

Führen Sie die Validierung in Phasen durch. Beginnen Sie mit einer Test-OU oder einer repräsentativen Dienstgruppe und erweitern Sie dann auf privilegierte Benutzer, administrative Arbeitsstationen, VPN/NPS, Smartcard-Benutzer, Dienstkonten und Maschinenzertifikatszenarien. Gehen Sie nicht davon aus, dass ein bestandener Smartcard-Test jeden Zertifikatauthentifizierungspfad in der Domäne validiert.

Wie EtcSec verwandte Exposition erkennt

EtcSec sollte schwaches Zertifikatmapping als eine Exposition der Zertifikatidentitätsbindung behandeln, nicht nur als AD CS-Vorlagenproblem. Zu den verwandten Signalen gehören schwache oder veraltete altSecurityIdentities-Zuordnungen, Zertifikatvorlagen, die authentifizierungsfähige Zertifikate mit gefährlicher Antragstellerkontrolle ausstellen, übermäßig breite Registrierungsberechtigungen, CA-Einstellungen, die anfragebereitgestellte SANs erlauben, und Kompatibilitätseinstellungen von Domänencontrollern, die schwaches Zuordnungsverhalten beibehalten.

Die Plattform kann diese Exposition auch mit angrenzenden Angriffspfaden verknüpfen: AD CS-Vorlagen, die beliebige Identitäten erlauben, Prinzipale, die Zertifikatvorlagen-ACLs ändern können, privilegierte Benutzer, die auf schwache Zertifikatzuordnungen angewiesen sind, und fehlende Domänencontroller-Überwachung für zertifikatbasierte Authentifizierungsereignisse. Das ist die nützliche operative Sicht. Eine schwache Zuordnung ist gefährlich, weil sie zwischen Zertifikatausstellung und Kontoauthentifizierung liegt.

Kontrolle	Warum sie wichtig ist
Full Enforcement für zertifikatbasierte Authentifizierung	Verweigert die Authentifizierung, wenn das Zertifikat nicht stark zugeordnet werden kann.
Starke Zertifikatbindungspfade	Ersetzt wiederverwendbare namensbasierte Zuordnungen durch starke manuelle `altSecurityIdentities`-Zuordnungen wie Aussteller/Seriennummer, SKI oder SHA1-Hash des öffentlichen Schlüssels, oder durch andere starke Pfade wie SID-Erweiterung, Key Trust oder Aussteller/SID.
Härtung der AD CS-Vorlagen	Verhindert, dass nicht vertrauenswürdige Benutzer authentifizierungsfähige Zertifikate für beliebige Identitäten erhalten.
Überprüfung der Schannel-Zuordnung	Findet Anwendungspfade, die noch von schwacher Zertifikatzuordnung abhängen.
Überwachung der CA-Ausstellung	Zeigt, welche Zertifikate an wen, von welcher Vorlage und mit welchen Identitätsdaten ausgestellt wurden.
Überprüfung der Zertifikate privilegierter Konten	Stellt sicher, dass Administratoren und sensible Dienstkonten sich nicht auf schwache Identitätsbindung verlassen.
Widerrufsvalidierung	Bestätigt, dass verdächtige oder ersetzte Zertifikate sich nicht mehr authentifizieren.

Schwaches Zertifikatmapping in AD CS: Warum starke Bindung zählt