Esta vez me he decidido a escribir una serie de notas con mucho texto y pocas figuras, así que serán para leer con calma, y sobre todo el que se interese por conocer cómo replica Active Directory entre los Controladores de Dominio.
Primero definiremos algunos de los elementos básicos que intervienen, y vemos, en la interfaz gráfica, y algunos términos, para recién luego entrar en la parte interna del funcionamiento de la replicación de Active Directory (Directorio Activo)
El mito del “Controlador de Dominio Principal”
Comencemos por tratar de corregir un error muy común como es hablar de: PDC (Primary Domain Controller), o Controlador de Dominio Principal o inclusive de Controlador Principal del Dominio.
Esta función no existe más hace años, sólo llegó hasta Windows Server NT 4.0
Sólo queda un FSMO Rol llamado “Emulador de PDC” (PDC Emulator) que en realidad no tiene casi relación.
En ambiente Windows Server NT 4.0 había un único Controlador de Dominio que podía hacer modificaciones en el directorio, y era justamente el PDC. Pero a partir de ambiente de Dominio con Windows Server 2000 no es más así.
Una de las importantes características de Active Directory es justamente que cualquier Controlador de Dominio del Dominio puede hacer modificaciones en la base de Active Directory
¿Y por qué se mantiene el término PDC, aunque se emulado? bueno, porque históricamente este equipo manejaba además otras funciones, y además por razones de compatibilidad con sistemas operativos anteriores en las versiones que soportaban compatibilidad con NT 4.0, y luego en las versiones que soportan compatiblidad con las que soportaban NT 4.0 🙂
Por ejemplo si el Dominio todavía admitía Controladores de Dominio NT 4.0, o si había viejos sistemas operativos cliente (Win95/98) que no tenían instalado el “DS Client” y no sabían que un usuario podía cambiar su contraseña en cualquier Controlador de Dominio.
Otra función de compatibilidad, si se usa el entorno de red de XP/W2003, que es creado por el servicio Browser (Examinador), entonces este Emulador PDC cumple la funcionalidad de Domain Master Browser.
Pero de todas formas tiene algunas características especiales que sigue manejando como ser:
- Es el principal servidor de tiempo contra el cual sincronizan el resto de los Controladores de Dominio del Dominio, y los Emuladores PDC de los Sub-Dominios
- Es donde se pone foco cada vez que editamos una Group Policy
- Recibe replicación preferencias de los cambios de contraseñas
Las Particiones (Naming Context) de Active Directory
Bueno, volvamos al tema que realmente nos interesa, que es la replicación entre Controladores de Dominio
Si cualquier Controlador de Dominio acepta cambios, es importante conocer cómo se propagarán dichos cambios al resto de los Controladores de Dominio, tanto del Bosque como del propio Dominio, ya que diferentes tipos de datos tienen diferentes alcances de replicación.
La base de Active Directory (NTDS.DIT) aunque es un único archivo en realidad contiene varias particiones, teniendo cada una su propio ámbito de replicación.
Tendremos por los menos tres particiones y seguramente alguna más como ya veremos. Cada una de estas particiones se denomina “Naming Context” o “NC”
- Esquema (Schema): este NC contiene toda la definición de atributos y clases de Active Directory, como así también configuraciones internas importantes. Su ámbito de replicación es a todos los Controladores de Dominio del Bosque
- Configuration (Configuración): esta también se replica a todos los Controladores de Dominio del Bosque, y contiene información sobre los Dominos que integran el Bosque, la configuración de Sitios, Enlaces, Redes, etc. e inclusive hasta configuración de algunas aplicaciones a nivel de Bosque como es el caso de Exchange
- Dominio (Domain): este NC es la que contiene todos los objetos de nuestro Domino, usuarios, grupos, etc. (una parte de las GPOs ya que además hay otra parte en la carpeta SYSVOL). Esta se replica en todos los Controladores de Domino del propio Dominio, y finalmente una réplica parcial a los Global Catalog (Catálogo Global)
Y si el asistente de promoción instaló y configuró el servicio DNS, además tendremos dos particiones más
- ForestDNSZones: contiene los registros DNS que se replicarán a todos los Controladores de Dominio con servicio DNS en el Bosque (Forest)
- DomainDNSZones: contiene los registros DNS que se replicarán a todos los Controladores de Dominio con servicio DNS en el Dominio (Domain)
Lo podemos ver fácilmente con ADSIEdit, como muestra la siguiente figura
Replicación “Dentro” y “Entre” Sites (Sitios)
Un tema que es importante que tengamos en cuenta antes de seguir con el objetivo de la nota, está relacionado con la distinción de la forma de replicación entre sitios y dentro de un sitio.
Y vamos aclarando esto aunque por ahora será en forma sencilla: ¿Qué es un Sitio?
Un Sitio (Site) es una o más redes IP, con conectividad permanente, confiable y con suficiente ancho de banda disponible para la replicación.
Habría que definir qué es “suficiente ancho de banda disponible”, pero esto es muy variable de acuerdo a la estructura de nuestro Active Directory, así que por ahora consideraremos que un Sitio (Site) es “casi equivalente” a un sitio físico, donde generalmente no tenemos problemas de conectividad
¿Y por qué es esto? porque la replicación tiene distintos objetivos en cada caso. Si no tenemos problemas de conectividad, el objetivo principal es que un cambio que se produce en un Controlador de Dominio se replique en muy poco tiempo en el resto de los Controladores de Dominio. En cambio, si tenemos posibles restricciones de conectividad como puede suceder con enlaces WAN, el objetivo es diferente, como por ejemplo, controlar y disminuir dicho tráfico de replicación
“Dentro de un Site (Sitio)” se asume buena conectividad, y por lo tanto hay un proceso que se ejecuta (cada 15 minutos) en todos los Controladores de Dominio denominado KCC = Knowledge Consistency Checker, que consultando los registros DNS del resto de los Controladores de Dominio, determina los “Connection objects” (Objetos conexión) que son por los que recibirá datos del resto.
Cada Controlador de Dominio crea los “Connection Objects” de forma de cumplir dos condiciones:
- Cada Controlador de Dominio, tendrá por lo menos dos Connection Objects desde otros dos Controladores de Dominio para recibir actualizaciones (Tolerancia a fallas)
- Ningún Controlador de Dominio quedará a más de tres “saltos” de otro. O sea que un cambio en la base, nunca deberá pasar por más de tres Controladores de Dominio hasta llegar al último
La estructura final, si la pudiéramos ver sería algo así como un doble anillo de replicación entre todos los Controladores de Dominio, y eventualmente “cruces” interiores si alguno quedara a más de tres “saltos”
Si quiere graficarlo, dibujen un eptágono (polígono de 7 lados) y observen que un cambio producido en uno de ellos pasará por no más de tres saltos para llegar a otro. Y si agregan un octavo Controlador de Dominio, va a haber que agregar Objetos Conexións para llegar a este último
Los valores por omisión de tiempos de replicación dentro de un Site, son como sigue: cuando un Controlador de Dominio acepta un cambio, pone un “timer” (contador) por 5 segundos durante los cuales sigue aceptando cambios. Luego de esto le avisa a los Controladores de Dominio que replican desde él (Replication Partners) que hay cambios y que deben actualizarse. Si hay varios, deja un intervalo de 30 segundos entre uno y otro.
Luego, es responsabilidad de estos “Replication Partners” ir a buscar los cambios.
Y finalmente podemos decir que como el máximo período de aceptación de cambios, multiplicado por la cantidad de “saltos”, un cambio dentro de un Site (Sitio) puede demorar en propagarse al resto (Converger la información) un máximo de 15 segundos.
No es habitual ni generalmente recomendado hacer cambios sobre estos parámetros, pero si alguien desea hacer cambios puede ver el siguiente enlace How to Modify the Default Intra-Site Domain Controller Replication Interval
Esta replicación se ejecuta siempre usando RPC (Remote Procedure Calls)
Esta casi inmediata replicación de cambios, podría afectarnos si existieran enlaces WAN de por medio, así que como veremos a continuación, cuando tengamos enlaces de este tipo, lo debemos configurar para evitar un tráfico que puede resultar excesivo.
Entre Sites (Sitios) la replicación se maneja de forma totalmente diferente, ya que el objetivo es controlar y disminuir el tráfico.
Dentro de cada Site, hay un Controlador de Dominio que asume la función de ISTG = Inter-site Topology Generator. Lo podemos ver en Active Directory Sites and Services
Éste es quien nombra al Bridgehead Server (Servidor Cabeza de Puente) que será el que replicará con otro Site. Se pueden configurar los Bridgehead Server preferidos por cada protocolo (IP o SMTP) pero debemos tener cuidado porque en ese caso el sistema lo elegirá solamente entre los preferidos. Si elegimos uno o varios y ninguno de esos estuviera disponible, se cortaría la replicación entre Sites.
La frecuencia de replicación entre Sites por omisión es de 3 horas, configurable entre 15 minutos, y una vez a la semana, y además se pueden configurar: los días y horarios que esté habilitada la replicación, asociarle un Costo, que no es función del ancho de banda, sino que es una preferencia administrativa para definir los Objetos Conexión, cuando hay posibilidades redundantes.
El procedimiento para configurar Sites, Subnets y Links pueden consultarlo en la nota http://windowserver.wordpress.com/2011/05/28/creacin-de-un-bosque-forest-parte-3/
Aunque de todas formas veré de hacer una futura nota, con detalles y consideraciones sobre la forma de configurar los “Sites”, “Subnets”, “Links” y “Site Link Bridges” para cada caso.
Teniendo ya los conceptos básicos establecidos para comprender el proceso de Replicación entre Controladores de Dominio en dos notas siguientes veremos primero cómo hace y qué variables utiliza internamente para controlar la replicación, y luego plantearemos el caso de replicación con varios sitios e inclusive con redes donde no todos los sitios pueden alcanzar a todos los demás
Trackbacks
[…] Active Directory Replication – A fondo – Parte 1 […]
[…] Active Directory Replication – A fondo – Parte 1 By Guillermo Delprato […]