Mappage de certificat faible dans AD CS

Qu'est-ce qu'un mappage de certificat faible ?

Le mappage de certificat faible est un risque d'authentification par certificat dans Active Directory, où un certificat peut être associé à un compte via des données de nom réutilisables plutôt que via une liaison de compte forte et non réutilisable. En termes AD CS concrets, le problème apparaît lorsque l'authentification Kerberos par certificat ou l'authentification par certificat client Schannel accepte des mappages basés sur des noms tels que l'UPN, le nom DNS, l'adresse e-mail, le nom de sujet, ou l'émetteur et le nom de sujet combinés.

Le risque n'est pas que les certificats soient intrinsèquement dangereux. L'authentification par certificat est une fonctionnalité d'identité Windows légitime. Le risque est que les mappages basés sur des noms peuvent être ambigus ou réutilisables, en particulier lorsque les certificats, noms de comptes, UPN, noms alternatifs de sujet ou mappages hérités ne lient pas de façon unique le certificat au compte visé. Microsoft a traité cette classe de problèmes via des changements d'authentification par certificat sur les contrôleurs de domaine Windows, incluant l'application du mappage de certificat fort et des événements d'audit pour les certificats non compatibles avec le mode Full Enforcement.

Cet article se concentre sur le comportement de mappage de certificat documenté par Microsoft : la force du mappage KDC Kerberos, altSecurityIdentities, StrongCertificateBindingEnforcement, les CertificateMappingMethods de Schannel, et les événements opérationnels qui révèlent des mappages faibles ou échoués. Il ne traite pas tous les problèmes AD CS comme un seul et même sujet. Les erreurs de configuration de modèle comme l'enregistrement SAN arbitraire sont liées, mais le mappage de certificat faible concerne spécifiquement la façon dont le certificat est lié à un compte pendant l'authentification.

Pour la surface d'attaque AD CS plus large, voir Attaques de certificats ADCS : comment ESC1 à ESC8 mènent à Domain Admin. Pour un chemin d'authentification par clé lié mais distinct, voir Shadow Credentials : abus de msDS-KeyCredentialLink dans Active Directory.

Comment fonctionne le mappage de certificat

Ouverture de session Kerberos par certificat

Dans l'authentification Kerberos par certificat, le centre de distribution de clés (KDC) reçoit une demande d'authentification par certificat et doit déterminer quel compte le certificat représente. La documentation Microsoft PKCA définit la force du mappage de certificat et classe les méthodes de mappage comme faibles ou fortes. Les mappages faibles dépendent de données de nom. Les mappages forts dépendent d'identifiants plus difficiles à réutiliser ou directement liés au compte.

Microsoft liste des mappages KDC faibles tels que SAN UPNName, SAN DNSName, altSecurityIdentities émetteur et sujet, altSecurityIdentities sujet seul, et le champ 822 d'altSecurityIdentities. Microsoft liste des mappages forts tels que le SID, Key Trust, altSecurityIdentities émetteur et numéro de série, l'identifiant de clé de sujet, le hash SHA1 de la clé publique, et émetteur et SID. La différence opérationnelle est directe : si le KDC mappe un certificat via une méthode faible, il doit continuer à chercher un mappage plus fort et peut échouer la demande d'authentification s'il n'en trouve pas.

Cette distinction explique pourquoi la liaison forte compte. Un certificat qui contient un nom réutilisable n'est pas aussi fort qu'un certificat qui porte une extension SID ou qui est explicitement mappé via émetteur et numéro de série, SKI, ou hash SHA1 de clé publique. Le travail du défenseur est de supprimer les mappages faibles évitables et de s'assurer que l'authentification par certificat réussit uniquement via des mappages forts.

Mappage de certificat client Schannel

Kerberos n'est pas le seul composant Windows qui mappe des certificats à des comptes. Microsoft documente que Schannel peut mapper un certificat client fourni à une application serveur vers un compte utilisateur Windows. La valeur de registre CertificateMappingMethods contrôle quelles méthodes de mappage Schannel peut utiliser. Microsoft indique que les mappages Sujet/Émetteur, Émetteur, et UPN sont faibles et désactivés par défaut dans le comportement mis à jour, tandis que S4U2Self et S4U2Self explicite sont forts.

