Trust fra domini e foreste

In una foresta i trust tra domini dello stesso albero sono automatici, bidirezionali e transitivi (parent-child e tree-root): un utente può autenticarsi ovunque nella foresta. I trust che configuri a mano seguono regole diverse. Un forest trust collega due foreste distinte, può essere one-way o two-way ed è transitivo verso tutti i domini delle due foreste, ma non si estende a una terza. Un external trust collega un singolo dominio di un’altra foresta ed è sempre non transitivo. Il realm trust serve verso Kerberos non-Windows; lo shortcut trust accorcia il percorso di autenticazione tra due domini profondi della stessa foresta.

Due leve d’esame ricorrenti: la direzione (il trust punta in senso opposto all’accesso: se gli utenti della foresta A devono usare risorse in B, il trust va da B verso A) e la selective authentication, che al posto del forest-wide authentication obbliga a concedere esplicitamente il permesso “Allowed to authenticate” sui singoli server.

gMSA e service account

I group Managed Service Account (gMSA) eliminano la gestione manuale delle password dei service account: AD genera e ruota la password automaticamente (default circa 30 giorni) e più host possono condividere lo stesso account — utile per farm IIS, NLB o cluster. Prerequisito: creare una volta la KDS root key (Add-KdsRootKey) e installare l’account sui membri con Install-ADServiceAccount. Il predecessore sMSA (standalone) è legato a un solo computer. Scegli gMSA quando il servizio gira su più server o dietro load balancer.

Microsoft Entra Domain Services

Entra Domain Services è un managed domain: Microsoft gestisce i domain controller, tu non hai Domain Admin/Enterprise Admin ma solo il gruppo AAD DC Administrators. Offre LDAP, NTLM, Kerberos, Group Policy e domain join senza deployare DC in Azure. La sincronizzazione degli oggetti da Entra ID è one-way (Entra → managed domain); non puoi modificare lo schema né promuovere DC. È la scelta per il lift-and-shift di app legacy che richiedono LDAP/Kerberos in Azure. Con la SKU adeguata supporta un resource forest trust one-way verso l’AD DS on-premises.

Backup, DSRM e authoritative restore

Il backup di AD DS è il system state (include NTDS.DIT, SYSVOL, registry), preso con Windows Server Backup / wbadmin. Per ripristinare si entra in Directory Services Restore Mode (DSRM), la cui password locale è distinta e va conosciuta in anticipo. Un restore non authoritative (default) riporta il DC allo stato del backup e poi la replica lo riallinea. Un authoritative restore serve quando devi recuperare oggetti cancellati (es. una OU eliminata per errore): dopo il non-authoritative restore, con ntdsutil marchi il subtree come authoritative, così i version number vengono incrementati e gli oggetti si replicano verso gli altri DC anziché essere ricancellati. Alternativa più semplice per la sola cancellazione accidentale: l’AD Recycle Bin, se abilitato prima dell’incidente.

NTDS.DIT, Sites & Services e replica

NTDS.DIT è il database della directory. La offline defragmentation (ntdsutil, in DSRM) recupera spazio su disco; la online defrag automatica non lo restituisce. In Active Directory Sites and Services definisci site, subnet e site link: la replica intra-site è quasi immediata e non compressa, quella inter-site è schedulata e compressa, con cost e schedule sul site link. Il KCC costruisce la topologia e repadmin diagnostica la replica multimaster (USN, up-to-dateness vector). In vista dell’esame (passing score 700/1000, in ritiro il 30 settembre 2026) privilegia i criteri di scelta rispetto ai singoli passaggi operativi.

Trappole tipiche d’esame

  • Utenti di foresta A devono accedere a risorse in foresta B → forest trust con direzione corretta: il trust si crea da B (dove stanno le risorse) verso A; la direzione è opposta al flusso di accesso.
  • Limitare quali utenti trusted si autenticano solo su certi server → selective authentication: invece del forest-wide, concedi “Allowed to authenticate” caso per caso.
  • Recuperare una OU cancellata e l’AD Recycle Bin non era abilitato → authoritative restore: system state restore in DSRM più ntdsutil per marcare il subtree; il non-authoritative da solo la ricancella via replica.
  • Service account condiviso da più web server senza gestire password → gMSA: un sMSA non basta perché legato a un solo host; ricorda la KDS root key come prerequisito.
  • App legacy con LDAP/Kerberos da spostare in Azure senza gestire DC → Entra Domain Services: managed domain senza Domain Admin e con schema non modificabile, quindi inadatto se devi estendere lo schema.
  • NTDS.DIT cresciuto dopo grandi cancellazioni → offline defragmentation: con ntdsutil in DSRM per rilasciare spazio al filesystem; la online defrag non riduce il file.