SOC managé - surveillance continue  ·  veille cyber : CERT-FR / CISA / NVD  ·  réponse à incident en priorité
Tous les pas à pas

Durcissement · Tuto 2/4

Durcir Active Directory (2/4) : protocoles d'authentification et surface des DC.

Publié le 4 septembre 2026 Lecture 20 min

Vérifié le 5 septembre 2026 Sources ANSSI-PA-099, Microsoft Learn, CISA (recoupées ce jour) À revoir avant septembre 2027

C'est la partie qui casse la production quand elle est mal menée. Les protocoles d'authentification d'un domaine Windows portent des défauts hérités : RC4 dans Kerberos, NTLM, LDAP en clair, SMB non signé, résolution de noms de secours. Aucun n'est là par négligence - chacun existe pour rester compatible avec quelque chose. Le durcissement consiste donc moins à « désactiver » qu'à découvrir ce qui en dépend encore, puis à le corriger, puis seulement à couper.

En résumé

  • Les protocoles d'authentification d'un domaine Windows portent des défauts historiques choisis pour la compatibilité, pas pour la sécurité : RC4 dans Kerberos, NTLM, LDAP en clair, SMB non signé, LLMNR.
  • L'ordre de traitement est toujours le même : auditer, identifier les applications qui dépendent du protocole, les corriger, puis restreindre. Bloquer d'emblée dans un environnement mal connu casse la production.
  • Le compte krbtgt signe tous les tickets Kerberos du domaine : sa réinitialisation se fait deux fois, espacées, sous peine soit de laisser valides les tickets forgés, soit de couper l'authentification de tout le domaine.
  • La signature LDAP et le channel binding ferment le relais d'authentification vers les contrôleurs de domaine ; ils se déploient en mode audit avant d'être imposés.
  • Un contrôleur de domaine n'a aucune raison d'imprimer, d'héberger une application ou d'exposer RDP à tout le parc : réduire sa surface vaut autant que durcir ses protocoles.
La règle qui gouverne toute cette page

Auditer, identifier les applications concernées, les corriger, restreindre, et seulement ensuite bloquer. Un domaine où l'on désactive NTLM d'un coup sans inventaire préalable ne devient pas plus sûr : il devient un domaine où plus rien ne fonctionne, où l'on annule tout dans l'heure, et où personne ne retentera avant deux ans.

Ce qu'il vous faut

  • Des droits d'administration du domaine, depuis un poste d'administration dédié (voir la partie 1).
  • La console de gestion des stratégies de groupe, et le droit de modifier la stratégie des contrôleurs de domaine.
  • Un accès aux journaux des contrôleurs de domaine, ou mieux, à leur collecte centralisée.
  • Une fenêtre de changement, et l'accord des équipes applicatives : cette partie va révéler des dépendances oubliées.
SANS SIGNATURE — l'authentification n'est pas liée à son expéditeur poste authentif. attaquant sur le même réseau rejouée telle quelle contrôleur de domaine accepte : rien ne prouve d'où elle vient AVEC SIGNATURE ET CHANNEL BINDING — l'authentification est scellée à sa session poste authentif. signée attaquant sur le même réseau rejeu refusé contrôleur de domaine la signature ne correspond plus à la session Le relais ne casse rien : il réutilise une authentification valide - c'est pour cela qu'aucun correctif ne le ferme. La signature LDAP et SMB lie l'authentification à sa session ; le channel binding l'attache en plus au tunnel TLS. Même logique pour LLMNR et NBT-NS : ils fournissent à l'attaquant l'authentification qu'il relaiera ensuite.
Le relais d'authentification : ce que ferment la signature et le channel binding

1. Réduire la surface des contrôleurs de domaine