Cela compte car l'authentification par certificat peut apparaître à plusieurs endroits : ouverture de session par carte à puce, PKINIT, authentification TLS client, applications web héritées, portails VPN, flux NPS/RADIUS, et services d'administration internes. Un domaine peut avoir un KDC durci pendant qu'un chemin applicatif dépend encore d'un mappage Schannel faible. Traitez Kerberos et Schannel comme des surfaces de contrôle liées mais distinctes.

Le rôle des modèles AD CS

Les modèles de certificat AD CS influencent quels certificats peuvent être émis et quelles données d'identité ils contiennent. La documentation Microsoft Defender for Identity décrit des modèles de certificat risqués où les utilisateurs peuvent demander des certificats valides pour des utilisateurs arbitraires selon les paramètres du modèle. Elle pointe spécifiquement l'option Supply in the request, les EKU d'authentification comme Client Authentication ou Smartcard Logon, les permissions d'enregistrement trop permissives, l'absence d'approbation par un gestionnaire, et les modèles publiés par une AC.

L'abus de modèle et le mappage faible ne sont pas identiques. Un problème de modèle contrôle si un utilisateur peut obtenir un certificat avec des revendications d'identité dangereuses. Un problème de mappage contrôle si le domaine ou l'application accepte ce certificat comme un compte spécifique. Dans les environnements réels, les deux problèmes se combinent souvent : un modèle laisse un utilisateur non privilégié demander un certificat avec des données d'identité contrôlées par l'attaquant, et un mappage faible laisse ces données se résoudre vers un compte privilégié.

Pourquoi le mappage faible compte encore après les changements d'application de Microsoft

Le KB5014754 de Microsoft documente les changements d'authentification par certificat pour les contrôleurs de domaine Windows. Ces changements traitent des vulnérabilités d'élévation de privilèges pouvant survenir lorsque le KDC Kerberos sert des demandes d'authentification par certificat. Microsoft explique qu'avant la mise à jour de sécurité du 10 mai 2022, l'authentification par certificat ne tenait pas compte d'un signe dollar en fin de nom de machine, et que des conflits entre UPN et sAMAccountName introduisaient des vulnérabilités d'usurpation.

Les dates opérationnelles importantes sont déjà passées. Microsoft a documenté que les contrôleurs de domaine sont passés en mode Full Enforcement avec la mise à jour de sécurité Windows de février 2025, sauf si les administrateurs avaient déjà configuré la clé de registre StrongCertificateBindingEnforcement. Microsoft a également documenté qu'après la mise à jour de sécurité Windows du 9 septembre 2025, cette clé de registre ne serait plus prise en charge. En mode Full Enforcement, si un certificat ne peut pas être mappé fortement, l'authentification est refusée.

Cela ne rend pas le sujet obsolète. Cela change ce que les défenseurs doivent auditer. Dans un environnement patché, les dépendances de mappage faible deviennent des ruptures opérationnelles, de la dette de sécurité, ou le signe que quelqu'un a conservé des paramètres de compatibilité qui devraient être supprimés. Dans des environnements moins homogènes, des niveaux de patch de contrôleurs de domaine mixtes, l'usage de certificats client hérités, des applications basées sur Schannel, des déploiements d'AC non-Microsoft, et des mappages manuels altSecurityIdentities peuvent encore créer une exposition réelle.

Un audit mature devrait répondre à trois questions :

Tous les contrôleurs de domaine et serveurs AD CS sont-ils patchés avec les mises à jour de sécurité Microsoft pertinentes ?
Les ouvertures de session par certificat réussissent-elles via des mappages forts plutôt que des mappages faibles basés sur des noms ?
Des applications ou contrôleurs de domaine dépendent-ils encore d'un comportement de compatibilité, de méthodes Schannel faibles, ou de mappages manuels hérités ?

La chaîne d'attaque

Un modèle défensif sûr de chaîne d'attaque ressemble à ceci :

Étape	Ce qui se passe	Ce que les défenseurs doivent vérifier
1. Opportunité d'émission de certificat	Un modèle, un paramètre d'AC, ou un chemin d'enregistrement permet à un utilisateur d'obtenir un certificat avec des données d'identité pouvant influencer l'authentification.	Examiner les EKU d'authentification, `Supply in the request`, les permissions d'enregistrement, l'approbation par un gestionnaire, les signatures autorisées, et si le modèle est publié.
2. Mappage de compte faible	Le certificat se mappe à un compte via des données de nom réutilisables ou un mappage `altSecurityIdentities` hérité plutôt qu'une liaison de compte forte.	Inventorier les méthodes de mappage faible, les mappages manuels, les paramètres Schannel, et les événements d'audit KDC.
3. Authentification par certificat	Le certificat est présenté pour PKINIT Kerberos, ouverture de session par carte à puce, ou un chemin d'authentification client Schannel.	Corréler les événements KDC, le comportement Schannel, l'émission par l'AC, et la sensibilité du compte cible.
4. Impact sur les privilèges	Le compte mappé est privilégié, possède des droits de mouvement latéral, ou peut atteindre des services sensibles.	Examiner les comptes privilégiés, l'accès aux services, et l'utilisation en aval après authentification par certificat.
5. Risque de persistance ou de rejeu	Le certificat reste valide jusqu'à expiration ou révocation, même en cas de réinitialisation de mot de passe.	Révoquer les certificats si nécessaire, supprimer les mappages faibles, et vérifier la liaison forte après nettoyage.

L'article évite intentionnellement la syntaxe d'outils offensifs. L'échec technique est clair sans chemin d'exploitation prêt à copier-coller : un certificat est émis ou accepté avec des données d'identité qui ne devraient pas suffire à représenter le compte cible.

Ce chemin se situe à côté d'autres chemins d'escalade Active Directory. Pour les chemins de permissions d'objet, voir Abus d'ACL et DCSync : les chemins silencieux vers Domain Admin. Pour une persistance Kerberos qui ne dépend pas de certificats, comparez Attaque Golden Ticket : les clés de votre royaume et Attaque Silver Ticket : tickets de service Kerberos forgés dans Active Directory.

Détection

La détection du mappage de certificat faible est un problème de corrélation. Un seul événement peut montrer un mappage de certificat faible ou échoué, mais il n'explique pas à lui seul comment le certificat a été émis, si le compte est privilégié, ou si un chemin applicatif hérité dépend encore d'un comportement faible.

Signal	Source	Ce qu'il faut chercher	Limitation
Événements de mappage faible ou échoué du KDC	Journal Système du contrôleur de domaine après les mises à jour pertinentes	Événements documentés par le KB5014754 pour les certificats sans mappage fort ou échouant aux critères Full Enforcement.	Nécessite des contrôleurs de domaine à jour et des tentatives d'authentification par certificat pertinentes.
Émission de certificat vers des identités sensibles	Journaux de sécurité de l'AC AD CS	Certificats émis avec des EKU d'authentification, l'identité du demandeur, le nom du modèle, les données SAN ou de sujet si journalisées.	La journalisation de l'AC doit être activée et conservée ; l'émission seule ne prouve pas une authentification réussie.
Valeurs `altSecurityIdentities` faibles	Inventaire Active Directory	Mappages manuels basés sur des noms tels qu'émetteur/sujet, sujet seul, ou mappages de type RFC822/e-mail.	Le mappage manuel peut être une logique métier héritée ; à valider avant suppression.
Configuration de mappage faible Schannel	Registre du contrôleur de domaine et comportement applicatif	Valeurs `CertificateMappingMethods` réactivant des méthodes de mappage faibles.	Les échecs Schannel peuvent affecter des applications ; tester avant de modifier des paramètres de production.
Risque de modèle	Revue de modèle AD CS ou évaluation Defender for Identity	`Supply in the request`, EKU d'authentification, permissions d'enregistrement larges, absence d'approbation, modèles publiés.	Le risque de modèle et le risque de mappage sont liés mais pas identiques.

