Bonnes pratiques de délégation Active Directory

Meilleures pratiques de délégation Active Directory

Déléguer le contrôle de parties spécifiques du réseau permet aux utilisateurs d'accéder aux données nécessaires pour leur travail. Cependant, offrir un accès illimité à tout le monde peut représenter des risques de cybersécurité importants pour une organisation. La délégation Active Directory peut restreindre efficacement l'accès uniquement à ce dont les utilisateurs ont besoin.

Suivez les meilleures pratiques de délégation Active Directory ci-dessous pour protéger votre réseau.

Qu'est-ce que la délégation Active Directory ?

La délégation Active Directory (AD) vous permet d'autoriser les utilisateurs à effectuer des tâches nécessitant des permissions élevées — sans les ajouter à des groupes hautement privilégiés tels que Domain Admins et Account Operators. Pour déléguer le contrôle dans Active Directory, vous pouvez utiliser l'Assistant de délégation de contrôle dans la console de gestion Microsoft (MMC) Active Directory Users and Computers (ADUC).

Comment développer un modèle de délégation AD

Il est préférable d'adopter une approche pratique pour déléguer des droits. N'oubliez pas que la simplicité équivaut à la maintenabilité, et un modèle de délégation durable vous rapportera énormément en vous permettant de contrôler correctement et efficacement les permissions déléguées dans Active Directory.

Étape 1 : Créer des rôles

La première étape dans le développement d'un modèle de délégation Active Directory est de créer un ensemble de rôles d'administrateur et de leur attribuer les responsabilités appropriées. Limitez-vous à un petit nombre de rôles gérable pour un contrôle pratique de la délégation. Trouver le bon équilibre peut être difficile car avoir trop de rôles ajoute de la complexité et des charges de gestion, mais avoir trop peu de rôles ne permettra pas une séparation efficace des rôles.

Les meilleures pratiques suggèrent d'utiliser les rôles suivants :

Administrateurs de service :

• Les administrateurs d'entreprise sont responsables de l'administration des services de haut niveau dans l'entreprise. Ce groupe ne devrait contenir aucun membre permanent.
• Les administrateurs de domaine sont responsables de l'administration des services de haut niveau dans le domaine. Ce groupe ne doit contenir qu'un petit nombre d'administrateurs de confiance et facile à gérer.
• Les administrateurs de niveau 4 sont responsables de l'administration des services à travers le domaine. Les droits d'accès accordés permettent de gérer uniquement les services et fonctionnalités nécessaires et servent de point d'escalade pour les administrateurs de données.

Administrateurs de données :

• Les administrateurs de niveau 1 sont responsables de la gestion générale des objets d'annuaire, y compris la réinitialisation des mots de passe, la modification des propriétés des comptes utilisateurs, etc.
• Les administrateurs de niveau 2 sont responsables de la création et de la suppression sélectives des comptes d'utilisateurs et d'ordinateurs pour leur emplacement ou organisation.
• Les administrateurs régionaux sont responsables de la gestion de la structure des unités organisationnelles (OU) et ont reçu les autorisations pour créer la plupart des objets au sein de leur OU.
• Les administrateurs de niveau 3 gèrent tous les administrateurs de données et servent de points d'assistance et d'escalade de haut niveau pour tous les administrateurs régionaux.

Étape 2 : Attribuer des responsabilités

Ensuite, développez un ensemble de cas d'utilisation pour aider à identifier ce que chaque rôle peut et ne peut pas faire. Des cas d'utilisation bien préparés vous aideront à expliquer les rôles aux parties prenantes de votre organisation et à garantir une attribution de rôle adéquate. Lors de la définition des responsabilités, catégorisez-les par fréquence, importance et difficulté.

Les listes de contrôle d'accès (ACL) sur les conteneurs Active Directory définissent quels objets peuvent être créés et comment ces objets sont gérés. La délégation de droits implique des opérations de base sur les objets, telles que la capacité de voir un objet, de créer un objet enfant d'une classe spécifiée, ou de lire les informations d'attribut et de sécurité sur des objets d'une classe spécifiée. Outre ces opérations de base, Active Directory définit des Droits Étendus, qui permettent des opérations telles que Envoyer en tant que et Gérer la Topologie de Réplication.

Automatisez le processus de test pour garantir que chaque rôle fonctionne comme prévu.

Étape 3 : Définir un modèle de sécurité d'OU

Une fois vos rôles et responsabilités établis, vous devriez définir votre modèle d'unité d'organisation (OU) et de groupe de sécurité. Une OU de niveau supérieur (ou une série d'OUs) devrait être créée directement sous le domaine pour contenir tous les objets. Cette OU de niveau supérieur a le but spécifique de définir le périmètre de gestion avancé pour les administrateurs de niveau 4. Avec une OU de niveau supérieur, les droits sur le service d'annuaire peuvent commencer au niveau de l'OU plutôt qu'au niveau du domaine.

Sous les unités organisationnelles de premier niveau, vous devriez créer des hiérarchies de sous-unités organisationnelles distinctes pour représenter chaque région ou unité commerciale avec une équipe de gestion des données distincte. Chaque sous-unité organisationnelle régionale devrait avoir une hiérarchie d'unités organisationnelles standard et non extensible pour gérer les objets d'annuaire.

Enfin, pour empêcher les administrateurs d'augmenter leurs privilèges, créez des sous-groupes d'administrateurs séparés — un groupe d'Admins de niveau 1, un groupe d'Admins de niveau 2 et un groupe d'Admins régionaux pour chaque sous-hiérarchie d'OU — et placez les comptes appropriés dans chaque groupe. Placer ces comptes dans des OU séparées permet de restreindre la gestion à leur niveau ou en dessous.

Étape 4 : Contrôlez comment les droits délégués sont utilisés

La clé d'un modèle de délégation réussi est de faire respecter le principe du moindre privilège. En pratique, cela signifie que chaque principal de sécurité (tel qu'un utilisateur ou un compte de service) doit pouvoir effectuer uniquement les tâches requises pour ses rôles et rien de plus. Tous les administrateurs doivent se connecter en tant qu'utilisateurs moyens et utiliser leurs droits privilégiés uniquement lorsque c'est nécessaire.

Pour réaliser cela sans demander à l'utilisateur de se déconnecter puis de se reconnecter, utilisez le service de connexion secondaire (Runas.exe). Cela permet aux utilisateurs d'élever leurs privilèges en fournissant des informations d'identification alternatives lors de l'exécution de scripts ou d'autres exécutables sur des serveurs et des postes de travail.

Comment déléguer les privilèges d'administrateur dans Active Directory

L'Assistant Délégation de contrôle offre un moyen facile de déléguer des permissions dans Active Directory. Par exemple, supposons que vous voulez que les membres du groupe Help Desk puissent créer, supprimer et gérer des comptes d'utilisateurs dans l'unité d'organisation All Users de votre domaine AD. Pour cela, vous devez effectuer les étapes suivantes :

1. Ouvrez la console Utilisateurs et ordinateurs Active Directory.
2. Cliquez avec le bouton droit sur l'OU All Users et choisissez Delegate Control. Cliquez sur le bouton Next dans l'assistant Delegation of Control Wizard.
3. Cliquez sur le bouton Ajouter dans la page Utilisateurs ou Groupes de l'assistant.
4. Dans la boîte de dialogue Select Users, Computers, or Groups, saisissez le nom du groupe (Help Desk), cliquez sur le bouton Check Names pour vérifier que le nom est correct, et cliquez sur OK.
5. Assurez-vous que le nom du groupe sélectionné figure désormais sur la liste de la page Utilisateurs ou Groupes, et cliquez sur Suivant.
6. Sélectionnez Create, delete, and manage user accounts sur la page des tâches à déléguer et cliquez sur Suivant.
7. Vérifiez les informations de la dernière page de l'assistant et cliquez sur Finish.

Vous pouvez confirmer que les permissions ont été correctement définies en vérifiant l'onglet Sécurité des propriétés de l'OU cible.

Considérations lors de la délégation de permissions spécifiques

La délégation dans Active Directory permet aux organisations d'accorder des autorisations que les utilisateurs n'auraient généralement pas sans les ajouter à des groupes privilégiés. Cependant, les entreprises doivent prendre en compte quelques éléments lors de la délégation des permissions.

