Nombrar un nuevo bosque de Active Directory: ¿por qué no se recomienda DNS de horizonte dividido?


23

Con suerte , todos sabemos cuáles son las recomendaciones para nombrar un bosque de Active Directory , y son bastante simples. Es decir, se puede resumir en una sola oración.

Use un subdominio de un nombre de dominio registrado existente y elija uno que no se vaya a usar externamente. Por ejemplo, si tuviera que incorporar y registrar el hopelessn00b.comdominio, mi bosque AD interno debería llamarse internal.hopelessn00b.comor ad.hopelessn00b.como corp.hopelessn00b.com.

Hay razones abrumadoramente convincentes para evitar el uso de dominios de primer nivel "falsos" o nombres de dominio de etiqueta única , pero estoy teniendo un tiempo difícil encontrar razones convincentes de manera similar a evitar el uso del dominio raíz ( hopelessn00b.com) ya que mi nombre de dominio y utilizar un subdominio como corp.hopelessn00b.comlugar . Realmente, la única justificación que puedo encontrar es que el acceso al sitio web externo desde el interno requiere un A nameregistro DNS y escribir www.frente al nombre del sitio web en un navegador, que es bastante "meh" en lo que respecta a los problemas.

Entonces, ¿qué me estoy perdiendo? ¿Por qué es mucho mejor usar ad.hopelessn00b.comcomo mi nombre de bosque de Active Directory hopelessn00b.com?

Solo para que conste, es realmente mi empleador el que necesita convencerse: el hombre jefe está vendiendo atrasados, y después de darme el visto bueno para crear un nuevo bosque de AD llamado corp.hopelessn00b'semployer.compara nuestra red interna, quiere quedarse con un bosque de AD llamado hopelessn00b'semployer.com( lo mismo que nuestro dominio registrado externamente). Espero poder obtener alguna razón convincente o razones por las que la mejor práctica es la mejor opción, así puedo convencerlo de eso ... porque parece más fácil que la ira dejar de fumar y / o encontrar un nuevo trabajo, al menos para el momento. En este momento, "las mejores prácticas de Microsoft" y el acceso interno al sitio web público de nuestra empresa no parecen estar reduciéndolo, y realmente , realmente , realmente espero que alguien aquí tenga algo más convincente.


1
Corrección menor: requeriría un registro A interno, no un registro SRV www.
MDMarra

@ HopelessN00b - Mark es perfecto con todo lo que hubiera dicho y más. Su escenario de "pareja" es la guinda del pastel. No he tenido el "placer" de encontrarme con ese escenario con DNS de horizonte dividido. Lo habría mencionado haciendo resoluciones de nombre en una succión de VPN, pero no pensé en DirectAccess en particular.) Si tuviera que pensar en algo, lo tiraré. Estoy horrorizado por el trabajo y el potencial de errores que crea. Eso solo es razón suficiente para justificar no hacerlo. Sobre todo, todavía me molestan las personas que dicen "las grandes compañías lo hacen así que está bien" como excusa.
Evan Anderson

Respuestas:


24

Tanta reputación para tener. Ven a mí preciosa.

De acuerdo, Microsoft ha documentado bastante bien que no debes usar un horizonte dividido o un TLD inventado como lo has vinculado muchas veces (¡grita en mi blog!). Hay algunas razones para esto.

  1. El wwwproblema que has señalado anteriormente. Molesto, pero no es un factor decisivo.

  2. Te obliga a mantener registros duplicados para todos los servidores públicos que también son accesibles internamente, no solo www. mail.hopelessnoob.comEs un ejemplo común. En un escenario ideal, tendría una red perimetral separada para cosas como mail.hopelessnoob.como publicwebservice.hopelessnoob.com. Con algunas configuraciones, como un ASA con interfaces internas y externas , de todos modos necesita un NAT interno o un DNS de horizonte dividido, pero para las organizaciones más grandes con una red perimetral legítima donde sus recursos orientados a la web no están detrás de un límite de NAT. Esto provoca trabajo innecesario.

  3. Imagina este escenario: eres hopelessnoob.cominterna y externamente. Tiene una corporación con la que se está asociando example.comy hace lo mismo: dividir el horizonte internamente con su AD y con su espacio de nombres DNS de acceso público. Ahora, configura una VPN de sitio a sitio y desea autenticación interna para que la confianza atraviese el túnel mientras tiene acceso a sus recursos públicos externos para salir a través de Internet. Es casi imposible sin un enrutamiento de políticas increíblemente complicado o tener su propia copia de su zona DNS interna: ahora acaba de crear un conjunto adicional de registros DNS para mantener. Entonces tienes que lidiar con la horquilla al final ysu fin, política de enrutamiento / NAT, y todo tipo de otros trucos. (En realidad estaba en esta situación con un AD que heredé).

  4. Si alguna vez implementa DirectAccess , simplifica drásticamente sus políticas de resolución de nombres; esto probablemente también sea cierto para otras tecnologías VPN de túnel dividido.

Algunos de estos son casos extremos, otros no, pero todos se evitan fácilmente . Si tiene la capacidad de hacer esto desde el principio, bien podría hacerlo de la manera correcta para que no se encuentre con uno de estos en una década.


1
Salsa impresionante. Creo que 3 y 4 podrían cerrar el trato ... pero lo dejaré abierto para ver si alguien tiene algo más. Y con suerte alentarás más preciosussssses a tu manera. Dos votos a favor para esa respuesta son bastante débiles ... vamos, gente. ¡Necesita votos positivos!
HopelessN00b

2
+1 - Me encanta Sigan con la pelea.
Evan Anderson

8

Esta afirmación: "Realmente, la única justificación que puedo encontrar es que acceder al sitio web externo desde el interno requiere un registro DNS SRV y escribir www. Delante del nombre del sitio web en un navegador" no es cierto.

Significa que necesita mantener una copia de todos sus registros públicos en sus servidores DNS de AD, lo que podría causar problemas, especialmente si no lo hace correctamente, omita algunos, etc. Si alguien quiere llegar a ftp.company. com pero se olvida de crear el alias en el DNS interno (o no lo automatizó correctamente), la gente interna no puede acceder al sitio FTP público en absoluto.

Esto está bastante bien desarrollado en la pregunta a la que se vinculó: ¿ Mejores prácticas de nomenclatura de Windows Active Directory?

Si mantener múltiples copias de sus zonas DNS es un problema fácil de resolver para siempre, entonces supongo que puede hacer lo que quiera. Hasta que la EM cambie algo que lo rompa. Usted podría simplemente seguir sus recomendaciones.


Buen punto. Por supuesto, no tenemos servicios públicos como ese, y subcontratamos nuestro alojamiento web, así que ... no estoy seguro de cuánto importará, pero puedo agregarlo a la lista. Gracias.
HopelessN00b

1
Tal como lo edité, la forma en que se usa la identidad pública de Internet de su empresa hoy en día podría no reflejar con precisión cómo se usará en 5 años.
mfinni

Sí, pruebas futuras ... otra buena. Ojalá pudiera darte otro +1. :)
HopelessN00b

5

No me importa lo suficiente el representante para crear una respuesta larga hoy ... así que lo mantendré breve.

Solía ​​estar bien con split-dns y lo implementé varias veces hasta que Evan y Mark me convencieron de lo contrario. Sinceramente, NO es que no se pueda hacer ... se puede, y algunos podrían estar bien con eso (a pesar de los gastos generales y el trabajo realizado para ello).

Hace 2 años surgieron 2 cosas específicas para mí que solidificaron NO usarlo:

  1. Como señaló en su pregunta, simplemente no puede permitir que los usuarios internos accedan a su sitio web externo solo con el nombre de dominio. No pregunte por qué eso fue tan importante, pero teníamos usuarios internos que se enfurecerían al escribir solo el nombre de dominio en un navegador sin wwwque aparezca el sitio web real, ya que el registro de dominio corresponde al dominio AD y no es un todo para llegar wwwy NO PUEDE SER internamente.
  2. Problemas de Exchange: Exchange AutoDiscover puede no obtener los certificados y generará un error. Esto puede suceder tanto interna como externamente. Esto se hizo aún más evidente cuando comenzamos a tener "Buzones de correo externos del bosque" en nuestra organización de Exchange y no veían el mismo DNS interno que nosotros.

Espero que ayude.


1
Je je ... Con el tiempo, @MDMarra y yo haremos que pienses igual que nosotros.
Evan Anderson

2
La resistencia es inútil ... ¡su AD se asimilará en un subdominio de su dominio principal!
Ward - Restablece a Monica

Como comentario aparte, he solucionado el problema de WWW instalando IIS en todos los DC y creando una página de redireccionamiento ASP a www. En realidad, esto funciona bastante bien, a pesar del uso algo frívolo de IIS.
cscracker
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.