Identifier les actifs Tier 0 : méthode d'inventaire AD

Chaque contrôle Tier 0 que vous déploierez ensuite, des GPO de refus d'ouverture de session aux silos d'authentification, ne protège que la liste d'actifs que vous lui fournissez. La plupart des projets de tiering échouent non pas parce que les contrôles sont faibles, mais parce que la liste est fausse : le serveur de sauvegarde capable de restaurer NTDS.dit, le vCenter qui héberge les DC, le groupe du support qui peut réinitialiser le mot de passe d'un Domain Admin via une ACE oubliée. Les attaquants se moquent des actifs que vous avez étiquetés Tier 0. Ils suivent les relations de contrôle jusqu'à ce que l'une d'elles atteigne le domaine.

Ce guide vous donne une méthode reproductible pour construire cet inventaire : la définition à appliquer, les catégories que la plupart des équipes oublient, le PowerShell pour les énumérer et la manière d'enregistrer le résultat pour que les contrôles suivants puissent l'exploiter. Il va plus loin que la présentation générale de Tier 0 et accès à privilèges, à lire en premier pour le modèle en tiers lui-même.

La définition : le contrôle, pas l'importance

Un système relève du Tier 0 si sa compromission permet à un attaquant de prendre le contrôle d'Active Directory. Ce contrôle peut être direct (ouverture de session sur un DC, appartenance à Domain Admins) ou indirect (écriture dans une GPO liée à l'UO Domain Controllers, émission d'un certificat qui s'authentifie comme n'importe quel utilisateur, lecture du disque virtuel d'un DC). Le test est transitif : si A contrôle B et que B est Tier 0, alors A est Tier 0.

Deux conséquences en découlent. D'abord, le caractère « critique pour l'activité » n'entre pas en ligne de compte : votre ERP est important mais relève généralement du Tier 1. Ensuite, le Tier 0 est plus vaste que l'UO Domain Controllers ; l'objectif de l'inventaire est d'y trouver tout ce qui s'y trouve, puis de le réduire délibérément en supprimant les chemins de contrôle inutiles.

Mesurer : les catégories d'actifs

Passez en revue les catégories ci-dessous. La plupart peuvent être découvertes à partir d'AD lui-même.

Les contrôleurs de domaine et leur plateforme

Tous les DC accessibles en écriture et les RODC, plus tout ce qui se trouve en dessous : hôtes de virtualisation, plan de gestion de la virtualisation (vCenter, SCVMM, administrateurs de cluster Hyper-V), baies SAN ou de stockage qui contiennent les disques des DC, gestion hors bande (iLO, iDRAC) des DC physiques, et référentiel de sauvegarde des DC.

# Tous les DC de la forêt, avec l'OS et l'indicateur RODC
(Get-ADForest).Domains | ForEach-Object {
    Get-ADDomainController -Filter * -Server $_ |
        Select-Object Domain, HostName, OperatingSystem, IsReadOnly, Site
}

L'infrastructure d'identité

• AD CS : chaque AC d'entreprise, plus la racine hors ligne. Une AC qui émet des certificats d'authentification client peut fabriquer une ouverture de session pour n'importe quel compte.
• Les serveurs AD FS et toute personne capable de lire leur clé de signature de jetons.
• Les serveurs Microsoft Entra Connect / Cloud Sync. Le compte de synchronisation détient des droits de réplication (et la synchronisation du hachage de mot de passe lit tous les hachages).
• Les plateformes PAM et coffres-forts (CyberArk, Delinea et équivalents) qui stockent ou injectent des identifiants Tier 0.

$config = (Get-ADRootDSE).configurationNamingContext

# AC d'entreprise enregistrées dans la forêt
Get-ADObject -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$config" `
    -Filter 'objectClass -eq "pKIEnrollmentService"' -Properties dNSHostName |
    Select-Object Name, dNSHostName

