Le modèle d'administration par niveaux d'Active Directory expliqué

Un administrateur de domaine se connecte à l’ordinateur portable d’un utilisateur pour résoudre un problème d’imprimante. Un malware déjà présent sur cet ordinateur lit les identifiants dans la mémoire du Local Security Authority Subsystem Service (LSASS) et les rejoue dans tout l’environnement, rendant le plan de contrôle d’identité de tout le domaine accessible depuis une machine du service d’assistance.

Cela se produit constamment, et les chiffres le confirment. Le Netwrix 2026 Data and Identity Security Report a révélé que 75 % des expositions de données sensibles commencent par des identités compromises ou des permissions mal configurées. La plupart commencent par un identifiant privilégié stocké en mémoire sur une machine non fiable.

La question évidente est de savoir pourquoi les contrôles que la plupart des organisations utilisent déjà n'ont pas réussi à l'arrêter. L'authentification multifactorielle (MFA), privileged access management (PAM) et l'Accès Conditionnel agissent sur les identifiants une fois qu'ils atteignent l'appareil, ce qui est trop tard pour intervenir. Le modèle d'administration par niveaux agit plus tôt, en régulant où une identité privilégiée est autorisée à apparaître dès le départ.

Qu'est-ce que le modèle d'administration par niveaux d'Active Directory ?

Le modèle d’administration hiérarchique d’Active Directory (AD) est une conception d’accès privilégié qui sépare les comptes, systèmes et outils administratifs en Niveau 0, Niveau 1 et Niveau 2 selon leur champ de contrôle sur l’environnement. Sa règle de sécurité principale est que les identifiants des niveaux supérieurs s’authentifient uniquement depuis des systèmes approuvés dans leur niveau attribué, ce qui réduit le vol d’identifiants et les mouvements latéraux.

Le principe sous-jacent est que c’est le clavier, et non le système cible, qui définit le niveau de confiance effectif d’une session. Un identifiant Domain Admin saisi sur un ordinateur portable du support technique transmet l’exposition de cet ordinateur directement au contrôleur de domaine qu’il gère. La documentation du modèle de niveaux AD de Microsoft considère donc la station de travail administrative comme faisant partie de la frontière de sécurité.

Les unités organisationnelles (OUs), les groupes et Group Policy Objects (GPOs) sont généralement le point de départ des équipes, et ils organisent uniquement les objets auxquels le modèle s'applique. La séparation des niveaux se fait par des comptes dédiés par niveau, l'application de la connexion, les postes de travail administratifs, délégation délibérée, la surveillance et un processus de révision des exceptions.

Pourquoi la hiérarchisation d’Active Directory est toujours importante

La hiérarchisation précède la plupart des outils actuellement vendus pour résoudre l'accès privilégié. Les organisations utilisant MFA, Privileged Access Management et l'accès conditionnel portent encore l'exposition qu'elle était censée éliminer, et les raisons se résument au rayon d'impact, au chemin d'attaque et à la couverture.

Il contient un rayon d'explosion qui couvre tout l'environnement

La hiérarchisation limite la portée d’une seule identité exposée, ce qui est crucial dans AD car AD est le plan de contrôle d’identité. Les comptes privilégiés et les services qui les soutiennent contrôlent l’accès, l’authentification, les politiques et la récupération pour chaque système qui fait confiance au domaine.

Sans cette limite, une seule identité d’administrateur de répertoire suffit pour tout atteindre. Récupérer un serveur membre prend un après-midi, tandis que récupérer un plan de contrôle d’identité sur lequel un attaquant a eu des droits administratifs est un projet de récupération de forêt.

Il ferme le chemin que la plupart des violations utilisent réellement

Le tiering bloque la condition préalable unique dont dépendent la plupart des compromissions de domaine : une identité à privilèges élevés apparaissant sur un poste de travail à moindre confiance. Pass-the-hash, le dumping des identifiants LSASS, et le vol de tickets Kerberos nécessitent que cela se soit produit en premier.

Supprimer la précondition, plutôt que de détecter chaque technique, rend le contrôle durable, car il résiste à des outils que personne n’a encore développés.

Il comble une lacune que Privileged Access Management et MFA ne peuvent couvrir seuls

La hiérarchisation régit où une identité peut être utilisée, ce qui est la seule question que les autres contrôles laissent ouverte. Les postes de travail à accès privilégié (PAWs) établissent la confiance du point de terminaison, PAM et l’accès just-in-time (JIT) régissent la durée, et MFA et l’Accès Conditionnel régissent la force de l’authentification.

Le token theft playbook de Microsoft montre à quel point la force de l'authentification est peu utile une fois qu'un identifiant est déjà sur un endpoint compromis, car un attaquant qui vole et rejoue un jeton émis obtient l'accès même si l'utilisateur a satisfait MFA.

