DSACLS e RSOP (Logging) in Active Directory: perché ADUC resta disabilitato e come risolvere davvero

Assegni il diritto “Generate Resultant Set of Policy (Logging)” a una OU con dsacls, ma in ADUC il menu RSoP rimane grigio? Qui trovi cause, diagnosi e una procedura risolutiva completa per rendere effettiva la delega al gruppo DOMAIN\RBAC‑Workstations‑Admin.

Indice

Scenario

Obiettivo: consentire ai membri del gruppo DOMAIN\RBAC‑Workstations‑Admin di eseguire Resultant Set of Policy (Logging) su una specifica OU.

dsacls "ou=Disabled Computers,dc=domain,dc=local" /I:T ^
  /G "DOMAIN\RBAC-Workstations-Admin":CA;"Generate Resultant Set of Policy (Logging)"

Il comando scrive correttamente la ACE (Access Control Entry) sull’OU. Tuttavia, aprendo Active Directory Users and Computers (ADUC), l’opzione Resultant Set of Policy (Logging) risulta ancora disabilitata per i membri del gruppo, mentre:

Funziona subito se il diritto è assegnato a un singolo utente con lo stesso comando.
Funziona se la delega viene eseguita tramite la procedura guidata di delega in ADUC.

Come ADUC decide se abilitare il menu

Il punto chiave: ADUC non si limita a “vedere” la ACE sulla OU. Abilita il menu solo se, al momento dell’apertura della console, il token di sicurezza dell’utente contiene già il SID del gruppo delegato e se l’ACL effettiva (valutata lungo la gerarchia dell’OU) concede davvero il diritto esteso Generate Resultant Set of Policy (Logging) all’utente.

In altre parole, servono contemporaneamente:

La ACE scritta e replicata su tutti i DC pertinenti.
Un token utente aggiornato che includa il SID del gruppo con la delega.
Nessun blocco o conflitto di ereditarietà lungo il percorso.
I permessi di lettura sui GPO necessari per la valutazione (vedi più avanti).

Cause probabili e cosa significano

Categoria	Dettagli
Propagazione	La modifica dell’ACL deve replicarsi tra i controller di dominio. In ambienti multi‑sito, la convergenza può richiedere minuti o ore. Fino a replica completata, alcuni DC mostreranno il menu abilitato e altri no.
Aggiornamento del token utente	Il token di sicurezza dell’utente viene generato al logon. Se il gruppo è stato aggiunto dopo, non compare nel token finché non si effettua logoff/logon (o si aggiorna il TGT Kerberos). Senza il SID del gruppo nel token, ADUC lascia il menu disattivato.
Caching di gruppo	Su RODC e in scenari dove il GC non è contattabile, è attivo il token‑group caching. Serve un nuovo logon su un DC/GC aggiornato perché l’appartenenza al gruppo venga riflessa nel token.
Ambito di ereditarietà	L’opzione `/I:T` abilita l’ereditarietà verso oggetti figlio, ma ACE conflittuali su livelli superiori o oggetti con “Proteggi dall’eredità” possono interrompere la catena, impedendo ad ADUC di calcolare il diritto effettivo.
Limiti di ADUC	ADUC abilita il menu solo se il tuo token corrente soddisfa i controlli di accesso. Non basta che la ACE esista a directory: deve essere valida e valutabile subito per il tuo utente.

Procedura rapida di risoluzione

Segui l’ordine proposto: risolve oltre il 90% dei casi in produzione.

Forzare la replica e verificare

Avvia una sincronizzazione del catalogo su un DC con connettività completa, quindi attendi la convergenza tra i siti.

repadmin /syncall /AdeP

Se usi ADUC, seleziona Change Domain Controller… e connettiti esplicitamente al DC su cui hai aggiornato l’ACL per escludere problemi di latenza inter‑site.

Rigenerare il token di sicurezza

Effettua logoff/logon o riavvia la sessione. In alternativa, da prompt elevato sul client:

klist purge &amp;&amp; gpupdate /force

Nota: chiudere e riaprire ADUC non basta; il token si rigenera solo al nuovo logon (o al rinnovo del TGT).

Controllare tipo e ambito del gruppo

Il gruppo deve essere di tipo Security (non Distribution).
Global: valido per assegnazioni all’interno dello stesso dominio.
Universal: preferibile per scenari multi‑dominio/forestali.
Domain Local: usare con cautela; può avere senso se la delega è limitata a un solo dominio come destination delle ACL.

Verificare l’ACL effettiva e l’ereditarietà

Controlla che la ACE sia realmente presente e non “neutralizzata” da protezioni o ACE conflittuali a monte:

dsacls "ou=Disabled Computers,dc=domain,dc=local" | findstr /I "Resultant"

Se vedi la voce “Generate Resultant Set of Policy (Logging)” per il tuo gruppo e il menu è ancora grigio, sei quasi certamente davanti a un problema di token o replica.

Eseguire un test con utente nuovo

Crea un utente “pulito”, aggiungilo al gruppo delegato e prova subito da una postazione qualsiasi. Se il menu si abilita all’istante, il problema era la cache sul vecchio account (token non aggiornato).

Usare la Delegation Wizard come alternativa rapida

Quando serve urgenza o certezza visiva, la procedura guidata di delega in ADUC aggiunge le ACE necessarie (compresi permessi correlati) e ti mostra l’ereditarietà in modo più esplicito. È anche utile come confronto: applica la delega via wizard su un ambiente di test e confronta le ACE con l’output di dsacls.

Approfondimento: cosa fa davvero “Generate RSOP (Logging)”

“Generate Resultant Set of Policy (Logging)” è un diritto esteso su oggetti di directory (Domini e OU) che consente a un soggetto (utente/gruppo) di eseguire la raccolta dell’effettiva applicazione delle GPO per un utente o un computer target. A differenza della modalità Planning (simulazione), la modalità Logging legge lo stato reale dai target.

Per funzionare in modo fluido, oltre all’ACE di “Generate RSOP (Logging)” servono in pratica:

Lettura dei GPO referenziati via gPLink sui container superiori (dominio/OU) e accesso in lettura al contenuto dei GPO (SYSVOL). In molte organizzazioni ciò è già garantito ad Authenticated Users.
In ambienti particolarmente hardenizzati, potrebbe essere necessario che l’operatore possa eseguire query WMI in lettura sul namespace root\RSOP del computer target. Spesso è già permesso ai membri del dominio; in caso contrario, prevedi la delega WMI “Remote Enable” ai soli operatori autorizzati.

Perché via wizard “funziona” e via dsacls “a volte no”

La differenza non è magia, ma combinazione di fattori:

Il wizard tende a scrivere più ACE correlate oltre al singolo diritto esteso, assicurando che ADUC possa risolvere tutte le dipendenze (lettura GPO, eredità chiara, ecc.).
La prova col wizard spesso avviene dopo tempo sufficiente perché la replica sia completata e l’operatore abbia già rinnovato il token (ad esempio dopo un logoff), mascherando la vera causa.

Schema decisionale di troubleshooting

[1] ACE presente su OU?  ----- No ----&gt; Correggi dsacls e riprova
           |
           Yes
           v
[2] Replica completata? --- No ----&gt; repadmin /syncall /AdeP e attendi
           |
           Yes
           v
[3] Token aggiornato? ---- No ----&gt; logoff/logon o klist purge
           |
           Yes
           v
[4] Ereditarietà ok? ----- No ----&gt; rimuovi blocchi/protezioni e riallinea ACL
           |
           Yes
           v
[5] Lettura GPO ok? ------ No ----&gt; garantisci permessi di Read sui GPO
           |
           Yes
           v
[6] Menu ancora grigio? --- Yes ---&gt; prova con utente nuovo; se va, cache utente

Best practice operative

Standardizza i gruppi: usa gruppi di tipo Security; se devi attraversare i limiti di dominio/forest, promuovi a Universal e aspetta la replica sul GC.
Isola le deleghe: crea gruppi dedicati per ciascuna responsabilità (es. RBAC‑Workstations‑Admin per i computer, RBAC‑Users‑Support per gli utenti).
Documenta le ACE: conserva l’output di dsacls prima/dopo; facilita rollback e audit.
Connetti ADUC al DC giusto: evita diagnosi fuorvianti causate da DC non aggiornati; usa “Connect to Domain Controller…”.
Evita di rompere l’ereditarietà: preferisci deleghe sul container più alto possibile che copra il perimetro desiderato; la gestione sarà più semplice.

Comandi utili di verifica

Verifica della ACE specifica su OU

dsacls "ou=Disabled Computers,dc=domain,dc=local" | findstr /I "Resultant"

Replica immediata

repadmin /syncall /AdeP

Token/kerberos refresh lato client

klist purge &amp;&amp; gpupdate /force

Quale DC stai usando

echo %LOGONSERVER%

Controllo gruppi nel token corrente

whoami /groups

Esempi pratici di delega con DSACLS

Concedere Logging su OU specifica (ereditarietà attivata)

dsacls "ou=Disabled Computers,dc=domain,dc=local" /I:T ^
  /G "DOMAIN\RBAC-Workstations-Admin":CA;"Generate Resultant Set of Policy (Logging)"

Concedere anche Planning (se necessario per la simulazione)

