Administración de Windows

Guía de réplica de Active Directory

Laura E. Hunter

Resumen:

• Transición a Active Directory
• Mantener la coherencia
• Gestión de la resolución de conflictos
• Cambios en Windows Server 2008

Antes de la introducción de Windows 2000 Server y Active Directory, muchos entornos corporativos dependían de Windows NT para su infraestructura de servidores y

administración de identidades y acceso. Cuando se implementó Windows NT® 4.0, era una oferta atractiva para el espacio de los sistemas operativos de red (NOS), pero tuvo varios inconvenientes que hacían difícil su implementación en una gran empresa.

Para empezar, Windows NT usaba un espacio de nombres plano para almacenar recursos de red, lo cuál significaba que no existía una buena manera de separar los recursos en subconjuntos más pequeños ni de configurar algún tipo de administración granular. No puede, por ejemplo, configurar un contenedor departamental para los recursos de su departamento de marketing, ni configurar un administrador local con derechos para restablecer únicamente las contraseñas de los usuarios de dicho departamento. De esta manera, la seguridad de Windows NT se basaba en todo o nada; si deseaba delegar las tareas administrativas en un ingeniero de soporte técnico de escritorio, a menudo se veía forzado a conceder muchos más permisos que otorgaría en otra situación.

Además, Windows NT almacenaba toda su información en una base de datos del administrador de cuentas de seguridad (SAM) que no estaba diseñada para crecer por encima de los 40 MB. Si su base de datos SAM crecía por encima del máximo recomendado (lo cual pasaba aproximadamente con entre 25.000 y 40.000 objetos, según la configuración), debía dividir su entorno en varios dominios independientes, lo cuál dificultaba tanto la administración de la red como la tarea de ofrecer a los usuarios el acceso a los recursos. Cada dominio NT contenía un único controlador de dominio principal (PDC), que incluía la única copia de lectura/escritura de la base de datos SAM; aunque fuera posible implementar uno o más controladores de dominio de reserva (BDC) para ofrecer tolerancia a errores, estos BDC eran de sólo lectura y no podían realizar actualizaciones, como por ejemplo cambiar una contraseña de usuario, para lo cual era necesaria una operación de escritura.

Por último, Windows NT dependía de la resolución de nombres NetBIOS, que se basaba en la difusión, y que generaba a menudo una gran cantidad de tráfico cuando los usuarios examinaban sus recursos de red, especialmente si necesitaban hacerlo a través de un vínculo WAN lento o con mucho tráfico.

Emerge un nuevo modelo

En el año 2000, Microsoft lanzó al mercado Windows® 2000, que incluía una revisión importante de sus ofertas de NOS anteriores. El nuevo servicio de NOS, Active Directory®, era tan diferente de Windows NT como cabía esperar. Active Directory no dependía de un espacio de nombres plano, sino que se creó a partir del estándar X.500, que creó una estructura de organizativa jerárquica; los recursos podían ahora organizarse en varas unidades organizativas dentro de un único dominio y la administración de cada unidad organizativa se podía delegar hasta el nivel de las tareas.

Otro cambio significativo respecto de Windows NT fue el nuevo modelo de réplica con varios maestros. Atrás quedaba el PDC que admitía escritura y los BDC asociados; en Active Directory, cada controlador de dominio tenía la capacidad de escribir en la base de datos de Active Directory.

Sin embargo, aunque contribuía a una mayor flexibilidad en términos de compatibilidad con un entorno grande o descentralizado, también generaba nuevos desafíos para mantener la integridad de Active Directory. Si John Smith y Jane Dow cambian el mismo objeto en oficinas que se encuentran en cada punta del país, ¿qué sucede si dichos cambios son incompatibles entre sí? El modelo de réplica de Active Directory define las formas en que se comunican las actualizaciones a todos los controladores de dominio dentro de un entorno, así como la manera de administrar cualquier conflicto que surja como resultado de la capacidad de varios maestros de realizar cambios prácticamente desde cualquier lugar.

Mecánica de la réplica de Active Directory

