Starke Zertifikatzuordnung (KB5014754) in der Praxis

Vor Mai 2022 ordnete ein Domänencontroller ein Zertifikat einem Konto überwiegend anhand des Namens zu: über den UPN im alternativen Antragstellernamen (SAN) bei Benutzerzertifikaten, über den DNS-Namen bei Computerzertifikaten. Damit war der Inhalt des Zertifikats das Einzige, was zwischen einem Antragsteller und jeder Identität stand, deren Namen er in ein Zertifikat bringen konnte. CVE-2022-26923 („Certifried“) zeigte, wie wenig dafür nötig war: Ein Benutzer, der ein Computerkonto anlegen durfte, konnte dessen dNSHostName auf den Namen eines Domänencontrollers setzen und ein Zertifikat erhalten, das dem DC zugeordnet wurde. KB5014754 ist Microsofts Lösung. Es verpflichtet KDC und Schannel zu einer starken Bindung zwischen Zertifikat und Konto und wird seit 2025 vollständig erzwungen.

Dieser Leitfaden behandelt, was „stark“ in der Praxis bedeutet, wie Sie die Zertifikate und Zuordnungen finden, die diese Anforderung nicht erfüllen, wie Sie jede Kategorie korrigieren und was die Erzwingung lahmlegt. Er setzt voraus, dass Ihre Vorlagen bereits bereinigt sind, wie in Zertifikatvorlagen auditieren und im Leitfaden zur AD-CS-Härtung beschrieben.

Wie starke Zuordnung funktioniert

Unter vollständiger Erzwingung akzeptiert das KDC ein Zertifikat für PKINIT nur, wenn eines der folgenden Merkmale es an das Konto bindet:

1. Die SID-Sicherheitserweiterung (szOID_NTDS_CA_SECURITY_EXT, OID 1.3.6.1.4.1.311.25.2). Unternehmens-CAs mit dem Update vom Mai 2022 oder neuer schreiben die SID des Antragstellers bei Online-Vorlagen, deren Antragsteller aus Active Directory erstellt wird, in diese Erweiterung.
2. Eine starke explizite Zuordnung im Attribut altSecurityIdentities des Kontos: X509IssuerSerialNumber, X509SKI oder X509SHA1PublicKey.
3. Eine SID im SAN als URL der Form tag:microsoft.com,2022-09-14:sid:<SID>, die spätere Updates zu KB5014754 für Zertifikate eingeführt haben, die die Erweiterung nicht tragen können. Prüfen Sie, ob der Update-Stand Ihrer DCs dies unterstützt, bevor Sie sich darauf verlassen.

Das Verhalten des KDC wurde über StrongCertificateBindingEnforcement unter HKLM\SYSTEM\CurrentControlSet\Services\Kdc gesteuert:

Zeitplan laut KB5014754: Am 10. Mai 2022 wurden die SID-Erweiterung und der Kompatibilitätsmodus mit Überwachungsereignissen eingeführt; im Februar 2025 wurde die vollständige Erzwingung zum Standard, ein explizit gesetzter Wert 1 wurde aber noch berücksichtigt; im September 2025 wurde der Kompatibilitätsmodus entfernt, sodass aktuelle DCs unabhängig von der Registrierung erzwingen. Steht der Wert noch in Ihrer Baseline, dokumentiert er Historie, keine Maßnahme. Auch der Wert CertificateBackdatingCompensation, der im Kompatibilitätsmodus die Prüfung „Zertifikat älter als Konto“ feinjustierte, ist irrelevant, sobald die Erzwingung dauerhaft gilt.

Schannel (TLS-Clientzertifikat-Authentifizierung bei IIS, LDAPS und anderen) hat einen eigenen Schalter, CertificateMappingMethods unter HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel. Das Update änderte dessen Standard auf 0x18 (S4U2Self-basierte Zuordnung), wodurch Schannel dieselben KDC-Prüfungen durchläuft. Ein Zurücksetzen auf 0x1F aktiviert die schwache UPN- und Antragstellerzuordnung wieder und ist als Befund zu werten.

Messen: KDC-Ereignisse 39, 40 und 41

Jeder DC protokolliert Probleme bei der Zertifikatzuordnung im Systemprotokoll über den Anbieter Kerberos Key Distribution Center:

• 39: Ein Zertifikat war gültig, konnte aber nicht stark zugeordnet werden. Warnung im Kompatibilitätsmodus, Ablehnung unter vollständiger Erzwingung.
• 40: Das Zertifikat wurde vor der Erstellung des Kontos ausgestellt, und es existiert keine starke Zuordnung. Abgelehnt.
• 41: Die SID-Erweiterung des Zertifikats stimmt nicht mit der SID des Kontos überein. Abgelehnt und untersuchenswert: Entweder wurde das Konto neu angelegt, oder jemand legt ein Zertifikat vor, das für einen anderen Prinzipal ausgestellt wurde.

Sammeln Sie sie von allen DCs:

$dcs = (Get-ADDomainController -Filter *).HostName
$events = foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -ErrorAction SilentlyContinue -FilterHashtable @{
        LogName = 'System'
        ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
        Id = 39, 40, 41
        StartTime = (Get-Date).AddDays(-30)
    }
}
$events | Group-Object Id, { $_.Properties[0].Value } |
    Sort-Object Count -Descending |
    Select-Object Count, Name -First 50

Die erste Eigenschaft jedes Ereignisses ist der Kontoname. Die Gruppierung nach Ereignis-ID und Konto macht aus Tausenden von Ereignissen eine kurze Liste scheiternder Identitäten. Lesen Sie für jede Gruppe ein vollständiges Ereignis: Die Meldung enthält Antragsteller, Aussteller und Seriennummer des Zertifikats und verrät so, welche CA und welche Vorlage es erzeugt haben.

Auditieren: Zertifikate ohne SID-Erweiterung

Bei AD-CS-Zertifikaten lautet die Frage, welche Vorlagen Zertifikate ohne die Erweiterung ausstellen. Drei Ursachen decken fast jeden Fall ab:

• Offline-Vorlagen („Informationen werden in der Anforderung angegeben“): Die CA kann nicht wissen, auf welches Konto sich der Antragsteller bezieht, und fügt daher keine SID hinzu.
• CT_FLAG_NO_SECURITY_EXTENSION (0x80000 in msPKI-Enrollment-Flag) auf der Vorlage, wodurch die Erweiterung unterdrückt wird. In Kombination mit schwacher Zuordnung war das die Klasse ESC9.
• Die CA-weit deaktivierte Erweiterung über DisableExtensionList, die sie für jede Vorlage unterdrückt (die Klasse ESC16).

# Vorlagen, die die SID-Erweiterung unterdrücken
$tplBase = "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)"
Get-ADObject -SearchBase $tplBase -LDAPFilter '(objectClass=pKICertificateTemplate)' -Properties 'msPKI-Enrollment-Flag' |
    Where-Object { $_.'msPKI-Enrollment-Flag' -band 0x80000 } | Select-Object Name

# CA-weite Unterdrückung (für jede CA ausführen): 1.3.6.1.4.1.311.25.2 darf nicht aufgeführt sein
certutil -config "ca01.corp.example\CORP-Issuing-CA" -getreg policy\DisableExtensionList

Um ein Zertifikat auf einem Client zu untersuchen, prüfen Sie direkt seine Erweiterungen:

Get-ChildItem Cert:\LocalMachine\My, Cert:\CurrentUser\My |
    Where-Object { $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.5.5.7.3.2' } |
    Select-Object Subject, Issuer, NotAfter,
        @{n='SidExtension';e={ [bool]($_.Extensions | Where-Object { $_.Oid.Value -eq '1.3.6.1.4.1.311.25.2' }) }}

Auditieren: altSecurityIdentities

Explizite Zuordnungen sind verbreitet bei Smartcards aus Kartenverwaltungssystemen von Drittanbietern, bei gesamtstrukturübergreifender Zertifikatanmeldung und bei Dienstkonten, die sich mit einem Zertifikat authentifizieren. Klassifizieren Sie sie:

Get-ADObject -LDAPFilter '(altSecurityIdentities=*)' -Properties altSecurityIdentities, objectClass |
ForEach-Object {
    foreach ($m in $_.altSecurityIdentities) {
        $strength = switch -Regex ($m) {
            '^X509:<I>.+<SR>'     { 'Strong (IssuerSerial)' }
            '^X509:<SKI>'         { 'Strong (SKI)' }
            '^X509:<SHA1-PUKEY>'  { 'Strong (SHA1 public key)' }
            '^X509:<RFC822>'      { 'Weak (email)' }
            '^X509:<I>.+<S>'      { 'Weak (issuer+subject)' }
            '^X509:<S>'           { 'Weak (subject only)' }
            '^Kerberos:'          { 'Kerberos principal mapping' }
            default               { 'Unknown' }
        }
        [pscustomobject]@{ Account = $_.Name; Class = $_.objectClass; Strength = $strength; Mapping = $m }
    }
} | Sort-Object Strength | Format-Table -AutoSize

Prüfen Sie auch, wer das Attribut schreiben kann. Schreibzugriff auf altSecurityIdentities eines privilegierten Kontos erlaubt einem Angreifer, sein eigenes Zertifikat diesem Konto zuzuordnen — die Klasse ESC14. Nehmen Sie das Attribut in Ihre Prüfung der AD-ACLs auf und stellen Sie sicher, dass Tier-0-Konten durch AdminSDHolder geschützt sind, damit ein delegierter ACE nicht auf ihnen verbleiben kann.

Erzwingen: jede Kategorie korrigieren

• AD-CS-Online-Vorlagen: bereits stark, sobald die CAs das Update vom Mai 2022 haben, solange keines der beiden Unterdrückungs-Flags gesetzt ist. Entfernen Sie CT_FLAG_NO_SECURITY_EXTENSION aus den Vorlagen und die OID aus DisableExtensionList mit certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2, gefolgt von einem Neustart des CA-Dienstes. Stellen Sie dann neu aus: Bestehende Zertifikate erhalten die Erweiterung nicht nachträglich, also lösen Sie die Erneuerung über die automatische Registrierung aus („Alle Zertifikatsinhaber erneut registrieren“ auf der Vorlage) oder warten Sie die reguläre Erneuerung ab, wenn sie in Ihr Zeitfenster fällt.
• Offline-Vorlagen für die Authentifizierung: Verlagern Sie den Anwendungsfall nach Möglichkeit auf eine Online-Vorlage. Andernfalls fügen Sie pro Zertifikat eine starke explizite Zuordnung hinzu oder nehmen die SID bei der Anforderung als URL in den SAN auf.
• Schwache explizite Zuordnungen: Ersetzen Sie sie durch X509IssuerSerialNumber. Die Seriennummer muss in umgekehrter Bytereihenfolge geschrieben werden, verglichen mit der Anzeige in Zertifikatbetrachtern — der häufigste Grund, warum eine neue Zuordnung mit Ereignis 39 scheitert.

# Eine IssuerSerialNumber-Zuordnung aus einer Zertifikatdatei erstellen
$cert   = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new('C:\temp\jdoe-card.cer')
$bytes  = $cert.GetSerialNumber()          # bereits Little-Endian (umgekehrt)
$serial = -join ($bytes | ForEach-Object { $_.ToString('x2') })
# Die Beispiele in KB5014754 führen die Aussteller-RDNs in umgekehrter Reihenfolge auf (DC=... zuerst)
$rdns   = $cert.Issuer -split ',\s*(?=\w+=)'
[array]::Reverse($rdns)
$issuer = $rdns -join ','
$map    = "X509:<I>$issuer<SR>$serial"
$map    # vor dem Schreiben prüfen
# Set-ADUser jdoe -Add @{ altSecurityIdentities = $map }

Testen Sie die resultierende Zeichenfolge an einem einzelnen Konto, bevor Sie sie per Skript auf Hunderte anwenden; das Format des Aussteller-DN muss dem entsprechen, was das KDC vergleicht, und der KB-Artikel enthält ausgearbeitete Beispiele.

• Intune und Drittanbieter-CAs: Nehmen Sie die SID als URI in den SAN auf (tag:microsoft.com,2022-09-14:sid:<SID>); verwenden Sie in Intune-PKCS- und -SCEP-Profilen die Variable für die lokale SID. Für Drittanbieter-CAs ohne diese Möglichkeit verwenden Sie explizite starke Zuordnungen oder übernehmen die KB5014754-Anleitung des Herstellers.
• Neu angelegte Konten (Ereignis 41): Das alte Zertifikat trägt die alte SID. Widerrufen Sie es und registrieren Sie ein neues für das neue Konto.

Überprüfen

Nach den Korrekturen sollte die Ereignisabfrage aus dem Schritt „Messen“ für die Ereignisse 39 und 40 gegen null gehen, und verbleibende 41-Ereignisse sollten einzeln untersucht werden. Prüfen Sie, dass Schannel auf Servern nicht gelockert wurde:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel' `
    -Name CertificateMappingMethods -ErrorAction SilentlyContinue

Erwartet wird: nicht vorhanden oder 0x18. Bestätigen Sie auf der CA, dass neu ausgestellte Authentifizierungszertifikate die OID 1.3.6.1.4.1.311.25.2 enthalten, indem Sie eines mit certutil -dump <file>.cer ausgeben. Nehmen Sie die Ereignisse 39, 40 und 41 dauerhaft in Ihre DC-Überwachung auf, wie in der Referenz der AD-Ereignis-IDs beschrieben: Nach der Erzwingung ist eine Häufung von 41-Ereignissen ein Signal, kein Rauschen.

Was dabei ausfallen kann

• Smartcards aus Kartenverwaltungssystemen von Drittanbietern mit reinen UPN-Zertifikaten können sich nicht mehr anmelden, bis jede Karte eine starke Zuordnung hat oder neu ausgestellt wurde.
• 802.1X und VPN mit Computer- oder Benutzerzertifikaten über NPS scheitern bei Zertifikaten aus Offline-Vorlagen oder von Nicht-Microsoft-CAs ohne SID. WLAN-Ausfälle nach der Erzwingung sind die häufigste Beschwerde.
• Gesamtstrukturübergreifende Zertifikatanmeldung, die auf Namenszuordnung beruht, benötigt explizite starke Zuordnungen in der Ressourcen-Gesamtstruktur.
• Gelöschte und mit gleichem Namen neu angelegte Konten können keine Zertifikate verwenden, die für das alte Objekt ausgestellt wurden (Ereignis 41).
• Legacy-Geräte und Appliances, die sich mit Clientzertifikaten über schwache Schannel-Zuordnung bei LDAPS oder IIS authentifizieren, scheitern, sobald CertificateMappingMethods wieder auf dem sicheren Standard steht.

Weiterführend: der Themenbereich AD-Zertifikatdienste, Kerberos-Härtung für die übrigen Maßnahmen auf KDC-Seite und Machine Account Quota, das die bequeme Quelle angreiferkontrollierter Computerkonten beseitigt, auf die Certifried angewiesen war.