Par exemple, une bonne conception d'Unité Organisationnelle (OU) joue un rôle crucial dans la délégation AD. Ensuite, avec cette OU ou cet ensemble d'OUs, établissez des niveaux pour la sécurité. Dans chaque niveau, vous devriez accorder l'accès le moins privilégié. L'accès à privilèges minimaux limite ce que les utilisateurs peuvent faire au strict nécessaire pour leur travail. L'accès à privilèges minimaux est la clé de la cybersécurité d'une organisation, car il réduit le nombre de personnes ayant accès aux données critiques.

Par exemple, une organisation peut restreindre les permissions de réinitialisation de mot de passe ou de déverrouillage, accorder des permissions pour modifier uniquement les numéros de téléphone, déléguer la gestion de l'appartenance à des groupes dans Active Directory à des utilisateurs spécifiques, et ainsi de suite.

Il est également dans le meilleur intérêt d'une entreprise d'éviter d'utiliser des groupes intégrés (y compris les Enterprise Admins ou Domain Admins) car ces groupes peuvent avoir des permissions robustes et étendues. Au lieu de cela, déléguer les permissions de l'Active Directory en niveaux et effectuer des audits réguliers de l'accès privilégié est préférable.

Meilleures pratiques de délégation AD

Suivez ces directives pour utiliser Active Directory Domain Services avec succès et déléguer de manière appropriée.

• Pour que la délégation soit réussie, les unités d'organisation (OU) doivent être conçues et mises en œuvre correctement, et les objets appropriés (utilisateurs, groupes, ordinateurs) doivent y être placés.
• N'utilisez pas de groupes intégrés ; les privilèges au sein du domaine sont généralement trop larges. Au lieu de cela, de nouveaux groupes devraient être créés qui sont conçus uniquement pour la délégation.
• Utilisez des UO imbriquées. Il y aura différents niveaux d'administrateurs de données au sein de AD. Certains se verront déléguer le contrôle sur un type de données entier, comme les serveurs — et d'autres pourraient se voir attribuer seulement un sous-ensemble d'un type de données, comme les serveurs de fichiers. Cette hiérarchie est établie en créant des UO et des sous-UO, avec l'administration déléguée au sommet ayant plus de privilèges que ceux plus bas dans la structure des UO.
• Effectuez des audits réguliers pour voir qui s'est vu déléguer des privilèges administratifs à différents niveaux dans AD.
• Effectuez des audits annuels sur qui dispose de quels contrôles délégués Active Directory.
• Auditez votre environnement à la recherche d’activités suspectes pouvant indiquer une compromission ou une mauvaise utilisation des droits délégués, telles que des tentatives d’élévation de privilèges pour contrôler des objets informatiques, d’accès à des données sensibles via le réseau, ou de modification ou suppression des paramètres de sécurité (comme les exigences de mot de passe).
• Envisagez de passer d'un modèle de délégation qui repose sur des privilèges permanents à une stratégie de Privileged Access Management (PAM) avec un accès juste-à-temps. De cette manière, vous pouvez éviter les abus ou l'utilisation malveillante des droits d'accès permanents, améliorer le contrôle de l'utilisation des privilèges et réduire considérablement la surface de votre attaque.

Ces groupes disposent d'une autorité totale sur l'ensemble du domaine : tout compte dans Domain Admins peut lire et écrire chaque objet dans l'annuaire, quel que soit le niveau de spécificité de la tâche réelle.

La délégation Active Directory corrige ce décalage en attribuant des autorisations spécifiques aux tâches au niveau de l’OU plutôt que par l’appartenance à un groupe privilégié.

Ce guide explique comment construire un modèle de délégation AD, comment appliquer les droits délégués à l’aide de l’Assistant Délégation de Contrôle, et les pratiques opérationnelles qui empêchent l’accumulation des permissions déléguées en accès non contrôlés.

Un technicien du help desk ajouté à Domain Admins pour des réinitialisations de mot de passe de routine dispose du même accès que l'ingénieur qui maintient l'infrastructure AD, quel que soit le travail réel requis.

Qu'est-ce que la délégation Active Directory ?

Environ 30 % des intrusions commencent par l'abus de comptes valides, selon The IBM X-Force 2025 Threat Intelligence Index. Les groupes privilégiés intégrés d'Active Directory rendent ces identifiants disproportionnellement dangereux car ils accordent une autorité de lecture et d'écriture à l'échelle du domaine à chaque compte qu'ils contiennent.

