La délégation de contrôle Active Directory
Sommaire
I. Présentation
Dans ce tutoriel, nous allons voir comment déléguer des permissions au sein d'un domaine Active Directory. Grâce à la délégation de permissions, appelée "délégation de contrôle" dans la console Active Directory, il est possible de donner l'autorisation de réaliser des tâches d'administration à des utilisateurs "non-administrateurs".
D'un point de vue de la sécurité, c'est intéressant, car on peut autoriser un utilisateur ou un groupe à effectuer une action, par exemple réinitialiser le mot de passe des utilisateurs, sans pour autant que l'utilisateur soit membre du groupe "Admins du domaine", ou un autre groupe avec des privilèges plus importants.
La délégation de contrôle est fréquemment utilisée dans certains cas de figure, notamment pour effectuer les tâches suivantes :
- Réinitialiser les mots de passe de comptes utilisateurs (par exemple, dans une école pour une personne qui gère les comptes des élèves)
- Ajouter un ordinateur dans le domaine (par exemple, pour le compte utilisé par l'outil de déploiement ou pour les techniciens en charge des déploiements)
- Ajouter un utilisateur à un groupe (utile pour le service support)
- Désactiver des comptes utilisateurs
- Etc.
Voici quelques exemples, mais les possibilités sont très nombreuses alors je ne serai pas étonné que votre besoin ne soit pas dans cette liste. Je vais prendre un cas de figure que je trouve très utile et assez populaire, disons : le fait d'attribuer la permission de déverrouiller les comptes Active Directory et de réinitialiser le mot de passe des comptes. Ainsi, on peut imaginer que le groupe "GG-Service-Support" de l'Active Directory dispose de cette autorisation pour tous les comptes de l'OU "Personnel" de l'Active Directory.
II. Où peut s'appliquer la délégation de contrôle ?
Lorsque l'on prévoit de mettre en place une délégation de contrôle dans l'Active Directory, cela peut-être effectué à différents niveaux du domaine Active Directory. Disons que c'est assez granulaire et flexible. Au niveau de l'annuaire Active Directory, la délégation peut être configurée au niveau des éléments suivants :
- L'intégralité du domaine Active Directory
- Un site Active Directory
- Une unité d'organisation spécifique
- Un objet spécifique de l'annuaire
Néanmoins, il y a quelques règles à respecter si l'on veut suivre les bonnes pratiques. Tout d'abord, il est déconseillé d'attribuer des permissions directement sur un utilisateur ! Il vaut mieux créer un groupe de sécurité, ajouter l'utilisateur à ce groupe, et attribuer l'autorisation à ce groupe (sur le même principe que ce que l'on va faire). C'est beaucoup plus facile à maintenir puisque pour ajouter la même autorisation à un autre utilisateur, il suffira de l'ajouter dans ce groupe de sécurité. Dans le même esprit, vous ne devez pas utiliser les groupes existants dans l'Active Directory pour créer une délégation, il faut utiliser vos propres groupes.
Quant à la protection des comptes "Administrateurs", vous ne devez pas accorder d'autorisations sur l'OU qui contient ces comptes ! Sinon, on peut imaginer que ces autorisations soient exploitables pour prendre le contrôle d'un compte administrateur. Autrement dit, il faut isoler l'OU qui contient les comptes administrateurs. Par exemple, si l'on accorde la possibilité de réinitialiser le mot de passe à un groupe et que dans le périmètre de la délégation, il y a les comptes administrateurs, il devient possible de réinitialiser le mot de passe d'un compte admin puis de l'utiliser.
Enfin, il est recommandé d'auditer périodiquement les permissions déléguées au sein de votre annuaire Active Directory, afin de faire le tri si besoin, mais aussi pour voir s'il n'y a pas des autorisations indésirables.
III. Déléguer la réinitialisation des mots de passe Active Directory
Avant de commencer, je crée dans mon Active Directory le groupe de sécurité "GG-Service-Support" et j'ajoute à groupe l'utilisateur "florian". Pour information, voici les deux commandes PowerShell correspondantes :
New-ADGroup "GG-Service-Support" -Path "OU=SecuriteInfra,OU=Groupes,DC=it-connect,DC=local" -GroupScope Global Add-AdGroupMember -Identity "GG-Service-Support" -Members "florian"
Ensuite, il va falloir enchaîner les clics pour créer la délégation de contrôle, même si l'on pourrait le faire en PowerShell (mais ce n'est pas forcément ce qu'il y a de plus intuitif...).
Ouvrez la console "Utilisateurs et ordinateurs Active Directory" sur votre contrôleur de domaine ou un poste équipé des outils d'administration. On commence par effectuer un clic droit sur l'OU "Personnel", car c'est sur cette unité d'organisation que l'on veut attribuer des autorisations, puis on clique sur "Délégation de contrôle".
On clique sur "Suivant" pour passer le premier écran.
Il faut que l'on sélectionne le groupe "GG-Service-Support", car c'est à lui que l'on souhaite attribuer les droits. On clique sur le bouton "Ajouter", on recherche le groupe et on valide.
On obtient le résultat suivant, ce qui est conforme : on continue.
Désormais, il va falloir que l'on détermine les tâches à déléguer au groupe "GG-Service-Support". Pour cela, on peut piocher dans la liste des tâches courantes, qui contient de nombreuses entrées, dont :
- Créer, supprimer et gérer les comptes d'utilisateurs
- Réinitialiser les mots de passe utilisateur et forcer le changement de mot de passe à la prochaine ouverture de session
- Créer, supprimer et gérer les groupes
- Modifier l'appartenance à un groupe
- Lire toutes les informations sur l'utilisateur
- Etc.
On va plutôt créer une règle sur mesure, car il n'en existe pas qui correspond exactement à ce que l'on veut faire, donc on choisit "Créer une tâche personnalisée à déléguer" puis on poursuit.
Notre objectif étant d'agir sur des comptes utilisateurs, il faut que l'on choisisse uniquement ce type d'objets. Pour cela, on clique sur "Seulement des objets suivants dans le dossier" puis on coche la case "Objets utilisateurs".
A noter la présence de deux options intéressantes si vous souhaitez déléguer la création et la suppression d'objets (par exemple des utilisateurs) dans cette OU : "Créer les objets sélectionnés dans ce dossier" et "Supprimer les objets sélectionnés dans ce dossier". Cela ne nous concerne pas dans ce cas de figure, mais c'est bon à savoir.
Remarque : en sélectionnant les objets de type "ordinateur" et en cochant l'option "Créer les objets sélectionnés dans ce dossier", vous pouvez déléguer l'ajout de machines à votre domaine Active Directory. Cette autorisation doit être positionnée sur l'OU "Computers" de l'AD, car c'est là que sont ajoutées les machines par défaut.
Il est l'heure de déterminer quelles sont les autorisations que l'on souhaite déléguer ! Au sein de la zone "Afficher les autorisations", on coche "Spécifiques aux propriétés" en plus de "Générales" pour que la liste d'autorisations soit un peu plus fournie. Ensuite, dans la liste des autorisations, on doit rechercher et cocher "Lire lockoutTime" et "Ecrire lockoutTime" pour donner accès à la fonction de déverrouillage du compte.
Cela ne s'arrête pas là, car nous devons permettre aux membres de notre groupe la réinitialisation du mot de passe des utilisateurs, donc on doit cocher en plus "Réinitialiser le mot de passe". Au total, il y a trois autorisations à sélectionner.
Voilà, l'autorisation est prête à être mise en place : il ne reste plus qu'à cliquer sur le bouton "Terminer" !
IV. Tester la délégation de contrôle AD
Nous avons mis en place notre délégation de contrôle dans l'Active Directory, mais comment s'assurer qu’elle fonctionne ? Et bien, tout simplement en réalisant un test avec le compte "florian" puisqu'il est membre du groupe "GG-Service-Support" ! Pour cela, plusieurs méthodes sont possibles... On peut se connecter sur une machine avec le compte "florian" et ouvrir la console "Utilisateurs et ordinateurs Active Directory", ou bien utiliser PowerShell. Je vais partir sur la deuxième méthode.
Tout d'abord, on définit une variable nommée "$CredsFlorian" qui va contenir les identifiants du compte "florian" :
$CredsFlorian = Get-Credential -UserName "IT-Connect\florian" -Message "Mot de passe pour le compte florian"
Le mot de passe du compte est demandé :
Ensuite, on va réinitialiser le mot de passe de l'utilisateur "vincent.timmes" qui est dans l'OU "Personnel" en lui attribuant le mot de passe "Caen@Normandie14". Attention, j'attire votre attention sur l'importance de préciser "-Credential $CredsFlorian" afin que la commande soit exécutée avec le compte "florian" ! Sinon, cela fausse le test.
Set-ADAccountPassword "vincent.timmes" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "Caen@Normandie14" -Force) -Credential $CredsFlorian -Verbose
La commande ci-dessus doit fonctionner et retourner "COMMENTAIRES : Opération « Set-ADAccountPassword » en cours sur la cible « CN=Vincent Timmes,OU=Personnel,DC=it-connect,DC=local »." comme le mode verbeux est actif.
Notre délégation de contrôle fonctionne ! Éventuellement, vous pouvez avoir une erreur si le mot de passe ne respecte pas la politique de mots de passe de votre Active Directory.
Maintenant, si l'on essaie de créer un utilisateur nommé "florian2" dans l'OU "Personnel" toujours avec le compte "florian", on va voir que l'on obtient une erreur ! Ce qui, cette fois-ci, est normal ! 🙂
New-ADUser -Name "florian2" -Path "OU=Personnel,DC=it-connect,DC=local" -Credential $CredsFlorian
Voyez par vous-même :
V. Afficher et modifier une délégation de contrôle AD
Pour afficher les droits sur une unité d'organisation de l'Active Directory, et ainsi identifier la présence éventuelle d'une délégation, il faut activer l'affichage avancé dans la console "Utilisateurs et ordinateurs Active Directory". Pour cela, on doit cliquer sur "Affichage" puis "Fonctionnalités avancées".
Ensuite, on effectue un clic droit sur l'OU "Personnel" puis on clique sur "Propriétés".
Dans l'onglet "Sécurité", nous pouvons visualiser les droits actuels sur cette OU. Tiens, tiens, on retrouve notre groupe "GG-Service-Support", pour en savoir un peu plus, on clique sur le bouton "Avancé".
Dans la liste des autorisations, on peut voir deux lignes correspondantes à notre groupe. L'une concerne la possibilité de réinitialiser le mot de passe, l'autre n'est pas très précise, mais elle devrait correspondre à la partie verrouillage. Pour en avoir le cœur net, on double-clique sur la seconde ligne.
Le détail des autorisations s'affiche, et si l'on regarde bien, on va voir deux cases cochées "Lire lockoutTime" et "Ecrire lockoutTime" : ce qui correspond à la délégation créée précédemment.
Si l'on souhaite éditer cette délégation de contrôle, il n'y a pas d'assistant dédié pour cela, il faut agir sur les autorisations directement via l'onglet "Sécurité" de notre OU. Que ce soit pour modifier ou supprimer l'autorisation, c'est ici que ça se passe. En fait, même pour créer une nouvelle délégation de contrôle, on pourrait le faire manuellement via l'onglet "Sécurité" sans avoir recours à l'assistant.
VI. Auditer la délégation de contrôle Active Directory
Pour auditer la délégation de contrôle, on peut s'appuyer sur PowerShell, mais aussi des solutions propriétaires. Il me semble que Netwrix Auditor intègre ce genre de fonctionnalités. Pour ma part, je vais vous présenter l'outil gratuit "AD ACL Scanner" basé sur PowerShell. Il s'agit d'un outil disponible sur GitHub qui est utilisable à la fois en ligne de commande et en interface graphique, simplement en exécutant le script PowerShell.
Voici le lien vers le projet où vous pouvez télécharger la dernière version : AD ACL Scanner
Il suffit d'exécuter le script "ADACLScan.ps1" avec un compte administrateur afin d'analyser l'Active Directory. Cela va ouvrir une interface graphique : il faut commencer par établir la connexion à l'Active Directory en cliquant sur le bouton "Connect" (cela utilise le compte actuel et cible le domaine actuel).
Une fois la connexion établie, la structure de l'annuaire Active Directory s'affiche dans la zone "Nodes" en bas à gauche. Il faut cliquer sur le noeud qui sert de base pour effectuer l'analyse. Cela dépend de ce que l'on veut faire : auditer les permissions seulement sur une OU ou sur une partie un peu plus large de l'AD (par exemple une OU et ses sous-OU), voire même tout le domaine. Pour cet exemple, et comme mon annuaire n'est pas très conséquent, je vais sélectionner le domaine "DC=it-connect,DC=local".
Ensuite, la partie de droite sert à configurer les options pour l'analyse. On coche les options "Skip default permissions" et "Skip protected permissions" pour exclure les permissions natives de l'Active Directory. Cela permettra de voir plus facilement les délégations de contrôle ajoutées par un admin de l'Active Directory ou par une application.
Concernant l'option "Scan Depth", cela permet d'ajuster le périmètre de l'analyse :
- Base : seulement sur le noeud sélectionné
- One Level : le noeud sélectionné et les objets de premiers niveaux
- Subtree : le noeud sélectionné et l'ensemble des sous-objets
Enfin, on peut configurer le format de sortie du rapport. Ici, je sélectionne "HTML", mais d'autres formats sont disponibles (Excel / CSV). Ce qui donne la configuration suivante :
On clique sur "Run Scan" et puis on laisse l'outil travailler un instant, le temps de l'analyse. Quand ce sera terminé, un rapport va s'ouvrir, comme celui-ci dessous.
Le rapport peut contenir énormément de lignes en fonction de votre annuaire Active Directory et des options sélectionnées. Néanmoins, c'est bien structuré et chaque nouvel objet analysé est mis en évidence afin de créer des sortes de séparateurs dans le rapport.
On peut voir que l'OU "Personnel" est présente dans ce rapport, et nous retrouvons bien les autorisations du groupe "GG-Service-Support" ! Le petit bonus, c'est que les noms de groupe sont cliquables : si l'on clique sur un nom, une nouvelle page s'affiche afin de nous indiquer quels sont les membres du groupe. Pratique.
Si l'on veut mettre en évidence les permissions critiques, c'est-à-dire correspondantes à un haut niveau de droits, il faut cocher l'option "Show color coded criticality" de l'onglet "Assessment".
Pour tester, j'ai mis le groupe "GG-Service-Support" en contrôle total sur l'OU "Personnel" et j'ai relancé un scan. Voici le résultat avec ce fameux code couleur :
L'outil "AD ACL Scanner" est fonctionnel et assez puissant : il dispose de nombreuses options pour auditer les permissions liées aux objets de l'Active Directory donc je vous encourage à l'ajouter à votre trousse à outils sysadmin et à l'explorer ! Dans le cas où vous effectuez des exports CSV, l'outil peut vous aider à les comparer grâce aux fonctions de l'onglet "Compare".
Désormais, vous êtes en mesure de configurer la délégation de contrôle au sein de votre annuaire Active Directory !
Bonjour,
Je veux bien d’autres exercices corrigés avec vsphere, pfsense,Esxi,serveur 2019,pare feu,réseaux, calcul réseaux, client léger, Linux, commandes linux et d’autres s’il vous plaît. Je prépare un titre professionnel de technicien supérieur système et réseaux.
Cordialement,
Hello,
Petite note sur la délégation directement à des groupes d’équipe (ici avec un groupe global).
Il est judicieux de déléguer les ACLs sur des groupes de domaine local, qui détient dans sa nomenclature le type de droit délégué. On ajoutera le groupe d’équipe ensuite à ce groupe de délégation. (AGDLP etc…)
Je suis vraiment pas fan de porter les ACLs directement sur des groupes d’équipe (groupe global qui plus est) au même titre que directement sur un compte utilisateur (que tu notifies d’ailleurs).
C’est véritablement compliqué sur de grosses infras d’auditer tout ça et surtout si l’on doit donner le même droit à des services différents, il faut remodifier les ACLs etc … ça s’empile et ça ne fait pas propre du tout.
Les avantages à passer par un Domain Local pour porter la délégation :
– Facilité pour déléguer le type de droits à plusieurs équipes – surtout dans un contexte avec Multiple Forest/Domain (notamment avec des forets d’administration)
– Facilité pour auditer les droits donnés sans passer par scan d’ACLs (et cependant c’est top d’indiquer cette méthode btw, qui reste quand même une tache à faire dans tous les cas)
L’inconvénient :
– Sécuriser les groupes de délégation dans une OU, où seuls certains comptes peuvent modifier le membership
– Augmentation du TokenSize Kerberos
2ème petite note : les groupes « existants » AD que tu mentionnes, certains sont utiles pour les comptes à haut privilège pour certaines taches. (Builtin\Administrators , Domain Admins, Enterprise Admins, Schema Admins)
Des précisions auraient été les bienvenues sur les impacts par rapport à l’utilisation des groupes Builtin, type « Account Operators » par exemple : le adminsdholder qui casse l’héritage des droits des comptes utilisateurs y figurant, ce qui résulte que le compte utilisateur n’est plus administrable par un de ses collègues par ex (et vice versa d’ailleurs) – avec la notion du AdminCount positionné sur le compte.
Ce qui renforce l’intéret d’utiliser une délégation « custom ».
Bonne journée 😉
Maz’
Bonjour,
merci pour toutes ces infos.
J’ai tout de même une question :
je viens de faire des tests de délégations, je me suis basé sur une OU qui contient des sous ou avec des users dedans, je pensais pouvoir manager ma délégation par héritage mais il semblerait que si l on souhaite faire des délégations fines (créer une tache personnalisée) comme tu le montres il faut avoir la présence des objets en question directement sous l’OU et pas dans une sous OU (les options propres a ces objets n’apparaissent pas dans les choix). Si quelqu’un peut me confirmer ou me dire s il y a une autre méthode?
Merci
Bonne journée
Bonjour, aurais-t’il une commande sur powershell afin de faire la délégations ?
Cordialement,
Bonjour,
Pour un utilitaire comme Veeam, savez-vous le type d’objet de délégation qu’il faut donner sur le compte de service (en évitant de mettre le compte admin du domain bien sur)
De mémoire je pense déjà au groupe « Ordinateur » mais concernant le droit de sauvegarde ..?
Cordialement,
Bonjour,
Je tente d’effectuer une délagation de contrôle pour un utilisateur mais j’ai systématiquement ce message d’erreur (voir image via le lien):
https://ibb.co/b30SV9R
Windows ne peut pas effectuer le changement de mot de passe pour XXX car: Accès refusé
J’ai créé une console mmc que j’ai mis à disposition de l’utilisateur que je souhaite autoriser à effectuer un reset des mots de passe, j’ai bien créé la délégation pour cet utilisateur mais j’ai systématiquement cette erreur et je n’arrive pas à voir pourquoi.
Au niveau serveur, j’ai créé une OU dans laquelle est présent ce user ainsi que tout les autres pour lesquels je souhaite qu’il puisse réinitialiser le mot de passe
Quelqu’un pourrait-il m’aider pour solder ce problème?
Merci