AD CS et le Mappage de certificats – MAJ du 11 février 2025

Sommaire

Introduction

Le mappage de certificats ADCS permet qu’un compte (utilisateur ou ordinateur) de l’Active Directory (AD) s’authentifie à l’aide d’un certificat et de la clé privée associée. Ce dernier doit référencer le compte utilisé afin que le Key Distribution Center (KDC) puisse valider et permettre l’authentification. Ainsi, l’extension PKINIT (Public Key Cryptography for Initial Authentication) du protocole Kerberos permettra de réaliser une authentification basée sur les informations contenues dans le certificat. Le mot Mappage correspond ainsi à la façon dont le certificat est relié au compte de l’Active Directory.

Il existe deux types de mappage de certificats : Le mappage implicite et le mappage explicite.

Le mappage Implicite est réalisé à partir de l’User Principal Name (UPN) du compte utilisateur, ou à partir du DNSHostName¹ du compte ordinateur. Cette information sera indiquée dans le Subject AlternativeName (SAN) d’un certificat ayant un Extended Key Usage d’authentification (Client Authentication et/ou Server Authentication).
Les informations reliants le certificat à un compte de l’Active Directory sont donc renseignées directement dans le certificat, d’où l’appellation mappage Implicite.

Le mappage Explicite, quant à lui, verra les informations du certificat (Autorité de Certification émettrice, numéro de série du certificat, …) entrées dans l’attribut AltSecurityIdentities du compte de l’Active Directory. C’est cette différence qui rend le mappage Explicite.

Ces deux types de mappage ne peuvent pas être utilisés conjointement. Il est nécessaire de configurer une seule de ces deux méthodes sur l’ensemble du domaine. La méthode de mappage par défaut utilisée est la méthode implicite (via le SAN).

Le mappage de certificat peut être implicite ou explicite, et fort ou faible. Ces deux notions fonctionnent ensemble. Il y a donc 4 options différentes qui peuvent être utilisées pour mapper un certificat avec un compte de l’Active Directory :

Type de mappage	Robustesse
Implicite	Fort
Implicite	Faible
Explicite	Fort
Explicite	Faible

Avant de comprendre ce qu’est un mappage fort ou faible, il est nécessaire d’approfondir les deux types de mappages existants

Les différents types de mappage

Mappage implicite via le SAN

Comme expliqué précédemment, cette méthode consiste à indiquer l’UPN de l’utilisateur, ou le dNSHostName du compte ordinateur, dans le SAN du certificat. De cette manière, l’Active Directory est capable de retrouver le compte correspondant au certificat présenté en le cherchant via son UPN / dNSHostName.
Lors de la création d’un modèle de certificat avec AD CS, l’UPN ou le DNS Name doit être coché dans l’onglet Subject Name pour que ce type de mappage puisse avoir lieu :

L’UPN / DNSHostName est alors renseigné dans le certificat au niveau du SAN lors de l’enrôlement :

Pour rappel, cette méthode est celle par défaut et doit être désactivée si l’utilisation du Mappage Explicite est désirée.

En utilisant ce type de mappage :

Chaque certificat ne peut être associé qu’à un seul compte utilisateur.
Il est obligatoire de renseigner l’UPN de l’utilisateur / DNSHostName de la machine dans le SAN du certificat.
Le certificat doit contenir l’extension SID szOID_NTDS_CA_SECURITY_EXT pour être considéré comme mappé de manière forte.
Il résulte des deux points précédents que la compatibilité avec les PKI externes (autre qu’AD CS) est compliquée voire incertaine.

Attention : Ce type de mappage est considéré comme un mappage faible, sauf si le certificat contient l’extension SID szOID_NTDS_CA_SECURITY_EXT de la KB5014754 du 10 mai 2022 (plus de précisions dans la section « Mise à jour du 10 mai 2022 (KB5014754) »).
A partir du 11 février 2025, avec cette méthode de mappage, les authentifications échoueront si les certificats ne disposent pas de l’extension SID szOID_NTDS_CA_SECURITY_EXT.

Sources : https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

Mappage Explicite via l’attribut AltSecurityIdentities

Cette seconde méthode de mappage consiste à ajouter des informations du certificat dans l’attribut AltSecurityIdentities du (ou des) compte(s) utilisateur ou ordinateur associé(s).

Lors de l’authentification, le contrôleur de domaine pourra vérifier l’attribut AltSecurityIdentities du compte spécifié et vérifier que les informations du certificat présenté correspondent à celles contenues dans l’attribut.

Il existe 6 façons de remplir l’attribut AltSecurityIdentities :

La méthode par défaut est de renseigner l’Issuer et le Subject du certificat dans l’attribut. Cette méthode n’est pas recommandée. En effet, deux certificats différents peuvent avoir les mêmes valeurs dans les champs Issuer et Subject.

La méthode recommandée est d’inscrire dans l’attribut AltSecurityidentities les valeurs Issuer et Serial Number du certificat (qui correspondent respectivement à la CA émettrice et au numéro de série du certificat). Ce type de mappage est considéré comme un mappage fort.

En utilisant ce type de mappage :

Chaque certificat peut être associé à plusieurs comptes utilisateurs.
- Une même personne peut donc s’authentifier sur plusieurs comptes différents avec un même certificat.
- Un champ supplémentaire doit être ajouté à l’écran d’ouverture de session Windows pour spécifier le compte avec lequel on souhaite ouvrir la session.
Il n’est pas obligatoire de renseigner l’UPN de l’utilisateur dans le SAN du certificat.
- Si celui-ci est renseigné, le mappage fonctionnera tout de même (il n’est donc pas nécessaire de modifier le modèle de certificat lorsque vous voulez transitionné de la première méthode de mappage à la seconde)
Cette méthode de mappage est beaucoup plus flexible concernant les certificats émanant de PKI externes (hors AD CS).

Synthèse des différents types de Mappage

Mise à jour du 10 mai 2022 (KB5014754)

Détails de la mise à jour

Certaines techniques permettent d’exploiter le mappage entre comptes de l’Active Directory et certificats afin d’obtenir un accès en tant qu’autrui (Builtin\Administrator par exemple).

Cela a généré de multiples vulnérabilités (CVE-2022-34691, CVE-2022-26931 et CVE-2022-26923), à la suite de quoi Microsoft a publié un Patch (KB5014754) le 10 mai 2022 qui inclut les fonctionnalités suivantes :

Les certificats émis par les serveurs ADCS vont contenir l’extension szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2) qui référence le SID du compte AD en plus de l’UPN (ou du DNSName pour un objet machine) contenu dans le SAN.
Ce SID permet d’identifier de façon incontestable le propriétaire légitime du certificat lorsque le SAN est rempli automatiquement depuis les informations de l’AD.
Lors d’une authentification Kerberos avec PKINIT, le service KDC des contrôleurs de domaine va vérifier la présence :
- Soit d’une référence forte du certificat pour un utilisateur (strong certificate mapping à l’aide de l’attribut altSecurityIdentities de l’objet utilisateur).
- Soit de la présence de l’extension szOID_NTDS_CA_SECURITY_EXT référençant le SID de l’utilisateur dans le certificat (OID : 1.3.6.1.4.1.311.25.2).
Ajout de nouveaux évènements dans le journal évènements System (numéro d’évènements 39, 40 et 41).

En parallèle de sa nouvelle extension szOID_NTDS_CA_SECURITY_EXT utilisée dans le mappage implicite, Microsoft a déployé 2 clés de registre pour paramétrer le mappage de certificats afin de corriger la CVE-2022-26923 (certifried.md) avec la fameuse KB5014754:

La clé de registre StrongCertificateBindingEnforcement pour le mappage Kerberos (utilisé dans l’authentification Kerberos)
La clé de registre CertificateMappingMethods pour le mappage SChannel (authentification Schannel).

Modifications et impacts

Important : A partir du 11 février 2025, Microsoft poussera une mise à jour visant à ce que les authentifications avec des certificats ne respectant pas les critères de mappage soient refusées.

Seuls les certificats suivants seront autorisés :