La délégation Active Directory permet aux administrateurs d'accorder des autorisations élevées spécifiques à une tâche aux utilisateurs ou groupes sans les ajouter à des groupes privilégiés tels que Domain Admins ou Account Operators.

Comment développer un modèle de délégation AD

Un technicien du help desk délégué pour réinitialiser les mots de passe dans une OU obtient ce droit uniquement dans ce périmètre. La permission ne s'étend pas aux autres OUs et le compte n'apparaît dans aucun groupe privilégié.

Délégation Active Directory applique des entrées de contrôle d'accès (ACE) à une unité organisationnelle (OU) ou une classe d'objet spécifique, limitant la permission exactement à ce que le rôle requiert.

Un modèle de délégation définit les rôles administratifs dans votre environnement, les droits détenus par chaque rôle, et la structure OU qui délimite ces droits. Sans cela, les permissions déléguées s'accumulent de manière informelle et deviennent impossibles à auditer.

Étape 1 : Créez des rôles

1. Les administrateurs de données gèrent les objets dans l'annuaire sans toucher à l'infrastructure sous-jacente. Organisez ce niveau par portée :
2. Les administrateurs de service gèrent l'infrastructure Active Directory elle-même. Ce niveau comprend les Enterprise Admins, Domain Admins et tout compte qui maintient la réplication AD, les services de domaine ou les comptes de service utilisés par des systèmes critiques. Chaque membre de ce niveau peut affecter chaque objet du domaine, il faut donc le garder aussi restreint que l'environnement le permet.

• Niveau 2 (Administrateurs Départementaux) : Gérer les comptes utilisateurs au sein d’un département ou d’une fonction spécifique.
• Niveau 1 (Administrateurs Régionaux) : Gérer les objets utilisateur et groupe au sein d'une région géographique ou d'une unité commerciale définie.

Commencez par définir deux niveaux de rôles d’administrateur : administrateurs de service et administrateurs des données.

• Niveau 3 (Help Desk) : Effectuer des opérations limitées, telles que la réinitialisation des mots de passe et le déblocage des comptes, au sein d'une OU assignée.

Gardez le nombre de rôles réduit. Chaque rôle supplémentaire crée un ensemble d'autorisations qui doit être documenté, attribué et examiné. La prolifération des rôles est une cause principale de l'accumulation d'accès non contrôlés dans les environnements AD matures.

Étape 2 : Attribuer les responsabilités

Pour chaque rôle, documentez quels droits s’appliquent, sur quelles classes d’objets et dans quelles UO. Cartographiez chaque affectation selon trois dimensions :

1. Fréquence : À quelle fréquence le rôle exécute la tâche ; cela détermine la cadence de révision et si des outils automatisés sont justifiés.
2. Importance : Que la tâche soit critique pour l'entreprise ou un travail administratif de routine influence les seuils d'approbation pour l'octroi initial.
3. Difficulté : Si la tâche nécessite un jugement technique ou peut être effectuée par un généraliste ; cela détermine les exigences en matière de formation et d’intégration.

Étape 3 : Définir un modèle de sécurité OU

Utilisez les listes de contrôle d'accès (ACL) standard d'Active Directory pour les opérations courantes et Extended Rights pour des opérations telles que Force Change Password ou Apply Group Policy. Documentez chaque affectation au moment de la délégation ; les droits non documentés sont invisibles lors des revues d'accès et des audits.

Pour chaque périmètre, créez un groupe de sécurité dédié et appliquez les droits délégués au groupe plutôt qu’aux comptes individuels.

Au niveau supérieur, créez des OU qui correspondent à votre modèle administratif, qu'il soit géographique, organisationnel ou fonctionnel. Dans chaque OU de niveau supérieur, créez des sous-OU correspondant aux périmètres d'administration des données.

Cette structure limite l'escalade basée sur l'héritage : un administrateur délégué au niveau de la sous-OU ne peut pas affecter les objets dans les OU parentes ou sœurs sauf si des droits lui sont explicitement accordés à ce niveau. Passez en revue la structure des OU chaque fois que le modèle organisationnel change.

