• Guide, Sicurezza, Sistemi Operativi
• 6 Gennaio 2025

Le Authentication Policies e gli Authentication Policy Silos sono strumenti avanzati di Active Directory, introdotti con Windows Server 2012 R2, che vi consentono di migliorare la sicurezza del vostro ambiente IT, in particolare per proteggere gli account privilegiati.

Authentication Policies

Le Authentication Policies vi permettono di definire criteri di autenticazione personalizzati per gli account e i computer nel vostro dominio Active Directory. Grazie a queste, potete:

• Limitare l’accesso basato su condizioni specifiche: Potete configurare una policy che consente l’accesso solo da dispositivi autorizzati o da una subnet di rete specifica.
• Applicare restrizioni temporali: Potete impostare una policy che limita l’autenticazione solo a determinate fasce orarie.
• Definire condizioni avanzate: Ad esempio, richiedere un protocollo di autenticazione specifico come Kerberos o l’uso di meccanismi di protezione avanzati.
• Proteggere account privilegiati: Potete applicare criteri più rigorosi a utenti con privilegi elevati, come amministratori di dominio, riducendo i rischi di compromissione.

Authentication Policy Silos

Gli Authentication Policy Silos (APS) vi consentono di organizzare e raggruppare account (utenti, computer o servizi) in contenitori logici, applicando specifiche Authentication Policies ai gruppi così definiti.

Come funzionano gli APS:

• Creazione di un Silo: Potete creare un Silo per raggruppare account che condividono esigenze di sicurezza simili.
• Associazione a una Authentication Policy: Collegate ogni Silo a una Authentication Policy, così da applicare le restrizioni definite a tutti gli account al suo interno.
• Protezione degli account privilegiati: Potete usare gli APS per isolare e proteggere account sensibili come quelli degli amministratori di dominio, riducendo la loro esposizione agli attacchi.

Claims-based authentication

Con la claims-based authentication è possibile includere informazioni aggiuntive, come attributi specifici di utenti o dispositivi, nel processo di autenticazione. Questi attributi, detti claims, possono rappresentare dettagli come il ruolo di un utente, il reparto a cui appartiene o la configurazione del dispositivo utilizzato. Questo approccio permette di implementare regole di accesso più flessibili e basate su criteri aziendali complessi.

Abilitare la policy “KDC support for claims, compound authentication and Kerberos armoring” sui Domain Controller serve a introdurre funzionalità avanzate di sicurezza nel processo di autenticazione Kerberos in Active Directory. Questa impostazione consente di sfruttare le claims, l’autenticazione composta e il Kerberos armoring.

L’autenticazione composta (compound) migliora la sicurezza combinando le informazioni dell’utente e del dispositivo durante l’autenticazione. Questo significa che il Domain Controller verifica non solo l’identità dell’utente, ma anche la conformità del dispositivo utilizzato, assicurando che l’accesso sia consentito solo da dispositivi approvati.

Il Kerberos armoring, noto anche come FAST (Flexible Authentication Secure Tunneling), aggiunge un livello di protezione crittografica al protocollo Kerberos. Questo rafforzamento protegge il traffico di autenticazione contro attacchi di tipo replay, man-in-the-middle e manipolazione dei dati, rendendo il processo di autenticazione più sicuro e affidabile.

Per implementare queste funzionalità, è necessario che i Domain Controller siano aggiornati a Windows Server 2012 o versioni successive e che lo schema Active Directory supporti le nuove tecnologie. Anche i client che si connettono al dominio devono essere compatibili. Abilitando questa policy, si rafforza la protezione degli account privilegiati e si ottempera a requisiti avanzati di sicurezza e conformità normativa, garantendo al contempo un accesso condizionato più flessibile e sicuro.

 

Ho abilitato la funzionalità di claim-based authentication creando una nuova GPO e collegandola alla organizational unit dei domain controller. Mettete su Supported la voce Computer Configuration > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring

Figura 1: Abilitazione della policy di KDC support for claims, compound authentication, and Kerberos armoring

Per permettere di estendere le funzionalità avanzate del protocollo Kerberos anche ai dispositivi client che si autenticano nel dominio Active Directory è necessario creare una policy di dominio che modifichi il parametro Computer Configuration > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring.

