Durcir AD CS : corriger les failles ESC1 à ESC8

Les services de certificats Active Directory (AD CS) constituent une infrastructure Tier 0, au même titre que les contrôleurs de domaine, car un certificat émis par l'AC peut authentifier en tant que n'importe quel compte désigné par le demandeur — en contournant entièrement les défenses des contrôleurs de domaine. Les classes d'erreurs de configuration ESC1 à ESC8, documentées par la communauté de la recherche en sécurité, décrivent autant de façons distinctes dont une AC trop permissive délivre des certificats qu'elle ne devrait pas émettre. Ce guide aborde chaque classe d'un point de vue défensif — à quoi ressemble l'erreur de configuration et comment la corriger —, avec des commandes de vérification et la surveillance nécessaire pour détecter les tentatives d'abus.

Pourquoi AD CS relève du Tier 0

Le rôle d'une AC est de lier une identité à une clé publique. Si un utilisateur à faibles privilèges peut demander un certificat pour un Domain Admin — ou pour tout compte avec un EKU Client Authentication —, il peut utiliser ce certificat pour s'authentifier en tant que ce compte via PKINIT, sans jamais connaître son mot de passe et sans toucher directement à la pile d'authentification d'un contrôleur de domaine. Le serveur d'AC lui-même, ainsi que la clé privée du certificat racine ou émetteur de l'AC, doivent être traités avec la même discipline de tiering qu'un contrôleur de domaine : pas de navigation web depuis l'AC, pas d'ouverture de session hors administrateurs PKI, et des postes d'administration dédiés et durcis pour la gestion de l'AC.

Les classes ESC1 à ESC8, côté défense

Elles sont décrites de manière conceptuelle — l'erreur de configuration et sa correction —, et non comme des étapes d'exploitation.

ESC1 : le demandeur fournit le sujet + EKU d'authentification client

Un modèle de certificat qui permet au demandeur de spécifier un Subject Alternative Name (SAN) arbitraire, combiné à un EKU autorisant l'authentification client (Client Authentication, Smart Card Logon ou équivalent), permet à tout utilisateur autorisé à s'inscrire de demander un certificat usurpant l'identité d'un autre compte, y compris des comptes privilégiés.

Correction : auditez chaque modèle à la recherche du drapeau « enrollee supplies subject ». Supprimez-le sauf besoin métier précis et documenté (certains scénarios d'inscription automatique en ont légitimement besoin — associez-les alors à des droits d'inscription strictement restreints).

# Lister les modèles et repérer enrollee-supplies-subject
Get-ADObject -SearchBase (Get-ADRootDSE).ConfigurationNamingContext `
    -LDAPFilter "(objectClass=pKICertificateTemplate)" -Properties msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage |
    Select-Object Name, msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage

msPKI-Certificate-Name-Flag est un masque de bits : les modèles dont le bit 0x1 (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) est positionné sont les modèles à risque. Croisez avec les OID de pKIExtendedKeyUsage pour l'authentification client (1.3.6.1.5.5.7.3.2) ou l'ouverture de session par carte à puce (1.3.6.1.4.1.311.20.2.2).

ESC2 : modèles « Any Purpose » ou sans EKU

Un modèle sans restriction d'EKU, ou avec l'EKU Any Purpose, peut être détourné de la même manière qu'ESC1 dès qu'il est combiné à un contrôle du sujet ou à un agent d'inscription vulnérable. Retirez les modèles Any Purpose et sans EKU de l'inscription générale ; restreignez-les fortement ou mettez-les hors service.

ESC3 : agent de demande de certificat vulnérable

Les modèles Enrollment Agent permettent à leur détenteur de demander des certificats au nom d'autres utilisateurs. Un modèle Enrollment Agent trop large (émis pour un groupe étendu, sans restreindre les modèles/utilisateurs pour lesquels l'agent peut inscrire) devient un chemin d'usurpation d'identité. Restreignez l'émission des certificats Enrollment Agent et associez-la aux « Certificate Managers Restrictions » de l'AC (restrictions par agent, par modèle et par utilisateur cible).

ESC4 : contrôle d'accès faible sur les modèles

Si un groupe à faibles privilèges détient des droits Write/WriteDacl/WriteOwner sur l'objet AD d'un modèle sensible, il peut le réécrire pour y introduire lui-même des drapeaux de type ESC1. Auditez les ACL des modèles, pas seulement leurs paramètres.

$templates = Get-ADObject -SearchBase (Get-ADRootDSE).ConfigurationNamingContext `
    -LDAPFilter "(objectClass=pKICertificateTemplate)"
foreach ($t in $templates) {
    (Get-Acl -Path "AD:\$($t.DistinguishedName)").Access |
        Where-Object { $_.ActiveDirectoryRights -match "WriteProperty|WriteDacl|WriteOwner|GenericAll" } |
        Select-Object @{n='Template';e={$t.Name}}, IdentityReference, ActiveDirectoryRights
}

