Pregunta ¿Buenas prácticas de nombres de Windows Active Directory?


Esto es un Pregunta canónica sobre 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 de manera idéntica a un dominio DNS es una mala idea (lo que significa que tener example.com como nombre de Active Directory no es bueno cuando tenemos el example.com nombre de dominio registrado para su uso como nuestro sitio web).

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

¿Existen prácticas recomendadas sobre lo que debería o no debería ser un nombre de Active Directory?


80
2017-10-21 13:10


origen




Respuestas:


Este ha sido un tema de discusión divertido sobre la falla del servidor. Parece que hay diferentes "opiniones religiosas" sobre el tema.

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

Así que, si tienes foo.com, utilizar ad.foo.com o algo así.

Lo más vil, como 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 los registros del DNS de Internet (como www) en la zona DNS de Active Directory para permitir que los nombres "externos" se resuelvan. He visto cosas completamente tontas como IIS instalado en cada DC en una organización que ejecuta un sitio web que redirige de manera tal que alguien ingresa foo.com en su navegador sería redirigido a www.foo.com Por estas instalaciones de IIS. ¡Absolutamente estupidez!

El uso del nombre de dominio de Internet no le otorga ventajas, pero crea "make work" cada vez que cambia las direcciones IP a las que se refieren los nombres de host externos. (¡Intente usar un DNS con carga equilibrada geográficamente para los hosts externos e integrándolo con una situación de "DNS dividido", también! Vaya, eso sería divertido ...)

El uso de tal subdominio no tiene 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 los veo citados como excusas para usar el nombre de dominio de Internet como el nombre de dominio de AD).

También veo la excusa "muchas compañías grandes lo hacen". Las grandes empresas pueden tomar decisiones sensatas con tanta facilidad (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.


94
2017-10-21 13:16



Pero entonces el nombre NetBIOS del dominio no es ... bueno, bonito :) corp no es tan descriptivo como foo. - Anton Gogolev
Sin embargo, puede asignar el nombre NetBIOS que desee. Muchos de mis clientes tienen nombres como "ad.example.com", pero el nombre de NetBIOS es "EJEMPLO". DCPROMO le preguntará cuál desea que sea el nombre NetBIOS durante la creación del dominio. - Evan Anderson
Si lo hace, tenga cuidado con los problemas con dominios que tienen comodines. Cuando tenga * .foo.com, host.internal.foo.com lo igualará en algunas situaciones - JamesRyan
No tengo conocimiento de ningún producto de servidor de correo electrónico que requiera que uses el nombre de dominio AD como el sufijo de la dirección de correo electrónico de los usuarios. Intercambio tiene Nunca requiere cualquier tipo de correlación entre el nombre de dominio de AD y los sufijos de la dirección de correo electrónico. - Evan Anderson
Office365 solo requiere que sus usuarios inicien sesión con su UPN con un sufijo que coincida con su dominio de inquilino. Dado que la política de direcciones de buzones de Exchange predeterminada se puede definir como cualquier cosa, al igual que su sufijo UPN, es trivial. Tenemos EXAMPLE.COM como el nombre de nuestra compañía (y el arrendatario en Office365), EXAMPLE.NET (también registrado) como el bosque, CORP.EXAMPLE.NET como el dominio de la cuenta principal (con otros subdominios regionales, por ejemplo, EU.EXAMPLE. NET) con EJEMPLO como nombre NetBIOS, todos los usuarios de la organización de Exchange del bosque usan Name@EXAMPLE.COM para UPN y para correo electrónico. Office365 está perfectamente feliz con esto. - Ryan Fisher


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 en la web pública es example.com su AD interno podría ser nombrado algo así como ad.example.com o internal.example.com.

  2. Un dominio de segundo nivel no utilizado que posees y no usar en ningún otro lugar. Por ejemplo, si su presencia en la web pública es example.com su AD podría ser nombrado example.net  mientras te hayas registrado example.net ¡Y no lo uses en ningún otro lugar!

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


