• Guide, Sicurezza, Sistemi Operativi
• 2 Aprile 2026

Il Dynamic Access Control (DAC) rappresenta una delle funzionalità più interessanti introdotte per migliorare la gestione dell’accesso ai dati nei file server basati su Windows. In ambienti aziendali moderni, infatti, non è più sufficiente controllare l’accesso ai file utilizzando esclusivamente ACL NTFS o gruppi di sicurezza tradizionali: le organizzazioni richiedono un controllo più dinamico, basato su attributi dell’utente, del dispositivo e delle risorse.

Il DAC nasce proprio con questo obiettivo: definire criteri centralizzati per l’accesso ai dati, applicati in modo coerente su più file server, riducendo la complessità amministrativa e migliorando il livello di sicurezza complessivo.

Questa funzionalità è stata introdotta per la prima volta con Windows Server 2012 ed è strettamente integrata con Active Directory Domain Services, il File Server Resource Manager e le funzionalità di classificazione dei file. Il suo utilizzo consente di implementare un modello di sicurezza più evoluto rispetto ai tradizionali permessi statici.

A cosa serve il Dynamic Access Control

Utilizzando il Dynamic Access Control potete:

• applicare criteri di accesso centralizzati basati su attributi
• classificare automaticamente i file in base al contenuto o alla posizione
• utilizzare claim-based access per utenti e dispositivi
• implementare criteri di auditing avanzati
• testare le policy in modalità staging prima della distribuzione in produzione

L’elemento chiave è che l’accesso non viene più determinato solo da “chi siete”, ma anche da contesto, dispositivo utilizzato e classificazione del dato.

Vantaggi principali

Il Dynamic Access Control introduce diversi vantaggi operativi:

Il primo riguarda la centralizzazione della sicurezza. Potete definire le regole una sola volta e applicarle a più file server, evitando configurazioni manuali ripetitive.

Il secondo è la maggiore granularità. Potete controllare l’accesso in base a attributi come reparto, ruolo, livello di sicurezza del documento o stato del dispositivo.

Un altro vantaggio importante è la possibilità di simulare le policy prima di renderle effettive, riducendo il rischio di bloccare utenti legittimi.

Considerate anche che il DAC migliora la compliance normativa, permettendovi di classificare i dati sensibili e applicare criteri coerenti con le policy aziendali.

Quando utilizzare il Dynamic Access Control

Il DAC è particolarmente utile quando:

• gestite grandi ambienti con molti file server
• dovete proteggere dati sensibili
• volete ridurre la gestione manuale delle ACL
• dovete applicare criteri basati su attributi di utenti e dispositivi
• avete necessità di auditing avanzato sugli accessi

Claims nel Dynamic Access Control

Uno degli elementi fondamentali del Dynamic Access Control è rappresentato dai Claims. I claims consentono di arricchire il processo di autorizzazione utilizzando attributi dinamici associati a utenti e computer, permettendovi di superare il tradizionale modello basato esclusivamente su gruppi di sicurezza.

In altre parole, invece di concedere l’accesso solo perché un utente appartiene a un gruppo, potete autorizzare l’accesso in base a proprietà specifiche, come il reparto, la sede o il livello di sicurezza del dispositivo.

Cosa sono i Claims

I Claims sono informazioni aggiuntive incluse nel token Kerberos dell’utente o del computer durante l’autenticazione. Queste informazioni vengono poi utilizzate per valutare le Central Access Rules definite nel Dynamic Access Control.

Quando un utente effettua il logon, Active Directory aggiunge al token non solo i gruppi di sicurezza, ma anche i claims configurati. Il file server utilizza queste informazioni per determinare se l’accesso deve essere consentito o negato.

User Claims

Gli User Claims sono attributi associati agli oggetti utente in Active Directory. Vengono utilizzati per prendere decisioni basate sulle caratteristiche dell’utente.

Esempi tipici di User Claims includono:

• Reparto (Department)
• Ruolo (Title)
• Paese (Country)
• Livello di sicurezza (Security Clearance)

Supponiamo, ad esempio, di voler consentire l’accesso a una cartella solo agli utenti del reparto Finance. Potete creare una regola che verifica il valore del claim Department invece di creare e mantenere manualmente gruppi dedicati.

Quando l’utente effettua l’accesso al dominio, il Domain Controller legge gli attributi dell’utente in Active Directory. Questi attributi vengono trasformati in claims e inseriti nel token Kerberos. Quando l’utente accede al file server, il server valuta i claims e applica la Central Access Policy.

Computer Claims

I Computer Claims funzionano in modo analogo, ma si basano sugli attributi degli oggetti computer in Active Directory. Questo vi consente di controllare l’accesso anche in base al dispositivo utilizzato.

Esempi comuni di Computer Claims:

• Posizione del computer (es. sede)
• Tipo di dispositivo
• Sistema operativo
• Stato di sicurezza
• Appartenenza a OU specifiche

Un caso tipico è consentire l’accesso a documenti sensibili solo se l’utente utilizza un computer aziendale. Anche se l’utente è autorizzato, l’accesso può essere negato se si connette da un dispositivo non conforme.

Il funzionamento è simile agli User Claims: durante l’autenticazione del computer, il Domain Controller aggiunge al token le informazioni relative al dispositivo. Quando l’utente accede al file server, il server valuta sia i User Claims sia i Computer Claims, permettendovi di creare regole combinate.

Utilizzo combinato di User e Computer Claims

Uno dei punti di forza del Dynamic Access Control è proprio la possibilità di combinare entrambe le informazioni. Potete creare regole come:

• L’utente appartiene al reparto Research
• Il computer è un dispositivo aziendale
• Il file è classificato come Confidenziale

Solo se tutte le condizioni sono soddisfatte, l’accesso viene consentito.

Questo approccio introduce un modello di controllo contestuale, molto più potente rispetto ai permessi statici NTFS.

Resource Properties nel Dynamic Access Control

Le Resource Properties rappresentano gli attributi associati alle risorse, in particolare ai file e alle cartelle, e costituiscono uno degli elementi fondamentali del Dynamic Access Control. Se i User Claims e i Computer Claims descrivono chi accede, le Resource Properties descrivono invece a cosa si sta accedendo.

In pratica, le Resource Properties permettono di classificare i dati aggiungendo metadati ai file. Queste informazioni vengono poi utilizzate nelle Central Access Rules per determinare se l’accesso deve essere consentito o negato.

Ad esempio, potete definire Resource Properties come:

• Livello di confidenzialità
• Tipo di documento
• Reparto proprietario
• Data classification
• Informazioni sensibili

Una volta definite, queste proprietà possono essere applicate manualmente oppure automaticamente tramite la File Classification Infrastructure (FCI) del File Server Resource Manager.

Come funzionano

Il funzionamento è piuttosto diretto. Quando un file viene classificato con una Resource Property, questa informazione viene salvata come metadato NTFS. Durante la richiesta di accesso, il file server confronta gli User Claims, i Computer Claims e le Resource Properties del file.

Se le condizioni definite nella Central Access Rule sono soddisfatte, l’accesso viene consentito; in caso contrario viene negato.

Un esempio protrebbe essere definire una regola che consente l’accesso solo se l’utente appartiene al reparto Research, il file ha Resource Property “Confidenziale” e il computer è aziendale.

Questo modello consente un controllo basato sul contenuto del dato, rendendo la gestione delle autorizzazioni molto più flessibile rispetto ai tradizionali permessi NTFS.

Perché sono importanti

Le Resource Properties sono fondamentali perché permettono di classificare i dati in modo strutturato, applicare criteri di accesso basati sul contenuto, supportare requisiti di compliance e data governance e automatizzare la protezione delle informazioni sensibili.

Nel contesto del Dynamic Access Control, le Resource Properties completano il modello basato su claims, consentendovi di implementare un sistema di autorizzazione realmente dinamico e contestuale.

Prerequisiti per il Dynamic Access Control

Per poter implementare il Dynamic Access Control è necessario che l’infrastruttura soddisfi alcuni requisiti fondamentali. Questa funzionalità è stata introdotta con Windows Server 2012, pertanto richiede un ambiente Active Directory aggiornato e file server compatibili.

Il primo requisito riguarda il livello funzionale del dominio, che deve essere almeno Windows Server 2012, necessario per supportare i claims, le Central Access Policies e le Resource Properties.

È inoltre necessario utilizzare file server basati su Windows Server 2012 o successivi, perché solo queste versioni sono in grado di valutare le Central Access Rules durante il controllo degli accessi. I client possono essere Windows 8 o versioni successive per sfruttare pienamente i Computer Claims, anche se il DAC può funzionare in modalità parziale con client precedenti.

Un altro elemento importante è la presenza del File Server Resource Manager, utile per la classificazione dei file e l’utilizzo delle Resource Properties, anche se non è obbligatorio per configurazioni di base.

È inoltre richiesta una corretta configurazione della replica Active Directory, poiché i componenti del Dynamic Access Control vengono distribuiti tramite AD e devono essere disponibili in tutto il dominio.

Preparazione dell’ambiente

Ho creato il dominio adatum.com e aggiunto il server LON-SVR7, che utilizzerò come File Server, insieme al client LON-CL1.

Figura 1: Ambiente di lavoro

Successivamente ho creato una Organizational Unit dedicata ai sistemi che saranno coinvolti nella configurazione del Dynamic Access Control. In questo modo potete applicare in maniera mirata le Group Policy necessarie senza impattare l’intero dominio.

All’interno della OU DAC-Protected ho spostato sia il client sia il file server che utilizzerò per i test. Questo approccio consente di isolare i sistemi che devono ricevere le configurazioni relative ai claims, alla compound authentication e al Kerberos armoring.

Questa operazione è importante perché le configurazioni del Dynamic Access Control vengono distribuite tramite Group Policy; applicarle a una OU dedicata vi permette di controllare con precisione i sistemi coinvolti nel laboratorio ed evitare effetti collaterali sugli altri computer del dominio.

Figura 2: Creazione della OU DAC-Protected e inserimento dei computer LON-CL1 e LON-SVR7 nell’Active Directory Administrative Center

Per completare la preparazione dell’ambiente ho configurato anche l’appartenenza del computer LON-CL1 al gruppo IT Workstations. Questo passaggio è utile perché consente di utilizzare l’appartenenza a gruppi come attributo del dispositivo, che potrà essere sfruttato successivamente nei Computer Claims del Dynamic Access Control.

Figura 3: Configurazione dell’appartenenza del computer LON-CL1 al gruppo IT Workstations nell’Active Directory Administrative Center

Per la demo ho utilizzato l’utente Nicola Ferrini, configurandone l’appartenenza al dipartimento Research. Questo passaggio è importante perché l’attributo Department verrà utilizzato come User Claim nelle regole del Dynamic Access Control, consentendo di controllare l’accesso alle risorse in base al reparto di appartenenza.

Nella figura sotto viene mostrata la console Active Directory Users and Computers con la finestra delle proprietà dell’utente Nicola Ferrini. Nella scheda Organization è visibile il campo Department valorizzato con Research.

Configurando correttamente questo attributo, sarà possibile creare regole del tipo: consentire l’accesso solo agli utenti appartenenti al dipartimento Research, indipendentemente dai gruppi di sicurezza tradizionali.

Figura 4: Configurazione dell’attributo Department per l’utente Nicola Ferrini in Active Directory Users and Computers

Support Dynamic Access Control and Kerberos Armoring

Per iniziare il laboratorio è necessario abilitare il supporto ai claims all’interno di Active Directory. Questo passaggio è fondamentale perché il Key Distribution Center (KDC) deve essere in grado di includere nel ticket Kerberos le informazioni relative a User Claims e Computer Claims, che verranno poi utilizzate dal file server per le decisioni di accesso.

Questa configurazione viene eseguita tramite Group Policy, applicando l’impostazione ai Domain Controller. L’obiettivo è attivare il supporto per Dynamic Access Control, Compound Authentication e Kerberos Armoring, elementi necessari per il corretto funzionamento del DAC.

Procedura

Accedete al Domain Controller (il mio si chiama LON-DC1) e aprite la Group Policy Management Console, quindi modificate la Default Domain Controllers Policy. All’interno dell’editor dei criteri di gruppo dovete navigare nel seguente percorso:

Computer Configuration → Policies → Administrative Templates → System → KDC

In questo nodo trovate l’impostazione Support Dynamic Access Control and Kerberos Armoring, che consente di attivare il supporto ai claims e alla protezione Kerberos.

Questa policy può essere configurata con diverse opzioni:

• disabilitare completamente il supporto DAC
• abilitare il supporto in ambienti misti
• Always provide claims
• richiedere autenticazione Kerberos armorizzata

Selezionate l’opzione Enabled con Always provide claims, in modo da garantire che i Domain Controller forniscano sempre i claims durante l’autenticazione.

Dopo aver configurato la policy, è necessario aggiornare i criteri di gruppo eseguendo il comando gpupdate /force

Figura 5: Abilitazione della policy KDC support for claims, compound authentication and Kerberos armoring con opzione Always provide claims nella Default Domain Controllers Policy

Configurazione degli User e Device Claims

Per definire gli User Claims e i Device Claims ho utilizzato l’Active Directory Administrative Center, accedendo al nodo Dynamic Access Control. In questa sezione sono disponibili tutti gli elementi necessari per la configurazione del Dynamic Access Control, tra cui Claim Types, Resource Properties, Resource Property Lists e le Central Access Policies.

Nella figura sotto è visibile il nodo Dynamic Access Control con la voce Claim Types selezionata. Da questa sezione è possibile definire i claims basati sugli attributi degli utenti e dei computer.

Figura 6: Nodo Dynamic Access Control – Claim Types nell’Active Directory Administrative Center

Per utilizzare l’attributo del reparto all’interno del Dynamic Access Control, ho creato un Claim Type basato sull’attributo Department di Active Directory. In questo modo il valore del dipartimento degli utenti potrà essere utilizzato come User Claim nelle regole di accesso.

Dalla finestra Create Claim Type nell’Active Directory Administrative Center ho selezionato come Source Attribute il campo department ed il claim è stato reso disponibile sia per la classe User che per la classe Computer.

Nella sezione Suggested Values ho definito i valori IT e Research, che rappresentano i dipartimenti utilizzati nell’ambiente. Questa configurazione consente di standardizzare i valori del claim e di utilizzarli in modo coerente nelle Central Access Rules del Dynamic Access Control.

Figura 7: Creazione del Claim Type Company department basato sull’attributo Department con valori suggeriti IT e Research

Figura 8: Claim Type Company department creato e visibile nella sezione Claim Types del Dynamic Access Control

Oltre al claim basato sul Department, è possibile creare ulteriori Claim Types utilizzando qualsiasi attributo disponibile in Active Directory. Questo consente di costruire regole di accesso molto più granulari e adattate alle esigenze dell’organizzazione.

Nella figura sotto è mostrata la creazione di un nuovo Claim Type basato sull’attributo description. Il claim è stato reso disponibile per la classe Computer, così da poter utilizzare il valore della descrizione dei computer come Device Claim.

Questo approccio dimostra come sia possibile creare tutti i claim necessari partendo dagli attributi presenti in Active Directory. Ad esempio potete utilizzare attributi e informazioni dei computer per definire policy di accesso più dinamiche e contestuali.

Figura 9: Creazione di un Claim Type basato sull’attributo description per l’utilizzo come Device Claim

Figura 10: Claim Type description creato e visibile nell’elenco dei Claim Types del Dynamic Access Control

Configurazione delle Resource Properties

Per utilizzare la classificazione dei file nel Dynamic Access Control, ho configurato le Resource Properties, che consentono di associare metadati alle risorse e utilizzarli nelle Central Access Rules.

Nella figura sotto viene mostrato l’Active Directory Administrative Center nel nodo Dynamic Access Control → Resource Properties. Tra le proprietà disponibili è presente Department, inizialmente in stato Disabled. Ho selezionato questa proprietà e l’ho abilitata scegliendo Enable dal menu contestuale.

L’abilitazione della Resource Property Department consente di utilizzarla per classificare file e cartelle in base al reparto di appartenenza. Questo valore potrà essere confrontato con il User Claim configurato in precedenza, permettendo di creare regole di accesso dinamiche basate sulla corrispondenza tra reparto dell’utente e reparto associato alla risorsa.

Ho abilitato anche la proprietà Confidentiality.

Figura 11: Abilitazione della Resource Property Department nella sezione Resource Properties del Dynamic Access Control

Dopo aver abilitato la Resource Property Department, ho configurato i valori che verranno utilizzati per la classificazione delle risorse.

Nella figura sotto è mostrata la configurazione della Resource Property Department. Nella sezione Suggested Values ho selezionato Add e ho aggiunto il valore Research, impostando sia Value sia Display name con lo stesso valore. Dopo aver inserito le informazioni ho confermato con OK per rendere disponibile il nuovo valore.

Questa configurazione consente di classificare file e cartelle assegnando il reparto Research, che potrà essere confrontato con il claim dell’utente durante la valutazione delle Central Access Rules del Dynamic Access Control.

Figura 12: Aggiunta del valore Research tra i Suggested Values della Resource Property Department

Figura 13: Valore Research aggiunto e visibile tra i Suggested Values della Resource Property Department

Global Resource Property List

Dopo aver configurato le Resource Properties, è necessario renderle disponibili ai file server tramite una Resource Property List. A questo scopo ho utilizzato la Global Resource Property List, che rappresenta l’elenco globale delle proprietà utilizzabili per la classificazione delle risorse.

Nella figura sotto è visibile l’Active Directory Administrative Center nel nodo Dynamic Access Control → Resource Property Lists. È presente la Global Resource Property List, che contiene le Resource Properties che possono essere distribuite ai file server. Questa lista viene utilizzata per pubblicare le proprietà configurate e renderle disponibili durante la classificazione dei file.

Figura 14: Visualizzazione della Global Resource Property List nel nodo Resource Property Lists del Dynamic Access Control

Dopo aver abilitato le Resource Properties, ho verificato che fossero presenti nella Global Resource Property List. Questo controllo è necessario perché solo le proprietà incluse in questa lista vengono rese disponibili ai file server per la classificazione delle risorse.

Dalla finestra Global Resource Property List, nella sezione Resource Properties, sono visibili sia la proprietà Department sia Confidentiality, già presenti nell’elenco. Questo conferma che, dopo l’abilitazione, le proprietà sono automaticamente incluse nella lista globale e rese disponibili per la classificazione delle risorse.

Figura 15: Verifica della presenza delle Resource Properties Department e Confidentiality nella Global Resource Property List

Implementazione della File Classification

Per utilizzare le Resource Properties sui file è necessario installare sui File Server il componente File Server Resource Manager, che fornisce le funzionalità di File Classification Infrastructure utilizzate dal Dynamic Access Control.

Nella figura sotto è mostrata la procedura di installazione tramite Server Manager sul server LON-SVR7 (che ho utilizzato come File Server). All’interno del wizard Add Roles and Features ho selezionato File and Storage Services, quindi File and iSCSI Services e ho abilitato il ruolo File Server Resource Manager.

Una volta installato, il File Server Resource Manager permette di assegnare manualmente o automaticamente le proprietà alle risorse, rendendo possibile l’applicazione delle policy del Dynamic Access Control basate sulla classificazione dei dati.

Figura 16: Installazione del ruolo File Server Resource Manager

Dopo l’installazione del File Server Resource Manager, ho aggiornato la console per verificare la disponibilità delle Resource Properties configurate in Active Directory. Questo passaggio consente di confermare che le proprietà siano state correttamente pubblicate e rese disponibili sul file server.

Nella figura sotto è mostrata la console File Server Resource Manager nella sezione Classification Management → Classification Properties. Dopo aver aggiornato la schermata, sono visibili le proprietà Confidentiality e Department con Scope Global, segno che le Resource Properties abilitate in Active Directory sono state correttamente replicate al file server.

Figura 17: Visualizzazione delle Resource Properties Confidentiality e Department nel File Server Resource Manager dopo l’aggiornamento della console

Per applicare la classificazione ai file ho creato una Classification Rule utilizzando il File Server Resource Manager. Le Classification Rule permettono di assegnare automaticamente delle Resource Properties a file e cartelle, rendendo possibile l’utilizzo del Dynamic Access Control basato sui metadati.

Nella figura sotto è mostrata la finestra Create Classification Rule. Nella scheda Scope ho definito l’ambito della regola, specificando la cartella C:\Projects come percorso su cui applicare la classificazione. In questo modo tutti i file contenuti in questa directory possono essere analizzati e classificati secondo i criteri definiti nella regola.

Una Classification Rule consente quindi di identificare i file da classificare, assegnare automaticamente una Resource Property e applicare criteri coerenti su intere strutture di cartelle.

Questo meccanismo è fondamentale perché il Dynamic Access Control utilizza proprio queste proprietà per determinare l’accesso alle risorse in base ai claims degli utenti e dei computer.

Figura 18: Creazione di una Classification Rule con scope impostato sulla cartella C:\Projects

Per classificare automaticamente i file ho configurato la Classification Rule utilizzando il metodo Content Classifier. Questo approccio consente di analizzare il contenuto dei file e assegnare una Resource Property quando vengono trovati determinati valori o pattern.

Nella figura sotto è mostrata la scheda Classification della regola. Ho selezionato il metodo Content Classifier, che permette di esaminare il contenuto dei file alla ricerca di stringhe specifiche. Come proprietà da assegnare ho scelto Confidentiality, impostando il valore High, in modo che i file contenenti determinate informazioni vengano classificati automaticamente come altamente confidenziali.

Attraverso il pulsante Configure ho definito i Classification Parameters, specificando la stringa secret da ricercare all’interno dei file. Quando il motore di classificazione individua questa parola, assegna automaticamente la proprietà Confidentiality = High ai file presenti nella cartella configurata.

Questo meccanismo consente di implementare una classificazione automatica dei dati, fondamentale per applicare successivamente regole di accesso dinamiche basate sul livello di confidenzialità delle informazioni.

Figura 19: Configurazione di una Classification Rule con metodo Content Classifier per assegnare automaticamente la proprietà Confidentiality = High ai file contenenti la stringa “secret”

Dopo aver configurato la regola, ho verificato che fosse presente nell’elenco delle Classification Rules e ho avviato manualmente il processo di classificazione per applicarla ai file della cartella configurata.

Dal riquadro Actions ho avviato l’opzione Run Classification With All Rules Now, che esegue immediatamente il motore di classificazione senza attendere l’esecuzione pianificata.

Questa operazione analizza i file presenti nel percorso configurato e assegna automaticamente le Resource Properties in base ai criteri definiti nella regola. In questo modo i file vengono classificati e diventano immediatamente utilizzabili dalle policy del Dynamic Access Control.

Figura 20: Regola di classificazione creata e avvio manuale della classificazione tramite Run Classification With All Rules Now

Dopo l’esecuzione della classificazione, il File Server Resource Manager genera automaticamente un report che consente di verificare i risultati dell’analisi e controllare quali file sono stati classificati.

Nella figura sotto è mostrato l’Automatic Classification Report generato al termine della classificazione. Il report riporta il percorso analizzato, in questo caso C:\Projects, e fornisce diverse sezioni riepilogative come Size by Owner, Size by File Group e Size by Property.

Nella parte inferiore è visibile il dettaglio dei file classificati, dove viene indicata la proprietà assegnata. Nel laboratorio il file presente nella cartella è stato classificato con Confidentiality = High, in base alla regola configurata in precedenza. Questo conferma che la Classification Rule ha individuato correttamente il contenuto e ha applicato la proprietà prevista.

Il report rappresenta uno strumento importante perché consente di validare il processo di classificazione automatica prima di applicare le policy di accesso del Dynamic Access Control.

Figura 21: Report di classificazione automatica generato dal File Server Resource Manager con il dettaglio dei file classificati e della proprietà Confidentiality assegnata

Per verificare l’applicazione della classificazione ho controllato direttamente le proprietà del file nella cartella configurata. Questo consente di confermare che la Classification Rule abbia assegnato correttamente la Resource Property.

Nella figura sotto sono mostrate le proprietà del file Project Ferrini. Nella scheda Classification è visibile la proprietà Confidentiality impostata su High, assegnata automaticamente dal File Server Resource Manager in base alla regola configurata. La proprietà Department non risulta valorizzata, poiché non è stata definita alcuna regola di classificazione per questo attributo.

Questa verifica conferma che la classificazione automatica è stata applicata correttamente.

Figura 22: Verifica della proprietà Confidentiality = High assegnata automaticamente al file nella scheda Classification

Oltre alla classificazione automatica, è possibile assegnare manualmente le Resource Properties direttamente dalle proprietà del file. Questo approccio è utile quando si desidera classificare singoli file senza creare una regola automatica.

Nella figura sotto sono mostrate le proprietà del file Project Ferrini nella scheda Classification. Ho selezionato manualmente la proprietà Department, scegliendo il valore Research tra quelli disponibili. I valori visualizzati derivano dalla Resource Property configurata in Active Directory e resa disponibile tramite il File Server Resource Manager.

Figura 23: Assegnazione manuale della proprietà Department selezionando il valore Research dalla scheda Classification del file

Configurazione delle Central Access Rules

Le Central Access Rules rappresentano l’elemento con cui si definiscono le condizioni di accesso basate sugli attributi del Dynamic Access Control. Consentono di costruire regole che valutano contemporaneamente le proprietà dei file, i claims degli utenti e, se necessario, anche quelli dei computer.

Non sono obbligatorie per l’accesso ai file, perché i permessi NTFS tradizionali continuano a funzionare normalmente. Tuttavia diventano necessarie quando si vuole implementare un modello di autorizzazione basato sugli attributi, evitando di gestire manualmente numerosi gruppi di sicurezza. In pratica, le Central Access Rules non sostituiscono i permessi NTFS, ma li affiancano aggiungendo un ulteriore livello di controllo.

Il principale vantaggio è la possibilità di definire criteri centralizzati e dinamici. Questo approccio semplifica la gestione delle autorizzazioni, riduce il numero di gruppi necessari e rende il controllo degli accessi più flessibile, soprattutto in ambienti con grandi quantità di dati classificati.

Figura 24: Central Access Rules nell’Active Directory Administrative Center

Per definire il comportamento della regola ho configurato le condizioni che determinano a quali risorse applicare i permessi. In questo caso ho creato una regola basata sulla proprietà Department.

Nella figura sotto è mostrata la creazione della Central Access Rule denominata Department Match. Nella sezione Target Resources ho definito una condizione selezionando Resource → Department → Equals → Research. In questo modo la regola verrà applicata solo alle risorse classificate con il valore Department = Research.

Questa configurazione consente di limitare l’ambito della regola ai soli file che possiedono la proprietà specificata, evitando che venga applicata indiscriminatamente a tutte le risorse.

Figura 25: Configurazione della condizione della Central Access Rule basata sulla proprietà Department = Research

Dopo aver definito le risorse target ho configurato i permessi che verranno applicati quando la condizione risulta soddisfatta. In questa fase è possibile specificare sia i diritti di accesso sia eventuali condizioni aggiuntive basate sui claims dell’utente.

Nella figura sotto è mostrata la finestra Permission Entry for Permissions. Ho selezionato come Principal il gruppo Authenticated Users e ho assegnato i permessi di Modify, Read and Execute, Read e Write.

Nella parte inferiore ho aggiunto una condizione basata sul claim utente, impostando User → Company department → Equals → Research. In questo modo i permessi vengono concessi solo agli utenti il cui attributo Department corrisponde al valore Research.

La regola combina quindi la proprietà della risorsa definita in precedenza con il claim dell’utente, consentendo l’accesso solo quando entrambe le condizioni risultano soddisfatte.

Figura 26: Configurazione dei permessi della Central Access Rule con condizione basata sul claim utente Department = Research

Figura 27: Verifica delle autorizzazioni configurate nella Central Access Rule con condizione basata sul claim utente

Dopo aver configurato le condizioni e i permessi, la Central Access Rule risulta completa e pronta per essere utilizzata.

Nella figura sotto è mostrata la configurazione completa della regola Department Match. Nella sezione Target Resources è definita la condizione Resource.Department Equals “Research”, che limita l’applicazione della regola alle risorse classificate con questo valore.

Nella sezione Permissions è presente la voce che assegna i diritti di Modify con la condizione User.Company department Equals “Research”, mentre le altre autorizzazioni rappresentano i permessi standard per SYSTEM, Administrators e Owner.

La regola è quindi configurata per valutare sia le proprietà della risorsa sia il claim dell’utente.

Figura 28: Configurazione completa della Central Access Rule con condizioni su risorsa e utente

Una volta completata la configurazione, la Central Access Rule viene visualizzata nell’elenco delle regole disponibili all’interno del nodo Central Access Rules del Dynamic Access Control.

Da questo momento la regola è disponibile e può essere riutilizzata nella definizione delle policy centralizzate.

Figura 29: Central Access Rule creata e disponibile nel nodo Central Access Rules

Creo adesso una seconda Central Access Rule per gestire l’accesso ai documenti classificati come confidenziali.

Creazione della regola per i documenti confidenziali

Nella figura sotto definisco la nuova regola Access Confidential Docs. Nella sezione Target Resources imposto una condizione basata sulla proprietà della risorsa, selezionando Resource, quindi Confidentiality, con operatore Equals e valore High. In questo modo la regola viene applicata esclusivamente alle risorse classificate con un livello di riservatezza elevato.

Figura 30: Creazione della Central Access Rule per le risorse con proprietà Confidentiality impostata su High

Definisco quindi anche per questa regola le condizioni di autorizzazione modificando le permissions.

Configurazione delle autorizzazioni condizionali

Ho modificato le autorizzazioni aggiungendo condizioni basate sia sul claim dell’utente sia sul claim del dispositivo. Per il principal Authenticated Users assegno i permessi di Modify, quindi definisco una prima condizione in cui il Company department dell’utente deve essere uguale a Research.

Aggiungo poi una seconda condizione combinata con operatore AND, specificando che il dispositivo deve appartenere al gruppo IT Workstations. In questo modo l’accesso viene consentito solo quando entrambe le condizioni risultano soddisfatte.

La configurazione introduce quindi un controllo più restrittivo, in cui l’accesso ai documenti classificati come confidenziali dipende contemporaneamente dall’identità dell’utente e dal computer utilizzato.

Figura 31: Configurazione delle autorizzazioni condizionali con claim utente e dispositivo

Nella figura sotto è visibile il risultato finale della configurazione della Central Access Rule Access Confidential Docs. Nella sezione Target Resources è riportata la condizione Resource.Confidentiality Equals High, che limita l’ambito della regola alle risorse classificate come altamente confidenziali.

Figura 32: Visualizzazione dei permessi correnti e proposti della Central Access Rule Access Confidential Docs

A questo punto risultano configurate due Central Access Rules, entrambe disponibili per essere incluse in una Central Access Policy.

Figura 33: Elenco delle Central Access Rules configurate nel Dynamic Access Control

Dopo aver definito le Central Access Rules, è necessario creare una Central Access Policy, che consente di raggruppare più regole e applicarle alle risorse.

Configurazione delle Central Access Policies

Le Central Access Policy rappresentano il contenitore logico delle regole precedentemente create e costituiscono l’elemento che verrà effettivamente distribuito ai file server.

Attraverso una policy è possibile combinare più Central Access Rules e applicarle in modo coerente alle risorse, centralizzando la gestione delle autorizzazioni basate su claims e proprietà di classificazione.

Figura 34: Central Access Policies in Dynamic Access Control

Ho selezionato la regola Department Match dall’elenco delle Central Access Rules disponibili e l’ho aggiunta alla sezione Member Central Access Rules della policy. In questo modo la policy eredita le condizioni di accesso definite nella regola, basate sulla corrispondenza tra il department dell’utente e quello della risorsa.

La Central Access Policy diventa quindi il contenitore che consente di applicare questa logica di autorizzazione alle risorse del file server.

Figura 35: Aggiunta della regola Department Match alla Central Access Policy

Figura 36: Central Access Policy Department Match con la regola Department Match associata

Ho creato anche una seconda Central Access Policy, dedicata alla protezione dei documenti confidenziali.

Nella figura sotto sono quindi visibili due Central Access Policies: Department Match e Protect confidential docs. La prima è associata alla regola che controlla la corrispondenza del department, mentre la seconda è stata creata per applicare le restrizioni basate sulla classificazione Confidentiality e sulle condizioni combinate di utente e dispositivo.

Entrambe le policy sono ora disponibili e potranno essere distribuite ai file server tramite Group Policy.

Figura 37: Elenco delle Central Access Policies configurate nel Dynamic Access Control

Applicazione delle Central Access Policies tramite Group Policy

Per applicare le Central Access Policies al file server ho creato una GPO dedicata e l’ho collegata alla OU DAC-Protected, creata in precedenza per isolare i sistemi coinvolti nel laboratorio. Ho quindi configurato la GPO seguendo il percorso Computer Configuration → Policies → Windows Settings → Security Settings → File System → Central Access Policy.

Nella figura sotto sono visibili le due policy Department Match e Protect confidential docs, entrambe aggiunte all’elenco delle Central Access Policies applicabili. In questo modo ho pubblicato le policy all’interno della GPO rendendole disponibili sui sistemi che ricevono la configurazione.

Figura 38: Configurazione della GPO con due Central Access Policies applicate al file server

Verifica del rilascio dei claim per l’utente

Prima di testare le Central Access Policies ho verificato che i claims utente vengano effettivamente rilasciati durante l’autenticazione. Questo controllo è importante perché le regole di Dynamic Access Control utilizzano tali informazioni per valutare le condizioni di accesso.

Nella figura sotto è mostrato l’output del comando whoami /claims, eseguito da una sessione dell’utente. Il comando consente di visualizzare i claims inclusi nel ticket Kerberos, tra cui il Company department utilizzato nelle regole configurate.

La presenza del claim conferma che il domain controller sta includendo le informazioni dell’utente nel processo di autenticazione.

Figura 39: Verifica del rilascio dei claim utente tramite comando whoami /claims

Applicazione delle Central Access Policies alla cartella

Sul file server LON-SVR7 ho verificato che le Central Access Policies distribuite tramite Group Policy fossero disponibili e le ho applicate alla cartella C:\Projects.

Nella figura sotto è mostrata l’applicazione della policy Protect confidential docs nella scheda Central Policy delle impostazioni avanzate di sicurezza della cartella. La policy è stata configurata per essere applicata a This folder, subfolders and files, rendendo attiva la regola associata ai file classificati come confidenziali.

Figura 40: Applicazione della Central Access Policy “Protect confidential docs” alla cartella C:\Projects

Nella figura sotto è mostrata l’applicazione della policy Department Match alla stessa cartella. Anche in questo caso la configurazione è stata estesa a cartella, sottocartelle e file, consentendo la valutazione dinamica dei claims relativi al reparto dell’utente.

In questo modo entrambe le Central Access Policies risultano applicate alla cartella C:\Projects, permettendo al file server di valutare le condizioni definite nelle Central Access Rules durante i tentativi di accesso.

Figura 41: Applicazione della Central Access Policy “Department Match” alla cartella C:\Projects

Test di accesso da client autorizzato

Nella figura sotto è mostrato l’accesso alla condivisione \\LON-SVR7\Projects dalla macchina LON-CL1, appartenente al gruppo IT Workstations. L’utente Nicola Ferrini, appartenente al dipartimento Research, ha potuto aprire la cartella e accedere correttamente al file presente, dimostrando che le condizioni definite nelle Central Access Policies sono state soddisfatte.

Il test ha confermato che, quando il dispositivo appartiene al gruppo richiesto e i claims utente corrispondono alle regole configurate, il Dynamic Access Control consente l’accesso alle risorse protette.

Figura 42: Accesso consentito alla cartella \LON-SVR7\Projects dalla macchina LON-CL1 appartenente al gruppo IT Workstations

Test di accesso da client non autorizzato

Nella figura sotto è mostrato il tentativo di accesso alla condivisione \\LON-SVR7\Projects da una macchina che non soddisfa le condizioni definite nelle Central Access Policies, oppure utilizzando un utente non appartenente al dipartimento Research.

L’accesso alla cartella è stato negato e Windows ha restituito un errore di autorizzazione insufficiente. Questo comportamento conferma che il Dynamic Access Control applica correttamente le regole configurate, impedendo l’accesso quando i claims dell’utente o del dispositivo non corrispondono ai criteri stabiliti.

Figura 43: Accesso negato alla cartella \LON-SVR7\Projects da client o utente che non soddisfa le condizioni della Central Access Policy

Configurazione dell’Access-Denied Remediation

La funzionalità Access-Denied Assistance permette di personalizzare il messaggio visualizzato agli utenti quando l’accesso a una risorsa viene negato. Questa impostazione consente di sostituire l’errore standard con un messaggio più esplicativo, indicando ad esempio il motivo del blocco o le modalità per richiedere l’autorizzazione. In questo modo l’utente riceve indicazioni utili invece di un generico “Access denied”.

È inoltre possibile abilitare la richiesta di assistenza direttamente dal messaggio, permettendo agli utenti di inviare automaticamente una richiesta ai responsabili della risorsa o agli amministratori. Questa funzionalità semplifica la gestione delle autorizzazioni e riduce le richieste informali, integrando il processo di accesso con le politiche di Dynamic Access Control.

Per configurare la funzionalità Access-Denied Remediation è necessario modificare la Group Policy dedicata al DAC. Dopo aver aperto l’editor della GPO, si accede al percorso Computer Configuration → Policies → Administrative Templates → System → Access-Denied Assistance. Da qui si apre l’impostazione Customize message for Access Denied errors e la si abilita per definire un messaggio personalizzato.

Nel campo destinato al testo del messaggio viene inserito un avviso che verrà visualizzato agli utenti quando l’accesso a una risorsa viene negato. Questo consente di fornire indicazioni più chiare rispetto al messaggio standard, ad esempio spiegando che il blocco è dovuto a una policy di autorizzazione e invitando l’utente a richiedere l’accesso.

Figura 44: Configurazione del messaggio personalizzato per l’Access-Denied Remediation tramite Group Policy

Ho abilitato anche l’impostazione Enable access-denied assistance on client for all file types, utilizzata per attivare la visualizzazione del messaggio di Access-Denied Remediation sui computer client.

Questa configurazione è necessaria affinché i sistemi client possano visualizzare il messaggio personalizzato definito nella policy. Senza questa impostazione, anche se il messaggio è configurato lato server, il client potrebbe continuare a mostrare il generico errore di accesso negato.

Abilitando questa opzione si garantisce che, per tutti i tipi di file, i client ricevano e mostrino le informazioni aggiuntive relative al blocco e le eventuali istruzioni per richiedere l’accesso.

Figura 45: Abilitazione della visualizzazione dell’Access-Denied Assistance sui client tramite Group Policy

Verifica dell’Access-Denied Remediation

Nella figura sotto è mostrato il messaggio visualizzato sul client dopo l’applicazione della policy e l’aggiornamento tramite gpupdate /force sul server LON-SVR7.

Quando un utente tenta di accedere alla condivisione senza soddisfare le condizioni definite nelle Central Access Policies, viene visualizzato il messaggio personalizzato configurato nella Group Policy, accompagnato dal pulsante Request Assistance.

Figura 46: Messaggio personalizzato di Access-Denied Remediation visualizzato sul client con opzione Request Assistance

Nella figura sotto è mostrata la finestra Request Assistance, visualizzata quando l’utente seleziona l’opzione per richiedere supporto dopo un accesso negato. La finestra riporta automaticamente il percorso della risorsa, l’identità dell’utente e consente di inserire un messaggio descrittivo per motivare la richiesta di accesso.

Figura 47: Finestra Request Assistance per l’invio di una richiesta di accesso alla risorsa protetta

Troubleshooting

Per analizzare il comportamento delle Dynamic Access Control (DAC) e verificare correttamente le decisioni di accesso, è necessario abilitare preventivamente i meccanismi di auditing e identificare i registri eventi da consultare. Il processo di troubleshooting deve seguire un approccio strutturato, verificando nell’ordine l’emissione dei claim, la valutazione delle Central Access Policy e i tentativi di accesso al file system.

Come indicato dalla documentazione Microsoft Understand and Troubleshoot Dynamic Access Control in Windows Server 2012, il troubleshooting delle Central Access Policy richiede la verifica dell’infrastruttura, dell’autenticazione basata su claim e della configurazione dell’auditing prima di analizzare i log di sicurezza.

Abilitazione dell’auditing

Sul file server è necessario attivare la Advanced Audit Policy Configuration per consentire la registrazione degli eventi DAC. In particolare, devono essere configurate le seguenti voci:

• Audit File System → Success and Failure
• Audit Central Access Policy Staging → Success and Failure

Queste impostazioni permettono di registrare sia i tentativi di accesso ai file sia la valutazione delle Central Access Policy.

Figura 48: Configurazione della Advanced Audit Policy sul file server LON-SVR7

Oltre alla configurazione globale, è necessario abilitare l’auditing direttamente sulla risorsa protetta. Sulla cartella oggetto della policy (nel caso specifico C:\Projects) è stata quindi configurata una voce di auditing (SACL) con le seguenti caratteristiche:

• Principal: Everyone
• Type: Success and Failure
• Applies to: This folder, subfolders and files
• Permessi monitorati: Read, Read & Execute, List folder contents

Questa configurazione consente di registrare gli eventi relativi ai tentativi di accesso negati o consentiti in base alle condizioni definite dalla Central Access Policy.

Figura 49: Configurazione della voce di auditing sulla cartella C:\Projects, con monitoraggio dei tentativi di accesso in errore

Verifica dei log

Una volta applicate le configurazioni e aggiornate le policy con il comando gpupdate /force, il troubleshooting può essere effettuato tramite Event Viewer, consultando il log:

Event Viewer → Windows Logs → Security

Gli eventi principali da analizzare sono:

• 4626 – emissione dei claim utente o dispositivo
• 4818 – valutazione della Central Access Policy
• 4819 – eventi di staging delle Central Access Policy
• 4656 – richiesta di accesso alla risorsa
• 4663 – tentativo di accesso al file system

L’analisi combinata di questi eventi consente di determinare se l’accesso è stato negato per mancata corrispondenza dei claim, per condizioni della Central Access Policy o per permessi NTFS tradizionali.

Assegnazione manuale dei permessi con condizioni

Oltre all’utilizzo delle Central Access Policy, il Dynamic Access Control consente di definire regole di accesso direttamente a livello di risorsa. Attraverso la finestra Advanced Security Settings, è possibile aggiungere una nuova voce di autorizzazione e utilizzare il pulsante Add a condition per applicare condizioni basate sugli attributi utente o del dispositivo.

Questa modalità permette di configurare controlli dinamici senza dover necessariamente distribuire una Central Access Policy tramite Group Policy. Ad esempio, è possibile assegnare permessi al gruppo Authenticated Users limitando l’accesso solo agli utenti il cui attributo Company department corrisponde a un determinato valore. In questo modo, la valutazione dell’accesso avviene direttamente sulla risorsa, mantenendo la flessibilità del DAC ma con una configurazione locale.

La configurazione centralizzata tramite Central Access Policy offre diversi vantaggi rispetto all’assegnazione manuale delle condizioni sulle singole risorse. In particolare, consente di standardizzare i criteri di accesso e ridurre il rischio di configurazioni incoerenti o errori operativi. Definendo le regole una sola volta e distribuendole tramite Group Policy, è possibile garantire che le stesse condizioni vengano applicate in modo uniforme su tutti i file server e sulle cartelle interessate.

Questo approccio facilita anche la gestione e la manutenzione nel tempo: eventuali modifiche ai criteri di accesso possono essere effettuate centralmente senza intervenire manualmente su ogni risorsa. Di conseguenza, la configurazione centralizzata risulta preferibile in ambienti di produzione, dove la coerenza, la tracciabilità e la scalabilità della gestione delle autorizzazioni sono elementi fondamentali.

Figura 50: Assegnazione manuale dei permessi con condizioni

Considerazioni aggiuntive sul Dynamic Access Control

Il Dynamic Access Control introduce un modello di autorizzazione più evoluto rispetto alle tradizionali ACL NTFS, consentendo di basare le decisioni di accesso non solo sui gruppi di sicurezza, ma anche su attributi utente, dispositivo e proprietà delle risorse. Questo approccio permette di implementare controlli di accesso basati sul contesto, migliorando la sicurezza e la flessibilità nella gestione dei dati.

Un ulteriore vantaggio del DAC è la separazione tra classificazione delle risorse e definizione delle policy di accesso. Le risorse possono essere classificate mediante proprietà specifiche, che vengono poi utilizzate dalle Central Access Policy per determinare i permessi. Questo consente di adattare rapidamente i criteri di accesso senza modificare manualmente le autorizzazioni su ogni cartella.

La presenza della modalità Central Access Policy Staging consente inoltre di testare le policy prima della loro applicazione effettiva. Attraverso l’analisi dei log, è possibile verificare l’impatto delle regole e identificare eventuali configurazioni errate, riducendo il rischio di blocchi indesiderati in ambienti di produzione.

L’integrazione con l’auditing avanzato permette di tracciare in modo dettagliato le decisioni di accesso e di facilitare le attività di troubleshooting. Gli amministratori possono analizzare i log per comprendere quali condizioni hanno determinato la concessione o il rifiuto dell’accesso, migliorando la visibilità sul comportamento delle policy.

Ovviamente la gestione centralizzata tramite Central Access Policy consente di standardizzare i criteri di sicurezza, semplificare la manutenzione e garantire coerenza nell’applicazione delle regole. Questo rende il Dynamic Access Control particolarmente adatto a contesti enterprise, dove è necessario implementare un modello di accesso scalabile, controllato e facilmente controllabile.

Conclusioni

L’implementazione del Dynamic Access Control ha permesso di definire criteri di accesso basati su attributi utente, appartenenza a gruppi e condizioni del dispositivo, garantendo un controllo più granulare rispetto alle tradizionali autorizzazioni NTFS. La configurazione delle Central Access Policy e la loro applicazione alle risorse hanno consentito di verificare correttamente il rilascio dei claim e l’applicazione delle regole di accesso.