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.
- Replicación de servicios de dominio de Active Directory
- Proceso DC Locator de Clientes / Servidores Miembros
- 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.
- 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
- 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. :)