# Empreinte Entra Connect : comptes de synchronisation et objet ordinateur Seamless SSO
Get-ADUser -Filter 'SamAccountName -like "MSOL_*" -or SamAccountName -like "Sync_*"' -Properties Description |
    Select-Object SamAccountName, Description
Get-ADComputer -Filter 'Name -eq "AZUREADSSOACC"' -Properties PasswordLastSet

La Description des comptes MSOL_ indique normalement le nom du serveur qui exécute Entra Connect. Ce serveur relève du Tier 0.

Les plans de gestion qui atteignent le Tier 0

Tout ce qui exécute du code sur une machine Tier 0 relève du Tier 0 : serveurs de site SCCM/MECM dont les regroupements incluent des DC, Intune s'il gère les PAW, consoles EDR offrant un shell distant ou l'exécution de scripts sur les DC, outils de correctifs, agents de supervision qui s'exécutent en SYSTEM avec diffusion centralisée de scripts, et les PAW et serveurs de rebond utilisés pour administrer le Tier 0. Les découvrir relève surtout de l'entretien : listez chaque agent installé sur un DC et demandez qui contrôle sa console.

# Services et comptes d'exécution sur chaque DC, point de départ pour découvrir les agents
Get-ADDomainController -Filter * | ForEach-Object {
    Get-CimInstance Win32_Service -ComputerName $_.HostName |
        Where-Object { $_.PathName -notmatch '\\Windows\\' } |
        Select-Object PSComputerName, Name, StartName, PathName
}

Auditer : comptes, groupes et contrôle indirect

Les groupes privilégiés intégrés

Partez des SID connus plutôt que des noms, qui varient selon la langue :

Ajoutez DnsAdmins (sans RID fixe) et tout groupe applicatif disposant de droits au niveau du domaine, comme Exchange Windows Permissions d'Exchange dans les déploiements plus anciens.

$domain = Get-ADDomain
$root   = Get-ADDomain -Identity (Get-ADForest).RootDomain
$d = $domain.DomainSID.Value
$r = $root.DomainSID.Value
$targets = @(
    'S-1-5-32-544','S-1-5-32-548','S-1-5-32-549','S-1-5-32-550','S-1-5-32-551',
    "$d-512","$d-516","$d-520","$d-526" |
        ForEach-Object { [pscustomobject]@{ Sid = $_; Server = $domain.DNSRoot } }
) + @(
    # Schema Admins, Enterprise Admins et Enterprise Key Admins n'existent que dans le domaine racine de la forêt
    "$r-518","$r-519","$r-527" |
        ForEach-Object { [pscustomobject]@{ Sid = $_; Server = $root.DNSRoot } }
)

foreach ($t in $targets) {
    $g = Get-ADGroup -Identity $t.Sid -Server $t.Server
    Get-ADGroupMember -Identity $g -Server $t.Server -Recursive |
        Select-Object @{n='Group';e={$g.Name}}, Name, objectClass, distinguishedName
}

Chaque membre renvoyé est un compte Tier 0, y compris les comptes de service et les membres de groupes imbriqués inattendus. -Recursive ne renvoie que les utilisateurs et ordinateurs terminaux ; listez les groupes imbriqués eux-mêmes avec une requête non récursive si vous en avez besoin.

Le contrôle indirect via les ACL et les GPO

C'est là que la plupart des inventaires sont incomplets. Recherchez :

• Les droits de réplication sur la tête du domaine (DS-Replication-Get-Changes-All), traités dans trouver les droits DCSync.
• Les droits d'écriture sur les GPO liées à l'UO Domain Controllers ou à la racine du domaine, ainsi que les droits d'écriture de gPLink sur ces conteneurs.
• Les propriétaires et droits d'écriture sur AdminSDHolder, les UO Tier 0 et les objets utilisateurs Tier 0 (réinitialisation de mot de passe, GenericAll, WriteDacl, WriteOwner).
• Les lecteurs de secrets Tier 0 : principaux autorisés à récupérer les mots de passe des gMSA utilisés sur des serveurs Tier 0, et principaux capables de lire les mots de passe LAPS des ordinateurs Tier 0.

# GPO liées à l'UO Domain Controllers et qui peut les modifier
$dcOu = (Get-ADDomain).DomainControllersContainer
(Get-GPInheritance -Target $dcOu).GpoLinks | ForEach-Object {
    $gpoName = $_.DisplayName
    Get-GPPermission -Guid $_.GpoId -All |
        Where-Object { $_.Permission -in 'GpoEdit','GpoEditDeleteModifySecurity' } |
        Select-Object @{n='GPO';e={$gpoName}}, @{n='Trustee';e={$_.Trustee.Name}}, Permission
}

# Principaux capables de lire les mots de passe gMSA, pour les gMSA exécutés sur des serveurs Tier 0
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword |
    Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

La revue manuelle des ACL ne passe pas à l'échelle au-delà de quelques conteneurs. Exécutez BloodHound ou un outil de graphe équivalent, marquez vos objets Tier 0 connus et listez chaque principal disposant d'un chemin vers eux. La démarche est décrite dans la gestion des chemins d'attaque.

Les oublis fréquents

D'un audit à l'autre, les mêmes actifs sont laissés hors du Tier 0. Vérifiez chacun d'eux explicitement.

L'identité cloud avec un chemin de retour vers l'on-premises. Si Entra Connect fonctionne avec la réécriture du mot de passe (password writeback), ou si des administrateurs cloud peuvent gérer le serveur Entra Connect via Azure Arc, Intune ou la console d'une VM hébergée dans le cloud, alors certains rôles cloud peuvent atteindre le Tier 0. Listez les détenteurs des rôles Global Administrator et Hybrid Identity Administrator ainsi que les propriétaires de l'abonnement hébergeant un DC ou un serveur de synchronisation, et intégrez ces rôles à l'inventaire.

DnsAdmins et les droits sur les zones DNS. L'appartenance à DnsAdmins, ou un accès en écriture à la configuration du serveur DNS, a historiquement permis l'exécution de code sur les DC via les paramètres de plugin DNS au niveau du serveur. Même une fois corrigé, un accès en écriture aux zones intégrées à AD permet à un attaquant de rediriger le trafic destiné aux noms des DC. Gardez ce groupe vide ou réservé au Tier 0.

Les modèles de certificats et objets PKI. Le serveur d'AC n'est pas le seul actif AD CS. Un accès en écriture aux modèles de certificats, à l'objet NTAuthCertificates ou au conteneur Public Key Services de la partition de configuration peut produire un modèle qui s'authentifie comme un Domain Admin. Ces objets résident dans la partition de configuration et échappent facilement à une revue fondée sur les UO.

Les consoles de sauvegarde et d'instantanés. Quiconque peut restaurer l'état système d'un DC, monter un instantané ou exporter une VM depuis la sauvegarde peut lire NTDS.dit. Cela inclut les opérateurs de sauvegarde du produit de sauvegarde, et pas seulement le groupe AD Backup Operators.

Les comptes de service qui s'exécutent sur les DC. Les agents de supervision, de sauvegarde et d'EDR tournent souvent sous un compte de domaine dont le mot de passe est stocké sur des dizaines de serveurs Tier 1. Ce compte est Tier 0 puisqu'il s'exécute sur les DC, donc chaque serveur qui stocke son mot de passe devient lui aussi Tier 0. Remplacez ces comptes par le SYSTEM local, un gMSA restreint aux DC ou un compte dédié par tier.

Les anciens administrateurs. Les anciens administrateurs avec adminCount=1, les ACE obsolètes accordées nominativement il y a des années et les comptes désactivés qui restent propriétaires d'objets Tier 0 maintiennent tous des chemins de contrôle. La propriété, en particulier, accorde implicitement WriteDacl : vérifiez donc l'Owner des objets Tier 0, pas seulement leur DACL.

Imposer : enregistrer et circonscrire l'inventaire

