• Guide, Sicurezza, Sistemi Operativi
• 6 Agosto 2026

Per impostazione predefinita, Active Directory è progettato per essere facilmente consultabile. Un utente autenticato può visualizzare gran parte della struttura del dominio, come le Organizational Unit (OU), gli utenti e i gruppi, anche se non dispone delle autorizzazioni necessarie per modificarli.

Nella maggior parte degli ambienti questo comportamento è perfettamente normale. In alcuni scenari, però, potrebbe essere utile limitare la visibilità di determinati oggetti o attributi, rendendoli accessibili soltanto agli amministratori o a specifici gruppi di utenti.

Pensate, ad esempio, agli account amministrativi, ai service account oppure a un’infrastruttura condivisa tra più aziende. In questi casi non è sufficiente impedire la modifica degli oggetti: può essere utile nasconderne completamente l’esistenza agli utenti che non sono autorizzati a visualizzarli.

Per raggiungere questo obiettivo, Active Directory mette a disposizione alcune funzionalità poco conosciute ma ancora oggi pienamente supportate. In questa guida utilizzeremo un dominio basato su Windows Server 2025, ma vedremo strumenti disponibili da molti anni e tuttora validi anche nelle versioni più recenti del sistema operativo.

Nota: Le ACL di Active Directory sono disponibili fin da Windows 2000 Server. Anche List Object Mode è stato introdotto con Windows 2000 Server, mentre il Confidentiality Bit è disponibile a partire da Windows Server 2003 Service Pack 1.

Come si può vedere nella figura sotto, un normale Domain User può aprire la console Active Directory Users and Computers (installata tramite gli strumenti RSAT su Windows 11) e consultare liberamente la struttura del dominio. Sebbene l’utente non appartenga ai gruppi amministrativi, può comunque visualizzare le Organizational Unit, gli utenti, i gruppi e gli altri oggetti presenti nella directory.

Questo comportamento prende il nome di Active Directory Enumeration e rappresenta il funzionamento predefinito di Active Directory. In altre parole, la possibilità di visualizzare un oggetto non implica automaticamente il diritto di modificarlo. L’utente può infatti enumerare gli oggetti presenti nella directory, mentre le operazioni consentite su ciascun oggetto continuano a essere determinate dalle autorizzazioni assegnate.

Figura 1: Un normale utente di dominio può enumerare Active Directory

Perché Active Directory consente l’enumerazione degli oggetti?

A prima vista potrebbe sembrare un comportamento poco sicuro. In realtà, Active Directory è stato progettato per consentire agli utenti autenticati di individuare le risorse del dominio e di collaborare più facilmente all’interno dell’organizzazione.

Pensate, ad esempio, alla Rubrica Globale (GAL) di Exchange, alla ricerca di un collega in Outlook oppure alla possibilità di individuare utenti, gruppi o computer tramite una semplice query LDAP. Tutte queste funzionalità si basano sulla possibilità di enumerare gli oggetti presenti nella directory.

Per questo motivo, la visibilità di un oggetto è indipendente dalle autorizzazioni necessarie per modificarlo. Un utente può sapere che un oggetto esiste senza avere alcun diritto di amministrarlo.

Questo approccio è perfettamente adeguato nella maggior parte degli ambienti. Esistono però scenari in cui ridurre la quantità di informazioni visibili agli utenti rappresenta un ulteriore livello di sicurezza e consente di applicare in modo più rigoroso il principio del Least Privilege.

Quando può essere utile nascondere gli oggetti?

Nella maggior parte delle infrastrutture non esiste alcuna necessità di modificare il comportamento predefinito di Active Directory. Esistono però situazioni in cui limitare la visibilità degli oggetti può rappresentare un ulteriore livello di sicurezza.

Pensate, ad esempio, agli account amministrativi. Sebbene un normale utente non possa modificarli, è comunque in grado di individuarli e conoscerne il nome. Lo stesso vale per i service account, spesso utilizzati da applicazioni o servizi che richiedono privilegi elevati.