Les certificats mappés via le SubjectAltName et qui possèdent l’extension SID szOID_NTDS_CA_SECURITY_EXT.
Les certificats mappés via le AtlSecurityidentities avec un mappage fort.

Les certificats émis avant la mise à jour des serveurs AD CS ne contiennent pas l’extension SID.
Dans le cas d’un mappage implicite via le SAN, il faut réémettre ces certificats pour qu’ils disposent d’un mappage fort.
Dans le cas d’un mappage explicite via l’attribut AltSecurityIdentities, il n’est pas nécessaire de réémettre ces certificats.

Méthodes d’authentification

Comme vu précédemment, deux clés de registres ont été intégrées dans la mise à jour de mai 2022. Ces clés de registre ont pour objectif de permettre aux certificats ancestraux (qui ne possédaient pas la nouvelle extension szOID_NTDS_CA_SECURITY_EXT) de toujours permettre l’authentification.
Ces clés de registre ont donc pour but d’assurer une compatibilité afin de permettre une transition douce vers les méthodes de mappage fort.

Nous avons ainsi les deux clés de registre :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel\CertificateMappingMethods : pour l’authentification Schannel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement : pour l’authentification Kerberos

Pour supporter ce mode de compatibilité, Microsoft a également ajouté le flag CT_FLAG_NO_SECURITY_EXTENSION au niveau de l’attribut msPKI-Enrollment-Flag situé sur chaque Template de certificat. Si ce flag est présent, l’autorité de certification n’inclura pas l’objectSid dans la nouvelle extension szOID_NTDS_CA_SECURITY_EXT (un des prérequis de l’ESC9).

StrongCertificateBindingEnforcement – (Authentification Kerberos)

Dans le cas de l’authentification Kerberos, le mappage fort implicite de certificat signifie que ce dernier utilisera la nouvelle extension szOID_NTDS_CA_SECURITY_EXT pour valider les informations contenues dans le SAN (UPN ou dNSHostName) du certificat.
Concernant le mappage fort explicite, il est nécessaire d’utiliser un des types de mappage recommandé par Microsoft afin de remplir les données de l’attribut altSecurityIdentities du compte AD.

Lors de l’authentification Kerberos, la clé de registre StrongCertificateBindingEnforcement peut prendre 3 valeurs :

0 : Le mappage fort n’est pas utilisé.
L’Extension szOID_NTDS_CA_SECURITY_EXT ne sera pas vérifiée pour le mappage implicite (même si présente dans le certificat) et tous les types de mappages explicites seront autorisés. Nous avons donc un comportement de compatibilité maximale, car cela revient à ne rien changer après le patch de 2022. Ce mode n’est plus opérationnel depuis le 11 avril 2023 et configurer la clé sur 0 désormais revient à la configurer sur la valeur 1.
1 : Valeur par défaut – Transition vers une méthode de mappage fort.
Avec cette valeur, le KDC vérifiera si un type de mappage fort implicite est utilisé. Ainsi, si l’extension szOID_NTDS_CA_SECURITY_EXT est présente, alors l’authentification sera autorisée. Si ce n’est pas le cas, cette dernière aura lieu tout de même, mais avec les informations contenues dans le SAN (méthode d’avant patch).
Toute authentification basée sur un mappage explicite sera autorisée (faible ou fort).
Cette période de transition, avec cette valeur de clé de registre, sera désactivé le 11 février 2025.
2 : Mappage fort uniquement.
Pour le mappage implicite, l’extension szOID_NTDS_CA_SECURITY_EXT doit être présente et contenir le SID du compte AD. Tandis que pour le mappage explicite, seuls les modes de mappage forts seront acceptés pour l’authentification. Pour tous les autres cas, l’authentification sera refusée.
Ce mode sera celui par défaut à partir de février 2025.

Dans tous les cas, lorsque l’extension szOID_NTDS_CA_SECURITY_EXT est présente lors d’un mappage implicite, le KDC comparera le SID contenu dans cette dernière avec les informations fournies en clair dans le SAN du certificat (UPN ou dNSHostName). Si ces informations sont différentes, l’authentification sera refusée.

Pour aller plus loin

Si la clé de registre StrongCertificateBindingEnforcementvaut 0 et que le certificat contient un UPN (en principe ce sera donc un compte utilisateur), le KDC va rechercher un compte utilisateur avec cet UPN. Si aucun utilisateur est trouvé, il tentera ensuite d’associer l’UPN du certificat au sAMAccountName d’un utilisateur. En cas d’échec, un $ sera ajouté à la fin de l’UPN du certificat afin d’essayer de trouver un compte ordinateur qui correspond.
Dans le cas où le certificat contient un dNSHostName (donc ici pour un compte ordinateur), le KDC va séparer la partie compte ordinateur et domaine. Par exemple, SRV1.sudo-ad.fr deviendra SRV1 et sudo-ad.fr. Un $ sera ajouté à SRV1 (SRV1$) et le KDC cherchera un compte ordinateur avec ce sAMAccountName.

Si la clé de registre StrongCertificateBindingEnforcement vaut 1 ou 2, et qu’aucun mappage explicite n’est mis en place, l’extension szOID_NTDS_CA_SECURITY_EXT sera utilisée pour réaliser le mappage avec l’attribut objectSid du compte. Si cette extension n’est pas présente et que la clé vaut 1, le mappage aura lieu comme expliqué précédemment. Si l’extension n’est pas présente et que la clé vaut 2, l’authentification sera refusée.

CertificateMappingMethods – (Authentification Schannel)

Pour rappel, le Microsoft Secure Channel, ou SChannel, est un package de sécurité qui contient plusieurs protocoles de sécurité (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 et PCT) qui assurent une authentification et une communication privée entre le client et le serveur.

Pour créer une connexion sécurisée, le client et le serveur doivent tous deux obtenir les informations d’identification Schannel à partir de certificats, puis créer une session sécurisée. Une fois la connexion établie, des informations sur les attributs des informations d’identification et leur contexte sont disponibles. Si une connexion est perdue, elle peut être renégociée en demandant une nouvelle connexion. Avant de fermer la connexion, le client et le serveur doivent tous deux effectuer un nettoyage et supprimer la connexion.

Durant l’authentification Schannel, le processus de mappage de certificat variera en fonction de la valeur de la clé de registre CertificateMappingMethods :

CertificateMappingMethods est un masque de bits (base 64) où chaque bit représente un type de mappage différent qui est pris en charge pour l’authentification SChannel : 0x4 par exemple active le mappage UPN et 0x1F les active tous (ancienne valeur par défaut).

La valeur par défaut actuelle est 0x0018 (0x0008 et 0x0010). Schannel ne supporte pas directement le mappage implicite via l’extension szOID_NTDS_CA_SECURITY_EXT, mais cette méthode de mappage peut être utilisée en convertissant le mappage Schannel en mappage Kerberos grâce à S4USelf. Cela reviendra donc dans ce cas au mappage implicite expliqué précédemment.

Synthèse

Mises à jour à venir

Il est important de notifier qu’à partir du 11 février 2025 (Aujourd’hui), la valeur par défaut de la clé de registre StrongCertificateBindingEnforcement sera 2 et que les modes 1 et 0 ne seront plus compatibles, donc l’authentification sera refusée en cas de mappage faible.
Tous les anciens certificats qui sont basés sur une méthode de mappage faible devront être renouvelés pour prendre en compte le mappage fort.

En cas d’authentification refusée, l’évènement d’ID 39 (ou 41 pour Windows Server 2008 R2 SP1 & SP2) sera disponible.

Heureusement, il sera possible de créer la clé de registre StrongCertificateBindingEnforcement et de la paramétrer à 1 (car si la clé est à ce moment inexistante, la valeur par défaut sera 2) et de conserver le mode compatibilité jusqu’au 10 septembre 2025. Passé cette date, aucun mappage faible ne sera autorisé et la clé de registre StrongCertificateBindingEnforcement ne sera plus supportée.

Sources

Cette information sera entrée dans le champ DNSName du certificat (sous-catégorie du SAN) ↩︎

Merci à mes amis Bastien et Killyan pour leurs contributions et relecture de ce premier article !