Criteri di autenticazione e silo Active Directory, Tier 0: il controllo Kerberos che (quasi) nessuno distribuisce

Criteri di autenticazione e silo Active Directory, Tier 0: cosa sono davvero

La protezione tramite criteri di autenticazione e silo Active Directory Tier 0 è un'unica funzionalità di Windows Server 2012 R2 che la maggior parte degli ambienti non ha ancora attivato, anche a distanza di un decennio dal rilascio. Un silo di criteri di autenticazione è un contenitore AD (objectClass msDS-AuthNPolicySilos) che raggruppa gli account utente, computer e servizio che si vogliono proteggere insieme. Un criterio di autenticazione (objectClass msDS-AuthNPolicies) è l'insieme di regole applicato a quel contenitore: per quanto tempo può vivere un ticket Kerberos (TGT, ticket-granting ticket), da quali dispositivi un account è autorizzato ad accedere, e quali principal possono autenticarsi presso un servizio eseguito con quell'account.

L'idea è semplice: gli account Domain Admins dovrebbero autenticarsi solo da una manciata di workstation di amministrazione privilegiata (PAW) e controller di dominio. I criteri di autenticazione e i silo sono il meccanismo che trasforma questa assunzione in qualcosa che il KDC applica realmente, invece di una regola che vive solo in un documento di onboarding.

Un account può appartenere a un solo silo. Una volta assegnato, il controller di dominio allega un'attestazione di silo di criteri di autenticazione al ticket Kerberos dell'account al momento dell'accesso, attestazione che le risorse compatibili con le attestazioni possono usare per i propri controlli di accesso, in aggiunta a quanto già limitato dal criterio del silo.

L'esempio pratico di Microsoft illustra bene l'intento: costruire un silo "Amministratori della foresta" contenente gli account Enterprise Admins, Schema Admins e Domain Admins, e poi applicare un criterio in modo che l'accesso tramite password o smart card da qualsiasi cosa diversa da un controller di dominio o una console di amministrazione designata fallisca senza appello. Al silo non importa come sia stata ottenuta la credenziale — phishing, replay, o digitata correttamente dal vero amministratore — conta solo se il dispositivo di origine è nella lista consentita.

Un singolo silo può contenere tutte e tre le classi di account Active Directory — utente, computer e account di servizio gestito — ma il criterio si comporta in modo diverso per ciascuna classe. Gli account di servizio e computer non dovrebbero mai entrare nel gruppo Protected Users: il motivo indicato da Microsoft è che ogni autenticazione in ingresso fallisce per questi tipi di account, e l'appartenenza non offre comunque alcuna protezione locale perché la password o il certificato sono sempre presenti sull'host. Microsoft sconsiglia inoltre di configurare una durata del TGT per gli account computer. La distinzione per tipo di account conta quanto l'appartenenza al silo in sé.

Come funziona: durata del TGT, attestazioni e il requisito di armoring

I criteri di autenticazione agiscono in due punti dello scambio Kerberos: lo scambio AS (accesso iniziale, emissione del TGT) e lo scambio TGS (richieste di ticket di servizio). Si possono limitare tre cose:

1. Durata del TGT — impostata a un valore più breve e non rinnovabile rispetto al valore predefinito del dominio (4 ore è ciò che i membri del gruppo Protected Users ottengono automaticamente). Un account Tier 0 con un TGT non rinnovabile di 1 ora offre una finestra molto più ridotta a un attaccante che ruba un ticket.
2. AllowedToAuthenticateFrom — l'insieme dei dispositivi da cui un utente può accedere. Applicato nello scambio AS.
3. AllowedToAuthenticateTo — l'insieme dei principal autorizzati ad autenticarsi presso un servizio eseguito con questo account. Applicato nello scambio TGS.

Le restrizioni sui dispositivi sono il punto in cui si arenano la maggior parte delle implementazioni. Verificare AllowedToAuthenticateFrom richiede l'armoring Kerberos (FAST): il KDC ha bisogno del TGT del dispositivo richiedente per validarne l'identità prima di poter decidere se quel dispositivo è nella lista consentita. Le due impostazioni di Group Policy che attivano l'armoring arrivano su Non configurata in un dominio predefinito — lo abbiamo trattato separatamente — quindi su un dominio non modificato, la restrizione di accesso semplicemente non funziona in silenzio, anche se la restrizione sulla durata del TGT continua a funzionare. È un prerequisito qui, non un rafforzamento opzionale in più.

Ogni silo di criteri di autenticazione parte in modalità solo controllo (audit) — l'equivalente PowerShell di -WhatIf. La modalità audit registra ciò che fallirebbe senza bloccare nulla, che è il modo previsto per rodare un criterio prima che un amministratore si blocchi fuori dal proprio dominio.

Perché questo controllo resta inutilizzato nella maggior parte delle architetture Tier 0

Tre punti di attrito spiegano perché i criteri di autenticazione e i silo raramente escono dalla fase pilota, anche in ambienti che per il resto prendono sul serio l'amministrazione a livelli.

Un livello funzionale di dominio che nessuno rivede più

Durate del TGT personalizzate richiedono il livello funzionale di dominio Windows Server 2012 R2 sul dominio account. Limitare l'accesso utente richiede lo stesso DFL sul dominio account con supporto per il controllo dinamico degli accessi, più dispositivi client che supportino a loro volta il controllo dinamico degli accessi. Limitare l'emissione dei ticket di servizio è un requisito sul dominio risorsa, che deve essere a sua volta al DFL 2012 R2 — quindi un'architettura Tier 0 tra domini ha due livelli funzionali da verificare, non uno solo. Molti domini hanno alzato il proprio DFL anni fa per un motivo non correlato — una migrazione di trust di foresta, un'estensione dello schema per un altro progetto — e non sono mai tornati a chiedersi cos'altro quel livello funzionale avesse sbloccato. I silo di criteri di autenticazione restano su quella lista, inutilizzati, perché nulla spinge un amministratore ad andarli a cercare.

Nessuna eccezione, nessuna via di fuga

Una volta che un account rientra nelle restrizioni di autenticazione, non esiste alcuna soluzione alternativa: un Domain Admin bloccato da un silo applicato resta bloccato, punto (RID 500 a parte). Microsoft formula la sua versione più netta di questo avvertimento a proposito del gruppo Protected Users piuttosto che dei silo, ma la modalità di fallimento è la stessa: le restrizioni di autenticazione non hanno soluzioni alternative, gli Enterprise Admins e i Domain Admins vi sono soggetti come chiunque altro, e iscrivere tutti i membri di quei gruppi in una volta sola può bloccarli tutti — inclusi gli account che normalmente risolverebbero il problema. La guida specifica di Microsoft per i criteri di autenticazione e i silo è procedurale più che rassicurante: mantenere client e controller di dominio connessi alla rete, ruotare le password degli account protetti in seguito, e disabilitare l'accesso memorizzato nella cache dove possibile. Questo profilo di rischio basta a far sì che la maggior parte dei team si fermi a un pilota di uno o due account di test senza mai andare oltre.

La dipendenza dall'armoring

Ottenere un vero valore dalle restrizioni sui dispositivi richiede che l'armoring Kerberos funzioni già, e l'armoring stesso è una modifica GPO separata sia sui controller di dominio sia sui client che la maggior parte dei team non ha fatto — vedi il requisito sopra. Fare un pilota dei criteri di autenticazione senza prima l'armoring significa pilotare una funzionalità che, in silenzio, fa solo metà di quello che dovrebbe fare.

Nessuno di questi è un motivo per saltarlo. Un TGT accorciato e non rinnovabile sugli account Tier 0 riduce direttamente la finestra per un ticket rubato — il caso del pass-the-ticket, in cui un attaccante estrae un TGT legittimo dalla memoria e lo riusa finché resta valido.

Bisogna essere precisi su cosa non copre. Un criterio di autenticazione plasma il ticket che il KDC emette: il controller di dominio restituisce un TGT non rinnovabile con la durata configurata quando risponde a una richiesta AS, e verifica la restrizione di accesso rispetto alla richiesta AS blindata (armored). Un Golden Ticket viene forgiato offline con la chiave krbtgt e non passa mai da uno scambio AS, quindi porta con sé la durata e l'identità scelte dall'attaccante — la durata del TGT del silo e la sua restrizione di accesso non hanno alcun potere su di esso. Ciò che può ancora colpire un ticket forgiato è il controllo lato TGS: un servizio il cui account porta una condizione AllowedToAuthenticateTo viene valutato quando il ticket di servizio viene richiesto, non quando il TGT è stato creato. Anche questo ha un limite — resta comunque un controllo lato KDC, e un Silver Ticket viene forgiato contro la chiave stessa del servizio e presentato direttamente all'host senza che il controller di dominio venga mai interpellato, quindi nessun criterio di autenticazione lo vede mai.

Configurare un silo di criteri di autenticazione

La guida completa si trova nella guida Microsoft per configurare gli account protetti; in sintesi:

1. Attivare l'armoring Kerberos

Tramite Group Policy, su controller di dominio e client:

Configurazione computer > Modelli amministrativi > Sistema > KDC
  "Supporto client del Centro distribuzione chiavi (KDC) per attestazioni, autenticazione
   composta e blindatura Kerberos" → Abilitata, "Fornisci sempre attestazioni"

Configurazione computer > Modelli amministrativi > Sistema > Kerberos (client)
  "Supporto client Kerberos per attestazioni, autenticazione composta
   e blindatura Kerberos" → Abilitata

Conferma con un accesso di prova da un client aggiunto al dominio prima di toccare qualsiasi criterio — altrimenti i fallimenti dell'armoring sono silenziosi, e non conviene eseguire il debug di due nuove funzionalità contemporaneamente.

2. Creare il criterio di autenticazione

Impostare una durata del TGT in minuti:

New-ADAuthenticationPolicy -Name "Tier0-AdminPolicy" `
  -UserTGTLifetimeMins 60 `
  -Description "Account admin Tier 0 - TGT non rinnovabile di 1h"

3. Creare il silo — non applicato per impostazione predefinita

New-ADAuthenticationPolicySilo -Name "Tier0-Silo"

Ogni nuovo silo parte in modalità audit. Aggiungi -Enforce solo una volta che il periodo di audit è pulito — è l'equivalente integrato di -WhatIf, ed esiste proprio perché un errore di battitura in una condizione di controllo di accesso non blocchi l'account che avrebbe potuto risolvere il problema.

4. Concedere l'accesso e assegnare gli account

Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "da-jsmith"

Get-ADUser -Filter 'Name -like "da-*"' |
  Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo "Tier0-Silo" `
    -AuthenticationPolicy "Tier0-AdminPolicy"

Un account deve sia ricevere l'accesso al silo sia avere assegnata la coppia silo/criterio — concedere solo l'accesso non iscrive l'account.

5. Rodare, poi applicare

Set-ADAuthenticationPolicySilo -Identity "Tier0-Silo" -Enforce $true
Set-ADAuthenticationPolicy -Identity "Tier0-AdminPolicy" -Enforce $true

Il silo e il criterio hanno ciascuno il proprio flag Enforce — attivarne solo uno lascia l'altro in modalità audit, il che è una fonte comune di confusione del tipo "perché questo non ha bloccato nulla" durante il rollout.

Rilevamento

Gli eventi vivono in un log operativo disabilitato per impostazione predefinita — abilitarlo è il passo zero perché tutto questo diventi visibile:

Visualizzatore eventi > Registri applicazioni e servizi > Microsoft > Windows >
Authentication > AuthenticationPolicyFailures-DomainController → Abilita registro

Un picco di 105/106 dopo che un silo passa da audit ad applicato è o un blocco legittimo da correggere (un PAW non ancora nella lista consentita), o un vero tentativo di usare una credenziale Tier 0 da un punto in cui non dovrebbe — entrambi i casi meritano un'allerta.

Rimedio (Remediation)

1. Fai l'inventario degli account Tier 0 e dell'insieme esatto di host da cui dovrebbero potersi mai autenticare (PAW, controller di dominio — nient'altro).
2. Attiva l'armoring Kerberos tramite GPO sui controller di dominio e sui client idonei Tier 0; conferma con un accesso di prova prima di toccare qualsiasi criterio.
3. Crea il criterio di autenticazione e il silo in modalità audit; lasciali non applicati per almeno un intero ciclo operativo.
4. Abilita il log AuthenticationPolicyFailures-DomainController ed esamina gli eventi 305/306 per individuare falsi positivi — PAW mancanti, jump host dimenticati.
5. Applica il silo e il criterio. Ruota immediatamente la password di ogni account iscritto.
6. Abbina questo all'appartenenza al gruppo Protected Users per gli account che non necessitano di delega Kerberos — Protected Users blocca inoltre NTLM, la preautenticazione DES/RC4, e sia la delega vincolata sia quella non vincolata senza eccezioni. Non aggiungere mai account di servizio o computer a Protected Users: ogni autenticazione in ingresso fallisce per questi tipi di account.

Come EtcSec rileva questo problema

L'audit Active Directory di EtcSec segnala l'assenza di questo controllo da diverse angolazioni piuttosto che con un unico controllo: NOT_IN_PROTECTED_USERS individua gli account privilegiati esclusi dal gruppo Protected Users, WEAK_KERBEROS_POLICY segnala un dominio la cui durata massima del ticket resta sopra le 10 ore o la cui finestra di rinnovo supera i 7 giorni, FGPP_NOT_CONFIGURED segnala un dominio privo di qualsiasi criterio di password granulare, e i controlli allineati ANSSI ANSSI_R40_NO_PSO_TIER0 e ANSSI_R82_R83_ADMIN_ARCHITECTURE segnalano specificamente i gruppi admin Tier 0 non coperti da un criterio granulare dedicato o da alcun controllo di restrizione dell'accesso.