ESC5 : contrôle d'accès faible sur les objets PKI

Même principe qu'ESC4, mais appliqué à l'objet AC, à l'objet NTAuthCertificates ou au conteneur Certificate Templates / au conteneur des AC eux-mêmes. Quiconque dispose d'un accès en écriture sur ces objets AD peut ajouter une AC malveillante aux émetteurs approuvés de la forêt.

ESC6 : EDITF_ATTRIBUTESUBJECTALTNAME2

Ce drapeau, défini au niveau de toute l'AC, autorise la fourniture d'un SAN dans la demande pour n'importe quel modèle, quels que soient les drapeaux de sujet du modèle lui-même — ce qui transforme de fait chaque modèle activé en risque ESC1. Vérifiez-le et supprimez-le :

certutil -config "<CAHostName>\<CAName>" -getreg policy\EditFlags

Recherchez EDITF_ATTRIBUTESUBJECTALTNAME2 dans la sortie. Supprimez-le :

certutil -config "<CAHostName>\<CAName>" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc; net start certsvc

ESC7 : contrôle d'accès vulnérable sur l'AC

Des autorisations trop larges au niveau de l'AC (Manage CA, Manage Certificates) accordées à des groupes autres que les administrateurs PKI permettent à leurs détenteurs d'approuver des demandes en attente ou de modifier des paramètres de l'AC, y compris d'émettre des certificats qui seraient sinon refusés. Contrôlez-les avec certutil -getreg CA\Security ou l'onglet Sécurité du composant logiciel enfichable MMC de l'AC, et limitez-les au seul groupe d'administrateurs PKI.

ESC8 : relais NTLM vers l'inscription web de l'AC

Le point de terminaison d'inscription web HTTP/HTTPS de l'AC (certsrv, ou CES/CEP pour l'inscription automatique) accepte l'authentification NTLM sur un canal qui, sans Extended Protection for Authentication (EPA), peut recevoir une authentification NTLM contrainte ou interceptée ailleurs sur le réseau et relayée — ce qui produit un certificat pour l'identité relayée. C'est la déclinaison propre à AD CS du problème plus large du relais NTLM traité dans Bloquer le relais NTLM.

Correction : imposez HTTPS sur tous les points de terminaison d'inscription web et activez Extended Protection for Authentication dans IIS sur les répertoires virtuels CertSrv/CES/CEP. Si l'inscription web n'est pas activement utilisée, désactivez complètement le service de rôle.

# Exiger SSL et activer EPA sur le répertoire virtuel CertSrv (à exécuter sur le serveur d'AC/d'inscription web).
# Ces sections sont verrouillées au niveau serveur : les écrire dans applicationHost.config avec -Location.
Import-Module WebAdministration
$loc = 'Default Web Site/CertSrv'
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/access' -Name sslFlags -Value 'Ssl'
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication' `
    -Name 'extendedProtection.tokenChecking' -Value 'Require'

Liste de contrôle des remédiations générales

Surveillance et détection

Activez l'audit de l'AC afin que chaque émission, refus et modification de modèle soit journalisé :

certutil -setreg CA\AuditFilter 127
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

Examinez le journal Security de l'AC pour les ID d'événements 4886 (demande soumise), 4887 (certificat émis), 4888 (refusé) et 4899 (modèle modifié). Établissez une référence des demandeurs attendus par modèle et alertez sur toute émission vers des comptes ou des SAN inattendus :

Get-WinEvent -LogName Security | Where-Object { $_.Id -in 4886,4887,4888,4899 } |
    Select-Object TimeCreated, Id, Message

Exportez aussi périodiquement la configuration des modèles pour détecter les dérives :

certutil -v -Template "<TemplateName>" > template-audit.txt

Ce qui casse

• Supprimer les drapeaux SAN / resserrer l'inscription : tout flux reposant sur des demandes de certificats en libre-service avec sujets personnalisés (certains provisionnements de clients VPN, scripts d'inscription d'objets IoT/équipements) devra être redirigé vers un modèle dédié et strictement délimité.
• Approbation du gestionnaire : transforme l'inscription automatique en flux de demandes en attente pour les modèles concernés, ce qui ajoute un délai pour les utilisateurs finaux jusqu'à l'intervention d'un approbateur — limitez-la aux modèles sensibles, pas à toute l'AC.
• EPA sur l'inscription web : casse les clients ou répartiteurs de charge qui terminent TLS avant IIS d'une manière qui supprime le jeton de liaison de canal ; validez votre chemin de terminaison TLS avant l'activation.
• Désactiver l'inscription web : casse tout processus qui dépend encore des pages certsrv héritées ou de CES/CEP pour l'inscription automatique en HTTP — migrez-les d'abord vers l'inscription automatique par stratégie de groupe.

Consultez aussi Durcissement des contrôleurs de domaine et Durcissement de Kerberos pour les contrôles Tier 0 voisins, et ESC1 pour une analyse approfondie de cette classe d'erreur de configuration.