Mejores prácticas de nombres de Windows Active Directory?

Esta es una pregunta canónica sobre los nombres de dominio de Active Directory.

Después de experimentar con dominios de Windows y controladores de dominio en un entorno virtual, me di cuenta de que tener un dominio de directorio activo nombrado idénticamente a un dominio DNS es una mala idea (lo que significa que tener example.comun nombre de Active Directory no es bueno cuando tenemos el example.comnombre de dominio registrado para su uso como nuestro sitio web).

Esta pregunta relacionada parece respaldar esa conclusión , pero todavía no estoy seguro de qué otras reglas existen para nombrar dominios de Active Directory.

¿Existen algunas prácticas recomendadas sobre cómo debe ser o no un nombre de Active Directory?

Este ha sido un tema de discusión divertido sobre Falla del servidor. Parece haber diferentes "opiniones religiosas" sobre el tema.

Estoy de acuerdo con la recomendación de Microsoft : use un subdominio del nombre de dominio de Internet ya registrado de la compañía.

Entonces, si posee foo.com, use ad.foo.como algo así.

Lo más vil, según lo veo, es usar el nombre de dominio de Internet registrado, literalmente, para el nombre de dominio de Active Directory. Esto hace que se vea obligado a copiar manualmente registros del DNS de Internet (como www) en la zona DNS de Active Directory para permitir que se resuelvan los nombres "externos". He visto cosas completamente tontas como IIS instaladas en cada DC en una organización que ejecuta un sitio web que redirige de manera tal que alguien que ingrese foo.coma su navegador sea redirigido www.foo.compor estas instalaciones de IIS. ¡Absurdas tonterías!

El uso del nombre de dominio de Internet no le ofrece ventajas, pero crea "trabajo" cada vez que cambia las direcciones IP a las que se refieren los nombres de host externos. (¡Intente usar DNS con equilibrio de carga geográfico para los hosts externos e integre eso también con una situación de "DNS dividido"! Gee-- eso sería divertido ...)

El uso de dicho subdominio no tiene ningún efecto en cosas como la entrega de correo electrónico de Exchange o los sufijos de Nombre principal de usuario (UPN), por cierto. (A menudo veo a ambos citados como excusas para usar el nombre de dominio de Internet como nombre de dominio AD).

También veo la excusa "muchas grandes compañías lo hacen". Las grandes empresas pueden tomar decisiones descabelladas tan fácilmente (si no más) que las pequeñas empresas. No compro eso solo porque una gran empresa toma una mala decisión que de alguna manera hace que sea una buena decisión.

Solo hay dos respuestas correctas a esta pregunta.

1. Un subdominio no utilizado de un dominio que usa públicamente. Por ejemplo, si su presencia pública en la web es example.comsu anuncio interno, podría llamarse algo así como ad.example.como internal.example.com.

2. Un dominio de segundo nivel no utilizado que usted posee y no utiliza en ningún otro lugar. Por ejemplo, si su presencia en la web pública es example.comsu AD, ¡podría nombrarse example.net siempre que se haya registrado example.nety no lo use en ningún otro lugar!

Estas son tus dos únicas opciones. Si haces otra cosa, te estás dejando expuesto a mucho dolor y sufrimiento.

¡Pero todos usan .local!
No importa No deberías He blogueado sobre el uso de .local y otros TLD inventados como .lan y .corp . Bajo ninguna circunstancia deberías hacer esto.

No es más seguro. No se trata de "mejores prácticas" como afirman algunas personas. Y no tiene ningún beneficio sobre las dos opciones que he propuesto.

Pero quiero nombrarlo igual que la URL de mi sitio web público para que mis usuarios sean en example\userlugar dead\user
Esto es una preocupación válida, pero equivocada. Cuando promociona el primer DC en un dominio, puede establecer el nombre NetBIOS del dominio a lo que quiera que sea. Si sigue mi consejo y configura su dominio para que sea ad.example.com, puede configurar el nombre NetBIOS del dominio examplepara que sus usuarios inicien sesión como example\user.

En Active Directory Forests and Trusts, también puede crear sufijos UPN adicionales. No hay nada que le impida crear y configurar @ example.com como el sufijo UPN principal para todas las cuentas en su dominio. Cuando combina esto con la recomendación anterior de NetBIOS, ningún usuario final verá que el FQDN de su dominio es ad.example.com. Todo lo que vean será example\o @example.com. Las únicas personas que necesitarán trabajar con el FQDN son los administradores de sistemas que trabajan con Active Directory.

