Mettere in sicurezza AD DS: password, delega e autenticazione

Un dominio AD DS compromesso non si ripara: si ricostruisce. Per questo l’esame non chiede «come si imposta una password policy», ma quali controlli si sommano e che cosa smette di funzionare quando li accendi: qui AZ-802 misura le conseguenze, non la configurazione.

Le password: tre strati che devono essere tutti d’accordo

Su un account convivono fino a tre insiemi di regole, e non sono alternativi.

AD DS accetta una password nuova solo se tutti i validatori concordano: Entra Password Protection è un supplemento, non un rimpiazzo, e convive con qualsiasi altro password filter DLL di terze parti. Se un PSO impone 15 caratteri, il banned list non abbassa quel minimo, e viceversa una password di 20 caratteri costruita su un termine vietato viene comunque respinta.

Microsoft Entra Password Protection per AD DS

Due componenti, nessuna delle quali mette i DC su Internet:

• il proxy service su un member server aggregato al dominio, che inoltra a Entra ID le richieste di download della policy. È obbligatorio anche se il DC avesse accesso diretto a Internet;
• il DC agent, composto da password filter DLL più servizio, installato sui domain controller.

Il DC agent scarica la policy, la deposita in una cartella dedicata nella radice di sysvol (da cui replica agli altri DC) e ne verifica l’età ogni ora. Se nessuna policy è disponibile localmente, la password viene accettata e viene loggato un evento di avviso.

Requisiti che l’esame ama chiedere: DC agent e proxy su Windows Server 2012 R2 o successivo, .NET Framework 4.7.2, replica di sysvol in DFSR (con FRS il software si installa ma non funziona), connettività RPC (porta 135 più la porta del proxy, dinamica o statica via Set-AzureADPasswordProtectionProxyConfiguration -StaticPort). Il livello funzionale di dominio e foresta è irrilevante e non servono estensioni di schema.

La registrazione avviene due volte: Register-AzureADPasswordProtectionProxy per ogni proxy (Global Administrator la prima volta nel tenant, poi basta Security Administrator) e Register-AzureADPasswordProtectionForest una volta per foresta, con privilegi di Enterprise Admin on-premises. L’installazione del DC agent richiede un riavvio; quella del proxy no.

Modalità: si accendono dal Microsoft Entra admin center, in Authentication methods > Password protection, con Audit (si logga soltanto) o Enforced (si rifiuta). La validazione avviene solo su cambio o reset della password: le password già esistenti in directory non vengono mai rivalutate.

Protected Users: protezione non configurabile

Aggiungere un account al gruppo Protected Users (RID 525) applica restrizioni che non si possono modulare. Sul client: niente credenziali in chiaro per CredSSP, niente WDigest, nessuna cache dell’NTOWF per NTLM, nessuna chiave DES o RC4, e soprattutto nessun cached verifier, quindi niente sign-in offline. Sul domain controller, se il domain functional level è Windows Server 2012 R2 o superiore: niente autenticazione NTLM, niente DES/RC4 in pre-autenticazione Kerberos, nessuna delega (vincolata o non vincolata) e TGT non rinnovabile oltre le 4 ore iniziali (240 minuti cablati).

Mai inserirci account di servizio o computer: sull’host la password è comunque disponibile, non guadagni nulla e l’autenticazione in ingresso fallisce. E serve una chiave AES: gli account la cui password non è mai stata cambiata su un DC Windows Server 2008 o successivo si autobloccano.

Authentication policy e authentication policy silo

Dove Protected Users è rigido, le authentication policy sono configurabili. Una policy definisce la durata del TGT (sempre non rinnovabile) e le condizioni di access control: ms-DS-User-Allowed-To-Authenticate-From (da quali dispositivi l’utente può fare sign-in) e ...-To (chi può autenticarsi verso un servizio che gira con quell’account). Il silo lega utenti, computer e service account e applica loro le policy; un account può stare in un solo silo.

Requisito chiave: la restrizione «solo da questi host» si valuta sul TGT dell’host usato per armorare la richiesta, quindi richiede DFL Windows Server 2012 R2 e il supporto Dynamic Access Control (Key Distribution Center (KDC) client support for claims, compound authentication and Kerberos armoring sui DC, Kerberos client support... sui client). La sola durata del TGT non richiede DAC.

New-ADAuthenticationPolicy Tier0-Policy -UserTGTLifetimeMins 240 `
  -UserAllowedToAuthenticateFrom (Get-Acl .\tier0hosts.txt).sddl -Enforce
New-ADAuthenticationPolicySilo -Name Tier0-Silo -Enforce
Grant-ADAuthenticationPolicySiloAccess -Identity Tier0-Silo -Account adm.rossi
Set-ADAccountAuthenticationPolicySilo -Identity adm.rossi -AuthenticationPolicySilo Tier0-Silo

Policy e silo nascono in audit mode: senza -Enforce generano solo eventi (log AuthenticationPolicyFailures-DomainController, ID 105/305 per il TGT, 106/306 per il service ticket). E l’Administrator predefinito del dominio (S-1-5-21-<dominio>-500) è sempre esente dalle authentication policy, anche dentro un silo enforced.

Irrobustire e restringere l’accesso ai DC

Il principio è uno solo: non si amministra un sistema fidato da un host meno fidato. Da qui le pratiche che l’esame dà per acquisite — host amministrativi dedicati, senza browser né posta, senza accesso a Internet, con BitLocker e allowlist applicativa (oggi App Control for Business, confluenza di AppLocker e WDAC), aggiornati da un’infrastruttura di patching separata e raggiunti via jump server con RD Gateway. Si aggiungono Interactive logon: Require smart card e soprattutto i user rights assignment: concedere Allow log on locally e Allow log on through Remote Desktop Services solo agli account di quel livello, e negare esplicitamente (Deny access to this computer from the network, Deny log on as a batch job, Deny log on as a service, Deny log on locally, Deny log on through Remote Desktop Services) gli account privilegiati sulle macchine di livello inferiore. Nelle filiali non presidiate si usa un RODC; per l’amministratore locale, Windows LAPS; per le attività delegate, JEA.

Account, gruppi predefiniti e delega

Sugli account privilegiati: Account is sensitive and cannot be delegated (la si controlla anche in troubleshooting, perché Protected Users blocca la delega senza che la casella risulti spuntata), Smart card is required for interactive logon, tipi di cifratura Kerberos limitati ad AES. I gruppi predefiniti — Domain Admins, Enterprise Admins, Schema Admins, Account Operators — sono protetti da AdminSDHolder: il processo SDProp riscrive ogni 60 minuti l’ACL dei membri, imposta adminCount a 1 e disabilita l’ereditarietà, quindi una delega applicata direttamente su quegli oggetti sparisce da sola. Tenere Schema Admins vuoto e usare account separati per livello è la contromisura corretta.

«Delega» in AD DS ha due significati e l’esame li mescola: la delega amministrativa (ACE su OU, Delegation of Control Wizard) e la delega Kerberos. Di quest’ultima: unconstrained (da evitare), constrained (configurata sull’account front-end) e resource-based constrained delegation, che si configura invece sulla risorsa con Set-ADComputer -PrincipalsAllowedToDelegateToAccount.

Sui protocolli: Kerberos è il default, NTLM si riduce con le policy Network security: Restrict NTLM (prima in audit), RC4 si dismette con Network security: Configure encryption types allowed for Kerberos, e LDAP va protetto con signing e channel binding. Per i servizi, gMSA; i dMSA (delegated Managed Service Account) esistono solo da Windows Server 2025 e richiedono il relativo livello funzionale di dominio.

Trappole tipiche d’esame

1. PSO ed Entra Password Protection non si escludono. Se un PSO impone 15 caratteri e il DC agent è attivo, la password deve superare entrambi: il banned list non solleva né abbassa il minimo di lunghezza, e AD DS richiede il consenso di tutti i validatori.
2. Sui RODC non si installa il DC agent (i cambi password sono inoltrati ai DC scrivibili) e il proxy non è supportato su un RODC. Il DC agent va invece su tutti i DC scrivibili: il deploy parziale è ammesso, ma solo per test. Il livello funzionale non è un requisito; DFSR sì.
3. Protected Users toglie il sign-in offline. Gli utenti che lavorano scollegati dalla rete non riescono più a sbloccare il portatile perché il cached verifier non viene più creato. Non è un bug del laptop: è la protezione che funziona.
4. L’Administrator predefinito (RID 500) ignora le authentication policy, anche se lo metti in un silo enforced. Se lo scenario chiede perché quell’unico account continua ad autenticarsi da una postazione qualsiasi, la risposta è questa, non un errore di configurazione.
5. Le condizioni «allowed to authenticate from» richiedono Kerberos armoring. Senza DFL 2012 R2 e senza Dynamic Access Control abilitato su DC e client, la restrizione non si applica (o fa fallire i client che non armorano). Il solo UserTGTLifetimeMins invece funziona senza DAC. E ricorda che policy e silo nascono in audit.
6. I livelli funzionali oggi si possono anche abbassare. La vecchia regola «si alzano e basta» non è più vera: non scartare una risposta solo perché prevede un downgrade del functional level.