Windows Server 2016/2019: errore “You do not have permission to view or edit this object’s audit settings” sulla scheda Auditing – cause e soluzioni

Su Windows Server 2016/2019 può comparire l’errore “You do not have permission to view or edit this object’s audit settings” aprendo la scheda Auditing. Qui trovi cause, verifiche e procedure passo‑passo per sbloccare l’accesso e configurare correttamente le SACL.

Indice

Panoramica del problema

Su alcuni server (membri o controller di dominio) amministratori con Full Control sul file, sulla cartella o sull’unità non riescono comunque a visualizzare o modificare la scheda Auditing in Proprietà ▸ Sicurezza ▸ Avanzate. L’errore tipico è:

You do not have permission to view or edit this object’s audit settings

Il comportamento è sorprendente perché l’utente può essere perfino il proprietario dell’oggetto, riuscire a cambiare DACL e proprietà… ma l’auditing resta inaccessibile.

Perché Full Control non basta

La chiave è distinguere tra DACL e SACL:

DACL (Discretionary ACL): controlla chi può fare cosa sull’oggetto. Il proprietario può sempre ripristinare o cambiare la DACL.
SACL (System ACL): definisce cosa viene registrato nei log di sicurezza (successo/fallimento di accessi). La lettura/scrittura della SACL non dipende dalla DACL: è protetta dal privilegio SeSecurityPrivilege (Manage auditing and security log).

In pratica, anche con Full Control o con la proprietà, senza SeSecurityPrivilege attivo nel token la scheda Auditing non si apre.

Cause principali individuate

Mancanza del privilegio “Manage auditing and security log” (SeSecurityPrivilege) sul tuo account o sul gruppo di cui fai parte. Solo chi possiede questo diritto può leggere/modificare le SACL.
Privilegio presente ma non attivo nella sessione elevata. Con UAC abilitato, potresti operare con un token che non ha SeSecurityPrivilege abilitato o che non viene “alzato” dal processo che stai usando.
Eredità bloccata. Se l’oggetto o un contenitore antenato ha l’eredità disattivata/protetta, l’UI può non riuscire a calcolare le SACL effettive e non te le mostra.

Checklist rapida di risoluzione

Se hai poco tempo, segui nell’ordine questi controlli. Nella sezione successiva trovi la procedura completa, con comandi e script.

Passo	Azione	Percorso / Comando	Note operative
1	Verificare/assegnare `SeSecurityPrivilege`	`gpedit.msc` → Computer Configuration ▸ Windows Settings ▸ Security Settings ▸ Local Policies ▸ User Rights Assignment → Manage auditing and security log	Aggiungi il tuo account o un gruppo (es. Domain Admins, Backup Operators) e distribuisci via GPO se necessario.
2	Aprire uno strumento con token realmente elevato	Esegui CMD o PowerShell con Run as administrator e verifica con `whoami /priv` che `SeSecurityPrivilege` sia Enabled	Se il privilegio risulta Disabled, chiudi e riapri la sessione elevata; non affidarti a finestre lanciate da processi non elevati.
3	Controllare l’eredità delle ACL	Proprietà ▸ Sicurezza ▸ Avanzate → pulsante Enable inheritance (se presente)	L’eredità disattivata può spezzare i permessi necessari a visualizzare l’auditing.
4	Escludere interferenze UAC	(Facoltativo) Portare temporaneamente UAC su Never notify, riprovare, poi ripristinare	Se così funziona, affidati a sessioni realmente elevate o delega corretta del privilegio.
5	Delegare in modo granulare	Group Policy Management Console → GPO dedicata per Manage auditing and security log	Assegna il diritto solo ai team che ne hanno necessità.

Procedura dettagliata passo‑passo

Verificare e assegnare il privilegio SeSecurityPrivilege

Obiettivo: assicurarsi che l’account con cui operi possieda il diritto “Manage auditing and security log”.

Su server membri/stand‑alone:

Apri gpedit.msc.
Vai a Computer Configuration ▸ Windows Settings ▸ Security Settings ▸ Local Policies ▸ User Rights Assignment.
Apri Manage auditing and security log e aggiungi l’account o il gruppo idoneo (spesso Administrators, Domain Admins o Backup Operators per scenari di backup/audit).
Chiudi e applica: gpupdate /force oppure riavvio per sicurezza.

Su controller di dominio:

Apri Group Policy Management (gpmc.msc).
Modifica la GPO Default Domain Controllers Policy o, meglio, crea una GPO dedicata linkata all’OU Domain Controllers.
Stesso percorso: Computer Configuration ▸ Windows Settings ▸ Security Settings ▸ Local Policies ▸ User Rights Assignment → Manage auditing and security log.
Aggiungi i gruppi autorizzati (tipicamente Domain Admins/Enterprise Admins via Administrators built‑in) e mantieni la delega least privilege.
Forza il refresh: gpupdate /force su ciascun DC oppure attendi la replica.

Verifica da riga di comando (eseguire da una finestra elevata):

whoami /priv | findstr /I SeSecurityPrivilege

Se non compare, il privilegio non è assegnato. Se compare come Disabled, il token esecutivo non lo ha attivato; vedi la sezione successiva.

Aprire strumenti con un token realmente elevato

Con UAC attivo, anche gli amministratori lavorano spesso con un token ridotto; solo i processi lanciati con Run as administrator ottengono il token elevato. Alcune note pratiche:

Apri un Prompt dei comandi o Windows PowerShell con Run as administrator e lavora da lì.
Evita di aprire finestre di proprietà partendo da processi non elevati: l’UI eredita il token del processo padre.
Se l’UI continua a rifiutarsi, usa PowerShell per leggere o modificare direttamente la SACL (vedi più avanti).

Controllo immediato del token:

whoami /groups
whoami /priv

In whoami /priv verifica che SeSecurityPrivilege sia Enabled. Se risulta Disabled, chiudi l’applicazione e rilanciala con Run as administrator. In scenari particolari (es. desktop condiviso) può essere necessario disconnettersi e rientrare.

Controllare ed eventualmente ripristinare l’eredità

Una SACL “protetta” (eredità disattivata) può impedire all’UI di mostrare l’auditing. Controlla così:

Clic destro sull’oggetto → Proprietà ▸ Sicurezza ▸ Avanzate.
Se appare Enable inheritance, l’eredità è disabilitata: premi per riabilitarla.

Verifica via PowerShell (richiede un processo con SeSecurityPrivilege):

$path = 'D:\Dati'
$acl = [System.IO.Directory]::GetAccessControl($path, [System.Security.AccessControl.AccessControlSections]::Audit)
$acl.AreAuditRulesProtected  # True = eredità SACL disattivata

Riabilitare eredità SACL via PowerShell:

$path = 'D:\Dati'
$acl = [System.IO.Directory]::GetAccessControl($path, [System.Security.AccessControl.AccessControlSections]::Audit)
$acl.SetAuditRuleProtection($false, $true)  # disabilita la protezione e conserva le voci ereditate
[System.IO.Directory]::SetAccessControl($path, $acl)

Escludere interferenze di UAC per test mirato

Se sospetti che UAC stia impedendo l’abilitazione effettiva dei privilegi:

Imposta temporaneamente il cursore UAC su Never notify (Pannello di Controllo → Change User Account Control settings).
Disconnetti e ricollega la sessione amministrativa, riprova l’accesso alla scheda Auditing.
Ripristina subito la soglia UAC precedente al termine del test.

In ambienti bloccati, valuta criteri specifici di UAC (es. Admin Approval Mode) in Computer Configuration ▸ Windows Settings ▸ Security Settings ▸ Local Policies ▸ Security Options.

Delegare il privilegio in modo granulare

Per ridurre il rischio di eccessiva esposizione, assegna SeSecurityPrivilege solo ai team che ne hanno davvero bisogno (es. sicurezza, backup, forensics):