A los efectos de estos ejemplos, sólo explicaremos la réplica interna en los sitios. Básicamente, la réplica dentro de un sitio se diseña para replicar rápidamente los cambios a los DC del mismo sitio y se realiza mediante la notificación de cambios. En el caso de la réplica interna en sitios, DC1 notificará a DC2 que tiene cambios que deben replicarse, después de lo cuál DC2 extraerá dichos cambios de DC1. De forma similar, cuando DC2 tenga algún cambio lo notificará a DC1, después de lo cual DC1 extraerá dichos cambios de DC2. Como puede ver, toda la réplica de Active Directory sucede en las operaciones de extracción, no en las de inserción.

Dado que Active Directory puede escalar a cientos de miles o incluso a millones de objetos, es necesario dividir la base de datos de Active Directory en secciones, denominadas contextos de nomenclatura (NC). Como mínimo, cada controlador de dominio almacena tres NC en su copia local de la base de datos de Active Directory.

NC de esquema Este NC se replica al resto de los controladores de dominio del bosque. Contiene información acerca del esquema de Active Directory, que, a su vez, define las diferentes clases y atributos de objetos que hay dentro de Active Directory.

NC de configuración Este NC también se replica al resto de los DC del bosque, y contiene información de configuración para todo el bosque que pertenece al diseño físico de Active Directory, así como información acerca de especificadores de pantalla y cuotas de Active Directory para todo el bosque.

NC de dominio Este NC se replica al resto de los DC dentro un sólo dominio de Active Directory. Éste es el NC que contiene los datos de Active Directory a los que se tiene acceso con más frecuencia: los usuarios, grupos, equipos y otros objetos reales que residen dentro de un dominio de Active Directory determinado.

Para optimizar mejor el tráfico de réplica, cada contexto de nomenclatura se replica por separado para que un NC que cambia pocas veces, como el NC de esquema, no ocupe ancho de banda de red que necesita el DC de dominio, que probablemente cambiará con mayor frecuencia.

Dado que los cambios de directorio se pueden realizar desde cualquier DC de Active Directory, la réplica de Active Directory debe realizar el seguimiento de dos tipos de operaciones de escritura. Uno de los tipos es el de las escrituras originales: aquéllas que tienen lugar cuando un determinado cambio se realiza directamente en un DC determinado. Por ejemplo, si se conecta a DC1 y cambia una contraseña de usuario, el cambio en cuestión se considera una escritura original en DC1. Active Directory también debe realizar el seguimiento de escrituras replicadas; como puede suponer, esto significa que se ha replicado un determinado cambio desde otro controlador de dominio. El cambio que se haya considera escritura original en DC1 se considera una escritura replicada cuando se replica a DC2, a DC3 y a cualquier otro DC en todo el dominio.

Los controladores de dominio de Active Directory administran la transmisión de cambios de directorio mediante el uso de metadatos de réplica. Esto significa que, además de comunicar los datos reales que han cambiado de un DC a otro (si la descripción de John Smith se cambia por "Director de RR. HH."), Active Directory también transmite información adicional acerca de dicho cambio para permitir que los controladores de dominio administren la réplica de la manera más eficiente, como por ejemplo el DC a partir del cuál se originó el cambio, el momento en que se realizó el cambio y otros datos clave.

El primer elemento de los metadatos de réplica que explicaremos es el números de secuencias de actualización (USN). Cada controlador de dominio mantiene un USN que es específico de dicho controlador de dominio. Siempre que se realiza un cambio en Active Directory desde ese DC, el USN se incrementa en 1. Así que si un DC tiene un USN de 1.000 a las 11 de la mañana y de 1.005 a las 11:30 de la mañana, sabrá que se realizaron cinco cambios en la base de datos de Active Directory en ese DC. Cuáles hayan sido dichos cambios no importa en lo que respecta al USN: puede haber modificado cinco objetos diferentes, creado cinco objetos, eliminado cinco objetos o cualquier combinación de estas opciones; el USN del DC seguirá aumentando en cinco. Además, los USN sólo pertenecen a un controlador de dominio específico, y no tienen ninguna relevancia cuando se comparan con los otros DC. Es posible que un DC de un dominio realice un cambio a las 11:30 de la mañana al que asigne un USN de 1051, y que un segundo DC del mismo dominio realice un cambio precisamente en el mismo momento que le asigna un USN de 5084. Aunque estos dos DC tienen USN radicalmente diferentes para un cambio que se realiza aproximadamente en el mismo momento, este hecho es irrelevante para la manera en que se replican estos cambios; los números de secuencias de actualización de un DC no tienen ningún significado en ninguno de los otros DC en cuanto a la comparación de los cambios entre sí.

Pero esta no es la única manera de aumentar un USN de DC. Recuerde que un cambio en la base de datos de Active Directory puede consistir en una escritura original o una escritura replicada. Ambos tipos de operaciones de escritura aumentan los números de secuencias actualizadas en un controlador de dominio, lo cual significa que aumentan siempre que los cambios se replican desde otro DC. Ahora, cada DC necesita claramente una manera de realizar un seguimiento de los cambios que ya se han replicado ya que, de lo contrario, cada DC enviaría a través de la red la base de datos completa de Active Directory en cada réplica. Para evitarlo, cada controlador de dominio de Active Directory mantiene un valor denominado vector de límite máximo (HWMV) para los otros controladores de dominio con los cuales realiza la réplica. Cada DC asociará este vector de límite máximo al identificador único global (GUID) del DC remoto, para evitar cualquier confusión si un controlador de dominio remoto cambia de nombre o se elimina del directorio.

Empecemos con un ejemplo sencillo, donde se configuran dos controladores de dominio en los dominios contoso.com, dc1.contoso.com y dc2.contoso.com. Dado que existen dos DC en el dominio contoso.com, DC1 y DC2 sólo se replican entre sí. Tenga en cuenta que este es un ejemplo sencillo que aún no muestra todo el panorama de réplica de Active Directory; añadiremos más información a medida que vayamos explicando más detalles.

También hay que señalar que el USN actual de DC1 es 3000, el USN actual de DC2 es 4500, y que estos dos DC están completamente actualizados entre sí cuando empezamos nuestro ejemplo:

Paso 1: DC1 y DC2 están actualizados entre sí. DC1 tiene un vector de límite máximo para DC2 de 4500, y DC2 tiene un vector de límite máximo para DC1 de 3000, como se muestra en la figura 1.

Figura 1** Estado actual de los dos DC **

Paso 2: Un administrador crea un nuevo objeto en DC1, y el USN de DC1 aumenta a 3001, como se muestra en la figura 2. Observe que el HWMV de DC1 no cambia en DC2, porque DC1 aún no ha notificado a DC2 que tiene cambios en espera.

Figura 2** Se agrega un nuevo objeto **

Paso 3: DC1 notifica a DC2 que tiene cambios disponibles. DC2 inicia la réplica con DC1 para solicitar todas las actualizaciones disponibles. Como parte de esta solicitud, DC2 envía a DC1 el vector de límite máximo que tiene almacenado para DC1, como se muestra en la figura 3.

Figura 3** Notificación de cambios **(Hacer clic en la imagen para ampliarla)

Paso 4: DC1 envía a DC2 el cambio que corresponde al USN 3001, es decir, el objeto que se crea en DC1 en el paso 2. DC2 actualiza su propio USN a 4501 y su HWMV para DC1 a 3001, como se muestra en la figura 4.

Figura 4** Cambios y actualizaciones **(Hacer clic en la imagen para ampliarla)

¿Todo bien por ahora? Pero ahora existe un problema. DC2 tiene un cambio que necesita replicar. Si lo único necesario son los USN y los vectores de límite máximos, en este momento DC2 se pondría en contacto con DC1 para volver a replicarle el mismo cambio que DC1 acaba de replicar a DC2, lo cual provocaría un ciclo de réplica interminable y eso consumiría cada vez más el ancho de banda de manera progresiva. Para combatir esta situación, necesitamos algunas piezas más del rompecabezas, y la primera de ellas es el vector de actualización (vector UTD o, simplemente, UTDV).

El UTDV es otra parte de los metadatos de réplica que se usa para amortiguar la propagación; es decir, su propósito es evitar que un mismo cambio malgaste el ancho de banda con continuas replicas una y otra vez a través de la red. Cada DC mantiene una tabla de UTDV para el resto de los DC que almacenan una réplica del contexto de nomenclatura en cuestión. Para el NC de dominio, cada DC de un dominio mantiene un UTDV para cada DC del dominio; para los NC de configuración y esquema, se mantiene para cada DC del bosque. La tabla de UTDV realiza un seguimiento no sólo del USN más alto que ha recibido cada DC de sus asociados de réplica, sino también del valor más alto de USN que ha recibido de cada DC que replica un NC determinado. Para permitir que esto suceda, cada cambio que se replica incluye también la siguiente información:

• El GUID del DC que replica el cambio. Puede ser un cambio que se replica como una escritura original o como una escritura replicada.
• El USN del DC que replica el cambio. Una vez más, puede ser de una escritura original o de una escritura replicada.
• El GUID del DC que originó el cambio. Si este GUID es el mismo que el GUID del DC que replica el cambio, entonces se trata de una escritura original. De lo contrario, entra en juego la tabla de UTDV.
• El USN del DC que originó el cambio. Nuevamente, si este USN es el mismo que el USN del DC que replica el cambio, entonces se trata de una escritura original. De lo contrario, la tabla de UTDV está desactivada.

Para ilustrar mejor este proceso, aumentaremos la complejidad de nuestro ejemplo añadiendo un tercer controlador de dominio, DC3. En esta instancia, DC1, DC2, y DC3 son todos asociados de réplica mutuos: DC1 replica con DC2 y DC3, DC2 con DC1 y DC3, y DC3 con DC1 y DC2:

Paso 1: DC1, DC2 y DC3 están todos actualizados entre sí.

Paso 2: DC3 realiza una sola escritura original al restablecer la contraseña de la cuenta de usuario jsmith. DC3 notifica a DC1 y DC2 que tiene cambios disponibles. DC1 y DC2 incorporan la escritura original de DC3 y, a continuación, actualizan sus tablas de HWMV y de UTDV para DC3 como se muestra en la figura 5.

Figura 5** Actualización de las tablas de HWMV y de UDTV **(Hacer clic en la imagen para ampliarla)

Paso 3: Aquí es donde entra en juego el vector de actualización. DC2 notifica a DC1 que tiene cambios disponibles. A continuación, DC1 se pone en contacto con DC2 para solicitar los nuevos cambios al enviar a DC2 la siguiente información:

• El valor de límite máximo de DC1 para DC2, que en este caso es 4501.
• La tabla de UTDV de DC1 (que se muestra en la figura 6), que indica el USN original que ha recibido de todos los DC, incluido DC3.

Figure 6 Tabla UTDV

En función del HWMV de 4501, DC2 comprueba que no ha replicado el cambio en cuestión a DC1 (consulte la figura 7).

Figure 7 Es necesario replicar un cambio

Sin embargo, a partir de la tabla de UTDV que DC1 transmitió antes de que comenzara la réplica, DC2 determina que en realidad DC1 no necesita este cambio, porque ya lo ha recibido de DC3. En este momento, DC1 simplemente actualiza su entrada de HWMV para DC2 para reflejar el aumento de USN, como se muestra en la figura 8. Sin embargo, para conservar el ancho de banda, los datos reales no se envían por la red.

Figura 8** Amortiguamiento de la propagación **(Hacer clic en la imagen para ampliarla)

Paso 4: Este mismo amortiguamiento de propagación se producirá cuando DC2 notifique a DC3 que tiene cambios disponibles y cuando de DC1 notifique a DC2 y DC3 del mismo modo. Los tres DC actualizarán sus respectivas entradas de HWMV para sus asociados de réplica como se muestra en la figura 8, pero nuevamente, los datos reales no recorrerán la red porque ya se transmitieron a cada DC en el paso 2.

Resolución de conflictos en un entorno con varios maestros

Hasta aquí nuestros ejemplos pertenecen a un mundo ideal, donde sólo un administrador realiza cambios en un DC a la vez y jamás nadie pisa el trabajo de los demás. En el mundo real, sabemos que rara vez sucede así. Como las actualizaciones de un objeto de Active Directory pueden venir de cualquier controlador de dominio del dominio, ¿qué sucede si dos administradores realizan actualizaciones que producen conflictos desde dos controladores de dominio diferentes? En un entorno de Active Directory se producen tres tipos de conflictos, y cada uno de ellos usa un método de resolución de conflictos diferente.

Cambios de propiedad que producen conflictos . Este conflicto se produce si dos administradores actualizan el mismo objeto de una manera que genere un conflicto: un administrador define la descripción de un usuario como "Marketing", mientras que otro administrador en un DC diferente define la misma descripción de usuario como "Ventas y marketing".

Creación de nuevos objetos que entran en conflicto . Este conflicto se produce si dos administradores crean un objeto con el mismo nombre al mismo tiempo, como por ejemplo, dos usuarios denominados jsmith.

Mover un objeto a un contenedor eliminado . Este tipo de conflicto es mucho menos habitual y sucede si un administrador crea o mueve un objeto de un contenedor, como una unidad organizativa, al mismo tiempo que otro administrador de un DC diferente elimina dicho contenedor.

Para abordar los dos primeros tipos de conflictos, es el momento de presentar dos conjuntos más de metadatos de réplica que se usan principalmente en la resolución de conflictos. El valor versionID se asigna a cada atributo individual de un objeto, con un valor inicial de 1 cuando el objeto se crea por primera vez. VersionID aumenta en 1 siempre que desde cualquier DC se modifica un atributo individual. Por lo tanto, si se actualiza el atributo de descripción de un usuario concreto desde su valor predeterminado (en blanco o <no establecido>) a "Departamento de marketing", el atributo de descripción tendrá un versionID de 2. Si más adelante la descripción se modifica a "Departamento de ventas y marketing", el atributo de descripción tendrá un versionID de 3, etc. Este versionID se incluye con cada entrada de réplica junto con los otros conjuntos de metadatos que ya hemos presentado.

VersionID también se puede usar para reducir aún más el tráfico de réplica. Por ejemplo si un administrador de DC2 ha realizado varios cambios en un único atributo (quizás haya cometido errores al escribir el cambio) de manera que DC2 tenga las escrituras originales correspondientes a los versionID 2, 3, 4 y 5, entonces DC2 sólo replicará la escritura correspondiente al último, versionID 5. Dado que, de todos modos, los cambios anteriores simplemente estarán sobrescritos, de este modo se obtiene un método abreviado para reducir el uso innecesario de ancho de banda.

Cada cambio en Active Directory incluye también la segundo conjunto adicional de metadatos que se usa en la resolución de conflictos, una marca de tiempo, como parte de los metadatos de réplica y que indica cuándo se realizó la modificación.

El atributo de marca de tiempo se usa también como una medida proactiva del estado de Active Directory. Si un DC no ha detectado cambios con una marca de tiempo relativamente reciente de un DC determinado, comenzará a generar mensajes de error que indican que es posible que exista un problema con el DC en cuestión.

¿Cómo se usan estos dos atributos en la resolución de conflictos? Examinemos por separado cada tipo de conflicto.

Resolución de cambios de propiedad que producen conflictos

Considere el ejemplo del objeto de usuario jsmith en el dominio contoso.com. Un administrador en DC1 cambia la descripción de jsmith a "Marketing". Casi simultáneamente, un administrador en DC3 cambia la misma descripción de usuario a "Ventas y marketing". En este momento, la información comparada de DC1 y DC3 acerca del atributo de la descripción de jsmith es la que se muestra en la figura 9.

Figure 9 Cambios casi simultáneos

Si DC2 recibe simultáneamente ambos cambios, está claro que deberá determinar cuál es el cambio "ganador". El orden de desempates para la resolución de conflictos es el siguiente:

1. La modificación que tiene el versionID más alto se aceptará como cambio "ganador"; el cambio "perdedor" se sobrescribirá. En este caso, el versionID es 2 para ambos registros, así que necesitamos pasar al segundo factor de desempate.
2. Si ambos registros tienen el mismo versionID, el cambio que tiene la marca de tiempo posterior será aceptado como cambio ganador; se sobrescribirá el cambio perdedor. En este caso, la marca de tiempo de la escritura original de DC3 es posterior, así que la descripción de jsmith se establece en "Ventas y marketing". En el caso poco habitual de que tanto versionID como la marca de tiempo sean idénticos, necesitamos un tercer factor de desempate definitivo:
3. Si ambos registros tienen el mismo versionID y la misma marca de tiempo, ganará cualquier escritura que se origine en el DC con el GUID de número más bajo; se sobrescribirá la escritura con el GUID de número más alto. Por lo tanto si el GUID de DC1 es 1234567890 y el GUID de DC3 es 2345678901, la escritura original de DC1 ganaría si versionID y la marca de tiempo fueran idénticos.

