Active Directory es una aplicación muy robusta, como debe ser para un componente tan fundamental de la infraestructura de TI de una empresa. Pero la arquitectura que la hace robusta también la hace difícil de entender. Esta falta de comprensión a menudo conduce a suposiciones en su estrategia de recuperación que pueden dejar su AD roto sin una manera de volver a la normalidad.
Cuando el equipo de ingeniería y operaciones de AD elabora su plan de recuperación, la tendencia natural es pensar primero en recuperar los controladores de dominio (DC). Este es un buen primer paso, y se basa en dos razones muy prácticas. En primer lugar, los DC han sido históricamente el componente de AD que más falla. En segundo lugar, la recuperación y reconstrucción de servidores es una de las tareas operativas más antiguas del libro de operaciones, por lo que es natural aplicarla a esta situación.
Pero en el caso de Active Directory, el equipo a menudo no sigue ni planifica el otro tipo de desastre con el que se puede encontrar Active Directory: la corrupción lógica de los datos de AD.
La red de réplicas
Parte de lo que hace que Active Directory sea difícil de entender y solucionar operativamente es la complejidad de su modelo lógico de datos. Siempre he mirado AD a través de lo que considero varios pares de gafas. El primero y más obvio es la red de DC físicos y su salud. Tendemos a pensar en los DC de un bosque porque son los activos tangibles de Active Directory. A continuación están mis gafas de sitios. Con ellas, veo la topología de sitios de la red corporativa y cómo los datos se replican constantemente entre los DC: sitios de buena conectividad (que pueden o no tener un DC en ellos), enlaces de sitios para conectar los sitios de la forma que más se ajuste a las necesidades de los usuarios y las aplicaciones que utilizan los sitios de AD, y el ajuste fino de estos enlaces de sitios con el coste de los enlaces y la prioridad de DNS para favorecer a unos DC sobre otros.
Pero la realidad es más complicada que un diagrama de arquitectura de sitios. Si se observa de cerca la replicación con una herramienta como ADREPLSTATUS o Repadmin, se revela la verdadera complejidad de Active Directory. Cada DC aloja varias particiones de directorio que contienen datos importantes, y los diferentes diseños de bosque influyen en qué particiones aloja un DC. Cada una de esas particiones se conecta con varios otros DCs en otras partes del dominio o bosque. Yo veo esto como una madeja de cientos de trozos de hilo multicolor conectando clavijas en un tablero de clavijas. Algunos colores de hilo van a unas pocas clavijas, mientras que otros colores van a todas las clavijas del tablero. Es una maravilla que funcione, y más aún que funcione tan bien.
Pero este mecanismo funciona tan bien para datos malos como para datos buenos. En caso de corrupción de datos lógicos, los datos corruptos se replicarán a través de todos los DC del dominio o bosque. En los casos en que la corrupción lógica es grave (como la desactivación de la cuenta del DC en AD a través de la consola estándar de Usuarios y Computación) es necesario llevar a cabo una recuperación de desastres de AD. El proceso de restauración de Microsoft incluye más de 50 pasos manuales, lo que lo hace lento, propenso a errores e insuficiente para los requisitos de la empresa. La complejidad del procedimiento es lo suficientemente alta como para que Microsoft lo ofrezca como parte de ADRES (AD Recovery Execution Service), un compromiso de servicio de 5 días que se centra en problemas de recuperación de AD.
Muchas empresas han implementado sitios de recuperación ante desastres en Active Directory para proporcionar DC de conmutación por error para los usuarios y el servicio si el DC normal ha fallado. Sin embargo, los sitios de DR o el número de DC que tenga no le ayudarán en caso de corrupción lógica: en realidad, complicarán la recuperación.
Ahí es donde puede tener un procedimiento manual que seguir o una solución automatizada que lo haga por usted.
