Come verificare i permessi GPO e SYSVOL in Active Directory

Contesto

Durante security assessment e review di governance GPO, capita spesso di trovare ambienti con tooling maturo: change management, auditing, workflow approvativi, versioning e processi formalizzati.

Il punto critico non e quasi mai lo strumento in se.

Il rischio nasce quando una delega viene implementata male, quando un gruppo operativo cresce senza controllo, oppure quando una correzione urgente amplia permessi oltre il necessario e resta permanente.

In questi casi una domanda diventa decisiva:

Cosa succede se un utente non autorizzato puo modificare il contenuto distribuito tramite SYSVOL?

La risposta e semplice: puoi avere una GPO apparentemente sicura in console, ma con payload operativo alterabile sul file system.

Se il tuo obiettivo e capire non solo chi puo alterare il contenuto di una GPO, ma anche come distinguere tra chi deve ricevere la policy e chi deve amministrarla, una lettura utile e GPO Security Filtering vs Delegation in Active Directory: differenze critiche per audit e hardening.

Scope e evidenze

Questo articolo e focalizzato su uno scope preciso: sicurezza operativa delle GPO lato SYSVOL (GPT), non solo deleghe in GPMC.

Le evidenze riportate sono pratiche e verificabili:

• scenario reale osservato in security assessment;
• laboratorio controllato senza payload offensivi;
• checklist e comandi PowerShell per audit/remediation;
• principi least privilege applicabili in produzione.

Obiettivo dell'articolo

Questo articolo non sostiene che i prodotti di governance GPO introducano automaticamente vulnerabilita.

Al contrario, nella maggior parte dei casi il problema e implementativo:

• deleghe eccessive;
• ACL NTFS o Share troppo permissive;
• ereditarieta non controllata;
• gruppi di sicurezza riutilizzati negli anni;
• account di servizio con privilegi non minimizzati.

L'obiettivo e mostrare come identificare e correggere questo rischio in modo pratico.

Quick audit in 5 minuti

Se hai poco tempo, verifica subito questi 5 punti prima di proseguire:

1. ACL SHARE su SYSVOL e NETLOGON: nessun Change/Full a gruppi generici.
2. ACL NTFS su Policies\{GUID}: assenza di Modify/Write per identita non autorizzate.
3. Intersezione permessi effettivi NTFS+SHARE su accesso remoto SMB.
4. Ereditarieta ACL sui percorsi GPT: nessuna eredita anomala o storica.
5. Membership dei gruppi delegati GPO/SYSVOL: niente gruppi legacy troppo ampi.

Se uno di questi 5 punti fallisce, tratta la GPO come esposta fino a remediation completata.

Confronto GPC/SYSVOL e audit delle modifiche

Per una review ripetibile, il report esporta in un CSV i livelli di permission del GPC restituiti da Get-GPPermission, le ACE NTFS della copia GPT su SYSVOL e gli eventi recenti associati alle GPO. Genera anche un report HTML locale con riepiloghi grafici, ricerca e paginazione; il CSV mantiene tutte le colonne e resta l'evidenza completa. Le chiavi GPO consentono di affiancare i due lati e mettere in evidenza trustee presenti solo da una parte o ACL con ereditarietà attiva.

Limite importante: i livelli GPO (GpoApply, GpoRead, GpoEditDeleteModifySecurity) e i diritti NTFS (ReadAndExecute, Modify, FullControl) non sono valori direttamente equivalenti. Il report confronta trustee e mostra i diritti separatamente; un trustee presente da entrambi i lati richiede comunque una review semantica. Permessi AD come List Object non hanno una mappatura NTFS uno-a-uno. Il report è read-only e non ripara le ACL. Per il messaggio GPMC «The permissions for this GPO in the SYSVOL folder are inconsistent with those in Active Directory», il controllo e la sincronizzazione documentati restano quelli di Microsoft: Permissions for this GPO are inconsistent. Non cliccare per sincronizzare senza aver prima salvato e revisionato le ACL.