Un inventaire qui vit dans un tableur dérive en quelques semaines. Encodez-le dans AD pour que les stratégies puissent le cibler :

1. Créez une arborescence d'UO Tier 0 dédiée (par exemple OU=Tier0 avec les sous-UO Accounts, Groups, Servers, Devices) et déplacez-y chaque objet utilisateur, groupe et serveur Tier 0. Ne bloquez l'héritage qu'après avoir examiné ce que cela supprime.
2. Créez des groupes tels que Tier0-Servers et Tier0-Accounts contenant les objets ordinateurs et utilisateurs, afin que les GPO de refus d'ouverture de session et les silos référencent des groupes et non des listes.
3. Réservez la modification de cette arborescence d'UO aux seuls administrateurs Tier 0. Supprimez les délégations héritées accordées au support et aux groupes Tier 1.
4. Pour chaque chemin indirect découvert, tranchez : le supprimer (la réponse habituelle), ou l'accepter et faire entrer le principal qui le contrôle dans le Tier 0.

# Étiqueter les serveurs Tier 0 pour le ciblage des stratégies en aval
$t0 = Get-ADGroup 'Tier0-Servers'
'DC01','DC02','PKI-ISSUING01','ENTRACONNECT01' | ForEach-Object {
    Add-ADGroupMember -Identity $t0 -Members (Get-ADComputer $_)
}

Vérifier

Vérifier consiste à prouver qu'il n'existe aucun chemin de contrôle inexpliqué vers l'ensemble étiqueté :

# Objets protégés par SDProp : tout ce qui n'est pas dans votre liste Tier 0 doit être justifié
Get-ADObject -LDAPFilter '(adminCount=1)' -Properties objectClass, whenChanged |
    Select-Object Name, objectClass, whenChanged, DistinguishedName

# UO Tier 0 : ACE non héritées accordées à des principaux hors Tier 0
$ou = "OU=Tier0,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:$ou").Access | Where-Object { -not $_.IsInherited } |
    Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Les comptes adminCount=1 obsolètes sont fréquents après le départ de personnes des groupes privilégiés. Effacez adminCount et rétablissez l'héritage sur ces comptes une fois confirmé qu'ils n'appartiennent plus à aucun groupe protégé. Dans l'outil de graphe, le contrôle est simple : le nombre de principaux hors Tier 0 disposant d'un chemin vers Domain Admins doit tendre vers zéro, et chaque chemin restant doit faire l'objet d'un ticket.

Ce que cela casse

• Les outils de gestion partagés : une fois les DC déclarés Tier 0, la console SCCM, EDR ou de supervision de l'entreprise qui les gère est soit promue en Tier 0 (avec ses administrateurs), soit doit cesser de gérer les DC. Les deux options modifient la responsabilité opérationnelle et nécessitent un outil ou un périmètre distinct pour le Tier 0.
• Les opérations de virtualisation : les administrateurs VMware ou Hyper-V capables de gérer les VM des DC deviennent des administrateurs Tier 0. Attendez-vous à des résistances et prévoyez un cluster dédié ou un périmètre d'autorisations restreint sur les VM des DC.
• Les droits délégués au support : déplacer les comptes Tier 0 dans une UO protégée supprime les délégations de réinitialisation de mot de passe et de déverrouillage qui s'y appliquaient. Un administrateur qui verrouille son compte Tier 0 doit désormais passer par un pair Tier 0, et non par le support.
• Les restaurations de sauvegarde : réserver la plateforme de sauvegarde aux opérateurs Tier 0 peut ralentir les restaurations de fichiers courantes si la même console sert aux deux. Séparez la tâche de sauvegarde des DC sur une infrastructure dédiée, comme décrit dans protéger les sauvegardes AD contre les rançongiciels.

Pour aller plus loin : la vue d'ensemble Tier 0 et accès à privilèges pour l'ensemble du domaine, les postes d'administration à privilèges pour les postes qui administrent cet inventaire, et ACL et sécurité des objets pour auditer en profondeur les chemins de contrôle indirects.