L'administration Active Directory en tiers en une page

Un domaine Active Directory a exactement la solidité du poste le plus négligé sur lequel un administrateur du domaine a un jour ouvert sa session pour rendre service : la gentillesse est une vertu, mais pas une politique de sécurité.

L’essentiel

• Trois étages, une règle. Le tier 0 contient l’annuaire et tout ce qui peut le contrôler ; le tier 1, les serveurs et les applications ; le tier 2, les postes de travail et leurs utilisateurs. Un compte n’ouvre jamais de session sur un étage inférieur au sien, et un étage inférieur ne contrôle jamais un étage supérieur.
• Le tier 0 déborde des contrôleurs de domaine. La PKI qui délivre des certificats d’authentification (AD CS), le serveur de synchronisation vers Entra ID, les sauvegardes des contrôleurs, les hyperviseurs qui les hébergent, l’outil de déploiement ou la console d’EDR capables d’y exécuter du code : tout ce qui contrôle le tier 0 en fait partie, et se protège comme lui.
• Pourquoi un admin du domaine sur un poste expose le domaine. Une ouverture de session interactive (console, Bureau à distance classique, « Exécuter en tant que ») laisse dans la mémoire de la machine de quoi s’authentifier au nom du compte tant que la session vit, et le cache de connexion en garde une empreinte après. Qui prend un jour la main sur ce poste prend ce qui s’y trouve. Le compte ne vaut donc pas plus que la machine la moins protégée où il s’est connecté.
• Un compte par tier, des interdictions écrites. L’administrateur a un compte ordinaire pour ses courriels, et un compte d’administration par tier qu’il administre. Sur les machines des tiers 1 et 2, une stratégie de groupe interdit l’ouverture de session aux comptes du tier 0 (droits « Interdire l’ouverture d’une session locale », « … par les services Bureau à distance », en tant que tâche et en tant que service) ; les stratégies et silos d’authentification (depuis Windows Server 2012 R2) restreignent en plus les machines depuis lesquelles ces comptes s’authentifient.
• Un poste d’administration dédié. Le tier 0 s’administre depuis un poste réservé à cet usage : durci, sans messagerie ni navigation sur Internet, seul autorisé à joindre les interfaces d’administration. Administrer l’annuaire depuis le poste où l’on lit ses courriels revient à garder les clés du coffre dans la boîte aux lettres.
• LAPS cloisonne les postes entre eux. Windows LAPS, intégré à Windows depuis la mise à jour d’avril 2023, donne à chaque machine un mot de passe d’administrateur local aléatoire, stocké dans l’annuaire (ou Entra ID), lisible par les seuls groupes autorisés et renouvelé, y compris après usage. Un poste tombé n’ouvre plus tous les autres avec le même mot de passe.
• Protected Users réduit ce qui traîne. Pour les membres de ce groupe (depuis Windows Server 2012 R2) : pas de NTLM, pas de DES ni de RC4 en Kerberos, pas de délégation, pas de vérificateur de connexion en cache, pas de secret en clair conservé par CredSSP ou WDigest, ticket Kerberos initial limité à 4 heures. On y place les comptes d’administration après essai, jamais les comptes de service ni le compte de secours.

Idées reçues, et fausses

• « Il suffit de fermer sa session après le dépannage. » Faux. Si le poste est déjà compromis quand l’administrateur s’y connecte, la session a été servie chaude, et la déconnexion arrive après le départ du train. Le cache de connexion, lui, reste à quai.
• « Nos unités d’organisation Tier0, Tier1 et Tier2 font notre modèle en tiers. » Faux. Une unité d’organisation range des objets, elle ne protège rien. Le modèle tient dans qui se connecte où et qui contrôle quoi ; le nom du dossier relève de la décoration intérieure.
• « Le tier 0, ce sont les contrôleurs de domaine. » Faux. C’est aussi la sauvegarde qui les restaure, l’hyperviseur qui les fait tourner, la PKI qui signe des certificats de connexion et l’outil qui y pousse du logiciel. Un tier 0 bien gardé dont la sauvegarde traîne au tier 1 est un château fort avec une chatière.
• « Avec Protected Users, plus besoin de cloisons. » Faux. Le groupe réduit les secrets laissés et raccourcit leur vie ; il n’empêche pas celui qui tient le poste de se servir d’une session ouverte tant qu’elle dure. C’est une ceinture de sécurité, pas un permis de conduire les yeux fermés.
• « LAPS protège le domaine. » Faux. LAPS protège les postes les uns des autres en rendant unique le compte d’administrateur local. Les comptes du domaine restent hors de son périmètre : l’admin du domaine connecté sur un poste y laisse sa session, LAPS ou pas.

Pour aller plus loin : Active Directory délégations et chemins d’attaque · Comment structurer Active Directory et déléguer sans escalade · Kerberos et KDC dans Active Directory, attaques et durcissement · Séparer plan de contrôle et plan de données · Comment limiter le mouvement latéral après compromission · Accès juste-à-temps et privilèges temporaires · Déployer FIDO2 pour comptes à privilèges.

À lire aussi

• Le Kerberoasting en une pagePourquoi un compte de service Active Directory doté d'un SPN et d'un mot de passe faible est un risque, et les cinq parades qui rendent son ticket inutile : gMSA, mot de passe long, AES sans RC4, moindre privilège, événement 4769.
• Configurer Windows Hello for Business sans mot de passeGuide pratique de déploiement de l’authentification sans mot de passe sur Active Directory avec Windows Hello for Business.
• Auditer les comptes orphelins Active DirectoryMéthode pas-à-pas pour détecter, qualifier et traiter les comptes orphelins et les droits excessifs dans un annuaire d’entreprise.
• GPO Active Directory : durcissement, abus et contrôleFonctionnement, usages de durcissement, détournements et contrôle des objets de stratégie de groupe (GPO) dans Active Directory.

Pages voisines

L'administration Active Directory en tiers en une page

Elle cite

• Accès juste-à-temps et privilèges temporaires
• Active Directory délégations et chemins d’attaque
• Comment limiter le mouvement latéral après compromission
• Comment structurer Active Directory et déléguer sans escalade
• Déployer FIDO2 pour comptes à privilèges
• Kerberos et KDC dans Active Directory, attaques et durcissement
• Séparer plan de contrôle et plan de données