Active Directory - Doube Hop Kerberos Delegation
Introduzione
Dopo la migrazione dei servizi applicativi su nuove macchine Windows Server 2022 sono emersi alcuni problemi. Attraverso un'attenta analisi si è riscontrato che il problema era imputabile a una configurazione errata della delega Kerberos in Active Directory. L'esistenza di un'ambiente di collaudo ha permesso le attività correttive senza impattare la produzione.
Il cliente
Il nostro Cliente, una società FinTech, si distingue per la sua capacità di offrire un'ampia gamma di servizi finanziari e di pagamento sia per il cittadino che per le imprese.
Le basi
Nell'autenticazione Kerberos, un Ticket Granting Ticket (TGT) è un token di autenticazione dell'utente emesso dal Key Distribution Center (KDC) che viene utilizzato per richiedere i token di accesso al Ticket Granting Service (TGS) per specifiche risorse del dominio.
Il TGT è il ticket iniziale richiesto dai client per ottenere altri ticket, viene fornito al client per dimostrare la sua identità e autenticità. I TGT vengono utilizzati successivamente nel processo di autenticazione Kerberos per richiedere l'accesso ad altri servizi, che in cambio forniscono ulteriori ticket per l'accesso.
Un servizio è un processo eseguito su un computer che funge da host. I servizi sono identificati con un SPN (service principal name) e vengono eseguiti nel contesto di un utente del dominio per acquisire un TGT dal TGS.
Solitamente i servizi vengono eseguiti nel contesto dell'account del computer che li ospita, ma questo non è sempre vero
Un account di servizio è un account speciale utilizzato da un'applicazione e non da un utente.
La parte più importante è capire che i servizi (come qualsiasi processo) che sono in esecuzione nel contesto di un account utente e quindi hanno i privilegi e i permessi di quell'utente.
Un SPN è il nome in base al quale un client identifica in modo univoco un'istanza di un servizio. Questo nome può essere utilizzato dal servizio di autenticazione Kerberos per l'autenticazione di un servizio. Per connettersi a un servizio, un client individua un'istanza del servizio, compone un nome SPN per l'istanza, esegue la connessione al servizio e presenta il nome SPN al servizio per l'autenticazione.
La delega Kerberos è un'estensione del protocollo di autenticazione Kerberos che consente a un server di agire come intermediario, impersonando un client e acquisendo ticket per accedere a risorse di rete aggiuntive. In questo modo, il server può sfruttare l'identità autenticata del client per eseguire azioni per suo conto, senza richiedere al client una nuova autenticazione per ogni singola risorsa.
Kerberos Unconstrained e Constrained Delegation
Esisono tre tipologie di delega in Active Directory:
- Delega non vincolata
- Delega vincolata
- Delegata vincolata basata sulle risorse
- In giallo, la prima opzione consente di configurare un account in modo che NON possa essere considerato attendibile per la delega, comunemente usato su account sensibili o amministrativi che non dovrebbero mai essere usati per la delega
- La seconda opzione, in verde, consente di configurare un account per la delega non vincolata
- La terza opzione, in rosso, consente di configurare un account per la delega vincolata
La delega non vincolata consente a un utente o a un computer con l'opzione "Trust This user/computer for delegation to any service" abilitata di impersonare QUALSIASI utente autenticato e di richiedere l'accesso a QUALSIASI servizio (per questo motivo è meno sicura e non andrebbe utilizzata).
La delega vincolata è una funzionalità che offre agli amministratori dei servizi la possibilità di specificare e applicare i limiti di attendibilità delle applicazioni limitando l'ambito in cui i servizi delle applicazioni possono agire per conto di un utente. Ciò può essere utile quando è necessario configurare quali account del servizio front-end possono delegare ai propri servizi back-end.
Un utente si autentica su un web server di destinazione e poi tale server preleva alcuni contenuti da un server terzo. Come fa il Web Server ad autenticarsi contro il File Server per prelevare il contenuto?
- Utilizzare un utente generico (serviceuser@dominio.local)
- Utilizzare l'identità dell'utente che si è appena autenticato sul web server
In questo esempio, per l'opzione 2, si dovrà configurare la delega vincolata per il serviceuser@dominio.local
La delega vincolata basata su risorse cambia il modo in cui è possibile configurare la delega vincolata e funziona attraverso un trust. Invece di specificare quale oggetto può delegare a quale servizio, la risorsa che ospita il servizio specifica quali oggetti possono delegare ad esso. Da un punto di vista amministrativo, ciò consente al proprietario della risorsa di controllare chi può accedervi. Ad esempio, invece di specificare con delega vincolata che l'account del servizio WebServer può delegare al servizio SQL per accedere al database, è possibile specificare sull'account del servizio SQL Server che l'account del servizio WebServer dispone delle autorizzazioni per delegare l'accesso ad esso.
Kerberos Double Hop è un termine utilizzato per descrivere il mantenimento delle credenziali di autenticazione Kerberos del client su due o più connessioni.
Esistono dei requisiti affinché un servizio possa eseguire il double hop di Kerberos. L'account del servizio deve essere trustato per la delega (per agire per conto di un altro utente). Poi i server di origine e di destinazione devono trovarsi nella stessa foresta o deve esistere un trust a livello di foresta tra le foreste e l'account di servizio di primo livello deve trovarsi nella root della foresta fidata.
Analisi del problema
Di fronte al problema abbiamo intrapreso una fase di analisi preliminare per circoscrivere e comprendere appieno la natura del problema. Riconoscendo l'importanza di una metodologia strutturata per affrontare le sfide complesse, abbiamo optato per la realizzazione di un disegno dettagliato che ci avrebbe permesso di analizzare lo scenario ad alto livello.
Il disegno ha avuto lo scopo di mappare il flusso di autenticazione e autorizzazione all'interno dell'ambiente Active Directory del cliente.
Durante questa fase, abbiamo anche condotto un'analisi approfondita delle configurazioni esistenti, esaminando le impostazioni di delega Kerberos, le autorizzazioni dei servizi applicativi e le interazioni tra i componenti dell'infrastruttura. Questo approccio ci ha permesso di ottenere una visione chiara delle relazioni e delle dipendenze tra i vari elementi dell'ambiente, facilitando l'individuazione delle cause sottostanti al problema.
Soluzione
La prima azione intrapresa è stata l'attivazione dei log avanzati per Kerberos su tutte le macchine coinvolte nel processo di autenticazione e autorizzazione.
Successivamente attraverso un'analisi dei servizi applicativi e dei relativi account, abbiamo assicurato che ogni servizio disponesse di un SPN correttamente configurato, consentendo una corretta autenticazione e autorizzazione all'interno dell'ambiente Active Directory.
Parallelamente, abbiamo rivisto e aggiornato le configurazioni di delega Kerberos per gli account coinvolti nel processo, garantendo che le autorizzazioni fossero correttamente assegnate.
Infine abbiamo collaborato con il cliente per condurre un test per verificare che tutto funzionasse come previsto e che il problema fosse stato risolto.
Tools
- KerbTray
- KList
- Kerberos Event logging
Riferimenti
- https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/understanding-kerberos-double-hop/ba-p/395463
- https://learn.microsoft.com/it-it/windows-server/security/kerberos/kerberos-constrained-delegation-overview
- https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-kerberos-event-logging