Durcissement des contrôleurs de domaine : la base DC

Les contrôleurs de domaine sont la cible la plus précieuse de la plupart des environnements Windows : en compromettre un revient, pour un attaquant, à posséder le domaine. Pourtant, les DC sont souvent traités comme de simples serveurs membres : rôles par défaut laissés actifs, accessibles en RDP par la moitié du support, autorisés à naviguer sur Internet « par commodité ». Ce guide détaille les étapes de configuration concrètes qui réduisent la surface d'attaque d'un DC à ce dont il a réellement besoin : l'authentification, la réplication et le DNS.

Tout ce qui suit vient s'ajouter à votre cycle de correctifs existant, sans le remplacer. Considérez-le comme le niveau minimal pour n'importe quel DC, que vous en ayez deux ou deux cents.

Appliquer la base de sécurité Microsoft

Partez de la base de sécurité publiée par Microsoft dans le Security Compliance Toolkit pour le rôle de contrôleur de domaine, plutôt que d'inventer votre propre stratégie à partir de zéro. Les GPO de la base traduisent les recommandations actuelles de Microsoft en matière de stratégie d'audit, d'attribution des droits utilisateur et d'options de sécurité, et elles sont versionnées pour chaque version de Windows Server.

1. Téléchargez auprès de Microsoft la version actuelle du Security Compliance Toolkit (SCT) et la base de sécurité Windows Server correspondant à la version de l'OS de vos DC.
2. Importez les GPO de la base dans votre domaine (liées d'abord à une UO de test) à l'aide du script Baseline-ADImport.ps1 fourni dans le package ou de l'assistant Import Settings de la console de gestion des stratégies de groupe (GPMC). LGPO.exe n'applique les paramètres qu'à la stratégie locale d'une seule machine de test.
3. Comparez la base à vos GPO de DC actuelles avec Get-GPOReport -ReportType Html avant le déploiement, afin de savoir exactement ce qui va changer.
4. Liez la GPO de base à une UO ne contenant que des contrôleurs de domaine (normalement l'UO intégrée Domain Controllers), jamais à la racine du domaine.

# Exporter les GPO liées aux DC pour comparaison avant d'importer la base
Get-GPO -All | Where-Object { (Get-GPInheritance -Target "OU=Domain Controllers,DC=corp,DC=example,DC=com").GpoLinks.DisplayName -contains $_.DisplayName } |
    ForEach-Object { Get-GPOReport -Guid $_.Id -ReportType Html -Path "C:\GPOBackup\$($_.DisplayName).html" }

Réimportez la base à chaque mise à jour publiée par Microsoft ; traitez-la comme de la gestion des correctifs, pas comme un projet ponctuel.

Désactiver le service Spouleur d'impression sur les DC

Le service Spouleur d'impression a été le point d'entrée de plusieurs vulnérabilités critiques, au premier rang desquelles PrintNightmare (CVE-2021-34527), sans compter une longue série de problèmes liés à l'installation de pilotes point-and-print et à des abus de coercition (coercition RPC via le spouleur alimentant un NTLM relay). Aucune de ces fonctionnalités n'est nécessaire sur un contrôleur de domaine.

# Désactiver et arrêter le Spouleur d'impression sur tous les DC
Get-ADDomainController -Filter * | ForEach-Object {
    Invoke-Command -ComputerName $_.HostName -ScriptBlock {
        Stop-Service -Name Spooler -Force
        Set-Service -Name Spooler -StartupType Disabled
    }
}

Imposez ce réglage de manière centralisée par GPO afin qu'il survive aux redémarrages et aux réinstallations :

• Computer Configuration → Policies → Windows Settings → Security Settings → System Services → Print Spooler → définir sur Disabled.

Vérification :

Get-ADDomainController -Filter * | ForEach-Object {
    Get-Service -ComputerName $_.HostName -Name Spooler | Select-Object MachineName, Status, StartType
}

Si une application historique a réellement besoin de services d'impression sur un serveur, c'est le rôle d'un serveur d'impression dédié, hors DC, jamais d'un contrôleur de domaine.

Restreindre l'ouverture de session locale et RDP au seul Tier 0

Tout compte capable d'ouvrir une session interactive ou RDP sur un DC est, dans les faits, un Domain Admin. Appliquez les paramètres d'attribution des droits utilisateur ci-dessous via une GPO liée à l'UO Domain Controllers, et renseignez-les avec un groupe d'administrateurs Tier 0 dédié plutôt qu'avec des groupes larges comme Domain Admins ou Server Admins.

# Vérifier l'appartenance actuelle au droit Allow log on through RDS sur un DC
$dc = "DC01"
secedit /export /cfg C:\Temp\dc01-secpol.cfg /areas USER_RIGHTS
Select-String -Path C:\Temp\dc01-secpol.cfg -Pattern "SeRemoteInteractiveLogonRight"

Associez ces mesures au modèle Tier 0 et accès privilégiés : les administrateurs Tier 0 doivent se connecter depuis des postes d'administration sécurisés (PAW), pas depuis leur portable du quotidien, et l'accès RDP permanent doit être remplacé autant que possible par une élévation juste-à-temps.

Bloquer l'accès Internet sortant des contrôleurs de domaine

Un DC n'a aucune raison légitime de joindre des hôtes Internet arbitraires. Les flux sortants sont un canal post-compromission classique pour les rappels de commande et contrôle et la préparation d'exfiltration. Restreignez les flux sortants des DC au niveau du pare-feu réseau à ce qui est strictement nécessaire à l'exploitation :

• Windows Update / WSUS ou un point de terminaison de gestion des correctifs
• Les sources NTP de synchronisation horaire (si vous n'utilisez pas une hiérarchie de temps interne)
• Les points de terminaison de révocation de certificats/OCSP s'ils sont hébergés publiquement
• Les éventuels points de terminaison de synchronisation d'annuaire nécessaires (par exemple Entra Connect, s'il n'est pas colocalisé)

# Example firewall intent (implement in your perimeter/NGFW, not just Windows Firewall)
DENY  DC-subnet -> ANY (0.0.0.0/0)  port 80,443   [default deny]
ALLOW DC-subnet -> WSUS-server      port 8530,8531
ALLOW DC-subnet -> approved-NTP     port 123

Ne vous reposez pas uniquement sur le Pare-feu Windows Defender : imposez ce filtrage au niveau réseau, afin qu'une modification de stratégie locale sur le DC ne puisse pas rouvrir discrètement les flux sortants.

Priorités de correctifs : ZeroLogon, PetitPotam/coercition, PrintNightmare

Trois classes de vulnérabilités méritent une priorité permanente dans votre cycle de correctifs, car chacune peut mener directement à la compromission du domaine :

ZeroLogon (CVE-2020-1472) : exploite une faille du canal sécurisé Netlogon pour réinitialiser le mot de passe du compte machine d'un DC. Appliquez le correctif complet (le correctif initial de 2020 plus la phase d'application qui impose à tous les clients Netlogon d'utiliser le RPC sécurisé) et confirmez le mode d'application :

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "FullSecureChannelProtection" -ErrorAction SilentlyContinue

Consultez ZeroLogon pour le contexte de la vulnérabilité elle-même.

PetitPotam et les autres techniques de coercition : elles abusent d'interfaces RPC/DCOM pour contraindre un DC à s'authentifier auprès d'un point de terminaison contrôlé par l'attaquant, généralement pour alimenter une attaque NTLM relay contre AD CS ou LDAP. Mesures d'atténuation :

• Activez Extended Protection for Authentication (EPA) sur les points de terminaison d'inscription web AD CS et sur LDAP.
• Désactivez NTLM là où c'est possible ou, au minimum, imposez la signature LDAP/LDAPS et la liaison de canal (channel binding).
• Déployez des filtres RPC pour bloquer les appels non authentifiés vers les interfaces de type EFSRPC/MS-RPRN depuis des hôtes non DC lorsqu'ils ne sont pas nécessaires.

PrintNightmare : traité plus haut par la désactivation du spouleur ; appliquez tout de même les correctifs, car certaines CVE secondaires liées aux pilotes d'impression touchent aussi du code hors spouleur.

Suivez ces trois familles de CVE comme des éléments « à corriger sous 72 heures après publication » dans le SLA de votre gestion des vulnérabilités, indépendamment du rythme habituel du Patch Tuesday.

Sécuriser la synchronisation horaire (w32time)

Kerberos dépend d'une synchronisation horaire avec un décalage maximal de 5 minutes par défaut ; un attaquant capable de manipuler l'horloge d'un DC peut perturber l'authentification ou créer les conditions d'un rejeu de tickets. Assurez-vous que votre émulateur PDC se synchronise sur une source de temps externe de confiance et que tous les autres DC suivent la hiérarchie du domaine ; ne laissez jamais les DC se synchroniser indépendamment sur des serveurs NTP Internet arbitraires.

# Sur l'émulateur PDC
w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update
Restart-Service w32time

# Vérification
w32tm /query /status
w32tm /query /source

Désactiver les rôles et fonctionnalités inutiles

Auditez chaque DC avec Get-WindowsFeature et supprimez tout ce qui dépasse AD DS, DNS et les outils d'administration nécessaires. Les suspects habituels : IIS resté installé après une ancienne installation d'autorité de certification, le client Telnet, SMB1 et des rôles de partage de fichiers inutilisés.

Get-WindowsFeature | Where-Object Installed -eq $true | Select-Object Name, InstallState
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

Synthèse des vérifications

# Contrôle rapide de l'état de durcissement des DC
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    [PSCustomObject]@{
        DC              = $dc
        SpoolerRunning  = (Get-Service -ComputerName $dc -Name Spooler).Status
        SMB1Enabled     = (Get-SmbServerConfiguration -CimSession $dc).EnableSMB1Protocol
        TimeSource      = (w32tm /query /source /computer:$dc)
    }
}

Ce que cela casse

• Les outils d'administration qui se connectent directement en RDP aux DC. Certains agents de sauvegarde, de supervision ou de gestion des correctifs supposent un accès RDP interactif ou une ouverture de session locale sans restriction. Redirigez-les vers des comptes de service disposant de droits délégués explicitement, ou passez à une gestion par agent qui ne nécessite pas de droits d'ouverture de session interactive.
• Les outils historiques dépendant de l'impression qui utilisaient (à tort) un DC comme serveur d'impression de secours.
• Les agents de supervision tiers qui contactent directement Internet depuis le DC ; ils doivent passer par un proxy approuvé ou être déplacés hors du DC.
• Les intégrations proches du NTLM relay qui reposaient sur du LDAP non signé ou sur une inscription AD CS non compatible EPA ; elles doivent être mises à jour pour prendre en charge la signature et la liaison de canal avant que vous ne l'imposiez à l'échelle du domaine.

Combinez ce durcissement avec les pratiques décrites dans Durcissement de Kerberos et Sécurité des objets et des ACL : un OS de DC durci n'est que la moitié du tableau si les ACL de l'annuaire et la configuration Kerberos restent permissives.