DSACLS : déléguer « Generate Resultant Set of Policy (Logging) » à un groupe Active Directory (guide complet)

Comment déléguer correctement le droit étendu « Generate Resultant Set of Policy (Logging) » à un groupe Active Directory avec DSACLS, et résoudre l’état « grisé » dans ADUC ? Ce guide détaille la méthode, les commandes et le dépannage.

Sommaire

Vue d’ensemble

Dans de nombreux environnements, on souhaite autoriser une équipe (par exemple le support de niveau 2) à exécuter RSoP‑Logging sur un périmètre d’ordinateurs sans leur attribuer les droits d’administrateur local. La voie la plus précise consiste à déléguer le droit étendu Active Directory Generate Resultant Set of Policy (Logging) sur une OU, via la ligne de commande DSACLS.

Problème récurrent : la commande fonctionne pour un utilisateur individuel, mais « l’option » RSoP demeure grisée pour les membres d’un groupe, alors même que l’ACE correspondante apparaît dans l’ACL. Ce comportement s’explique par un ensemble de facteurs : réplication AD, jetons Kerberos mis en cache, portée et type du groupe, héritage des ACE, et limites de l’interface ADUC.

Résumé des causes et remèdes

Problème identifiéExplicationCorrectifs possibles
Propagation des ACLLes ACE ajoutées par DSACLS se répliquent comme tout objet AD. Dans un domaine multisite, la réplication et le recalcul des jetons prennent du temps.Déclencher la réplication : repadmin /syncall. Laisser le temps aux DC distants, puis vérifier à nouveau.
Cache d’appartenance aux groupesLe SID du groupe vit dans le jeton de sécurité. Tant qu’un nouveau jeton n’est pas émis, les nouveaux droits n’apparaissent pas.Déconnexion/reconnexion, ou klist purge, voire fermeture/reconnexion de session distante (RDP).
Type et portée du groupeUn distribution group n’a pas de SID. Un groupe domain local n’est valable que pour des ressources du domaine où il réside. L’imbrication non appropriée peut bloquer la prise en compte.Utiliser un security group global ou universel pour couvrir plusieurs domaines/forêts et éviter les surprises d’imbrication.
Héritage et ciblageLe droit doit effectivement s’appliquer aux objets ordinateur ciblés. Un ACE au niveau de l’OU sans ciblage « computer » peut ne pas produire l’effet attendu.Limiter l’ACE aux descendants de type computer dans DSACLS (voir commandes ci‑dessous). En option, utiliser /T pour pousser explicitement si l’héritage est bridé.
Limitation de l’interface ADUCADUC ne rafraîchit pas toujours l’état de la commande « Resultant Set of Policy ».Fermer/ré‑ouvrir ADUC, ou lancer la console depuis un autre poste doté des RSAT.

Ce que fait exactement ce droit étendu

Le droit Generate Resultant Set of Policy (Logging) est un control access right (extended right) stocké dans la partition de configuration d’Active Directory. Lorsqu’il est accordé sur un objet computer (ou sur une OU avec application aux objets computer descendants), il autorise la collecte des données RSoP Logging sur le poste cible via WMI/DCOM, sans conférer d’autres privilèges.

Deux modes existent :

  • Logging : collecte de l’état réel des GPO appliquées aux objets (ce qui nous intéresse ici).
  • Planning : simulation de l’application des GPO (droit distinct, à ne pas confondre).

Dans GPMC (Group Policy Management), ce droit est exploité par l’assistant Group Policy Results. En ligne de commande, on valide l’accès en ciblant la machine avec gpresult ou la cmdlet PowerShell Get-GPResultantSetOfPolicy.

Préparatifs : informations à réunir

  1. Groupe cible : créer (ou identifier) un groupe de sécurité, idéalement global (CONTOSO\Helpdesk‑RSOP), et y ajouter les comptes concernés.
  2. DN de l’OU : relever le distinguishedName de l’OU contenant les ordinateurs visés (ex. OU=Workstations,OU=Paris,DC=contoso,DC=local).
  3. Contrainte de périmètre : décider si la délégation doit s’appliquer à tous les ordinateurs de l’OU et de ses sous‑OU.

Accorder le droit avec DSACLS (méthode recommandée)

