Vous avez segmenté votre Active Directory en Tier 0, 1 et 2 : le plus dur est fait. Mais si votre help desk travaille encore avec un compte d’administration partagé, votre modèle de tiering est déjà contourné.
C’est le paradoxe de nombreux projets de sécurisation AD : l’architecture est saine, mais la délégation opérationnelle reste celle d’avant. Trop de droits, pour trop de monde, sans traçabilité nominative. Ce n’est la faute de personne : le découpage en niveaux est porté par l’infrastructure ou le RSSI, le quotidien du support s’organise de son côté. Deux mondes, deux budgets, et un sujet qui tombe entre les deux.
Architecture saine, délégation d’avant
D’un côté, ce qui a été fait : segmentation Tier 0, Tier 1, Tier 2, postes d’administration dédiés, séparation des comptes d’administration, durcissement des contrôleurs de domaine. De l’autre, ce qui n’a pas bougé : des comptes d’administration partagés au help desk, des droits AD accordés « pour que ça marche », aucune approbation sur les opérations sensibles, une journalisation qui ne nomme personne.
Le tiering répond à une question : qui a le droit d’ouvrir une session, et où. Il laisse ouverte une autre question : qui a le droit de modifier quoi. Un technicien de support a reçu, il y a trois ans, un droit de réinitialisation de mot de passe sur une OU. Depuis, des comptes à privilèges se sont retrouvés dans cette OU. Il peut désormais réinitialiser le mot de passe d’un compte Tier 0 depuis son poste Tier 2, sans jamais ouvrir de session Tier 0. Aucune règle du modèle n’a été violée, aucun contrôle technique ne lève d’alerte : la frontière n’a pas été franchie par une connexion, mais par un droit.
- Le mot de passe circule : transmis à l’arrivée d’un technicien, jamais changé à son départ.
- Les droits par défaut sont trop larges : un technicien qui doit créer des utilisateurs peut aussi modifier des groupes, des GPO ou des comptes de service.
- Des comptes admin fantômes subsistent : membres de Domain Admins hérités d’anciens projets, comptes de prestataires jamais désactivés.
- Aucune revue périodique : les délégations accordées en urgence sur incident ne sont jamais réévaluées.
Si trois de ces quatre symptômes sont présents chez vous, le tiering ne protège plus grand-chose. Le mode opératoire est connu : les campagnes attribuées au groupe Scattered Spider, chez MGM Resorts en 2023 puis chez Marks & Spencer en 2025, reposent sur l’ingénierie sociale du support pour obtenir une réinitialisation de mot de passe ou de MFA sur un compte ciblé. Un help desk qui opère avec un compte partagé aux droits larges n’a ni le moyen de refuser, ni le moyen de prouver ce qui a été fait.
Le replay du webinar
Jérémy Selin, de LAZAR SOFT, explique pourquoi la délégation native d’Active Directory ne suffit plus après un projet de tiering, puis montre dans ADManager Plus comment remplacer les comptes partagés par une délégation granulaire, encadrée et tracée.
Pourquoi la délégation native ne suffit pas
La délégation native, par ACL et depuis la console Utilisateurs et ordinateurs Active Directory, n’est pas mauvaise. Elle n’a simplement pas été conçue pour ce qu’on lui demande après un tiering. Elle sait dire « tu as le droit d’écrire sur cet objet ». Elle ne sait pas dire « tu peux créer un utilisateur selon le modèle standard du site de Montpellier, sans pouvoir le placer dans un groupe sensible ».
- Granularité : des droits par objet et par OU, là où il faudrait raisonner par action métier et par attribut.
- Contrôle avant exécution : aucun, le droit accordé s’exerce immédiatement.
- Imputabilité : le journal enregistre le compte utilisé, partagé ou non, pas la personne.
- Lisibilité : ACL dispersées, héritages coupés, groupes imbriqués. Qui peut réinitialiser le mot de passe de votre directeur financier ? Soit tout le support, soit personne ne sait le dire.
- Réversibilité : le retrait est manuel et repose sur la mémoire de celui qui a accordé le droit.
Le modèle cible tient en deux règles : zéro compte partagé, zéro droit AD accordé au technicien. Le technicien ne détient plus de permission dans l’annuaire. Il détient un rôle dans un outil de délégation, qui exécute l’action à sa place après contrôle, dans son périmètre, sous son identité nominative. Le test est simple : depuis le poste d’un technicien du support, ouvrez la console AD et tentez de modifier un objet. Si cela fonctionne, le chantier reste ouvert.
Le privilège ne disparaît pas, il se déplace. Dispersé hier entre plusieurs techniciens, il se concentre dans le compte de service d’ADManager Plus, traité comme un actif Tier 0 : mot de passe fort en coffre, rotation documentée, aucun usage interactif, surveillance dédiée. Reste la moitié du travail qu’on oublie le plus souvent : retirer aux techniciens les ACL déléguées et leurs appartenances aux groupes d’administration. Leur poste redevient alors un poste Tier 2 ordinaire. Et les mêmes rôles s’appliquent à Active Directory, Entra ID, Microsoft 365 et Exchange.
Les quatre piliers, démontrés dans ADManager Plus
1. Délégation granulaire : le périmètre avant le droit
À 20:52 dans le replay
Chaque rôle se construit en répondant à trois questions, dans cet ordre : qui, un technicien nommé et jamais un compte partagé ; quoi, une liste d’actions ; où, une OU, un groupe, un site ou un attribut de filtrage. Les rôles se dessinent à partir des motifs de tickets les plus fréquents, pas à partir de l’organigramme. Exemple présenté : un rôle Support niveau 1 pour le site de Montpellier autorisé à réinitialiser un mot de passe, déverrouiller un compte et créer un utilisateur via le modèle « Standard », mais pas à modifier un groupe d’administration, agir hors de son OU ou toucher à un compte de service ou une GPO.
Dans la démonstration, le rôle de réinitialisation impose un mot de passe généré automatiquement et son changement à la prochaine connexion. Les délégations n’ont d’effet que dans l’outil : les privilèges réels du technicien dans Active Directory restent inchangés.
Bon à savoir. Une action interdite n’affiche pas de message d’erreur : elle n’apparaît tout simplement pas à l’écran du technicien. Et les modèles de création garantissent des comptes homogènes, avec les bons attributs : un gain de qualité, pas seulement de sécurité.
2. Workflows d’approbation : le contrôle avant l’exécution
À 27:03 dans le replay
Certaines opérations ne doivent pas dépendre du jugement d’une seule personne, un vendredi à 17 h. Le circuit présenté enchaîne une demande soumise par le technicien, une revue technique par le niveau 2, une validation métier ou RSSI, puis l’application automatique dans l’annuaire. Dans la démonstration, un workflow de réinitialisation de mot de passe est rattaché à une règle d’affectation, qui peut cibler des OU précises.
À soumettre à approbation : l’ajout à un groupe sensible ou d’administration, la création d’un compte à privilèges ou de service, la réactivation d’un compte désactivé. À laisser en exécution directe : le déverrouillage, la réinitialisation standard, la mise à jour d’attributs non sensibles.
La règle de conception. Approuver l’exception, pas le quotidien. Réinitialiser le mot de passe d’un utilisateur courant n’a pas le même impact que celui du directeur financier.
3. Traçabilité nominative : la preuve d’audit
À 30:55 dans le replay
Une entrée de journal exploitable contient l’identité du technicien et non celle du compte de service, l’action, l’objet cible et les attributs modifiés, l’horodatage et le résultat, le workflow et l’approbateur associés. Les rapports d’audit d’ADManager Plus retracent ce que chaque technicien a fait sur les utilisateurs, les mots de passe, les groupes et les ordinateurs. Ils s’exportent et se planifient.
Deux usages en découlent. En interne, instruire un incident : qui a modifié cet objet, et sur quelle demande. En externe, fournir la preuve à l’auditeur sans reconstitution manuelle. Côté référentiels, l’article 21 de NIS2 inclut les politiques de contrôle d’accès et la gestion des actifs ; l’ISO/IEC 27001 couvre le contrôle d’accès (5.15), les droits d’accès (5.18), les droits d’accès privilégiés (8.2) et la journalisation (8.15).
À garder en tête. Aucun outil ne rend conforme : il produit la preuve que vous appliquez ce que vous avez écrit. Et les deux référentiels demandent de revoir les droits, pas seulement de les attribuer.
4. Détecter les droits excessifs et les comptes fantômes
À 34:37 dans le replay
Quatre familles de rapports, souvent le premier livrable d’un projet : les membres des groupes d’administration (Domain Admins, Enterprise Admins, Account Operators, Schema Admins) ; les comptes à privilèges inactifs ; les comptes à configuration à risque, comme un mot de passe sans expiration, une délégation non contrainte ou un SPN exposé ; les délégations hors standard, avec des ACL hors modèle, des héritages rompus ou des droits directs sur les OU.
La différence avec un script d’audit maison tient à ce qui suit : des actions correctives en masse depuis le rapport, avec une trace, et des rapports planifiés envoyés au RSSI. Le constat ponctuel devient un processus, avec une campagne de revue trimestrielle des droits et un nettoyage automatisé des comptes inactifs.
Le bon calcul. Un droit excessif découvert par l’auditeur coûte toujours plus cher qu’un droit excessif découvert par un rapport planifié.
Une trajectoire en quatre jalons
De l’état des lieux au verrouillage
- Semaines 1 et 2, cartographier : inventaire des comptes d’administration partagés, des ACL déléguées et des motifs de demande.
- Semaines 3 et 4, modéliser : définition des rôles par périmètre et des opérations soumises à approbation.
- Semaines 5 à 8, basculer : mise en service pour le support niveau 1, puis retrait progressif des droits AD natifs.
- Semaine 9 et suivantes, verrouiller : suppression des comptes partagés, rapports périodiques, revue trimestrielle formalisée.
Le jalon 3 est le seul qui compte vraiment : tant que les droits AD natifs ne sont pas retirés, les deux modèles coexistent, et le plus permissif l’emporte.
Trois choses à retenir
Le tiering isole, la délégation autorise. Les deux sont nécessaires, un seul des deux ne protège pas. Un compte partagé n’est pas un compte : sans identité nominative, il n’y a ni imputabilité, ni preuve, ni révocation. Commencez par mesurer : les rapports de droits excessifs suffisent à cadrer le projet.
Pour passer à l’action, LAZAR SOFT propose un atelier de cadrage de 30 minutes à distance, une preuve de concept ADManager Plus sur un périmètre défini, et un rapport d’écart sur vos droits d’administration.
LAZAR SOFT
Qui peut vraiment réinitialiser le mot de passe de votre directeur financier ?
Nos équipes avant-vente répondent aux questions de mise en oeuvre sur l’ensemble du catalogue ManageEngine.