Sólo hay dos respuestas correctas a esta pregunta.
-
Un subdominio no utilizado de un dominio que utiliza públicamente. Por ejemplo, si su presencia web pública es example.com su AD interno podría llamarse así ad.example.com o internal.example.com .
-
Un dominio de segundo nivel no utilizado que usted posee y no lo uses en ningún otro sitio. Por ejemplo, si su presencia pública en la web es example.com su AD podría llamarse example.net siempre que se haya registrado example.net y no lo uses en ningún otro sitio.
Estas son sus dos únicas opciones. Si haces otra cosa, te estás exponiendo a mucho dolor y sufrimiento.
Pero todo el mundo utiliza el .local.
No importa. No deberías. Ya he escrito sobre el uso de .local y otros TLDs inventados como .lan y .corp . Bajo ninguna circunstancia debes hacer esto.
No es más seguro. No son las "mejores prácticas", como afirman algunos. Y no tiene cualquier beneficio sobre las dos opciones que he propuesto.
Pero quiero ponerle el mismo nombre que la URL de mi sitio web público para que mis usuarios sean example\user en lugar de ad\user
Es una preocupación válida, pero equivocada. Cuando se promociona el primer DC de un dominio, se puede establecer el nombre NetBIOS del dominio como se desee. 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 se conecten como example\user .
En los bosques y fideicomisos de Active Directory, también puede crear sufijos UPN adicionales. No hay nada que te impida crear y establecer @ejemplo.com como sufijo UPN principal para todas las cuentas de tu dominio. Si 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 . Los únicos que tendrán que 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 el nombre de su AD es el mismo que el de su sitio web de cara al público. Ahora, sus usuarios no pueden llegar a example.com internamente a menos que los tenga prefijados www. en su navegador o ejecuta IIS en todos sus controladores de dominio (esto es malo). También tienes que curar dos zonas DNS no idénticas que comparten un espacio de nombres distinto. En realidad es más molestia de lo que merece la pena. Ahora imagine que tiene una asociación con otra empresa y que ellos también tienen una configuración de DNS de horizonte dividido con su AD y su presencia externa. Usted tiene un enlace de fibra privada 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 salir por Internet. También crea todo tipo de dolores de cabeza para los administradores de la red en ambos lados. Evita esto. Confía en mí.
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 he recomendado arriba.
