Le modèle en tiers et les comptes d'administration

Le modèle en tiers (tiering) est une organisation de l'administration d'Active Directory qui classe les ressources en trois niveaux selon le contrôle qu'elles donnent, et qui interdit à un compte d'administration de se connecter à une machine d'un niveau inférieur au sien. Ainsi, les identifiants d'un administrateur du domaine ne se trouvent jamais sur un poste ou un serveur moins protégé, où ils pourraient être volés. Ce chapitre délimite les tiers de Sorbier, crée les comptes et l'arborescence d'OU, impose les interdictions par GPO et protège les comptes privilégiés.

Le principe : ne jamais descendre

L'ANSSI, dans ses recommandations de 2023 sur l'administration sécurisée des systèmes reposant sur Active Directory, et Microsoft, dans son modèle d'accès, partent du même constat : un secret se trouve sur une machine dès qu'un compte s'y authentifie (chapitre 2). Si un administrateur du domaine ouvre une session sur le poste de Julie pour la dépanner, ses identifiants passent par ce poste ; si ce poste est compromis, le domaine l'est.

Deux règles :

1. Un compte d'un tier n'administre que son tier. adm1-clambert administre les serveurs, pas les contrôleurs ni les postes.
2. Un compte ne se connecte jamais à une machine d'un tier inférieur. Le tier 0 ne se connecte ni aux serveurs membres ni aux postes. Le contrôle va du haut vers le bas, les connexions jamais.

Des comptes séparés pour chaque usage

Chaque administrateur a plusieurs comptes, un par usage :

Les comptes d'administration n'ont pas de boîte aux lettres et n'ont pas accès à Internet : la porte d'entrée la plus fréquente (le courriel piégé, la page web malveillante) ne peut alors jamais s'ouvrir avec des privilèges. Ils ont un mot de passe différent de celui du compte de bureautique, plus long, et soumis à une stratégie affinée (chapitre 7).

L'arborescence d'OU d'une administration en tiers

On range les comptes et les machines d'administration dans une branche dédiée, pour leur appliquer des GPO et des délégations distinctes. Une organisation possible chez Sorbier :

ad.sorbier.example
├── Domain Controllers                (srv-ad, srv-ad2)
├── Administration
│   ├── Tier0
│   │   ├── Comptes                   (adm0-amercier, adm0-clambert)
│   │   ├── Groupes                   (GG_Admins_T0)
│   │   └── Postes                    (PAW-T0-01)
│   ├── Tier1
│   │   ├── Comptes                   (adm1-amercier, adm1-clambert)
│   │   └── Groupes                   (GG_Admins_T1_Serveurs)
│   └── Tier2
│       ├── Comptes                   (adm2-mdiallo, adm2-clambert)
│       └── Groupes                   (GG_Admins_T2_Postes)
└── Sorbier
    ├── Serveurs                      (srv-fichiers, srv-gestion, srv-journaux)
    ├── Ordinateurs                   (postes des salariés)
    ├── Utilisateurs
    └── Groupes

La délégation suit la même logique : les membres de GG_Admins_T2_Postes reçoivent le droit de gérer les objets ordinateurs de l'OU Sorbier/Ordinateurs, mais aucun droit sur la branche Administration. Seuls les comptes de tier 0 peuvent modifier les comptes et groupes de tier 0. Le cours Windows Server montre l'assistant de délégation et les commandes de création des comptes.

# Créer un compte de tier 0, sensible, non délégable, avec un mot de passe saisi à l'écran
New-ADUser -Name "adm0-amercier" -SamAccountName "adm0-amercier" `
    -UserPrincipalName "adm0-amercier@ad.sorbier.example" `
    -Path "OU=Comptes,OU=Tier0,OU=Administration,DC=ad,DC=sorbier,DC=example" `
    -AccountPassword (Read-Host -AsSecureString "Mot de passe") -Enabled $true `
    -AccountNotDelegated $true -Description "Administration du domaine, tier 0"

Add-ADGroupMember -Identity "Admins du domaine" -Members "adm0-amercier"
Add-ADGroupMember -Identity "Protected Users" -Members "adm0-amercier"

Interdire les connexions vers un tier inférieur, par GPO

La règle « ne jamais descendre » s'impose techniquement avec des droits utilisateur, dans Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur :

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

Deux GPO suffisent chez Sorbier :

Sur les contrôleurs de domaine, c'est l'inverse : on limite qui peut s'y connecter. La GPO des contrôleurs n'accorde Permettre l'ouverture d'une session locale et Autoriser l'ouverture de session par les services Bureau à distance qu'aux administrateurs du tier 0.

Les stratégies et silos d'authentification (Authentication Policies and Silos, disponibles depuis Windows Server 2012 R2) vont plus loin : elles disent depuis quelles machines un compte peut obtenir un ticket Kerberos. Un silo de tier 0 peut ainsi imposer que adm0-amercier ne s'authentifie que depuis le poste d'administration du tier 0 et les contrôleurs. C'est la mesure recommandée par l'ANSSI pour les niveaux élevés ; elle demande une préparation soignée et dépasse ce qu'on attend en BTS, mais tu dois savoir qu'elle existe.

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

Un poste d'administration dédié (PAW, Privileged Access Workstation) est un poste réservé aux tâches d'administration, sans messagerie ni navigation sur Internet, durci et administré lui-même par le tier qu'il sert. Le poste d'administration de Sorbier (192.168.10.209, VLAN 99 ADMIN) joue ce rôle :

• il ne sert qu'aux comptes adm0-* et adm1-* ; on n'y lit pas ses courriels ;
• ses flux sortants sont limités par le pare-feu aux contrôleurs, aux serveurs et au bastion (192.168.10.210) ; Internet est bloqué, sauf vers les sites de mises à jour ;
• il est dans le tier le plus élevé qu'il administre : s'il sert au tier 0, il est de tier 0 ;
• son disque est chiffré (BitLocker), Credential Guard y est actif, et seuls des logiciels approuvés y tournent.

Le bastion (192.168.10.210) complète le dispositif : les administrateurs ouvrent leurs sessions d'administration à travers lui, ce qui centralise l'authentification multifacteur et l'enregistrement des sessions. Le chapitre Comptes à privilèges et bastion du cours Authentification détaille ce fonctionnement, le cours Cybersécurité des infrastructures l'architecture des zones d'administration, et le cours Pare-feu pfSense les règles de filtrage du VLAN 99 (de la matrice des flux aux règles).

Protéger les comptes privilégiés

Le groupe Protected Users. Créé avec Windows Server 2012 R2, il applique à ses membres des protections non configurables, à condition que le niveau fonctionnel du domaine soit au moins Windows Server 2012 R2 :

C'était la solution attendue dans le sujet 2024 pour la mise en cache des identifiants des administrateurs. Deux précautions données par Microsoft : ne jamais y mettre de comptes de service ni de comptes d'ordinateur (la protection ne sert à rien pour eux et casse leur fonctionnement), et ajouter les administrateurs progressivement, après avoir vérifié qu'ils s'authentifient bien en AES. Le sujet 2024 rappelait aussi de garder au moins un compte hors du groupe, pour le secours.

« Le compte est sensible et ne peut pas être délégué ». Cette case de l'onglet Compte (ou -AccountNotDelegated $true) interdit à tout service d'agir au nom du compte. On la coche sur tous les comptes d'administration.

Des groupes privilégiés presque vides. Administrateurs de l'entreprise et Administrateurs du schéma restent vides en temps normal ; on y ajoute un compte le temps d'une opération, puis on le retire. Admins du domaine ne contient que deux ou trois comptes adm0-*. Les groupes Opérateurs de compte, Opérateurs de serveur, Opérateurs de sauvegarde et Opérateurs d'impression restent vides : on délègue finement à la place.

L'objet AdminSDHolder. Toutes les 60 minutes, un processus du contrôleur qui détient le rôle d'émulateur PDC recopie les permissions de l'objet CN=AdminSDHolder,CN=System sur les comptes et groupes protégés (membres des groupes privilégiés), et met leur attribut adminCount à 1. Conséquences : une délégation posée sur une OU ne s'applique pas aux comptes d'administration (c'est voulu), et une modification des permissions d'AdminSDHolder se propage à tous les comptes privilégiés. Toute modification de cet objet est donc suspecte et doit être surveillée (chapitre 9).

Le compte Administrateur intégré du domaine (RID 500) reçoit un mot de passe très long rangé dans un coffre, n'est utilisé qu'en secours et chaque utilisation déclenche une alerte.

Exercices