Microsoft AZ-801: Sicurezza di Active Directory Domain Services — Guida allo studio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fa parte della Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Active Directory Domain Services (AD DS) è alla base dell’identità e dell’accesso nelle reti Windows. Mettere in sicurezza AD DS significa controllare come le credenziali vengono create, archiviate e utilizzate; limitare dove le identità privilegiate possono autenticarsi; rafforzare i protocolli di autenticazione; eseguire l’audit delle azioni di alto valore; e garantire un ripristino affidabile. Questa sezione tratta le policy granulari per password e account, le protezioni per le identità privilegiate, il rafforzamento e la delega dell’autenticazione, l’auditing e le SACL, il Cestino (Recycle Bin), la firma LDAP e il channel binding, il comportamento di AdminSDHolder, il backup e i ripristini autorevoli inclusa la recovery di SYSVOL, e il modello di tiering di AD.

Policy sulle Credenziali e Controlli sulle Identità Privilegiate

Le policy granulari per le password (PSO, Fine-grained password policies) consentono di avere più policy di password/blocco account in un singolo dominio, senza la necessità di domini aggiuntivi. Le PSO sono oggetti msDS-PasswordSettings archiviati in CN=Password Settings Container,CN=System,<domain DN> (il contenitore msDS-PasswordSettingsContainer). Una PSO si applica a utenti e gruppi di sicurezza globali tramite l’attributo msDS-PSOAppliesTo. Quando a un utente si applicano più PSO (direttamente o tramite gruppi), la PSO risultante è quella con il valore msDS-PasswordSettingsPrecedence più basso; in caso di parità, prevale la PSO con il GUID più basso. La PSO effettiva dell’utente viene registrata nell’attributo msDS-ResultantPSO. Progettare le PSO in modo che i numeri di precedenza più bassi corrispondano alle policy più restrittive che si intende far prevalere, e convalidare le policy effettive leggendo l’attributo msDS-ResultantPSO.

Il gruppo di sicurezza Protected Users rafforza la sicurezza degli account di alto valore rimuovendo i comportamenti di autenticazione legacy e rischiosi. I membri:

Non possono usare NTLM, Digest o CredSSP
Hanno l’uso di RC4 e DES per Kerberos negato
Non possono essere delegati tramite Kerberos (delega non vincolata o vincolata)
Ricevono TGT non rinnovabili con una durata fissa e breve (predefinita di 4 ore)
Non memorizzano nella cache credenziali in chiaro o segreti a lungo termine sulla workstation (impedisce il fallback a WDigest e la permanenza di materiale relativo alle credenziali in LSASS) Utilizzare questo gruppo per le identità privilegiate gestite da persone e per i proprietari di servizi ad alto rischio, dopo averne convalidato la compatibilità con le applicazioni. I domain controller devono eseguire Windows Server 2012 R2 o versioni successive per applicare queste protezioni.

Le policy di autenticazione e i silo di policy di autenticazione limitano dove e come gli account possono autenticarsi. Una policy di autenticazione può impostare vincoli Kerberos per singolo account, come la durata del TGT e i dispositivi consentiti (tramite SPN/FQDN dell’host). Un silo di policy di autenticazione raggruppa utenti, computer e account di servizio in modo che solo le combinazioni consentite possano autenticarsi utilizzando Kerberos, vincolati da tale policy. Questo impone controlli di tipo “station-to-admin”: ad esempio, gli amministratori di Tier 0 possono accedere solo ai domain controller e a workstation ad accesso privilegiato (PAW) designate, ma non ai server membri o alle workstation. Combinare con il gruppo Protected Users per ottenere il massimo effetto. Queste funzionalità richiedono DC con Windows Server 2012 R2 e l’armoring del KDC.

AdminSDHolder e SDProp proteggono le ACL delle identità privilegiate. I membri dei gruppi di amministrazione predefiniti (ad esempio, Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators e altri) sono “protetti”. SDProp viene eseguito ogni ora sul PDC Emulator, copiando l’ACL da CN=AdminSDHolder,CN=System agli oggetti protetti e disabilitando l’ereditarietà delle ACL su di essi (AdminCount=1). Per concedere diritti di helpdesk su oggetti protetti, modificare l’ACL su AdminSDHolder — mai direttamente sui singoli oggetti protetti — altrimenti la modifica verrà annullata. Quando un account viene rimosso da tutti i gruppi protetti, riabilitare l’ereditarietà delle ACL e azzerare AdminCount in modo che le ACL e le GPO a livello di OU vengano nuovamente applicate.

Adottare un modello di tiering di AD per ridurre al minimo l’esposizione delle credenziali. Il Tier 0 contiene i domain controller, i sistemi di identità (PKI, federazione, PAM) e gli account amministrativi che li gestiscono. Il Tier 1 contiene i carichi di lavoro dei server e i loro amministratori. Il Tier 2 contiene le workstation e i loro amministratori. Impedire l’accesso tra i tier, utilizzare le PAW per l’amministrazione dei Tier 0/1 e isolare le credenziali utilizzando funzionalità come Protected Users, silo di autenticazione, Remote Credential Guard, Just-Enough Administration (JEA) e Windows LAPS per la rotazione delle password degli amministratori locali.

Unire i pezzi: Operazioni, Priorità di Hardening e Accesso a Tier

Dare priorità innanzitutto al Tier 0: imporre la firma LDAP/il channel binding, rimuovere la delega non vincolata, passare a KCD/RBCD, inserire le identità privilegiate in Protected Users e associare policy/silo di autenticazione per limitare gli endpoint di logon, e richiedere le PAW per gli amministratori di Tier 0/1. Stabilire PSO per gli account privilegiati con blocco e rotazione rigidi. Attivare l’auditing avanzato con SACL sui container di Tier 0. Garantire backup giornalieri dello stato del sistema (System State) dei DC e runbook documentati per il ripristino autoritativo e il recupero di SYSVOL. Nei Tier 1/2, bloccare il logon degli amministratori ai tier inferiori, eliminare il riutilizzo dell’amministratore locale con Windows LAPS e monitorare i picchi degli eventi 4625/4740 e l’uso improprio del 4648 per tentativi di movimento laterale.

Scenario Pratico

Adobe deve mettere in sicurezza rapidamente una foresta AD DS on-premise dopo aver acquisito una filiale le cui applicazioni line-of-business si basano su protocolli legacy. Gli obiettivi sono ridurre il successo degli attacchi di password spraying, fermare il relay di credenziali verso i DC, limitare i logon privilegiati alle PAW, modernizzare la delega per un tier web e garantire un ripristino rapido da eliminazioni accidentali.

Definire i PSO e assegnarli ai gruppi privilegiati

Creare un PSO rigido (valore di precedenza basso) in msDS-PasswordSettingsContainer con una durata della password breve, complessità elevata e blocco aggressivo.
Applicarlo tramite msDS-PSOAppliesTo a “Domain Admins”, “Server Admins” e a un gruppo personalizzato “Tier0‑Privs”. Perché: I PSO a granularità fine si applicano solo agli account ad alto rischio senza interferire con l’intero dominio, e la precedenza garantisce che la policy più restrittiva prevalga.

Implementare Protected Users e silo di autenticazione

Aggiungere gli amministratori umani di Tier 0 al gruppo Protected Users.
Creare una policy di autenticazione che consenta il logon Kerberos solo dagli SPN degli host PAW e dai DC; collegare account e PAW in un silo di policy di autenticazione. Perché: Il gruppo Protected Users elimina NTLM/RC4 e impedisce la delega; i silo impongono la regola “solo dalle PAW”, riducendo l’esposizione dei token e i percorsi per il furto di credenziali.

Eseguire l’hardening di LDAP e monitorare eventuali problemi

Impostare “Domain controller: LDAP server signing requirements” su Require; configurare inizialmente LDAPEnforceChannelBinding=1.
Esaminare gli eventi 2886–2889 del Directory Service per identificare i bind legacy; correggere le applicazioni, quindi impostare LDAPEnforceChannelBinding=2. Perché: La firma e il channel binding eliminano i percorsi di relay comuni verso i DC, mentre l’applicazione graduale evita interruzioni di servizio.

Migrare la delega a RBCD per il tier web

Convertire i server web di front-end dalla delega non vincolata a RBCD aggiungendo i loro account computer all’attributo msDS-AllowedToActOnBehalfOfOtherIdentity dell’account di servizio dell’API di back-end.
Rimuovere i flag legacy “Trust this computer for delegation to any service”; definire con precisione gli SPN dei servizi. Perché: RBCD consente alla risorsa di dettare chi può delegare a essa e limita l’impersonificazione agli obiettivi previsti, riducendo il movimento laterale.

Abilitare l’auditing avanzato e le SACL

Configurare l’Advanced Audit Policy per Account Management, Logon/Logoff, Account Logon e Directory Service Changes.
Sulle OU e sui gruppi chiave di Tier 0, aggiungere SACL che eseguano l’audit delle operazioni di scrittura su member e servicePrincipalName e delle modifiche a permessi/proprietario.
Inoltrare i log a un SIEM; impostare alert per le anomalie degli eventi 4720, 4740, 4625 e 4648. Perché: Non si può difendere ciò che non si può vedere; questi eventi espongono la creazione di account, i blocchi, i logon falliti e i pattern di utilizzo esplicito delle credenziali.

Attivare il Cestino di AD DS e finalizzare i runbook di ripristino

Abilitare il Cestino a livello di foresta e documentare i flussi di lavoro di Restore-ADObject.
Standardizzare i backup giornalieri dello stato del sistema (System State) dei DC con Windows Server Backup, testare il ripristino autoritativo tramite ntdsutil in un ambiente di laboratorio.
Documentare ed esercitarsi sul ripristino autoritativo e non autoritativo di SYSVOL (DFSR). Perché: Un ripristino rapido e accurato scoraggia le azioni distruttive degli attaccanti e mitiga gli errori degli amministratori senza causare deriva dei privilegi.

Implementare operativamente il modello a tier di AD

Definire gli asset di Tier 0/1/2; limitare i logon degli amministratori per tier utilizzando Group Policy e silo di autenticazione.
Distribuire le PAW per i Tier 0/1, imporre Remote Credential Guard e ruotare le password degli amministratori locali con Windows LAPS. Perché: La suddivisione in tier garantisce l’isolamento delle credenziali e ferma l’escalation dell’attaccante tra i vari livelli, allineando le operazioni quotidiane con i confini di sicurezza.

← Microsoft Sentinel e Monitoraggio della Sicurezza · Tutti i domini · Azure Arc e Gestione di Server Ibridi →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →