Asesoramiento sobre el diseño de Active Directory para servidores multihomed

Un cliente me ha encargado que presente un diseño de Active Directory que funcione para un escenario con los siguientes requisitos (simplificado, en realidad son mucho peores):

• Hay una subred para sistemas cliente.
• Hay una subred para sistemas de servidor.
• Las dos redes no están conectadas.
• Cada servidor debe tener dos tarjetas de red, una en la red de los servidores y la otra en la red de los clientes.
• El tráfico entre clientes y servidores solo debe fluir en la red de los clientes.
• El tráfico entre servidores solo debe fluir en la red de servidores.
• Esto también debería aplicarse a los controladores de dominio.

No hace falta decir que esto no va muy bien con la forma en que Active Directory usa DNS para localizar controladores de dominio; cualquier enfoque posible llevaría a uno de los siguientes escenarios:

• Los DC registran su dirección IP "del lado del cliente" en el dominio DNS; los clientes hablarán con ellos usando esa dirección, pero también lo harán los servidores y el tráfico de replicación de AD.
• Los DC registran su dirección IP "del lado del servidor" en el dominio DNS; los servidores hablarán con ellos usando esa dirección y el tráfico de replicación fluirá en esa red, pero los clientes no podrán comunicarse con ellos.
• Los DC registrarán ambas direcciones IP en el dominio DNS; nadie sabe qué hará cualquier sistema para llegar a ellos.

Por supuesto, estos requisitos son completamente locos y no se pueden cumplir todos al mismo tiempo, a menos que se utilicen soluciones locas como dividir el servicio DNS en las dos redes y llenar sus registros SRV a mano (argh) o hacer que los servidores ubiquen Los DC que usan DNS y los clientes localizan los DC que usan WINS (doble-argh).

La solución que se me ocurrió es tener dos DC en la red de "servidores" y dos DC en la de "clientes", definiendo dos sitios de AD y cruzando el límite entre las dos redes solo con tráfico de replicación de DC. Esto todavía requerir alguna mutilación de DNS, ya que cada servidor todavía tiene dos tarjetas de red (aparte de los dos controladores de dominio del servidor y puramente servidores back-end), pero tiene al menos algunas posibilidades de trabajo.

¿Algún consejo, aparte de huir lo más rápido posible?

Permítanme comenzar diciendo que estoy de acuerdo con muchos de los demás: convencer al cliente de lo contrario o ejecutar.

Sin embargo, dados los requisitos enumerados (hay muchos no listados), puedo pensar (y parcialmente probado) al menos el trabajo preliminar para que esto suceda.

Hay varios aspectos específicos que deben considerarse.

1. Replicación de servicios de dominio de Active Directory
2. Proceso DC Locator de Clientes / Servidores Miembros
3. Resolución de nombres y tráfico para servicios que no son de AD DS

Uno y dos tienen mucho en común: en general, estamos al capricho de Microsoft en este caso y tenemos que trabajar dentro de los límites de los procesos AD DS de Microsoft.

Número tres, tenemos un poco de espacio para trabajar. Podemos elegir las etiquetas utilizadas para acceder a los servicios (archivos, instancias de bases de datos, etc.).

Esto es lo que propongo:

Cree sus controladores de dominio (DC)

• Probable al menos dos.
• Cada DC tendrá dos NIC, uno en cada sitio de red IP / AD DS, llamándolos clt y srv por ahora.
• Solo configure una NIC en cada DC en este momento en la red srv.

Configure los sitios y servicios de AD correctamente

• sitio srv y subred
• sitio clt y subred
• desmarque "Puentear todos los enlaces del sitio" desde Sitios -> Transportes entre sitios -> Haga clic con el botón derecho en "IP"
• elimine el DEFAULTIPSITELINK si existe (o si le cambió el nombre) para que no haya enlaces de sitios configurados. Tenga en cuenta que esto es algo desconocido para mí: es probable que KCC descargue errores en el registro de eventos del servicio de directorio indicando que los dos sitios (srv y clt) no están conectados a intervalos variables. Sin embargo, la replicación continuará entre los dos DC ya que pueden contactar entre sí utilizando las IP en el mismo sitio.

Configurar zona adicional en AD DS DNS integrado

• Si su dominio de AD DS es acme.local , cree una segunda zona integrada de AD principal con actualizaciones dinámicas habilitadas llamada clt.acme.local .

Configure las segundas NIC en sus DC

• Estas NIC serán las NIC en la red / sitio clt.
• Establecer sus IP
• Aquí está la parte mágica - Propiedades del adaptador -> Propiedades de IPv4 -> Avanzado -> Pestaña DNS -> Establecer el sufijo DNS para esta conexión en clt.acme.local -> marcar Registrar esta conexión ... -> Verificar Usar esta conexión Sufijo DNS ... -> OK hasta el final.
• ipconfig / registerdns
• Esto registrará la IP de clt NIC en la zona clt.acme.local, lo que nos proporciona un método para controlar qué IP / red se usa más adelante.

Configurar NIC de servidor miembro

• Las NIC del servidor miembro en el sitio clt deben tener su sufijo DNS y casillas de verificación configuradas en consecuencia, como se indicó anteriormente.
• Estas configuraciones se pueden usar con estático y DHCP, no importa.

Configurar el comportamiento de resolución DNS [stub] en los sitios

• DC's -> Configure DC srv NIC para que se use a sí mismo y a otras DC srv NIC IP. Deje DC clt NIC DNS vacío (aunque se necesita una IP estática). (El servidor DC DNS seguirá escuchando en todas las IP de forma predeterminada).
• Servidores miembros -> Configure la NIC srv del servidor miembro para usar las direcciones IP del sitio srv de DC. Deje el servidor miembro clt NIC DNS vacío (se puede usar IP estática).
• Clientes / Estaciones de trabajo -> Configure DNS (ya sea a través de DHCP o estático) para usar las clt NIC IP de DC.

Configure asignaciones / recursos adecuadamente

• Cuando los servidores se comuniquen entre sí, asegúrese de usar .acme.local -> resolverá la IP de la red srv.
• Cuando los clientes hablen con los servidores, asegúrese de usar .clt.acme.local -> resolverá clt IP de red.

De que estoy hablando

• La replicación de AD DS seguirá ocurriendo ya que los DC pueden resolverse entre sí y conectarse entre sí. La zona acme.local y _msdcs.acme.local solo contendrá la replicación AD DS de DC srv NIC IP solo ocurrirá en la red srv.
• El proceso del localizador de DC para servidores miembros y estaciones de trabajo funcionará, aunque existe la posibilidad de retrasos en varias partes de varios procesos de AD DS cuando se desconoce el sitio, si se devuelven múltiples IP de DC, se probarán, fallarán y continuarán hasta que uno funcione. Los efectos sobre DFS-N tampoco se han evaluado por completo, pero seguirán funcionando.
• Los servicios que no son de AD DS funcionarán bien si usa las etiquetas .acme.local y .clt.acme.local mencionadas anteriormente como se describe.

No he probado completamente esto, ya que es bastante ridículo. Sin embargo, el punto de esta respuesta (wow, larga) es comenzar a evaluar si es posible o no, no si debe hacerse.

@Comentarios

@Massimo 1/2 No confunda varios sitios de AD DS en la zona acme.local y, por lo tanto, los registros SRV poblados por DC en esos sitios en la zona acme.local necesitan registros SRV en la zona clt.acme.local. El sufijo DNS primario del cliente (y el dominio de Windows al que están unidos) seguirá siendo acme.local. Las estaciones cliente / trabajo solo tienen una NIC única, con el sufijo DNS primario probablemente derivado de DHCP, establecido en acme.local.

La zona clt.acme.local no necesita registros SRV, ya que no se utilizará en el proceso del localizador DC. Solo lo usan los clientes / estaciones de trabajo para conectarse a los servicios que no son de AD DS del servidor miembro utilizando las IP del servidor miembro en la red clt. Los procesos relacionados con AD DS (DC locator) no usarán la zona clt.acme.local, sino los sitios (y subredes) de AD DS en la zona acme.local.

@Massimo 3

Habrá registros SRV para los sitios clt y srv AD DS, solo para que existan en la zona acme.local, vea la nota anterior. La zona clt.acme.local no necesita registros SRV relacionados con DC.

Los clientes podrán localizar una multa DC. Los servidores DNS del cliente apuntan a las IP clt de los DC.

Cuando se inicia el proceso del localizador DC en el cliente

• Si el cliente conoce su sitio, la pregunta de DNS será _ldap._tcp. [Sitio] ._ sites.dc._msdcs.acme.local SRV. Esto devolverá los DC específicos del sitio que tienen registros SRV registrados.
• Si el cliente no conoce su sitio, la pregunta de DNS será _ldap._tcp.dc._msdcs.acme.local SRV. Esto devolverá todos los DC. El cliente intentará unirse al LDAP de DC hasta que encuentre uno que responda. Cuando el cliente encuentra uno, realiza una búsqueda en el sitio para determinar el sitio del cliente y almacena en caché el sitio en el registro para que las futuras instancias del localizador DC ocurran más rápido.

@Massimo 4

Ugh, buena captura. A mi modo de ver, hay dos formas de solucionar este problema.

1. El menor impacto (en comparación con los 2 a continuación) es crear una entrada en el archivo hosts en los clientes / estaciones de trabajo para dc1.acme.local y dc2.acme.local apuntando a las IP de NIC de clt de los DC.

o

2. Cree manualmente los registros SRV necesarios en el archivo netlogon.dns en cada uno de los DC. Esto probablemente tendrá algunas consecuencias en la red del servidor. Los servidores miembros a veces pueden comunicarse con los DC en la red clt si esto está configurado.

En general, nada de eso es bonito, pero ese no es necesariamente el objetivo final. Tal vez el cliente solo está probando tus habilidades técnicas. Póngalo en su mesa de conferencias y dígales "Aquí, esto funcionará, pero le cobro 4 veces mi tarifa normal para configurarlo y admitirlo. Puede reducirlo a 1,5 veces mi tarifa normal - .5 veces la carga PITA, haciendo [solución correcta] ".

Como se señaló anteriormente, mi recomendación es convencer de lo contrario o correr. Pero seguro que es un pequeño ejercicio divertido en ridículo. :)

Al final fui con la solución de dos sitios:

• Dos DC para la red de "servidores", dos DC para la red de "clientes".
• Dos sitios de AD, uno para las redes de "servidores" y otro para "clientes".
• Los DC en la red de "servidores" solo tendrán una NIC en ese (los clientes no van a hablar con ellos en absoluto), por lo que esto es fácil.
• Los DC en la zona de "clientes" tendrán dos, pero solo registrarán en el DNS a sus clientes.
• Los servidores hablarán con sus DC, los clientes hablarán con los suyos.

Por supuesto, esto significa habilitar el tráfico de replicación entre las dos redes; los DC en la red de "clientes" seguirán teniendo una NIC en la red de "servidores", pero como no se registrará en el DNS, los DC en esa red se comunicarán con ellos utilizando sus direcciones IP del lado del cliente; para que la NIC sea completamente inútil, y algunos puertos de firewall deberán abrirse. La única otra opción sería destruir los hostsarchivos de los DC , pero esperemos que eso se pueda evitar.

Bueno, creo que esto es lo mejor que se podría hacer para cumplir tantos requisitos (locos) como sea posible.

Gracias por todos los consejos :-)

En primer lugar, cuando brindamos servicio a nuestros clientes, debemos preguntarnos cuáles son sus requisitos. Permitir al cliente comprender que su nivel de complejidad es innecesario.

• ¿Cuál fue el número de clientes?
• Esto es todo el tráfico interno?
• ¿Cuál es el nivel funcional de los dominios?
• ¿Se está utilizando el protcol TLS?

Usar el método KISS: crearía dos VLAN "SVR" y "CLT" que permitan SSL / TLS y lo llamen Día ...