Permessi SYSVOL in Active Directory: baseline e drift

Contesto

SYSVOL e NETLOGON sono directory critiche in qualsiasi infrastruttura Active Directory. Contengono script, template e GPT (Group Policy Template) che i client di dominio leggono a ogni ciclo di Group Policy Refresh. Come abbiamo già visto, se i permessi che li proteggono non sono corretti, il rischio operativo e di sicurezza è immediato.

Il problema più comune non è la configurazione iniziale. Windows Server imposta una baseline ragionevole al momento della promozione del Domain Controller. Il problema è il drift nel tempo: una correzione urgente applica permessi troppo ampi e non viene mai rivista, un tool legacy aggiunge un account di servizio con Full Control e lo lascia lì, un errore propagato via ereditarietà contamina le ACL di decine di GPT in modo silenzioso.

Questa guida definisce la baseline attesa, i segnali di drift più frequenti e le verifiche minime per mantenerla sotto controllo.

Per capire chi può realmente modificare una GPO e come condurre un assessment completo, la lettura di riferimento è Audit permessi SYSVOL in Active Directory: come verificare chi può modificare davvero le GPO.

Scope

Questa guida copre:

• permessi NTFS e Share attesi su SYSVOL e NETLOGON dopo una promozione standard;
• differenza tra permessi nominali (visibili in GUI) e permessi effettivi (applicati via SMB);
• pattern di drift più frequenti in ambienti enterprise;
• comandi PowerShell per verifica rapida e review periodica;
• criteri di remediation senza impatto su replica DFSR.

Non copre la procedura di audit completa delle singole GPO, la delega GPMC o il meccanismo GPC/GPT. Per questi argomenti, fare riferimento alla guida principale sull'assessment SYSVOL ACL.

Struttura di SYSVOL e NETLOGON

In ogni Domain Controller, SYSVOL è esposta sia come percorso locale sia come share di rete. Di seguito il default, se non diversamente specificato durante la promozione:

Percorso locale:   C:\Windows\SYSVOL\sysvol\<domain.local>\
Percorso UNC:      \\<domain.local>\SYSVOL\<domain.local>\
                   \\<domain.local>\NETLOGON    (alias per la sottocartella scripts\)

Sottocartelle principali:
  Policies\     -> GPT (Group Policy Template) per ogni GPO
  scripts\      -> Script logon/logoff/startup/shutdown

La share NETLOGON è un alias della sottocartella scripts\ all'interno della SYSVOL. I client accedono a entrambe via SMB, quindi i permessi effettivi dipendono dall'intersezione tra permessi NTFS e permessi di Share.

Baseline attesa: permessi NTFS

I seguenti permessi NTFS rappresentano la baseline attesa dopo una promozione standard su dominio con functional level Windows Server 2008 R2 o successivo dove sia stata implementata la replica DFSR.

Radice SYSVOL (\SYSVOL\sysvol\<domain.local>\)

Identità	Permessi NTFS	Scope	Tipo
NT AUTHORITY\SYSTEM	Full Control	Questa cartella, sottocartelle e file	Esplicito
BUILTIN\Administrators	Full Control	Questa cartella, sottocartelle e file	Esplicito
<DOMAIN>\Domain Admins	Full Control	Questa cartella, sottocartelle e file	Esplicito
<DOMAIN>\Enterprise Admins	Full Control	Questa cartella, sottocartelle e file	Esplicito
<DOMAIN>\Enterprise Domain Controllers	Read & Execute	Questa cartella, sottocartelle e file	Esplicito
NT AUTHORITY\Authenticated Users	Read & Execute, List, Read	Questa cartella, sottocartelle e file	Esplicito
CREATOR OWNER	Full Control	Solo sottocartelle e file	Speciale

Sottocartella Policies\ e singoli GPT ({GUID}\)

Per ereditarietà, le stesse ACL si propagano dalla radice a tutta la gerarchia Policies\. Ogni subfolder corrispondente a una GPO ({GUID}\) eredita queste impostazioni, salvo modifiche introdotte da strumenti di governance GPO o da interventi manuali.

L'assenza di CREATOR OWNER applicato alla cartella corrente (non solo a sottocartelle e file) è corretta e attesa. Se compare con scope più ampio, è un segnale da verificare.

Permessi Share attesi

Share	Identità	Permesso Share
SYSVOL	Everyone	Read
NETLOGON	Everyone	Read

I permessi Share su Everyone: Read sono corretti per design. L'accesso in scrittura deve essere controllato esclusivamente a livello NTFS, non Share. La presence di Change o Full Control sulla Share per identità non di sistema è sempre un segnale critico.

Permessi nominali vs permessi effettivi

Il meccanismo di intersezione NTFS+Share — con scenario reale di laboratorio e dimostrazione dell'impatto operativo — è trattato in dettaglio nella guida Audit permessi SYSVOL in Active Directory: come verificare chi può modificare davvero le GPO. Questa sezione serve come riferimento rapido per leggere correttamente la baseline.

Su accesso remoto SMB il layer più restrittivo tra NTFS e Share prevale sempre:

Account	NTFS	Share SYSVOL	Risultato accesso remoto
Account A	Modify	Read	Read — la Share limita
Account B	Read	Change	Read — NTFS limita
Account C	Full Control	Full Control	Full Control
Account D	Write	Read	Read — la Share limita
Account E	Read & Execute	— (non elencato)	Read & Execute

Conseguenza per la lettura della baseline: controllare solo NTFS o solo Share restituisce sempre un quadro incompleto. I due layer vanno letti insieme.

Drift tipico

Questi sono i pattern più frequenti che ho personalmente osservato in ambienti enterprise dopo mesi o anni di operatività.

1. Account di servizio con Full Control legacy

Strumenti come AGPM, Quest GPOADmin o Quest Recovery Manager richiedono spesso accesso alla SYSVOL durante l'installazione. L'account di servizio viene aggiunto con Full Control e raramente rimosso dopo una migrazione, una sostituzione del tool o una dismissione del progetto.

Il rischio concreto: un account di servizio non monitorato, con password vecchia o condivisa, che ha Full Control su tutta la gerarchia Policies\.

2. Gruppi operativi con permessi Write ereditati

Durante un'urgenza, viene aggiunto Modify a un gruppo di supporto IT su una specifica cartella GPT. L'ereditarietà propaga il permesso ad altre GPT non coinvolte nell'operazione originale. Il cambio non viene mai revocato.

3. Inheritance break non documentato

Per isolare una GPT specifica, viene disabilitata l'ereditarietà e applicata una ACL custom. Dopo mesi, nessuno ricorda perché quell'eccezione esiste e il permesso custom è più ampio della baseline. Nei review standard la cartella sembra "normale" perché non ha ACL anomale evidenti — ma il fatto che abbia inheritance disabilitato è già un segnale.

4. Pre-Windows 2000 Compatible Access

Origine

Il gruppo Pre-Windows 2000 Compatible Access esiste in ogni dominio Active Directory fin da Windows 2000. Nasce da una scelta fatta durante la promozione del primo Domain Controller: il wizard dcpromo chiedeva se l'ambiente dovesse essere compatibile con applicazioni pre-Windows 2000, come server RAS legacy, applicazioni NTLM di terze parti o software che enumeravano utenti e gruppi di dominio senza autenticazione Kerberos.

Se si sceglieva la compatibilità legacy, il gruppo Everyone — e in alcuni casi Anonymous Logon — veniva aggiunto automaticamente come membro di Pre-Windows 2000 Compatible Access. Questa membership è rimasta invariata nei domini che hanno attraversato upgrade successivi senza una revisione esplicita.

Cosa fa

Il gruppo concede ai propri membri permessi in lettura su determinati oggetti in Active Directory — account utente, gruppi, attributi di membership — che sarebbero altrimenti accessibili solo ad account autenticati. Storicamente serviva per permettere a servizi legacy di interrogare il directory senza disporre di un account di dominio o di una sessione Kerberos valida.

Il canale tipico era la null session SMB: una connessione anonima a IPC$ che, con i permessi legacy attivi, consentiva l'enumerazione del dominio senza credenziali. Questa superficie di attacco è stata documentata e sfruttata per anni prima che venisse chiusa per default nelle versioni successive di Windows.

Perché finisce su SYSVOL

Nei domini promossi con compatibilità legacy, la ACL SYSVOL eredita permessi che includono i membri di questo gruppo — in pratica Everyone o Anonymous Logon con accesso in lettura. Nei casi più gravi, upgrade successivi da NT4 o da Windows 2000 hanno propagato questi permessi all'intera gerarchia Policies\ senza che nessuno li rimuovesse.

Il risultato: il contenuto dei GPT (script, Registry.pol, impostazioni di sicurezza) è leggibile da chiunque, inclusi utenti non autenticati se Anonymous Logon è presente.

Come verificare la membership attuale

Get-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" |
    Select-Object Name, objectClass, distinguishedName |
    Format-Table -AutoSize

In un ambiente moderno questo gruppo dovrebbe essere vuoto o contenere solo account esplicitamente documentati per applicazioni legacy ancora in produzione. La presenza di Everyone o Anonymous Logon è un finding critico da trattare immediatamente.

5. Rimozione accidentale di SYSTEM

Una modifica errata durante un hardening aggressivo può rimuovere NT AUTHORITY\SYSTEM dalla ACL SYSVOL. Questo non impatta l'accesso diretto degli utenti, ma può interferire con operazioni di sistema, backup agentless e il funzionamento stesso della replica DFSR.

6. Everyone o Domain Users con Read+Write sulla Share

Durante il troubleshooting di un problema di replica o di accesso client, viene impostato Change su Everyone sulla share SYSVOL o NETLOGON. Il problema viene "risolto" così e il permesso rimane indefinitamente.

Quick check PowerShell

Verifica permessi Share

# Permessi Share di SYSVOL e NETLOGON
Get-SmbShareAccess -Name SYSVOL  | Format-Table -AutoSize
Get-SmbShareAccess -Name NETLOGON | Format-Table -AutoSize

Output atteso: Everyone con Read. Qualsiasi Change o Full Control per identità non di sistema è un segnale da trattare immediatamente. Per l'analisi del layer Share in un contesto di assessment completo, inclusi gli scenari di abuso, vedi la guida di assessment SYSVOL ACL.

Verifica ACL NTFS sulla radice Policies

$domain      = $env:USERDNSDOMAIN
$policiesPath = "\\$domain\SYSVOL\$domain\Policies"

(Get-Acl -Path $policiesPath).Access |
    Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited |
    Sort-Object IdentityReference |
    Format-Table -AutoSize

Rilevare Write/Modify fuori dalla baseline

$domain      = $env:USERDNSDOMAIN
$policiesPath = "\\$domain\SYSVOL\$domain\Policies"

$baseline = @(
    "NT AUTHORITY\SYSTEM",
    "BUILTIN\Administrators",
    "$env:USERDOMAIN\Domain Admins",
    "$env:USERDOMAIN\Enterprise Admins",
    "$env:USERDOMAIN\Enterprise Domain Controllers",
    "CREATOR OWNER"
)

(Get-Acl -Path $policiesPath).Access |
    Where-Object {
        ($_.FileSystemRights -match "Write|Modify|FullControl") -and
        ($_.IdentityReference.Value -notin $baseline) -and
        ($_.AccessControlType -eq "Allow")
    } |
    Select-Object IdentityReference, FileSystemRights, IsInherited |
    Format-Table -AutoSize

Se questo script restituisce risultati, ogni riga è un candidato per revisione immediata. Output vuoto è il risultato atteso.

Rilevare GPT con inheritance disabilitato