Abilitando questa policy a livello di dominio, garantite che i dispositivi client siano pienamente integrati nel sistema di autenticazione avanzato, migliorando la sicurezza complessiva del vostro ambiente Active Directory e permettendo l’implementazione di criteri di accesso più flessibili e basati sul contesto. L’autenticazione diventa più resiliente contro attacchi, in quanto il traffico Kerberos è protetto da un tunnel crittografico e si permette ai client di sfruttare regole di accesso condizionato basate su attributi (claims) e criteri aziendali avanzati definiti in Active Directory.

Figura 2: Abilitazione del Kerberos client support for claims, compound authentication and Kerberos armoring per tutti i client del dominio

NOTA: È necessario riavviare sia i client che i Domain Controller per applicare correttamente le modifiche introdotte dall’abilitazione delle policy relative al supporto per claims, autenticazione composta e Kerberos armoring.

Perché è necessario il riavvio?

• Domain Controller: Dopo aver abilitato la policy sul KDC (Key Distribution Center), il servizio Kerberos deve essere riavviato per iniziare a supportare le nuove funzionalità. Poiché il servizio KDC è critico per il funzionamento del dominio e non può essere riavviato manualmente senza riavviare il server, è necessario un reboot.
• Client: I client devono essere riavviati per caricare le nuove impostazioni di gruppo (Group Policy) applicate, incluse quelle che modificano il comportamento del client Kerberos. Il riavvio assicura che il sistema utilizzi correttamente il nuovo livello di protezione e che le comunicazioni con i Domain Controller avvengano in modo coerente.

Configurazione delle Authentication Policy e degli Authentication Policy Silos utilizzando Active Directory Administrative Center (ADAC)

La configurazione delle Authentication Policies e degli Authentication Policy Silos tramite l’Active Directory Administrative Center (ADAC) è un processo relativamente semplice e intuitivo.

Avviate Active Directory Administrative Center (ADAC) su un domain controller server Windows Server 2012 R2 o superiore e nel pannello di navigazione a sinistra, cercate e selezionate la voce “Authentication”. Questa sezione contiene le opzioni per configurare Authentication Policies e Policy Silos. Cliccate su “New” e selezionate “Authentication Policy”.

Figura 3: Creazione di una nuova Authentication Policy dall’Active Directory Administrative Center (ADAC)

La policy è stata denominata “Privileged-Access-Restriction-Policy” e include diverse sezioni per impostare restrizioni e criteri avanzati di autenticazione. Ho selezionato l’opzione “Enforce policy restriction”, il che significa che le regole definite in questa policy verranno applicate in modo obbligatorio. È disponibile anche un’opzione di “Audit policy” per monitorare le attività senza applicare restrizioni, utile in una prima fase di test.

Nella Sezione User Sign On ho configurato un limite temporale per la durata dei Ticket Granting Ticket (TGT) degli utenti, impostato a 120 minuti. Questo serve a ridurre la finestra temporale di validità di un TGT, aumentando la sicurezza. Dopo due ore l’utente non potrà fare più nessuna operazione e deve fare logoff/logon di nuovo per continuare ad operare.

Per quanto riguarda la sezione Service Tickets for User Accounts, non sono state definite condizioni o restrizioni particolari per i service tickets destinati agli utenti, ma c’è la possibilità di aggiungerle per controllare meglio l’accesso alle risorse. Anche nella sezione Service Sign On, relativa agli account di servizio, non ci sono configurazioni attive, sebbene si possano impostare regole come la durata dei TGT o le restrizioni basate sui dispositivi per gli account di servizio.

La sezione Service Tickets for Service Accounts consente di configurare ulteriori controlli sui service tickets per gli account di servizio, ma al momento non ci sono regole attive. Infine, la sezione Computer permette di applicare criteri specifici di autenticazione per i computer, come la durata dei TGT o restrizioni basate sui dispositivi.

Figura 4: Configurazioni della nuova Authentication Policy dall’Active Directory Administrative Center (ADAC)

Un Authentication Policy Silo è una funzionalità che consente di creare un contenitore logico per raggruppare account specifici (utenti, computer o servizi) e applicare restrizioni avanzate di autenticazione.

L’obiettivo principale di un Authentication Policy Silo è quello di migliorare la sicurezza degli account privilegiati o critici, isolandoli dagli altri account del dominio e imponendo regole di accesso rigorose. Il silo permette di limitare i logon ad un particolare set di utenti su un particolare set di computers. Quindi gli utenti si potranno loggare solo a quel gruppo di computer e nient’altro.

Cliccate su “New” e selezionate “Authentication Policy Silo”.

Figura 5: Creazione di un Authentication Policy Silo

Il nome che ho assegnato al Silo è “Privileged-Access-Restriction-Silo”, utile per identificarlo tra altri Silos configurati nel dominio. Ho selezionato l’opzione “Enforce silo policies”, che significa che tutte le regole configurate per questo Silo verranno applicate obbligatoriamente agli account inclusi e l’opzione “Protect from accidental deletion” per evitare che il Silo venga eliminato per errore.

Nella Sezione Authentication Policy ho selezionato l’opzione “Use a single policy for all principals that belong to this authentication policy silo”. Questo significa che una sola Authentication Policy verrà applicata a tutti gli account inclusi nel Silo. La policy associata è “Privileged-Access-Restriction-Policy”. Questa Authentication Policy definisce le restrizioni e i criteri specifici di autenticazione (es. durata dei ticket, restrizioni sui dispositivi, ecc.) per tutti gli account contenuti nel Silo.

Questa configurazione è progettata per proteggere gli account privilegiati o sensibili attraverso:

• L’applicazione obbligatoria delle regole della Privileged-Access-Restriction-Policy, che include restrizioni avanzate di autenticazione.
• L’organizzazione degli account in un Silo, che funge da contenitore logico per una gestione centralizzata.

Figura 6: Configurazione dell’Authentication Policy Silo

Impostazione della policy del Silo agli account

Successivamente, è necessario impostare la policy del Silo sugli account (sia per gli utenti che per i computer). Questo può essere fatto selezionando gli account dall’Active Directory Administrative Center (ADAC) e accedendo alla sezione dedicata al Silo. Assegnare un Authentication Policy Silo (APS) a un account serve per applicare restrizioni avanzate di autenticazione e migliorare la sicurezza di quell’account in un ambiente Active Directory.

Dopo aver assegnato il Silo, l’account (utente o computer):

• Sarà vincolato ai criteri di autenticazione definiti nell’Authentication Policy associata al Silo.
• Sarà protetto dalle restrizioni avanzate, come la durata dei ticket Kerberos, limitazioni sui dispositivi, e altre regole specifiche configurate nella policy.

Nota importante : Se avete configurato il Silo in modalità “Enforce“, tutte le restrizioni verranno applicate immediatamente agli account associati. In alternativa, se il Silo è in modalità “Audit“, potrete monitorare il comportamento degli account senza che le restrizioni vengano applicate.

Figura 7: Assegnazione della Authentication Policy Silo (APS) a un computer account

Figura 8: Assegnazione della Authentication Policy Silo (APS) a un user account

Modificare la policy per imporre le restrizioni

Una volta creata la policy, sarà necessario modificarla in modo tale che l’autenticazione di un utente o di un account sia consentita solo se l’account appartiene effettivamente al Silo specificato.

La modifica della policy con la condizione User.AuthenticationSilo Equals “Privileged-Access-Restriction-Silo” serve a vincolare gli account associati al Silo di autenticazione denominato Privileged-Access-Restriction-Silo.

Questa regola garantisce che solo gli account correttamente configurati e assegnati al Privileged-Access-Restriction-Silo possano essere autenticati. È una misura di sicurezza aggiuntiva per:

• Limitare l’accesso: Solo gli account associati a quel Silo possono autenticarsi. Gli altri account, anche se tentano di accedere, vengono bloccati.
• Implementare isolamento logico: Gli account che non soddisfano questa condizione non possono utilizzare le risorse protette da questa policy, isolando gli account privilegiati o sensibili.

 

Come funziona nella pratica?

Quando un utente tenta di autenticarsi, il processo di autenticazione verifica se l’attributo AuthenticationSilo dell’account corrisponde al nome del Silo specificato nella policy (“Privileged-Access-Restriction-Silo”). Se questa condizione non è soddisfatta, l’autenticazione viene negata.

Esempio:

1. Un utente (ad esempio, User1) appartiene al Silo Privileged-Access-Restriction-Silo.
2. La policy specifica che solo gli account con AuthenticationSilo = “Privileged-Access-Restriction-Silo” possono autenticarsi.
3. Se User1 tenta di autenticarsi, il sistema verifica che l’attributo AuthenticationSilo dell’utente corrisponda al valore richiesto dalla policy.
4. Se l’attributo corrisponde, l’autenticazione viene approvata; altrimenti viene bloccata.

La condizione, di fatto, limita l’autenticazione esclusivamente agli account assegnati al Silo specificato. È particolarmente utile per proteggere account privilegiati e isolare risorse critiche.

Figura 9: Modifica della policy con la condizione User.AuthenticationSilo Equals “Privileged-Access-Restriction-Silo” per vincolare gli account associati al Silo di autenticazione denominato Privileged-Access-Restriction-Silo

Figura 10: Modifica della policy con la condizione User.AuthenticationSilo Equals “Privileged-Access-Restriction-Silo” per vincolare gli account associati al Silo di autenticazione denominato Privileged-Access-Restriction-Silo

Per verificare che il Silo e le relative configurazioni siano applicate correttamente potete visualizzarne le proprietà e noterete la presenza dei segni di spunta verde accanto alla risorse che sono state assegnate al Silo, come mostrato nella figura sotto:

Figura 11: Verifica delle configurazioni applicate al Silo

Applicazione delle Authentication Policies e degli Authentication Policy Silos

Quando vengono apportate modifiche alle Authentication Policies o ai Silos di autenticazione, il sistema utilizza i Kerberos Ticket Granting Tickets (TGT) per autenticare gli account. Tuttavia, i TGT esistenti memorizzati nella cache potrebbero non riflettere immediatamente le nuove policy. Di conseguenza, le vecchie configurazioni potrebbero continuare a essere applicate fino a quando i ticket nella cache non scadono o vengono eliminati.

Eseguire klist purge forza la rimozione dei ticket memorizzati nella cache sul Domain Controller, assicurando che:

• Tutte le richieste di autenticazione successive utilizzino i nuovi criteri configurati nelle Authentication Policies o nei Silos.
• Si evitino conflitti o comportamenti non desiderati dovuti all’uso di ticket obsoleti.

 

NOTA: Riavviate i domain controller e i client per ottenere i claims che indicheranno che faranno parte del Silo creato.

Figura 12: Rimozione dei ticket memorizzati nella cache sul Domain Controller

Test di funzionamento

Per testare il funzionamento delle Authentication Policies e degli Authentication Policy Silos configurati è sufficiente collegarsi come User 1 sul PC BZ-FS1 (i due account che abbiamo configurato nella nostra policy).

Come si può vedere dalla figura sotto, l’account User 1 è riuscito ad effettuare il login al BZ-FS1. Utilizzando il comando whoami /claims si noterà che l’utente possiede il claim relativo all’Authentication Silo configurato.

Figura 13: L’account User 1 è riuscito ad effettuare il login al BZ-FS1

Se User 1 tenta di autenticarsi ad un computer che non fa parte dell’Authentication Silo riceverà un messaggio di errore. Nelle figure sotto viene mostrato sia un tentativo di un accesso interattivo che di un tentativo di accesso in desktop remoto.

Figura 14: Tentativo di accesso interattivo ad un computer non contenuto nell’Authentication Silo

Figura 15: Tentativo di accesso tramite desktop remoto ad un computer non contenuto nell’Authentication Silo

Troubleshooting

Abilitare l’opzione di Audit user/device claims tramite i criteri di gruppo (Group Policy) è un passaggio essenziale per monitorare, risolvere i problemi e verificare che le Authentication Policies e i Policy Silos siano applicati correttamente in Active Directory. Questo tipo di auditing consente di registrare dettagli relativi alle claims di utenti e dispositivi durante il processo di autenticazione.

Scegliete una Group Policy Object (GPO) esistente o createne una nuova per configurare l’auditing e modificate il parametro Policies > Windows Settings > Security Settings > Advanced Auditing Policy Configuration > Audit Policies > Logon/Logoff. Io ho deciso di modificare la Default Domain Controllers policy.

Figura 16: Advanced Audit policy

Sui domain controller poi potrete verificare gli event ID 4626, che vi mostreranno i claim rilasciati sia per i computer che per gli utenti.

Sui domain controller esiste anche un log specifico nel ramo Microsoft > Windows >Authentication/AuthenticationPolicyFailures-DomainController che è disabilitato di default e va abilitato manualmente su TUTTI i domain controller. Questo log permette di visualizzare tutti i login che non sono andati a buon fine per colpa/merito della Authentication policy.

Figura 17: Abilitazione del log sui Domain controller per il controllo dell’efficacia delle authentication policy

Quando un utente si logga su un dispositivo dove non è autorizzato, un messaggio di errore viene scritto nel log, come mostrato nella figura sotto:

Figura 18: Messaggio di errore quando un utente tenta di accedere a un computer a cui non ha i permessi di accesso per colpa dell’authentication policy

Utilizzo delle Authentication Policies e degli Authentication Policy Silos per l’Active Directory Tier model

L’utilizzo delle Authentication Policies e degli Authentication Policy Silos nel contesto del Active Directory Tier Model è una soluzione altamente efficace per rafforzare la sicurezza di un’infrastruttura Active Directory (AD). Questo approccio consente di isolare gli account e i sistemi nei rispettivi livelli (Tier) e applicare regole specifiche di autenticazione e accesso per limitare i rischi di compromissione.

Cos’è l’Active Directory Tier Model?

L’AD Tier Model è un framework di sicurezza che suddivide l’infrastruttura di Active Directory in tre livelli o “Tier” per garantire l’isolamento e ridurre il rischio di escalation in caso di compromissione:

• Tier 0: Contiene i sistemi e gli account più critici, come i Domain Controller, i server AD FS e gli account amministrativi di livello superiore.
• Tier 1: Include i server e i sistemi di applicazione aziendale (ad esempio, i server di file, database e applicazioni).
• Tier 2: Contiene i dispositivi degli utenti finali, come workstation e laptop.

Il principio fondamentale è che gli account o i sistemi di un Tier non devono interagire o autenticarsi con sistemi appartenenti a un Tier superiore. Ne abbiamo già parlato nella guida Implementare Active Directory Tier Model – ICT Power

Come si applicano Authentication Policies e Silos nel Tier Model?

Le Authentication Policies e i Silos possono essere configurati per garantire che gli account di ogni Tier rispettino rigorosamente i confini del modello. Questo avviene tramite:

• Isolamento degli account privilegiati per Tier:
  • Gli account amministrativi di Tier 0 (ad esempio, amministratori di dominio) vengono isolati e possono autenticarsi solo sui sistemi di Tier 0, come i Domain Controller.
  • Gli account amministrativi di Tier 1 vengono confinati ai server e alle applicazioni di Tier 1.
  • Gli account utente standard di Tier 2 sono limitati all’accesso ai dispositivi degli utenti finali.
• Restrizioni di accesso tramite Authentication Policies:
  • Le Authentication Policies possono essere configurate per consentire agli account di accedere solo ai sistemi e alle risorse del proprio Tier.
  • Ad esempio, una policy può limitare gli account di Tier 0 affinché possano autenticarsi solo da workstation sicure approvate per l’amministrazione.
• Utilizzo dei Silos per raggruppare e proteggere gli account:
  • Ogni Tier può avere uno o più Authentication Policy Silos per organizzare e proteggere gli account associati.
  • Gli account assegnati a un Silo ereditano automaticamente le regole di autenticazione definite nella Authentication Policy associata al Silo.

Configurazione passo-passo per l’AD Tier Model

• Creazione dei Silos per ogni Tier:
  • Create un Authentication Policy Silo per ciascun Tier (ad esempio, “Tier-0-Silo”, “Tier-1-Silo”, “Tier-2-Silo”).
  • Assegnate a ogni Silo gli account appropriati (ad esempio, amministratori di dominio per Tier 0, amministratori di server per Tier 1 e utenti finali per Tier 2).
• Configurazione delle Authentication Policies:
  • Create Authentication Policies specifiche per ogni Tier.
    • Per il Tier 0, configurate una policy che consenta l’autenticazione solo sui Domain Controller e da dispositivi sicuri.
    • Per il Tier 1, consentite l’accesso ai server aziendali, limitando l’autenticazione a subnet specifiche.
    • Per il Tier 2, permettete l’accesso solo alle workstation o ai laptop utente.
  • Associate ciascuna policy al Silo corrispondente.
• Impostazione delle restrizioni sui dispositivi:
  • Configurate le Authentication Policies per applicare restrizioni sui dispositivi da cui gli account possono autenticarsi. Ad esempio, limitate gli amministratori di Tier 0 all’utilizzo di workstation di amministrazione dedicate.
• Monitoraggio e auditing:
  • Configurate i Silos in modalità Audit inizialmente, per monitorare eventuali problemi prima di applicare le restrizioni in modalità Enforce.
  • Utilizzate il registro eventi e strumenti di monitoraggio come Event Viewer per verificare il comportamento degli account e l’applicazione delle policy.

 

L’utilizzo delle Authentication Policies e degli Authentication Policy Silos nel contesto del Active Directory Tier Model è una soluzione altamente efficace per rafforzare la sicurezza di un’infrastruttura Active Directory (AD). Questo approccio consente di isolare gli account e i sistemi nei rispettivi livelli (Tier) e applicare regole specifiche di autenticazione e accesso per limitare i rischi di compromissione.

 

Esempio pratico

• Scenario 1: Tier 0 (Domain Controller e amministratori di dominio):
  • Silo: “Tier-0-Silo”.
  • Authentication Policy: Consente agli amministratori di autenticarsi solo sui Domain Controller e da workstation di amministrazione specifiche.
  • Effetto: Gli amministratori di Tier 0 non possono autenticarsi su sistemi di Tier 1 o Tier 2.
• Scenario 2: Tier 1 (Server applicativi e amministratori di server):
  • Silo: “Tier-1-Silo”.
  • Authentication Policy: Limita l’autenticazione degli amministratori di server alle macchine di Tier 1 e a subnet specifiche.
  • Effetto: Gli amministratori di Tier 1 non possono accedere ai Domain Controller di Tier 0.
• Scenario 3: Tier 2 (Utenti finali e workstation):
  • Silo: “Tier-2-Silo”.
  • Authentication Policy: Permette agli utenti di accedere solo alle proprie workstation e blocca l’accesso ai server di Tier 1 o ai Domain Controller di Tier 0.
  • Effetto: Gli utenti finali sono confinati alle proprie workstation.

 

Conclusioni

L’integrazione tra Authentication Policies, Authentication Policy Silos e il Active Directory Tier Model rappresenta un approccio organico e avanzato per rafforzare la sicurezza in un’infrastruttura Active Directory. Le Authentication Policies offrono un controllo granulare sull’autenticazione, consentendo di definire criteri precisi, come la durata dei ticket Kerberos, i dispositivi autorizzati e i requisiti di rete. Questo tipo di configurazione migliora significativamente la protezione degli account, in particolare di quelli privilegiati, prevenendo attacchi noti come il pass-the-hash e il pass-the-ticket.

Gli Authentication Policy Silos aggiungono un ulteriore livello di protezione, isolando gli account critici in contenitori logici. Questo isolamento garantisce che gli account sensibili siano separati dagli altri, riducendo i rischi di compromissione laterale o a cascata. I Silos centralizzano inoltre l’applicazione delle Authentication Policies, semplificando la gestione e rafforzando la sicurezza complessiva.

Il modello Tier di Active Directory introduce una struttura chiara per isolare gli account e i sistemi in tre livelli: il Tier 0 per i sistemi e gli account più critici, il Tier 1 per i server e le applicazioni aziendali e il Tier 2 per i dispositivi degli utenti finali. Questo modello riduce drasticamente il rischio di escalation delle minacce, confinando ogni account e sistema al proprio livello e garantendo che non ci siano interazioni tra livelli diversi senza autorizzazioni specifiche.

L’implementazione combinata di questi strumenti consente di raggiungere un elevato livello di protezione, riducendo la superficie di attacco e prevenendo compromissioni catastrofiche. La sicurezza di Active Directory ne risulta significativamente migliorata, permettendo alle organizzazioni di affrontare le minacce informatiche in modo proattivo e strutturato.