Instalación de Active Directory – Promoviendo un Controlador de Dominio en un Site Remoto – Nota V

En esta nota, y como continuación de la infraestructura de Active Directory que estamos creando de acuerdo al diseño aceptado, procederemos a promover un Controlador de Dominio del Dominio Raíz (root.guillermod.com.ar) en un Site remoto (Mendoza)

Hay varios motivos por los cuales puede ser conveniente que en un Site que tendrá un “dominio propio” (mza.root.guillermod.com.ar) se instale un Controlador de Dominio de uno que corresponde a otro Site

Para poner como ejemplo sólo uno: que sea habitual que usarios que tienen cuenta en root.guillermod.com.ar incien sesión en máquinas del sitio remoto Mendoza, y además se desea que en caso de problemas con el enlace WAN los mismos puedan inciar sesión sin inconvenientes

Como recordatorio, incluiré nuevamente el diagrama propuesto en la nota inicial de la infraestructura a crear. En esta nota promoveremos a Controlador de Dominio a DC3, que es un Controlador de Dominio del Dominio Raíz (root.guillermod.com.ar) pero que estará físicamente en un Site remoto (Mendoza)

Lo primero que debemos hacer es confirmar la conectividad entre las subredes IP que hemos definido

La conexión entre las redes la podemos hacer de dos formas diferentes, una “más real”, y otra más práctica para un ambiente de pruebas como el que estamos desarrollando

La “más real” podríamos hacerla utilizando dos servidores y configurar una “VPN Sitio a Sitio”. Pueden ver un ejemplo de configuración con paso a paso en Windows Server 2012: Conectando Sitios por VPN (Site to Site VPN)

La “más práctica” la pueden ver en la nota publicada en este mismo sitio con el nombre “Configurando un Router (Enrutador) Para Ambiente de Pruebas – “El Router de un hombre pobre”

Por otro lado, como vamos a proceder a la promoción de un nuevo Controlador de Dominio debemos disponer de una nueva instalación de Windows Server 2012 (no clonar anteriores, o alternativamente ejecutar SYSPREP)

De acuerdo a lo planificado le he dado el nombre DC3, y he configurado adecuadamente IPv4

Para verificar que existe conectividad con uno de los Controladores de Dominio existentes, e inclusive que se pueden resolver los nombres, podemos probar con PING y NSLOOKUP

Como no hace falta, y a la vez ahorrar un reinicio, procederemos a configurarlo como Controlador de Dominio adicional en el Dominio existente sin necesidad de tenerlo unido previamente al Dominio, está en grupo de trabajo

Debemos instalar el Rol correspondiente, que no mostraré las capturas de pantalla porque ya lo hemos hecho muchas veces, es siempre igual, sólo mostraré desde el momento de la configuración como Controlador de Dominio

Nos aseguramos que esté marcada la opción “Add a domain controller to an existing domain”, y como la máquina está en grupo de trabajo, nos convendrá ingresar manualmente el nombre del Dominio sin usar el botón “Select”, e ingresar las credenciales correspondientes usando el botón “Change”

En la siguiente pantalla podremos observar que además de lo habitual (DNS y GC), automáticamente, gracias a que ya hemos creado los Sites, con la información de la configuración de TCP/IP se ha asignado al Site Correcto (Mendoza)
Sólo deberemos completar la contraseña DSRM

Vemos que podríamos seleccionar desde qué Controlador de Dominio se hace la replicación inicial

Trabajará unos minutos

Y reinciará automáticamente al finalizar el proceso

Cuando esté disponible podremos iniciar sesión con el administrador de Dominio, y deberíamos verificar que todo esté correctamente, pero espere… tenga un poco de paciencia, hasta que todo quede “como debe ser” suelen pasar hasta 30 minutos, así que es momento para un descanso

¿Ya volvió? bueno, continuamos entonces.Observemos si ya se han creado los Objetos Conexión entre los Controladores de Dominio

En DC1, voy a “Active Directory Sites and Services” y ya se puede observar que se ha creado el “Objeto Conexión” que replica desde DC3 hacia DC1 ¡Bien!

Si me quiero apurar y forzar una replicación en este momento, pueden que se encuentren con el siguiente cuadro, no preocuparse, esperar un poco

Si ahora en DC3 vamos a “Active Directory Sites and Services”, y dejamos pasar el tiempo suficiente (F5, F5, F5, …) ya veremos creado el Objeto Conexión, que en este caso es desde DC2 a DC3
Esto es porque DC2 ha asumido la función de “Bridgehead Server” para el Site Mendoza

Si tratamos de forzar una replicación, y no recibimos el mensaje mostrado anteriormente, nos encontraremos con otro

Es lo esperable, cuando dos Controladores de Dominio se encuentran en Sites diferentes, por omisión, la replicación se hace de acuerdo a la programación, y no se puede forzar.
En realidad es casi una mentira :-) Lo que no puede replicarse de esta forma es la replicación de la carpeta SYSVOL, la base de Active Directory (NTDS.DIT) se ha replicado

Entonces ahora ya llegó el momento de hacer algunas verificaciones adicionales para ver que todo esté funcionando correctamente

Lo primero que haré es ir a “Active Directory Users and Computers” en cualquiera de los Controladores de Dominio, y verificar que en la Unidad Organizativa Domain Controllers estén presentes las tres correspondientes máquinas

Además vamos a verificar que en DNS estén las registraciones correctas y necesarias, no sólo los registros A

Podemos ver que se han registrado en el Site Central los Controladores de Dominio de este Site

Y que DC3 se ha registrado para cubrir el Site Mendoza

En la configuración de TCP/IPv4 podemos observar que ha hecho el cambio habitual (127.0.0.1)

Podemos cambiarlo si deseamos

Es muy buena idea, además de lo hecho, revisar el “Event Viewer” por errores. Como vemos en este caso, son sólo las advertencias esperables

Dejamos hasta acá, en la próxima nota configuraremos el Controlador de Dominio de sólo lectura (RODC) para el Site Cordoba en la nota “Instalación de Active Directory – Promoción de un RODC (Read Only Domain Controller) – Nota VI

 

 

Anuncios
Post a comment or leave a trackback: Trackback URL.

Comentarios

  • David  On 18/06/2013 at 17:08

    Excelente muy bien explicado.

    Esperemos el siguiente tema

    Saludos

    • Delprato  On 19/06/2013 at 08:46

      Gracias David
      Ya está casi lista la nota IV promocionando el RODC, si no llego hoy ya la publicaré seguramente mañana

  • pavilion  On 24/06/2013 at 17:02

    Guillermo una duda, es necesario que el ITadmin de Mendoza, conozca la clave de administrador del DC3? de ser así tendría acceso completo al AD del dominio root no?
    Habría alguna forma de limitar que pudiera hacer cambios en el AD del root o evitar que haga remote desktop a DC1 y DC2?

    Agradecido por estas notas que despejan muchas dudas!!!!

    • Delprato  On 25/06/2013 at 08:53

      La pregunta está relacionada justamente con una de las dificultades de la infraestructura, y viene muy bien tu pregunta
      :-)

      DC3 es un Controlador de Dominio del Dominio raíz (Root), es parte de “root.guillermod.com.ar”. Lo único “extraño” es que este Controlador de Dominio está en un Sitio (Site) diferente, donde luego se creará un Dominio específico para el mismo.
      El motivo, como fue planteado en la primera nota, es para asegurarse que los usuarios del Dominio raíz puedan iniciar sesión en el sitio Mendoza, si el enlace estuviera caído. Otro motivo podría ser porque fuera habitual que usuarios del Dominio raíz estuvieran físicamente en el sitio Mendoza

      Y por lo tanto, como DC3 es un Controlador de Dominio, del Dominio raíz (root.guillermod.com.ar), es exactamente lo mismo que DC1 o DC2, solamente es que “esta lejos” :-)

      Cuando comencemos con la instalación de DC4, ese es otro tema, porque este sí es de un Dominio diferente

  • Carlos  On 30/10/2013 at 15:50

    Muchas gracias por este excelente artículo! La verdad ha sido de mucho apoyo para mi! Solamente tengo una consulta, al tener 3 DC para mi root domain, ¿cómo tendrían que quedar los “Forwarders” de cada DNS? ¿estos deben quedar solamente hacia un proveedor público o deben redirigirse entre ellos mismos? Gracias!

    • Guillermo Delprato  On 30/10/2013 at 18:12

      El tema es así, para poder resolver nombres de Internet por lo menos uno debe tener Reenviadores a los del proveedor de Internet

      Suponiendo que tengas DC1, DC2 y DC3, los tres con DNS
      Si DC1 y DC2 “forwardean” a DC3 y este a los del proveedor, tienes la ventaja que DC3 tendrá el “cache DNS” más completo, pero por otro lado tienes el inconveniente de poder sobrecargarlo
      Si cada DC sale al ISP, no sobrecargas, pero puedes generar un poco más de tráfico porque cada uno mantiene su propio “cache DNS”

      Funcionará de las dos formas

      • Carlos  On 30/10/2013 at 20:47

        ¡Muchas gracias! Solamente un detalle adicional. Actualmente tengo 2 sites distribuidos así: 2 DC en mi site “root”, 1 DC de mi “root” en el site remoto, y 1 DC para el child domain en el site remoto. Pregunto: ¿En los DC que están localmente en mi site “root”, debo configurar en los “forwarders” la IP del DC del child domain ubicado en mi sitio remoto? Gracias nuevamente

      • Guillermo Delprato  On 31/10/2013 at 06:52

        En lo que llamas “site root” que entiendo que en realidad es el “site central” (porque los que pueden ser “root” son los Dominios) en los DNSs en realidad debería haber una delegación al Dominio “child”, no “forwarders”

      • Carlos  On 31/10/2013 at 11:21

        ¡Correcto a eso me refería a mi site central! ¿Podrías explicarme un poco más sobre la delegación? Mi intención es garantizar correctamente la resolución de nombres desde mi dominio root hacia el child. gracias!

      • Guillermo Delprato  On 31/10/2013 at 11:55

        ¿Querés que escriba un curso de DNS en los comentarios de una nota? :D :D :D

        Revisa las 3 notas que ya están en el blog y que explican el funcionamiento de DNS

        Cómo funciona DNS – Parte 1 | WindowServer:
        https://windowserver.wordpress.com/2011/05/07/cmo-funciona-dns-parte-1-2/

        Cómo funciona DNS – Parte 2 | WindowServer:
        https://windowserver.wordpress.com/2011/05/26/cmo-funciona-dns-parte-2/

        Cómo Funciona DNS – Parte 3 – Integración con Active Directory | WindowServer:
        https://windowserver.wordpress.com/2011/06/24/cmo-funciona-dns-parte-3-integracin-con-active-directory/

      • Carlos  On 31/10/2013 at 12:27

        Jajaja, muchas gracias de verdad!

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: