1. Modèle de menace et administration en tiers

1.1 Pourquoi AD est la cible n°1

Dans la quasi-totalité des compromissions de SI Windows (rançongiciel, espionnage), l'attaquant suit le même schéma : un poste utilisateur compromis, récupération d'identifiants en mémoire ou sur le réseau, mouvement latéral, puis prise de contrôle d'un compte disposant de droits sur le domaine. Une fois Domain Admins ou l'équivalent obtenu, le chiffrement ou l'exfiltration de tout le parc se fait par GPO ou par tâche planifiée en quelques minutes.

Le problème central n'est pas une vulnérabilité logicielle, mais l'exposition des identifiants privilégiés : un administrateur de domaine qui ouvre une session RDP sur un serveur applicatif laisse des éléments réutilisables (ticket Kerberos, hash NT, jeton) sur une machine bien moins protégée qu'un DC. Le durcissement AD consiste donc d'abord à cloisonner où les comptes privilégiés s'authentifient, puis à réduire les chemins d'attaque (ACL, délégations, protocoles faibles), et enfin à détecter.

1.2 Le modèle en tiers

Le modèle historique de Microsoft (Tier 0/1/2) reste la base pédagogique et opérationnelle la plus utilisée, même si Microsoft le présente désormais dans un cadre plus large, l'Enterprise Access Model (plan de contrôle, plan de gestion, plan de données, accès utilisateurs et applicatifs, intégrant le cloud).