dsacls "ou=Disabled Computers,dc=domain,dc=local" /I:T ^
  /G "DOMAIN\RBAC-Workstations-Admin":CA;"Generate Resultant Set of Policy (Planning)"

Garantire la sola lettura dei GPO (se non già presente)

In molti ambienti Authenticated Users hanno già Read sui GPO. Se non fosse così, puoi delegare Read a livello di dominio o direttamente sui GPO interessati (tramite GPMC). Mantieni il principio del privilegio minimo.

Verifiche di sicurezza e rollback

Principio del privilegio minimo: delega solo le operazioni strettamente necessarie; evita di ampliare la superficie di attacco con permessi generici.
Rollback: se devi rimuovere la delega in urgenza, usa la Delegation Wizard per revocare in modo tracciabile o ripristina l’ACL esportata (mantieni copia dell’output dsacls “prima” dei cambi).

Checklist rapida

[ ] Replica tra DC completata
[ ] Utenti hanno effettuato nuovo logon (o klist purge)
[ ] Gruppo è di tipo Security e con ambito adeguato (Global/Universal)
[ ] Nessuna eredità bloccata sulle OU superiori
[ ] ACE visibile in dsacls per “Generate RSOP (Logging)”
[ ] Permessi di Read sui GPO verificati

FAQ operative

Posso far funzionare subito senza logoff?
A volte sì, rigenerando il TGT con klist purge e riaprendo la sessione elevata, ma il modo affidabile resta un nuovo logon.

Serve essere Domain Admin?
No. Proprio la delega serve a evitare privilegi eccessivi, assegnando diritti mirati (RSoP Logging) solo ai gruppi che ne hanno esigenza.

Perché su un utente singolo funziona subito ma col gruppo no?
Perché l’utente ha già nel token la SID propria, ma per la SID del gruppo è necessario un nuovo logon (oltre alla replica). Con la delega sul singolo, il menu si abilita immediatamente.

È meglio delegare a livello di dominio o di OU?
Dipende dal perimetro. Se l’operatore deve analizzare computer distribuiti su più OU, la delega a livello di dominio riduce la complessità. In caso contrario, limita la delega alle sole OU necessarie.

Conclusioni

Quando il menu Resultant Set of Policy (Logging) resta disattivato per un gruppo dopo l’uso di dsacls, la causa è quasi sempre una combinazione di replica non ancora completata e token utente non rigenerato, talvolta aggravata da ereditarietà interrotta o da permessi di lettura GPO mancanti. Seguendo la procedura qui descritta (replica, refresh del token, verifica ereditarietà e diritti complementari) la delega diventa operativa in modo affidabile. La Delegation Wizard resta una scorciatoia utile quando serve un risultato immediato e visivamente verificabile, ma dsacls offre massima ripetibilità e automazione per ambienti gestiti con criteri RBAC.

Ricapitolando i passaggi chiave

Applica la ACE con dsacls e abilita l’ereditarietà (/I:T).
Forza la replica (repadmin /syncall /AdeP) e connettiti al DC giusto.
Rigenera il token (logoff/logon o klist purge).
Verifica l’ACL con dsacls e l’assenza di blocchi d’ereditarietà.
Assicurati della lettura GPO a livello di dominio/OU.
In caso di dubbio, testa con un utente nuovo o usa la Delegation Wizard per conferma.

Con queste verifiche, nella maggior parte dei casi il menu RSOP (Logging) in ADUC si abilita correttamente per i membri del gruppo delegato.

Nota finale: in ambienti con RODC, VPN on‑demand o linee WAN lente, prevedi tempi di replica e token refresh più lunghi. Inserisci questi aspetti nelle tue runbook e nelle aspettative degli operatori per evitare falsi allarmi.

Esempio completo “ready‑to‑run”

:: 1) Delega il diritto RSOP (Logging) sull'OU
dsacls "ou=Disabled Computers,dc=domain,dc=local" /I:T ^
  /G "DOMAIN\RBAC-Workstations-Admin":CA;"Generate Resultant Set of Policy (Logging)"

:: 2) Replica e verifica
repadmin /syncall /AdeP
dsacls "ou=Disabled Computers,dc=domain,dc=local" | findstr /I "Resultant"

:: 3) Lato operatore: rigenera token e GPO
klist purge && gpupdate /force

:: 4) Se ancora grigio: controlla DC usato e token
echo %LOGONSERVER%
whoami /groups

Se tutto è in ordine, la voce Resultant Set of Policy (Logging) comparirà abilitata in ADUC per i membri di DOMAIN\RBAC‑Workstations‑Admin quando si seleziona la OU o i computer all’interno della stessa.