Chi compromette un domain controller compromette la foresta. AZ-802 dà per scontato che tu sappia lanciare la procedura guidata di promozione, e ti chiede piuttosto che cosa fare quando quella procedura non si può completare nel modo normale: un DC che non tornerà mai più in rete, una filiale senza armadio chiuso a chiave, un ruolo FSMO su una scheda madre bruciata.

Promuovere, demolire e ripulire

La promozione avviene con Install-ADDSDomainController (la Configuration Wizard di Server Manager offre View script e genera proprio quel cmdlet). Ricorrono -DomainName, -SafeModeAdministratorPassword, -SiteName, -DatabasePath, -LogPath, -SYSVOLPath, -ReplicationSourceDC e -InstallationMediaPath per l’Install From Media. Il sito indicato con -SiteName deve già esistere: il cmdlet non lo crea, per quello serve New-ADReplicationSite.

La rimozione è Uninstall-ADDSDomainController, ed è qui che si gioca la differenza che l’esame chiede:

Scenario Parametri Che cosa resta da fare
DC in più, raggiunge gli altri nessuno (-Credential solo se non sei già Domain Admin) niente: la demozione ripulisce i metadati da sola
Ultimo DC del dominio -LastDomainControllerInDomain, -RemoveApplicationPartitions, eventualmente -IgnoreLastDnsServerForZone e -RemoveDNSDelegation serve appartenere a Enterprise Admins: si rimuove il dominio
DC isolato in modo permanente -ForceRemoval (più -DemoteOperationMasterRole se tiene ruoli FSMO) metadata cleanup obbligatoria e immediata su un DC sopravvissuto

La demozione forzata lascia metadati orfani nella foresta e butta via ogni modifica non replicata su quel DC. La pulizia si fa da un DC rimasto e con RSAT corrente è automatica: basta cancellare l’oggetto computer dalla OU Domain Controllers in Active Directory Users and Computers (o l’oggetto NTDS Settings in Active Directory Sites and Services) e spuntare l’opzione che dichiara il DC definitivamente offline. La via da riga di comando resta ntdsutil → metadata cleanup → connections → connect to server <NomeServer> → quit → remove selected server <NomeServer>, e il server a cui ti connetti dev’essere un partner di replica di quello rimosso. Se compare «Access is denied», il colpevole è quasi sempre il flag Protect object from accidental deletion.

Due vincoli sull’ordine delle operazioni: rimuovere il ruolo AD DS con DISM su una macchina ancora promossa non è supportato e impedisce l’avvio; Uninstall-WindowsFeature invece si rifiuta di togliere i binari finché il DC non è stato demoto e riavviato.

Hardening: la risposta che Microsoft si aspetta

Alla richiesta «ridurre la superficie d’attacco del sistema operativo e impedire al server di raggiungere Internet» la guida di sicurezza risponde con due mosse precise: installare il sistema operativo in modalità Server Core e bloccare l’accesso a Internet dai DC. Nessun browser va usato su un domain controller; il blocco si costruisce con controlli applicativi (oggi App Control for Business, che ha assorbito AppLocker e WDAC), un proxy «black hole» e Windows Firewall with Advanced Security, mentre il firewall perimetrale blocca le connessioni in uscita. Intorno: TPM e BitLocker su tutti i volumi, rack dedicati, RDP consentito via GPO collegate alle OU dei domain controller solo da jump server autorizzati, patching separato dal resto del parco, amministrazione remota da privileged access workstation. Se in una sede non puoi chiudere il server in una stanza a chiave, la raccomandazione cambia oggetto: metti lì un RODC.

Domain controller in Azure

Estendere una foresta on-premises in una virtual network passa da due configurazioni DNS in due momenti diversi, ed è lì che l’esame ti aspetta.

Prima di promuovere le VM, le impostazioni DNS della virtual network devono puntare ai DNS server on-premises: senza quello le macchine in Azure non risolvono il dominio, non trovano un replication source e la promozione fallisce. Dopo la promozione i nuovi DC diventano DNS primario e secondario della VNet, e i server on-premises scalano a terziari. Attenzione: le VM già accese continuano a usare le vecchie impostazioni DNS finché non vengono riavviate — se i member server della VNet risolvono ancora verso l’on-premises, la risposta è il riavvio, non una riconfigurazione dentro il guest.

Il resto della checklist: indirizzo IP privato statico assegnato in Azure, mai configurato nel sistema operativo guest (il prerequisite check avvisa che la scheda non ha IP statico: è un falso allarme, si ignora); disco dati gestito separato per NTDS.dit, log e SYSVOL, con host caching impostato su None; VM in un availability set o in zone diverse; subnet dedicata con NSG; site-to-site VPN o ExpressRoute verso la rete aziendale.

RODC: staging, delega e password