La syntaxe DSACLS permettant d’accorder un droit étendu sur les objets ordinateur descendants d’une OU ressemble à ceci :

dsacls "<DN-de-l'OU>" /G "DOMAINE\Groupe":CA;Generate Resultant Set of Policy (Logging);computer

Exemple concret :

dsacls "OU=Workstations,OU=Paris,DC=contoso,DC=local" ^
  /G "CONTOSO\Helpdesk-RSOP":CA;Generate Resultant Set of Policy (Logging);computer

Points clés :

  • CA; indique que l’on accorde un control access right (droit étendu).
  • Le nom du droit doit correspondre au displayName exact de l’extended right (il est en anglais, même sur des DC localisés).
  • ;computer borne l’application de l’ACE aux objets ordinateur descendants (héritage correct et ciblage précis).

Variante en poussant l’ACE sur toute l’arborescence

Si l’héritage est désactivé sur certaines sous‑OU ou ordinateurs, vous pouvez « pousser » l’ACE sur tous les objets de l’arborescence avec /T. À utiliser avec prudence et, si possible, toujours en la limitant aux objets computer :

dsacls "OU=Workstations,OU=Paris,DC=contoso,DC=local" /T ^
  /G "CONTOSO\Helpdesk-RSOP":CA;Generate Resultant Set of Policy (Logging);computer

Forcer la réplication et rafraîchir les jetons

repadmin /syncall
klist purge

Ensuite, demandez à un membre du groupe de se déconnecter/reconnecter pour obtenir un jeton frais. La réplication inter‑sites peut ajouter un délai supplémentaire avant que tous les DC exposent la nouvelle ACE.

Vérifier immédiatement que la délégation fonctionne

  1. Via GPResult : gpresult /R /S NOM-ORDI /USER DOMAINE\UtilisateurDeTest Attendez‑vous à voir s’afficher la liste des GPO appliquées au poste et à l’utilisateur.
  2. Via PowerShell (sur un poste disposant des RSAT) : Get-GPResultantSetOfPolicy -Computer NOM-ORDI -User DOMAINE\UtilisateurDeTest -ReportType Html -Path C:\Temp\RSOP.html Ouvrez le rapport généré pour confirmer la lecture.
  3. Via DSACLS (contrôle de l’ACE effective sur un ordinateur) : dsacls "CN=NOM-ORDI,OU=Workstations,OU=Paris,DC=contoso,DC=local" /S Recherchez une ligne montrant l’ACE « Generate Resultant Set of Policy (Logging) » accordée à votre groupe.

Quand l’option RSoP reste grisée dans ADUC

Même avec une ACE correcte, l’interface peut rester grisée pour des raisons de cache ou parce qu’elle évalue localement l’état d’autorisations sans prendre en compte une mise à jour récente. Voici la marche à suivre :

  • Fermez et relancez ADUC (dsa.msc) et/ou GPMC (gpmc.msc).
  • Réexécutez repadmin /syncall, attendez quelques minutes, puis réessayez.
  • Testez hors d’ADUC avec gpresult ou Get-GPResultantSetOfPolicy (cela contourne les heuristiques de la MMC).

Éviter les pièges de groupe et d’imbrication

  • Type : sécurité — n’utilisez jamais de distribution group pour des permissions ; il n’a pas de SID.
  • Portée : global/universel — privilégiez‑les lorsque le périmètre dépasse un seul domaine. Un domain local ne peut pas servir partout et peut mener à des jetons incomplets hors de son domaine d’origine.
  • Imbrication maîtrisée — évitez les chaînes trop profondes ou qui mélangent des portées incompatibles.

Procédure pas‑à‑pas (opérationnelle)

  1. Créer (ou choisir) le groupe CONTOSO\Helpdesk-RSOP (type : Security, portée : Global).
  2. Ajouter quelques comptes de test au groupe.
  3. Sur un contrôleur de domaine (ou un poste RSAT), exécuter : dsacls "OU=Workstations,OU=Paris,DC=contoso,DC=local" ^ /G "CONTOSO\Helpdesk-RSOP":CA;Generate Resultant Set of Policy (Logging);computer
  4. Forcer la réplication et rafraîchir le jeton : repadmin /syncall klist purge
  5. Vérifier avec gpresult ou Get-GPResultantSetOfPolicy.
  6. Optionnel : fermer/ré‑ouvrir ADUC, puis contrôler que l’option RSoP n’est plus grisée.

Commandes prêtes à l’emploi

ObjectifCommandeNotes
Accorder RSoP Logging à un groupe sur tous les ordinateurs d’une OUdsacls "OU=Workstations,DC=contoso,DC=local" ^ /G "CONTOSO\Helpdesk-RSOP":CA;Generate Resultant Set of Policy (Logging);computerACE héritée par les objets computer descendants.
Pousser l’ACE dans tout l’arbre (si héritage bridé)dsacls "OU=Workstations,DC=contoso,DC=local" /T ^ /G "CONTOSO\Helpdesk-RSOP":CA;Generate Resultant Set of Policy (Logging);computerÀ utiliser avec prudence. Vérifiez l’ACL après exécution.
Retirer toutes les ACE du groupe sur l’OUdsacls "OU=Workstations,DC=contoso,DC=local" /R "CONTOSO\Helpdesk-RSOP"Idéal pour revenir à l’état initial (pensez à sauvegarder avant).
Afficher l’ACL (diagnostic)dsacls "OU=Workstations,DC=contoso,DC=local" /SUtile pour archiver avant/après (> ACL_Backup.txt).

Validation côté réseau et WMI

Même avec l’ACE présente, la collecte RSoP échouera si la communication distante est filtrée. Contrôlez les points suivants sur les postes visés :

  • Service Windows Management Instrumentation (WMI) démarré.
  • Pare‑feu : règles entrantes WMI/DCOM activées (Windows Management Instrumentation (WMI‑In), Remote Service Management selon la stratégie).
  • Résolution DNS et time sync correctes (Kerberos exige un faible écart d’horloge).

Erreurs fréquentes : 0x80041003 (WBEM_E_ACCESS_DENIED) ou RPC Server Unavailable, généralement résolues par l’ouverture des flux WMI/DCOM et la vérification du nom DNS complet.

Check‑list de diagnostic rapide

  1. Le groupe est‑il bien Security (pas Distribution) ?
  2. Le scope du groupe est‑il Global/Universal (pas seulement Domain Local si le périmètre dépasse le domaine) ?
  3. Les comptes test ont‑ils reçu un nouveau jeton (déconnexion/reconnexion ou klist purge) ?
  4. La réplication AD est‑elle terminée (repadmin /replsummary propre) ?
  5. L’ACE est‑elle visible sur un ordinateur cible (dsacls "CN=PC01,..." /S) ?
  6. Le réseau autorise‑t‑il WMI/DCOM et la résolution DNS ?

Recommandations pratiques supplémentaires

  1. Validation rapide : exécuter gpresult /R /S <ComputerName> /USER <TestUser> ou Get-GPResultantSetOfPolicy depuis un membre du groupe.
  2. Délégation graphique fiable : le Delegation of Control Wizard d’ADUC ou la GPMC (nœud Group Policy ResultsDelegation) écrivent les ACE exactes sans ambiguïté.
  3. Documenter les ACE étendues : dsacls <OU> /S > ACL_Backup.txt avant/après toute modification, pour audit et rollback.
  4. Contrôler la réplication : en multisite, surveillez repadmin /replsummary et utilisez repadmin /syncall si nécessaire.
  5. Séparation des rôles : si le groupe sert exclusivement à RSoP‑Logging, n’ajoutez pas d’autres privilèges pour minimiser les risques.

Automatiser la délégation de façon sûre (PowerShell + DSACLS)

Le snippet ci‑dessous récupère automatiquement le displayName du droit étendu et applique l’ACE, ce qui évite les fautes de frappe :

# Paramètres
$OuDn   = "OU=Workstations,OU=Paris,DC=contoso,DC=local"
$Group  = "CONTOSO\Helpdesk-RSOP"

# Trouver le displayName exact du droit étendu RSoP Logging

\$root = Get-ADRootDSE
\$cfg  = \$root.configurationNamingContext
\$car  = Get-ADObject -SearchBase \$cfg `        -LDAPFilter '(&(objectClass=controlAccessRight)(displayName=Generate Resultant Set of Policy (Logging)))'`
-Properties displayName,rightsGuid

if (-not \$car) { throw "Droit étendu RSoP (Logging) introuvable." }

\$rightName = \$car.displayName

# Appliquer l’ACE sur l’OU (descendants de type computer)

\$cmd = 'dsacls "{0}" /G "{1}"\:CA;{2};computer' -f \$OuDn, \$Group, \$rightName
Write-Host \$cmd
Invoke-Expression \$cmd

# Forcer la réplication (optionnel)

Invoke-Expression "repadmin /syncall" 

Astuce : si votre déploiement comporte plusieurs OUs, bouclez sur une liste d’OU et appliquez la même commande.

Questions fréquentes

Faut‑il être administrateur local sur les postes ?

Non, pas si le droit étendu RSoP (Logging) est correctement accordé et que WMI/DCOM sont accessibles. En revanche, des GPO ou durcissements de sécurité locaux peuvent imposer des restrictions supplémentaires ; validez‑le en amont sur un échantillon de postes.

Dois‑je toucher aux permissions WMI (root\rsop) ?

Dans la plupart des cas, non : l’extended right côté AD suffit. En cas de durcissement WMI spécifique, une délégation « Remote Enable » peut s’avérer nécessaire, mais ce n’est pas la configuration par défaut.

Pourquoi la permission marche pour un utilisateur directement mais pas via un groupe ?

C’est typique d’un jeton non rafraîchi (session persistante) ou d’un groupe au mauvais type/portée. Rafraîchissez le jeton (klist purge + reconnexion) et vérifiez le type Security et la portée Global/Universal.

Bonnes pratiques de sécurité

  • Principe du moindre privilège : déléguez uniquement le droit RSoP (Logging), rien de plus.
  • Groupes dédiés : créez un groupe spécifiquement pour cette tâche (évitez d’y empiler d’autres rôles).
  • Journalisation & audit : conservez systématiquement les exports DSACLS (/S) avant/après.
  • Revue périodique : vérifiez trimestriellement les membres du groupe et la nécessité du droit.

Annexe : penser « application au bon endroit »

Pour RSoP‑Logging, le destinataire du droit est l’objet ordinateur. C’est pourquoi l’ACE doit s’appliquer à des descendants de type computer. Poser l’ACE au mauvais niveau (par exemple au dessus, sans ciblage d’objet) peut donner une impression de succès dans l’ACL tout en ne débloquant pas l’option dans les outils.

Annexe : exemple complet avec sauvegarde et rollback

REM 1) Sauvegarder l’ACL actuelle de l’OU
dsacls "OU=Workstations,OU=Paris,DC=contoso,DC=local" /S > C:\Temp\ACL_Workstations_before.txt

REM 2) Accorder le droit (descendants de type computer)
dsacls "OU=Workstations,OU=Paris,DC=contoso,DC=local" ^
/G "CONTOSO\Helpdesk-RSOP"\:CA;Generate Resultant Set of Policy (Logging);computer

REM 3) Forcer la réplication et rafraîchir le jeton
repadmin /syncall
klist purge

REM 4) Vérifier sur un poste cible
dsacls "CN=PC01,OU=Workstations,OU=Paris,DC=contoso,DC=local" /S

REM 5) (Optionnel) Rollback - retirer toutes les ACE du groupe sur l’OU
dsacls "OU=Workstations,OU=Paris,DC=contoso,DC=local" /R "CONTOSO\Helpdesk-RSOP" 

Conclusion

Pour rendre opérationnelle la délégation Generate Resultant Set of Policy (Logging) à un groupe AD, la recette gagnante tient en quatre points : (1) accorder le droit à l’endroit pertinent (descendant computer) avec DSACLS, (2) s’assurer du bon type/portée du groupe, (3) prendre en compte la réplication et le rafraîchissement des jetons, (4) valider hors interface via gpresult/Get-GPResultantSetOfPolicy. En respectant ces étapes et les contrôles réseau WMI/DCOM, l’option cesse d’être grisée et vos équipes peuvent obtenir des rapports RSoP fiables, sans sur‑privilégier les comptes.

Sommaire