Active Directory Replication – A fondo – Parte 2

Continuando con la nota anterior, en esta veremos y analizaremos las variables internas que usa la replicación de Active Directory, para detectar y replicar cambios, como así también la forma de evitar replicaciones redundantes.

El uso que hace Active Directory de que cualquier Controlador de Dominio acepte cambios, y que en teoría cualquiera pueda replicar desde cualquier otro Controlador de Dominio, implica un problema complejo de resolver, ya que los objetivos son: que los cambios se repliquen y la información de todos sea consistente lo antes posible, pero controlando el tráfico de red, y optimizando todo lo posible el tráfico de red y sobre todo en enlaces WAN

Específicamente hablaremos de: USN = Update Sequence Number, HWMV = High Watermark Vector, UTDV = Up-To-Dateness Vector, GUIDs, InvocationIDs, y todos los que sean necesarios para comprender el funcionamiento interno

Vamos al tema. Cada Controlador de Dominio es identificado unívocamente por un GUID (Global Unique IDentifier) que fue asignado durante la creación y que no cambiará durante toda su vida. Este identificador nunca es repetido, ni re-utilizado.

Los que venimos de “vieja época” estamos acostumbrados a los SIDs (Security IDentifiers) y antes decíamos que esa asignación “nunca podía cambiar”, pero actualmente eso no es correcto.
Como actualmente podemos mover cuentas entre diferentes Dominios, y el SID de una cuenta de Dominio contiene al SID del Dominio, es fácil darse cuenta que si muevo una cuenta a otro Dominio obligatoriamente debe cambiar su SID
Y por eso, actualmente el identificador único y permanente es el GUID.

Además, todos los Controladores de Dominio tienen un contador interno y propio que le sirve para identificar cuán actualizados están.
Se denomina USN = Update Sequence Number y es un número de 64 bit

Este USN, reitero, independiente en cada Controlador de Dominio, se incrementa en uno (1) por cada cambio que acepta.
En ningún caso disminuye, ni se reutiliza, salvo restaurando desde una copia de seguridad.

Un cambio en AD generalmente es la creación, actualización o eliminación de un objeto, o inclusive de un atributo de un objeto

Además debemos tener en cuenta que si una transacción fallara, el sistema la deshace por completo, pero no reutiliza el USN

Cuando un objeto es creado o modificado, el atributo usnChanged de dicho objeto incluye el USN de la transacción producida

De esta forma, uno puede saber los cambios que se han producido en Controlador de Dominio, observando el USN del mismo.

O mejor todavía. puedo hacer que el Controlador de Dominio busque todos los objetos cuyo atributo usnChanged es mayor que la última vez que pregunté. Y por lo tanto puedo saber qué cambios necesito que me transfiera.

Para desarrollar un ejemplo práctico, pero teórico, supongamos tener un Dominio con tres Controladores de Dominio. Los llamaré DC-A, DC-B y DC-C para identificarlos.

Partamos además que la información inicialmente es la misma en todos los Controladores de Dominio
Usaré además USNs totalmente ficticios pero fáciles de recordar

Comencemos por algo simple, en DC-A el administrador crea tres grupos

Operación USN en DC-A USN en DC-B USN en DC-C
USNs inciales 1000 2000 3000
Creación de 3 grupos 1003 2000 3000
Replicación de DC-A a DC-B 1003 2003 3000
Replicación de DC-A a DC-C 1003 2003 3003

Observamos que ahora los tres Controladores de Dominio tienen la misma información (convergencia)

En DC-A (donde se crearon los grupos) este cambio es considerado un “Originating Write”, en cambio desde DC-B y DC-C que recibieron el cambio, estos son considerados “Replicated Write”

Ahora supongamos que un administrador, conectado a DC-B, actualiza un atributo de uno de los grupos (cualquiera de cualquiera)

Vemos nuevamente la tabla anterior pero actualizada

Operación USN en DC-A USN en DC-B USN en DC-C
USNs inciales 1003 2003 3003
Modificación de grupo en DC-B 1003 2004 3003
Replicación de DC-B a DC-A 1004 2004 3003
Replicación de DC-B a DC-C 1004 2004 3004

En este último caso el “Originating Write” es DC-B, y estos cambios son “Replicated Write” en DC-A y DC-C

Ahora vamos a ver cómo es en realidad el tema, cómo se complica y cómo se resuelve.

Hasta ahora hemos planteado la replicación desde un Controlador de Dominio hacia los otros dos, pero debemos tener en cuenta que como cada uno crea dos conexiones entrantes para replicar (ver Parte 1), también existe replicación entre DC-B y DC-C

