Vous venez de créer un « junior admin », mais le compte parvient à modifier des objets dans ADUC sans délégation apparente. Ce guide explique d’où viennent ces droits, comment les prouver avec l’onglet Accès effectif, et comment corriger proprement sans perturber la production.
Vue d’ensemble du problème
Dans Active Directory, les droits ne proviennent pas d’un seul endroit. Un utilisateur cumule :
- ses permissions directes ;
- les droits hérités des conteneurs parents (domaine, OU) ;
- les privilèges hérités de tous ses groupes (y compris imbriqués) ;
- les droits « étendus » (extended rights) et les « validated writes » propres à certains types d’objets ;
- éventuellement des effets du mécanisme AdminSDHolder/SDProp si des groupes protégés sont en jeu.
Résultat : un compte « standard » peut, en pratique, disposer de droits d’écriture sur des utilisateurs, groupes, ordinateurs ou OU sans délégation explicite récente — parce qu’un ancien assistant de délégation, un groupe intégré trop large, ou une ACE héritée expose l’environnement.
Ce que l’onglet Sécurité > Avancé > Accès effectif vous révèle (et ne révèle pas)
L’onglet Accès effectif calcule les permissions nettes (Allow – Deny) pour un principal donné sur un objet. Utilisez-le comme boussole : il pointe la zone problématique et accélère l’enquête. Toutefois, validez toujours vos conclusions par un examen de la DACL (dsacls / Get-Acl) et un test contrôlé (ex. tentative de modification dans un environnement de préproduction).
Diagnostic pas-à-pas (méthode éprouvée)
Identifier les droits réels du compte
- Dans ADUC, ouvrez Propriétés de l’objet cible (ou du domaine/OU) → Sécurité → Avancé → Accès effectif.
- Sélectionnez l’utilisateur problématique. Recherchez tout droit inattendu : GenericWrite, Write, Modify, Full Control, WriteDacl, WriteOwner ou droits étendus (Reset Password, Add/Remove self as member, etc.).
- Répétez l’opération sur le parent direct (OU) et sur le domaine racine. Dans les environnements compromis, la source se situe souvent au-dessus.
Vérifier l’appartenance aux groupes (y compris l’imbrication)
Un grand classique : le compte appartient — parfois par héritage — à un groupe ayant reçu une délégation ancienne. Dressez l’inventaire complet :
# PowerShell (RSAT)
Get-ADPrincipalGroupMembership -Identity junior.admin |
Select-Object Name, GroupScope, DistinguishedName
# CMD
whoami /groups
net user junior.admin /domain Inspectez particulièrement la présence (même indirecte) de groupes intégrés : Account Operators, Server Operators, Backup Operators, Print Operators, DNSAdmins, ainsi que tout groupe « métiers » ayant reçu des droits sur des OU.
Contrôler l’héritage des autorisations
- Dans Sécurité > Avancé, examinez la colonne Hérité de (Inherited From).
- Si des ACE dangereuses proviennent d’un parent, corrigez au niveau parent (domaine/OU) plutôt que de bricoler chaque enfant.
- N’utilisez Désactiver l’héritage que si vous maîtrisez l’impact ; préférez la correction à la source avec une délégation ciblée.
Inspecter les délégations antérieures
Dans ADUC, clic droit sur le domaine/OU → Délégation du contrôle. Ce wizard a peut‑être accordé « Créer, supprimer et gérer des comptes d’utilisateurs » à un groupe dont junior.admin est membre. S’il est trop large, remplacez‑le par une délégation plus fine (droits explicites sur un sous-ensemble d’objets, portée limitée à une OU).
Activer l’audit et retracer
Activez l’audit de la Gestion des comptes et de l’Accès aux services d’annuaire (via GPO ou stratégie locale avancée). Les journaux révéleront qui a modifié quoi, où et quand.
| Événement | Signification | Quand le rechercher |
|---|---|---|
| 4720 / 4726 | Création / suppression d’utilisateur | Apparition/Disparition inattendue de comptes |
| 4738 | Modification d’utilisateur | Attributs sensibles changés (memberOf, UAC…) |
| 4728/4729, 4732/4733, 4756/4757 | Ajout/Retrait d’un membre dans un groupe (global/local/universel) | Escalade via appartenance à des groupes privilégiés |
| 5136 / 5137 / 5139 | Changement / Création / Déplacement d’objet AD | Modification structurelle (OU, groupes, GPO links) |
Où se cachent les droits « fantômes » ? (analyse approfondie)
Groupes intégrés à surveiller
| Groupe | Impact courant | Recommandation |
|---|---|---|
| Account Operators | Peut gérer de nombreux comptes et groupes non‑administrateurs au niveau du domaine. | Évitez d’y placer les comptes « junior ». Déléguez plutôt sur une OU spécifique. |
| Server Operators | Puissance élevée sur les DC (services, partage…). Peut conduire à l’accès aux secrets AD. | Usage exceptionnel uniquement. Privilégiez JIT/JEA ou PAM. |
| Backup Operators | Peut lire des données sensibles (sauvegardes), vecteur d’exfiltration. | Limiter et auditer. Aucun lien avec la gestion d’utilisateurs. |
| DNSAdmins | Droits sur objets DNS AD‑intégrés. Mal maîtrisé, peut conduire à une élévation. | N’accorder qu’aux opérateurs DNS. Revoir périodiquement. |
ACE trop larges sur domaine/OU
Les entrées d’ACE (Access Control Entry) de type Allow appliquées à Everyone, Authenticated Users ou Domain Users sont des « répartiteurs » de privilèges. Quelques exemples à traquer :
| ACE dangereuse | Symptômes | Où regarder |
|---|---|---|
| GenericWrite/GenericAll sur Descendant User objects | Tout membre du domaine peut changer des attributs d’utilisateurs | Domaine racine ou OU « utilisateurs » |
WriteProperty sur l’attribut member des Descendant Group objects | Ajout/suppression libre de membres aux groupes | OU des groupes métiers |
| WriteDacl / WriteOwner sur des conteneurs | Possibilité d’auto‑octroi de Full Control (escalade rapide) | N’importe quel parent d’objets sensibles |
AdminSDHolder / SDProp
Si un utilisateur devient (même brièvement) membre d’un groupe protégé (ex. Domain Admins), son attribut adminCount=1 et l’héritage d’ACL peut être désactivé. À l’inverse, des ACE trop permissives appliquées à AdminSDHolder se propageront ensuite aux objets protégés. Vérifiez :
Get-ADUser -Identity junior.admin -Properties adminCount, MemberOf |
Select-Object SamAccountName, adminCount, MemberOf
# Contrôler la DACL d'AdminSDHolder
$dn = (Get-ADDomain).DistinguishedName
dsacls "CN=AdminSDHolder,CN=System,$dn" Droits étendus et validated writes
Certains droits ne se voient pas en une ligne « Write ». Par exemple : Reset password, Validated write to DNS host name (ordinateurs), Change Password (self‑service). Dans l’onglet Accès effectif, parcourez la liste des Extended Rights et vérifiez ceux accordés via l’héritage.
Scripts et commandes pour aller vite
Lister les ACL efficaces sur une OU et repérer les ACE larges
# Requiert le module ActiveDirectory (RSAT)
$searchBase = "OU=Paris,DC=contoso,DC=com"
$dangerousPrincipals = @("Everyone","Authenticated Users","Domain Users")
Get-ADOrganizationalUnit -LDAPFilter "(ou=*)" -SearchBase $searchBase -SearchScope Subtree |
ForEach-Object {
$ou = $*.DistinguishedName
$acl = Get-Acl "AD:$ou"
$acl.Access | Where-Object {
$dangerousPrincipals -contains $*.IdentityReference.Value -and
(
$*.ActiveDirectoryRights -match "GenericAll|GenericWrite|WriteProperty|WriteDacl|WriteOwner|ExtendedRight"
) -and
($*.IsInherited -eq $true -or $_.InheritanceType -ne "None")
} | Select-Object @{n="OU";e={$ou}},
IdentityReference, ActiveDirectoryRights, InheritanceType, ObjectType, IsInherited
} | Format-Table -Auto DSACLS : voir la DACL du domaine et des OU
REM DACL du domaine
for /f "tokens=2 delims=: " %d in ('dsquery * -scope base -filter "(objectclass=domainDNS)" -attr distinguishedName') do @dsacls "%d"
REM DACL d'une OU
dsacls "OU=Paris,DC=contoso,DC=com" Inventaire des groupes (imbriqués)
# Vue rapide des groupes imbriqués
Get-ADPrincipalGroupMembership -Identity junior.admin |
Sort-Object Name |
Format-Table Name, GroupScope, DistinguishedName -Auto
# Option : afficher les groupes hérités par transitivité
function Get-NestedGroups {
param([string]$Identity)
$seen = @{}
$queue = New-Object System.Collections.Generic.Queue[Object]
$queue.Enqueue($Identity)
while ($queue.Count -gt 0) {
$obj = $queue.Dequeue()
if ($seen.ContainsKey($obj)) { continue }
$seen[$obj] = $true
Get-ADPrincipalGroupMembership -Identity $obj | ForEach-Object {
$_
$queue.Enqueue($_.DistinguishedName)
}
}
}
Get-NestedGroups -Identity "junior.admin" | Select Name, GroupScope Ce que Accès effectif ne dit pas toujours explicitement
- Les Deny ciblés : un Deny spécifique (This object only) peut neutraliser un Allow hérité sur le même objet, mais pas sur ses descendants, ce qui rend la lecture « à l’œil » trompeuse si l’on ne remonte pas les parents.
- Les changements de propriétaire : disposer de WriteOwner permet d’usurper la propriété et d’étendre ensuite ses droits (WriteDacl), ce qui n’apparaît pas comme « Full Control » immédiat.
- Les validated writes : ils autorisent certaines modifications d’attributs si la valeur proposée est « valide » (ex. SPN), sans apparaître comme un WriteProperty générique.
Plan de remédiation (pragmatique et durable)
- Bloquez l’hémorragie : retirez temporairement l’utilisateur des groupes identifiés comme à risque (en documentant). Si une ACE dangereuse est appliquée à Everyone/Authenticated Users, corrigez au parent (domaine/OU) et forcez la réplication.
- Appliquez AGDLP pour la délégation :
- Accounts → Global groups → Domain Local groups → Permissions.
- Exemple :
GG-Helpdesk-UserMgmtmembre deDL-OU-Paris-UserAdmins; déléguez Créer/Supprimer/Gérer les comptes d’utilisateurs sur OU=Paris uniquement.
- Spécifiez au maximum : préférez les ACE object-specific (ex. Descendant User objects) plutôt que this object and all descendants indifférenciés.
- Interdisez les ACE « grand public » : bannissez GenericWrite/GenericAll pour Everyone ou Authenticated Users sur des conteneurs de production.
- Réduisez les groupes intégrés : sortez les comptes « opérateurs » de Account/Server Operators, remplacez par des groupes métiers délégués à des OU.
- Établissez un journal de délégation : conservez une matrice Qui / Où / Quoi signée par les propriétaires d’applications. Revoyez‑la à chaque cycle de changements.
- Mettez en place JIT/JEA/PIM : accès à la demande, expirations automatiques, approbations.
Tableau de contrôle rapide (checklist)
| Vérification | Pourquoi c’est utile | Outil/Commande |
|---|---|---|
| Accès effectif sur l’objet et ses parents | Voir les permissions cumulées (directes + héritées) | ADUC → Sécurité → Avancé → Accès effectif |
| Member Of + groupes imbriqués | Détecter un héritage via un groupe privilégié | whoami /groups, net user <compte> /domain, Get-ADPrincipalGroupMembership |
| Analyse des ACL (domaine/OU) | Repérer des ACE « Everyone/Authenticated Users » trop permissives | dsacls, Get-Acl (RSAT) |
| Délégation du contrôle | Identifier un ancien wizard trop large | ADUC → Clic droit → Délégation du contrôle |
| Audit AD | Retracer qui a fait quoi (événements 4720, 4726, 5136…) | Stratégie de sécurité avancée / GPMC |
| AdminSDHolder | Écarter un héritage « spécial » pour objets protégés | Get-ADUser -Properties adminCount, dsacls sur AdminSDHolder |
Exemples concrets et anti‑patterns
Exemple 1 : membre d’un groupe « Opérateurs »
Symptôme : l’utilisateur peut réinitialiser des mots de passe dans une OU d’utilisateurs métiers. Cause : appartenance (directe ou indirecte) à Account Operators. Fix : retirer l’appartenance, créer un groupe global GG-ServiceDesk, le placer dans un groupe local de domaine DL-OU-Lyon-UserMgmt, déléguer uniquement sur OU=Lyon.
Exemple 2 : ACE héritée « GenericAll » pour Authenticated Users
Symptôme : tout utilisateur peut modifier n’importe quel groupe d’une OU. Cause : une ACE héritée au niveau OU=Groupes accorde GenericAll sur Descendant group objects à Authenticated Users. Fix : supprimer l’ACE, recréer des ACE ciblées vers DL-OU-GroupAdmins avec WriteProperty: member.
Exemple 3 : WriteDacl sur une OU
Symptôme : « junior.admin » parvient à s’octroyer des droits étendus partout dans une OU. Cause : une ACE « WriteDacl » héritée pour Domain Users sur l’OU. Fix : retirer WriteDacl, assainir la DACL, journaliser l’opération.
FAQ ciblée
RSAT ajoute‑t‑il des droits ? Non. RSAT n’apporte que des consoles/outils. Les ACL AD déterminent les permissions.
Pourquoi un Deny ne « résout » pas tout ? Les Deny sont spécifiques : mal positionnés, ils bloquent des scénarios légitimes sans empêcher une escalade ailleurs. Évitez les Deny « globaux ». Préférez des Allow précis.
Différence entre Change Password et Reset Password ? Change concerne le titulaire du compte (ou un flux self‑service) et exige d’authentifier l’ancien secret ; Reset est un droit étendu d’administration qui remplace le secret sans l’ancien mot de passe.
Pourquoi Accès effectif diffère parfois de la réalité ? L’interface simplifie la résolution. Elle peut masquer des combinaisons complexes (validated writes, effets de propriété). D’où l’importance de confronter avec dsacls et un test contrôlé.
Procédure recommandée de bout en bout
- Inventaire : relevez les groupes du compte, adminCount, et collectez les événements d’audit des 48–72 h.
- Localisation : identifiez l’objet (ou la famille d’objets) que l’utilisateur parvient à modifier.
- Observation : calculez Accès effectif sur l’objet, son parent direct, le domaine.
- Preuve : exportez la DACL (
dsacls) avant/après. Constituez un dossier de changement. - Correction : supprimez ACE « grand public », resserrez les délégations, sortez des groupes intégrés.
- Prévention : formalisez AGDLP, mettez en place des délégations modèles par OU, activez JIT/PIM.
- Surveillance : alertes SIEM sur les événements 4728/4729, 4732/4733, 5136, 4720/4726.
Annexe : droits AD utiles à connaître
| Droit | Effet | Remarques |
|---|---|---|
| GenericRead / GenericWrite | Lecture/écriture large sur l’objet | À proscrire pour des identités génériques |
| WriteProperty | Écriture d’attributs | Peut être restreint à un attribut (ex. member) |
| ExtendedRight | Droits « spéciaux » (reset password, add/remove self…) | Souvent à l’origine d’« anomalies » perçues |
| WriteDacl / WriteOwner | Changer les ACL / propriétaire | Danger critique sur des conteneurs |
| CreateChild / DeleteChild | Créer/supprimer des objets enfants | Privilégiez une portée object‑specific |
Conseils d’exploitation au quotidien
- Étiquetez vos OU (par périmètre métier/géographique) et déléguez par OU, jamais au niveau du domaine.
- Figez une convention de nommage :
GG-<Périmètre>-<Fonction>(global),DL-<Périmètre>-<Rôle>(domain local),AG-<Nom>(accounts). - Évitez les groupes universels pour la délégation standard si vous avez plusieurs domaines/sites : préférez global + domain local.
- Nettoyez régulièrement les ACE orphelines (identités supprimées, SIDs inconnus) et les anciennes délégations de projets.
- Testez en préproduction toute modification d’ACL (script de validation, compte test, capture des événements).
Conclusion
Si un « utilisateur standard » modifie des objets dans ADUC, ce n’est presque jamais un bug : c’est la conséquence d’une délégation héritée, d’un groupe intégré trop permissif ou d’une ACE mal calibrée. La combinaison Accès effectif → DACL → Groupes imbriqués permet d’isoler la source en quelques minutes. Corrigez à la racine (OU/domaine), appliquez AGDLP, auditez, et verrouillez durablement vos délégations.
Résumé opérationnel (à garder sous la main)
- Identifier les droits réels : ADUC → Sécurité > Avancé > Accès effectif sur l’objet, l’OU parente et le domaine.
- Lister les groupes :
whoami /groups,net user <compte> /domain,Get-ADPrincipalGroupMembership. - Contrôler l’héritage : repérer l’Inherited From des ACE, corriger au parent.
- Vérifier la délégation : supprimer les délégations « globales », reconstruire des ACE spécifiques.
- Auditer : activer la journalisation (4720/4726/4738/4728–4757/5136–5139) et surveiller via SIEM.
Fiches pratiques
Commandes utiles
REM Groupes de l’utilisateur (CMD)
whoami /groups
net user junior.admin /domain
REM Énumérer les membres des Account Operators
net group "Account Operators" /domain
REM Lister la DACL du domaine
for /f "tokens=2 delims=: " %d in ('dsquery * -scope base -filter "(objectclass=domainDNS)" -attr distinguishedName') do @dsacls "%d" # Groupes imbriqués (PowerShell)
Get-ADPrincipalGroupMembership -Identity junior.admin | Sort Name
# DACL d'une OU (PowerShell via provider AD:)
Get-Acl "AD:OU=Paris,DC=contoso,DC=com" | Select -ExpandProperty Access
# Rechercher les ACE trop larges (exemple)
$dangerous = "Everyone","Authenticated Users","Domain Users"
Get-ADOrganizationalUnit -LDAPFilter "(ou=*)" -SearchBase "DC=contoso,DC=com" | %{
$acl = Get-Acl "AD:$($_.DistinguishedName)"
$acl.Access | ?{ $dangerous -contains $_.IdentityReference.Value -and
$_.ActiveDirectoryRights -match "GenericAll|GenericWrite|WriteProperty|WriteDacl|WriteOwner" }
}
Bonnes pratiques de délégation
- Créez un groupe global par équipe (Service Desk, Identités Régionales…).
- Créez un groupe local de domaine par OU cible (ex.
DL-OU-Paris-UserAdmins). - Déléguez des droits object‑specific (ex. utilisateurs seulement) au niveau de l’OU unique concernée.
- Ajoutez les groupes globaux dans les groupes locaux. Ajoutez des comptes dans les groupes globaux uniquement.
- Documentez chaque délégation (propriétaire, justification, durée de vie, date de revue).
Mini‑mémo : points clés
- RSAT n’ajoute aucun droit ; seules les ACL AD comptent.
- Les groupes intégrés Account Operators et Server Operators confèrent déjà des droits d’édition sur certains objets.
- Toujours vérifier Accès effectif sur l’objet et sur ses parents (OU/domaine).
- L’héritage et les groupes imbriqués sont la source la plus fréquente des « droits magiques ».
- Évitez GenericWrite/GenericAll pour des identités génériques. Préférez des délégations fines.