Windows Server 2003 e 2008 - Come interpretare Access Control List in formato SDDL

Ciao a tutti! Durante il troubleshooting di problemi di varia natura, spesso ci capita di incorrere nel comune errore di Access Denied. L’utente non ha sufficienti permessi per eseguire l’operazione desiderata. In molti casi, ciò è causato da una incorretta configurazione dei permessi degli utenti sulle varie cartelle, specialmente quelle condivise in rete; è utile quindi sapere come fare a controllare queste impostazioni.

Oggi parleremo quindi di Access Control List (ACL). Semplicemente una ACL è una lista di tutti i permessi che i diversi utenti hanno su un particolare oggetto (tipicamente un file o una cartella). Ognuna delle righe di questa tabella, contenente i permessi per un particolare utente o gruppo, è definita ACE (Access Control Entry).

Possiamo sicuramente andare a controllare i vari permessi attraverso l’interfaccia grafica (da Explorer: tasto destro/proprietà/security ), ma in alcuni casi l’operazione potrebbe diventare complicata qualora gli utenti siano molti ed abbiano diversi livelli di accesso, nonchè permessi speciali, per i quali dovremo andare continuamente a consultare la schermata “advanced”.

Per questo motivo, esistono dei tool che ci permettono di esportare con facilità tutte le informazioni in formato testo. Ad esempio possiamo utilizzare cacls.exe oppure icacls.exe inserendo come parametro la cartella che vogliamo controllare. L’output sarà una lista degli utenti e i differenti livelli di permessi che hanno. AD esempio:

cacls C:\Windows

Tuttavia tali informazioni possono venirci recapitate anche in formato SDDL (Security Descriptor Definition Language). Possiamo visualizzare le stesse informazioni della schermata precedente in formato SDDL utilizzando lo switch /s di cacls.exe:

cacls C:\Windows /s

Come vedete, l’output è MOLTO più difficile da interpretare :) lo scopo di questo post sarà quindi fornirvi alcune linee guida per interpretare tali stringhe SDDL qualora non sia possibile disporre di altri dati più facilmente leggibili.

Per il nostro scopo utilizzeremo come esempio di riferimento (e cercheremo di decodificare) la stringa

D:PAI(A;;0x100081;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)

Innanzitutto, la D: iniziale è sempre presente e sta per DACL (Discretionary Access Control List). Può essere seguita da uno o più dei seguenti flags:

P = SDDL_PROTECTED (i permessi non possono essere ereditati da cartelle più in alto nella gerarchia)

AR = SDDL_AUTO_INHERIT_REQ (gli oggetti figli possono ereditare i permessi da questo oggetto su richiesta)

AI = SDDL_AUTO_INHERITED (gli oggetti figli ereditano i permessi da questo oggetto)

PAI = P + AI . In questa configurazione, gli accessi sono bloccati e limitati al singolo oggetto e non sono ereditati nè ereditabili (come nel caso del nostro esempio).

In seguito, contenuti tra parentesi tonde, saranno elencati tutti gli specifici ACE (Access Control Entry). Il formato è il seguente:

(<Tipo>;<Flags>;<Rights>;<GUID_oggetto>;<GUID_ereditato>;<SID_utente>)

Il Tipo di permesso può essere quello di accesso consentito (A) o negato (D). I Flags principali invece sono i seguenti:

CI = SDDL_CONTAINER_INHERIT (il permesso verrà ereditato dai container figli)

OI = SDDL_OBJECT_INHERIT (il permesso verrà ereditato dagli oggetti figli)

NP = SDDL_NO_PROPAGATE (il permesso non può essere propagato)

IO = SDDL_INHERIT_ONLY (il permesso non è applicato all’oggetto corrente ma solo ereditato)

ID = SDDL_INHERITED (il permesso è stato ereditato)

Per quanto riguarda i permessi veri e propri – <Rights> – possiamo trovarli espressi sia sotto forma di Access Mask che in forma testuale. L’Access Mask è una stringa di 32 bit, dove ogni bit corrisponde ad un particolare permesso (read, write, etc). Se intendiamo assegnare più di un permesso all’utente in questo particolare ACE, dobbiamo settare ad uno tutti i relativi bit (nella posizione corretta!). Per semplicità, è sufficiente riportare i valori esadecimali dei diversi permessi ed ottenerne la somma. La tabella completa è riportata al seguente link http://msdn.microsoft.com/en-us/library/cc246801(PROT.13).aspx.

Quindi, ad esempio, la stringa rights = 0x100081 corrisponde ai permessi di Synchronize (0x00100000), Read Attributes (0x00000080) e List Directory (0x00000001). è utile familiarizzare con il concetto di Access Mask, poichè i permessi vengono comunicati in questo modo ad esempio attraverso il protocollo SMB/SMB2.

Alternativamente possiamo trovare tutti i permessi espressi in forma testuale, di seguito i più comuni:

GA = all access (generic)

GR = read (generic)

GW = write (generic)

FA = all access (file)

FR = read (file)

FW = write (file)

Tralasciando la trattazione sui GUID, che esula dallo scopo di questo post, ci rimane da vedere solo il campo finale, nient’altro che il SID dell’utente a cui vengono applicati i permessi contenuti in questo ACE. Il SID identifica esplicitamente e in maniera univoca un utente (o un gruppo) locale o all’interno dell’Active Directory. Anche per questo campo, il parametro può essere espresso sotto forma di stringa, ad esempio abbiamo:

WD = Everyone

BA = Built-in Administrators

SY = System

AU = Authenticated Users

DA = Domain Administrators

DU = Domain Users

A questo link è presente una lista completa degli altri SID noti http://msdn.microsoft.com/en-us/library/aa379602.aspx

Riassumendo, in riferimento al nostro esempio abbiamo:

(A;;0x100081;;;AU) = Tutti gli utenti autenticati (AU) hanno un permesso di accesso consentito (A) alla cartella con permessi di Synchronize (0x00100000), Read Attributes (0x00000080) e List Directory (0x00000001).

(A;OICI;FA;;;SY) = L’utenza System (SY) ha un permesso di accesso consentito (A) che è stato ereditato (CI) e verrà propagato (OI), con permessi di full control sui files (FA)

(A;OICI;FA;;;BA) = Gli utenti che fanno parte del gruppo Built-in Administrators (BA) hanno un permesso di accesso consentito (A) che è stato ereditato (CI) e verrà propagato (OI), con permessi di full control sui files (FA)

Rimando infine a questo link per una trattazione dettagliata e completa di tutti gli altri parametri che non abbiamo approfondito in questo post http://technet.microsoft.com/en-us/library/aa374928(VS.85).aspx

Come sempre, grazie del tempo che avete dedicato alla lettura, nella speranza che possa esservi stata utile.

Ciao e alla prossima!

Stefano Gagliardi
Support Engineer
Microsoft Enterprise Platform Support