Apri Group Policy Management.
Crea una GPO dedicata (es. “Deleghe auditing”).
Configura Manage auditing and security log con i gruppi minimi necessari (gruppi di servizio, gruppi locali del server, ecc.).
Linka la GPO alle OU interessate (server, cluster, file server) e documenta la delega.

Strumenti e comandi utili

Controllare rapidamente la presenza del privilegio

whoami /priv | findstr /I SeSecurityPrivilege

Leggere e modificare la SACL via PowerShell

Esempio: aggiungere una voce di auditing che registra Success/Failure per DOMAIN\OperatoreAudit su una cartella e contenuti.

$path  = 'D:\Condivisa'
$user  = 'DOMAIN\OperatoreAudit'

Carica solo la sezione Audit

$acl = [System.IO.Directory]::GetAccessControl($path, [System.Security.AccessControl.AccessControlSections]::Audit)

Crea una regola di auditing per Modify su contenitore e oggetti figli

$inherit = [System.Security.AccessControl.InheritanceFlags]::ContainerInherit `         -bor [System.Security.AccessControl.InheritanceFlags]::ObjectInherit
$propagate = [System.Security.AccessControl.PropagationFlags]::None
$rights = [System.Security.AccessControl.FileSystemRights]::Modify
$auditFlags = [System.Security.AccessControl.AuditFlags]::Success`
-bor [System.Security.AccessControl.AuditFlags]::Failure

$rule = New-Object System.Security.AccessControl.FileSystemAuditRule($user, $rights, $inherit, $propagate, $auditFlags)

Applica la regola

$acl.AddAuditRule($rule)
[System.IO.Directory]::SetAccessControl($path, $acl)

Se ricevi “Attempted to perform an unauthorized operation”, il processo non possiede SeSecurityPrivilege o il privilegio non è attivo.

Esportare e ispezionare i privilegi assegnati tramite criteri

secedit /export /cfg C:\Temp\secpol.cfg
findstr /I "SeSecurityPrivilege" C:\Temp\secpol.cfg

Il valore elenca SID o nomi dei gruppi con il privilegio. Usa questa informazione per correggere le GPO.

Riparare eredità di SACL su alberi profondi

La GUI non sempre propaga bene su migliaia di sottocartelle. Con PowerShell puoi forzare lo sblocco dell’eredità su un intero albero:

$root = 'D:\Archivio'
Get-ChildItem -Path $root -Directory -Recurse | ForEach-Object {
  try {
    $acl = [System.IO.Directory]::GetAccessControl($_.FullName, [System.Security.AccessControl.AccessControlSections]::Audit)
    if ($acl.AreAuditRulesProtected) {
      $acl.SetAuditRuleProtection($false, $true)
      [System.IO.Directory]::SetAccessControl($_.FullName, $acl)
    }
  } catch {
    Write-Warning "Impossibile aggiornare $($.FullName): $($.Exception.Message)"
  }
}

Casi particolari e note di campo

Strumenti di backup. Il privilegio SeSecurityPrivilege è lo stesso usato dai motori di backup per leggere i log di sicurezza. Se un account di servizio riesce a leggere i log ma la tua UI non apre la scheda Auditing, con ogni probabilità stai operando con un token non elevato o in cui il privilegio non è stato abilitato.
Controller di dominio. Evita di lavorare con account standard promossi a Local Administrator tramite Restricted Groups: sui DC i gruppi locali sono rimpiazzati da gruppi di dominio built‑in e potresti non ereditare correttamente il privilegio.
ReFS / Scale‑Out File Server. In cluster, assicurati che tutti i nodi ricevano la stessa GPO con SeSecurityPrivilege. Incongruenze tra nodi portano a comportamenti intermittenti quando la proprietà si muove.
Desktop remoto multi‑hop. Se ti colleghi a un server A e da lì apri una sessione amministrativa su B, verifica i privilegi sul nodo effettivo dove stai operando (usa sempre whoami /priv sul server target).
Explorer e singola istanza. File Explorer è single‑instance: lanciare explorer.exe da un prompt elevato spesso non crea una nuova istanza elevata. Per attività sulle SACL preferisci PowerShell/CLI o tool MMC aperti con Run as administrator.
Operazioni come SYSTEM (opzione avanzata). In casi estremi, per audit forensics, puoi avviare una shell come Local System (ad es. con PsExec) che possiede SeSecurityPrivilege per definizione. Usa questa strada solo se approvata dalle tue policy interne.

Diagnostica guidata

Usa la seguente “alberatura” logica quando incontri l’errore:

Il tuo account ha il privilegio? Se whoami /priv non mostra SeSecurityPrivilege, assegnalo via GPO/Local Policy.
Il processo è elevato? Se il privilegio appare ma è Disabled, rilancia lo strumento con Run as administrator. Verifica di nuovo.
L’eredità è protetta? Se la scheda resta inaccessibile, controlla e riabilita l’eredità SACL.
Persistono anomalie? Prova a leggere la SACL via PowerShell. Se fallisce, il problema è sicuramente di token/privilegio.

Domande frequenti

Essere proprietario dell’oggetto dovrebbe bastare?

No. La proprietà consente di riprendere la DACL, non la SACL. La SACL richiede SeSecurityPrivilege.

Quali gruppi hanno il privilegio per impostazione predefinita?

In generale il gruppo Administrators lo possiede; sui DC i membri di Domain Admins/Enterprise Admins ne beneficiano tramite appartenenza. Può variare secondo le policy della tua organizzazione.

Posso usare ICACLS per configurare l’auditing?

icacls gestisce principalmente la DACL. Per SACL usa PowerShell/.NET come mostrato, oppure la GUI quando funzionante.

Perché `whoami /priv` mostra il privilegio ma come Disabled?

Significa che il token del processo ha il privilegio disponibile ma non abilitato. La maggior parte delle UI lo abilita automaticamente quando necessario; se non accade, rilancia l’applicazione in modo elevato (o usa PowerShell).

È sicuro disattivare temporaneamente UAC?

Solo per test mirati e su server non esposti. Ripristina immediatamente la configurazione e preferisci sempre l’esecuzione elevata di singoli strumenti.

Best practice operative

Documenta chiaramente quali gruppi possiedono SeSecurityPrivilege nelle tue GPO.
Separa i ruoli: auditing/forensics, backup e amministrazione quotidiana dovrebbero avere privilegi distinti.
Automatizza i controlli con script che verificano whoami /priv, AreAuditRulesProtected e che esportano la secedit.
Valida regolarmente la coerenza sui nodi di cluster e file server.

Esempio completo di script diagnostico

Lo script seguente controlla privilegi, stato eredità e capacità di leggere la SACL su un set di percorsi. Eseguilo da PowerShell elevato.

# Parametri
$Paths = @('D:\Condivisa', 'E:\Progetti')

1) Verifica privilegio

$hasPriv = (whoami /priv | Select-String -Pattern 'SeSecurityPrivilege') -ne $null
if (-not $hasPriv) {
Write-Warning 'Il token corrente NON contiene SeSecurityPrivilege. Assegna il diritto o rilancia la sessione.'
}

foreach ($p in $Paths) {
Write-Host "==> Verifica: $p"
try {
$acl = [System.IO.Directory]::GetAccessControl($p, [System.Security.AccessControl.AccessControlSections]::Audit)
$prot = $acl.AreAuditRulesProtected
Write-Host "  - Lettura SACL: OK"
Write-Host ("  - Eredità SACL protetta: {0}" -f $prot)
$rules = $acl.GetAuditRules($true,$true,[System.Security.Principal.NTAccount])
if ($rules.Count -eq 0) {
Write-Host "  - Nessuna voce di auditing presente"
} else {
Write-Host ("  - Voci di auditing: {0}" -f $rules.Count)
$rules | ForEach-Object {
Write-Host ("     {0} {1} {2}" -f $.IdentityReference, $.FileSystemRights, $.AuditFlags)
}
}
} catch {
Write-Warning ("  - Errore: {0}" -f $*.Exception.Message)
}
}