Un altro scenario piuttosto comune riguarda gli ambienti multi-tenant o le infrastrutture gestite da un provider di servizi. In questi casi più aziende condividono lo stesso dominio Active Directory e ogni amministratore dovrebbe poter visualizzare esclusivamente gli oggetti appartenenti alla propria organizzazione.

Infine, alcuni oggetti possono contenere attributi sensibili, come identificativi applicativi, informazioni riservate o dati utilizzati da specifiche applicazioni. Anche se l’oggetto deve rimanere visibile, potrebbe essere opportuno impedire la lettura di alcuni attributi.

Come è possibile limitare la visibilità degli oggetti?

Active Directory offre diversi meccanismi per limitare la visibilità delle informazioni. Sebbene abbiano lo stesso obiettivo, non risolvono lo stesso problema.

Il primo livello è rappresentato dalle Access Control List (ACL), ovvero le autorizzazioni applicate agli oggetti della directory. Attraverso le ACL è possibile controllare chi può leggere, modificare o amministrare un oggetto.

Quando le ACL non sono sufficienti, è possibile abilitare il List Object Mode. Questa funzionalità modifica il modo in cui Active Directory restituisce gli oggetti durante un’enumerazione, consentendo di nascondere completamente quelli che un utente non è autorizzato a visualizzare.

Importante: Il List Object Mode non può essere abilitato per una singola Organizational Unit o per un singolo dominio. Una volta attivato, interessa l’intera foresta Active Directory. La funzionalità abilita semplicemente un nuovo meccanismo di valutazione delle autorizzazioni, mentre la visibilità dei singoli oggetti continua a dipendere dalle ACL configurate dagli amministratori.

Esiste infine il Confidentiality Bit, che opera a un livello ancora più granulare. In questo caso l’oggetto continua a essere visibile, ma è possibile impedire la lettura di uno o più attributi considerati riservati.

È importante sottolineare che questi meccanismi non sono alternativi tra loro. Le ACL continuano a rappresentare il modello di autorizzazione di Active Directory e vengono sempre valutate. Il List Object Mode non sostituisce le ACL, ma modifica esclusivamente il modo in cui Active Directory restituisce gli oggetti durante l’enumerazione, consentendo di nascondere quelli per i quali l’utente non dispone delle autorizzazioni appropriate.

ACL: il primo livello di protezione

Le Access Control List (ACL) rappresentano il meccanismo di sicurezza su cui si basa Active Directory. Ogni oggetto della directory, come utenti, gruppi, computer e Organizational Unit, possiede un insieme di autorizzazioni che stabilisce quali operazioni possono essere eseguite dai vari utenti o gruppi.

Come si può vedere nella figura sotto, anche una semplice Organizational Unit dispone di una propria ACL. Per impostazione predefinita, il gruppo Authenticated Users riceve alcune autorizzazioni di lettura che consentono ai normali utenti del dominio di consultare la struttura della directory.

Nella maggior parte degli scenari è possibile ottenere il risultato desiderato semplicemente modificando queste autorizzazioni. Tuttavia, le ACL non sono state progettate per nascondere completamente gli oggetti. Anche dopo aver limitato i permessi di lettura, un utente potrebbe continuare a individuarne l’esistenza durante l’enumerazione di Active Directory.

Figura 2: Le autorizzazioni (ACL) applicate a una Organizational Unit

Cosa succede se modifichiamo le ACL?

Per capire come Active Directory gestisce la visibilità degli oggetti, proviamo a modificare le autorizzazioni di una Organizational Unit.

Dopo aver rimosso il permesso Read dal gruppo Authenticated Users sulla OU Privileged Accounts, abbiamo effettuato un nuovo accesso con un normale utente di dominio (Nicola Ferrini).

Come si può osservare nella figura sotto, la OU Privileged Accounts non è più visibile nella console Active Directory Users and Computers. L’utente continua a poter enumerare il dominio e visualizzare gli altri oggetti per i quali dispone delle autorizzazioni di lettura, ma la OU sulla quale abbiamo rimosso il permesso Read è completamente scomparsa dall’elenco.

Questo semplice test dimostra come le ACL influenzino direttamente la visibilità degli oggetti.

Figura 3: La OU Privileged Accounts non è più visibile dopo la rimozione del permesso Read

Rimuovere il permesso Read dal gruppo Authenticated Users può avere effetti collaterali e non rappresenta la soluzione consigliata per nascondere gli oggetti in un ambiente di produzione.

Il permesso Read è fondamentale in Active Directory. Se lo rimuoveste indiscriminatamente da una OU, potreste riscontrare effetti collaterali come:

• impossibilità per gli utenti di cercare o aprire gli oggetti contenuti nella OU;
• malfunzionamenti di applicazioni che eseguono query LDAP;
• problemi con Exchange, Microsoft Entra Connect, MECM, software HR o altri prodotti che leggono Active Directory;
• deleghe amministrative che non funzionano più come previsto.

Se l’obiettivo è nascondere un oggetto senza alterare il normale funzionamento di Active Directory, Microsoft mette a disposizione una funzionalità specifica: List Object Mode.

List Object Mode

Come abbiamo visto prima, in molti casi è sufficiente modificare le ACL per impedire agli utenti di visualizzare una Organizational Unit o uno specifico oggetto. Questa soluzione è semplice e spesso rappresenta la scelta migliore negli ambienti aziendali tradizionali.

Microsoft mette però a disposizione una funzionalità più avanzata denominata List Object Mode, progettata per controllare il comportamento dell’enumerazione di Active Directory. Quando questa modalità è abilitata, il servizio directory può utilizzare il permesso List Object per decidere se un determinato oggetto debba essere mostrato durante la navigazione della directory.

La differenza rispetto alle ACL è importante. Le autorizzazioni tradizionali stabiliscono quali operazioni un utente può eseguire su un oggetto, mentre List Object Mode introduce un controllo aggiuntivo sulla visibilità degli oggetti durante l’enumerazione. Secondo la documentazione Microsoft Controlling Object Visibility – Win32 apps | Microsoft Learn, questa funzionalità è particolarmente indicata in scenari con deleghe amministrative avanzate, hosting o ambienti multi-tenant, nei quali è necessario limitare con precisione gli oggetti visibili ai diversi amministratori senza modificare il normale modello di sicurezza della directory.

A differenza delle ACL, List Object Mode non è abilitato per impostazione predefinita. La funzionalità deve essere attivata modificando l’attributo dSHeuristics dell’oggetto CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration della foresta Active Directory.

La modifica può essere effettuata utilizzando ADSI Edit oppure tramite strumenti di amministrazione equivalenti, utilizzando le credenziali di Enterprise Admin. Per abilitare List Object Mode è sufficiente impostare a 1 il terzo carattere dell’attributo dSHeuristics. Se l’attributo non è valorizzato, è possibile impostarlo direttamente al valore 001. Se ci sono altri numeri, lasciateli inalterati, mettendo a 1 solo la cifra finale.

È importante sottolineare che la modifica ha effetto sull’intera foresta e non può essere limitata a un singolo dominio o a una specifica Organizational Unit. Prima di abilitarla in produzione è quindi consigliabile verificarne il comportamento in un ambiente di test.

Figura 4: Abilitazione di List Object Mode modificando l’attributo dSHeuristics

Nota: Dopo aver modificato l’attributo dSHeuristics, in una foresta con più controller di dominio, sarà necessario attendere la normale replica di Active Directory affinché la modifica venga applicata a tutti i server.

Per configurare il permesso List Object, aprite le proprietà della Organizational Unit, selezionate la scheda Security e fate clic su Advanced. Nella finestra Advanced Security Settings selezionate la voce relativa all’utente o al gruppo da modificare e fate clic su Edit.

Come mostrato nella figura sotto, dopo aver abilitato List Object Mode compare una nuova autorizzazione denominata List object. Questo permesso consente di controllare se uno specifico oggetto debba essere visualizzato durante l’enumerazione di Active Directory. A differenza del permesso Read, non determina la possibilità di leggere le proprietà dell’oggetto, ma esclusivamente la sua visibilità.

Figura 5: Il permesso List Object è disponibile nelle autorizzazioni avanzate dopo l’abilitazione di List Object Mode

NOTA: Per esperienza personale, List Object Mode è raramente utilizzato. Per farlo funzionare correttamente bisogna riprogettare le ACL della struttura di Active Directory, non semplicemente aggiungere un permesso su una singola OU. È una configurazione pensata per ambienti multi-tenant o di hosting, non per “nascondere una OU” in un dominio aziendale tradizionale. Anche Microsoft avverte che questa modalità aumenta il numero di controlli di accesso e va usata con attenzione.

Proteggere i singoli attributi con il Confidentiality Bit

Fino a questo punto abbiamo visto come limitare la visibilità di interi oggetti di Active Directory. In alcuni scenari, però, non è necessario nascondere un utente, un gruppo o una Organizational Unit, ma soltanto alcune informazioni contenute nei relativi attributi.

Per rispondere a questa esigenza, Active Directory mette a disposizione il Confidentiality Bit. Questa funzionalità consente di contrassegnare un attributo come riservato, in modo che possa essere letto soltanto dagli utenti o dai gruppi autorizzati.

La differenza rispetto alle ACL e a List Object Mode è sostanziale. L’oggetto continua a essere visibile durante l’enumerazione della directory, ma uno o più attributi vengono esclusi dalla lettura per gli utenti che non dispongono delle autorizzazioni necessarie.

Microsoft suggerisce questa soluzione quando è necessario proteggere informazioni sensibili, come identificativi applicativi, dati riservati o attributi personalizzati utilizzati da applicazioni aziendali, evitando di nascondere completamente l’oggetto.

Configurare il Confidentiality Bit

Il Confidentiality Bit viene configurato modificando il valore dell’attributo searchFlags nello schema di Active Directory. Ogni attributo dello schema possiede infatti un insieme di flag che ne definiscono il comportamento. Impostando il bit 7 (valore 128) l’attributo viene contrassegnato come confidenziale. Da quel momento, oltre al normale permesso Read Property, Active Directory richiederà anche il diritto Control Access per consentirne la lettura.

È importante sapere che non tutti gli attributi possono essere contrassegnati come confidenziali. Gli attributi appartenenti allo schema base di Active Directory (identificabili dal valore systemFlags = 0x10) non possono essere modificati. Per questo motivo il Confidentiality Bit viene normalmente utilizzato con attributi personalizzati introdotti da applicazioni o da estensioni dello schema. Trovate maggiori informazioni alla pagina Mark an attribute as confidential – Windows Server | Microsoft Learn

Supponiamo di voler impedire ai normali utenti del dominio di visualizzare il valore dell’attributo employeeNumber, consentendone l’accesso esclusivamente ai membri del gruppo HR.

In questo modo, l’oggetto utente continuerà a essere normalmente visibile in Active Directory, ma il contenuto dell’attributo riservato potrà essere letto soltanto dagli utenti autorizzati.

Il primo passo consiste nel contrassegnare l’attributo employeeNumber come confidenziale, modificando il valore dell’attributo searchFlags nello schema di Active Directory.

Figura 6: Il Confidentiality Bit viene abilitato impostando il valore 128 nell’attributo searchFlags della definizione dell’attributo nello schema di Active Directory

Dopo aver contrassegnato employeeNumber come confidenziale, dobbiamo assegnargli un valore su un account di prova.

Aprite Active Directory Users and Computers e abilitate View > Advanced Features. Aprite quindi le proprietà dell’utente scelto per il laboratorio, ad esempio Nicola Ferrini, e selezionate la scheda Attribute Editor.

Individuate l’attributo employeeNumber, fate clic su Edit e inserite un valore di prova, ad esempio RM-000123. Confermate la modifica con OK.

Figura 7: Assegnazione di un valore all’attributo employeeNumber

Dopo aver abilitato il Confidentiality Bit e valorizzato l’attributo employeeNumber, possiamo verificare il comportamento dal punto di vista di un utente che non dispone delle autorizzazioni necessarie.

Nel nostro laboratorio abbiamo effettuato l’accesso con Monica, un normale utente del dominio appartenente al reparto Marketing. Aprendo le proprietà dell’utente Nicola Ferrini e selezionando la scheda Attribute Editor, l’attributo employeeNumber risulta presente, ma il relativo valore non è più leggibile.

Questo comportamento conferma che il Confidentiality Bit non nasconde l’oggetto di Active Directory né elimina l’attributo, ma impedisce agli utenti non autorizzati di leggerne il contenuto.

Figura 8: Un utente privo delle autorizzazioni necessarie non può leggere il valore dell’attributo employeeNumber

Per impostazione predefinita, dopo aver abilitato il Confidentiality Bit, soltanto gli amministratori possono leggere il valore dell’attributo. Se desiderate autorizzare altri utenti, ad esempio il personale del reparto HR, è necessario concedere il diritto Control Access sullo specifico attributo.

Come evidenziato dalla documentazione Microsoft Mark an attribute as confidential – Windows Server | Microsoft Learn, questa operazione non può essere eseguita tramite Active Directory Users and Computers, ma richiede l’utilizzo di Ldp.exe, che consente di creare una ACE object-specific riferita esclusivamente all’attributo employeeNumber. Questo approccio permette di autorizzare il gruppo HR senza estendere inutilmente i privilegi ad altri attributi dell’oggetto.

Aprite Ldp.exe, selezionate Connection > Connect e indicate il nome di un Domain Controller. Lasciate la porta 389 se utilizzate LDAP oppure specificate 636 se avete configurato LDAPS. Selezionate quindi Connection > Bind ed eseguite l’autenticazione con un account autorizzato a modificare le ACL dell’oggetto.

Dal menu View selezionate Tree, lasciate vuoto il campo BaseDN oppure inserite il Distinguished Name del dominio, ad esempio DC=virtual,DC=lab

Espandete l’albero fino a individuare l’utente Nicola Ferrini. Fate clic con il pulsante destro sull’oggetto e selezionate Security Descriptor > Edit

Figura 9: Apertura del Security Descriptor dell’utente tramite Ldp.exe

Nella sezione DACL fate clic su Add ACE. Impostate il gruppo HR come Trustee, selezionate Allow come tipo di autorizzazione, abilitate il diritto Read Property ed il diritto Control access e scegliete EmployeeNumber – attribute nel campo Object type. Confermate la modifica con OK e aggiornate il Security Descriptor.

In questo modo il diritto Control Access verrà applicato esclusivamente all’attributo employeeNumber, senza concedere autorizzazioni aggiuntive sugli altri attributi dell’oggetto utente.

Figura 10: Creazione di una ACE specifica che autorizza il gruppo HR a leggere l’attributo confidenziale employeeNumber

Fate clic sul pulsante Update per salvare il nuovo Security Descriptor nell’oggetto Active Directory.

Figura 11: Aggiornamento del nuovo Security Descriptor nell’oggetto Active Directory

Per verificare la configurazione, effettuate l’accesso con un utente appartenente al gruppo HR, nel nostro caso Holly, e aprite Active Directory Users and Computers. Dopo aver abilitato View > Advanced Features, aprite le proprietà dell’utente Nicola Ferrini e selezionate la scheda Attribute Editor.

