I Domain Controller di Active Directory risultano sempre “Trusted for delegation”. È normale? In questo articolo spieghiamo perché non puoi disattivare l’unconstrained delegation sui DC, i rischi reali e le mitigazioni operative da applicare subito.
Panoramica del problema
Per impostazione predefinita, tutti i Domain Controller (DC) di Active Directory sono contrassegnati come Trusted for delegation, ossia abilitati alla delegazione non vincolata (unconstrained delegation). Amministratori e team di sicurezza si chiedono spesso se sia possibile disattivare questa impostazione per “chiudere” una superficie d’attacco. La risposta breve è: no, non in modo supportato o sostenibile. La risposta utile è: mitiga i rischi dove serve davvero e rinforza i controlli intorno ai DC.
Cos’è la delegazione in Kerberos (e perché interessa i DC)
Kerberos è il protocollo di autenticazione nativo di Active Directory. Il flusso più importante consiste in:
- Il client ottiene un TGT (Ticket-Granting Ticket) dal KDC (che nei domini AD è eseguito sui DC).
- Il client scambia il TGT per uno o più TGS (service ticket) verso i servizi di destinazione (LDAP, SMB, HTTP, MSSQL, ecc.).
- In scenari “a salto” (il cosiddetto double hop), un servizio intermedio deve agire a nome dell’utente verso un altro servizio. È qui che entra in gioco la delegazione.
Esistono tre modelli di delegazione:
- Unconstrained delegation: il servizio può impersonare l’utente verso qualunque altro servizio. È il comportamento dei DC, by design.
- Constrained Delegation (KCD): la delegazione è limitata a una lista di SPN (service principal) predefiniti.
- Resource‑Based Constrained Delegation (RBCD): è la risorsa di destinazione a definire chi è autorizzato a delegare verso di essa, modello consigliato per i workload moderni perché più granulare e più vicino al principio del least privilege.
La realtà tecnica sui Domain Controller
Su un DC, la delegazione non vincolata non è un optional: è un requisito funzionale. Ecco i punti chiave da conoscere:
- Non è possibile rimuoverla in modo supportato. Il bit
TRUSTEDFORDELEGATIONsull’oggetto computer del DC viene ripristinato automaticamente dai servizi di base (NetLogon/KDC) a ogni avvio del sistema. - Le modifiche manuali vengono annullate. Se imposti “Do not trust this computer for delegation” su un DC, l’opzione viene sovrascritta nel giro di pochi secondi; il comportamento è voluto e documentato.
- Perché? Il DC non è solo KDC: esegue LDAP, replica AD, DFS/SYSVOL, spesso DNS integrato. Per erogare questi servizi deve poter presentare credenziali a nome degli utenti e dei servizi, operando con ticket FORWARDABLE. Senza, molte operazioni di base fallirebbero (autenticazione Kerberos, trust inter-foreste, gestione remota, double hop di strumenti Microsoft, ecc.).
Cosa succede se provi a disattivarla
Puoi disattivare temporaneamente il flag da interfaccia (ADUC) o via PowerShell, ma:
- Il DC torna “Trusted for delegation” automaticamente.
- L’eventuale forzatura con procedure non supportate può rompere autenticazioni e servizi di dominio fondamentali.
- La riduzione del rischio percepita è illusoria: se un attore minaccia ha esecuzione codice su un DC, ha già raggiunto il livello Tier‑0.
Da qui la regola d’oro: non cercare di disattivare l’unconstrained delegation sui DC. Concentrati invece sulla mitigazione a più livelli (host, identità, rete, monitoraggio).
Rischi di sicurezza: cosa temere (e cosa no)
La delegazione non vincolata espone a rischio soprattutto quando un server non di fiducia riceve TGT/TGS forwardable e un attaccante può estrarre ticket dalla memoria per impersonare utenti verso altri servizi. Tuttavia, per i DC il discorso è diverso:
- Il DC è già Tier‑0. Se compromesso, l’attaccante ha la chiave del regno, a prescindere dalla delegazione. Il focus deve essere prevenire l’accesso al DC e isolare il Tier‑0.
- I rischi più concreti sono laterali: sessioni privilegiate aperte dal DC verso altri sistemi, con possibilità di riutilizzo dei ticket se questi sono estraibili dai server intermedi.
Conclusione: trattiamo i DC come asset ultra‑sensibili, riducendo al minimo accessi e movimenti di credenziali, e portiamo la delegazione granulare (KCD/RBCD) sui server applicativi.
Linee guida di mitigazione (soluzioni pratiche)
| Obiettivo | Azioni consigliate |
|---|---|
| Ridurre la superficie d’attacco sui DC | • Impedire il logon interattivo, RDP o con credenziali privilegiate direttamente sui DC; usare jump server sicuri. • Applicare il criterio GPO “Deny log on locally” ai gruppi d’utente non necessari. |
| Proteggere gli account ad alto privilegio | • Impostare “Account is sensitive and cannot be delegated” su Enterprise Admins, Domain Admins, account di service tier‑0. • Inserire tali account nel gruppo Protected Users dove possibile. |
| Limitare la delegazione sugli altri server | • Per server applicativi, usare Constrained Delegation (KCD) o, meglio, Resource‑Based Constrained Delegation (RBCD) anziché unconstrained. I DC continueranno a essere unconstrained, ma i workload rimarranno confinati. |
| Proteggere le credenziali in memoria | • Abilitare Windows Defender Credential Guard o Remote Credential Guard per impedire il furto di ticket su host non DC. • Aggiornare i sistemi per usufruire di Kerberos FAST/KDC Armoring. |
| Monitorare e reagire | • Abilitare l’audit avanzato di Kerberos (Event ID 4768, 4769, 4742). • Implementare un SIEM che allerti su emissioni di TGT/TGS con flag FORWARDABLE anomali e su logon privilegiati ai DC. |
| Aggiornamento & hardening | • Applica patch regolarmente. • Obbliga LDAPS con firma e sigillo. • Implementa criteri di scadenza‑rapida dei ticket su account privilegiati se supportabile. |
Procedure passo‑passo consigliate
Isolare l’accesso ai DC con jump server
- Allestisci una PAW/SAW (Privileged/ Secured Admin Workstation) o jump server per amministrare il Tier‑0.
- Configura un GPO su tutti i DC che nega il logon locale e RDP a chiunque non appartenga a gruppi amministrativi strettamente necessari.
- Implementa Just‑Enough Administration e Just‑In‑Time dove applicabile (ad esempio con PAM o PIM), evitando account permanenti sempre privilegiati.
Proteggere gli account privilegiati
- Per gli account Enterprise Admins, Domain Admins, KRBTGT e per i servizi Tier‑0, imposta l’attributo Account is sensitive and cannot be delegated.
- Valuta l’inserimento nel gruppo Protected Users per disabilitare automaticamente meccanismi meno sicuri (es. NTLM, delegazione, DES) e ridurre la durata del TGT.
Esempi PowerShell
# Segna un account come "non delegabile"
Set-ADAccountControl -Identity "admin-tier0" -AccountNotDelegated $true
Applica a tutti gli utenti del gruppo "Domain Admins"
Get-ADGroupMember "Domain Admins" -Recursive |
Where-Object {$*.objectClass -eq 'user'} |
ForEach-Object { Set-ADAccountControl -Identity $*.DistinguishedName -AccountNotDelegated $true }
Aggiungi utenti privilegiati a "Protected Users"
Add-ADGroupMember -Identity "Protected Users" -Members "admin-tier0","svc-backup-tier0" Portare la delegazione granulare nei workload (KCD/RBCD)
Nei server applicativi non‑DC, evita l’unconstrained delegation: preferisci RBCD (prima scelta) o KCD.
Esempi amministrativi
# Constrained Delegation (KCD): consenti a WEBAPP1 di delegare solo verso lo SPN MSSQLSvc di BACKEND1
Set-ADComputer -Identity "WEBAPP1" -Add @{
"msDS-AllowedToDelegateTo" = "MSSQLSvc/BACKEND1.contoso.local:1433"
}
Resource-Based Constrained Delegation (RBCD):
è la RISORSA di destinazione a definire chi può delegare verso di lei
Set-ADComputer -Identity "BACKEND1" -PrincipalsAllowedToDelegateToAccount "WEBAPP1$" Con RBCD il controllo è decentrato sul server di destinazione; si riducono blast radius e complessità, ed è più facile automatizzare in pipeline di deployment.
Proteggere le credenziali in memoria
- Windows Defender Credential Guard: isola segreti di LSASS con virtualizzazione (VBS) per impedire estrazioni di ticket/password da host compromessi.
- Remote Credential Guard: quando usi RDP verso server amministrativi, evita che le tue credenziali vengano delegate al server remoto.
Abilitazione via GPO
- Credential Guard:
Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security→ Abilita, quindi imposta Credential Guard (consigliato “Enabled with UEFI lock”). - Remote Credential Guard:
Computer Configuration > Administrative Templates > System > Credentials Delegation > Restrict delegation of credentials to remote servers→ “Require Remote Credential Guard”.
Rafforzare Kerberos: FAST/KDC Armoring e policy
- Abilita Kerberos FAST (KDC Armoring) su DC e client per proteggere lo scambio di pre-autenticazione e ridurre rischi di ticket fishing e manipolazioni.
- Valuta Authentication Policies & Silos (dalla funzionalità AD DS avanzata) per imporre orari, postazioni e durata dei ticket differenti per account privilegiati.
GPO rilevanti
Computer Configuration > Policies > Administrative Templates > System > KDC→ abilita il supporto per claims, compound auth e armoring.Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy→ valuta la riduzione delle durate dei ticket, tenendo conto dell’impatto su servizi legacy.
Audit e rilevazione (SIEM)
Attiva l’audit Kerberos e invia i log al SIEM. Eventi chiave:
- 4768 – TGT rilasciato (Authentication Service).
- 4769 – TGS rilasciato (Service Ticket). Verifica l’opzione FORWARDABLE e anomalie di volume/origine.
- 4742 – Modifica di oggetto computer (utile per cambi di delegazione).
Esempi di query (indicative)
# Microsoft Sentinel (KQL) – picchi di TGS FORWARDABLE
SecurityEvent
| where EventID == 4769
| extend TicketOptions = tostring(AdditionalFields)
| where TicketOptions has_cs "FORWARDABLE"
| summarize count() by TargetUserName, Computer, bin(TimeGenerated, 1h)
| order by count_ desc
Splunk – logon privilegiati sui DC
index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624 host=
| search Account_Type=User (TargetUserName="Admin" OR TargetUserName="svc")
| stats count by TargetUserName, Logon_Type, src, host LDAP sicuro, patch e configurazioni baseline
- LDAPS + firma/sigillo: richiedi la firma per server e client LDAP e l’uso di LDAPS ove possibile. Abilita il requisito di channel binding per mitigare attacchi man-in-the-middle.
- Patching rigoroso: mantieni aggiornati DC, membri del dominio e applicazioni Kerberos‑aware.
- Baseline di sicurezza: adotta baseline hardening coerenti (CIS, Microsoft Security Baselines) come partenza, poi personalizza per il tuo ambiente.
Visibilità: verificare lo stato attuale
Prima di cambiare, fotografa lo stato. Ecco comandi utili:
# Elenca tutti i DC e mostra se sono marcati "TrustedForDelegation"
Get-ADDomainController -Filter * |
ForEach-Object { Get-ADComputer $_.ComputerObjectDN -Properties userAccountControl } |
Select-Object Name, @{Name="TrustedForDelegation";Expression={($_.userAccountControl -band 0x80000) -ne 0}}
Trova computer (non-DC) con unconstrained delegation attiva (attenzione!)
Get-ADComputer -Filter * -Properties userAccountControl |
Where-Object { ($.userAccountControl -band 0x80000) -ne 0 -and $.PrimaryGroupID -ne 516 } |
Select-Object Name, DNSHostName Nota: PrimaryGroupID = 516 è tipicamente usato dai DC. Il secondo comando aiuta a individuare server applicativi che non dovrebbero avere delegazione non vincolata.
Perché non si può disattivare del tutto la delegazione sui DC
I DC fungono contemporaneamente da Key Distribution Center (KDC) e da endpoint di molti servizi di dominio (replica SYSVOL/DFS, DNS integrato in AD, LDAP, gestione trust, ecc.). Per erogare questi servizi devono:
- Ricevere un TGT dal client.
- Presentarsi essi stessi verso altri servizi a nome dell’utente.
Questo flusso richiede ticket FORWARDABLE e quindi la delegazione non vincolata. Disabilitarla impedirebbe operazioni di base di Active Directory, rompendo autenticazioni Kerberos, trust di foresta e il double hop di molti strumenti e funzioni interne.
Domande frequenti (FAQ)
Posso forzare “Do not trust this computer for delegation” su un DC?
Puoi impostarlo, ma sarà sovrascritto automaticamente dai servizi di sistema. Non è una via praticabile né supportata.
Se lascio tutto com’è sui DC, non sto aumentando il rischio?
Il rischio principale è consentire la delega non vincolata su server applicativi. I DC devono rimanere unconstrained; la sicurezza si ottiene isolando il Tier‑0, proteggendo le credenziali e monitorando l’uso dei ticket.
Che differenza c’è fra KCD e RBCD?
KCD limita la delega a SPN elencati sul caller; RBCD sposta il controllo sulla risorsa di destinazione, è più flessibile e si integra meglio con scenari DevOps/Cloud.
Il gruppo Protected Users è sufficiente?
È un ottimo rinforzo, ma non sostituisce jump server, hardening degli host, patching e audit.
Checklist operativa rapida
- ☑ Blocca logon locale/RDP ai DC per account non Tier‑0.
- ☑ Segna gli account privilegiati come non delegabili e aggiungili a Protected Users.
- ☑ Mappa e migra le deleghe applicative da unconstrained a RBCD/KCD.
- ☑ Abilita Credential Guard e Remote Credential Guard sui sistemi amministrativi.
- ☑ Abilita Kerberos FAST/KDC Armoring e ottimizza le policy dei ticket.
- ☑ Attiva audit Kerberos (4768/4769/4742) e allarmi su FORWARDABLE anomali.
- ☑ Enforce LDAPS con firma/sigillo e channel binding.
- ☑ Mantieni patch e baseline di sicurezza aggiornate.
Antipattern da evitare
- RDP diretto ai DC da workstation generiche o contesti non Tier‑0.
- Server applicativi con delegazione non vincolata “per comodità”. È una scorciatoia pericolosa.
- Account di servizio onnipotenti condivisi fra applicazioni diverse.
- Disabilitare forzatamente la delegazione sui DC: non solo inutile, potenzialmente dannoso.
Impatto e compatibilità: cosa testare prima
Alcune mitigazioni possono influenzare applicazioni legacy:
- FAST/KDC Armoring: verifica compatibilità di applicazioni Kerberos‑aware più datate.
- Riduzione della durata dei ticket: aumentare l’overhead di rinnovo può impattare job di lunga durata o servizi che assumono TGT “lunghi”. Valuta “Authentication Policies” per target selettivi.
- LDAPS obbligatorio e firma: assicurati che tutti i client e i connettori LDAP supportino le impostazioni richieste e abbiano trust CA corretti.
Governance e processo
La sicurezza dei DC è un programma, non un progetto “una tantum”. Adotta pratiche di governance:
- Asset inventory dei sistemi Tier‑0 e delle catene di delega applicativa.
- Change control per ogni modifica di SPN, deleghe KCD/RBCD e privilegi degli account.
- Continuous monitoring: dashboard SIEM con trend di TGT/TGS, logon privilegiati e modifiche agli oggetti computer/utente critici.
- Runbook di risposta per reset rapido della password KRBTGT (doppio reset, finestre coordinate), account disable e isolamento host compromessi.
Conclusioni
- No, i Domain Controller non possono funzionare senza delegazione unconstrained; qualsiasi tentativo di rimuoverla viene annullato dal sistema operativo.
- Sì, è possibile (e necessario) mitigare i rischi applicando hardening sugli account e limitando la delega su sistemi non‑DC.
- Investire in Credential Guard, RBCD e audit dettagliato riduce in modo sostanziale l’esposizione, mantenendo la piena funzionalità di Active Directory.
Tratta i DC come il cuore della tua identità: pochi accessi, controllati e monitorati. Sposta la complessità della delega sui workload e rendila granulare. È qui che si gioca la differenza tra una foresta AD fragile e un’infrastruttura resiliente.
Appendice: altri esempi utili
Individuare host con delega KCD attiva e SPN
# Elenca i computer con KCD (msDS-AllowedToDelegateTo popolato) e relativi SPN
Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo,servicePrincipalName |
Where-Object { $_.msDS-AllowedToDelegateTo } |
Select-Object Name, DNSHostName, msDS-AllowedToDelegateTo, servicePrincipalName
Verificare RBCD su una risorsa
# Mostra chi può delegare verso BACKEND1 (RBCD)
(Get-ADComputer -Identity "BACKEND1" -Properties PrincipalsAllowedToDelegateToAccount).
PrincipalsAllowedToDelegateToAccount
Policy Kerberos – riferimento rapido
- Maximum lifetime for user ticket (TGT): durata del TGT. Per ambienti ad alto rischio, valuta valori più conservativi, previa analisi impatto.
- Maximum lifetime for service ticket (TGS) e renew‑until: definiscono la “longevità” e il rinnovo dei ticket.
- Enforce user logon restrictions: dovrebbe essere abilitato per far rispettare i controlli di appartenenza ai gruppi durante le autenticazioni.