Lo script legge i log Security dei DC negli ultimi 30 giorni. 5136 registra modifiche agli attributi GPC solo se Audit Directory Service Changes e una SACL mirata le consentono; non usarlo da solo come prova di una modifica DACL (Microsoft Event 5136). 4662 con WRITE_DAC (0x40000) è il segnale per operazioni sulla DACL AD e richiede Audit Directory Service Access più una SACL che auditi WRITE_DAC sul GPC (Microsoft Event 4662). 4670 segnala permessi modificati su oggetti file system: richiede Audit File System e una SACL su SYSVOL che auditi Change Permissions o Take Ownership; non viene generato quando viene modificata la SACL stessa (Microsoft Event 4670). Configura auditing e SACL in modo mirato: possono produrre volumi elevati.

Prerequisiti di esecuzione: richiede PowerShell 7 o superiore e i moduli RSAT ActiveDirectory e GroupPolicy installati; non è compatibile con Windows PowerShell 5.1. In PowerShell 7 carica i moduli RSAT tramite il livello di compatibilità Windows PowerShell. Eseguirlo da un amministratore con permessi di lettura sul log Security di tutti i domain controller elencati.

Interpretare e verificare i segnali "Trustee only"

Trustee only in GPC/GPT indica che il SID manca dall'altro elenco: non è una prova automatica di ACL vulnerabile. I permessi GPC e i diritti NTFS GPT sono modelli distinti, non confrontabili uno-a-uno. CREATOR OWNER con ContainerInherit, ObjectInherit e InheritOnly vale per file e sottocartelle, non concede accesso diretto alla radice GPT. Nei GPO predefiniti, Domain Admins/Enterprise Admins possono corrispondere a BUILTIN\Administrators, e Server Operators può avere sola lettura; verifica però i membri diretti del gruppo. L'ACE standard di BUILTIN\Administrators concede realmente scrittura: un utente aggiunto direttamente al gruppo può modificare il GPT anche se non riceve GpoCustom sul GPC. Non presumere che ogni account in quel gruppo sia equivalente a Domain/Enterprise Admins: valida e approva singolarmente i membri diretti.

Per il GPO interessato, confronta la permission GPC, le ACE GPT e le flag complete di ereditarietà; verifica anche chi appartiene a BUILTIN\Administrators. L'ispezione non cambia il dominio. Le ultime righe creano solo file di backup locali. Esegui in PowerShell 7 e adatta $moduleRoot se i manifest RSAT sono installati altrove.

$moduleRoot = Join-Path $env:WINDIR "System32\WindowsPowerShell\v1.0\Modules"
Import-Module (Join-Path $moduleRoot "ActiveDirectory\ActiveDirectory.psd1") -SkipEditionCheck
Import-Module (Join-Path $moduleRoot "GroupPolicy\GroupPolicy.psd1") -SkipEditionCheck

$domain = Get-ADDomain
$gpoName = "Default Domain Policy"
$gpo = Get-GPO -Name $gpoName -Domain $domain.DNSRoot -Server $domain.PDCEmulator
$gpcPermissions = Get-GPPermission -Guid $gpo.Id -All `
    -DomainName $domain.DNSRoot -Server $domain.PDCEmulator
$gptPath = "\\$($domain.PDCEmulator)\SYSVOL\$($domain.DNSRoot)\Policies\{$($gpo.Id)}"
$gptAcl = Get-Acl -LiteralPath $gptPath

$gpcPermissions | Select-Object Trustee, Permission, Inherited
[pscustomobject]@{ GptDaclProtected = $gptAcl.AreAccessRulesProtected }
$gptAcl.Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, `
    IsInherited, InheritanceFlags, PropagationFlags
Get-ADGroupMember -Identity "CN=Administrators,CN=Builtin,$($domain.DistinguishedName)" `
    -Server $domain.PDCEmulator | Select-Object Name, ObjectClass, SID

$backupPath = Join-Path $PWD ("GPO-ACL-Backup-" + (Get-Date -Format "yyyyMMdd-HHmmss"))
New-Item -ItemType Directory -Path $backupPath -ErrorAction Stop | Out-Null
Backup-GPO -Guid $gpo.Id -Path $backupPath -Domain $domain.DNSRoot -Server $domain.PDCEmulator
$gptAcl | Export-Clixml -Path (Join-Path $backupPath "gpt-acl-before.xml")

Il backup GPO e il file XML sono punti di ripristino/evidenza; la cartella viene creata dal codice prima di chiamare Backup-GPO.

In GPMC controlla Delegation > Advanced e confronta trustee, diritti e membership con la baseline approvata. Su un GPO predefinito, usa Restore Defaults soltanto se vuoi ripristinare deliberatamente i permessi standard. Se GPMC segnala un'incoerenza e propone di allineare SYSVOL ad Active Directory, non confermare alla cieca: l'operazione riscrive l'ACL NTFS del GPT e rimuove l'ereditarietà (Microsoft KB 2838154). Per un GPO personalizzato, modifica la delega tramite GPMC; non copiare manualmente l'ACL GPC sull'ACL GPT.

Se un utente non autorizzato all'amministrazione dei DC è membro diretto di BUILTIN\Administrators, tratta la membership come un percorso di scrittura effettivo su SYSVOL, anche se il report non trova una permission GPC corrispondente. Controlla sia l'elenco dei membri diretti di BUILTIN\Administrators sia i gruppi annidati dell'utente e confrontali con Get-GPPermission: Domain Admins ed Enterprise Admins sono deleghe amministrative attese, mentre un account fuori da queste deleghe richiede approvazione esplicita. Se l'appartenenza è involontaria, correggi la membership con change control; non rimuovere l'ACE BUILTIN\Administrators dal GPT predefinito, perché serve anche agli amministratori autorizzati. Se l'utente deve amministrare solo GPO specifiche, usa una delega GPMC circoscritta invece di concedergli amministrazione DC. Dopo la remediation, ricontrolla GPMC, NTFS e Share, riesegui il report e prova l'applicazione su un client pilota.

Prodotti che spesso richiedono deleghe o accessi aggiuntivi

Nei contesti enterprise e comune trovare soluzioni che richiedono account dedicati, workflow approvativi o accesso ai contenuti GPO/SYSVOL.

Prodotto	Vendor	Scopo
Advanced Group Policy Management (AGPM)	Microsoft	Versioning, approvazione e change management GPO
GPOADmin	Quest	Governance e controllo modifiche GPO
Recovery Manager for Active Directory	Quest	Backup e ripristino GPO e SYSVOL
PolicyPak	Netwrix	Estensioni avanzate alle policy Microsoft
ADManager Plus	ManageEngine	Gestione amministrativa delle GPO
ADAudit Plus	ManageEngine	Auditing delle modifiche alle policy
Cayosoft Administrator	Cayosoft	Governance e amministrazione Active Directory
Cayosoft Guardian	Cayosoft	Auditing e monitoraggio delle modifiche
Change Manager for Group Policy	SDM Software	Workflow approvativi e controllo modifiche
Group Policy Automation Engine	SDM Software	Automazione e deployment di GPO
Group Policy Auditing and Attestation	SDM Software	Auditing e compliance
Group Policy Compliance Manager	SDM Software	Controlli di conformità

La loro presenza non implica una debolezza, ma deve attivare una verifica puntuale su:

• ACL NTFS;
• ACL Share;
• gruppi delegati;
• account di servizio;
• permessi ereditati sui percorsi GPT.

Dove vive davvero una Group Policy

Una GPO e composta da due elementi distinti.

Group Policy Container (GPC)

Parte in Active Directory:

CN={GUID}
CN=Policies
CN=System
DC=domain
DC=local

Contiene metadata, versioni e informazioni di collegamento.

Group Policy Template (GPT)

Parte nella SYSVOL:

\\domain.local\SYSVOL\domain.local\Policies\{GUID}

Contiene i file realmente consumati dai client:

• script;
• Registry.pol;
• preferenze;
• impostazioni macchina/utente;
• contenuti distribuiti.

Il GPT è il punto di impatto operativo.

Il controllo che quasi tutti saltano

Molti audit si concentrano correttamente su:

• deleghe in GPMC;
• ownership delle GPO;
• diritti di creazione e linking;
• permessi di modifica lato GPO.

Molto meno spesso vengono analizzate con la stessa profondita le ACL NTFS e Share della SYSVOL sui percorsi GPT.

Eppure e li che i client leggono cio che devono applicare.

Se il GPT è modificabile da identità non autorizzate, la policy è compromessa anche quando la GPMC sembra in ordine.

Perché con ACL NTFS errate qualcuno può scrivere (e quando non può)

Questo punto e fondamentale: sui percorsi SMB i permessi effettivi sono l'intersezione tra ACL NTFS e ACL SHARE.

In pratica:

• se NTFS concede Modify ma la SHARE concede solo Read, da remoto via \\domain\SYSVOL la scrittura non passa;
• se sia NTFS sia SHARE concedono scrittura, il contenuto GPT puo essere alterato;
• se l'accesso avviene localmente sul Domain Controller (path locale), la SHARE non entra nel calcolo.

Quindi, quando in assessment trovi scrittura effettiva su GPT, devi sempre verificare entrambi i piani: NTFS e SHARE.

Quali permessi SHARE aspettarsi di default su SYSVOL/NETLOGON

I dettagli possono variare leggermente tra baseline e hardening, ma in un assetto sano il principio e:

• utenti autenticati con sola lettura;
• amministratori con pieno controllo;
• nessun Change o Full assegnato a gruppi generici (Everyone, Authenticated Users, Domain Users).

Check rapido consigliato:

Get-SmbShareAccess -Name SYSVOL
Get-SmbShareAccess -Name NETLOGON

Oppure:

net share

Laboratorio dimostrativo (senza strumenti commerciali)

Per isolare il problema non serve software terzo.

Scenario

Dominio:

MGLAB.LOCAL

GPO:

MGWP - Logon Script Demo

Configurazione:

User Configuration
 └ Windows Settings
    └ Scripts (Logon)

Script iniziale:

echo %USERNAME% logged on >> C:\Temp\Users.log

Nessun payload offensivo: solo comportamento dimostrativo.

Situazione iniziale

• ACL corrette;
• utenti standard in sola lettura;
• amministratori con pieno controllo.

Errore amministrativo tipico

Durante una delega o un troubleshooting viene assegnato, ad esempio:

Authenticated Users = Modify

oppure:

Everyone = Modify

oppure:

GPO-Operators = Modify

su una cartella GPT in SYSVOL.

Effetto pratico

Un utente standard (es. Test Account), senza diritti GPMC e senza deleghe amministrative GPO, puo comunque modificare il file distribuito dal GPT se ha Modify su quel percorso.

Dal punto di vista AD/GPMC puo sembrare tutto regolare:

• nessuna delega GPO alterata;
• nessuna modifica evidente ai permessi in console;
• policy apparentemente sicura.

Ma alla successiva applicazione, i client consumano il contenuto GPT modificato.

Pippo non modifica il GPO in console.

Pippo modifica cio che il GPO distribuisce.

Questa differenza è il cuore del rischio.

Perché è un rischio alto anche nei framework di assessment

Molte metodologie di security assessment AD classificano ad alto rischio i contenuti distribuiti via GPO modificabili da utenti standard o gruppi non strettamente autorizzati.

Il principio e lo stesso usato da molte piattaforme di analisi posture AD: non basta la governance logica delle deleghe, serve controllo forte anche sul piano file system SYSVOL.

Checklist di verifica rapida

1) Inventario GPO

Get-GPO -All

2) Revisione deleghe GPO

Get-GPPermission -All -Name "MGWP - Logon Script Demo"

Nota: in produzione conviene esportare tutte le deleghe e filtrare identità inattese.

3) Analisi ACL SYSVOL

icacls \\domain\SYSVOL\domain\Policies

oppure:

Get-Acl "\\domain\SYSVOL\domain\Policies\{GUID}" | Format-List

Ricerca indicatori critici sui percorsi GPT:

• Modify;
• Write;
• Full Control;
• ereditarieta non prevista;
• gruppi generici (Everyone, Authenticated Users) con permessi oltre Read/ReadAndExecute.

4) Analisi ACL SHARE su SYSVOL e NETLOGON

Get-SmbShareAccess -Name SYSVOL
Get-SmbShareAccess -Name NETLOGON

Indicatori critici lato SHARE:

• Change o Full su gruppi generici;
• deleghe SHARE non allineate al modello least privilege;
• differenze inattese tra SYSVOL e NETLOGON.

Remediation operativa

Priorita immediata

1. Rimuovere diritti di scrittura non necessari da GPT in SYSVOL.
2. Verificare anche ACL Share, non solo NTFS.
3. Controllare ereditarieta su cartelle Policies e sottocartelle GUID.
4. Rivalidare gruppi delegati e membership effettiva.

Governance da stabilizzare

1. Usare gruppi dedicati per deleghe GPO con naming chiaro e scopo limitato.
2. Separare account operativi da account di servizio.
3. Introdurre review periodica delle ACL SYSVOL (es. mensile o trimestrale).
4. Mettere a scadenza ogni eccezione con owner e motivazione.
5. Integrare un controllo specifico SYSVOL nei processi di change GPO.

Controlli di detection consigliati

• Alert su variazioni ACL nelle cartelle Policies{GUID};
• monitoraggio cambi file in SYSVOL non associati a change approvati;
• correlazione con eventi di modifica GPO e finestre manutentive.

FAQ rapide (intent di ricerca)

Qual e la differenza tra GPO Security Filtering e Delegation?

Security Filtering definisce chi applica la policy. Delegation definisce chi puo amministrare la policy o i suoi contenuti. Sono piani diversi: puoi avere filtering corretto ma deleghe/ACL SYSVOL sbagliate che espongono comunque il GPT.

Quali permessi di default sono attesi su SYSVOL?

In una baseline sana, utenti autenticati hanno sola lettura e amministratori pieno controllo. Non dovrebbero esistere Change o Full assegnati a gruppi generici su SHARE, ne Modify non giustificati su NTFS GPT.

GPC vs GPT: dove si concentra il rischio operativo?

Il GPC gestisce metadata e governance logica, ma il GPT in SYSVOL contiene il payload applicato ai client. Se il GPT e scrivibile da identita non autorizzate, il rischio operativo e immediato anche con GPMC apparentemente in ordine.

Come ripristinare i permessi SYSVOL in sicurezza?

Prima esegui un backup ACL e una finestra di change controllata. Poi rimuovi scritture non necessarie su NTFS/SHARE, valida ereditarieta e membership dei gruppi delegati, infine verifica applicazione GPO su un pilot prima dell'estensione.

E sufficiente controllare solo le deleghe in GPMC?

No. Le deleghe in GPMC coprono la governance logica del GPO, ma non garantiscono da sole l'integrità del contenuto GPT nella SYSVOL. Va sempre verificato anche il piano ACL NTFS e Share.

Errori ricorrenti da evitare

• Fidarsi solo della vista deleghe in GPMC.
• Correggere incident aprendo Modify in modo temporaneo e non rimuoverlo.
• Riutilizzare gruppi legacy senza revisione membership.
• Delegare a gruppi troppo ampi per semplificare operazioni urgenti.
• Valutare solo il rischio AD logico ignorando il rischio file system.

Approfondimenti correlati

• RC4 deprecation in Active Directory
• Fallback Kerberos -> NTLM in Active Directory
• SPN in Active Directory: guida pratica con KCD e RBCD
• Active Directory RC4 remediation: service account da RC4 ad AES senza reset password

Conclusioni

Quando valuti la sicurezza delle Group Policy, non fermarti alla domanda:

Chi puo modificare il GPO?

Aggiungi sempre la domanda decisiva:

Chi puo modificare cio che il GPO distribuisce?

Se non proteggi la SYSVOL con la stessa disciplina con cui governi le deleghe in GPMC, una policy apparentemente solida puo diventare un vettore di distribuzione non affidabile per l'intero dominio.

---

Hai bisogno di aiuto?

Se stai facendo security assessment AD o hardening GPO/SYSVOL e vuoi una verifica rapida ma concreta su ACL, deleghe e rischio operativo reale, possiamo analizzare insieme il tuo scenario e definire una remediation prioritaria.

• Contattami per una review tecnica mirata sul tuo ambiente.
• Supporta il progetto su PayPal se questi contenuti ti aiutano nel lavoro quotidiano.

---