$domain      = $env:USERDNSDOMAIN
$policiesPath = "\\$domain\SYSVOL\$domain\Policies"

Get-ChildItem -Path $policiesPath -Directory | ForEach-Object {
    $acl = Get-Acl -Path $_.FullName
    if ($acl.AreAccessRulesProtected) {
        [PSCustomObject]@{
            GPT               = $_.Name
            Path              = $_.FullName
            InheritanceBlocked = $true
        }
    }
} | Format-Table -AutoSize

Output vuoto è il risultato atteso. Se compaiono cartelle con InheritanceBlocked = True, verificare manualmente la motivazione e documentarla se legittima.

Affiancamento rapido dei due layer

Per avere Share e NTFS sullo stesso schermo durante una review:

$domain = $env:USERDNSDOMAIN

Write-Host "=== SHARE PERMISSIONS ===" -ForegroundColor Cyan
Get-SmbShareAccess -Name SYSVOL | Format-Table -AutoSize

Write-Host "=== NTFS ACL - Policies ===" -ForegroundColor Cyan
(Get-Acl -Path "\\$domain\SYSVOL\$domain\Policies").Access |
    Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited |
    Format-Table -AutoSize

Periodic review model

Una verifica una-tantum non è sufficiente. I permessi SYSVOL tendono a degradare nel tempo con ogni cambio operativo urgente, ogni nuova installazione di tool e ogni riorganizzazione del team.

Il modello consigliato prevederebbe almeno tre livelli:

Frequenza	Attività	Strumento
Settimanale	Confronto snapshot ACL con baseline salvata	PowerShell + file CSV di riferimento
Mensile	Review manuale inheritance break e account di servizio	PowerShell + AD review
Trimestrale	Revisione completa Share + NTFS + membership gruppi delegati	Assessment completo

Salvare uno snapshot della baseline

$domain      = $env:USERDNSDOMAIN
$policiesPath = "\\$domain\SYSVOL\$domain\Policies"
$snapshotDir  = "C:\ACL-Baseline"

if (-not (Test-Path $snapshotDir)) { New-Item -ItemType Directory -Path $snapshotDir | Out-Null }

$snapshotFile = Join-Path $snapshotDir "sysvol-policies-acl-$(Get-Date -Format 'yyyyMMdd').csv"

(Get-Acl -Path $policiesPath).Access |
    Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited |
    Export-Csv -Path $snapshotFile -NoTypeInformation -Encoding UTF8

Write-Host "Snapshot salvato: $snapshotFile"

Eseguire questo script prima di qualsiasi change e dopo ogni intervento. Il confronto tra due snapshot consecutivi evidenzia immediatamente variazioni non documentate.

Confrontare lo snapshot corrente con quello di riferimento

$baseline = Import-Csv "C:\ACL-Baseline\sysvol-policies-acl-<DATA_APPROVATA>.csv"
$current  = (Get-Acl -Path "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies").Access |
                Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited

Compare-Object -ReferenceObject $baseline -DifferenceObject $current `
    -Property IdentityReference, FileSystemRights, AccessControlType |
    Format-Table -AutoSize

Le righe con => indicano ACE presenti nel corrente ma non nel baseline (aggiunte). Le righe con <= indicano ACE rimosse. Entrambe richiedono verifica.

Per stabilire quali drift richiedano una correzione immediata e quali vadano prima approfonditi, consulta il framework per dare priorità ai finding di hardening Active Directory.

Criteri di remediation

La rimozione di un permesso su SYSVOL richiede attenzione perché può impattare:

• la replica DFSR tra Domain Controller;
• gli account di servizio che leggono script o GPT in produzione;
• i client che accedono a NETLOGON per logon script.

Prima di intervenire

1. Documentare la ACL corrente con uno snapshot.
2. Identificare il motivo per cui quel permesso esiste: potrebbe essere un tool attivo in produzione.
3. Verificare se l'identità è ancora attiva in AD (account non disabilitato, gruppo con membri reali).
4. Pianificare in change window. Mai su urgenza in produzione.
5. Testare su un singolo GPT prima di applicare alla radice Policies o all'intera gerarchia SYSVOL.

Rimozione di una ACE specifica

$domain        = $env:USERDNSDOMAIN
$targetPath    = "\\$domain\SYSVOL\$domain\Policies"
$targetAccount = "DOMINIO\OldServiceAccount"

$acl = Get-Acl -Path $targetPath

$acl.Access |
    Where-Object { $_.IdentityReference -eq $targetAccount } |
    ForEach-Object { $acl.RemoveAccessRule($_) | Out-Null }

Set-Acl -Path $targetPath -AclObject $acl
Write-Host "ACE rimossa per: $targetAccount"

Ripristino ereditarietà su una GPT

Se una cartella GPT ha l'ereditarietà disabilitata senza documentazione o motivazione valida:

$domain  = $env:USERDNSDOMAIN
$gptPath = "\\$domain\SYSVOL\$domain\Policies\{GUID-DA-SOSTITUIRE}"

$acl = Get-Acl -Path $gptPath
# SetAccessRuleProtection($false, $true): riabilita inheritance e preserva le ACE esplicite esistenti
$acl.SetAccessRuleProtection($false, $true)
Set-Acl -Path $gptPath -AclObject $acl

Write-Host "Inheritance ripristinato su: $gptPath"

Dopo il ripristino, verificare che la GPT riceva correttamente le ACL ereditate dalla radice e che le ACE esplicite rimaste siano quelle attese.

Non modificare le Share SYSVOL/NETLOGON senza un piano

Le share SYSVOL e NETLOGON sono esposte da tutti i DC del dominio. Una modifica ai permessi Share non si replica automaticamente via DFSR: va eseguita manualmente su ogni nodo o tramite uno script coordinato. Prima di qualsiasi intervento, verificare il comportamento atteso su un DC non critico in un ambiente di test o di staging.

Checklist di baseline

Prima di dichiarare la baseline conforme, verificare tutti i seguenti punti:

• Share SYSVOL: Everyone con Read. Nessun Change o Full Control per identità non di sistema.
• Share NETLOGON: stessa regola.
• NTFS radice SYSVOL: SYSTEM, Domain Admins, Enterprise Admins con Full Control.
• NTFS Policies\: Authenticated Users con solo Read & Execute. Nessun Write o Modify.
• Nessun account di servizio legacy con Write o Full Control non documentato.
• Nessuna GPT con inheritance disabilitato senza motivazione documentata.
• Nessun gruppo generico (Domain Users, Everyone, Pre-Windows 2000 Compatible Access) con Write o superiore.
• CREATOR OWNER con scope limitato a sottocartelle e file, non applicato alla cartella corrente.
• NT AUTHORITY\SYSTEM presente e con Full Control sulla radice SYSVOL.
• Snapshot ACL aggiornato salvato e conservato per confronto futuro.

Approfondisci

Questa guida è stata progettata per completarsi con altri articoli sulla sicurezza operativa di Active Directory:

• Audit permessi SYSVOL in Active Directory: come verificare chi può modificare davvero le GPO — Scenario reale di laboratorio che dimostra come il contenuto di un GPT può essere alterato anche quando la policy sembra in ordine in console GPMC.

• GPO Security Filtering vs Delegation in Active Directory: differenze critiche per audit e hardening — Come distinguere il targeting della policy (chi la riceve) dalla governance amministrativa (chi può modificarla).

Ti è stata utile questa guida? Se gli script PowerShell, il periodic review model o la metodologia di remediation ti hanno aiutato a mappare il drift nel tuo ambiente, condividi pure o lascia un like — serve agli altri che si trovano nella tua stessa situazione.

Approfondisci anche gli altri articoli sulla sicurezza operativa di Active Directory. Ogni pezzo è pensato per completare la visione e darti gli strumenti concreti per implementare un modello di governance GPO robusto.