Best practices per la migrazione e la sostituzione dei Domain Controller in Active Directory

Active Directory Domain Services (AD DS) da più di 20 anni è nelle aziende il cuore dell’identità che regolamenta gli accessi alle risorse, applica le impostazioni di configurazione e regola la sicurezza per gli oggetti. Dalla prima versione basata su Windows 2000 siamo arrivati ad oggi alla versione 2022.

Il prossimo 10 ottobre 2023 termina il supporto esteso di Windows Server 2012 e Windows Server 2012 R2 e di conseguenza, tutte le aziende che non avranno sostituito questa release non riceveranno più aggiornamenti di sicurezza e supporto su problematiche scaturite da questi sistemi operativi. Questo vale ovviamente anche per il nostro caro amico di vecchia data Active Directory e dei pilastri su cui sta in piedi: i Domain Controllers.

Questo post non tratta di una guida per migrare AD dalla versione 2012 R2 alla versione X a piacimento… troppo semplice. La realtà è ben diversa (purtroppo).

Le migrazioni che al 90% dei casi mi capita di fare è questa azienda tipo (demo.lab) dove si trovano due polverosi Domain Controller (DC1 e DC2) con rispettivi IP statici su cui puntano, dialogano, contattano, interrogano tutti gli applicativi ed apparati di rete aziendali.

  • DC1 e DC2 sono stati creati (next next next) dall’amico smanettone sotto casa che “sapeva di computer e dell’internet”
  • DC1 e DC2 sono nomi statici cablati hardcoded in applicativi su cui gira il gestionale scritto dallo smanettone universitario di cui oggi non abbiamo uno straccio di documentazione (che poi quando chiediamo di lui ci dicono che lavora in un villaggio turistico)
  • DC1 viene interrogato by LDAP da un applicativo (applicativo che, come sempre, se si ferma l’azienda perde 1000€ al minuto di fatturato)
  • I relativi IP address di DC1 e DC2 sono impostati su tutti gli apparati di rete settati come DNS server e magari settati come IP helper address per rilasciare indirizzi dal DHCP su sedi sparse in tutto il mondo.

Capite dunque che, se facciamo “la migrazione” SENZA considerare questi due fattori (IP e DC name) rischiamo di far collassare tutto avendo impatti devastanti?
Non avete idea di quante volte i clienti mi abbiano detto: “Come mai se spengo il DC1 mi si blocca metà azienda? Non avevi detto che i servizi di Directory e DNS sono ridondati?”

Si, se ci penso mi scappa da ridere… vai tu a rincorrere chi ti ha scritto quella query LDAP?

Come risolviamo questa problematica? Abbiamo due possibilità:

  • Con un’analisi applicativa e relativo sviluppo per il cambio puntatori + cambio puntamenti indirizzi apparati di rete
    Analisi complicata ma AD migration semplice
    va scelta se l’intenzione è quella di creare nuovi nomi DC con nuovi IP ed approfittarne per svincolarsi dal vecchio ambiente
  • Con una migrazione Active Directory basata su una tecnica che chiamo “gioco delle tre carte” e con un rename DC
    Analisi evitata ma AD migration articolata
    va scelta se l’intenzione è quella di mantenere IP e nomi DC

Bene, oggi approfondiamo la seconda scelta, quella più articolata: il gioco delle tre carte

La situazione di partenza è tendenzialmente questa.

Figura 1 – Best Practice Migrazione DC situazione iniziale

Verifiche preliminari

Prima di iniziare a montare i nuovi Domain Controllers che andranno a sostituire gli esistenti consiglio un controllo allo stato dei Directory Services attraverso gli eventi ed i check SYSVOL, DNS e repliche attraverso questi comandi:

Verifiche SYSVOL: “dcdiag /e /test:sysvolcheck /test:advertising”

Verifiche DNS sul site AD: “dcdiag /Test:DNS /a

Verifiche DNS su tutti i DC: “dcdiag /Test:DNS /e

Verifiche repliche: “repadmin /showrepl

Verifiche time sync: “w32tm /query /status”

Verificare anche che il vecchio metodo di replica FRS sia migrato a DFSR. Se non l’avete già fatto vi rimando all’articolo di Ermanno Goletto e Roberto Massa che spiegano come migrare facilmente il metodo di replica a DFSR che, dalla versione Windows server 2019 è l’unico supportato (quindi non potete installare DC 2019 se non lo portate a DFSR)
Upgrade domain controller a Windows Server 2016 Parte 4 di 4 – ICT Power

Una volta verificato che i Domain Controllers siano in salute e replichino correttamente fra di loro possiamo procedere ad installare, e quindi affiancare, due nuovi Domain Controllers.

Figura 2 – Best Practice Migrazione DC domain Join

I due nuovi server Windows 2022 saranno dc1new e dc2new.

  1. Dargli un nome facilmente riconoscibile
  2. Impostargli i DNS DC1 e DC2
  3. Verificare che l’FQDN domain name sia raggiungibile per la server join
  4. Joinarli a dominio
  5. Impostare il dominio di destinazione
  6. Inserire le credenziali

La procedura appena riportata sarà da applicare a tutti i nuovi Domain controllers che prepareremo per il change DC. So che per alcuni risulta banale ma in passato ho visto tentare promozioni a Domain Controllers direttamente da server in workgroup cosa che, magari ha funzionato, ma sconsiglio.

Appena i nuovi server saranno member servers li troveremo nella folder computers pronti a diventare i nuovi Domain Controllers del nostro dominio demo.lab

Figura 3 – Best Practice Migrazione DC domain Joined

Promozione nuovi Domain Controllers

Ora che abbiamo i nostri due nuovi server Windows 2022 joinati nel dominio demo.lab possiamo procedere a promuoverli a ruolo di Domain Controllers: la procedura seguente sarà da applicare a tutti i nuovi Domain controllers che prepareremo per il change DC.

Qui di seguito vengono mostrati i diversi passaggi per installare i file binari necessari per implementare il ruolo di controller di dominio. Per velocizzare le attività possiamo installare i Management Tools via PowerShell attraverso questo comando: Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Figura 4 – Best Practice Migrazione DC installazione AD DS Management Tools

Una volta montati i management tools possiamo procedere alla promozione DC via GUI con il “Server Manager”.
Volendo si può fare via PowerShell con i seguenti comandi: Install-ADDSDomainController -DomainName “demo.lab” -InstallDns:$true -Credential (Get-Credential “DEMO\administrator”)

Figura 5 -Best Practice Migrazione DC domain promotion

Verrà proposto di inserire i nuovi Domain Controllers nel dominio esistente demo.lab

Figura 6 – Best Practice Migrazione DC add existing domain

Scegliere una DSRM password: NON sottovalutate questa password siccome equivale ad una local admin password della macchina.
A tal proposito vi rimando al seguente link dove vengono trattate le novità di Windows LAPS e la gestione centralizzata della DSRM password #POWERCON2023 – evento online del 14 luglio – Ermanno Goletto e Roberto Massa – Implementare e gestire Windows LAPS – ICT Power

Figura 7 – Best Practice Migrazione DC DSRM password

Potete quindi tranquillamente ignorare il messaggio di avviso di delega DNS.

Figura 8 – Best Practice Migrazione DC DNS Delegation Optoions

La seguente pagina permette di scegliere a quale DC replicare le partizioni

Figura 9 – Best Practice Migrazione DC replication Options

Nella pagina Percorsi è possibile sostituire i percorsi predefiniti delle cartelle per il database di Servizi di dominio Active Directory, i registri delle transazioni del database e la condivisione SYSVOL. Le posizioni predefinite sono sempre in sottodirectory di %systemroot% (ad esempio, C:\Windows).

Figura 10 – Best Practice Migrazione DC database path

Nella pagina seguente pagina ci viene ricordato che la foresta e relativo schema verranno aggiornate all’ultima versione.

In questo caso passeremo dalla versione 69 di Windows Server 2012 R2 alla versione 88 di Windows Server 2022 (da Windows Server 2019 non è cambiata)

Figura 11 – Best Practice Migrazione DC preparation Options

La pagina Controllo dei prerequisiti convalida che la configurazione scelta sia in grado di supportare una nuova foresta Servizi di dominio Active Directory. Cliccate quindi su Install e attendete il riavvio della macchina.

Figura 12 – Best Practice Migrazione DC Checks prerequisiti

Una volta terminata la promozione a ruolo di Domain Controller il server verrà automaticamente riavviato

Figura 13 – Best Practice Migrazione DC restart a termine promozione

Una volta preparati i nuovi server, installati i sistemi operativi, aggiornati e promossi a ruolo Domain Controllers avremo una situazione analoga a questa:

Figura 14 – Best Practice Migrazione DC situazione post promozione DC sostitutivi

Prima di procedere al punto cruciale dell’articolo verifichiamo nuovamente lo stato di replica Domain Controllers attraverso il comando “repadmin /showrepl

Figura 15 – Best Practice Migrazione DC repadmin /syncall

Il gioco delle tre carte

Siamo arrivati al gioco delle tre carte: come funziona?

Per ogni coppia di Domain Controller da sostituire avremo bisogno di un IP provvisorio su cui andremo ad appoggiarci per il cambio IP. Ora ci focalizzeremo sul cambio DC2 con DC2new. Il seguente elenco spiega come procederemo:

  1. Sul DC2 impostiamo l’IP jolly 192.168.0.200
  2. Riavviamo il server DC2
  3. Replichiamo la modifica a tutti i DC con “repadmin /syncall” e verifichiamo che i DNS si siano registrati correttamente
  4. Sul DC2new impostiamo l’IP 192.168.0.2 – Lo possiamo fare ora dato che l’IP originario è libero
  5. Riavviamo il server DC2new – Dopo il riavvio gli applicativi ricontatteranno il DNS originario 192.168.0.2
  6. Replichiamo la modifica a tutti i DC con “repadmin /showreple verifichiamo che i DNS si siano registrati correttamente
  7. Demote del DC2
  8. Rename
    di DC2new in DC2

Figura 16 – Best Practice Migrazione DC procedura

NOTA BENE: è consigliabile fare l’attività in accordo con l’azienda ed in orari di basso carico operativo. I punti sensibili sono dal punto uno al punto cinque, siccome in quel range temporale la connettività verso il server che andremo a sostituire non sarà garantita.

Ora i punti nel dettaglio

1 – Sul DC2 impostiamo l’IP jolly 192.168.0.200

Figura 17 – Best Practice Migrazione DC set IP jolly

2 – Riavviamo il server DC2

3Replichiamo la modifica a tutti i DC con “repadmin /syncalle verifichiamo
che i DNS si siano registrati correttamente

Al riavvio di DC2 forziamo le repliche con tutti i DC attraverso il comando “repadmin /syncall

Figura 18 – Best Practice Migrazione DC

4 – Sul DC2new impostiamo l’IP 192.168.0.2 – Lo possiamo fare ora dato che l’IP originario è libero

Figura 19 – Best Practice Migrazione DC change IP

5 – Riavviamo il server DC2new

6 – Replichiamo la modifica a tutti i DC con “repadmin /showreple verifichiamo che i DNS si siano registrati correttamente

In questo momento la criticità di non aver il DNS 192.168.0.2 è rientrata siccome al restart server, il servizio DNS ha ripreso a rispondere a tutte le query. Allo stesso modo, se riteniamo fondamentale ripristinare il nome macchina originario (DC2) per l’applicativo che punta staticamente al nome macchina, dovremo procedere con il demote del DC2 e rename del DC2new in DC2

Figura 20 – Best Practice Migrazione DC

7 – Demote del DC2

Figura 21 – Best Practice Migrazione DC Demote

Figura 22 – Best Practice Migrazione DC demote

Figura 23 – Best Practice Migrazione DC demote

Figura 24 – Best Practice Migrazione DC demote

Figura 25 – Best Practice Migrazione DC Proceed with removal

La seguente password è quella che sarà impostata per l’amministratore locale del server member

Figura 26 – Best Practice Migrazione DC demote

Figura 27 – Best Practice Migrazione DC demote

Figura 28 – Best Practice Migrazione DC demote

Una volta demotato il server DC2 diventerà un member server. Prima di rinominare DC2new in DC2 ricordarsi di:

  • rimuovere l’oggetto computer DC2 da “Active Directory Sites and Services
  • verificare eventuali record nel DNS sporchi lasciati dal demote
  • eliminare l’oggetto account computer da “Active Directory User and Computers”
  • spegnere e/o scollegare il vecchio server DC2

Figura 29 – Best Practice Migrazione DC demote

Figura 30 – Best Practice Migrazione DC demote

Figura 31 – Best Practice Migrazione DC demote

8 – Rename di DC2new in DC2

Ora che ci siamo liberati di ogni traccia del vecchio server DC2 windows 2012 R2, possiamo procedere con il rename Domain Controller da DC2new a DC2

Figura 32 – Best Practice Migrazione DC rename

Figura 33 – Best Practice Migrazione DC rename

Una volta riavviato ci assicureremo che le repliche ed i valori DNS siano corretti.

Figura 34 – Best Practice Migrazione DC rename

A termine dell’attività di sostituzione DC2 la situazione sarà come la seguente:

Figura 35 – Best Practice Migrazione DC

Ora possiamo concentrarci con la seconda coppia di Domain Controllers DC1 e DC1new seguendo lo stesso principio delle tre carte appoggiandoci all’IP jolly 192.168.0.100

Prima però dovremo spostare i ruoli FSMO da DC1 a DC2 attraverso questo semplice comando: Move-ADDirectoryServerOperationMasterRole -Identity netbiosName -OperationMasterRole 0,1,2,3,4

i valori 0,1,2,3 e 4 sono relativi ai ruoli FSMO mentre netbiosName il nome DC di destinazione su cui sposteremo i ruoli

PDCEmulator or 0

RIDMaster or 1

InfrastructureMaster or 2

SchemaMaster or 3

DomainNamingMaster or 4

Con il comando netdom query FSMO chiediamo ad Active Directory quale server detiene il ruolo.

Figura 36 – Best Practice Migrazione DC move FSMO roles

Figura 37 – Best Practice Migrazione DC move FSMO roles

Conclusioni

Come avete visto il mantenimento dei nostri nomi Domain Controller ed IP storici aziendali è possibile attraverso questa procedura.

È possibile anche intervenire “a cuore aperto” (lo faccio spesso) basta che si sappia esattamente dove sono i punti critici. Quello su cui dobbiamo fare massima attenzione è verificare sempre le repliche fra i DC attraverso Active Directory Sites and Services specialmente in aziende in cui i DC sono collocati in aree geografiche estese. In base a questo possiamo disegnare un piano a basso impatto di sostituzione graduale per il mantenimento dei processi aziendali che rimuova i vecchi DC su Windows 2012 R2 e successivamente innalzi la funzionalità di foresta e dominio alla versione di sistema operativo compatibile con i nostri DC appena aggiornati.