Concevez une hiérarchie OU qui reflète vos limites de délégation avant d'appliquer des autorisations. Placez les comptes privilégiés et administratifs dans des OU séparées des objets qu'ils gèrent : un compte Domain Admin stocké dans la même OU que les utilisateurs qu'il administre peut être ciblé via une privilege escalation au niveau de l'OU.

Étape 1 : Ouvrez l’Assistant Délégation de contrôle

Comment déléguer le contrôle dans Active Directory

L’Assistant Delegation of Control dans Active Directory Users and Computers (ADUC) est l’outil principal pour appliquer les droits délégués. Il écrit directement les entrées ACL dans l’OU ou le conteneur que vous sélectionnez et crée une attribution de permissions pouvant être consultée ultérieurement via l’onglet Sécurité de l’OU.

Étape 2 : Sélectionnez les utilisateurs ou groupes

L'affectation basée sur les groupes vous permet d'ajouter ou de retirer l'accès en modifiant l'appartenance plutôt qu'en modifiant directement l'ACL de l'OU, ce qui maintient la structure des permissions auditable et réversible.

Dans le volet Utilisateurs ou Groupes, ajoutez le security group qui représente le rôle d’administrateur recevant les droits délégués.

Dans ADUC, activez Fonctions Avancées dans le menu Affichage si ce n’est pas déjà fait. Naviguez jusqu’à l’OU où vous souhaitez appliquer la délégation, faites un clic droit, puis sélectionnez « Déléguer le contrôle ». L’assistant applique les droits uniquement à l’OU sélectionnée et à son contenu ; les OU parentes ne sont pas affectées.

Étape 3 : Choisissez les tâches à déléguer

Les droits attribués aux comptes individuels créent des ACE qui persistent lors des changements de rôle et du départ, sauf si quelqu'un les supprime manuellement.

Sélectionnez « Déléguer les tâches courantes suivantes » pour les opérations standard telles que la création ou la suppression de comptes utilisateur, la réinitialisation des mots de passe, la lecture des informations utilisateur ou la gestion de l'appartenance aux groupes.

Étape 5 : Complétez et vérifiez

Étape 4 : Spécifiez la portée de la délégation

Pour les droits en dehors de la liste prédéfinie, y compris les Extended Rights tels que Force Change Password ou Apply Group Policy, sélectionnez « Créer une tâche personnalisée à déléguer ».

Une fois l’assistant terminé, vérifiez le résultat en cliquant avec le bouton droit sur l’OU dans ADUC, en sélectionnant Propriétés, puis en ouvrant l’onglet Sécurité. Confirmez que l’ACE attendu est bien listé avec les autorisations et la portée correctes.

Pour les tâches personnalisées, définissez à quelles classes d’objets la délégation s’applique (objets utilisateur, objets ordinateur ou objets groupe) et si l’autorisation s’applique à l’OU elle-même, aux objets dans l’OU ou aux deux. Restreignez la portée aussi strictement que les responsabilités documentées du rôle l’exigent.

Meilleures pratiques pour la délégation Active Directory

Testez en vous connectant en tant que membre du groupe délégué et en tentant à la fois les opérations autorisées et exclues pour confirmer que la délégation fonctionne exactement comme prévu.

Documentez chaque délégation au moment de l'affectation

Un modèle de délégation et le Delegation of Control Wizard fournissent la base technique. Ces pratiques maintiennent la sécurité de cette base à mesure que l'environnement et l'organisation évoluent.

Après chaque exécution de l’Assistant de délégation de contrôle, enregistrez l’OU, le groupe recevant les droits, les autorisations spécifiques accordées et la justification commerciale dans un registre central d’accès avant que cet accès ne soit utilisé.

Attribuez des droits délégués aux groupes de sécurité, pas aux comptes individuels

Une feuille de calcul, un ticket ITSM ou un système IAM dédié remplissent tous cet objectif. Ce qui importe, c’est que la documentation existe avant que l’accès ne soit utilisé et qu’elle couvre la justification commerciale, pas seulement le périmètre technique.

Lorsque des droits sont attribués à un compte individuel, ils persistent dans l'ACL de l'OU même après que cette personne quitte l'organisation, change de rôle ou que son compte soit désactivé.

L'assistant ne produit aucun journal propre ; il applique les ACE au descripteur de sécurité de l'OU sans enregistrer l'action, l'approbateur ou la raison de l'octroi. Les ACE non documentés deviennent invisibles lors des revues d'accès et des audits, et après un changement de personnel, ils perdent leur seule source de contexte.

L'ACE reste attaché au SID du compte et ne se supprime pas automatiquement dans le cadre des étapes standard de départ.

Les modifications d'appartenance aux groupes génèrent des événements dans le journal de sécurité ; les modifications directes des ACE sur les OU nécessitent des paramètres spécifiques de la politique d'audit pour produire des preuves équivalentes.

Les droits attribués à un groupe de sécurité sont révoqués en supprimant le compte du groupe lors du départ, ce qui correspond aux flux de travail standard d’IAM, crée une piste d’audit claire et s’adapte à la croissance ou aux changements de l’équipe.

Appliquez le principe du moindre privilège à chaque délégation

Accordez uniquement les droits dont chaque rôle a besoin pour accomplir ses tâches documentées, en utilisant la portée OU la plus étroite et l'ensemble de permissions le plus spécifique requis par le travail.

Après avoir appliqué une délégation, testez-la en vous connectant en tant que membre du groupe délégué et en confirmant que seules les opérations prévues réussissent et que les opérations exclues échouent.

Examinez les autorisations déléguées au moins trimestriellement

Planifiez des examens d'accès périodiques pour énumérer les ACE sur les OU sensibles et confirmer que chaque entrée reflète toujours une exigence commerciale actuelle.

Le principe du moindre privilège appliqué à la délégation signifie limiter les droits à la sous-OU pertinente plutôt qu'à l'OU parente, et sélectionner des droits étendus spécifiques plutôt qu'un accès large en écriture. Cela implique également de diviser les tâches composées en délégations séparées plutôt que d'accorder des permissions plus larges pour couvrir plusieurs cas.

Les revues trimestrielles détectent la dérive des permissions avant qu’elle ne s’accumule dans le retard d’accès non documenté qui rend les environnements difficiles à auditer.

Détecter les permissions déléguées dans Active Directory à grande échelle nécessite PowerShell ou des outils dédiés ; l'interface native ADUC affiche l'état actuel des permissions mais n'enregistre rien sur la date de création d'un ACE ni sur son créateur.

Utilisez des comptes séparés pour les opérations privilégiées

Ouvrez l’onglet Sécurité sur l’OU cible (visible uniquement avec les fonctionnalités avancées activées dans ADUC) et vérifiez les entrées explicites et héritées. Supprimez toute ACE appartenant à un groupe sans membres actifs ni but documenté.

Exigez que les administrateurs utilisent un compte administrateur dédié lorsqu'ils effectuent des tâches déléguées, distinct du compte qu'ils utilisent pour les e-mails et le travail quotidien.

Une stratégie de Privileged Access Management qui sépare les comptes administrateurs des identifiants d'utilisation quotidienne est l'un des contrôles les plus efficaces contre les mouvements latéraux basés sur les identifiants.

Le compte standard gère les activités courantes et présente le profil de risque d’un identifiant utilisateur ordinaire ; le compte administrateur est activé uniquement lorsqu’une opération élevée est nécessaire et ne doit pas avoir accès aux e-mails, à la navigation web ou à toute station de travail traitant du contenu non fiable.

Avancez vers un accès just-in-time pour les délégations à privilèges élevés

L'isolation de la portée des privilèges limite ce qu'un attaquant peut obtenir en compromettant une seule identité et rend l'activité des comptes privilégiés auditable de manière isolée du comportement utilisateur habituel.

L'accès délégué permanent signifie que chaque compte disposant de ces droits est exposé en permanence via le vol d'identifiants, le phishing ou les mouvements latéraux, quel que soit la rareté d'utilisation réelle du compte.

Pour les rôles les plus privilégiés, éliminez complètement l'accès délégué permanent et remplacez-le par un accès just-in-time qui accorde des permissions élevées uniquement pendant la durée d'une tâche approuvée et les révoque automatiquement à la fin de la tâche.

Chaque type d’autorisation ci-dessous comporte des implications de sécurité que l’Assistant de délégation de contrôle ne met pas en évidence.

Considérations lors de la délégation de permissions spécifiques

L'accès just-in-time réduit la fenêtre pendant laquelle une identité compromise peut exploiter les droits délégués, diminue l'empreinte ACE que les revues trimestrielles doivent couvrir, et génère un enregistrement d'approbation et de session qui renforce les preuves d'audit pour les environnements réglementés.

Réinitialisation du mot de passe et déblocage du compte

Gestion des membres du groupe

Auditez les groupes concernés pour les membres protégés (Domain Admins, Enterprise Admins, Account Operators) avant d’appliquer cette délégation.

Toute délégation appliquée à ces comptes ne tiendra pas, et la simple tentative de l’appliquer est un signal pour enquêter.

Autorisations de l’objet de stratégie de groupe

Vérifiez d’abord la limite de l’OU. Un rôle délégué pour réinitialiser les mots de passe dans une OU contenant des comptes Domain Admin ou service accounts détient un chemin de réinitialisation des identifiants pour un accès tier-zero ; la portée de la permission est techniquement correcte, mais la portée de l’OU ne l’est pas. Vérifiez que l’OU contient uniquement des comptes utilisateurs standards avant d’appliquer la délégation.

Le processus SDProp d’Active Directory réapplique les ACE AdminSDHolder à ces comptes toutes les 60 minutes, écrasant silencieusement la délégation personnalisée.

Gestion des comptes informatiques

La délégation de Group Policy est divisée en trois droits (créer, modifier et lier), et le droit de liaison ne doit pas être accordé avec les autres par défaut.

Définissez ms-DS-MachineAccountQuota à zéro avant de déléguer la gestion des comptes ordinateurs ; sa valeur par défaut de 10 permet à tout utilisateur authentifié de joindre des ordinateurs au domaine sans aucune délégation.

Lier un GPO applique immédiatement ses paramètres à chaque objet dans l’OU cible et ses enfants. Traitez le lien comme une attribution distincte et élevée nécessitant sa propre approbation.

Paramètres de délégation d'authentification Kerberos

Notez également que la délégation standard des comptes informatiques inclut l'accès en écriture SPN ; ne donnez pas ce droit dans l'attribution sauf si le rôle l'exige spécifiquement, car l'accès en écriture SPN crée une exposition au Kerberoasting.

La délégation Kerberos est un attribut distinct de la délégation de contrôle Active Directory ; elle n’est pas configurée via l’Assistant Délégation de Contrôle et est facile à oublier lors des revues de délégation.

Comment Netwrix aide avec la délégation Active Directory

Lors de l’audit des comptes délégués, vérifiez si certains disposent également d’une délégation Kerberos sans restriction. Le cas échéant, traitez ce compte comme Tier 0 quelle que soit son OU, car un service compromis avec une délégation sans restriction expose tous les TGT que le contrôleur de domaine lui a transmis.

Les rôles accumulent des droits au fil du temps, les groupes récupèrent des membres qu’ils ne devraient pas avoir, et les ACE appliquées pour un projet spécifique restent sur les OU bien après la fin de ce projet.

La délégation Active Directory répartit le contrôle dans l’environnement, et chaque permission distribuée est une faille potentielle si elle n’est pas revue ou documentée.

Sans une visibilité continue sur les modifications des autorisations, les équipes de sécurité ne peuvent pas maintenir la posture d'accès que le modèle de délégation devrait appliquer.

La gouvernance de l'accès délégué nécessite de détecter les modifications des autorisations en temps réel, d'identifier les dérives avant qu'elles ne deviennent exploitables, et de produire des preuves défendables pour les revues d'accès et les audits de conformité.

Netwrix Auditor surveille les modifications des permissions AD en temps réel et produit la piste d’audit avant-après qui soutient les revues d’accès et les preuves réglementaires.

Ensemble, ils offrent aux équipes de sécurité une visibilité continue à la fois sur les changements en cours et sur l’état d’accès que ces changements produisent.

Netwrix Access Analyzer cartographie l'accès effectif via les groupes imbriqués et l'héritage des OU pour détecter les droits délégués excessifs ou obsolètes avant qu'ils ne deviennent des constats d'audit.

Demandez une démo pour voir comment Netwrix peut vous aider à gérer la délégation Active Directory, détecter les dérives de permissions et maintenir une piste d’audit défendable.