Les trois niveaux d'administration d'Active Directory

Chaque niveau regroupe les actifs et les identités administratives selon le contrôle qu’ils détiennent, et les exigences en matière de poste de travail et de connexion se renforcent à mesure que ce contrôle augmente. Le niveau d’un système est déterminé par ce qu’il peut atteindre.

Niveau 0 : Le plan de contrôle d'identité

Le niveau 0 contient tous les actifs qui contrôlent le service d'annuaire, directement ou indirectement. L'inventaire de Microsoft couvre les contrôleurs de domaine et Active Directory Domain Services (AD DS), Active Directory Certificate Services (AD CS) et l'infrastructure à clé publique (PKI) qui les soutient, ainsi que Active Directory Federation Services (AD FS). Microsoft Entra Connect ainsi que les comptes et groupes du niveau 0 y appartiennent également.

Les systèmes de sauvegarde capables de restaurer un contrôleur de domaine appartiennent aussi ici. Tout ce qui peut restaurer un contrôleur de domaine peut aussi en reconstruire un selon les conditions d’un attaquant.

Les administrateurs Tier 0 travaillent uniquement depuis Tier 0 PAWs, en utilisant des comptes dédiés Tier 0. Protéger les contrôleurs de domaine commence par contrôler quelles informations d’identification peuvent y accéder.

Niveau 1 : serveurs, charges de travail et applications d’entreprise

Le niveau 1 couvre les serveurs membres, applications, bases de données et les comptes qui les administrent, correspondant aux plans de gestion et de données/charge de travail dans le Enterprise Access Model de Microsoft.

En pratique, cela signifie des serveurs de fichiers, SQL Server, Exchange Server, des applications métier et des plateformes de virtualisation limitées aux charges de travail de niveau 1. La contrainte fonctionne dans les deux sens. Un administrateur de niveau 1 se connecte uniquement aux systèmes de niveau 1, et les systèmes de niveau 1 lancent uniquement l’administration de niveau 1.

Niveau 2 : Postes de travail et support utilisateur

Le niveau 2 présente la plus grande exposition des trois, en raison de ce qui se passe chaque jour sur ces endpoints. Les utilisateurs naviguent sur le web, ouvrent des pièces jointes, installent des logiciels et subissent les tentatives de phishing qui déclenchent la plupart des intrusions.

Cela couvre les postes de travail des utilisateurs finaux, les ordinateurs portables, les comptes utilisateurs et les identités qui les soutiennent. Le travail du service d'assistance se situe ici, couvrant les réinitialisations de mots de passe, le support des postes de travail et le dépannage des endpoints, et les droits des comptes de niveau 2 restent limités aux ressources de niveau 2.

Comment implémenter le modèle par niveaux dans Active Directory

La mise en œuvre commence par un inventaire précis et se termine par une application qui résiste à un administrateur local. Microsoft considère sa séquence recommandée comme un chemin plutôt qu'une chaîne de dépendances stricte, permettant ainsi aux étapes ultérieures de s'exécuter en parallèle.

1. Inventorier chaque compte et actif privilégié

Cataloguez chaque système AD, compte et outil avec accès administratif. Les indirects sont les plus importants, car rien ne signale qu'ils peuvent atteindre Tier 0. Cette liste comprend service accounts, les plateformes de sauvegarde pouvant restaurer les contrôleurs de domaine, l'infrastructure à clé publique et Entra Connect, que Microsoft classe comme un composant Tier 0.

Seules 36 % des organisations ont réalisé une évaluation complète de la sécurité AD au cours des 12 derniers mois, selon le Netwrix 2026 Data and Identity Security Report, la plupart des inventaires partant donc de zéro plutôt que d’un enregistrement existant.

2. Classez chaque actif selon ce qu’il peut contrôler

Tout compte ou système pouvant gérer un niveau supérieur appartient à ce niveau, quel que soit l’endroit où il était censé se situer.

Les plateformes de sauvegarde, les hôtes de virtualisation exécutant des machines virtuelles Tier 0, les agents d’endpoint detection and response sur les contrôleurs de domaine, et les droits de gestion de Group Policy appartiennent tous à Tier 0 lorsqu’ils peuvent accéder aux actifs Tier 0. Microsoft Incident Response a documenté le coût d’une erreur : un misconfigured PAM server situé en Tier 1 détenait les clés de Tier 0 et offrait aux attaquants un passage à travers la frontière.

3. Créez des comptes séparés pour chaque niveau

Attribuez aux administrateurs des comptes distincts par niveau, sans chevauchement. Cela signifie un compte identity-admin de niveau 0, un compte server-admin de niveau 1, et des identifiants standard pour l’usage quotidien pour tout le reste.

Le plan de modernisation rapide de Microsoft cible 100 % des utilisateurs privilégiés sur site disposant de comptes dédiés séparés. La séparation des comptes permet également l’application de la connexion, car un compte unique utilisé sur plusieurs niveaux ne donne rien à restreindre.

4. Appliquer des restrictions de connexion au contrôleur de domaine et au endpoint

Déployez les deux mécanismes disponibles plutôt que de choisir entre eux. Group Policy offre une large couverture sur les endpoints, et les politiques d’authentification Kerberos ajoutent une frontière que le contrôleur de domaine applique lui-même, qui est la partie qui tient encore après qu’une machine de niveau inférieur est entièrement compromise.

Les restrictions de connexion basées sur GPO refusent les droits de connexion interactifs, Remote Desktop Protocol (RDP), réseau, batch et service pour les comptes de niveau supérieur sur des points de terminaison de niveau inférieur via l'attribution des droits utilisateur. L'Autorité de sécurité locale du point de terminaison les applique, c'est pourquoi Microsoft reconnaît qu'un administrateur local peut contourner la stratégie de groupe et que la restriction ne s'applique qu'aux machines Windows jointes à AD.

Les stratégies d'authentification Kerberos et les silos de stratégies d'authentification restreignent l'origine d'une identité privilégiée, et le Centre de distribution de clés (KDC) du contrôleur de domaine applique cette vérification lors de l'émission d'un ticket. AD refuse d'émettre un Ticket Granting Ticket depuis un ordinateur non autorisé même si les identifiants sont corrects.

Les deux mécanismes comportent des prérequis faciles à manquer. Les vérifications du périphérique source nécessitent que le Kerberos armoring, également appelé Flexible Authentication Secure Tunneling, soit activé sur les contrôleurs de domaine et les clients. Les politiques d’authentification exemptent également le compte Administrateur de domaine intégré, qui doit être contrôlé séparément.

5. Donnez à chaque niveau sa propre station de travail renforcée

Déployez un PAW par niveau afin que l’environnement applique la séparation au lieu de compter sur un administrateur pour se souvenir d’une règle sous pression temporelle. Les recommandations de Microsoft indiquent que le modèle par niveaux dépend d’une administration démarrant depuis une station de travail de confiance correspondant au niveau administré.

Un PAW de niveau 0 suit des restrictions d’application strictes qui suppriment les emails, la navigation et les logiciels de productivité, qui sont les vecteurs de livraison des malwares de collecte de données d’identification. Associer le PAW avec Windows Defender Credential Guard maintient les identifiants dérivés hors de portée sur la machine elle-même.

6. Déployer par phases, en commençant par Tier 0

Protégez d'abord le Tier 0, en couvrant les comptes, les PAW et l'application, avant d'étendre le même processus au Tier 1 puis au Tier 2. Les phases ultérieures dépendent d'un plan de contrôle d'identité propre.

Testez les GPO d’application hors production avant qu’elles n’atteignent un domaine actif, car Microsoft avertit qu’un ordre de liaison incorrect peut empêcher les administrateurs de domaine d’accéder à tous les systèmes Windows du domaine, y compris les contrôleurs de domaine.

Erreurs courantes à éviter lors de la mise en œuvre du modèle par niveaux dans Active Directory

La plupart des programmes de hiérarchisation sont bien conçus, puis minés par l’écart entre la conception et ce qui est réellement appliqué. Chaque erreur élargit cet écart de manière prévisible, et chacune apparaît des mois après la clôture du projet.

Considérer le tiering comme un projet de refonte d’OU

Créer uniquement les OU Tier 0, Tier 1 et Tier 2 laisse les comptes privilégiés libres de s’authentifier partout. Les politiques d’authentification et les droits de refus GPO font respecter la limite, tandis que la structure du conteneur organise uniquement ce à quoi ces contrôles s’appliquent.

Configurez les restrictions de connexion avant de déplacer les objets AD dans la nouvelle structure OU, car les règles de refus prévalent sur les règles d’autorisation et une structure partiellement migrée peut entraîner des surprises dans les deux sens.

Autoriser les comptes et endpoints à double usage

Conservez les identifiants Tier 0 sur des points d’accès administratifs dédiés. Microsoft Incident Response constate à plusieurs reprises que les administrateurs utilisant des appareils administratifs ordinaires pour le travail quotidien laissent derrière eux des identifiants privilégiés que les outils de récupération d’identifiants peuvent exploiter.

Les comptes séparés et les PAW sont des contrôles, pas des commodités, et les abandonner sous pression temporelle est la manière la plus courante dont la hiérarchisation cesse silencieusement de fonctionner.

Surveillance des comptes de service et de l'automatisation

Les tâches planifiées, les outils de déploiement, les scripts et les comptes de service nécessitent la même discipline de niveau que les administrateurs humains, c’est-à-dire un propriétaire nommé, least privilege et un chemin d’authentification aligné sur le niveau.

Refusez les droits de connexion interactive pour les comptes de service et maintenez le chemin d'authentification de chaque service dans son niveau attribué. Group Managed Service Accounts aident en supprimant le mot de passe statique partagé qui rend un compte de service portable entre les niveaux.

Lacunes dans la surveillance des connexions inter-niveaux

Surveillez une authentification avec des identifiants Tier 0 sur un système Tier 1 ou Tier 2. Microsoft considère l’Événement 4964 comme très critique et conseille qu’une connexion de Domain Admin sur un poste utilisateur déclenche à la fois une alerte et une enquête.

Les échecs de connexion et l'utilisation explicite des identifiants, les ID d'événement 4625 et 4648, sont des signaux d'enquête utiles aux côtés des modifications de l'appartenance au privileged-group, des modifications de GPO et des exceptions accordées une fois et jamais révisées. Configurez explicitement la politique d'audit, car de nombreux paramètres GPO liés à l'audit sont livrés en Non Configuré.

Comment Netwrix prend en charge la visibilité par niveaux et les preuves d’audit

La hiérarchisation est une décision de conception et d'application que l'organisation détient. Les outils couvrent ce que la conception ne peut pas faire seule : prouver que les limites tiennent encore des mois plus tard et supprimer les identifiants permanents qui rendent la traversée digne d'être tentée.

Netwrix Auditor suit les modifications privilégiées à tous les niveaux

Netwrix Auditor est un produit d’audit informatique sur site qui suit les modifications privilégiées d’AD, les changements d’appartenance aux groupes, les modifications de GPO et les changements d’autorisations avec les valeurs avant et après. Ses rapports indiquent qui a changé quoi, quand et où, jusqu’à la station de travail d’origine.

Plusieurs de ces fonctionnalités correspondent directement à l'application des niveaux. L'analyse des échecs de connexion fait apparaître les tentatives d'authentification qu'une restriction inter-niveaux vient de bloquer, montrant que l'application fonctionne et n'est pas seulement configurée.

Les alertes de détection d'escalade de privilèges se déclenchent lorsqu'un compte obtient un accès élevé qu'il ne détenait pas auparavant, et la détection d'anomalies signale un comportement administratif qui s'écarte de la base de référence du compte. La couverture s'étend à Entra ID ainsi qu'à AD sur site, de sorte qu'une carte des niveaux hybride reste visible en un seul endroit.

Flagler Bank a obtenu une vue continue de son profil de risque informatique avec un département informatique d’une seule personne, réduisant les enquêtes de plusieurs heures à 10 minutes et atteignant la première valeur 30 minutes après la configuration.

Netwrix Privilege Secure prend en charge la séparation des comptes et l’accès just-in-time

Netwrix Privilege Secure fournit un accès privilégié limité à la tâche et crée une piste d’audit pour chaque session. Il crée un compte éphémère pour la session et le détruit ensuite, de sorte que les identifiants privilégiés existent uniquement pendant la réalisation du travail approuvé.

Cela importe car 76 % des organisations ne peuvent pas révoquer immédiatement un accès permanent une fois qu'il n'est plus nécessaire, selon le Netwrix 2026 Data and Identity Security Report.

Eastern Carver County Schools a remplacé les privilèges permanents par un accès just-in-time sur les systèmes contenant les données de 9 300 élèves, terminant le déploiement en quelques jours et supprimant la précipitation liée à l’audit des droits administratifs permanents.

Aucun des deux produits n’implémente le modèle par niveaux lui-même ; ils existent tous deux pour prouver qu’il fonctionne toujours après la fin du travail de conception.

Commencez par Tier 0, puis rendez le modèle opérationnel

Un programme de hiérarchisation devient opérationnel lorsque l’équipe peut démontrer que les identifiants de niveau supérieur sont restés dans les chemins d’authentification approuvés, qu’un propriétaire a examiné chaque exception et que la piste d’audit prouve que l’application a été respectée. Les connexions inter-niveaux bloquées, les modifications des groupes privilégiés, l’ancienneté des exceptions et la propriété du contrôle sont les mesures à suivre.

Pour la plupart des organisations, le point de départ efficace n'est pas une refonte. Inventoriez et protégez le plan de contrôle d'identité Tier 0, émettez des comptes Tier 0 séparés, déployez des PAW renforcés et appliquez des restrictions de connexion à la fois sur le point de terminaison et le KDC.

Demandez une démo pour voir comment Netwrix suit les modifications privilégiées entre les niveaux, signale les connexions inter-niveaux et conserve les preuves d’audit qui prouvent que les limites sont respectées.