Il deployment «da filiale» si fa in due tempi. Prima si pre-crea l’account in Active Directory Administrative Center (Domain Controllers → Pre-create a Read-only domain controller account) oppure con Add-ADDSReadOnlyDomainControllerAccount; l’account compare come Unoccupied Domain Controller Account. Poi il tecnico in sede installa il ruolo e aggancia il server all’account con Install-ADDSDomainController -UseExistingAccount: il nome del computer deve coincidere con quello dichiarato in -DomainControllerAccountName.

Due cose da sapere a memoria:

  • il percorso di staging è un porting da Windows Server 2008 R2 e non esegue l’adprep automatico. Se in quella foresta non è mai esistito un RODC, il wizard si ferma con l’errore «adprep /rodcprep was not yet run»: o lanci adprep.exe /rodcprep a mano, o promuovi prima un RODC non staged, che l’adprep lo esegue da solo;
  • -DelegatedAdministratorAccountName (pagina Delegation of RODC Installation and Administration) indica l’utente o gruppo che potrà agganciare il server all’account e che ottiene privilegi equivalenti al gruppo Administrators locale dell’RODC — installare driver, riavviare — senza entrare in Domain Admins né negli Administrators di dominio. È la risposta giusta per il tecnico di filiale.

La Password Replication Policy si configura con -AllowPasswordReplicationAccountName e -DenyPasswordReplicationAccountName. Se non selezioni Use advanced mode installation valgono i default: Deny per Administrators, Server Operators, Backup Operators, Account Operators e Denied RODC Password Replication Group, Allow per Allowed RODC Password Replication Group, che alla creazione del dominio è vuoto. Chi non è nell’elenco è negato implicitamente. Tradotto: di default sull’RODC non è memorizzata nessuna password, e un RODC che pure è global catalog e DNS server resta inutile durante un’interruzione WAN, perché per ogni autenticazione deve inoltrare la richiesta a un DC scrivibile che in quel momento non raggiunge.

La sicurezza degli account si governa dalla scheda Password Replication Policy dell’oggetto computer: Advanced mostra gli account le cui password sono attualmente memorizzate, la Resultant Policy risolve il caso di un singolo utente. Se l’RODC viene rubato si cancella il suo account computer accettando la proposta di reimpostare le password degli account che vi erano memorizzate, dopo averne esportato l’elenco.

FSMO: cinque ruoli, due verbi

Ruolo Ambito Se il titolare è offline
Schema Master foresta non si estende lo schema
Domain Naming Master foresta non si aggiungono o rimuovono domini e partizioni applicative
RID Master dominio i DC esauriscono il pool di RID e non creano più security principal
PDC Emulator dominio lockout, ultima password valida, sorgente di tempo autorevole (nel dominio root)
Infrastructure Master dominio riferimenti cross-domain non aggiornati

I verbi sono due e non sono sinonimi. Il transfer è la mossa pulita, con entrambi i DC vivi: Move-ADDirectoryServerOperationMasterRole -Identity <ServerDestinazione> -OperationMasterRole PDCEmulator. Il seize è l’ultima spiaggia, con il titolare morto: lo stesso cmdlet con -Force, oppure ntdsutil → roles → connections → connect to server <FQDN> → quit → seize pdc (gli altri: seize schema master, seize naming master, seize rid master, seize infrastructure master).

I permessi non sono uniformi: Schema Master richiede Schema Admins, Domain Naming Master Enterprise Admins, gli altri tre Domain Admins del dominio interessato. Nessuna di queste appartenenze implica le altre.

Trappole tipiche d’esame

  • Enterprise Admins non basta per lo Schema Master. Un account che è Enterprise Admin e Domain Admin del dominio root trasferisce quattro ruoli su cinque: quello dello schema fallisce per permessi finché non lo aggiungi a Schema Admins.
  • Dopo un seize il vecchio titolare non torna mai online. Se lo riaccendi si ripresenta come role holder e nasce un conflitto. Va tenuto isolato, formattato e ricostruito da zero — non ripristinato da backup — e il suo vecchio oggetto va rimosso con la metadata cleanup.
  • Demozione forzata ≠ metadata cleanup. -ForceRemoval ripulisce il server locale, non la directory. I metadati orfani si rimuovono a mano da un DC sopravvissuto, subito: sono una delle cause più frequenti dei casi di supporto AD DS.
  • RODC «funzionante» non significa «autonomo». Global catalog e DNS attivi non aiutano se la Password Replication Policy è quella di default: senza password memorizzate, un’interruzione WAN blocca le autenticazioni in filiale. La contromisura si pianifica prima, popolando l’Allowed RODC Password Replication Group con gli utenti e i computer della sede.
  • Il primo RODC della foresta richiede adprep /rodcprep, e il percorso di pre-creazione dell’account non lo esegue per te.
  • In Azure il DNS si tocca due volte — verso l’on-premises prima della promozione, verso i nuovi DC dopo — e le VM esistenti non recepiscono il cambio finché non vengono riavviate. L’IP statico, invece, si assegna sempre in Azure e mai dentro il guest.