Le modèle en tiers est-il encore recommandé maintenant que Microsoft parle de modèle d'accès d'entreprise ?

Oui. Le modèle d'accès d'entreprise étend le modèle en tiers aux plans de contrôle cloud et SaaS, mais la règle centrale ne change pas : les identifiants d'un plan plus privilégié ne doivent jamais être exposés sur un système moins fiable. Pour Active Directory sur site, la séparation Tier 0 / 1 / 2 reste la manière concrète de l'appliquer.

Puis-je ajouter des comptes de service à Protected Users ?

Non. Protected Users désactive NTLM, la délégation et les tickets Kerberos de longue durée pour ses membres. Les comptes de service et les comptes ordinateur cesseront de fonctionner. Utilisez plutôt des comptes de service administrés de groupe (gMSA) pour les services.

Quel est le gain le plus rapide si je ne peux pas encore mettre en place tout le modèle en tiers ?

Retirez de Domain Admins les comptes d'usage quotidien, créez des comptes d'administration distincts, ajoutez-les à Protected Users et interdisez-leur l'ouverture de session sur les postes de travail par GPO. Cela suffit à couper le chemin de vol d'identifiants le plus courant.

Modèle en tiers et Protected Users dans Active Directory

La plupart des compromissions d'Active Directory suivent le même chemin. Un attaquant arrive sur un poste de travail, trouve en mémoire un identifiant privilégié parce qu'un administrateur s'y est connecté, puis le réutilise jusqu'à atteindre un contrôleur de domaine. Credential Guard, l'EDR et LAPS compliquent tous la tâche, mais la cause profonde est architecturale : des identifiants très privilégiés ont été exposés sur une machine qu'un simple utilisateur peut compromettre.

Le modèle en tiers supprime cette exposition. Sa règle tient en une phrase : un compte ne peut ouvrir de session que sur les systèmes de son propre tier. Un Domain Admin ne saisit jamais de mot de passe sur un poste de travail, un administrateur de serveurs ne se connecte jamais sur le portable d'un utilisateur et les comptes du support ne touchent jamais aux serveurs. Ce guide traduit cette règle en stratégies de groupe, en appartenances aux groupes et en contrôles.

Les trois tiers

Tier	Contenu	Qui l'administre
Tier 0	Contrôleurs de domaine, AD DS lui-même, AD CS (PKI), AD FS, serveurs Microsoft Entra Connect / Cloud Sync, la plateforme de virtualisation ou de sauvegarde qui héberge les DC, et tout système qui les contrôle	Une poignée de comptes d'administration Tier 0, utilisés uniquement depuis des postes d'administration Tier 0
Tier 1	Serveurs membres et applications : serveurs de fichiers, SQL, web, d'applications	Comptes d'administration serveurs, depuis des serveurs de rebond ou des postes d'administration Tier 1
Tier 2	Postes de travail, portables, appareils utilisateurs, imprimantes	Comptes du support / d'administration des postes

Le plus difficile est d'être honnête sur le Tier 0. Tout ce qui peut contrôler un actif Tier 0 est Tier 0 : le cluster d'hyperviseurs qui exécute des DC virtuels, le serveur de sauvegarde capable de restaurer NTDS.dit, l'outil de déploiement logiciel dont l'agent tourne sur les DC, l'agent de supervision qui s'exécute en SYSTEM sur les DC. Si votre serveur de site SCCM pousse des logiciels sur les contrôleurs de domaine, SCCM est Tier 0.

Microsoft décrit désormais un modèle d'accès d'entreprise plus large, avec des plans de contrôle, de gestion, de données/charges de travail, d'accès utilisateur et d'accès applicatif, qui étend la même idée à Entra ID et aux charges de travail cloud. Pour AD sur site, les trois tiers sont la façon de le mettre en œuvre.

Étape 1 : séparer les comptes

Chaque administrateur reçoit un compte par tier dans lequel il intervient, en plus de son compte utilisateur normal :

jdoe - messagerie, navigation, Office. Aucun droit d'administration nulle part.
adm-t2-jdoe - admin local sur les postes de travail (idéalement via LAPS plutôt que par appartenance à un groupe).
adm-t1-jdoe - admin sur les serveurs membres.
adm-t0-jdoe - Domain Admins ou droits Tier 0 délégués. Quelques personnes seulement.

Créez une arborescence d'UO qui reflète les tiers (Admin\Tier0, Admin\Tier1, Admin\Tier2, chacune avec Accounts, Groups, Devices) pour que les GPO et les délégations puissent cibler proprement chaque tier.

Réduisez ensuite les groupes privilégiés. Vérifiez qui en est réellement membre, y compris par imbrication :

PowerShell

foreach ($g in "Domain Admins","Enterprise Admins","Schema Admins","Administrators",
               "Account Operators","Server Operators","Backup Operators","Print Operators") {
  Get-ADGroupMember -Identity $g -Recursive |
    Select-Object @{n="Group";e={$g}}, SamAccountName, objectClass
}

Account Operators, Server Operators, Backup Operators et Print Operators offrent tous des chemins vers la compromission d'un contrôleur de domaine. Ils doivent être vides. Schema Admins et Enterprise Admins doivent être vides en dehors des changements planifiés.

Étape 2 : imposer les restrictions d'ouverture de session par GPO

Le modèle en tiers ne fonctionne que s'il est imposé, pas seulement documenté. Utilisez User Rights Assignment sous Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies, appliqué par UO de tier :

GPO liée à	Deny log on locally	Deny log on through Remote Desktop Services	Deny access to this computer from the network	Deny log on as a batch job / as a service
Postes de travail (Tier 2)	Groupes d'admin Tier 0 et Tier 1	Groupes d'admin Tier 0 et Tier 1	Groupes d'admin Tier 0 et Tier 1	Groupes d'admin Tier 0 et Tier 1
Serveurs membres (Tier 1)	Groupes d'admin Tier 0	Groupes d'admin Tier 0	Groupes d'admin Tier 0	Groupes d'admin Tier 0
Contrôleurs de domaine (Tier 0)	Groupes d'admin Tier 1 et Tier 2	Groupes d'admin Tier 1 et Tier 2	(en général pas de refus : les DC doivent accepter les ouvertures de session réseau de tout le monde)	Groupes d'admin Tier 1 et Tier 2

Les droits de refus l'emportent sur les droits d'autorisation : la restriction tient même si quelqu'un ajoute adm-t0-jdoe au groupe Administrators local d'un poste. Incluez les groupes intégrés Domain Admins et Enterprise Admins dans les listes de refus Tier 0 des postes de travail et des serveurs membres.

Une remarque sur l'ouverture de session réseau : refuser « access from the network » aux comptes Tier 0 sur les serveurs bloque SMB, WinRM et l'administration à distance similaire par ces comptes, ce qui est précisément le but. Testez d'abord sur une UO pilote, car certains outils de gestion anciens comptent sur un Domain Admin qui se connecte partout.

Étape 3 : placer les humains Tier 0 dans Protected Users

Protected Users est un groupe de sécurité global intégré (Windows Server 2012 R2 et ultérieur) qui applique à ses membres des protections non configurables. Sur les appareils sous Windows 10 / Windows 11 ou Windows Server 2012 R2 ou ultérieur, et avec un niveau fonctionnel de domaine Windows Server 2012 R2 ou supérieur pour les protections côté contrôleur de domaine :

L'authentification NTLM est refusée : il n'y a donc aucune empreinte NTLM à voler ou à relayer.
Kerberos n'utilise ni DES ni RC4 pour la pré-authentification.
Le compte ne peut pas être délégué (délégation contrainte ou non contrainte).
La durée de vie du TGT est plafonnée à quatre heures au lieu de dix.
Les identifiants ne sont pas mis en cache : pas de vérificateur d'ouverture de session en cache, pas de mot de passe en clair CredSSP ou WDigest, pas de clés à long terme conservées en mémoire.

Ajoutez chaque compte humain d'administration Tier 0 et Tier 1. N'ajoutez pas les comptes de service, les comptes ordinateur ni votre compte d'urgence (il doit fonctionner quand Kerberos ne fonctionne pas). Testez d'abord : tout ce qui authentifie ces comptes en NTLM, par exemple une appliance de gestion qui se connecte par adresse IP, cessera de fonctionner, ce qui constitue généralement un constat en soi.

Pour les comptes qui ne peuvent pas rejoindre Protected Users, activez au minimum Account is sensitive and cannot be delegated sur l'objet compte.

PowerShell

Add-ADGroupMember -Identity "Protected Users" -Members adm-t0-jdoe, adm-t1-jdoe
Get-ADUser -Filter {AdminCount -eq 1} -Properties AccountNotDelegated |
  Select-Object SamAccountName, AccountNotDelegated

Étape 4 : administrer depuis le bon endroit

Les restrictions d'ouverture de session disent où un compte d'administration ne peut pas aller ; il lui faut aussi un endroit sûr où aller. Un poste d'administration sécurisé (PAW, privileged access workstation) est un appareil durci utilisé uniquement pour l'administration : pas de messagerie, pas de navigation, contrôle des applications strict, Credential Guard activé, et géré depuis son propre tier. Pour le Tier 0, c'est non négociable. Pour le Tier 1, des serveurs de rebond durcis sont un compromis courant.

Lorsque vous devez vous connecter en RDP depuis un appareil moins fiable, utilisez Remote Credential Guard (mstsc /remoteGuard) ou le mode Restricted Admin (mstsc /restrictedAdmin) pour que des identifiants réutilisables ne soient pas envoyés à l'hôte distant. Remote Credential Guard est généralement préférable, car il garde les requêtes Kerberos côté client tout en vous permettant d'accéder aux ressources réseau sous votre propre identité.

Étape 5 : stratégies et silos d'authentification (facultatif)

Pour une application plus stricte que les droits utilisateur, les stratégies et silos d'authentification d'Active Directory (niveau fonctionnel de domaine 2012 R2+) restreignent l'endroit où les comptes Tier 0 peuvent obtenir des tickets Kerberos, avec un contrôle effectué par le contrôleur de domaine lui-même. Par exemple, les membres d'un silo « Tier0 » ne reçoivent un TGT que s'ils ouvrent une session depuis un ordinateur de ce silo. Cela nécessite le blindage Kerberos (FAST) et des tests soigneux, mais comble des brèches que les droits de refus par GPO ne couvrent pas, comme un compte Tier 0 utilisé depuis un appareil non géré.

Vérifier

Où les comptes Tier 0 se sont-ils connectés ? Sur les contrôleurs de domaine, les événements 4768 (demande de TGT) et 4769 (demande de ticket de service) indiquent l'adresse du client ; sur les systèmes membres, l'événement 4624 avec le type d'ouverture de session 2 (interactive), 10 (interactive à distance) ou 3 (réseau) montre où les comptes ont été utilisés. Construisez un rapport des comptes Tier 0 qui s'authentifient depuis autre chose qu'un DC ou un PAW : il doit être vide.
Protected Users est-il effectif ? Sur un DC, le journal Applications and Services Logs > Microsoft > Windows > Authentication enregistre les échecs des membres de Protected Users (les journaux ProtectedUserFailures-DomainController et ProtectedUserSuccesses-DomainController sur les DC, et ProtectedUser-Client sur les clients, sont désactivés par défaut : activez-les d'abord). Les tentatives NTLM des membres apparaissent comme des échecs.
Existe-t-il des chemins cachés ? Des outils comme BloodHound (Community Edition) ou PingCastle cartographient les chemins d'attaque à travers les ACL, l'imbrication des groupes et la délégation. Exécutez-les régulièrement : un modèle en tiers sur le papier fuit souvent par une vieille ACL sur une UO ou une GPO modifiable par un groupe Tier 1.

Liste de contrôle

Liste des actifs Tier 0 formalisée, y compris hyperviseurs, sauvegarde, PKI et serveurs de synchronisation
Comptes d'administration distincts par tier, aucun droit d'administration sur les comptes d'usage quotidien
Groupes Operators vides, Schema/Enterprise Admins vides par défaut
GPO de refus d'ouverture de session sur les postes de travail, les serveurs membres et les DC
Comptes humains privilégiés dans Protected Users ; les autres marqués « sensitive and cannot be delegated »
PAW pour le Tier 0 ; Remote Credential Guard pour le RDP
Rapport mensuel des ouvertures de session Tier 0 hors du Tier 0
Revue planifiée des chemins d'attaque (BloodHound CE / PingCastle)

Le modèle en tiers relève davantage de l'organisation que de la technique, et c'est pour cela qu'il est souvent négligé. Associez-le à des mots de passe d'admin local uniques et à Credential Guard, et un seul portable hameçonné cesse d'être un chemin vers vos contrôleurs de domaine.