Mappage fort des certificats (KB5014754) en pratique

Avant mai 2022, un contrôleur de domaine mappait un certificat à un compte principalement par son nom : l'UPN dans le Subject Alternative Name pour les certificats utilisateur, le nom DNS pour les certificats d'ordinateur. Le contenu du certificat était donc la seule chose qui séparait un demandeur de n'importe quelle identité dont il parvenait à faire figurer le nom sur un certificat. CVE-2022-26923 (« Certifried ») a montré à quel point il en fallait peu : un utilisateur capable de créer un compte d'ordinateur pouvait définir son dNSHostName sur le nom d'un contrôleur de domaine et obtenir un certificat mappé sur le DC. KB5014754 est la correction de Microsoft. Elle oblige le KDC et Schannel à exiger une liaison forte entre certificat et compte, et elle est appliquée strictement depuis 2025.

Ce guide explique ce que « fort » signifie en pratique, comment trouver les certificats et mappages qui ne satisfont pas cette exigence, comment corriger chaque catégorie et ce que l'application stricte casse. Il suppose que vos modèles sont déjà assainis, comme décrit dans auditer les modèles de certificats et le pilier de durcissement AD CS.

Comment fonctionne le mappage fort

En mode Full Enforcement, le KDC n'accepte un certificat pour PKINIT que si l'un des éléments suivants le lie au compte :

1. L'extension de sécurité SID (szOID_NTDS_CA_SECURITY_EXT, OID 1.3.6.1.4.1.311.25.2). Les AC d'entreprise dotées de la mise à jour de mai 2022 ou ultérieure écrivent le SID du demandeur dans cette extension pour les modèles en ligne, où le sujet est construit à partir d'Active Directory.
2. Un mappage explicite fort dans l'attribut altSecurityIdentities du compte : X509IssuerSerialNumber, X509SKI ou X509SHA1PublicKey.
3. Un SID dans le SAN sous forme d'URL tag:microsoft.com,2022-09-14:sid:<SID>, ajouté par des mises à jour ultérieures de KB5014754 pour les certificats qui ne peuvent pas porter l'extension. Vérifiez que le niveau de mise à jour de vos DC le prend en charge avant de vous y fier.

Le comportement du KDC était contrôlé par StrongCertificateBindingEnforcement sous HKLM\SYSTEM\CurrentControlSet\Services\Kdc :

Calendrier, selon KB5014754 : le 10 mai 2022 a introduit l'extension SID et le mode Compatibility avec des événements d'audit ; février 2025 a fait de Full Enforcement la valeur par défaut tout en respectant encore une valeur explicite de 1 ; septembre 2025 a supprimé le mode Compatibility, de sorte que les DC actuels appliquent strictement quelle que soit la valeur du registre. Si cette valeur figure encore dans votre base de référence, c'est un vestige historique, pas un contrôle. La valeur CertificateBackdatingCompensation, qui ajustait la vérification « certificat plus ancien que le compte » en mode Compatibility, est elle aussi sans objet une fois l'application stricte permanente.

Schannel (authentification TLS par certificat client auprès d'IIS, de LDAPS et d'autres) dispose de son propre paramètre, CertificateMappingMethods sous HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel. La mise à jour a changé sa valeur par défaut en 0x18 (mappage basé sur S4U2Self), ce qui fait passer Schannel par les mêmes vérifications KDC. Le remettre à 0x1F réactive le mappage faible par UPN et par sujet et doit être traité comme un constat d'audit.

Mesurer : événements KDC 39, 40 et 41

Chaque DC journalise les problèmes de mappage de certificats dans le journal System, sous le fournisseur Kerberos Key Distribution Center :

• 39 : un certificat était valide mais n'a pas pu être fortement mappé. Avertissement en mode Compatibility, refus en Full Enforcement.
• 40 : le certificat a été émis avant la création du compte et aucun mappage fort n'existe. Refusé.
• 41 : l'extension SID du certificat ne correspond pas au SID du compte. Refusé, et à examiner : soit le compte a été recréé, soit quelqu'un présente un certificat émis pour un autre principal.

Collectez-les sur tous les DC :

$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

La première propriété de chaque événement est le nom du compte. Regrouper par ID d'événement et par compte transforme des milliers d'événements en une courte liste d'identités en échec. Lisez un événement complet par groupe : le message inclut le sujet, l'émetteur et le numéro de série du certificat, ce qui indique l'AC et le modèle qui l'ont produit.

Auditer : les certificats sans extension SID

Pour les certificats AD CS, la question est de savoir quels modèles émettent des certificats sans l'extension. Trois causes couvrent presque tous les cas :

• Les modèles hors ligne (« Supply in the request ») : l'AC ne peut pas savoir à quel compte le sujet se rapporte, elle n'ajoute donc pas le SID.
• CT_FLAG_NO_SECURITY_EXTENSION (0x80000 dans msPKI-Enrollment-Flag) sur le modèle, qui supprime l'extension. Combiné à un mappage faible, c'était la classe ESC9.
• L'extension désactivée pour toute l'AC via DisableExtensionList, ce qui la supprime pour tous les modèles (la classe ESC16).

# Modèles qui suppriment l'extension SID
$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

# Suppression au niveau de l'AC (à exécuter sur chaque AC) : 1.3.6.1.4.1.311.25.2 ne doit pas figurer dans la liste
certutil -config "ca01.corp.example\CORP-Issuing-CA" -getreg policy\DisableExtensionList