Avant de durcir des protocoles, retirez ce qui n'a pas à être là. Un contrôleur de domaine est la machine la plus sensible du système d'information ; chaque rôle supplémentaire y est une surface d'attaque en plus, sur la cible la plus intéressante.

  • Un système supporté et à jour. Les contrôleurs de domaine se patchent avant le reste du parc, pas après : une faille critique sur un contrôleur de domaine vaut plus cher à un attaquant que sur n'importe quel autre serveur. 
    Get-ADDomainController -Filter * |
    Select-Object HostName, OperatingSystem, OperatingSystemVersion
  • Aucun rôle superflu : pas d'IIS, pas de serveur de base de données, pas d'application métier, pas de partage de fichiers annexe, pas de navigateur, pas d'agent non maîtrisé.
  • Le spouleur d'impression désactivé. La faille PrintNightmare (CVE-2021-1675 et CVE-2021-34527) permettait une exécution de code à distance via ce service, et un contrôleur de domaine n'a structurellement aucune raison d'imprimer : 
    Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled
  • Le pare-feu actif, en refus par défaut en entrée, avec les flux nécessaires ouverts explicitement : 
    Get-NetFirewallProfile |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction
  • L'administration réservée aux postes dédiés. RDP et WinRM vers un contrôleur de domaine ne doivent être ouverts que depuis les PAW du palier 0 - jamais depuis le réseau utilisateur, jamais depuis un serveur quelconque.

2. Kerberos : passer en AES, retirer RC4 et DES

Kerberos doit être le protocole d'authentification par défaut d'un domaine moderne. Sa surface d'attaque la plus répandue est le kerberoasting, qui exploite précisément le fait qu'un domaine accepte encore le chiffrement RC4 sur les comptes de service : un ticket chiffré en RC4 se casse hors ligne bien plus vite qu'en AES.

Commencez par mesurer ce qui utilise encore RC4, plutôt que de couper à l'aveugle : les événements 4768 et 4769 des contrôleurs de domaine indiquent le type de chiffrement du ticket demandé (0x17 pour RC4, 0x12 pour AES256).

Puis appliquez, par stratégie de groupe :

Stratégies locales → Options de sécurité → « Sécurité réseau : configurer les types de chiffrement autorisés pour Kerberos »

Cochez AES128 et AES256, décochez DES et RC4. Puis, sur les comptes de service eux-mêmes :

Set-ADUser -Identity "svc-application" -KerberosEncryptionType AES128,AES256

Les appliances et applications anciennes sont la principale source de surprise ici : certaines n'implémentent qu'RC4. C'est exactement ce que l'audit préalable sert à découvrir.

3. Réinitialiser le compte krbtgt - deux fois, avec l'attente

Le compte krbtgt signe tous les tickets Kerberos du domaine. Qui obtient son empreinte peut forger des tickets valides pour n'importe quel compte, indéfiniment : c'est l'attaque dite du « Golden Ticket », et elle survit à la réinitialisation du mot de passe de tous les autres comptes du domaine.

La réinitialisation doit se faire deux fois, parce que l'annuaire conserve toujours la clé courante et la précédente. Après une seule réinitialisation, les tickets forgés avec l'ancienne clé restent acceptés : l'attaquant garde son accès.

Mais l'espacement entre les deux est tout aussi important, pour deux raisons distinctes qu'on confond souvent :

  • la réplication du nouveau mot de passe doit être achevée sur tous les contrôleurs de domaine ;
  • et il faut qu'au moins la durée de vie maximale d'un TGT se soit écoulée (10 heures par défaut), le temps que les tickets légitimes en circulation aient été renouvelés.

Enchaîner les deux réinitialisations trop vite ne rend pas l'opération plus efficace : cela coupe l'authentification de tout le domaine. Microsoft fournit un script dédié (New-KrbtgtKeys.ps1) qui gère cette séquence et vérifie la réplication entre les deux passes : utilisez-le plutôt qu'une réinitialisation à la main.

À faire une fois maintenant - vous ne savez pas ce qui a fuité avant votre arrivée -, puis au moins une fois par an, et systématiquement après toute suspicion de compromission.

4. NTLM : inventorier avant de restreindre

NTLM est une technologie de compatibilité, pas un mécanisme cible. Il est vulnérable au relais d'authentification et ne bénéficie d'aucune des protections apportées par Kerberos. Mais c'est aussi le protocole dont dépendent, sans que personne ne le sache, les vieilles applications, les scanners réseau, les copieurs multifonctions et les accès par adresse IP.

La méthode, dans cet ordre :

  1. Auditer. Activez l'audit NTLM par stratégie de groupe (« Sécurité réseau : restreindre NTLM » en mode Auditer) et collectez les événements 8001 à 8004 du journal NTLM/Operational, plus l'événement 4776 côté contrôleurs de domaine. Vous obtenez qui, depuis où, vers quoi.
  2. Corriger. Pour chaque flux identifié : nom DNS correct au lieu d'une adresse IP, service principal (SPN) correctement déclaré, ou migration vers une authentification moderne. C'est ici que passe l'essentiel du temps.
  3. Re-auditer jusqu'à ce que la liste résiduelle soit courte et entièrement expliquée.
  4. Restreindre progressivement, avec une liste d'exceptions écrite, puis bloquer.

En parallèle, trois réglages sans regret parce qu'ils ne concernent que des variantes déjà indéfendables :

  • NTLMv1 et les empreintes LM : « Sécurité réseau : ne pas stocker de valeur de hachage LAN Manager » activé, et « Sécurité réseau : niveau d'authentification LAN Manager » réglé sur Envoyer une réponse NTLMv2 uniquement, refuser LM et NTLM.
  • WDigest : ce fournisseur conservait les mots de passe en clair en mémoire. Il est désactivé par défaut depuis Windows 8.1 et Windows Server 2012 R2, mais la valeur de registre est souvent simplement absente - et certains logiciels la réactivent. Posez-la donc explicitement à zéro, pour que l'état ne dépende plus d'un défaut :

    HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest

    UseLogonCredential (REG_DWORD) = 0
  • LLMNR et NBT-NS : ces protocoles de résolution de noms de secours répondent à toute machine qui les interroge. Un attaquant sur le même réseau usurpe une réponse et récupère des authentifications à relayer - c'est le principe de l'outil Responder, et cela ne demande aucun privilège. Désactivez LLMNR par GPO (« Désactiver la résolution de noms de multidiffusion ») et NBT-NS via les paramètres WINS des interfaces réseau.

5. Signature LDAP et channel binding

Un annuaire interrogé en LDAP non signé accepte qu'une authentification lui soit relayée : un attaquant qui a capturé une authentification ailleurs sur le réseau la rejoue vers le contrôleur de domaine, qui n'a aucun moyen de savoir qu'elle ne vient pas de son interlocuteur. Deux mesures ferment ce chemin, et elles vont ensemble.

a. Auditer d'abord. Les contrôleurs de domaine peuvent signaler les connexions non sécurisées avant que vous ne les refusiez. Relevez, pour chacune : le client, l'application, le compte, le contrôleur de domaine, le type de liaison. Cette liste est votre plan de correction.

b. Exiger la signature LDAP, sur la stratégie des contrôleurs de domaine :

Default Domain Controllers Policy → Stratégies locales → Options de sécurité

Contrôleur de domaine : conditions requises pour la signature du serveur LDAP
    -> Exiger la signature

c. Le channel binding associe l'authentification à la session TLS qui la transporte, ce qui empêche de la déplacer vers une autre session. Déployez-le par paliers : audit, puis lorsque pris en charge, puis - une fois les clients corrigés - obligatoire.

d. LDAPS pour les applications qui doivent chiffrer leur trafic : le contrôleur de domaine doit disposer d'un certificat adapté, et le port 636 être joignable.

Test-NetConnection dc01.exemple.local -Port 636

6. Signature SMB, et retrait de SMBv1

La signature SMB protège contre la modification du trafic et contre le relais d'authentification. Elle se vérifie séparément côté serveur et côté client :

Get-SmbServerConfiguration |
    Select-Object EnableSecuritySignature, RequireSecuritySignature

Get-SmbClientConfiguration |
    Select-Object EnableSecuritySignature, RequireSecuritySignature
Set-SmbServerConfiguration -EnableSecuritySignature $true `
                           -RequireSecuritySignature $true -Confirm:$false

Set-SmbClientConfiguration -EnableSecuritySignature $true `
                           -RequireSecuritySignature $true -Confirm:$false
Les défauts récents sont asymétriques - ne supposez pas que c'est déjà fait

Les versions récentes de Windows durcissent la signature SMB par défaut, mais pas de la même manière selon le produit. Windows 11 24H2 dans ses éditions Pro, Entreprise et Éducation l'exige en entrée et en sortie. Windows Server 2025 ne l'exige qu'en sortie : un serveur peut donc encore accepter une connexion entrante non signée. Les éditions Famille ne l'exigent ni dans un sens ni dans l'autre. Autrement dit, « on est en 2025, c'est bon par défaut » est faux : vérifiez les deux directions sur chaque type de machine, et posez le réglage explicitement.

SMBv1 est un protocole obsolète et le vecteur historique de propagation de WannaCry. Il ne suffit pas de le désactiver : désinstallez-le, pour qu'aucune réactivation par erreur ne soit possible.

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Trois pratiques complémentaires, recommandées par Microsoft : privilégier Kerberos, éviter les connexions SMB par adresse IP, et ne pas utiliser d'alias DNS de type CNAME pour ces connexions - les trois retombent en NTLM.

7. DNS et DHCP

Kerberos ne fonctionne pas sans une résolution DNS correcte : c'est par DNS qu'un client trouve son contrôleur de domaine et construit les noms de service. Un DNS incohérent produit des symptômes d'authentification qu'on passe des jours à chercher ailleurs.

  • Les machines du domaine pointent sur le DNS du domaine, pas sur un résolveur public. Placer 8.8.8.8 en DNS principal sur une machine jointe au domaine casse la découverte des services.
  • Les transferts de zone sont restreints aux serveurs autorisés, jamais ouverts à tout serveur : une zone AD transférée est une cartographie complète de l'organisation offerte à qui la demande.
  • Les mises à jour dynamiques sont sécurisées lorsque l'architecture le permet.
  • Les serveurs DHCP sont autorisés dans l'annuaire (Get-DhcpServerInDC), afin qu'un serveur non déclaré ne puisse pas distribuer de mauvaises informations DNS.

Le contrôle qui résume tout :

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.exemple.local
Resolve-DnsName -Type SRV _kerberos._tcp.exemple.local

Vérifier que c'est en place

  1. Kerberos : après application, plus aucun événement 4768/4769 avec un type de chiffrement RC4 (0x17) sur une journée pleine - une journée pleine, pas une heure creuse.
  2. krbtgt : Get-ADUser krbtgt -Properties PasswordLastSet renvoie une date récente, et l'authentification du domaine fonctionne toujours après les deux passes.
  3. LDAP : une liaison non signée depuis un client de test est refusée, et plus aucun événement de connexion non sécurisée n'apparaît sur les contrôleurs de domaine.
  4. SMB : RequireSecuritySignature vaut True côté serveur et côté client, sur un contrôleur de domaine, un serveur membre et un poste.
  5. SMBv1 : Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol renvoie Disabled.
  6. Spouleur : Get-Service Spooler sur chaque contrôleur de domaine renvoie un service arrêté et désactivé.
Le piège à connaître

Les mesures de cette page cassent en silence et en différé. Une application qui ne s'authentifie qu'une fois par mois - une clôture comptable, un traitement de fin de trimestre, une sauvegarde annuelle - ne se plaindra pas le jour où vous coupez le protocole dont elle dépend. Elle se plaindra des semaines plus tard, quand personne ne fera plus le lien avec votre changement. C'est la raison pour laquelle les phases d'audit doivent durer au moins un cycle métier complet, et pourquoi vous devez conserver la liste datée de ce que vous avez coupé et quand.

Besoin d'aller plus loin

Kenawek mène ce type de migration protocolaire sur des environnements en production, en commençant par l'inventaire des dépendances qui n'existe presque jamais au démarrage. Parlons-en.

Sources