Siti, trust e replica sono tre modi di rispondere alla stessa domanda: con quale domain controller parla chi, e attraverso quale linea. L’esame non chiede la teoria della topologia, chiede la mossa: quale oggetto crei, quale proprieta’ cambi, quale strumento usi — e soprattutto quale strumento non puo’ fare quel lavoro.

Trust: che cosa colleghi, e da che parte

Dentro una foresta i trust tra domini sono automatici, bidirezionali e transitivi. Quelli che configuri tu seguono regole diverse:

Tipo Che cosa collega Transitivita’ Come si crea
Parent-child / tree-root domini della stessa foresta transitivo e bidirezionale automatico alla promozione del DC
Forest trust due foreste AD DS intere transitivo verso tutti i domini delle due foreste, mai verso una terza console Active Directory Domains and Trusts (o PowerShell)
External trust un singolo dominio di un’altra foresta sempre non transitivo console oppure netdom trust
Realm trust un realm Kerberos non-Windows la scegli tu con /Transitive:Yes o No netdom trust ... /add /realm /passwordt:*
Shortcut trust due domini profondi della stessa foresta transitivo console oppure netdom trust

La direzione e’ la prima trappola: il trust punta in senso opposto all’accesso. Se gli utenti di fabrikam.com devono usare risorse in contoso.com, su contoso.com esiste un trust in uscita (outgoing) verso fabrikam.com, che diventa il dominio trusted.

La seconda trappola e’ lo strumento. netdom trust gestisce moltissimo — /add, /remove, /twoway, /verify, /reset, le opzioni di sicurezza — ma la documentazione e’ esplicita: netdom trust non puo’ creare un forest trust fra due foreste AD DS. Per quello serve la console Active Directory Domains and Trusts, o uno script PowerShell se devi automatizzare. Un prompt elevato su un DC e un comando netdom trust contoso.com /domain:fabrikam.com /add /twoway /foresttransitive:yes non e’ la risposta giusta: creerebbe al massimo un external trust, non il forest trust chiesto. Il prerequisito, invece, e’ il functional level della foresta — e vale la pena ricordare che oggi i livelli funzionali di dominio e foresta si possono anche abbassare: «non si possono abbassare» e’ una nozione superata.

Mettere in sicurezza un trust che esiste gia’

Quando la migrazione e’ finita, il trust va stretto. Le opzioni sono tutte su netdom trust e hanno ambiti di validita’ diversi — l’esame ci gioca sopra:

Obiettivo Comando Dove e’ valida
Gli account migrati non devono piu’ accedere tramite SID history /EnableSIDHistory:No solo su forest trust in uscita
Accettare solo i SID del dominio direttamente trusted (SID filtering) /Quarantine:Yes trust esterni
Gli utenti trusted si autenticano solo dove glielo concedi /SelectiveAuth:Yes forest trust ed external trust in uscita
Bloccare la delega Kerberos completa verso l’altra foresta /EnableTgtDelegation:No forest trust in uscita

Con la selective authentication al posto del forest-wide authentication, il permesso Allowed to authenticate va concesso oggetto per oggetto sui server che devono restare raggiungibili. Per il routing dei suffissi di un forest trust ci sono /NameSuffixes e /ToggleSuffix:#, da eseguire uno dopo l’altro perche’ l’ordine delle voci puo’ cambiare. Per diagnosticare: netdom trust ... /verify e, se il canale sicuro e’ rotto, /reset.

Siti e subnet: quando un sito serve davvero

Un sito e’ un insieme di subnet ben connesse. Il criterio della documentazione e’ numerico: se la latenza round-trip fra le due reti e’ 10 ms o meno, le subnet possono stare nello stesso sito; sopra i 10 ms no. Un edificio a tre chilometri collegato in fibra non merita un sito nuovo: merita un oggetto subnet in piu’ (10.20.0.0/16) associato al sito esistente. Creare un sito senza DC ne’ applicazioni che lo richiedano aggiunge solo topologia da mantenere.

Si creano siti per: le sedi dove metterai domain controller, e le sedi con applicazioni che usano i siti per trovare il server piu’ vicino (DFS Namespaces, per esempio). Se una sede non merita un sito, la sua subnet va nel sito con cui ha il collegamento WAN migliore. Una subnet non associata a nessun sito e’ il difetto classico: il client non sa in che sito si trova e finisce su un DC qualsiasi del dominio.

Gli oggetti si creano nella console Active Directory Sites and Services o con New-ADReplicationSite, New-ADReplicationSubnet -Name 10.20.0.0/16 -Site HQ, e un DC si sposta con Move-ADDirectoryServer -Site. Dal lato client, nltest /dsgetsite dice in quale sito il computer crede di essere.

Il DC della sede e’ in manutenzione: e adesso?

Comportamento predefinito del DC Locator: prova un DC nel proprio sito; se non ce n’e’, prova un DC qualsiasi del dominio — anche dall’altra parte del mondo. La cura e’ il criterio di Group Policy Try Next Closest Site, disattivato di default: abilitato, inserisce un passaggio intermedio, cioe’ il sito piu’ vicino per costo dei site link, e solo dopo ripiega su un DC qualsiasi. Due dettagli che valgono una domanda: di default il DC Locator non considera i siti che contengono solo RODC nel calcolo del prossimo sito piu’ vicino, e la funzione lavora insieme all’automatic site coverage. Se lo abiliti, tieni la topologia dei costi semplice: e’ la raccomandazione esplicita della documentazione.

Ogni sito deve appartenere ad almeno un site link, altrimenti il log Directory Service segnala che la topologia non e’ connessa. Quando sposti un sito su un link nuovo, toglilo da DEFAULTIPSITELINK: se resta in entrambi, il KCC calcola le rotte sull’unione delle appartenenze e sbaglia percorso.

Il costo e’ il peso della rotta: il KCC sceglie il cammino meno costoso. La tabella ufficiale lo deriva dalla banda (1.024 diviso il logaritmo della banda in Kbps): 64 Kbps → 567, 1.024 Kbps → 340, 4.096 Kbps → 283. Ma la documentazione aggiunge la regola che l’esame preferisce: quei costi non tengono conto dell’affidabilita’, quindi su una linea che cade spesso — un collegamento satellitare, per dire — si imposta un costo piu’ alto apposta, cosi’ il failover della replica non ci finisce sopra. Non si disabilita il link e non si tocca lo schedule: si alza il costo, con Set-ADReplicationSiteLink -Identity BRANCH3-BRANCH2 -Cost 500.

Le altre due proprieta’: replication interval, predefinito 180 minuti, minimo 15, e schedule, che definisce le fasce in cui la replica e’ ammessa. Il trasporto e’ RPC su IP; SMTP e’ un residuo, non replica la partizione di dominio e non va usato.

Bridging: quando la transitivita’ mente

Di default Bridge all site links e’ attivo: tutti i site link sono transitivi, e il KCC assume che ogni DC possa parlare con ogni altro DC. Va disattivato in due casi: quando la rete IP non e’ completamente instradata, e quando vuoi controllare il flusso della replica (failover in hub-and-spoke, o attraverso un firewall). Disattivandolo tutti i link diventano non transitivi, e poi crei site link bridge espliciti che riproducono l’instradamento vero — ogni link del bridge deve condividere un sito con un altro link dello stesso bridge. Un sito di perimetro che raggiunge solo l’hub va modellato cosi’: niente rotte, niente bridge che lo includa insieme alle filiali. In PowerShell: New-ADReplicationSiteLinkBridge.

Replica: chi costruisce la topologia e come la si guarda

Il KCC genera i connection object dentro il sito ogni 15 minuti; l’ISTG, uno per sito, sceglie i bridgehead server che parlano con gli altri siti. La replica intra-site e’ basata su notifica, rapidissima e non compressa; quella inter-site segue schedule e interval ed e’ compressa. I connection object creati a mano scavalcano il KCC: sono una risposta sbagliata quasi sempre.

Per diagnosticare: repadmin /replsummary per la vista d’insieme, repadmin /showrepl per i partner di un DC, repadmin /showconn, repadmin /kcc per forzare il ricalcolo, repadmin /syncall /AdeP per spingere la replica in tutte le direzioni, e lato PowerShell Get-ADReplicationFailure, Get-ADReplicationPartnerMetadata e Sync-ADObject per un singolo oggetto urgente.

Trappole tipiche d’esame

  • Creare un forest trust da riga di comando → non si puo’: netdom trust non crea forest trust fra due foreste AD DS, serve la console Active Directory Domains and Trusts. Un netdom trust /add /twoway in un prompt elevato e’ la risposta sbagliata anche quando il comando «sembra» corretto.
  • Migrazione finita, trust in uscita da stringere → /EnableSIDHistory:No e /SelectiveAuth:Yes: entrambe valgono solo sul lato in uscita del trust; /Quarantine e’ il SID filtering dei trust esterni, non la stessa leva.
  • DC della filiale in manutenzione e i client finiscono ovunque → Try Next Closest Site: e’ un criterio di Group Policy disabilitato di default, non una proprieta’ del sito; e ignora i siti con soli RODC.
  • Nuovo edificio vicino e ben collegato → nuova subnet nel sito esistente, non un nuovo sito: il criterio e’ la latenza (10 ms round-trip), non la distanza in chilometri ne’ il fatto che la subnet sia diversa.
  • Linea inaffidabile che non deve essere usata per la replica → alza il costo del site link: la tabella dei costi guarda la banda, l’affidabilita’ la aggiungi tu; disabilitare il link o cambiare lo schedule non e’ la mossa.
  • Rete non completamente instradata → disabilita Bridge all site links e crea site link bridge: appartenere tutti a qualche site link non basta, perche’ la transitivita’ predefinita fa credere al KCC in rotte che la rete non ha.
  • Sito lasciato dentro DEFAULTIPSITELINK dopo averlo messo in un link nuovo: il KCC somma le due appartenenze e instrada la replica per una strada che non volevi.