Pour inspecter un certificat sur un client, examinez directement ses extensions :

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' }) }}

Auditer : altSecurityIdentities

Les mappages explicites sont courants pour les cartes à puce émises par des systèmes de gestion de cartes tiers, pour l'ouverture de session par certificat entre forêts et pour les comptes de service qui s'authentifient par certificat. Classez-les :

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

Auditez aussi qui peut écrire cet attribut. Un accès en écriture à altSecurityIdentities sur un compte privilégié permet à un attaquant d'y mapper son propre certificat : c'est la classe ESC14. Incluez l'attribut dans votre revue des ACL AD, et assurez-vous que les comptes Tier 0 sont protégés par AdminSDHolder afin qu'aucune ACE déléguée ne puisse y subsister.

Imposer : corriger chaque catégorie

• Modèles AD CS en ligne : déjà forts dès que les AC disposent de la mise à jour de mai 2022, tant qu'aucun des deux drapeaux de suppression n'est positionné. Retirez CT_FLAG_NO_SECURITY_EXTENSION des modèles, et retirez l'OID de DisableExtensionList avec certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2, suivi d'un redémarrage du service de l'AC. Réémettez ensuite : les certificats existants n'acquièrent pas l'extension ; déclenchez donc le renouvellement via l'inscription automatique (« Reenroll All Certificate Holders » sur le modèle) ou attendez le renouvellement naturel s'il tombe dans votre fenêtre.
• Modèles hors ligne utilisés pour l'authentification : basculez le cas d'usage vers un modèle en ligne lorsque c'est possible. Sinon, ajoutez un mappage explicite fort par certificat, ou placez le SID dans l'URL du SAN au moment de la demande.
• Mappages explicites faibles : remplacez-les par X509IssuerSerialNumber. Le numéro de série doit être écrit dans l'ordre d'octets inversé par rapport à l'affichage des visionneuses de certificats : c'est la raison la plus courante pour laquelle un nouveau mappage échoue avec l'événement 39.

# Construire un mappage IssuerSerialNumber à partir d'un fichier de certificat
$cert   = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new('C:\temp\jdoe-card.cer')
$bytes  = $cert.GetSerialNumber()          # déjà en little-endian (inversé)
$serial = -join ($bytes | ForEach-Object { $_.ToString('x2') })
# Les exemples de KB5014754 listent les RDN de l'émetteur dans l'ordre inverse (DC=... en premier)
$rdns   = $cert.Issuer -split ',\s*(?=\w+=)'
[array]::Reverse($rdns)
$issuer = $rdns -join ','
$map    = "X509:<I>$issuer<SR>$serial"
$map    # à relire avant écriture
# Set-ADUser jdoe -Add @{ altSecurityIdentities = $map }

Testez la chaîne obtenue sur un seul compte avant de l'automatiser sur des centaines ; le format du DN de l'émetteur doit correspondre à ce que compare le KDC, et le KB contient des exemples détaillés.

• Intune et AC tierces : ajoutez le SID au SAN sous forme d'URI (tag:microsoft.com,2022-09-14:sid:<SID>) ; dans les profils PKCS et SCEP d'Intune, utilisez la variable de SID local. Pour les AC tierces sans cette capacité, utilisez des mappages explicites forts ou reprenez les recommandations KB5014754 de l'éditeur.
• Comptes recréés (événement 41) : l'ancien certificat porte l'ancien SID. Révoquez-le et inscrivez un nouveau certificat pour le nouveau compte.

Vérifier

Après les corrections, la requête d'événements de l'étape Mesurer doit tendre vers zéro pour les événements 39 et 40, et chaque événement 41 restant doit être examiné individuellement. Vérifiez que Schannel n'a pas été assoupli sur les serveurs :

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

Une valeur absente ou égale à 0x18 est attendue. Sur l'AC, vérifiez que les certificats d'authentification nouvellement émis contiennent l'OID 1.3.6.1.4.1.311.25.2 en en exportant un avec certutil -dump <file>.cer. Ajoutez définitivement les événements 39, 40 et 41 à la supervision de vos DC, comme décrit dans la référence des ID d'événements AD : après l'application stricte, une rafale d'événements 41 est un signal, pas du bruit.

Ce qui casse

• Les cartes à puce issues de systèmes de gestion de cartes tiers avec des certificats uniquement basés sur l'UPN ne permettent plus d'ouvrir de session tant que chaque carte n'a pas de mappage fort ou n'a pas été réémise.
• 802.1X et VPN utilisant des certificats machine ou utilisateur via NPS échouent pour les certificats issus de modèles hors ligne ou d'AC non Microsoft sans SID. Les pannes du Wi-Fi après l'application stricte sont la plainte la plus fréquente.
• L'ouverture de session par certificat entre forêts reposant sur le mappage par nom nécessite des mappages explicites forts dans la forêt de ressources.
• Les comptes supprimés puis recréés avec le même nom ne peuvent pas utiliser les certificats émis pour l'ancien objet (événement 41).
• Les équipements et appliances hérités qui s'authentifient auprès de LDAPS ou d'IIS avec des certificats clients via un mappage Schannel faible échouent lorsque CertificateMappingMethods revient à la valeur par défaut sécurisée.

Pour aller plus loin : le thème Services de certificats AD, Durcissement de Kerberos pour les autres contrôles côté KDC, et le quota de comptes machine, qui supprime la source facile de comptes d'ordinateur contrôlés par l'attaquant sur laquelle reposait Certifried.