Deploy dei domain controller

Promuovere un server a domain controller richiede prima l’installazione della feature AD-Domain-Services, poi la promotion vera e propria con i cmdlet del modulo ADDSDeployment. Install-ADDSForest crea una foresta nuova (primo DC, dominio radice, functional level); Install-ADDSDomainController aggiunge un DC a un dominio esistente; Install-ADDSDomain crea un dominio figlio o un nuovo tree. Ogni promotion richiede la Directory Services Restore Mode (DSRM) password.

In ambiente ibrido puoi promuovere una Azure VM a domain controller, collegandola alla stessa rete della foresta (VNet peered o connessa via VPN/ExpressRoute). Due accortezze: il data disk che ospita ntds.dit e i log va configurato con host caching su None per evitare corruzione da write-back cache, e alla NIC va assegnato un IP statico. Non è la stessa cosa di Microsoft Entra Domain Services, che è un managed domain senza accesso amministrativo ai DC.

RODC e password replication policy

Un Read-Only Domain Controller ospita una replica in sola lettura di AD, pensata per branch office poco sicuri; si installa con Install-ADDSDomainController -ReadOnlyReplica. Di default non cacha password: cosa memorizza dipende dalla Password Replication Policy, governata dai gruppi Allowed RODC Password Replication Group e Denied RODC Password Replication Group, dove il deny prevale sull’allow. Così un RODC rubato espone solo gli account esplicitamente consentiti. Supporta anche l’Administrator Role Separation per delegare l’amministrazione locale senza diritti sul resto del dominio.

I cinque ruoli FSMO

AD è multi-master, ma alcune operazioni esigono un titolare unico: sono i ruoli FSMO (Flexible Single Master Operations). Due sono forest-wide: lo Schema Master, l’unico che può modificare lo schema, e il Domain Naming Master, che autorizza aggiunta e rimozione di domini. Tre sono domain-wide: il RID Master, che distribuisce i pool di RID ai DC; il PDC Emulator, riferimento per la sincronizzazione dell’ora, la priorità sui password change, il lockout degli account e la compatibilità legacy; e l’Infrastructure Master, che aggiorna i riferimenti cross-domain fra SID e nomi degli oggetti.

Trasferimento, seizure e global catalog

Se il titolare del ruolo è online, si esegue un transfer: spostamento pulito e reversibile con Move-ADDirectoryServerOperationMasterRole o dalle console MMC. Se il titolare è irrecuperabile si ricorre alla seizure, con ntdsutil (contesto roles, comando seize) oppure lo stesso cmdlet con -Force. Regola d’oro: dopo una seizure il vecchio DC non deve più tornare online senza un metadata cleanup, pena conflitti di ruolo.

Il global catalog non è un ruolo FSMO ma un attributo del DC: contiene una replica parziale di tutti gli oggetti dell’intera foresta. Serve per le ricerche forest-wide, per la risoluzione dell’universal group membership al logon e per l’UPN. Con più DC conviene distribuire più GC per ridondanza.

Trappole tipiche d’esame

  • DC su Azure VM che si corrompe dopo il reboot → soluzione: imposta la host caching del data disk con ntds.dit su None; la write-back cache è la causa classica di database AD non consistenti.
  • RODC rubato, quali credenziali sono esposte → soluzione: solo gli account nella PRP effettiva; il Denied group precede sempre l’Allowed, quindi controlla entrambi.
  • Estensione dello schema che fallisce → soluzione: serve lo Schema Master online e l’appartenenza a Schema Admins; è un ruolo forest-wide, non domain-wide.
  • Titolare FSMO acceso ma da spostare → soluzione: usa il transfer, non la seizure; la seizure è solo per un holder morto e obbliga al metadata cleanup del vecchio DC.
  • Infrastructure Master su un global catalog → soluzione: in una foresta multi-dominio è un problema se il ruolo sta su un GC mentre non tutti i DC lo sono; in un dominio singolo è ininfluente.
  • Logon che fallisce senza global catalog → soluzione: il GC risolve l’universal group membership; senza GC né universal group caching l’accesso può non completarsi.