Événements KDC et signaux Full Enforcement

Le KB5014754 de Microsoft a ajouté des événements d'audit pour identifier les certificats non compatibles avec le mode Full Enforcement. Il documente également qu'en mode Full Enforcement, l'authentification est refusée si un certificat ne peut pas être mappé fortement. Les contrôleurs de domaine qui journalisent ces événements vous indiquent soit qu'une tentative d'authentification par certificat est incompatible avec la liaison forte, soit qu'un mappage de certificat hérité existe encore dans un chemin que vous devez comprendre.

Ne traitez pas ces événements comme du bruit. Un avertissement de mappage faible peut être un problème de compatibilité métier, une tâche de migration, ou une investigation de sécurité. Priorisez les événements impliquant des utilisateurs privilégiés, des comptes de service, des contrôleurs de domaine, des postes d'administration, des services VPN/NPS, et des certificats émis par des modèles autorisant l'authentification.

Télémétrie d'émission et de modèle AD CS

La télémétrie d'émission AD CS répond à une question différente : d'où vient le certificat ? Examinez les journaux de l'AC pour les certificats émis, les demandes refusées, les noms de modèles, les comptes demandeurs, et les propriétés de certificat. Lorsque l'audit des services de certification est activé, des événements comme 4886, 4887, 4888, 4870, 4871, 4872, 4891, 4892, et 4898 fournissent une télémétrie concrète de demande, émission, refus, révocation, publication de CRL, changement de configuration, et chargement de modèle. Associez cela à la configuration du modèle : EKU d'authentification, sujet ou SAN fourni par le demandeur, permissions d'enregistrement, exigences d'approbation, signatures autorisées, et si le modèle est publié sur une AC.

Les évaluations de posture de sécurité Microsoft Defender for Identity peuvent aider à identifier les modèles permettant aux utilisateurs de demander des certificats valides pour des utilisateurs arbitraires, et les modèles exposés via les conditions CVE-2024-49019. Defender for Identity recommande spécifiquement de supprimer les permissions d'enregistrement non privilégiées, de désactiver Supply in the request, d'appliquer les correctifs pertinents pour les serveurs AD CS vulnérables, et d'utiliser des mitigations comme l'approbation par un gestionnaire ou les exigences de signature le cas échéant.

Inventaire des mappages manuels

Inventoriez altSecurityIdentities sur les utilisateurs, comptes privilégiés, et comptes de service. Microsoft documente plusieurs valeurs prises en charge et classe les mappages selon leur force. Les faibles sont basés sur des noms. Les forts utilisent émetteur et numéro de série, SKI, hash SHA1 de clé publique, mappage lié au SID, ou Key Trust.

Soyez prudent lors du nettoyage. Un mappage faible sur un utilisateur hérité à faible risque peut être une dépendance opérationnelle, alors qu'un mappage faible sur un compte privilégié est un constat à bien plus haut risque. Le plan de remédiation doit remplacer les mappages faibles par des mappages forts, pas simplement supprimer des chemins d'authentification de production sans migration.

Pour une couverture de journaux plus large autour de l'activité du contrôleur de domaine et des objets AD, associez cet article à Supervision Active Directory : les identifiants d'événements de sécurité qui comptent.

Remédiation

La remédiation doit traiter à la fois l'émission de certificat et le mappage de certificat. Ne corriger qu'un seul côté laisse des failles. Un plan sûr supprime les mappages faibles inutiles, met à jour les pratiques d'émission de certificat, valide l'application au niveau des contrôleurs de domaine, et teste les chemins applicatifs qui dépendent de certificats clients.

Appliquer la liaison de certificat forte

Commencez par les contrôleurs de domaine. Assurez-vous que tous les contrôleurs de domaine servant l'authentification par certificat sont patchés avec les mises à jour Microsoft pertinentes. Dans les environnements modernes patchés, Full Enforcement est l'état attendu. Si un contrôleur de domaine a encore une configuration de compatibilité ou un chemin d'exception, documentez pourquoi il existe, quels certificats en dépendent, et le plan de retrait exact.

⚠️

⚠️ Attention : les directives de Microsoft sont claires — le mode Full Enforcement refuse l'authentification lorsqu'un certificat échoue aux critères de mappage fort. Microsoft indique aussi que les méthodes Schannel faibles sont désactivées par défaut dans le comportement mis à jour, et que remettre CertificateMappingMethods à l'ancienne valeur large revient à réactiver des méthodes de mappage de certificat faibles. Traitez ce changement de registre comme une exception de compatibilité, pas comme un état de durcissement normal.

Remplacer les mappages faibles

Pour les mappages manuels dans altSecurityIdentities, remplacez les mappages faibles par des mappages forts lorsque l'activité a encore besoin d'un mappage explicite. Microsoft recommande des mappages forts comme émetteur et numéro de série lorsque les certificats ne peuvent pas être réémis avec la nouvelle extension SID. D'autres options de mappage fort incluent SKI et le hash SHA1 de clé publique selon la documentation Microsoft sur la force de mappage.

Ne laissez pas de comptes privilégiés mappés via des noms réutilisables. Les administrateurs de domaine, administrateurs de certificats, agents d'enregistrement, comptes de service, identités de secours (break-glass), et utilisateurs de postes d'administration ne devraient pas dépendre d'une liaison d'identité faible. Si un flux de certificat privilégié existe, il devrait utiliser un mappage fort, une émission documentée, des durées de vie de certificat courtes le cas échéant, et une surveillance explicite.

Corriger les modèles de certificat et les paramètres d'AC

Examinez les modèles pouvant émettre des certificats capables d'authentification. Les recommandations Microsoft Defender for Identity mettent en avant plusieurs mitigations concrètes pour les modèles permettant des demandes de certificat pour des utilisateurs arbitraires : désactiver Supply in the request, retirer les EKU permettant l'authentification utilisateur quand ce n'est pas nécessaire, retirer les permissions d'enregistrement trop permissives, exiger l'approbation d'un gestionnaire, exiger des signatures autorisées, ou dépublier les modèles des AC s'ils ne sont pas nécessaires.

Examinez également les paramètres au niveau de l'AC comme EDITF_ATTRIBUTESUBJECTALTNAME2. Microsoft Defender for Identity indique que si ce drapeau est activé et qu'un modèle est valide pour l'authentification, un attaquant peut enregistrer un certificat capable d'usurper des comptes arbitraires. Ce n'est pas la même chose qu'un mappage faible, mais cela affecte directement si des revendications d'identité dangereuses peuvent apparaître dans les certificats émis.

Tester les dépendances Schannel et applicatives

Avant de modifier les paramètres de mappage Schannel, identifiez les applications utilisant l'authentification par certificat client : applications IIS, VPN, NPS/RADIUS, portails d'administration internes, flux d'authentification d'appareil, et middleware hérité. Testez-les avec des chemins de mappage forts. Si un service tombe en panne uniquement lorsque le mappage faible est désactivé, la correction n'est pas de préserver indéfiniment le mappage faible. La correction est de mettre à jour l'émission de certificat et le mappage de compte pour que le service s'authentifie via une liaison forte.

Révoquer et réémettre si nécessaire

Si des certificats suspects ont été émis ou mappés faiblement, révoquez les certificats concernés, publiez des CRL mises à jour le cas échéant, et validez que les systèmes dépendants vérifient la révocation. Réémettez des certificats prenant en charge le mappage fort ou avec un mappage manuel fort explicite. Si le compte a été utilisé après authentification par certificat, traitez l'investigation comme une compromission d'identité : examinez les changements de groupe, l'accès aux services, le mouvement latéral, et les actions administratives en aval.

Validation après durcissement

La validation doit prouver que l'authentification fonctionne toujours pour les utilisateurs légitimes et échoue pour les certificats faiblement liés.

Étape de validation	Critère de succès
Revue des correctifs des contrôleurs de domaine	Tous les contrôleurs de domaine servant l'authentification par certificat sont à jour et fonctionnent dans l'état d'application attendu.
Revue des événements KDC	Aucun avertissement récurrent de mappage faible ne subsiste pour les flux d'authentification légitimes après migration.
Test de mappage fort	Les ouvertures de session par certificat utilisateur et machine réussissent via l'extension SID, Key Trust, ou des mappages forts explicites.
Test de mappage faible	Les certificats ne se mappant que via des méthodes faibles basées sur des noms échouent dans les conditions d'application.
Revue des modèles	Les modèles capables d'authentification ne permettent pas de revendications d'identité arbitraires sans contrôles compensatoires.
Revue Schannel	Les applications utilisant des certificats clients ne dépendent pas des méthodes de mappage faibles Sujet/Émetteur, Émetteur, ou UPN.
Validation d'incident	Les certificats révoqués ou remplacés ne s'authentifient plus, et l'activité du compte en aval a été examinée.

Exécutez la validation par phases. Commencez par une UO de test ou un groupe de services représentatif, puis étendez aux utilisateurs privilégiés, postes d'administration, VPN/NPS, utilisateurs de carte à puce, comptes de service, et scénarios de certificat machine. Ne présumez pas qu'un test de carte à puce réussi valide chaque chemin d'authentification par certificat du domaine.

Comment EtcSec détecte cette exposition

EtcSec devrait traiter le mappage de certificat faible comme une exposition de liaison d'identité de certificat, pas seulement comme un problème de modèle AD CS. Les signaux liés incluent les mappages altSecurityIdentities faibles ou hérités, les modèles de certificat émettant des certificats capables d'authentification avec un contrôle de sujet dangereux, les permissions d'enregistrement trop larges, les paramètres d'AC autorisant des SAN fournis par la demande, et les paramètres de compatibilité du contrôleur de domaine préservant un comportement de mappage faible.

La plateforme peut aussi relier cette exposition à des chemins d'attaque adjacents : modèles AD CS autorisant des identités arbitraires, principaux pouvant modifier les ACL de modèle de certificat, utilisateurs privilégiés dépendant de mappages de certificat faibles, et surveillance manquante du contrôleur de domaine pour les événements d'authentification par certificat. C'est la vue opérationnelle utile. Un mappage faible est dangereux car il se situe entre l'émission de certificat et l'authentification de compte.

Contrôles associés

Contrôle	Pourquoi c'est important
Full Enforcement pour l'authentification par certificat	Refuse l'authentification lorsque le certificat ne peut pas être fortement mappé.
Chemins de liaison de certificat forte	Remplace les mappages basés sur des noms réutilisables par des mappages manuels `altSecurityIdentities` forts comme émetteur/numéro de série, SKI, ou hash SHA1 de clé publique, ou par d'autres chemins forts comme l'extension SID, Key Trust, ou émetteur/SID.
Durcissement des modèles AD CS	Empêche les utilisateurs non fiables d'obtenir des certificats capables d'authentification pour des identités arbitraires.
Revue du mappage Schannel	Trouve les chemins applicatifs qui dépendent encore d'un mappage de certificat faible.
Surveillance de l'émission par l'AC	Montre quels certificats ont été émis, à qui, depuis quel modèle, et avec quelles données d'identité.
Revue des certificats des comptes privilégiés	S'assure que les administrateurs et comptes de service sensibles ne dépendent pas d'une liaison d'identité faible.
Validation de révocation	Confirme que les certificats suspects ou remplacés ne s'authentifient plus.

Le mappage de certificat faible n'est pas une case à cocher isolée. Il fait partie de la sécurité AD CS, de l'authentification Kerberos, du cycle de vie des comptes, et de l'authentification applicative. Si vous construisez une revue complète, associez cet article avec Comment auditer la sécurité Active Directory : checklist pratique pour les équipes internes et Attaques de délégation Kerberos : de la délégation non contrainte à l'abus RBCD pour comprendre les chemins d'identité adjacents.

Mappage de certificat faible dans AD CS : pourquoi la liaison forte compte