Mettre en place un tiering Active Directory avec des PAW Tier 0

Mettre en place un modèle de tiering Active Directory ne consiste pas seulement à créer trois unités d’organisation. L’objectif est de séparer les identités, les postes d’administration, les droits et les flux afin qu’un incident sur un poste utilisateur ou un serveur applicatif ne permette pas d’atteindre le plan d’identité.

1. Le problème que le tiering cherche à résoudre

Dans une administration traditionnelle, un même compte privilégié peut être utilisé pour gérer les contrôleurs de domaine, les serveurs membres et parfois même les postes utilisateurs. Cette pratique est confortable, mais elle crée un chemin d’escalade direct : si un poste de travail est compromis, les secrets d’un administrateur qui s’y connecte peuvent être récupérés en mémoire, dans le cache d’authentification ou par interception.

• Un incident sur un poste bureautique peut exposer un compte d’administration.
• Un compte réutilisé sur plusieurs niveaux transporte la compromission vers les systèmes les plus sensibles.
• Un compte membre d’un groupe très privilégié peut permettre de modifier les GPO, les ACL, les contrôleurs de domaine et les mécanismes d’authentification.
• La segmentation réseau seule ne suffit pas si les mêmes identifiants circulent sur tous les niveaux.

Le tiering crée donc des frontières de confiance. Les comptes d’un niveau élevé ne doivent jamais s’authentifier sur un niveau inférieur.

2. Définir les niveaux de confiance

Tier 0 : le plan d’identité

• Contrôleurs de domaine et services Active Directory.
• PKI d’entreprise et autorités de certification capables d’émettre des certificats d’authentification.
• Serveurs de fédération, synchronisation d’identités et outils disposant d’un contrôle équivalent sur l’annuaire.
• Comptes, groupes, GPO, stations d’administration et équipements capables de modifier le Tier 0.
• Systèmes de sauvegarde ou d’administration détenant un accès de restauration ou de contrôle sur les DC.

Tier 1 : serveurs et applications

• Serveurs membres Windows et Linux.
• Hyperviseurs et clusters de virtualisation qui n’hébergent pas ou ne contrôlent pas le Tier 0.
• Applications, bases de données, sauvegarde applicative, stockage et supervision.
• Comptes d’administration des serveurs.

Tier 2 : postes et support utilisateur

• Postes utilisateurs.
• Comptes de support de proximité.
• Outils de télédistribution et de gestion du parc.
• Terminaux exposés à la messagerie, au Web et aux documents externes.

Règle structurante : un administrateur Tier 0 ne doit pas ouvrir une session sur un serveur Tier 1 ou un poste Tier 2. Un administrateur Tier 1 ne doit pas ouvrir une session sur un poste Tier 2.

3. Séparer les comptes d’administration

Chaque administrateur conserve un compte bureautique sans privilège et reçoit un compte par niveau réellement administré.

Le compte Tier 0 ne doit pas disposer d’une boîte aux lettres utilisée au quotidien. Il ne doit pas naviguer sur Internet et ne doit pas être ajouté à des groupes Tier 1 ou Tier 2 par commodité.

4. Construire les OU et les groupes

OU=Tiering
├── OU=Tier0
│   ├── OU=Accounts
│   ├── OU=Groups
│   ├── OU=PAW
│   └── OU=Service-Accounts
├── OU=Tier1
│   ├── OU=Accounts
│   ├── OU=Groups
│   └── OU=PAW
└── OU=Tier2
    ├── OU=Accounts
    └── OU=Groups

Exemples de groupes anonymisés :

• GG-T0-PAW-Users : droit d’ouverture de session sur les PAW Tier 0.
• GG-T0-PAW-Local-Admins : administration locale des PAW, à limiter strictement.
• GG-T0-AD-Admins : délégations d’administration de l’annuaire.
• GG-T1-Server-Admins : administration des serveurs membres.
• GG-Deny-Logon-T0-On-Lower-Tiers : groupe exploité par les stratégies de refus de connexion.

5. Déployer des PAW Tier 0

Un PAW est une station d’administration privilégiée dédiée. Dans un environnement multisite, un déploiement réaliste consiste à prévoir au moins un PAW Tier 0 par site critique, par exemple SITEA-PAW-T0-01 et SITEB-PAW-T0-01.

• Machine physique ou VM fortement isolée selon le modèle de menace.
• Pas de client de messagerie, de suite bureautique générale ou d’outils personnels.
• Navigation Internet bloquée ou limitée à une liste d’administration explicite.
• Secure Boot, TPM, BitLocker, antivirus/EDR, VBS, Credential Guard et HVCI.
• Administration uniquement avec les comptes du niveau correspondant.
• Accès entrant limité aux réseaux d’administration connus.

6. Installer seulement les outils Tier 0 nécessaires

Le PAW doit permettre l’administration distante sans imposer une session RDP permanente sur les contrôleurs de domaine. Installez uniquement les composants utiles : Active Directory Users and Computers, Active Directory Administrative Center, Group Policy Management, DNS Manager, Sites and Services, outils PKI et modules PowerShell.

Import-Module ServerManager

$Features = @(
    'RSAT-AD-Tools',
    'RSAT-ADDS-Tools',
    'RSAT-DNS-Server',
    'GPMC',
    'RSAT-ADCS-Mgmt'
)

foreach ($Feature in $Features) {
    Install-WindowsFeature -Name $Feature -IncludeManagementTools
}

7. Concevoir les flux réseau

Tier 0 ne signifie pas « tout ouvrir entre les actifs Tier 0 ». Appliquez le moindre privilège et partez des méthodes d’administration utilisées.

Le catalogue global n’est pas un serveur séparé : il s’agit d’un rôle porté par certains DC. Vérifiez les DC concernés avant d’autoriser 3268/3269.

Get-ADDomainController -Filter * |
    Select-Object HostName,Site,IPv4Address,IsGlobalCatalog

8. Durcir le pare-feu du PAW

Sur le profil Domaine, une cible cohérente est : pare-feu activé, trafic entrant bloqué par défaut, trafic sortant autorisé et fusion des règles locales désactivée. Les règles d’accès doivent venir de la GPO.

Get-NetFirewallProfile -PolicyStore ActiveStore -Name Domain |
    Select-Object Name,Enabled,DefaultInboundAction,
        DefaultOutboundAction,AllowInboundRules,
        AllowLocalFirewallRules

Pour RDP, conservez seulement des règles GPO ciblant les réseaux d’administration. Désactivez les règles locales générales telles que Remote Desktop – User Mode (TCP-In) si elles autorisent Any.

9. Activer Credential Guard et HVCI

Dans la stratégie Turn On Virtualization Based Security, activez Secure Boot, la protection de l’intégrité du code et Credential Guard. Le mode Enabled without lock permet un retour arrière par GPO, ce qui est adapté à une phase pilote.

$PolicyPath = 'HKLM:SOFTWAREPoliciesMicrosoftWindowsDeviceGuard'
$Policy = Get-ItemProperty -Path $PolicyPath
$DeviceGuard = Get-CimInstance `
    -Namespace 'rootMicrosoftWindowsDeviceGuard' `
    -ClassName 'Win32_DeviceGuard'

$Configured = @($DeviceGuard.SecurityServicesConfigured)
$Running = @($DeviceGuard.SecurityServicesRunning)

[pscustomobject]@{
    EnableVBS                  = $Policy.EnableVirtualizationBasedSecurity
    LsaCfgFlags                = $Policy.LsaCfgFlags
    VBSRunning                 = $DeviceGuard.VirtualizationBasedSecurityStatus -eq 2
    CredentialGuardConfigured = $Configured -contains 1
    CredentialGuardRunning    = $Running -contains 1
    HVCIConfigured            = $Configured -contains 2
    HVCIRunning               = $Running -contains 2
}

Attention à l’interprétation : la valeur 1 représente Credential Guard et la valeur 2 HVCI/Memory Integrity. La seule présence de 2 ne prouve pas que Credential Guard fonctionne.

10. Ajouter les groupes locaux sans écraser l’existant

Avec les préférences de stratégie de groupe, utilisez l’action Update sur le groupe local Administrateurs et ajoutez le groupe Tier 0. Ne cochez pas les options supprimant tous les utilisateurs ou groupes existants sans avoir établi une liste complète des membres attendus.

$Administrators = Get-LocalGroup -SID 'S-1-5-32-544'
Get-LocalGroupMember -Group $Administrators.Name |
    Select-Object Name,ObjectClass,PrincipalSource

11. Vérifier Active Directory depuis le PAW

Un PAW n’est pas un contrôleur de domaine. Pour dcdiag, utilisez l’option /s: afin de cibler chaque DC. Complétez avec repadmin et des tests de ports.

$DCs = Get-ADDomainController -Filter * | Sort-Object Site,HostName

foreach ($DC in $DCs) {
    dcdiag.exe /s:$($DC.HostName) /q
}

repadmin.exe /replsummary
repadmin.exe /showrepl *

Testez au minimum DNS, Kerberos, RPC, LDAP, SMB, LDAPS et Global Catalog. Si un site distant ne répond que sur DNS 53, ne concluez pas immédiatement à une panne AD : cela peut révéler une matrice de flux incomplète.

12. Définir les refus de connexion

• Refuser aux comptes Tier 0 l’ouverture de session locale et RDP sur Tier 1 et Tier 2.
• Refuser aux comptes Tier 1 l’ouverture de session sur Tier 2.
• Autoriser les comptes Tier 0 uniquement sur les PAW et actifs Tier 0 prévus.
• Tester les stratégies de refus sur un petit périmètre avant généralisation.
• Prévoir un compte de secours gouverné et surveillé pour éviter un verrouillage opérationnel total.

13. Plan de déploiement réaliste

1. Inventorier les actifs, groupes, comptes de service et outils ayant un contrôle Tier 0.
2. Créer les comptes d’administration séparés.
3. Créer les OU et groupes, sans déplacer immédiatement tous les actifs.
4. Déployer un PAW pilote sur un site.
5. Installer les outils RSAT et valider les flux.
6. Durcir le pare-feu, Credential Guard, HVCI et les règles de connexion.
7. Tester l’administration quotidienne sans RDP permanent vers les DC.
8. Déployer le second PAW et vérifier le fonctionnement intersite.
9. Appliquer les refus de connexion aux niveaux inférieurs.
10. Auditer les journaux de connexion et corriger les usages résiduels.
11. Étendre ensuite le modèle aux comptes et PAW Tier 1.

14. Pièges fréquemment rencontrés

• Considérer que tous les systèmes de sécurité ou de supervision sont automatiquement Tier 0.
• Autoriser RDP vers tous les DC sans besoin identifié.
• Utiliser le compte Tier 0 pour administrer un hyperviseur ou un serveur applicatif Tier 1.
• Créer des comptes séparés sans mettre en place les refus de connexion correspondants.
• Désactiver le pare-feu Windows sur les PAW ou sur une large OU de serveurs.
• Confondre HVCI actif avec Credential Guard actif.
• Déployer les GPO sur tout le domaine avant d’avoir validé un groupe pilote.
• Oublier les comptes de service, outils de sauvegarde et solutions de management qui peuvent contrôler les DC.

15. Checklist de validation

• Les comptes T0, T1 et bureautiques sont distincts.
• Le compte T0 ne possède aucun usage bureautique.
• Les PAW sont dans une OU dédiée avec une GPO dédiée.
• Le pare-feu Domaine bloque l’entrant par défaut.
• Les règles RDP générales ne sont plus effectives.
• La fusion des règles locales est désactivée sur le profil Domaine.
• Credential Guard et HVCI sont tous deux configurés et actifs.
• Les outils RSAT fonctionnent depuis le PAW.
• Les DC distants sont joignables sur les ports nécessaires.
• RDP vers les DC est une exception documentée.
• Les refus de connexion empêchent les comptes élevés d’accéder aux niveaux inférieurs.
• Une procédure de secours et de retour arrière existe.

Conclusion

Un tiering réussi ne se mesure pas au nombre d’OU créées, mais à l’absence de chemins d’authentification dangereux entre les niveaux. Commencez petit, validez un PAW, observez les dépendances réelles et durcissez progressivement. La séparation des comptes, le contrôle des flux, les refus de connexion et la validation de Credential Guard forment un ensemble : retirer l’un de ces éléments affaiblit fortement le modèle.