Además, suponga que usa un espacio de nombres DNS de horizonte dividido, lo que significa que su nombre AD es el mismo que su sitio web público. Ahora, sus usuarios no pueden acceder example.cominternamente a menos que tenga un prefijo www.en su navegador o ejecute IIS en todos sus controladores de dominio (esto es malo). También tienes que curar doszonas DNS no idénticas que comparten un espacio de nombres disjunto. Realmente es más complicado de lo que vale. Ahora imagine que tiene una asociación con otra compañía y que también tienen una configuración de DNS de horizonte dividido con su AD y su presencia externa. Tiene un enlace de fibra privado entre los dos y necesita crear una confianza. Ahora, todo su tráfico a cualquiera de sus sitios públicos tiene que atravesar el enlace privado en lugar de simplemente salir por Internet. También crea todo tipo de dolores de cabeza para los administradores de red en ambos lados. Evita esto. Créeme.

Pero pero pero ... En
serio, no hay razón para no usar una de las dos cosas que he sugerido. Cualquier otra forma tiene dificultades. No te estoy diciendo que te apresures a cambiar tu nombre de dominio si está funcionando y en su lugar, pero si estás creando un nuevo AD, haz una de las dos cosas que he recomendado anteriormente.

Para ayudar a la respuesta de MDMarra:

NUNCA debe usar un nombre DNS de etiqueta única para su nombre de dominio. Esto estaba / está disponible antes de Windows 2008 R2. Las razones / explicaciones se pueden encontrar aquí: Implementación y operación de dominios de Active Directory que se configuran utilizando nombres DNS de etiqueta única | Soporte de Microsoft

No olvide NO utilizar palabras reservadas (se incluye una tabla en el enlace "Convenciones de nomenclatura" al final de esta publicación), como SYSTEM o WORLD o RESTRICTED.

También estoy de acuerdo con Microsoft en que debes seguir dos reglas adicionales (que no están establecidas en piedra, pero aún así):

1. NO debe nombrar su dominio en base a algo que cambiará o quedará desactualizado. Los ejemplos incluyen nombrar su dominio después de una línea de productos, sistema operativo o cualquier otra cosa que pueda cambiar con el tiempo. Quédese con algo lo suficientemente geográfico o concreto como para tener sentido 5 o incluso 10 años más adelante.
2. Quédese con nombres cortos de 15 caracteres o menos, esto permitirá que el nombre NETBIOS sea fácilmente el mismo que el nombre de dominio.

Finalmente, recomendaría que piense a largo plazo tanto como sea posible. Las empresas pasan por fusiones y adquisiciones, incluso pequeñas empresas. También piense en términos de obtener ayuda / consulta externa. Utilice nombres de dominio, estructura de AD, etc., que serán explicables a los consultores o personas aquí en SF sin mucho esfuerzo.

Enlaces de conocimiento:

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

Página de recomendación actual de Microsoft (W2k12) para el nombre de dominio del bosque raíz

No estoy de acuerdo con el uso de:

• example.com - por razones ya mencionadas en otras respuestas

Podría aceptar usar:

• ad.example.com - - por razones ya mencionadas en otras respuestas

Pero no lo haría yo mismo ni lo recomendaría. Durante la toma de control de la compañía, se renueva el cambio de marca, especialmente cuando la gerencia en ese punto quiere que las cosas cambien de inmediato. Cambiando el nombre de las migraciones, los cambios son muy difíciles o caros.

La mejor manera que recomendaría es comprar un dominio que sea irrelevante para el nombre de la empresa y también para la marca de la empresa. SIMPLE.CLOUD o similar debería funcionar bien siempre que pueda poseerlo.

He visto grandes compañías con 150,000 usuarios que usan AD y que todavía hacen referencia a compañías viejas que compraron hace años, o compañías que cambiaron de nombre y aunque a la larga no importa que estés usando \ login (si no puedes use UPN) todavía se ve mal frente a la administración que no entiende por qué no es trivial cambiarlo.

Siempre lo hago mydomain.local.

local no es un TLD válido, por lo que nunca compite con una entrada de DNS pública real.

Por ejemplo, me gusta saber que web1.mydomain.localse resolverá en la IP interna de un servidor web, mientras que web1.mydomain.comse resolverá en la IP externa.