none
Crear dos dominios en la misma red RRS feed

  • Pregunta

  • Buenos días,

    Por motivos empresariales, necesito crear un nuevo dominio en la red donde ya existe un dominio (llamémoslo dominio A):

    Dominio A: windows 2008 R2.

    Dominio B: el nuevo. Windows 2016 pero puede arrancar con nivel funcional 2008 R2 sin problemas.

    Comparten red, comparten DHCP, necesitan espacios de nombres diferentes y el único requisito y motivo de hacer esta operación es que para superar una certificación de seguridad imprescindible para el negocio, ciertos objetos del dominio A no pueden convivir con el resto.

    O sea que lo único que importa en realidad es que en el dominio B figuren sólo ciertos activos de la empresa, es decir, para el interés funcional u operacional no queremos ni necesitamos  aislar nada, pero por un tema estrictamente de negocio, éstos objetos concretos sí que deben aparecer únicamente en un solo controlador de dominio y por supuesto con espacios de nombres separados. 

    Para la migración de objetos usaré ADMT por supuesto, mis dudas son las siguientes:

    Para facilitar la migración ¿es mejor crear un bosque nuevo o un dominio nuevo dentro del existente? no habría inconveniente en crear relaciones de confianza, como decía lo único necesario es que en el dominio nuevo, bajo Usuarios y Equipos de AD solo figuren ciertos objetos concretos.

    ¿Es posible migrar sesiones de usuario? de forma que cuando los usuarios inicien sesión en el dominio B conserven todo lo que tenían en sus sesiones del dominio A. 

    ¿Qué inconvenientes hay a tener en cuenta?

    Gracias por la ayuda de antemano.

    viernes, 21 de junio de 2019 6:28

Respuestas

  • Hola, 

    Me respondo a mí mismo para completar un poco el tema ahora que terminó la migración. Todo ha salido satisfactoriamente, dejo lo que he hecho por si a alguien en un futuro le puede servir:

    Escenario inicial: controlador de dominio con objetos de dos empresas.

    Objetivo: separar solo algunos objetos en un dominio nuevo. Las peticiones DNS deben poder resolverse tanto si se pregunta por un objeto que se migró tanto si se pregunta por su nombre antiguo como por el nuevo.

    Solución: Empiezo con un disclaimer, aunque pongo "solución" probablemente pueda no verse como tal dado lo artesano y poco automatizado de la misma, no obstante a mí no me quedaba más remedio y las acciones que he llevado a cabo siguiendo además los consejos aquí recibidos están dando el funcionamiento esperado.

    Ahora sí. Lo que hice fue crear un controlador de dominio nuevo, en un bosque nuevo, sin relaciones de confianza, sin servidor DHCP aparte, y esto último debido a que son tan pocos los objetos que se migran y son además todos servidores con IP fija que en realidad no lo necesitaba. No obstante, como el nuevo dominio está en su propia subred, podría haber usado funcionalidad DHCP de la interfaz a la que se conecta este nuevo DC en el firewall para que diese servicio DHCP. 

    Respecto del DNS que era la parte mas farragosa lo que he hecho es configurar Conditional Forwarders en el dominio A y dominio B que apuntan cada uno al otro dominio, así cuando alguien pregunte por un objeto del dominio B al DC del dominio A, este redirigirá la petición al DC correcto y viceversa. Adicionalmente, es necesario que la configuración DNS de cada tarjeta de red en los servidores añada los sufijos DNS de ambos dominios siendo la de su propio dominio siempre la primera (IPv4-Properties-Advanced-DNSTag-Sufixes...).

    Respecto de las políticas de dominio, lo que hice fue crear (sin configurar, solo crear con el mismo nombre) las GPOs que existían en el dominio A, a mano, en el dominio B, luego sacar un backup de cada GPO en el dominio A y finalmente hacer un Import settings en dicha política en el dominio B. Puede ocurrir (como por ejemplo en la Default Domain Policy) que algunas configuraciones de la GPO afecten a Paths o UNC propios del dominio, en cuyo caso hay que crear una Migration Table usando la opción Populate para que se recoja en una tabla los campos "sensibles" que no podrán migrarse de una GPO a otra porque se utilicen SID de cuentas o similar. En cualquier caso, no queda más remedio que repasar cada GPO para confirmar que todo está correcto.

    Muy importante: ANTES de migrar cada equipo, hay que asegurarse que se conocen passwords de administrador local de la máquina. 
    Cada migración de un equipo requiere dos reinicios: el primero para pasarlo a grupo de trabajo, el segundo para agregarlo al nuevo dominio. No sé si se puede hacer el cambio directo pero la verdad que ni lo he intentado, son servidores críticos y preferí ir sobre seguro.

    Se da el caso que en realidad no tenía un DC (aunque para mi consulta inicial no lo creí relevante y no lo mencioné por no marear la perdiz), si no dos, en dos emplazamientos físicos distintos. Esta topología estaba reflejada en Active Directory Sites an Services, donde he tenido que replicar a mano los sites y subnets que había. Es muy sencillo, sólo se tiene que abrir ese módulo del AD e ir recorriendo la configuración y preparándola igual en el dominio destino: crear la subred de cada emplazamiento, asignarla a cada DC correcto, conectar los DCs, y listo. 

    Otra cosa a tener en cuenta es el tráfico entre firewalls: permitir tráfico DNS, RDP y LDAP (al menos) entre zonas.

    Sobre WSUS . WSUS permite actualizar equipos de otros dominios (o tal vez debería decir que NO es Domain-Sensitive), por lo que si se permite el tráfico por el puerto 8530 entre redes(o el que se tenga configurado), no tiene porqué haber problema en mantenerlo centralizado si así se quiere, no obstante con el volumen de tráfico que genera yo aconsejo tener un WSUS en cada sede física.

    TIP: cuando los servidores entraban al dominio nuevo, sólo podía entrar por consola, esto es debido a que en mi escenario las políticas locales de cada servidor fijaban usuarios concretos para acceder por RDP. Esto se corrige ejecutando secpol.msc y en LocalPolicies->User Rights Assignment -> Allow Log on Through RDP se añade los usuarios/grupos correctos. Aprendí también que la palabra LSDOU es muy útil para saber qué políticas prevalecen si entran en conflicto a distintos niveles de aplicación (este orden refleja qué  nivel tiene más "fuerza", siempre que la GPO no tenga seleccionada la opción ENFORCE): Local, Site, Domain, Organizational Unit. 

    Y creo que no me dejo nada, gracias por los consejos pues fueron muy útiles y espero que a alguien le sirva esta información. 

    miércoles, 17 de julio de 2019 9:01

Todas las respuestas

  • Hola,

    Respondiendo  a tus preguntas, si tienes que crear un nuevo dominio, Dominio B y no tienes requisitos porque no crear un dominio hijo?

    Sería simplemente un bosque y sería mas facil administrativamente.

    Y respecto a la pregunta de migrar sesiones de usuario, si van a convivir los dos dominio, no te recomiendo que migres a los usuarios, puesto que con eso sólo conseguirás que el usuario esté presente en un solo dominio y no podrá acceder al antiguo.

    Creo que debes pensar bien que quieres hacer.


    MCSE Formador y Consultor Microsoft.

    viernes, 21 de junio de 2019 11:06
  • [Guillermo] Respondo entre líneas

    Buenos días,

    Por motivos empresariales, necesito crear un nuevo dominio en la red donde ya existe un dominio (llamémoslo dominio A):

    Dominio A: windows 2008 R2.

    Dominio B: el nuevo. Windows 2016 pero puede arrancar con nivel funcional 2008 R2 sin problemas.
    [Guillermo] No tiene mucho sentido tener como Controlador de Dominio una versión más nueva, y usar funcionalidad menor

    Comparten red, comparten DHCP, necesitan espacios de nombres diferentes y el único requisito y motivo de hacer esta operación es que para superar una certificación de seguridad imprescindible para el negocio, ciertos objetos del dominio A no pueden convivir con el resto.
    [Guillermo] Acá si tienes un problema, El DHCP asigna no sólo direcciones IP, sino también Puerta de Enlace y servidor DNS. Si hay Dominios diferentes, no pueden usar las máquinas cliente el mismo DNS, cada uno debe apuntar a su Controlador de Dominio

    O sea que lo único que importa en realidad es que en el dominio B figuren sólo ciertos activos de la empresa, es decir, para el interés funcional u operacional no queremos ni necesitamos  aislar nada, pero por un tema estrictamente de negocio, éstos objetos concretos sí que deben aparecer únicamente en un solo controlador de dominio y por supuesto con espacios de nombres separados.
    [Guillermo] Esto es sencillo, cada Dominio tiene sus propios usuarios, máquinas y grupos

    Para la migración de objetos usaré ADMT por supuesto, mis dudas son las siguientes:
    [Guillermo] Esto no te conviene a mi entender, además de cuidar que no se migre el "SID History, puede generar confusión en los usuarios, y obliga a tener relaciones de confianza entre los Dominios, con lo cual un usuario de un Dominio podría iniciar su sesión en cualquiera de las máquinas sea de su Dominio o no, y hay compartidos con permisos a "Authenticated Users" o "Everyone" acceder a recursos del otro. Creo que sería mucho más sencillo asignar al nuevo Dominio el que contenga la menor cantidad de usuarios y máquinas

    Para facilitar la migración ¿es mejor crear un bosque nuevo o un dominio nuevo dentro del existente? no habría inconveniente en crear relaciones de confianza, como decía lo único necesario es que en el dominio nuevo, bajo Usuarios y Equipos de AD solo figuren ciertos objetos concretos.
    [Guillermo] Si están dentro del mismo Bosque tienes administración centralizada, ya que comparten grupos ("Enterprise Admins" y "Schema Admins") pero por otra parte tienes el tema del acceso a compartidos que puse más arriba

    ¿Es posible migrar sesiones de usuario? de forma que cuando los usuarios inicien sesión en el dominio B conserven todo lo que tenían en sus sesiones del dominio A. 
    [Guillermo] Como poder se puede, pero creo que sería mucho mejor que crees nuevos usuarios y les migres los datos, aunque todo dependerá de la cantidad de usuarios

    ¿Qué inconvenientes hay a tener en cuenta?
    [Guillermo] Eso sólo lo puedes determinar tu, habría que conocer toda la infraestructura y el uso :)

    Gracias por la ayuda de antemano.



    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    viernes, 21 de junio de 2019 11:28
    Moderador
  • Buenas Guillermo,

    De nuevo muchas gracias por tu rápida respuesta y la información de cada punto. Le daré una pensada teniendo en cuenta todo lo que me indicas, os mantendré informados.

    un saludo!

    israel.. 

    viernes, 21 de junio de 2019 12:57
  • Hola, 

    Me respondo a mí mismo para completar un poco el tema ahora que terminó la migración. Todo ha salido satisfactoriamente, dejo lo que he hecho por si a alguien en un futuro le puede servir:

    Escenario inicial: controlador de dominio con objetos de dos empresas.

    Objetivo: separar solo algunos objetos en un dominio nuevo. Las peticiones DNS deben poder resolverse tanto si se pregunta por un objeto que se migró tanto si se pregunta por su nombre antiguo como por el nuevo.

    Solución: Empiezo con un disclaimer, aunque pongo "solución" probablemente pueda no verse como tal dado lo artesano y poco automatizado de la misma, no obstante a mí no me quedaba más remedio y las acciones que he llevado a cabo siguiendo además los consejos aquí recibidos están dando el funcionamiento esperado.

    Ahora sí. Lo que hice fue crear un controlador de dominio nuevo, en un bosque nuevo, sin relaciones de confianza, sin servidor DHCP aparte, y esto último debido a que son tan pocos los objetos que se migran y son además todos servidores con IP fija que en realidad no lo necesitaba. No obstante, como el nuevo dominio está en su propia subred, podría haber usado funcionalidad DHCP de la interfaz a la que se conecta este nuevo DC en el firewall para que diese servicio DHCP. 

    Respecto del DNS que era la parte mas farragosa lo que he hecho es configurar Conditional Forwarders en el dominio A y dominio B que apuntan cada uno al otro dominio, así cuando alguien pregunte por un objeto del dominio B al DC del dominio A, este redirigirá la petición al DC correcto y viceversa. Adicionalmente, es necesario que la configuración DNS de cada tarjeta de red en los servidores añada los sufijos DNS de ambos dominios siendo la de su propio dominio siempre la primera (IPv4-Properties-Advanced-DNSTag-Sufixes...).

    Respecto de las políticas de dominio, lo que hice fue crear (sin configurar, solo crear con el mismo nombre) las GPOs que existían en el dominio A, a mano, en el dominio B, luego sacar un backup de cada GPO en el dominio A y finalmente hacer un Import settings en dicha política en el dominio B. Puede ocurrir (como por ejemplo en la Default Domain Policy) que algunas configuraciones de la GPO afecten a Paths o UNC propios del dominio, en cuyo caso hay que crear una Migration Table usando la opción Populate para que se recoja en una tabla los campos "sensibles" que no podrán migrarse de una GPO a otra porque se utilicen SID de cuentas o similar. En cualquier caso, no queda más remedio que repasar cada GPO para confirmar que todo está correcto.

    Muy importante: ANTES de migrar cada equipo, hay que asegurarse que se conocen passwords de administrador local de la máquina. 
    Cada migración de un equipo requiere dos reinicios: el primero para pasarlo a grupo de trabajo, el segundo para agregarlo al nuevo dominio. No sé si se puede hacer el cambio directo pero la verdad que ni lo he intentado, son servidores críticos y preferí ir sobre seguro.

    Se da el caso que en realidad no tenía un DC (aunque para mi consulta inicial no lo creí relevante y no lo mencioné por no marear la perdiz), si no dos, en dos emplazamientos físicos distintos. Esta topología estaba reflejada en Active Directory Sites an Services, donde he tenido que replicar a mano los sites y subnets que había. Es muy sencillo, sólo se tiene que abrir ese módulo del AD e ir recorriendo la configuración y preparándola igual en el dominio destino: crear la subred de cada emplazamiento, asignarla a cada DC correcto, conectar los DCs, y listo. 

    Otra cosa a tener en cuenta es el tráfico entre firewalls: permitir tráfico DNS, RDP y LDAP (al menos) entre zonas.

    Sobre WSUS . WSUS permite actualizar equipos de otros dominios (o tal vez debería decir que NO es Domain-Sensitive), por lo que si se permite el tráfico por el puerto 8530 entre redes(o el que se tenga configurado), no tiene porqué haber problema en mantenerlo centralizado si así se quiere, no obstante con el volumen de tráfico que genera yo aconsejo tener un WSUS en cada sede física.

    TIP: cuando los servidores entraban al dominio nuevo, sólo podía entrar por consola, esto es debido a que en mi escenario las políticas locales de cada servidor fijaban usuarios concretos para acceder por RDP. Esto se corrige ejecutando secpol.msc y en LocalPolicies->User Rights Assignment -> Allow Log on Through RDP se añade los usuarios/grupos correctos. Aprendí también que la palabra LSDOU es muy útil para saber qué políticas prevalecen si entran en conflicto a distintos niveles de aplicación (este orden refleja qué  nivel tiene más "fuerza", siempre que la GPO no tenga seleccionada la opción ENFORCE): Local, Site, Domain, Organizational Unit. 

    Y creo que no me dejo nada, gracias por los consejos pues fueron muy útiles y espero que a alguien le sirva esta información. 

    miércoles, 17 de julio de 2019 9:01
  • Hola, muchas gracias por haberte tomado el trabajo de describir cada una de las configuraciones que has hecho, todo muy detallado

    Ahora sí, prepárate porque te van a comenzar a preguntar a ti cómo has hecho determinados pasos :D

    ¡Gracias nuevamente!

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    miércoles, 17 de julio de 2019 10:30
    Moderador
  • jajajaja, gracias a tí por tus consejos Guillermo, me pusieron en el camino!

    Si puedo ayudar, a otros encantado lo haré. El conocimiento crece cuanto más se comparte jeje.

    un saludo!

    miércoles, 17 de julio de 2019 11:28