¡Pero todo el mundo usa .local!
No importa No deberias Tengo un blog sobre el uso de .local y otros TLD inventados como .lan y .corp. Bajo ninguna circunstancia debes hacer esto.

No es más seguro. No son las "mejores prácticas" como afirman algunas personas. Y no tiene alguna 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 estén example\user en lugar de ad\user
Esta es una preocupación válida, pero equivocada. Cuando promociona el primer DC en un dominio, puede configurar el nombre NetBIOS del dominio a lo que quiera que sea. Si sigues mi consejo y configuras tu dominio para que sea ad.example.com, puede configurar el nombre NetBIOS del dominio para que sea example para 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 principal de UPN 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 utiliza un espacio de nombres DNS de horizonte dividido, lo que significa que su nombre de AD es el mismo que el de su sitio web público. Ahora, tus usuarios no pueden llegar a example.com internamente a menos que tengas el prefijo www. en su navegador o ejecuta IIS en todos sus controladores de dominio (esto es malo). También tienes que curar dos Zonas de DNS no idénticas que comparten un espacio de nombres separado. Es realmente más molestia de lo que vale. Ahora imagine que tiene una sociedad con otra compañía y también tiene 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 un fideicomiso. Ahora, todo su tráfico a cualquiera de sus sitios públicos tiene que atravesar el enlace privado en lugar de simplemente salir a través de 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 trampas. 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 te he recomendado anteriormente.


87
2018-01-29 16:18



Un pequeño punto: uno puede usar algo mucho más pequeño, más rápido y seguro que IIS para servir a la redirección. Incluso haproxy o nginx son probablemente una exageración, y mucho menos un servidor con todas las funciones como apache2. - OrangeDog
Esto es cierto, pero todos De eso es descuidado e innecesario. - MDMarra
Uuuuw, sí, fue muy doloroso cuando alguien registró repentinamente el dominio local.net y todas las impresoras que obtuvieron silenciosamente NXDOMAIN antes de esa fecha de repente no respondieron más. Esa fue una investigación divertida ... - Johannes
Permítanme señalar que .local no está "inventado", de hecho está reservado; Simplemente no para este tipo de uso: en.wikipedia.org/wiki/.local - mikebabcock
En el momento en que esto fue escrito, no estaba reservado. - MDMarra


Para ayudar a la respuesta de MDMarra:

Debieras NUNCA use un nombre DNS de etiqueta única para su nombre de dominio tampoco. 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 mediante el uso de nombres DNS de etiqueta única | Soporte de Microsoft

No olvides NO usar 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 debe seguir dos reglas adicionales (que no están escritas en piedra, pero aún así):

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

Finalmente, te recomendaría que pienses lo más posible a largo plazo. Las empresas atraviesan 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 puedan explicarse 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

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


33
2018-01-29 16:35





No estoy de acuerdo con usar:

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

Podría aceptar el uso de:

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

Pero yo no lo haría ni lo recomendaría. Durante la toma de control de la empresa, el cambio de marca se desencadena, especialmente cuando la gerencia en ese momento quiere que las cosas cambien de inmediato. Renombrando 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 irrelevante para la marca de la compañía. SIMPLE.CLOUD o similar debería hacerlo bien siempre que puedas poseerlo. 

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


1
2017-10-27 15:33





Siempre 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 poder saber que web1.mydomain.local se resolverá a la IP interna de un servidor web, mientras que web1.mydomain.com Se resolverá a la IP externa.


-14
2017-09-23 20:03



FWIW, .local consultas martillo en el servidor raíz de L - ~ 800 / seg cuando miré. - jscott
dot.local, también conocido como dot.Fail - PnP
Usar un TLD no válido (o un dominio no registrado) no es una buena práctica, es una peor práctica, por todas las razones mencionadas anteriormente. Admito que he usado .local, pero eso fue antes de saberlo mejor. - Jonathan J