Best practice per la denominazione di Windows Active Directory?

Questa è una domanda canonica sulla denominazione del dominio di Active Directory.

Dopo aver sperimentato i domini Windows e i controller di dominio in un ambiente virtuale, mi sono reso conto che avere un dominio di Active Directory denominato in modo identico a un dominio DNS non è una buona idea (Significa che avere example.comcome nome di Active Directory non va bene quando abbiamo il example.comnome di dominio registrato per l'uso come nostro sito Web).

Questa domanda correlata sembra supportare tale conclusione , ma non sono ancora sicuro di quali altre regole ci siano in merito alla denominazione dei domini di Active Directory.

Esistono buone pratiche su ciò che un nome di Active Directory dovrebbe o non dovrebbe essere?

Questo è stato un argomento di discussione divertente su Server Fault. Sembra che ci siano diverse "opinioni religiose" sull'argomento.

Sono d'accordo con la raccomandazione di Microsoft : utilizzare un sottodominio del nome di dominio Internet già registrato dell'azienda.

Quindi, se possiedi foo.com, usa ad.foo.como qualcosa del genere.

La cosa più vile, come la vedo io, sta usando il nome di dominio Internet registrato, letteralmente, per il nome di dominio di Active Directory. Questo ti costringe a copiare manualmente i record da Internet DNS (come www) nella zona DNS di Active Directory per consentire la risoluzione di nomi "esterni". Ho visto cose assolutamente stupide come IIS installate su ogni controller di dominio in un'organizzazione che gestisce un sito Web che esegue un reindirizzamento in modo tale che qualcuno che accede foo.comal proprio browser verrebbe reindirizzato www.foo.comda queste installazioni IIS. Assoluta pazzia!

L'uso del nome di dominio Internet non offre alcun vantaggio, ma crea "make work" ogni volta che si modificano gli indirizzi IP a cui fanno riferimento i nomi host esterni. (Prova a usare DNS bilanciato geograficamente per gli host esterni e integralo anche con una situazione "DNS diviso"! Accidenti, sarebbe divertente ...)

L'uso di un sottodominio di questo tipo non ha alcun effetto su cose come la consegna di e-mail di Exchange o i suffissi UPN (User Principal Name), BTW. (Vedo spesso entrambi citati come scuse per l'utilizzo del nome di dominio Internet come nome di dominio AD).

Vedo anche la scusa "molte grandi aziende lo fanno". Le grandi aziende possono prendere decisioni difficili come le altre (se non più). Non lo compro solo perché una grande azienda prende una decisione sbagliata che in qualche modo ne fa una buona decisione.

Ci sono solo due risposte corrette a questa domanda.

1. Un sottodominio inutilizzato di un dominio che usi pubblicamente. Ad esempio, se la tua presenza sul web pubblico è il example.comtuo AD interno potrebbe essere chiamato come ad.example.como internal.example.com.

2. Un dominio di secondo livello inutilizzato che possiedi e che non usi altrove. Ad esempio, se la tua presenza sul web pubblico è il example.comtuo AD potrebbe essere nominato example.net fintanto che ti sei registrato example.nete non utilizzarlo altrove!

Queste sono le tue uniche due scelte. Se fai qualcos'altro, ti stai lasciando aperto a molto dolore e sofferenza.

Ma tutti usano .local!
Non importa Non dovresti. Ho scritto un blog sull'uso di .local e di altri TLD inventati come .lan e .corp . In nessun caso dovresti mai farlo.

Non è più sicuro. Non sono le "migliori pratiche" come sostengono alcune persone. E non ha alcun vantaggio rispetto alle due scelte che ho proposto.

Ma voglio nominarlo come l'URL del mio sito web pubblico in modo che i miei utenti siano example\userinvecead\user
Questa è una preoccupazione valida, ma sbagliata. Quando si promuove il primo controller di dominio in un dominio, è possibile impostare il nome NetBIOS del dominio su quello che si desidera. Se segui i miei consigli e imposti il ​​tuo dominio ad.example.com, puoi configurare il nome NetBIOS del dominio in examplemodo che gli utenti accedano come example\user.

Nelle foreste e trust di Active Directory è possibile creare anche suffissi UPN aggiuntivi. Non c'è nulla che ti impedisca di creare e impostare @ example.com come suffisso UPN principale per tutti gli account nel tuo dominio. Quando lo combini con la precedente raccomandazione NetBIOS, nessun utente finale vedrà mai l'FQDN del tuo dominio ad.example.com. Tutto ciò che vedranno sarà example\o @example.com. Le uniche persone che dovranno lavorare con il nome di dominio completo sono gli amministratori di sistema che lavorano con Active Directory.

Inoltre, supponi di utilizzare uno spazio dei nomi DNS a orizzonte diviso, il che significa che il tuo nome AD è lo stesso del tuo sito web pubblico. Ora, i tuoi utenti non possono accedere example.cominternamente a meno che tu non li abbia prefisso www.nel loro browser o non esegui IIS su tutti i tuoi controller di dominio (questo è male). Devi anche curarne duezone DNS non identiche che condividono uno spazio dei nomi disgiunto. È davvero più seccante di quanto valga la pena. Ora immagina di avere una partnership con un'altra società e che abbiano anche una configurazione DNS split-horizon con il loro AD e la loro presenza esterna. Hai un collegamento in fibra privata tra i due e devi creare un trust. Ora, tutto il tuo traffico verso i loro siti pubblici deve attraversare il collegamento privato invece di uscire semplicemente su Internet. Crea anche tutti i tipi di mal di testa per gli amministratori di rete su entrambi i lati. Evitare questo. Fidati di me.

Ma ma ...
Seriamente, non c'è motivo di non usare una delle due cose che ho suggerito. Qualsiasi altro modo ha insidie. Non ti sto dicendo di affrettarti a cambiare il tuo nome di dominio se è funzionante e in atto, ma se stai creando un nuovo annuncio, fai una delle due cose che ho raccomandato sopra.

Per aiutare la risposta di MDMarra:

Si dovrebbe MAI utilizzare un nome DNS con etichetta singola per il tuo nome di dominio sia. Questo era / è disponibile prima di Windows 2008 R2. Motivi / spiegazioni sono disponibili qui: Distribuzione e funzionamento dei domini di Active Directory configurati utilizzando nomi DNS con etichetta singola | Supporto Microsoft

Non dimenticare di NON utilizzare parole riservate (una tabella è inclusa nel link "Convenzioni di denominazione" nella parte inferiore di questo post), come SYSTEM o WORLD o RESTRICTED.

Sono anche d'accordo con Microsoft sul fatto che dovresti seguire due regole aggiuntive (che non sono impostate nella pietra, ma comunque):

1. NON devi nominare il tuo dominio in base a qualcosa che cambierà o diventerà obsoleto. Gli esempi includono la denominazione del dominio in base a una linea di prodotti, un sistema operativo o qualsiasi altra cosa che possa cambiare nel tempo. Attenersi a qualcosa di geografico o concreto sufficiente per dare un senso a 5 o anche 10 anni lungo la strada.
2. Stick con nomi brevi di 15 caratteri o meno, questo consentirà al nome NETBIOS di essere facilmente uguale al nome di dominio.

Infine, consiglierei di pensare il più a lungo possibile. Le aziende subiscono fusioni e acquisizioni, anche piccole aziende. Pensa anche in termini di assistenza / consulenza esterna. Usa nomi di dominio, strutture AD, ecc. Che saranno spiegabili a consulenti o persone qui su SF senza troppi sforzi.

Collegamenti di conoscenza:

http://technet.microsoft.com/en-us/library/cc731265%28v=ws.10%29.aspx

http://support.microsoft.com/kb/909264

http://support.microsoft.com/kb/300684/en-us

Pagina di consigli di Microsoft (W2k12) corrente per il nome di dominio della foresta radice

Non sono d'accordo con l'utilizzo di:

• esempio.com - per motivi già indicati in altre risposte

Potrei accettare usando:

• ad.example.com - - per motivi già indicati in altre risposte

Ma non lo farei da solo o lo consiglierei. Durante l'acquisizione dell'azienda, il rebranding di ogni inferno si scatena soprattutto quando la direzione a quel punto vuole che le cose cambino immediatamente. Rinominando le migrazioni, le modifiche sono molto difficili o costose.

Il modo migliore che consiglierei è di acquistare un dominio irrilevante per il nome dell'azienda e anche irrilevante per il marchio dell'azienda. SIMPLE.CLOUD o simili dovrebbero andare bene fintanto che puoi possederlo.

Ho visto grandi aziende con 150.000 utenti che usano AD che fa ancora riferimento a vecchie aziende che hanno acquistato anni fa, o aziende che hanno cambiato nome e anche se a lungo termine non importa che stai usando \ login (se non puoi usa UPN) sembra ancora male di fronte al management che non capisce perché non è banale cambiarlo.

Lo faccio sempre mydomain.local.

local non è un TLD valido, quindi non compete mai con una voce DNS pubblica effettiva.

Ad esempio, mi piace essere in grado di sapere che web1.mydomain.localsi risolverà nell'IP interno di un server Web, mentre web1.mydomain.comsi risolverà nell'IP esterno.