Probablemente piense: "¿No hubiera tenido más sentido que la marca de tiempo fuera el primer factor de desempate? Esta situación no está tan definida como quizás crea. Si la marca de tiempo fuera el principal factor de desempate en la resolución de conflictos de Active Directory, lo único que un administrador malintencionado necesitaría hacer para propagar sus cambios sería retrasar el reloj en un DC determinado para que siempre gane gracias a las marcas de tiempo.

Resolución de conflictos de creación de objetos

En los casos donde se crean dos objetos con el mismo nombre, Active Directory usará los tres mismos factores de desempate descritos en la sección anterior para determinar cuál es el objeto "ganador". Sin embargo, a diferencia de la sección anterior, el objeto "perdedor" no se sobrescribe. En vez de eso, se cambia el nombre del objeto perdedor mediante caracteres CNF (que indica objetos en conflicto), seguido por dos puntos y el GUID del objeto "perdedor". Esto permite que los administradores determinen más metódicamente qué objeto se debe retener y cuál eliminar.

Resolución del traslado de un objeto a un contenedor eliminado

Como mencioné anteriormente, la resolución del traslado de un objeto a un contenedor eliminado es un conflicto relativamente poco habitual, que sólo se produce en dos situaciones. En una, un administrador de un DC crea un objeto dentro de un contenedor determinado, por ejemplo la unidad organizativa Aprendizaje, al mismo tiempo que un administrador de otro DC elimina la unidad organizativa Aprendizaje. La segunda situación se puede producir cuando un administrador de un DC mueve un objeto a un contenedor al mismo tiempo que un administrador de otro DC elimina dicho contenedor.

En este caso, la resolución es bastante sencilla: Active Directory mueve el objeto "huérfano" a un contenedor especial diseñado para este fin dentro de Active Directory, el contenedor LostAndFound, que está ubicado en la raíz de cada dominio de Active Directory. En el dominio contoso.com, el contenedor LostAndFound se encuentra en la siguiente ruta de acceso LDAP: LDAP://cn=LostAndFound,dc=contoso,dc=com. Si no ve el contenedor LostAndFound cuando abre el complemento Usuarios y equipos de Active Directory, simplemente haga clic en Ver | Características avanzadas.

Protección contra la reversión de USN

Una de las situaciones más graves que puede encontrar en un entorno de Active Directory es también una de las más sencillas de evitar, una vez que se comprende su causa y cómo solucionar el problema. La reversión de USN es una condición de error que puede bloquear la réplica en su red por completo, y se produce cuando se permite que un controlador de dominio permanezca durante mucho tiempo sin conexión y más adelante vuelve a funcionar o cuando se restaura un controlador de dominio con un método no admitido.

Una causa subyacente de reversión de USN tiene que ver con la manera en que se procesan las eliminaciones de objetos en el entorno con varios maestros de Active Directory. Cuando un objeto se elimina en un DC, no se elimina por completo el objeto, sino que éste desecha de manera que el objeto de desecho se pueda replicar a los otros DC y notificarles así su eliminación. Lo más notable es que un objeto de desecho posee un atributo isDeleted que se establece en TRUE. Para reducir el tamaño del objeto de desecho, se elimina la mayor parte de los valores contenidos en el objeto, tales como descripción, información personal y pertenencia a grupos de un objeto de usuario (para obtener más información sobre este proceso, consulte el artículo de Gil Kirkpatrick "Reanimación de objetos de desecho de Active Directory," disponible en línea en technetmagazine.com/issues/2007/09).

La reversión de USN se puede producir porque estos objetos de desecho no se conservan por tiempo indefinido. De forma predeterminada, se purgan por completo de la base de datos de Active Directory después de 60 o 180 días (en función de la versión de Windows Server® que se ejecuta cuando se crea el entorno de Active Directory por primera vez). Este período de 60 o 180 días se denomina vigencia de objetos de desecho. Todos los controladores de dominio necesitan tener la posibilidad de replicar por lo menos una vez durante este período para no convertirse en elementos prácticamente inútiles; crean una oportunidad para la reversión de USN. Básicamente, la reversión de USN se produce cuando un controlador de dominio está tan desactualizado que "pierde" uno o más objetos de desecho y, de este modo, no puede obtener su copia local de la base de datos de Active Directory con un estado completamente actualizado con los otros DC. Para evitarlo, ningún controlador de dominio que permanezca sin conexión durante un tiempo mayor que la vigencia de objetos de desecho se debe volver a funcionar; más bien se debe reconstruir desde el principio después de eliminar los metadatos del antiguo DC de Active Directory con los pasos que se describen en el artículo 216498 de Microsoft Knowledge Base (support.microsoft.com/kb/216498).

La segunda causa de reversión de USN se produce cuando un controlador de dominio se restaura con un método no compatible, normalmente mediante una herramienta de clonación o creación de imagen de disco. Cuando esto sucede, la base de datos de Active Directory restaurada no se da cuenta de que se encuentra "atrasada en el tiempo", porque el método de restauración no conoce Active Directory. La reversión de USN era difícil de detectar en Windows 2000 y en la versión inicial de Windows Server 2003, pero Windows Server 2003 SP1 (y Windows Server 2008, aparecerá pronto en el mercado) tienen controles integrados para detectar cuándo un DC se restaura de un modo incorrecto. En estas versiones más reciente de los sistemas operativos, un DC registrará los identificadores de evento 1115, 2095, 2103 y 2110 en el registro de eventos de servicios de directorio; el texto de estos eventos, así como los pasos necesarios para realizar una recuperación ante una reversión de USN, se pueden encontrar en el artículo 875495 de Microsoft Knowledge Base (support.microsoft.com/kb/875495) para Windows Server 2003. Puede obtener información sobre cómo trabajar con reversiones de USN en Windows 2000 en el artículo 885875 de Microsoft Knowledge Base, disponible en support.microsoft.com/kb/885875).

Actualización del modelo de varios maestros en 2008

En la versión de Windows Server 2008 que pronto verá la luz, Microsoft ha incluido un leve cambio en el modelo de varios maestros: el Controlador de dominio de sólo lectura (RODC). El RODC está diseñado principalmente para implementaciones de sucursal o para cualquier situación donde no se dispone de personal de TI dedicado en una ubicación determinada y es necesario dar pasos adicionales para garantizar la integridad de un DC determinado. Aunque podríamos ocupar un artículo completo en explicar todos los detalles técnicos del RODC, revisemos los puntos clave que debe conocer.

Como su propio nombre indica, la copia de la base de datos de Active Directory que reside en un RODC es de sólo lectura. Puede conectarse a un RODC para leer prácticamente cualquier información que necesite, pero no puede realizar operaciones de escritura en un RODC.

En segundo lugar, un RODC no realiza ninguna réplica de salida. Este es un cambio fundamental respecto al modelo de réplica con varios maestros que hemos explicado hasta aquí. Un RODC recibirá la réplica de entrada de otros DC que se pueden escribir de Windows Server 2008, pero en ningún caso replicará información a los otros DC. Esto crea un nivel adicional de seguridad de manera tal que, incluso si un usuario malintencionado puede modificar de algún modo Active Directory desde el RODC, esas modificaciones no se propagarán hacia afuera al resto de su entorno.

Quizás lo más interesante de todo es que el RODC no replica contraseñas de usuario de forma predeterminada. Cuando la base de datos de Active Directory se replica de forma entrante a un RODC desde un DC que se puede escribir, todos los objetos de usuario se replican sin la información de la contraseña de usuario. Esto ofrece aún otro nivel de seguridad en un entorno de sucursal, de manera tal que si a un DC tuviera piernas y pudiera marcharse, no existe información de contraseña residente en el disco duro del DC. En conjunto, estos cambios en la idea original de réplica de Active Directory con varios maestros crean un modelo con muchas mejoras para la protección de los controladores de dominio ubicados en sucursales u otras ubicaciones remotas.

Laura E. Hunter ha recibido cuatro veces el premio Microsoft MVP en el área de redes de Windows Server. Cuenta con 10 años de experiencia en el sector de TI y es autora o coautora de numerosos libros, artículos, y notas del producto del sector, como Active Directory Cookbook, segunda edición (O'Reilly, 2006).

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.