Aller au contenu
05 · Services de certificats ADPartie 3 sur 4Intermédiaire

Sécuriser l'inscription web AD CS contre ESC8 et ESC11

Fermer le relais NTLM vers AD CS : repérer les points d'inscription HTTP, imposer HTTPS et EPA, retirer NTLM, supprimer Web Enrollment et imposer le chiffrement RPC.

Florian Amette8 min de lecture

ESC8 est la raison pour laquelle PetitPotam est devenu une technique de prise de contrôle du domaine plutôt qu'une simple curiosité. Un attaquant contraint un contrôleur de domaine à s'authentifier en NTLM, relaie cette authentification vers la page d'inscription HTTP de l'AC et reçoit un certificat émis pour le propre compte d'ordinateur du contrôleur de domaine. Ce certificat permet de s'authentifier via PKINIT en tant que DC, ce qui suffit pour demander des données de réplication. Aucun modèle n'est mal configuré et aucun mot de passe n'est deviné ; la faille tient à ce que l'AC accepte NTLM sur un canal qui ne lie pas l'authentification à la session (voir l'entrée de glossaire ESC8). ESC11 applique la même idée à l'interface d'inscription RPC de l'AC lorsque le chiffrement des demandes n'est pas imposé.

Ce guide couvre en détail la surface d'inscription : trouver chaque point de terminaison HTTP et RPC qui émet des certificats, décider lesquels doivent exister, et durcir les autres avec HTTPS, Extended Protection for Authentication (EPA), le retrait de NTLM et IF_ENFORCEENCRYPTICERTREQUEST. Il complète la vue d'ensemble des classes ESC du pilier de durcissement AD CS et les contrôles de relais plus généraux de Bloquer le relais NTLM.

Mesurer : trouver chaque point de terminaison d'inscription

AD CS peut exposer quatre chemins d'inscription. Seul le premier est toujours présent :

Point de terminaisonService de rôleTransportClasse de relais
MS-ICPR / DCOM (ICertPassage, ICertRequest)Certification AuthorityRPCESC11 si le chiffrement n'est pas imposé
/certsrvCertification Authority Web Enrollment (ADCS-Web-Enrollment)HTTP/HTTPSESC8
Certificate Enrollment Web Service (CES)ADCS-Enroll-Web-SvcHTTPSESC8 avec l'authentification Windows intégrée
Network Device Enrollment Service (/certsrv/mscep)ADCS-Device-EnrollmentHTTP/HTTPSRisque distinct, même durcissement

Commencez par ce qui est installé sur chaque AC et serveur d'inscription :

PowerShell
# À exécuter sur chaque AC / serveur web d'inscription
Get-WindowsFeature ADCS-* | Where-Object Installed | Select-Object Name, DisplayName

# AC d'entreprise et URI CES publiées dans AD
$pks = "CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)"
Get-ADObject -SearchBase "CN=Enrollment Services,$pks" -LDAPFilter '(objectClass=pKIEnrollmentService)' `
    -Properties dNSHostName, msPKI-Enrollment-Servers |
    Select-Object Name, dNSHostName, @{n='CES';e={$_.'msPKI-Enrollment-Servers' -join '; '}}

Vérifiez ensuite ce que chaque point de terminaison web propose réellement. Depuis un poste d'administration joint au domaine, sous Windows PowerShell 5.1, une requête non authentifiée renvoie les schémas d'authentification dans l'en-tête WWW-Authenticate. NTLM ou Negotiate en HTTP simple constitue le pire cas.

PowerShell
foreach ($url in 'http://ca01.corp.example/certsrv/','https://ca01.corp.example/certsrv/') {
    try   { Invoke-WebRequest -Uri $url -UseBasicParsing -ErrorAction Stop | Out-Null; "$url -> anonymous 200" }
    catch { "$url -> $($_.Exception.Response.StatusCode) $($_.Exception.Response.Headers['WWW-Authenticate'])" }
}

Enfin, mesurez l'utilisation. Si les journaux IIS ne montrent aucun accès légitime à /certsrv sur 90 jours, il ne s'agit pas de durcir le point de terminaison, mais de le supprimer.

PowerShell
Get-ChildItem 'C:\inetpub\logs\LogFiles\W3SVC1\*.log' |
    Where-Object LastWriteTime -gt (Get-Date).AddDays(-90) |
    Select-String -Pattern ' /certsrv' |
    ForEach-Object { ($_.Line -split ' ')[8] } |   # colonne c-ip dans l'ordre des champs W3C par défaut
    Group-Object | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

Vérifiez l'index de colonne par rapport à l'en-tête #Fields: de vos fichiers journaux avant de vous fier à la colonne d'IP cliente.

Décider point de terminaison par point de terminaison

Classez chaque point de terminaison avant de modifier quoi que ce soit. Un point de terminaison sans trafic légitime est supprimé. Un point de terminaison utilisé uniquement par des clients Windows joints au domaine peut généralement basculer vers l'inscription automatique via RPC, puis être supprimé. Un point de terminaison qui sert des équipements hors domaine, des forêts partenaires ou des appliances est conservé et reçoit le traitement complet décrit ci-dessous : HTTPS, EPA et Kerberos uniquement. CES mérite une remarque à part : il peut être configuré avec l'authentification Windows intégrée, par nom d'utilisateur et mot de passe, ou par certificat client. Seule la variante Windows intégrée est relayable au sens d'ESC8, mais l'authentification par nom d'utilisateur et mot de passe expose une invite de mot de passe à tout ce qui peut atteindre le service : préférez l'authentification par certificat pour les scénarios de renouvellement. NDES n'est pas une cible ESC8 de la même manière, puisqu'il émet des certificats sur la base d'un mot de passe de challenge plutôt que de l'identité Windows de l'appelant, mais il tourne sur la même pile IIS et mérite le même examen de HTTPS et d'exposition.

Imposer, option 1 : supprimer Web Enrollment

Les pages certsrv héritées existent principalement pour les demandes manuelles depuis un navigateur. L'inscription automatique par stratégie de groupe utilise RPC/DCOM, et non certsrv : la plupart des flux des machines jointes au domaine ne sont donc pas affectés par sa suppression. Si les données d'utilisation le permettent, désinstallez-le :

PowerShell
# Sur le serveur qui héberge Web Enrollment
Uninstall-AdcsWebEnrollment -Force
Uninstall-WindowsFeature ADCS-Web-Enrollment

Si le serveur d'AC n'héberge IIS pour aucune autre raison, supprimez aussi le rôle Serveur Web, ce qui réduit la surface d'attaque d'un hôte Tier 0. Faites le même examen pour CES et NDES : si rien ne les consomme, supprimez-les.

Imposer, option 2 : HTTPS, EPA et pas de NTLM

Lorsqu'un point de terminaison doit être conservé, durcissez-le en trois couches. Les sections d'authentification d'IIS sont verrouillées au niveau serveur par défaut : écrivez donc les paramètres dans applicationHost.config avec un chemin de location plutôt que dans le web.config du site.

PowerShell
Import-Module WebAdministration
$loc = 'Default Web Site/CertSrv'

# 1. Exiger TLS
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/access' -Name sslFlags -Value 'Ssl'

# 2. Exiger Extended Protection for Authentication (liaison de canal)
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication' `
    -Name 'extendedProtection.tokenChecking' -Value 'Require'

# 3. Proposer Kerberos uniquement : retirer le fournisseur NTLM, conserver Negotiate
Remove-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication/providers' `
    -Name '.' -AtElement @{ value = 'NTLM' }

Supprimez aussi la liaison HTTP simple du site (ou au moins des répertoires virtuels d'inscription) afin que rien ne se rabatte sur le port 80. Retirer uniquement la chaîne de fournisseur NTLM n'empêche pas NTLM à l'intérieur de Negotiate : Negotiate peut toujours se rabattre sur NTLM. Pour supprimer complètement NTLM, bloquez-le au niveau du système d'exploitation sur le serveur d'inscription, après audit :

  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts
  • Après une période d'audit sans anomalie : Network security: Restrict NTLM: Incoming NTLM traffic = Deny all accounts

Les événements d'audit sont écrits dans Applications and Services Logs > Microsoft > Windows > NTLM > Operational (événement 8002 pour le NTLM entrant). La méthode pas à pas se trouve dans auditer et restreindre NTLM.

Pour CES, l'avis de Microsoft sur ESC8 (KB5005413) demande en outre d'activer EPA dans le web.config propre au service, généralement sous C:\Windows\SystemData\CES\<CA name>_CES_Kerberos\, en définissant extendedProtectionPolicy policyEnforcement="Always" sur l'élément de sécurité du transport, en plus du paramètre IIS. Lorsqu'un répartiteur de charge termine TLS devant CES ou certsrv, EPA ne peut pas fonctionner, car le jeton de liaison de canal du client se rapporte au certificat du répartiteur ; faites passer TLS jusqu'à IIS ou ne publiez pas le point de terminaison via ce répartiteur.

Imposer : chiffrement des demandes RPC (ESC11)

L'interface MS-ICPR utilisée par certreq et certains clients accepte des demandes sans confidentialité des paquets, sauf si le drapeau d'interface IF_ENFORCEENCRYPTICERTREQUEST de l'AC est positionné. Vérifiez chaque AC :

PowerShell
certutil -config "ca01.corp.example\CORP-Issuing-CA" -getreg CA\InterfaceFlags

Si IF_ENFORCEENCRYPTICERTREQUEST est absent de la sortie, positionnez-le et redémarrez le service :

PowerShell
certutil -config "ca01.corp.example\CORP-Issuing-CA" -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
Restart-Service certsvc   # à exécuter sur l'AC

Le drapeau est activé par défaut sur les installations d'AC actuelles. Lorsqu'il manque, la raison habituelle est une ancienne modification de dépannage pour un client hérité : identifiez ce client avant de considérer qu'il est sans risque de le positionner.

Réduire le volet coercition

EPA et le retrait de NTLM neutralisent la cible du relais ; réduisez aussi la source d'authentifications contraintes. Désactivez le Spouleur d'impression sur les contrôleurs de domaine, appliquez les atténuations EFSRPC et les filtres RPC contre la coercition de type PetitPotam, et bloquez le SMB et le HTTP sortants depuis les DC vers tout ce qui n'est pas un autre système Tier 0. Ces contrôles sont traités dans bloquer la coercition d'authentification et le pare-feu des contrôleurs de domaine.

Vérifier

Relisez la configuration IIS de chaque répertoire virtuel durci :

PowerShell
$loc = 'Default Web Site/CertSrv'
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/access' -Name sslFlags
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication' -Name 'extendedProtection.tokenChecking'
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication/providers' -Name '.' |
    Select-Object -ExpandProperty Collection | Select-Object value

Résultat attendu : Ssl, Require, et uniquement Negotiate (ou Negotiate:Kerberos) dans la liste des fournisseurs. Relancez la sonde WWW-Authenticate de l'étape Mesurer : l'URL HTTP ne doit plus répondre, et l'URL HTTPS ne doit plus annoncer NTLM. Relancez certutil -getreg CA\InterfaceFlags sur chaque AC, et vérifiez que Locksmith ou vos propres contrôles ne signalent plus ESC8 ni ESC11.

Sur l'AC, conservez l'audit des émissions (événements 4886 et 4887) et alertez lorsqu'un certificat est émis pour le compte d'ordinateur d'un contrôleur de domaine à partir d'un modèle autre que votre modèle d'authentification des contrôleurs de domaine, ou par un demandeur autre que le DC lui-même. Cette alerte détecte un relais passé par un point de terminaison oublié.

Ce qui casse

  • Supprimer Web Enrollment : les demandes manuelles depuis un navigateur, certains scripts d'inscription Linux et macOS, et les appliances qui exploitent les pages certsrv cessent de fonctionner. Donnez à ces utilisateurs certreq sur un hôte joint au domaine, un modèle dédié demandé via un service contrôlé, ou un véritable frontal ACME/SCEP.
  • Exiger EPA : les clients et proxys qui ne prennent pas en charge la liaison de canal échouent avec une erreur HTTP 401. Les répartiteurs de charge qui terminent TLS et certains proxys inverses sont le cas courant ; les anciens clients HTTP tiers sont l'autre.
  • Retirer NTLM : les demandes provenant de machines non jointes au domaine, de clients qui atteignent l'AC par adresse IP ou par un nom sans SPN correspondant, et de clients d'autres forêts sans chemin Kerberos échouent toutes. Enregistrez le SPN de chaque alias utilisé (HTTP/pki.corp.example sur l'identité du pool d'applications).
  • IF_ENFORCEENCRYPTICERTREQUEST : les très anciens clients (époque Windows XP et Server 2003) et certains outils tiers qui appellent MS-ICPR sans confidentialité des paquets ne peuvent plus s'inscrire via RPC.
  • Désactiver le spouleur sur les DC : l'élagage des imprimantes publiées s'arrête ; rien d'autre sur un DC ne devrait en dépendre.

Pour aller plus loin : le thème Services de certificats AD, l'entrée de glossaire Relais NTLM, et la signature et la liaison de canal LDAP pour la protection équivalente contre le relais sur les contrôleurs de domaine.

Questions fréquentes

Le mappage fort des certificats bloque-t-il ESC8 ?

Non. Dans un relais ESC8, l'attaquant obtient un certificat pour le compte dont l'authentification a été relayée, par exemple le compte d'ordinateur d'un contrôleur de domaine. L'AC inscrit le SID authentique de ce compte dans le certificat : celui-ci est donc fortement mappé et passe l'application stricte de KB5014754. Seule la suppression du point de terminaison relayable, ou la liaison de l'authentification au canal TLS avec EPA associée au retrait de NTLM, ferme ce chemin.

HTTPS suffit-il à protéger certsrv ?

Non. HTTPS protège le trafic en transit mais n'empêche pas le relais : l'attaquant ouvre simplement sa propre session TLS vers l'AC et y fait transiter l'échange NTLM. C'est Extended Protection for Authentication qui lie l'échange NTLM ou Kerberos au canal TLS précis, ce qui fait échouer une authentification relayée. Il faut HTTPS et EPA ensemble, ou pas de NTLM du tout.

Que protège IF_ENFORCEENCRYPTICERTREQUEST ?

Il fait rejeter par l'AC les demandes de certificats soumises via l'interface RPC MS-ICPR, sauf si l'appel RPC utilise la confidentialité des paquets (chiffrement). Sans lui, une authentification NTLM vers l'interface d'inscription RPC peut être relayée : c'est la classe ESC11. Le drapeau est activé par défaut sur les AC Windows Server actuelles, mais des administrateurs le retirent parfois pour prendre en charge d'anciens clients : vérifiez-le donc sur chaque AC.

Sécuriser l'inscription web AD CS contre ESC8 et ESC11

Guides associés

NTLM & protocoles hérités

Exiger la signature SMB et désactiver SMBv1 partout

Imposer la signature SMB sur clients et serveurs, comprendre les défauts de Windows 11 24H2 et Server 2025, auditer SMBv1 et le retirer sans casser l'accès aux fichiers.

Fondamental
NTLM & protocoles hérités

Imposer la signature et la liaison de canal LDAP

Déployer la signature et la liaison de canal LDAP sur preuves : collecter les événements 2887, 2889 et 3039, corriger les clients, puis activer LdapEnforceChannelBinding.

Intermédiaire
Services de certificats AD

Mappage fort des certificats (KB5014754) en pratique

Préparer l'authentification par certificat au mode Full Enforcement de KB5014754 : extension SID, altSecurityIdentities, événements KDC 39/40/41 et correctifs efficaces.

Avancé