Errori comuni e come evitarli

Aggiungere l’utente agli Administrators locali e fermarsi lì. Senza il diritto esplicito Manage auditing and security log potresti non accedere all’auditing.
Aprire la finestra Proprietà da un processo non elevato. L’UI eredita il token e fallisce nonostante l’account abbia i diritti.
Ignorare l’eredità. Oggetti con protezione attiva sulle SACL possono confondere la GUI e bloccare la visualizzazione.
Non controllare tutti i nodi. In cluster/SoFS, un solo nodo fuori allineamento GPO può generare errori intermittenti.

Riepilogo operativo

Per accedere alla scheda Auditing serve obbligatoriamente il diritto Manage auditing and security log (SeSecurityPrivilege) attivo nel token del processo e una sessione realmente elevata. Assegna il privilegio via GPO, apri gli strumenti con Run as administrator e verifica che l’eredità non sia bloccata. In queste condizioni la scheda diventa immediatamente accessibile e le SACL possono essere lette/modificate in sicurezza.

Appendice di riferimento

Mappa mentale dei percorsi di configurazione

Assegnazione diritti utente: Computer Configuration ▸ Windows Settings ▸ Security Settings ▸ Local Policies ▸ User Rights Assignment → Manage auditing and security log.
Opzioni UAC: Computer Configuration ▸ Windows Settings ▸ Security Settings ▸ Local Policies ▸ Security Options.
UI SACL: Proprietà ▸ Sicurezza ▸ Avanzate ▸ Auditing.

Guida decisionale rapida

Sintomo	Causa probabile	Azione immediata
Errore di accesso alla scheda Auditing	Mancanza di `SeSecurityPrivilege`	Assegna via GPO/Local Policy e rilancia sessione elevata
`whoami /priv` mostra il privilegio ma Disabled	Processo non elevato o UAC che limita l’abilitazione	Apri lo strumento con Run as administrator
Scheda ancora inaccessibile su alcune directory	Eredità SACL protetta/bloccata	Riabilita eredità dalla GUI o via PowerShell
Comportamento intermittente in cluster	GPO incoerenti tra nodi	Verifica applicazione criteri su tutti i nodi

Conclusioni

Il messaggio “You do not have permission to view or edit this object’s audit settings” non è un problema di proprietà o di “pieno controllo”, ma un chiaro indicatore che il processo in uso non dispone del privilegio specifico per gestire le SACL o che l’eredità è stata protetta. Con un mix di deleghe corrette (GPO), sessioni elevate e verifiche mirate via CLI/PowerShell, la scheda Auditing torna immediatamente utilizzabile e l’infrastruttura resta allineata ai principi di least privilege e tracciabilità.

Suggerimenti aggiuntivi

Il privilegio SeSecurityPrivilege è lo stesso richiesto da strumenti di backup (ad es. wbadmin) per salvare i log di sicurezza: se un account di servizio riesce a leggere i log ma non ad accedere alla scheda Auditing, il problema è quasi sempre UAC o un token non elevato.
Su controller di dominio, soltanto gruppi amministrativi di alto livello lo possiedono per impostazione predefinita: evita di operare con account standard promossi a Local Administrator tramite Restricted Groups sul DC, perché non erediteranno automaticamente il privilegio appropriato.
Se il problema riguarda oggetti su volumi ReFS o su condivisioni Scale‑Out File Server, verifica che tutti i nodi del cluster abbiano coerentemente ricevuto la GPO con SeSecurityPrivilege.

In sintesi
Per vedere o modificare la scheda Auditing serve obbligatoriamente il diritto Manage auditing and security log attivo nel token dell’utente e un avvio con privilegi elevati. Assicurati che l’account (o il gruppo) abbia quel privilegio tramite GPO, poi apri Esplora risorse o—meglio—una console MMC/PowerShell come Administrator; in assenza di eredità bloccata, la scheda diventerà immediatamente accessibile.