Come mostrato nella figura seguente, il valore dell’attributo employeeNumber è ora correttamente visualizzato. La verifica conferma che il gruppo HR dispone delle autorizzazioni necessarie per leggere l’attributo confidenziale. E come potete vedere, può solo visualizzarle (View) e non modificarle (Edit) perché non gli abbiamo concesso la possibilità di farlo.

Figura 12: Un membro del gruppo HR può leggere il valore dell’attributo confidenziale employeeNumber

Importante: Come ho già scritto prima,
il Confidentiality Bit non è utilizzabile con tutti gli attributi di Active Directory. Gli attributi che fanno parte dello schema di base (Category 1), ovvero quelli utilizzati dal sistema per il funzionamento della directory, non possono essere contrassegnati come riservati. Tra questi rientrano, ad esempio, cn, distinguishedName, objectClass, objectGUID e sAMAccountName. Prima di implementare questa soluzione è quindi consigliabile verificare che gli attributi interessati supportino questa funzionalità.

Quando utilizzare List Object Mode e il Confidentiality Bit

List Object Mode e Confidentiality Bit risolvono problemi differenti e non devono essere considerati tecnologie alternative, ma strumenti complementari per implementare un modello di sicurezza più granulare in Active Directory.

List Object Mode interviene a livello di oggetto e consente di controllare la visibilità di Organizational Unit, utenti, gruppi e altri oggetti durante l’enumerazione della directory. Il suo scopo è limitare le informazioni disponibili agli utenti durante la navigazione di Active Directory, impedendo che vengano visualizzati elementi che non rientrano nelle loro responsabilità operative. Questa funzionalità risulta particolarmente utile per nascondere OU contenenti account privilegiati, ambienti amministrativi, strutture dedicate a specifici reparti o organizzazioni multi-tenant, riducendo così la superficie di esposizione delle informazioni.

Il Confidentiality Bit opera invece a livello di attributo. L’oggetto rimane normalmente visibile, ma uno o più attributi vengono restituiti soltanto agli utenti che dispongono delle autorizzazioni necessarie. Questo approccio è indicato quando un’informazione deve essere protetta senza nascondere l’intero oggetto. È il caso, ad esempio, di attributi quali employeeNumber, employeeID, identificativi HR, codici interni o altri dati utilizzati dalle applicazioni aziendali che non devono essere accessibili a tutti gli utenti del dominio.

Le due funzionalità possono essere utilizzate contemporaneamente per implementare un modello di sicurezza basato sul principio del least privilege. In uno scenario tipico, una Organizational Unit contenente account amministrativi può essere completamente nascosta agli utenti comuni tramite List Object Mode, mentre gli oggetti visibili nella directory possono esporre soltanto gli attributi strettamente necessari grazie al Confidentiality Bit. In questo modo si riduce sia la possibilità di enumerare gli oggetti presenti nella directory sia quella di accedere a informazioni sensibili memorizzate negli attributi di Active Directory.

Prima di adottare queste configurazioni in produzione è comunque consigliabile eseguire tutti i test in un ambiente di laboratorio, verificare attentamente le autorizzazioni applicate e attendere la completa replica delle modifiche tra i Domain Controller. Un’implementazione corretta consente di aumentare significativamente il livello di riservatezza delle informazioni senza compromettere il normale funzionamento delle applicazioni e dei servizi che utilizzano Active Directory.

Conclusioni

La configurazione predefinita di Active Directory privilegia la facilità di amministrazione, consentendo agli utenti autenticati di enumerare gran parte della directory. In molti contesti, tuttavia, questo comportamento espone informazioni che non dovrebbero essere accessibili a tutti.

Grazie a List Object Mode e al Confidentiality Bit è possibile limitare la visibilità degli oggetti e proteggere gli attributi più sensibili, implementando un modello di sicurezza più granulare senza compromettere il normale funzionamento dell’infrastruttura.

Con una corretta pianificazione delle autorizzazioni e un’adeguata fase di test, queste funzionalità rappresentano strumenti efficaci per ridurre l’esposizione delle informazioni e applicare il principio del least privilege anche all’interno di Active Directory.