Guide / windows-server
windows-server-ibrido · Capitolo 2 di 6
Perché il dominio AD non deve essere il dominio pubblico
Chiamare la directory interna come il dominio pubblico crea lo split-brain DNS, e lo paghi per anni. Un sottodominio non costa niente e lo evita.
Promuovere un server a domain controller chiede un nome di dominio. Sembra una formalità — possiedi esempio.it, quindi scrivi esempio.it — ed è l’unica decisione di tutta la costruzione che è davvero difficile da annullare.
Cosa va storto con la risposta ovvia
Se il dominio Active Directory interno si chiama esempio.it, e esempio.it è anche il dominio su cui vivono il sito e la posta, hai creato lo split-brain DNS: due sorgenti autoritative per la stessa zona, una interna e una pubblica, che non sanno l’una dell’altra.
Il primo giorno funziona. Costa un po’ ogni anno successivo, e i costi arrivano sotto forma di misteri: un servizio che va da casa e non dall’ufficio, un rinnovo di certificato che fallisce solo internamente, una posta che si comporta diversamente per i dipendenti.
La risposta che non costa niente
Usa un sottodominio dedicato per la directory:
ad.esempio.it ← il dominio Active Directory
corp.esempio.it ← stessa idea, gusto diversoIl DNS interno diventa autoritativo per ad.esempio.it, che è una zona che fuori non usa nessuno. Le query per esempio.it vengono inoltrate verso l’esterno e risposte dal DNS pubblico, come devono. Per ogni nome c’è esattamente un’autorità.
Gli utenti mantengono l’indirizzo giusto
L’obiezione immediata: se il dominio è ad.esempio.it, gli utenti diventano [email protected]?
No. Il nome della directory e il nome con cui si accede sono due cose separate, ed è questo passaggio a rendere gratuita la scelta del sottodominio.
In Domini e trust di Active Directory si aggiunge esempio.it come suffisso UPN alternativo. Poi si imposta il nome di accesso di ogni utente perché lo usi. Gli utenti sono [email protected], coerenti con il loro indirizzo di posta e con il loro account Microsoft 365, mentre la directory sotto si chiama in tutt’altro modo.
Il resto della promozione
- Installa i ruoli Servizi di dominio Active Directory e DNS.
- Promuovi a domain controller di una nuova foresta, con il sottodominio come nome di dominio.
- Imposta i server d’inoltro DNS — il firewall o un resolver pubblico — così che il server risolva tutto ciò che non è la propria zona.
- Aggiungi
esempio.itcome suffisso UPN in Domini e trust. - Crea un’unità organizzativa per gli utenti da sincronizzare, più un account amministrativo dedicato e un utente di prova.
- Snapshot, con un nome che dica cos’è.
L’unità organizzativa del punto 5 conta più di quanto sembri: la sincronizzazione della directory si può filtrare per OU, e avere già separati gli account che devono andare nel cloud da quelli che non devono trasforma quel filtro in un clic invece che in un ripensamento.
Tre cose sulla macchina
Un domain controller è infrastruttura critica. Segmento di rete fidato, sempre acceso, snapshot e backup. Non sulla stessa VLAN dei dispositivi IoT, e non una macchina che qualcuno spegne per liberare memoria.
La sincronizzazione è a senso unico. Una volta attiva, la directory on-premise è la fonte di verità. Gli attributi sincronizzati si modificano on-premise; cambiarli nel cloud o fallisce o viene sovrascritto al ciclo successivo. Meglio saperlo prima che qualcuno corregga un cognome nel portale sbagliato.