Durcir Active Directory (1/4) : identités, privilèges et postes d'administration.

C'est la partie qui rapporte le plus, et c'est pour cela qu'elle vient en premier. Les compromissions d'annuaire ne commencent presque jamais par une faille dans Active Directory lui-même : elles commencent par un poste utilisateur, et remontent parce que rien n'empêchait de remonter. Aucun correctif ne ferme ce chemin - seule l'organisation des identités le fait.

Ce qu'il vous faut

• Des droits d'administration du domaine, utilisés depuis un compte dédié - c'est précisément l'objet de ce qui suit.
• Le module PowerShell Active Directory (Import-Module ActiveDirectory), présent sur un contrôleur de domaine ou installable via les outils d'administration à distance (RSAT).
• La console de gestion des stratégies de groupe (GPMC).
• Un environnement de test, ou à défaut une unité d'organisation pilote avec possibilité de retour arrière.

1. Le modèle en paliers, et la seule règle qui le rend utile

Le modèle de paliers de Microsoft répartit systèmes et comptes en trois niveaux de confiance : palier 0 (contrôleurs de domaine, krbtgt, AD CS, AD FS, connecteurs d'annuaire, Domain Admins, Enterprise Admins), palier 1 (serveurs métier et leurs administrateurs), palier 2 (postes de travail, utilisateurs, support de proximité).

La règle qui fait tout le travail : un compte d'un palier ne s'authentifie jamais sur une machine d'un palier plus élevé. Un administrateur de domaine qui se connecte, même une seule fois, sur un poste utilisateur pour dépanner un collègue laisse sur cette machine de quoi rejouer son authentification. Si le poste est compromis ensuite - un hameçonnage suffit - l'attaquant remonte jusqu'au palier 0. Ce chemin ne demande aucune vulnérabilité, juste une habitude.

L'ANSSI constate régulièrement que les compromissions d'annuaires proviennent de pratiques d'administration insuffisamment cloisonnées bien plus que de failles logicielles. C'est ce qui rend cette partie plus rentable que toutes les autres réunies.

2. Séparer les comptes

Un même être humain, plusieurs comptes. Le compte bureautique lit les courriels et navigue ; le compte d'administration ne fait que cela, et rien d'autre :

jean.dupont        -> bureautique, courriel, navigation
adm-t1-jdupont     -> administration des serveurs  (palier 1)
adm-t0-jdupont     -> administration du domaine    (palier 0)

Un compte à privilèges ne lit jamais un courriel, n'ouvre jamais un document reçu, ne navigue jamais sur Internet, ne se connecte jamais sur un poste utilisateur. Ce n'est pas une question de discipline personnelle : c'est que ces trois activités sont les vecteurs d'intrusion les plus courants, et qu'on ne veut pas qu'elles s'exécutent dans une session qui détient les clés du domaine.

3. Rendre le cloisonnement obligatoire, pas seulement recommandé

C'est le point le plus souvent oublié, et il change tout : une politique de paliers qui repose sur la bonne volonté des administrateurs n'est pas une mesure de sécurité. Elle tient jusqu'au premier incident traité dans l'urgence, un vendredi soir, où quelqu'un se connectera « juste une fois » avec le mauvais compte.

Windows sait l'interdire techniquement, par les droits utilisateurs des stratégies de groupe. Créez d'abord un groupe par palier (par exemple GG-Admins-T0, GG-Admins-T1, GG-Admins-T2), puis liez une GPO à chaque unité d'organisation :

Configuration ordinateur → Stratégies → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Attribution des droits utilisateur

Et pour chaque cas, les cinq droits, pas seulement le premier - sinon il reste une porte :

• Interdire l'ouverture de session locale
• Interdire l'ouverture de session par les services Bureau à distance
• Interdire l'accès à cet ordinateur à partir du réseau
• Interdire l'ouverture de session en tant que tâche
• Interdire l'ouverture de session en tant que service

4. Réduire les groupes à privilèges

Commencez par regarder qui est réellement membre de quoi, en récursif - l'imbrication de groupes cache régulièrement des membres que personne n'a décidés :

$groupes = @(
    "Domain Admins", "Enterprise Admins", "Schema Admins",
    "Administrators", "Account Operators", "Backup Operators",
    "Server Operators", "Print Operators"
)

foreach ($g in $groupes) {
    Write-Host "=== $g ==="
    Get-ADGroupMember $g -Recursive |
        Select-Object Name, SamAccountName, ObjectClass
}

Les trois premiers sont ceux auxquels tout le monde pense. Les cinq suivants sont ceux qu'on oublie, et ils sont tout aussi dangereux : Account Operators peut modifier des comptes, Backup Operators peut lire l'intégralité du système de fichiers d'un contrôleur de domaine - y compris la base de l'annuaire - et Server Operators peut y démarrer un service. Chacun de ces trois groupes est une voie vers le palier 0. Ils devraient normalement être vides.

Pour chaque membre restant, une seule question : quelle tâche précise justifie ce niveau ? Un administrateur qui ne gère que des serveurs n'a rien à faire dans Domain Admins.

5. Protected Users

Ce groupe intégré applique aux comptes qui en sont membres un ensemble de restrictions qu'on ne peut pas contourner par configuration :

• plus d'authentification NTLM ;
• plus de chiffrement Kerberos faible (DES, RC4) ;
• plus de délégation possible, ni contrainte ni non contrainte ;
• ticket TGT limité à 4 heures, non renouvelable ;
• et surtout : plus aucune mise en cache des identifiants - ni mot de passe en clair, ni empreinte NTLM, ni clé de long terme après l'obtention du ticket initial.

C'est ce dernier point qui compte : il prive un attaquant de ce qu'il vient chercher en mémoire sur une machine compromise.

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

6. Marquer les comptes sensibles comme non délégables

Indépendamment de Protected Users, chaque compte de palier 0 doit porter l'indicateur « ce compte est sensible et ne peut pas être délégué ». Il empêche qu'un service auquel ce compte s'authentifie puisse ensuite agir en son nom :

Set-ADAccountControl -Identity "adm-t0-jdupont" -AccountNotDelegated $true

# Verification
Get-ADUser "adm-t0-jdupont" -Properties AccountNotDelegated |
    Select-Object SamAccountName, AccountNotDelegated

Pour appliquer et contrôler la mesure sur l'ensemble des comptes à privilèges, la partie 3 traite le sujet symétrique : les machines qui détiennent des droits de délégation.

7. Le poste d'administration dédié (PAW)

Conséquence directe du cloisonnement : si un compte de palier 0 ne doit jamais s'authentifier sur une machine moins protégée, il lui faut une machine au moins aussi protégée. C'est le rôle d'un poste d'administration dédié.

Cette machine ne navigue pas sur Internet, ne relève pas les courriels, n'exécute aucun logiciel autre que les outils d'administration, reçoit ses correctifs en priorité, porte un EDR et est pilotée par ses propres GPO. C'est contraignant, et c'est exactement le but : réduire au minimum la surface par laquelle elle pourrait être compromise.

Un raccourci fréquent, et faux : administrer depuis le poste bureautique en passant par un rebond RDP. Le rebond ne protège rien si le poste de départ est compromis - le clavier, l'écran et la session sont déjà entre les mains de l'attaquant. Le poste dédié doit être le point de départ, pas une étape intermédiaire.

8. Windows LAPS

Sans mesure spécifique, beaucoup d'organisations utilisent le même mot de passe administrateur local sur tout leur parc, hérité de l'image de déploiement. Un attaquant qui l'obtient sur une seule machine se déplace sur tout le parc en quelques minutes, sans exploiter la moindre vulnérabilité.

Windows LAPS, intégré nativement depuis Windows 11 22H2 et Windows Server 2022 (mise à jour d'avril 2023), génère un mot de passe administrateur local unique et aléatoire par machine, le renouvelle, et le stocke chiffré dans l'annuaire.

a. Étendre le schéma - une seule fois, depuis le maître de schéma. Opération irréversible : à préparer et tester avant.

Update-LapsADSchema

b. Autoriser les machines à écrire leur mot de passe, sur l'unité d'organisation concernée :

Set-LapsADComputerSelfPermission -Identity "OU=Postes,DC=exemple,DC=local"

c. Activer LAPS par stratégie de groupe :

Configuration ordinateur → Stratégies → Modèles d'administration → Système → LAPS

d. Vérifier, sur une machine de test :

Get-LapsADPassword "NOM-DU-POSTE" -AsPlainText

e. Contrôler qui peut lire ces mots de passe - c'est aussi important que le déploiement lui-même :

Find-LapsADExtendedRights -Identity "OU=Postes,DC=exemple,DC=local"

Toute personne figurant dans cette liste peut obtenir l'administration locale de n'importe quelle machine du périmètre : elle doit être traitée comme un compte à privilèges, avec les mêmes exigences que le reste de cette page.

9. Protéger les secrets qui restent en mémoire

Même bien cloisonné, un système garde en mémoire de quoi rejouer une authentification. Trois mécanismes réduisent cette exposition, tous à valider avant généralisation car ils touchent au sous-système d'authentification :

• Credential Guard isole les secrets d'authentification dans un environnement protégé par la virtualisation, hors de portée d'un processus même privilégié. Contrôle : Get-CimInstance Win32_DeviceGuard | Select-Object *.
• La protection LSA empêche le chargement de code non signé dans le processus qui détient ces secrets. Certaines solutions d'authentification tierces y sont sensibles : à tester.
• Remote Credential Guard évite de déposer des identifiants sur la machine distante lors d'une session RDP. Utile, mais ne remplace pas le poste dédié : il réduit l'exposition d'un chemin qui, idéalement, ne devrait pas exister.

10. Les utilisateurs ne sont pas administrateurs de leur poste

Un annuaire bien durci avec des postes où chacun est administrateur local reste vulnérable : l'administration locale suffit à installer un outil de collecte d'identifiants, à désactiver des protections, à lire la mémoire des processus.

Get-LocalGroupMember -Group "Administrators"

Les exceptions doivent être nommées, justifiées et datées. « C'est un développeur » n'est pas une justification ; « l'outil X exige des droits locaux, ticket n° 1234, revu le 1er mars » en est une.

11. Nettoyer les comptes obsolètes

Un compte qui ne s'est pas connecté depuis des mois est une cible de choix : personne ne remarquera son usage détourné, et personne ne s'apercevra que son mot de passe n'a pas changé depuis quatre ans.

# Comptes utilisateurs inactifs depuis plus de 90 jours
Search-ADAccount -AccountInactive -UsersOnly -TimeSpan 90.00:00:00 |
    Select-Object Name, SamAccountName, LastLogonDate

# Comptes machines inactifs depuis plus de 90 jours
Search-ADAccount -AccountInactive -ComputersOnly -TimeSpan 90.00:00:00 |
    Select-Object Name, LastLogonDate

# Comptes dont le mot de passe n'expire jamais
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires |
    Select-Object SamAccountName

Désactivez d'abord, jamais de suppression immédiate : un compte désactivé se réactive en cas d'erreur, un compte supprimé emporte avec lui son historique de permissions et les références qui pointaient vers lui. Laissez passer une période de battement - un mois couvre les absences longues - puis supprimez.

Vérifier que c'est en place

Une mesure appliquée mais non vérifiée n'est pas une mesure faite. Quatre contrôles qui prouvent le travail de cette page :

1. Le cloisonnement tient : depuis un poste du palier 2, tentez une ouverture de session avec un compte GG-Admins-T0. Elle doit échouer, avec un refus explicite - pas réussir « mais on ne le fait pas ».
2. Les GPO sont réellement appliquées sur les machines cibles, pas seulement créées : gpresult /h C:\Temp\gpresult.html sur un poste, un serveur et un contrôleur de domaine.
3. LAPS écrit vraiment : Get-LapsADPassword renvoie un mot de passe dont la date de renouvellement est récente, sur une machine prise au hasard - pas seulement sur celle qui a servi au test.
4. Les groupes hérités sont vides : Account Operators, Backup Operators, Server Operators et Print Operators ne renvoient aucun membre.

Sources

• ANSSI - Recommandations de sécurité relatives à Active Directory (ANSSI-PA-099)
• Microsoft Learn - Modèle de niveaux AD DS
• Microsoft Learn - Windows LAPS, vue d'ensemble
• Microsoft Learn - Paramètres de stratégie Windows LAPS (valeurs de PostAuthenticationResetDelay)
• Microsoft Learn - Configurer les comptes protégés (Protected Users)
• Kenawek - MFA : pourquoi l'authentification multifacteur n'est plus optionnelle