Unire una VM Azure a Entra Domain Services: decidere prima

Tre decisioni stanno davanti a una VM Windows Server che deve usare una directory gestita, e il comando di unione è la minore di esse. Scegliete il modello di directory sbagliato e l'unione riesce mentre l'applicazione continua a non potersi autenticare. Sbagliate la risoluzione dei nomi e il guasto compare in un punto che sembra un problema di credenziali.

Definite modello, risoluzione e account prima di toccare il server, poi il comando gira una volta.

Quale delle tre unioni volete davvero

L'unione del dispositivo registra una macchina in Microsoft Entra ID per l'accesso condizionale e l'accesso singolo, e non dà al carico di lavoro alcun ticket Kerberos verso un dominio in stile locale. L'unione al dominio tradizionale lega un oggetto computer in una directory e gli dà un account macchina, criteri di gruppo e autenticazione del dominio. Un dominio gestito fornisce quel secondo modello come servizio. I nomi suonano simili e i risultati no.

Solo le ultime due coinvolgono un controller di dominio nel senso comune, e solo l'opzione gestita toglie i server dal vostro elenco di patch.

La decisione di solito dipende dall'applicazione e non dalla preferenza. Il software che vuole un bind LDAP, un account di servizio con un SPN o oggetti di criteri di gruppo appartiene al modello di dominio. Il software che deve solo conoscere l'identità dell'utente su un dispositivo aziendale di solito no.

Il percorso DNS decide se l'unione può concludersi

Un'unione al dominio inizia con una ricerca di localizzatore per i record del controller del dominio, quindi la risoluzione dei nomi deve funzionare prima che venga controllata qualsiasi credenziale. Indirizzate la VM verso gli indirizzi di directory del dominio gestito, tramite le impostazioni DNS della rete virtuale o tramite un forwarder condizionale che manda lì solo quello spazio dei nomi. Un forwarder limitato allo spazio dei nomi è di solito la scelta più sicura, perché lascia intatto il resto della risoluzione della VM.

Provate il localizzatore e non un nome host nudo. Un ping al nome del dominio non dimostra quasi nulla, mentre una query SRV dei record del controller del dominio o restituisce i target attesi o fallisce subito:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53

Sostituite il nome del dominio e i due indirizzi con i valori della configurazione del vostro dominio gestito; i numeri qui sono esempi. Se la query restituisce risposte di un'altra zona, la VM usa un resolver che non inoltra lo spazio dei nomi gestito, e nessun numero di tentativi dell'unione lo cambierà.

Tenete il carico di lavoro fuori dalla subnet che il dominio gestito riserva alle proprie risorse di servizio, e tenete le porte della directory sul percorso privato. L'esposizione pubblica di quelle porte non è una scorciatoia; è un progetto diverso con un profilo di rischio diverso.

L'idoneità dell'account si controlla prima della macchina

L'account che esegue l'unione ha bisogno del permesso di creare un oggetto computer nel contenitore di destinazione, e deve potersi autenticare contro il dominio gestito. Un account solo cloud creato prima che il dominio gestito esistesse può mancare del materiale derivato dalla password che il dominio richiede, e un cambio o una reimpostazione della password lo rigenera. Quel dettaglio spiega una classe di errori di unione che sembrano password sbagliate quando la password è corretta. Provate la credenziale contro il dominio prima che si apra la finestra di manutenzione.

Gli account ibridi sincronizzati hanno i propri prerequisiti che un oggetto utente visibile non soddisfa da solo. Essere elencati nella directory non è lo stesso che poter ottenere un ticket da essa, quindi provate l'account prima della finestra di manutenzione e non durante.

Delegare il diritto di unione in modo stretto. Dare a ogni futuro utente del server l'appartenenza agli amministratori del dominio perché avvenga una sola registrazione è una concessione permanente per un problema temporaneo.

L'unione stessa è un solo comando

Con il modello scelto, il DNS che risponde e l'account idoneo, l'operazione è quella abituale di Windows. Il prompt tiene la password fuori dagli script e dalla cronologia della shell:

Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru

Il comando non riavvia la macchina da solo in questa forma, quindi il riavvio avviene secondo il piano di manutenzione e con il percorso di ripristino ancora disponibile. Un server già unito a un altro dominio necessita di un piano di migrazione, non di una seconda unione sopra la prima.

Annotate il contenitore in cui è finito l'oggetto computer e l'account che l'ha creato. Entrambi contano quando la macchina va riunita dopo una ricostruzione, e nessuno dei due è evidente dal server in seguito.

Ciò che l'appartenenza non concede

L'appartenenza al dominio non rende nessuno amministratore locale e non concede l'accesso al desktop remoto o alle condivisioni di file. Quei diritti si configurano separatamente, e su un dominio gestito restano nel suo ambito amministrativo supportato.

Il percorso di rete è una dipendenza continua e non un passo di configurazione. Se la connessione privata sparisce, il server continua a funzionare con credenziali in cache finché qualcosa non ha bisogno della directory, e allora il guasto arriva in un log applicativo e non accanto alla configurazione che è cambiata.

La guida di Microsoft per l'unione di Windows Server elenca i prerequisiti supportati per il flusso di lavoro del dominio gestito. Leggetela rispetto alle tre decisioni sopra e trattate ogni discrepanza come un motivo per fermarvi e non come un dettaglio da aggirare.