Tier	Contenu	Comptes associés	Règle d'or
Tier 0	DC, AD, ADCS (PKI d'entreprise), ADFS, Entra Connect / Cloud Sync, serveurs de sauvegarde des DC, hyperviseurs hébergeant des DC, outils de gestion des identités, PAW Tier 0	Domain/Enterprise/Schema Admins, Administrators du domaine, comptes de service de ces outils	Ne s'authentifient jamais sur un actif Tier 1 ou 2
Tier 1	Serveurs membres, applications, bases de données, middleware	Administrateurs serveurs, comptes de service applicatifs	Pas d'ouverture de session sur les postes de travail
Tier 2	Postes de travail, imprimantes, terminaux	Support / helpdesk	Pas de droits sur les serveurs ni sur AD

1.3 Traduction concrète dans l'AD

Le modèle se matérialise par une arborescence d'OU dédiée, des groupes par tier, et des droits d'ouverture de session refusés par GPO.

OU=Admin,DC=contoso,DC=local
  OU=Tier0
    OU=Accounts        (comptes adm-t0-*)
    OU=Groups          (GRP-T0-*)
    OU=Devices         (PAW Tier 0)
    OU=ServiceAccounts
  OU=Tier1
    OU=Accounts / Groups / ServiceAccounts
  OU=Tier2
    OU=Accounts / Groups / ServiceAccounts
OU=Servers  (Tier 1)
OU=Workstations (Tier 2)

# Creation de la structure (extrait)
$base = "DC=contoso,DC=local"
New-ADOrganizationalUnit -Name "Admin" -Path $base -ProtectedFromAccidentalDeletion $true
foreach ($t in "Tier0","Tier1","Tier2") {
    New-ADOrganizationalUnit -Name $t -Path "OU=Admin,$base"
    foreach ($s in "Accounts","Groups","ServiceAccounts","Devices") {
        New-ADOrganizationalUnit -Name $s -Path "OU=$t,OU=Admin,$base"
    }
}

# Bloquer l'heritage des GPO "poste de travail" sur l'OU Admin
Set-GPInheritance -Target "OU=Admin,$base" -IsBlocked Yes

1.4 Les refus d'ouverture de session (cœur du cloisonnement)

GPO appliquée à	Droits utilisateur à configurer (Deny)	Groupes refusés
OU Servers (Tier 1)	Deny log on locally, Deny log on through Remote Desktop Services, Deny access from the network, Deny log on as a batch job, Deny log on as a service	GRP-T0-Admins, Domain Admins, Enterprise Admins, GRP-T2-Admins
OU Workstations (Tier 2)	Mêmes droits	GRP-T0-Admins, Domain Admins, Enterprise Admins, GRP-T1-Admins
OU Domain Controllers	Deny log on through RDS / locally	GRP-T1-Admins, GRP-T2-Admins

2. PAW et comptes d'administration séparés

2.1 Comptes séparés par tier

Un administrateur dispose d'un compte bureautique sans aucun privilège (messagerie, navigation) et d'un compte par tier qu'il administre. Convention courante : jdupont, adm-t1-jdupont, adm-t0-jdupont. Les comptes d'administration :

• n'ont pas de boîte aux lettres ni de licence bureautique, ne sont pas synchronisés vers Entra ID (les rôles cloud privilégiés utilisent des comptes cloud-only, voir Entra ID) ;
• ont l'attribut « Account is sensitive and cannot be delegated » et sont membres de Protected Users (Tier 0 a minima) ;
• utilisent une authentification forte : carte à puce / Windows Hello for Business, ou au minimum un mot de passe long (20+) unique ;
• sont nominatifs ; le compte intégré Administrator (RID 500) est conservé avec un mot de passe long sous séquestre, pour la reprise uniquement.

# Marquer tous les comptes de l'OU Tier0 comme non delegables
Get-ADUser -SearchBase "OU=Accounts,OU=Tier0,OU=Admin,DC=contoso,DC=local" -Filter * |
    Set-ADAccountControl -AccountNotDelegated $true

# Comptes privilegies (adminCount=1) encore delegables : a corriger
Get-ADUser -Filter 'adminCount -eq 1 -and Enabled -eq $true' -Properties AccountNotDelegated |
    Where-Object { -not $_.AccountNotDelegated } | Select-Object SamAccountName

# Comptes privilegies avec mot de passe jamais change depuis plus d'un an
Get-ADUser -Filter 'adminCount -eq 1' -Properties PasswordLastSet |
    Where-Object PasswordLastSet -lt (Get-Date).AddDays(-365) |
    Select-Object SamAccountName, PasswordLastSet

2.2 Vider les groupes privilégiés

Domain Admins doit contenir quelques comptes (souvent 2 à 5), Enterprise Admins et Schema Admins doivent être vides en temps normal (on y ajoute un compte le temps d'une opération). Ne pas oublier les groupes « opérateurs » hérités, qui offrent des chemins vers Tier 0 :

Groupe	Risque	Cible
Account Operators	Peut modifier la plupart des comptes et groupes non protégés	Vide
Server Operators	Ouverture de session sur DC, modification de services	Vide
Backup Operators	Lecture de la base NTDS et des ruches de registre d'un DC	Vide ou compte de service Tier 0 dédié
Print Operators	Chargement de pilotes sur les DC	Vide
DnsAdmins	Historiquement, chargement d'une DLL dans le service DNS des DC	Vide / Tier 0
Group Policy Creator Owners	Création de GPO	Tier 0 uniquement

# Inventaire recursif des groupes sensibles
$groups = "Domain Admins","Enterprise Admins","Schema Admins","Administrators",
          "Account Operators","Server Operators","Backup Operators","Print Operators","DnsAdmins"
foreach ($g in $groups) {
    Get-ADGroupMember -Identity $g -Recursive -ErrorAction SilentlyContinue |
        Select-Object @{n='Groupe';e={$g}}, SamAccountName, objectClass
}

2.3 Postes d'administration privilégiés (PAW)

Un PAW est un poste dédié à l'administration d'un tier, durci et sans usage bureautique. C'est la seule machine depuis laquelle un compte Tier 0 ouvre une session. Caractéristiques attendues :

• Matériel dédié (ou au minimum OS hôte PAW avec VM bureautique, jamais l'inverse) ; Secure Boot, TPM, BitLocker, Credential Guard activé ;
• pas de navigation Internet ni de messagerie ; flux sortants limités aux cibles administrées (pare-feu local + filtrage réseau) ;
• contrôle d'application (WDAC / App Control for Business ou AppLocker) ;
• géré depuis Tier 0 (OU dédiée, GPO dédiées, pas de console de gestion Tier 1/2 qui y pousse du code) ;
• connexion aux serveurs via RDP en Restricted Admin ou Remote Credential Guard, ou de préférence via outils distants (RSAT, PowerShell remoting) qui n'exposent pas d'identifiants réutilisables.

# Connexion RDP sans deleguer d'identifiants reutilisables
mstsc.exe /remoteGuard /v:srv-app01.contoso.local
# ou mode Restricted Admin (necessite que la cible l'autorise)
mstsc.exe /restrictedAdmin /v:srv-app01.contoso.local

# Verifier que Credential Guard tourne sur le PAW
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
# 1 = Credential Guard actif

3. Protected Users, Authentication Policies et Silos

3.1 Le groupe Protected Users

Disponible depuis Windows Server 2012 R2, ce groupe global applique des protections côté DC et côté client, non désactivables par l'utilisateur :

Protection	Effet
Pas d'authentification NTLM	Le hash NT n'est pas utilisable pour s'authentifier ; pas de cache NTLM sur le client
Kerberos sans DES ni RC4 en pré-authentification	AES obligatoire
Pas de délégation	Ni contrainte ni non contrainte
TGT limité à 4 heures	Non renouvelable au-delà ; réauthentification
Pas de cache d'identifiants	Pas d'ouverture de session hors ligne (cached logon) avec ces comptes
CredSSP / Digest	Identifiants non conservés en clair

Add-ADGroupMember -Identity "Protected Users" -Members "adm-t0-jdupont"

# Verifier l'impact : evenements de rejet sur les DC
# Journal : Applications and Services Logs\Microsoft\Windows\Authentication
#   ProtectedUserFailures-DomainController / ProtectedUserSuccesses-DomainController
# (journaux desactives par defaut : les activer avant le test)
wevtutil sl "Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController" /e:true

3.2 Authentication Policies et Silos

Les silos d'authentification (niveau fonctionnel de domaine 2012 R2 minimum) permettent d'exprimer côté KDC : « ce compte Tier 0 ne peut obtenir un TGT que depuis une machine du silo Tier 0 ». C'est le moyen technique le plus robuste de faire respecter le modèle en tiers, car la restriction est appliquée par le DC et non par la machine cible.

Prérequis :

• GPO sur les DC : KDC support for claims, compound authentication and Kerberos armoring = Supported (ou Always provide claims) ;
• GPO sur les clients du silo (PAW) : Kerberos client support for claims, compound authentication and Kerberos armoring = Enabled ;
• les comptes du silo doivent pouvoir faire du Kerberos (pas de NTLM : cohérent avec Protected Users).

# 1. Politique : TGT de 4h, utilisable uniquement depuis une machine du silo
New-ADAuthenticationPolicy -Name "AP-Tier0" `
    -UserTGTLifetimeMins 240 `
    -UserAllowedToAuthenticateFrom 'O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == "Silo-Tier0"))' `
    -ProtectedFromAccidentalDeletion $true
# (pas de -Enforce : mode audit dans un premier temps)

# 2. Silo associe a la politique
New-ADAuthenticationPolicySilo -Name "Silo-Tier0" `
    -UserAuthenticationPolicy "AP-Tier0" `
    -ComputerAuthenticationPolicy "AP-Tier0" `
    -ServiceAuthenticationPolicy "AP-Tier0" `
    -ProtectedFromAccidentalDeletion $true

# 3. Autoriser puis affecter les membres (comptes ET machines : PAW + DC)
$members = Get-ADUser -SearchBase "OU=Accounts,OU=Tier0,OU=Admin,DC=contoso,DC=local" -Filter *
$members += Get-ADComputer -SearchBase "OU=Devices,OU=Tier0,OU=Admin,DC=contoso,DC=local" -Filter *
$members += Get-ADComputer -SearchBase "OU=Domain Controllers,DC=contoso,DC=local" -Filter *
foreach ($m in $members) {
    Grant-ADAuthenticationPolicySiloAccess -Identity "Silo-Tier0" -Account $m
    if ($m.objectClass -eq 'user') { Set-ADUser $m -AuthenticationPolicySilo "Silo-Tier0" }
    else { Set-ADComputer $m -AuthenticationPolicySilo "Silo-Tier0" }
}

# 4. Apres analyse des journaux d'audit : passage en mode bloquant
Set-ADAuthenticationPolicy -Identity "AP-Tier0" -Enforce $true
Set-ADAuthenticationPolicySilo -Identity "Silo-Tier0" -Enforce $true

4. Windows LAPS

4.1 Pourquoi et quoi

Un mot de passe administrateur local identique sur tout le parc transforme la compromission d'un poste en compromission de tous (réutilisation du hash NT). Windows LAPS, intégré nativement à Windows depuis les mises à jour d'avril 2023 (Windows 10/11, Windows Server 2019 et ultérieurs), remplace l'ancien « Microsoft LAPS » (MSI, attribut ms-Mcs-AdmPwd en clair), désormais déprécié.

Critère	Legacy LAPS	Windows LAPS
Installation	MSI + extension CSE	Intégré à l'OS
Stockage	ms-Mcs-AdmPwd (clair, protégé par ACL)	msLAPS-Password ou msLAPS-EncryptedPassword (chiffré)
Chiffrement	Non	Oui (DFL 2016 requis), déchiffrable par un principal désigné
Historique	Non	Oui (avec chiffrement)
Mot de passe DSRM des DC	Non	Oui (chiffrement obligatoire)
Rotation après usage	Non	Post-authentication actions (rotation + déconnexion / redémarrage)
Entra ID	Non	Oui (machines jointes Entra)
Nouveautés Server 2025 / Win 11 24H2	-	Gestion automatique du compte (création, renommage, désactivation), phrases de passe, détection de retour arrière d'image

4.2 Déploiement

# 1. Etendre le schema (une fois, en Schema Admin)
Update-LapsADSchema

# 2. Autoriser les ordinateurs d'une OU a ecrire leur propre mot de passe
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=contoso,DC=local"
Set-LapsADComputerSelfPermission -Identity "OU=Servers,DC=contoso,DC=local"

# 3. Droits de lecture / reinitialisation : groupes par tier
Set-LapsADReadPasswordPermission  -Identity "OU=Workstations,DC=contoso,DC=local" -AllowedPrincipals "CONTOSO\GRP-T2-LAPS-Read"
Set-LapsADResetPasswordPermission -Identity "OU=Workstations,DC=contoso,DC=local" -AllowedPrincipals "CONTOSO\GRP-T2-LAPS-Read"
Set-LapsADReadPasswordPermission  -Identity "OU=Servers,DC=contoso,DC=local" -AllowedPrincipals "CONTOSO\GRP-T1-LAPS-Read"

# 4. Auditer qui peut lire (droits etendus) - inclut les heritages oublies
Find-LapsADExtendedRights -Identity "OU=Workstations,DC=contoso,DC=local"

GPO : Computer Configuration > Administrative Templates > System > LAPS.

Paramètre	Valeur recommandée
Configure password backup directory	Active Directory
Password Settings	Complexité large (ou phrase de passe), longueur 20+, âge 30 jours (7 pour les serveurs sensibles)
Enable password encryption	Enabled
Configure authorized password decryptors	Groupe par tier (sinon : Domain Admins par défaut)
Configure size of encrypted password history	12
Post-authentication actions	Reset password and logoff (délai 8 à 24 h)
Enable password backup for DSRM accounts	Enabled (GPO liée à l'OU Domain Controllers)
Name of administrator account to manage	Uniquement si compte personnalisé (sinon RID 500)

4.3 Lecture et opérations

# Lire le mot de passe courant (dechiffre si le lecteur est autorise)
Get-LapsADPassword -Identity "PC-0142" -AsPlainText

# Historique
Get-LapsADPassword -Identity "PC-0142" -IncludeHistory -AsPlainText

# Forcer une rotation immediate (cote AD : expiration a maintenant)
Set-LapsADPasswordExpirationTime -Identity "PC-0142"

# Sur la machine : forcer le traitement de la politique, consulter le journal
Invoke-LapsPolicyProcessing
Get-WinEvent -LogName "Microsoft-Windows-LAPS/Operational" -MaxEvents 20

# Couverture : machines actives sans mot de passe LAPS
Get-ADComputer -Filter 'Enabled -eq $true' -Properties msLAPS-PasswordExpirationTime, LastLogonDate |
    Where-Object { -not $_.'msLAPS-PasswordExpirationTime' -and $_.LastLogonDate -gt (Get-Date).AddDays(-30) } |
    Select-Object Name, LastLogonDate

5. Kerberos : AES, gMSA/dMSA, SPN, roasting

5.1 Types de chiffrement : sortir de RC4

RC4-HMAC utilise directement le hash NT comme clé : un ticket de service chiffré en RC4 peut être attaqué hors ligne beaucoup plus vite qu'un ticket AES. Microsoft a engagé la désactivation progressive de RC4 dans Kerberos (annonces et mises à jour 2025-2026, avec phases d'audit puis d'application) : vérifiez l'état exact selon votre niveau de correctifs, mais l'objectif est clair, AES uniquement.

Valeur msDS-SupportedEncryptionTypes	Signification
0 / non défini	Comportement par défaut du DC (historiquement RC4 pour les comptes utilisateurs de service)
0x4 (4)	RC4 seul
0x8 (8)	AES128
0x10 (16)	AES256
0x18 (24)	AES128 + AES256 (cible)
0x1C (28)	RC4 + AES (transition)

# Comptes avec SPN et leur type de chiffrement declare
Get-ADUser -Filter 'servicePrincipalName -like "*"' `
    -Properties servicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
    Select-Object SamAccountName, @{n='EncTypes';e={$_.'msDS-SupportedEncryptionTypes'}}, PasswordLastSet

# Forcer AES sur un compte de service
Set-ADUser svc-app01 -KerberosEncryptionType AES128,AES256

# ATTENTION : un compte dont le mot de passe n'a pas ete change depuis
# la creation du domaine 2008+ peut ne pas avoir de cle AES -> le changer.

# Sur les DC, mesurer l'usage residuel de RC4 (4769 / 4768, champ Ticket Encryption Type)
#   0x17 = RC4-HMAC, 0x12 = AES256, 0x11 = AES128
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 5000 |
    Where-Object { $_.Properties[5].Value -eq 0x17 } |
    Group-Object { $_.Properties[2].Value } | Sort-Object Count -Descending |
    Select-Object Count, Name

5.2 Comptes de service : gMSA puis dMSA

Un compte de service utilisateur classique (mot de passe fixe, SPN, souvent membre de groupes privilégiés) est la cible idéale du kerberoasting. Les gMSA (group Managed Service Accounts) ont un mot de passe de 240 octets aléatoire, changé automatiquement tous les 30 jours, récupérable uniquement par les machines autorisées.

# Prerequis unique par foret : cle racine KDS
# (en production, attendre la replication : ~10 h apres creation)
Add-KdsRootKey -EffectiveImmediately

# Creer le gMSA, utilisable par les membres d'un groupe d'ordinateurs
New-ADServiceAccount -Name "gmsa-sql01" `
    -DNSHostName "gmsa-sql01.contoso.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "GRP-T1-SQL-Hosts" `
    -KerberosEncryptionType AES128,AES256 `
    -ServicePrincipalNames "MSSQLSvc/sql01.contoso.local:1433","MSSQLSvc/sql01.contoso.local"

# Sur le serveur (apres redemarrage pour prise en compte du groupe)
Install-ADServiceAccount -Identity gmsa-sql01
Test-ADServiceAccount -Identity gmsa-sql01   # doit renvoyer True
# Le service est ensuite configure avec CONTOSO\gmsa-sql01$ et un mot de passe vide

# Qui peut lire le mot de passe d'un gMSA (a auditer : equivaut a etre le compte)
Get-ADServiceAccount gmsa-sql01 -Properties PrincipalsAllowedToRetrieveManagedPassword |
    Select-Object -ExpandProperty PrincipalsAllowedToRetrieveManagedPassword

dMSA (delegated Managed Service Account), introduit avec Windows Server 2025, vise la migration des comptes de service existants : le dMSA hérite des droits du compte legacy, le compte legacy est ensuite désactivé, et l'identité est liée aux machines autorisées.

# Schema simplifie de migration (Windows Server 2025, DC 2025 requis)
New-ADServiceAccount -Name "dmsa-app01" -DNSHostName "dmsa-app01.contoso.local" `
    -CreateDelegatedServiceAccount -KerberosEncryptionType AES256
Start-ADServiceAccountMigration    -Identity "dmsa-app01" -SupersededAccount "CN=svc-app01,OU=ServiceAccounts,OU=Tier1,OU=Admin,DC=contoso,DC=local"
# ... periode d'observation : le service s'authentifie et le dMSA apprend ses usages ...
Complete-ADServiceAccountMigration -Identity "dmsa-app01" -SupersededAccount "CN=svc-app01,OU=ServiceAccounts,OU=Tier1,OU=Admin,DC=contoso,DC=local"

5.3 Kerberoasting et AS-REP roasting : prévention et détection

Technique	Condition côté AD	Prévention	Détection
Kerberoasting	Compte utilisateur avec SPN, mot de passe humain, RC4 accepté	gMSA/dMSA ; sinon mot de passe 30+ caractères aléatoire, AES only ; retirer les SPN inutiles ; aucun compte à SPN dans un groupe privilégié	4769 en RC4 (0x17) vers des comptes utilisateurs ; un même compte demandant des tickets pour de nombreux SPN en peu de temps ; compte « leurre » à SPN jamais utilisé légitimement
AS-REP roasting	Compte avec « Do not require Kerberos preauthentication »	Supprimer le drapeau (aucun besoin moderne)	4768 avec Pre-Authentication Type = 0

# Comptes sans pre-authentification Kerberos (doit etre vide)
Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' | Select-Object SamAccountName
# Correction
Set-ADAccountControl -Identity compte-legacy -DoesNotRequirePreAuth $false

# Comptes utilisateurs avec SPN membres d'un groupe privilegie (priorite absolue)
Get-ADUser -Filter 'servicePrincipalName -like "*" -and adminCount -eq 1' |
    Select-Object SamAccountName

# SPN dupliques (cause classique d'echec Kerberos -> repli NTLM)
setspn -X -F

6. NTLM : audit puis restriction

6.1 Contexte

NTLM n'offre pas d'authentification mutuelle, se relaie (NTLM relay vers LDAP, SMB, HTTP/ADCS) et accepte le hash NT comme secret (pass-the-hash). Microsoft a annoncé en 2024 la dépréciation de NTLM (toutes versions) au profit de Kerberos et de ses extensions (IAKerb, KDC local), et NTLMv1 a été retiré de Windows 11 24H2 et Windows Server 2025. La suppression totale de NTLM reste un chantier de longue haleine : l'approche réaliste est audit → réduction → exceptions documentées → blocage.

6.2 Étape 1 : interdire NTLMv1 et LM

# GPO : Network security: LAN Manager authentication level
#   = Send NTLMv2 response only. Refuse LM & NTLM   (valeur 5)
# Equivalent registre :
# HKLM\SYSTEM\CurrentControlSet\Control\Lsa  LmCompatibilityLevel = 5

# GPO : Network security: Do not store LAN Manager hash value on next password change = Enabled

# Detection NTLMv1 residuel sur les DC (4624, champ "Package Name (NTLM only)")
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20000 |
    Where-Object { $_.Message -match 'NTLM V1' } |
    Select-Object TimeCreated, @{n='Detail';e={($_.Message -split "`n" | Select-String 'Workstation Name|Account Name|Source Network Address') -join ' | '}}

6.3 Étape 2 : auditer tout NTLM

GPO (Security Options)	Où	Valeur
Network security: Restrict NTLM: Audit NTLM authentication in this domain	DC	Enable all
Network security: Restrict NTLM: Audit Incoming NTLM Traffic	Serveurs / DC	Enable auditing for all accounts
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers	Clients	Audit all

Les événements arrivent dans Applications and Services Logs\Microsoft\Windows\NTLM\Operational (8001 à 8004 : 8004 sur les DC indique le compte, la machine source et le serveur cible). Agrégez-les dans le SIEM pendant plusieurs semaines pour bâtir l'inventaire des flux NTLM.

# Top des couples (serveur cible, compte) en NTLM vus par un DC
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -FilterXPath "*[System[EventID=8004]]" -MaxEvents 20000 |
    ForEach-Object { $x = [xml]$_.ToXml(); [pscustomobject]@{
        Serveur = ($x.Event.EventData.Data | ? Name -eq 'SChannelName').'#text'
        Compte  = ($x.Event.EventData.Data | ? Name -eq 'UserName').'#text'
        Source  = ($x.Event.EventData.Data | ? Name -eq 'WorkstationName').'#text' } } |
    Group-Object Serveur, Compte | Sort-Object Count -Descending | Select-Object -First 30 Count, Name

6.4 Causes habituelles de NTLM et correction

Cause	Correction
Accès par adresse IP (\\192.0.2.10\partage)	Utiliser le FQDN ; Kerberos par IP n'est possible qu'avec un SPN IP explicite (déconseillé)
SPN absent ou dupliqué	setspn -Q / setspn -X, enregistrer le SPN sur le bon compte
Alias DNS (CNAME) sans SPN	setspn -S HTTP/alias.contoso.local svc-web
Application codée en dur sur NTLM	Configuration « Negotiate » / mise à jour éditeur, sinon exception
Machine hors domaine, appliance, NAS	Kerberos si supporté, sinon exception documentée et surveillée
Accès inter-forêts sans approbation adaptée	Vérifier routage des suffixes / approbation

6.5 Étape 3 : restreindre

Quand l'inventaire est maîtrisé : Restrict NTLM: NTLM authentication in this domain = Deny for domain accounts to domain servers (ou plus strict), avec la liste d'exceptions Add server exceptions in this domain. Commencez par les comptes Tier 0 (Protected Users le fait déjà pour eux), puis les serveurs Tier 0 (refus NTLM entrant sur les DC hors exceptions), puis le reste.

7. SMB signing, LDAP signing et channel binding

7.1 Pourquoi

Le relais NTLM consiste à rejouer une authentification interceptée vers un autre service. La signature (SMB, LDAP) et le channel binding (LDAPS, HTTPS/EPA) lient l'authentification à la session ou au canal TLS, ce qui rend le relais inopérant. C'est le complément indispensable de la réduction de NTLM.

7.2 SMB

# Etat cote serveur et client
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, RequireSecuritySignature, EncryptData
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature

# Exiger la signature (equivalent GPO "Microsoft network server/client: Digitally sign communications (always)")
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

# Supprimer SMBv1
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# Verifier les sessions en cours (Signed / Dialect)
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted
Get-SmbSession    | Select-Object ClientComputerName, ClientUserName, Dialect, Signed

7.3 LDAP signing et channel binding

Mesure	GPO / registre	Phase audit	Phase application
LDAP signing (DC)	Domain controller: LDAP server signing requirements	Événements 2887 (synthèse quotidienne) et 2889 (détail par client, journal Directory Service)	Require signing
LDAP signing (clients)	Network security: LDAP client signing requirements	-	Negotiate signing (minimum) / Require signing
Channel binding LDAPS	Domain controller: LDAP server channel binding token requirements (registre LdapEnforceChannelBinding : 0 / 1 / 2)	Événements 3039 à 3041	1 = When supported, puis 2 = Always

# Activer la journalisation detaillee des binds LDAP non signes (2889) sur un DC
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" /v "16 LDAP Interface Events" /t REG_DWORD /d 2 /f

# Extraire les clients fautifs
Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2889} -MaxEvents 2000 |
    ForEach-Object { $x=[xml]$_.ToXml(); [pscustomobject]@{
        Client = $x.Event.EventData.Data[0]; Compte = $x.Event.EventData.Data[1] } } |
    Group-Object Client, Compte | Sort-Object Count -Descending

# Remettre le niveau de log a 0 apres analyse (volumetrie)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" /v "16 LDAP Interface Events" /t REG_DWORD /d 0 /f

7.4 HTTP : EPA et services web d'ADCS

Les services d'inscription web d'ADCS (Web Enrollment, CES) et d'autres services IIS en authentification Windows sont des cibles de relais NTLM. Exigez HTTPS + Extended Protection for Authentication (EPA), désactivez NTLM sur ces sites, ou retirez ces rôles s'ils ne servent pas. Détail dans PKI et certificats.

8. Délégations Kerberos

8.1 Les trois mécanismes

Type	Attribut	Risque	Recommandation
Non contrainte	UAC TRUSTED_FOR_DELEGATION	Le serveur reçoit et garde en mémoire le TGT de tout utilisateur qui s'y connecte, y compris d'un DC si on force celui-ci à s'authentifier (coercition)	Interdite hors DC. Migrer vers contrainte / RBCD
Contrainte (KCD)	msDS-AllowedToDelegateTo (+ TRUSTED_TO_AUTH_FOR_DELEGATION si transition de protocole)	Si le compte est compromis, usurpation de n'importe quel utilisateur vers les SPN listés (avec transition de protocole : sans même que l'utilisateur se connecte)	Liste minimale, pas de SPN de DC (ldap/, cifs/ d'un DC = Tier 0)
RBCD (basée sur la ressource)	msDS-AllowedToActOnBehalfOfOtherIdentity sur la cible	Quiconque peut écrire cet attribut sur une machine peut s'y faire passer pour un admin	Auditer qui peut écrire l'attribut ; MachineAccountQuota = 0

8.2 Audit

# Delegation non contrainte (hors DC)
Get-ADComputer -Filter 'TrustedForDelegation -eq $true -and PrimaryGroupID -ne 516' |
    Select-Object Name, DistinguishedName
Get-ADUser -Filter 'TrustedForDelegation -eq $true' | Select-Object SamAccountName

# Delegation contrainte (avec ou sans transition de protocole)
Get-ADObject -Filter 'msDS-AllowedToDelegateTo -like "*"' `
    -Properties msDS-AllowedToDelegateTo, userAccountControl |
    Select-Object Name, @{n='T2A4D';e={[bool]($_.userAccountControl -band 0x1000000)}},
                  @{n='Cibles';e={$_.'msDS-AllowedToDelegateTo' -join ', '}}

# RBCD configuree
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
    Where-Object 'msDS-AllowedToActOnBehalfOfOtherIdentity' |
    Select-Object Name, @{n='Autorises';e={$_.'msDS-AllowedToActOnBehalfOfOtherIdentity'.Access.IdentityReference -join ', '}}

# Quota de creation de machines par les utilisateurs (defaut : 10)
Get-ADObject (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota |
    Select-Object ms-DS-MachineAccountQuota
Set-ADDomain -Identity contoso.local -Replace @{"ms-DS-MachineAccountQuota"="0"}

8.3 Réduire la surface de coercition

La délégation non contrainte est surtout dangereuse combinée à la coercition d'authentification (forcer un DC à s'authentifier vers une machine contrôlée, via le spouleur d'impression, EFSRPC, etc.). Mesures :

• Désactiver le service Print Spooler sur les DC et les serveurs Tier 0 qui n'impriment pas ;
• appliquer les correctifs EFSRPC / DFS et filtrer les RPC inutiles (filtres RPC, pare-feu Windows entre tiers) ;
• bloquer les flux SMB/HTTP sortants des DC vers les postes de travail (un DC n'a aucune raison de s'authentifier vers un poste) ;
• marquer les comptes sensibles AccountNotDelegated / Protected Users.

# Spooler sur les DC
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName {
    Stop-Service Spooler -Force; Set-Service Spooler -StartupType Disabled
    Get-Service Spooler | Select-Object PSComputerName, Status, StartType }

9. ACL dangereuses, AdminSDHolder et DCSync

9.1 Les droits qui équivalent à un contrôle total

Droit	Sur	Conséquence
GenericAll / GenericWrite / WriteDacl / WriteOwner	Utilisateur, groupe, ordinateur, OU, GPO	Prise de contrôle de l'objet (reset de mot de passe, ajout de membre, ajout d'ACE, modification de GPO)
User-Force-Change-Password (extended right)	Utilisateur	Réinitialisation du mot de passe
WriteProperty member (Self-Membership)	Groupe	Ajout à un groupe privilégié
WriteProperty servicePrincipalName	Utilisateur	Rend le compte « kerberoastable »
WriteProperty msDS-KeyCredentialLink	Utilisateur / ordinateur	Ajout d'une clé d'authentification (shadow credentials)
WriteProperty gPLink	OU / domaine	Liaison d'une GPO malveillante
Droits de réplication	Racine du domaine	DCSync : extraction de tous les hashes (dont krbtgt)

Ces ACE s'accumulent avec le temps : délégations helpdesk trop larges, installations d'Exchange (historiquement, droits WriteDacl sur le domaine), outils tiers, comptes de migration jamais nettoyés. Leur visualisation en graphe (BloodHound, section 13) est bien plus efficace que la lecture d'ACL objet par objet.

9.2 AdminSDHolder et SDProp

Le conteneur CN=AdminSDHolder,CN=System,DC=contoso,DC=local porte l'ACL de référence des objets protégés (membres directs ou indirects de Domain Admins, Administrators, Enterprise Admins, Schema Admins, opérateurs, krbtgt...). Le processus SDProp, exécuté par le PDC Emulator toutes les 60 minutes, réécrit l'ACL de ces objets à partir d'AdminSDHolder et pose adminCount=1.

• Persistance : une ACE ajoutée sur AdminSDHolder se propage à tous les comptes privilégiés et revient après chaque nettoyage. AdminSDHolder doit être audité (SACL + événement 5136) et comparé à une référence.
• Orphelins : un compte retiré d'un groupe protégé garde adminCount=1 et une ACL sans héritage. Il faut le nettoyer manuellement.

# ACL actuelle d'AdminSDHolder (a comparer a une reference exportee)
$dn = "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:$dn").Access |
    Select-Object IdentityReference, ActiveDirectoryRights, ObjectType, AccessControlType |
    Sort-Object IdentityReference | Format-Table -AutoSize

# Comptes adminCount=1 qui ne sont plus dans aucun groupe protege (orphelins)
$prot = foreach ($g in "Domain Admins","Enterprise Admins","Schema Admins","Administrators",
                       "Account Operators","Server Operators","Backup Operators","Print Operators") {
    Get-ADGroupMember $g -Recursive -ErrorAction SilentlyContinue | Select-Object -Expand SamAccountName }
Get-ADUser -Filter 'adminCount -eq 1' | Where-Object { $_.SamAccountName -notin $prot -and $_.SamAccountName -ne 'krbtgt' } |
    Select-Object SamAccountName
# Nettoyage : adminCount a vide puis reactivation de l'heritage
# Set-ADUser compte -Clear adminCount ; puis Securite avancee > Activer l'heritage

9.3 DCSync : qui a les droits de réplication ?

Le protocole de réplication (MS-DRSR) permet à un DC de demander les secrets à un autre. Tout principal disposant des deux droits étendus DS-Replication-Get-Changes et DS-Replication-Get-Changes-All sur la racine du domaine peut en faire autant depuis n'importe quelle machine. En dehors des DC, d'Enterprise/Domain Admins, Administrators et éventuellement du compte de connecteur Entra Connect (synchronisation des hashes), personne ne doit les avoir.

Droit étendu	GUID
DS-Replication-Get-Changes	1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
DS-Replication-Get-Changes-All	1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
DS-Replication-Get-Changes-In-Filtered-Set	89e95b76-444d-4c62-991a-0facbeda640c

# Liste des principaux ayant les droits de replication sur le domaine
Import-Module ActiveDirectory
$domDN = (Get-ADDomain).DistinguishedName
$guids = @{ '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'='Get-Changes'
            '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'='Get-Changes-All'
            '89e95b76-444d-4c62-991a-0facbeda640c'='Get-Changes-In-Filtered-Set' }
(Get-Acl "AD:$domDN").Access |
    Where-Object { $guids.ContainsKey($_.ObjectType.Guid) -or $_.ActiveDirectoryRights -match 'GenericAll' } |
    Select-Object IdentityReference, ActiveDirectoryRights,
                  @{n='Droit';e={ $guids[$_.ObjectType.Guid] }}, AccessControlType |
    Sort-Object IdentityReference

Détection : événement 4662 sur les DC (nécessite l'audit « Directory Service Access » et une SACL sur la racine du domaine, présente par défaut pour Everyone en succès) dont les propriétés contiennent l'un des GUID ci-dessus et dont le compte n'est pas un compte d'ordinateur de DC. Microsoft Defender for Identity détecte nativement ce scénario (réplication demandée par une machine qui n'est pas un DC), ce qui est plus fiable que la corrélation d'événements.

9.4 GPO et objets Tier 0

# Qui peut modifier les GPO liees aux DC ?
$gpos = (Get-GPInheritance -Target "OU=Domain Controllers,$((Get-ADDomain).DistinguishedName)").GpoLinks
foreach ($l in $gpos) {
    Get-GPPermission -Guid $l.GpoId -All |
        Where-Object { $_.Permission -in 'GpoEdit','GpoEditDeleteModifySecurity' } |
        Select-Object @{n='GPO';e={$l.DisplayName}}, @{n='Qui';e={$_.Trustee.Name}}, Permission
}
# Toute entree hors groupes Tier 0 est un chemin d'escalade.

10. ADCS et rotation du compte krbtgt

10.1 ADCS : un composant Tier 0

Une autorité de certification d'entreprise intégrée à AD émet des certificats acceptés pour l'authentification (PKINIT, Schannel). Un modèle de certificat mal configuré permet à un simple utilisateur d'obtenir un certificat au nom d'un administrateur. Les configurations vulnérables sont classées dans la littérature en familles ESC1 à ESC16 (modèle autorisant le sujet fourni par le demandeur avec EKU d'authentification, ACL de modèle trop larges, agent d'inscription, drapeau EDITF_ATTRIBUTESUBJECTALTNAME2, relais NTLM vers l'inscription web, mappage faible...).

• Traitez les serveurs d'AC, leurs clés (HSM idéalement) et leurs administrateurs comme Tier 0.
• Auditez les modèles publiés et leurs ACL (PingCastle, Locksmith, BloodHound les signalent).
• Assurez-vous que le mappage fort des certificats (KB5014754, extension SID dans les certificats) est appliqué : Microsoft est passé progressivement en mode application complète (2025) ; un DC encore en mode compatibilité est une faiblesse.

Procédures détaillées, commandes certutil et corrections ESC : voir PKI et certificats et OpenSSL.

10.2 Le compte krbtgt

Tous les TGT du domaine sont chiffrés et signés avec la clé du compte krbtgt. Quiconque obtient cette clé (DCSync, vol de ntds.dit, sauvegarde de DC non protégée) peut forger des TGT arbitraires (« golden ticket ») valables jusqu'au changement de la clé. Le mot de passe de krbtgt n'est changé que manuellement.

Le DC accepte la clé courante et la précédente : un seul reset n'invalide donc pas les tickets forgés avec l'ancienne clé. D'où la rotation double, avec un délai entre les deux.

1. Vérifier la santé de la réplication (repadmin /replsummary sans erreur) : un DC qui ne reçoit pas le nouveau mot de passe refusera les tickets émis par les autres.
2. Premier reset du mot de passe krbtgt, réplication forcée, contrôle de la version de l'attribut sur tous les DC.
3. Attendre au moins la durée de vie maximale d'un ticket (10 h par défaut, règle « Maximum lifetime for user ticket ») + le temps de réplication. En pratique, 24 h.
4. Second reset, réplication, contrôle.

# Etat actuel
Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber |
    Select-Object PasswordLastSet, msDS-KeyVersionNumber

# Version de l'attribut unicodePwd sur chaque DC apres un reset
repadmin /showobjmeta * "CN=krbtgt,CN=Users,DC=contoso,DC=local" | Select-String "unicodePwd"

# Microsoft publie un script dedie (New-KrbtgtKeys.ps1, depot GitHub "microsoft")
# qui propose un mode simulation, verifie la replication et cible aussi
# les comptes krbtgt_NNNNN des RODC. Preferer ce script a un reset manuel.

11. GPO de sécurité et baselines

11.1 Baselines Microsoft

Le Microsoft Security Compliance Toolkit fournit les baselines de sécurité par version (Windows Server 2025 « Domain Controller » et « Member Server », Windows 11, Edge, Microsoft 365 Apps) sous forme de sauvegardes de GPO, avec Policy Analyzer (comparaison entre baseline, GPO existantes et configuration effective) et LGPO (application locale). Windows Server 2025 propose aussi des baselines appliquées et maintenues via OSConfig.

# Importer une GPO de baseline depuis le dossier "GPOs" du toolkit
Import-GPO -BackupGpoName "MSFT Windows Server 2025 - Domain Controller" `
    -Path "C:\Baselines\WS2025\GPOs" -TargetName "BL-WS2025-DC" -CreateIfNeeded

# Lier en desactive d'abord, comparer avec Policy Analyzer, puis activer
New-GPLink -Name "BL-WS2025-DC" -Target "OU=Domain Controllers,DC=contoso,DC=local" -LinkEnabled No

# Etat effectif sur une machine
gpresult /h C:\Temp\rsop.html /f

11.2 Paramètres à fort impact

Paramètre	Valeur	Objectif
Credential Guard (VBS)	Activé avec verrou UEFI (postes, serveurs membres ; pas sur les DC)	Protéger les secrets LSA
LSA Protection (RunAsPPL)	Activé	Empêcher la lecture de LSASS par un processus non protégé
WDigest UseLogonCredential	0	Pas de mot de passe en clair en mémoire
Cached logons count	0 à 2 sur serveurs, 1 à 4 sur postes nomades	Limiter les vérificateurs en cache
LLMNR / NetBIOS over TCP / mDNS	Désactivés	Empêcher l'empoisonnement de résolution de noms
WPAD	Désactivé ou entrée DNS maîtrisée	Idem
Pare-feu Windows	Actif, règles entrantes restreintes, RDP/WinRM depuis les PAW / sous-réseaux d'admin uniquement	Limiter le mouvement latéral
Attack Surface Reduction (Defender)	Règle « Block credential stealing from LSASS » au minimum	Durcissement poste
PowerShell	Script Block Logging, transcription, Constrained Language via App Control	Visibilité (voir sécurité PowerShell)

11.3 Restreindre les administrateurs locaux

Le groupe local Administrators doit être piloté centralement : seul le compte LAPS et un groupe de domaine du tier concerné y figurent.

• Group Policy Preferences > Local Users and Groups (action Update, « Delete all member users/groups » coché) : remplace le contenu par la liste attendue, par OU.
• Ou Restricted Groups (plus brutal, remplace l'intégralité).
• Refuser l'usage réseau des comptes locaux : Deny access to this computer from the network et Deny log on through RDS pour le SID S-1-5-114 (« Local account and member of Administrators group »). Cela neutralise la réutilisation latérale d'un compte local, même identique.
• Désactiver l'élévation distante des comptes locaux : LocalAccountTokenFilterPolicy = 0 (défaut, à vérifier).

# Audit : membres du groupe Administrators local sur un lot de serveurs
$srv = Get-ADComputer -SearchBase "OU=Servers,DC=contoso,DC=local" -Filter 'Enabled -eq $true' | Select-Object -Expand Name
Invoke-Command -ComputerName $srv -ScriptBlock {
    Get-LocalGroupMember -SID S-1-5-32-544 | Select-Object @{n='Serveur';e={$env:COMPUTERNAME}}, Name, PrincipalSource
} -ErrorAction SilentlyContinue | Sort-Object Serveur | Format-Table -AutoSize

Voir aussi Droits Windows pour la gestion fine des ACL NTFS et des partages.

12. Journalisation et détection

12.1 Politique d'audit avancée

Utilisez exclusivement l'Advanced Audit Policy Configuration et activez Audit: Force audit policy subcategory settings to override audit policy category settings, sinon les deux mécanismes se contredisent.

Sous-catégorie	DC	Serveurs / postes
Credential Validation	Succès + Échec	Échec
Kerberos Authentication Service	Succès + Échec	-
Kerberos Service Ticket Operations	Succès + Échec	-
Computer / User / Security Group Account Management	Succès + Échec	Succès
Directory Service Access	Succès + Échec	-
Directory Service Changes	Succès	-
Logon / Logoff, Special Logon	Succès + Échec	Succès + Échec
Process Creation (+ ligne de commande)	Succès	Succès
Audit Policy Change, Authentication Policy Change	Succès	Succès
Security System Extension, System Integrity	Succès + Échec	Succès + Échec

# Verifier la politique effective
auditpol /get /category:*

# Inclure la ligne de commande dans 4688
# GPO : Administrative Templates > System > Audit Process Creation >
#       Include command line in process creation events = Enabled

# Taille des journaux sur les DC (le defaut est bien trop faible)
wevtutil sl Security /ms:4294967296     # 4 Go
wevtutil gl Security

12.2 Événements clés

ID	Signification	Usage en détection
4624 / 4625	Ouverture de session réussie / échouée	Type de logon (2 interactif, 3 réseau, 10 RDP), package NTLM vs Kerberos, compte Tier 0 sur machine hors Tier 0
4648	Ouverture avec identifiants explicites	runas, mouvement latéral
4672	Privilèges spéciaux attribués	Session administrative : où se connectent les comptes privilégiés
4768 / 4771	Demande de TGT / échec de pré-authentification	Pré-auth type 0 (AS-REP), pulvérisation de mots de passe (4771 en masse)
4769	Ticket de service	RC4 (0x17), volume anormal (kerberoasting), compte leurre
4776	Validation NTLM par le DC	Inventaire NTLM, pulvérisation
4662	Opération sur un objet AD	DCSync (GUID de réplication), lecture d'attributs LAPS
5136	Objet AD modifié	AdminSDHolder, GPO, msDS-KeyCredentialLink, délégations
4728 / 4732 / 4756	Membre ajouté à un groupe global / local / universel	Ajout à un groupe privilégié = alerte immédiate
4720 / 4722 / 4724 / 4738	Compte créé / activé / reset de mot de passe / modifié	Comptes inattendus, changement d'UAC (pré-auth, délégation)
4742	Compte ordinateur modifié	Ajout de délégation, de SPN
4740	Compte verrouillé	Pulvérisation, ancienne session
4719 / 1102	Politique d'audit modifiée / journal effacé	Tentative d'effacement de traces
4794	Tentative de définition du mot de passe DSRM	Persistance
7045 (System)	Service installé	Exécution distante (outils de type PsExec)

12.3 Collecte et Sysmon

• Windows Event Forwarding (WEF) : abonnements initiés par la source vers un collecteur Windows (WinRM), sans agent ; puis transfert vers le SIEM. Le collecteur qui reçoit les journaux des DC est un actif Tier 0.
• Sysmon (Sysinternals) complète l'audit natif : création de processus avec hash et parent (ID 1), connexions réseau (3), chargement de pilotes (6), accès à LSASS (10), requêtes DNS (22). Partir d'une configuration communautaire maintenue et l'adapter, la configuration par défaut étant peu utile.
• Sur les DC, viser une rétention locale d'au moins quelques jours et une rétention centrale de 6 à 12 mois (enquête post-incident).

# Installation Sysmon avec une configuration (fichier XML valide au prealable)
sysmon64.exe -accepteula -i C:\Sysmon\sysmonconfig.xml
# Mise a jour de la configuration
sysmon64.exe -c C:\Sysmon\sysmonconfig.xml

# Ajout d'un compte dans un groupe privilegie dans les dernieres 24 h (tous DC)
foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{LogName='Security'; Id=4728,4732,4756; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue |
        Select-Object @{n='DC';e={$dc}}, TimeCreated, Id, @{n='Detail';e={$_.Message.Split("`n")[0]}}
}

12.4 Règles de détection à fort rapport signal / bruit

Règle	Source	Logique	Faux positifs typiques
Ajout à un groupe Tier 0	4728 / 4732 / 4756 sur DC	Groupe cible dans la liste Tier 0, hors fenêtre de changement	Opérations planifiées (à corréler avec le ticket)
Réplication depuis une non-DC	4662 + GUID de réplication	Compte demandeur absent de la liste des comptes machine DC et du compte de synchronisation déclaré	Entra Connect (à exclure nominativement)
Compte leurre sollicité	4768 / 4769 / 4625 / 4624	Toute occurrence	Quasi aucun
Rafale de tickets de service RC4	4769	Un compte demande plus de N tickets RC4 vers des comptes utilisateurs distincts en 10 min	Scanners de vulnérabilités, applications legacy
Compte Tier 0 hors PAW / DC	4624 type 2, 3, 10 sur serveurs et postes	Compte membre du groupe Tier 0, machine hors OU Tier 0	Comptes de service mal classés
Modification d'AdminSDHolder ou de GPO liée aux DC	5136	DN de l'objet modifié	Mises à jour de baseline (planifiées)
Ajout de clé d'authentification	5136 sur msDS-KeyCredentialLink	Modifiant différent du compte lui-même / du service Windows Hello for Business	Enrôlement WHfB légitime
Journal effacé / audit modifié	1102 / 4719	Toute occurrence sur DC et serveurs Tier 0	Rares
Pulvérisation de mots de passe	4771 / 4776 / 4625	Une source, beaucoup de comptes distincts, 1 ou 2 échecs chacun	Session restée ouverte après changement de mot de passe (un seul compte)

Pour l'architecture de supervision (collecte, alerting, tableaux de bord), voir Monitoring.

13. Outils d'audit

Outil	Nature	Ce qu'il apporte	Usage conseillé
PingCastle	Audit ponctuel (exécutable, sans installation), rapport HTML avec score	Synthèse des risques : comptes privilégiés, délégations, krbtgt, LAPS, ADCS, GPO, protocoles faibles, objets obsolètes	Mensuel ; suivre l'évolution du score et traiter par règle
Purple Knight (Semperis)	Audit ponctuel, indicateurs d'exposition et de compromission	Indicateurs AD, Entra ID, Okta ; recherche d'indices de compromission passée	Second regard, complémentaire de PingCastle
BloodHound (Community Edition)	Collecte + graphe des relations	Chemins d'attaque vers Tier 0 (ACL, sessions, groupes, délégations, ADCS)	En défensif : « qui peut atteindre Domain Admins ? », supprimer les arêtes les plus empruntées
Microsoft Defender for Identity	Capteurs sur DC, ADCS, ADFS, Entra Connect ; console Defender XDR	Détection comportementale temps réel (DCSync, reconnaissance, pass-the-ticket...), évaluations de posture	Production, si licence disponible
Locksmith	Module PowerShell	Détection et corrections proposées pour les mauvaises configurations ADCS	Avant / après chaque évolution PKI
Policy Analyzer	Microsoft SCT	Écarts GPO vs baselines	À chaque nouvelle baseline

# PingCastle : healthcheck du domaine courant (depuis un poste Tier 0)
PingCastle.exe --healthcheck --server contoso.local

# Conserver les rapports XML pour suivre l'evolution
# (PingCastle sait consolider plusieurs rapports dans une carte / un tableau)

Pour la démarche d'audit globale (périmètre, restitution, priorisation), voir Audit de sécurité.

14. Sauvegarde et reprise de forêt

14.1 Ce qu'il faut sauvegarder

• État système d'au moins deux DC par domaine (dont celui qui porte le plus de rôles FSMO), quotidien : base NTDS, SYSVOL, registre, base de la PKI si ADCS est sur un DC (déconseillé).
• Sauvegarde hors domaine et immuable : un attaquant Domain Admin supprime d'abord les sauvegardes accessibles depuis le domaine. Le serveur de sauvegarde des DC ne doit pas être joint au domaine de production, ou appartenir à une forêt d'administration dédiée ; copie hors ligne / immuable obligatoire (voir Stratégie de sauvegarde).
• Configuration : export des GPO (Backup-GPO -All), DNS, liste des approbations, des sites et liens, des modèles de certificats.
• Le mot de passe DSRM de chaque DC (Windows LAPS le gère) et le mot de passe du compte RID 500, sous séquestre hors SI.

# Sauvegarde etat systeme vers un volume dedie
wbadmin start systemstatebackup -backupTarget:E: -quiet

# Export de toutes les GPO avec rapport
$d = "D:\GPOBackup\$(Get-Date -f yyyyMMdd)"; New-Item -ItemType Directory $d | Out-Null
Backup-GPO -All -Path $d
Get-GPOReport -All -ReportType Html -Path "$d\all-gpo.html"

# Age de la derniere sauvegarde vue par AD (par partition)
repadmin /showbackup *

14.2 Restaurations courantes

Besoin	Méthode
Objet supprimé par erreur	Corbeille AD (Restore-ADObject), si activée
Attribut / ACL modifiés à tort	Restauration non autoritaire d'un DC isolé puis export, ou outil tiers ; à défaut, correction manuelle à partir des métadonnées (repadmin /showobjmeta)
Arborescence supprimée sans corbeille	Restauration non autoritaire en DSRM puis ntdsutil "authoritative restore" sur le sous-arbre
SYSVOL corrompu sur tous les DC	Restauration autoritaire DFSR (msDFSR-Options = 1 sur le DC de référence)
Forêt compromise / chiffrée	Plan de reprise de forêt (ci-dessous)

14.3 Plan de reprise de forêt (principes du guide Microsoft)

1. Décider : la reprise de forêt est justifiée si tous les DC sont inutilisables ou si l'intégrité de l'annuaire n'est plus garantie (compromission Tier 0 avérée). Identifier la sauvegarde saine la plus récente.
2. Isoler : réseau de reprise sans lien avec la production (et sans la menace : postes d'admin neufs).
3. Restaurer un DC inscriptible par domaine (en commençant par la racine de forêt), en restauration non autoritaire de SYSVOL marquée autoritaire.
4. Sur ce DC : saisir les rôles FSMO, nettoyer les métadonnées des autres DC (ntdsutil metadata cleanup ou suppression via la console), augmenter le pool RID (invalider le pool courant / +100 000), réinitialiser le compte d'ordinateur du DC, le mot de passe krbtgt deux fois, les mots de passe des approbations, et le compte RID 500.
5. Assainir : retirer les persistances connues (comptes, ACL, GPO, AdminSDHolder, délégations, modèles de certificats) avant toute reconnexion.
6. Reconstruire les autres DC par promotion (pas par restauration), puis reconnecter progressivement les sites et serveurs, en réinitialisant les comptes de service et privilégiés.

15. Dépannage des effets de bord

Symptôme	Cause probable	Diagnostic / correction
Un admin ne peut plus ouvrir de session RDP sur un serveur après ajout à Protected Users	RDP via NTLM (accès par IP, CredSSP sans Kerberos), ou TGT expiré au-delà de 4 h	Se connecter par FQDN ; journal ProtectedUserFailures sur le DC ; klist purge puis réessayer
Service applicatif en échec « logon failure » après durcissement	Compte de service dans Protected Users, ou refus de logon as a service par la GPO tiers	4625 (statut / sous-statut) sur la machine ; retirer le compte du groupe / ajuster les droits ; migrer vers gMSA
Erreurs « KDC_ERR_ETYPE_NOSUPP » (4768/4769 en échec, code 0xE)	Compte ou service sans clé AES après passage en AES only	Changer le mot de passe du compte (génère les clés AES), vérifier msDS-SupportedEncryptionTypes du compte et du client
Copieur / scanner ne peut plus envoyer vers un partage	SMBv1 désactivé ou signature SMB exigée	Mettre à jour le firmware (SMB2/3 + signature) ; sinon partage dédié sur serveur isolé, exception documentée
Application LDAP en erreur « strong authentication required »	LDAP signing exigé, bind simple sur 389	Événements 2889 avant bascule ; passer l'application en LDAPS / StartTLS
Échec de bind LDAPS après activation du channel binding	Client ne supportant pas le CBT (ancienne bibliothèque, proxy TLS intermédiaire)	Événements 3039 ; mise à jour du client ; rester temporairement en mode 1
gMSA : Test-ADServiceAccount renvoie False	Machine pas encore membre effectif du groupe autorisé (jeton non rafraîchi), clé KDS non répliquée	Redémarrer le serveur (ou klist -li 0x3e7 purge) ; Get-KdsRootKey ; vérifier PrincipalsAllowedToRetrieveManagedPassword
LAPS : pas de mot de passe dans AD	GPO non appliquée, permission self absente, DFL insuffisant pour le chiffrement	Journal Microsoft-Windows-LAPS/Operational ; Invoke-LapsPolicyProcessing ; Find-LapsADExtendedRights
Après reset krbtgt : erreurs Kerberos sur un site distant	DC qui n'a pas reçu le nouveau mot de passe	repadmin /showobjmeta sur krbtgt, repadmin /syncall /AdeP ; ne jamais enchaîner le second reset avant convergence
Silo en application : un admin Tier 0 refusé depuis son PAW	PAW non membre du silo, ou blindage Kerberos non supporté côté client	Journal AuthenticationPolicyFailures-DomainController ; vérifier Get-ADComputer PAW -Properties AuthenticationPolicySilo et la GPO claims/armoring
Restriction NTLM : application cassée sans message clair	Flux absent de l'inventaire d'audit	Événements 4004 / 8004 (journal NTLM) ; ajouter une exception serveur temporaire, corriger le SPN / la configuration

# Boite a outils Kerberos cote client
klist                      # tickets de l'utilisateur courant
klist tgt                  # detail du TGT (type de chiffrement, duree)
klist -li 0x3e7 purge      # purger les tickets du compte machine (SYSTEM)
nltest /dsgetdc:contoso.local /kdc /force
setspn -Q HTTP/app01.contoso.local   # qui porte ce SPN ?

16. Checklist priorisée

16.1 Quick wins (semaines 1 à 4)

• [ ] Rapport PingCastle initial archivé (score de référence).
• [ ] Groupes Enterprise Admins / Schema Admins vides ; Domain Admins réduit à quelques comptes nominatifs ; groupes opérateurs vides.
• [ ] Aucun compte à SPN membre d'un groupe privilégié ; aucun compte sans pré-authentification Kerberos.
• [ ] ms-DS-MachineAccountQuota = 0.
• [ ] Spouleur d'impression désactivé sur les DC.
• [ ] Aucune délégation non contrainte hors DC.
• [ ] Droits de réplication (DCSync) limités aux principaux légitimes.
• [ ] NTLMv1 et LM refusés (LmCompatibilityLevel = 5), SMBv1 supprimé.
• [ ] LLMNR, NetBIOS et WPAD désactivés.
• [ ] Windows LAPS déployé sur postes et serveurs, chiffrement activé, DSRM sauvegardé.
• [ ] Comptes Tier 0 : AccountNotDelegated + Protected Users (après tests).
• [ ] Politique d'audit avancée + taille des journaux des DC ; alerte sur 4728/4732/4756 pour les groupes privilégiés.
• [ ] Corbeille AD activée ; sauvegarde état système quotidienne de deux DC, copie hors domaine.
• [ ] Date de dernier changement du krbtgt vérifiée ; rotation double planifiée.

16.2 Chantiers (trimestre 1 à 4)

• [ ] Modèle en tiers : OU, groupes, GPO de refus d'ouverture de session déployées progressivement (Tier 2 puis Tier 1).
• [ ] PAW pour les administrateurs Tier 0, puis Tier 1 ; Remote Credential Guard.
• [ ] Authentication Policies / Silos Tier 0 : audit puis application.
• [ ] Migration des comptes de service vers gMSA (ou dMSA sur DC 2025) ; AES only ; élimination de RC4 mesurée par les 4769.
• [ ] Inventaire NTLM complet, corrections SPN / FQDN, puis restriction avec exceptions documentées.
• [ ] SMB signing exigé partout, LDAP signing + channel binding appliqués sur les DC.
• [ ] Revue des ACL (BloodHound) : suppression des chemins vers Tier 0, nettoyage des adminCount orphelins, référence AdminSDHolder.
• [ ] Audit ADCS (ESC), mappage fort des certificats appliqué, services web d'inscription protégés ou retirés.
• [ ] Baselines Microsoft importées avec GPO de deltas ; administrateurs locaux pilotés centralement ; S-1-5-114 refusé en réseau.
• [ ] Collecte centralisée (WEF + SIEM), Sysmon, règles de détection (DCSync, kerberoasting, compte leurre) ; Defender for Identity si disponible.
• [ ] Hyperviseurs, sauvegarde et outils de déploiement qui touchent les DC traités en Tier 0.
• [ ] Plan de reprise de forêt écrit et exercé au moins une fois par an.

16.3 Contrôle récurrent

Fréquence	Contrôle
Quotidien	Alertes : ajout à un groupe privilégié, DCSync hors DC, compte leurre, effacement de journal
Hebdomadaire	Santé de réplication (repadmin /replsummary), sauvegardes des DC réussies et restaurables
Mensuel	PingCastle et comparaison du score, couverture LAPS, nouveaux SPN / délégations
Semestriel	Rotation double du krbtgt, revue des membres Tier 0, revue AdminSDHolder
Annuel	Exercice de reprise de forêt, revue BloodHound complète, audit externe