Por ejemplo, qué sucede cuando DC-B consulta el USN de DC-C, observa que se ha incrementado, y por lo tanto solicita la transferencia del último cambio, que en realidad ya sabemos que lo recibió desde DC-A
Sería una replicación que en realidad no actualizaría nada de datos, pero sí provocaría una actualización del USN de DC-B, que luego sería detectado por DC-A y … quedaríamos en un “loop infinito”.

Esto hay que resolverlo, así que profundicemos un poco más y veamos cómo se hace.

En realidad, el sistema utiliza dos GUIDs en cada Controlador de Dominio. Uno es el nombrado al principio de la nota, y que en realidad es conocido como “DSA GUID” (DSA = Directory Service Agent), es almacenado en el atributo “objectGUID” que podemos observar en Active Directory Sites and Services en las propiedades / Atributos de NTDS Settings del servidor
Este GUID es generado durante la promoción a Controlador de Dominio (DCPROMO), y no cambia

Pero además utiliza otro GUID que lo identifica durante el proceso de replicación, conocido como “Invocation ID”, y como ya veremos puede cambiar bajo determinadas circunstancias

Lo podemos ver en la misma pantalla que el anterior

Un ejemplo de caso de cambio del “Invocation ID”: cuando se hacer una restauración (Restore) de un Controlador de Dominio, o del System State (Estado del Sistema), el “Invocation ID” se vuelve a cero, y de esta forma se asegura que reciba todos los cambios que se han producido desde que se hizo la copia de Seguridad (Backup) y la restauración (Restore)

Al volver a cero el sistema se asegura que recibirá todos los cambios, casi como si fuera un nuevo Controlador de Dominio, y por esto mismo vemos por qué no hay que congelar estados (Snapshots), o recuperar imágenes de Controladores de Dominio

Vamos a ver ahora cómo se hace para que no se repliquen los cambios que ya ha recibido un Controlador de Dominio desde otro

Se utilizan dos vectores: HWMV = Hight-Watermark Vector y UTDV = Up-To-Dateness Vector

El HWMV es mantenido independientemente por cada Controlador de Dominio, para controlar cuál fue la última replicación (en USN) de cada uno de los otros Controladores de Dominio

El UTDV es utilizado por los Controladores de Dominio para no replicar innecesariamente datos ya recibidos

Cuando DC-A le envía a DC-B un pedido de cambios, este incluye su UTDV, entonces DC-B envía sólo los cambios que DC-A no ha recibido

La siguiente tabla muestra el HWMV de DC-A luego de los cambios producidos, en la primera tabla

HWMV en DC-A
Naming Context Domain Controller ID

Last USN

Domain NC DC-B Invocation ID

2003

Domain NC DC-C Invocation ID

3003

La siguente tabla muestra el HWMV en DC-B luego de la misma operación

HWMV en DC-B
Naming Context Domain Controller ID

Last USN

Domain NC DC-A Invocation ID

1003

Domain NC DC-C Invocation ID

3003

El vector UTDV almacena el más alto “Originating Update USN” que el Controlador de Dominio ha recibido de cada Controlador de Dominio replicando un determinado NC.
Guardando esta información, los Controladores de Dominio nunca enviarán los cambios que ellos ya han recibido por otra replicación.
Este comportamiento es conocido como “propagation dampening”

Usando el UTDV el Controlador de Dominio que envía la información puede determinar los cambios que no ha enviado al Controlador de Dominio que solicita la actualización, y además no enviar los cambios que este Controlador de Dominio ha recibido de otros Controladores de Dominio.
Esto evita el problema del “loop infinito”

Resumiendo el proceso, cada Controlador de Dominio mantiene en forma independiente un contador siempre creciente llamado USN, que es incrementado cada vez que el Controlador de Dominio ejecuta un “Originating Write”

Cuando los Controladores de Dominio replican, preguntan por todos los cambios sucedidos desde el último USN recibido desde dicho Controlador de Dominio. Este anterior USN está almacenado en el HWMV

Dentro de cada pedido de replicación está incluido su UTDV. Cada Controlador de Dominio mantiene un UTDV por cada NC replicado, y en el UTDV el Controlador de Dominio controla el más alto “Originating Update USN” del cual ha recibido cambios por cada Controlador de Dominio que replica dicho NC

Vemos un ejemplo simple, que estimo puede facilitar la comprensión. Los pasos serán:

  1. Crear una cuenta de usuario en DC-A
  2. Replicar este cambio a DC-B
  3. Modificar una propiedad de esta cuenta en DC-B
  4. Replicar este nuevo cambio a DC-A

Debemos tener en cuenta que uno de los puntos clave del modelo de replicación de Active Directory son los “metadatos” que podemos decir es la “información sobre los datos”, que es usado por Active Directory para determinar el estado relativo de los objetos entre los Controladores de Dominio

Cada objeto contiene un número de campos que almacena en cada atributo del objeto. Por ejemplo: Nombre del atributo, fecha y hora del último cambio, número de versión del atributo, Originating DC ID, y Originating DC USN

Vamos al ejemplo

Creación de un usuario en DC-A, datos en DC-A

Atributo

USN

Version

Timestamp

Originating DC

Originating USN

givenName

1001

1

21/4/12 9:21

DC-A DSA GUID

1001

sn

1001

1

21/4/12 9:21

DC-A DSA GUID

1001

unicodePwd

1001

1

21/4/12 9:21

DC-A DSA GUID

1001

El nuevo usuario replicado en DC-B

Atributo

USN

Version

Timestamp

Originating DC

Originating USN

givenName

2001

1

21/4/12 9:21

DC-A DSA GUID

1001

sn

2001

1

21/4/12 9:21

DC-A DSA GUID

1001

unicodePwd

2001

1

21/4/12 9:21

DC-A DSA GUID

1001

La cuenta de usuario actualizada en DC-B

Atributo

USN

Version

Timestamp

Originating DC

Originating USN

givenName

2001

1

21/4/12 9:21

DC-A DSA GUID

1001

sn

2001

1

21/4/12 9:21

DC-A DSA GUID

1001

unicodePwd

2002

2

22/4/12 12:44

DC-B DSA GUID

2002

El cambio hecho en DC-B se replica a DC-A

Atributo

USN

Version

Timestamp

Originating DC

Originating USN

givenName

1001

1

21/4/12 9:21

DC-A DSA GUID

1001

sn

1001

1

21/4/12 9:21

DC-A DSA GUID

1001

unicodePwd

1002

2

22/4/12 12:44

DC-B DSA GUID

2002

Bien, creo que esta parte fue la más difícil de comprender, pero nos da las bases para proseguir con otras notas e ir profundizando aún más, aunque dando esto por comprendido el resto es más sencillo.

Post a comment or leave a trackback: Trackback URL.

Comentarios

  • Jorge  On 29/04/2013 at 21:04

    Hola Guillermo. muy bueno, Gracias

  • yepe  On 10/09/2013 at 18:42

    excelente, pero de verdad que es dificil esto del directorio activo

    • Guillermo Delprato  On 11/09/2013 at 08:08

      Es que estás justo en la nota de la parte más complicada. Para la operación en general no son necesarios este tipo de conocimientos, he puesto estas notas porque siempre hay alguien que “quiere saber más” o “cómo es internamente”

      Un buena forma de comprender Active Directory lo tienes en el enlace que pongo más abajo; que a su vez tiene enlaces a otras notas para poder relacionar los temas ya que fueron publicadas fuera de orden
      Active Directory – Resumen (Relacionando Notas) | WindowServer:
      https://windowserver.wordpress.com/2013/03/01/active-directory-resumen-relacionando-notas/

  • Javier Azogue  On 18/09/2014 at 14:40

    Excelente nota Guillermo, gracias por la explicación detallada, un poco complicado entender de primera mano.

    • Guillermo Delprato  On 18/09/2014 at 15:02

      Gracias por el comentario Javier
      Si, a ese nivel el tema se complica un poco, y yo creo que es por eso que Microsoft ahora no sé si realmente lo documenta. Yo lo he sacado de información de hace bastante tiempo

  • Antonio Roncancio  On 17/04/2015 at 19:44

    Cordial saludo Guillermo…muchas gracias por la información pero no ubico la tercera parte…

    • Guillermo Delprato  On 18/04/2015 at 08:47

      Hola Antonio, no he preparado una tercera parte porque estas notas, tanto la primera como esta, no han sido muy populares, y realmente es un tema que da mucho trabajo preparar y escribir
      De todas formas si quieres profundizar el tema te dejo un enlace, pero en inglés que tiene mucha información: How the Active Directory Replication Model Works: Active Directory
      https://technet.microsoft.com/en-us/library/cc772726(v=ws.10).aspx
      Un lugar con muchísima información, pero muy difícil de conseguir ahora, es el “Windows 2000 Resource Kit” de Windows Server 2000 y específicamente en uno de los libros: “Core Networking Guide”, tenía información invaluable que Microsoft ya no publica más
      PD) Antonio, veo tu comentario dos veces con el mismo texto, elimino uno de los dos para que no esté repetido

      • antonioroncancio  On 20/04/2015 at 10:40

        …muchas gracias Guillermo por la respuesta…voy a revisar la información contenida en el link, y si a futuro publicas la tercera parte lo agradecería mucho…ya que la información que publicas en muy clara y a mi manera de ver de gran importancia.

      • Guillermo Delprato  On 20/04/2015 at 16:21

        ¡Gracias Antonio!

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: