[ARTICULO] Active Directory Domain Services | Virtualización Segura de DCs con Windows Server 2012

Virtualizar controladores de dominio, en los últimos años, ha sido una actividad comúnmente realizada por todos los que administramos plataformas de Active Directory Domain Services.

Hasta la llegada de Windows Server 2012, la virtualización de DCs no estaba completamente soportada: había problemas potenciales en la operatoria y consideraciones que debían ser respetadas para evitar problemáticas serias.

En este artículo vamos a recorrer cuáles fueron las novedades, en torno a virtualización, de Active Directory Domain Services en Windows Server 2012.

[toc]

Introducción

Objetivo y Alcance

Esta publicación tiene como objetivo mostrar a las organizaciones y administradores TI cuáles son las novedades relacionadas a virtualización de controladores de dominio a partir de Windows Server 2012, y cómo pueden estas ser aprovechadas para mejorar la operatoria y ejecución de actividades críticas.

Esta publicación se refiere a las siguientes tecnologías:

• Active Directory Domain Services en Windows Server 2012 y Windows Server 2012 R2.
• Windows Server 2012, versiones Standard y Datacenter.
• Windows Server 2012 R2, versiones Standard y Datacenter.

Audiencia

Este documento está dirigido a Consultores, Profesionales IT y personas que desarrollan tareas de Consultoría, Administración y Soporte o que simplemente están interesados en aprender nuevas cosas.

Comentarios y Corrección de Errores

Hemos realizado nuestro mejor esfuerzo para no cometer errores, pero al fin y al cabo somos seres humanos. Si deseás reportar algún error o darnos feedback de qué te pareció esta publicación, por favor no dejes de comunicarte con nosotros a través de correo electrónico a la siguiente dirección: info@tectimes.net.

Desarrollo

Virtualización de Controladores de Dominio pre-Windows Server 2012

Como hemos comentado en la introducción, virtualizar controladores de dominio, en los últimos años, ha sido una actividad comúnmente realizada por todos los que administramos plataformas de Active Directory Domain Services.

Sin embargo, esta práctica estaba repleta de consideraciones que se podrían resumir en la siguiente frase: “Never Pause, Never Clone, Never Snapshot”.

Documentos oficiales de Microsoft (http://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-8cd1-5fbaa6740ffe(v=ws.10)#operational_considerations_for_virtualized_domain_controllers) identifican las consideraciones de operación a tener en cuenta para controladores de dominio virtualizados:

Más allá de esto, la virtualización de controladores de dominio ha sido (y será por lo menos en el mediano plazo) una práctica muy común.

Vamos a recorrer tres puntos “críticos” sobre la virtualización de DCs “pre-Windows Server 2012” de modo tal de entender cuáles eran los desafíos a afrontar, para luego meternos en cómo fueron solucionados en Windows Server 2012.

Instantáneas (Snapshots)

La aplicación de instantáneas (o conocido como “snapshots”) traía problemas potenciales a infraestructuras de Aplicaciones Distribuidas (como lo es AD):

• Desplazamiento de Reloj Lógico.
• Operaciones ocurren fuera de la conciencia del OS.

El reloj lógico, en Active Directory Domain Services, es utilizado para rastrear cambios. Este reloj lótico es el Update Sequence Number (USN). El USN graba la secuencia de actualizaciones realizadas en cada Controlador de Dominio en relación al tiempo lineal:

En el ejemplo siguiente vemos la siguiente secuencia de acciones:

• T1: se crea una instantánea en el DC2. En ese momento el DC1 y DC2 están sincronizados y con una replicación saludable. El valor de USN es de 100.
• T2: Luego de la instantánea, se realiza el alta de 100 usuarios nuevos. Esto lleva el USN a 200 y quita identificadores relativos del pool disponible para dicho DC (DC2).
• T3: Por algún motivo, se vuelve atrás el DC2, puntualmente a la instantánea tomada en T1. Esto hace que el USN vuelva a ser de 100 y el pool de identificadores relativos vuelva a ser el anterior al T2.
• T4: Este cambio no es reconocido ni procesado por el sistema operativo, lo que produce que algunos usuarios no estén replicados en el DC2. Adicionalmente hay un potencial riesgo de SIDs conflictivos.

Esto tiene un impacto en la replicación:

• Lingering Objects.
• Contraseñas inconsistentes.
• Valores de atributos inconsistentes.
• Inconsistencias en Esquema de AD ante eventual rollback del Schema Master.

Adicionalmente, se potencia un impacto en los Security Principals:

• Duplicación de SIDs.
• Acceso no autorizado a recursos por un período de tiempo.
• En última instancia, además, los usuarios afectados no podrán iniciar sesión

Clonación de Discos

La clonación de discos tampoco es un procedimiento soportado pre-Windows Server 2012. ¿Por qué? Porque clonar discos requeriría ejecutar un proceso de SYSPREP para poder renovar el identificador único de equipo (SID) de modo tal que no existan inconsistencias dentro del Bosque / Dominio. Sin embargo, SYSPREP no está soportado cuando ya existen implementaciones de roles dentro de Windows Server.

Exportación de Equipos Virtuales

Muy similar al punto anterior: las recomendaciones oficiales indican que no debemos realizar el export de una máquina virtual, dado que puede registrarse una alteración en el USN que no podrá ser interpretada por el sistema operativo cuando restauremos la exportación.

Virtualización de Controladores de Dominio a partir de Windows Server 2012

Windows Server 2012 vino a revolucionar la virtualización de controladores de dominio, y más aún la virtualización de aplicaciones distribuidas (como ya veremos). Esto se da gracias a un identificador llamado “VM-Generation ID”, que permite que el sistema operativo tenga las herramientas necesarias para detectar acciones ejecutadas desde un hypervisor y tomar decisiones.

Introducción a Generation ID

VM-Generation ID es un componente que debe ser soportado por el Hypervisor, como Hyper-V de Windows Server 2012 y VMWare.

Es un identificador de 128 bits que los sistemas operativos virtualizados y aplicaciones instaladas en los sistemas pueden aprovechar y se ponen a disposición de las aplicaciones a través del controlador de Windows Server 2012. Como vemos, VM-Generation ID no es un componente exclusivo para virtualización de controladores de dominio, sino que es un componente que interactúa con el sistema operativo de modo tal que puede ser aprovechado por cualquier aplicación, y puntualmente aplicación distribuida (que es donde justamente existen mayores riesgos por temas de sincronización de datos.

VM-Generation ID es un atributo no replicado que se aloja en el objeto “Computer”, de modo tal que puntualmente para Active Directory Domain Services permite al DC detectar cambios y proteger a dicho servicio de eventuales inconsistencias. Con ese identificador, además, se pueden tomar decisiones para que el mismo sistema (sin intervención del administrador) remedie la situación.

Si bien las siguientes consideraciones son aplicables a cualquier sistema distribuido (que en su programación aproveche esta funcionalidad), vamos a puntualizar la semántica de la generación de VM-Generation ID específicamente para Active Directory:

• Si una operación de Virtualización causa un contexto de cambio en Active Directory: el sistema de virtualización debe proveer un nuevo VM-Generation ID.
• Si una operación de Virtualización no causa un contexto de cambio Active Directory: el sistema de virtualizción NO debe proveer un nuevo VM-Generation ID.
• Si no está claro si una operación de virtualización provocará un contexto de cambio en Active Directory: el sistema de virtualización DEBE proveer un nuevo VM-Generation ID.

¿Cómo funciona VM-Generation ID en la “vida real”? Vamos a analizar dos casos muy comunes: el soporte a instantáneas (snapshots) y el soporte a clonación de DCs.

Soporte a Instantáneas (snapshots)

Como ya hemos comentado, Windows Server 2012 da un soporte completo a controladores de dominio virtualizados y, por supuesto, brinda detección y tratamiento en la aplicación de instantáneas.

VM-Generation ID en Active Directory:

• Permite al DC para detectar cambios y proteger Active Directory.
• Es un atributo no replicado alojado en el Objeto “Computer”.

VM-Generation ID en la Replicación:

• El DC compara el VM-Generation ID en NTDS.DIT contra el actual.
• Si es diferente invalida el RID Pool y solicita actualización.

¿Cómo es el proceso? Vamos a verlo con el mismo ejemplo utilizado para instantáneas “pre-Windows Server 2012”:

Si analizamos el timeline de eventos, podemos identificar:

• T1: se crea una instantánea en el DC2. En ese momento el DC1 y DC2 están sincronizados y con una replicación saludable. El valor de USN es de 100.
• T2: Luego de la instantánea, se realiza el alta de 100 usuarios nuevos. Esto lleva el USN a 200 y quita identificadores relativos del pool disponible para dicho DC (DC2).
• T3: Por algún motivo, se vuelve atrás el DC2, puntualmente a la instantánea tomada en T1. Esto hace que el USN vuelva a ser de 100 y el pool de identificadores relativos vuelva a ser el anterior al T2.
• T4: El controlador de dominio detecta que ha sufrido una operación de restauración o rollback de instantánea, por lo cual como mecanismo de protección del servicio de directorio solicita actualizaciones al otro controlador de dominio, de modo tal que el USN y el RID POOL vuelven a ser los esperados. Una vez que esto ocurre, el controlador de dominio tiene datos actualizados y está sanamente operable.

Soporte a Clonación de Controladores de Dominio

Una de las novedades que más pueden ayudarnos a acelerar los procesos de implementación de controladores de dominio es el soporte para clonación.

Este soporte se basa en elegir un controlador de dominio (que no debe ser el PDC Emulator) y configurar diversos parámetros por línea de comandos y en Active Directory. Luego de ello el controlador de dominio puede apagarse y copiar el contenido de su disco virtual a otra máquina virtual. Una vez que la nueva máquina virtual es encendida, se realiza un proceso de verificación comparando si el VM-Generation ID alojado en el BIOS virtual es el mismo o distinto al alojado en el equipo. En caso que no sea el mismo (o sea la máquina fue clonada) comienza el proceso formal de clonación y generalización.

Como resultado de ello, obtendremos un controlador de dominio nuevo, unido al dominio por supuesto, y con los parámetros de nombre, ip y demás configurados previamente en la preparación.

El otro controlador de dominio, que se utilizó como base, detecta esto e inicia normalmente.

Para ser un poquito más gráficos, vamos a describir gráficamente este proceso:

Recordemos que VM-Generation ID es un parámetro que debe estar soportado por el Hypervisor. De tal como que es muy simple comparar que dicho parámetro coincida (o no) con el equipo virtual (valor alojado en el sistema) y el sistema, como en este caso, pueda tomar la decisión de iniciar un clonado.

Si bien este no es un tutorial, vamos a describir brevemente el proceso de clonación:

• Identificar el DC adecuado para clonación.
• Autorizar el DC para clonación agregandolo al grupo “Cloneable Domain Controllers”.
• Correr el CMDLet New-ADDCCloneConfigfile
  • Verifica los pre-requisitos.
  • Verifica la autorización del DC.
  • Permite especificar el Nombre, Dirección IP, Servidores DNS, Sitio, etc.
  • Un ejemplo está proporcionado en: %windir%\system32\SampleDCCloneConfig.xml
• Ejecutar Get-ADDCCloningExcludedApplicationList [-generateXML] para compatibilidad de aplicaciones.
• Apagar y exportar el disco del DC a clonar.
• Iniciar normalmente el otro DC utilizado de base.
• Importar el clon del DC a clonar tantas veces como se desee e iniciar el/los equipos

Debajo vemos un ejemplo del archivo de configuración XML previo al clonado del equipo:

Conclusiones

El soporte completo para virtualización de controladores de dominio (y en el fondo aplicaciones distribuidas) nos brinda un horizonte de posibilidades para aprovechar desde la Administración de Entornos Distribuidos.

Desde el lado de Active Directory Domain Services podemos comenzar a explorarlo y utilizarlo ya. Para el resto de aplicaciones distribuidas, dependerá de cada fabricante el soporte y desarrollo que haga para aprovechar las ventajas de VM-Generation ID.

Con respecto a los virtualizadores o hypervisores, Hyper-V soporta, en su versión 2012 y 2012 R2, VM-Generation ID. VMWare también lo ha soportado en últimas actualizaciones, de modo tal que el mercado está abierto para poder aprovechar estas ventajas.

Esperamos que esta publicación haya servido para introducirse en el soporte de virtualización en Active Directory, y estamos como siempre disponibles ante cualquier duda o consulta. ¡Muchas gracias por visitarnos y leernos!

Referencias y Links

• How to Virtualize Active Directory Domain Controllers (Part 1): http://blogs.technet.com/b/askds/archive/2010/06/10/how-to-virtualize-active-directory-domain-controllers-part-1.aspx
• Deployment Considerations for Virtualized Domain Controllers: http://technet.microsoft.com/en-us/library/dd348449(WS.10).aspx
• USN and USN Rollback: http://technet.microsoft.com/en-us/library/dd348479(WS.10).aspx
• Running Domain Controllers in Hyper-V: http://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-8cd1-5fbaa6740ffe(v=ws.10)
• What’s New in Active Directory Domain Services (AD DS): http://technet.microsoft.com/en-us/library/hh831477.aspx
• Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100): http://technet.microsoft.com/en-us/library/hh831734.aspx
• Windows Server 2012 VM-Generation ID Support in vSphere: http://blogs.vmware.com/apps/2013/01/windows-server-2012-vm-generation-id-support-in-vsphere.html
• Safely Cloning an Active Directory Domain Controller with Windows Server 2012 – Step-by-Step #ws2012 #hyperv #itpro #vmware: http://blogs.technet.com/b/keithmayer/archive/2012/08/06/safely-cloning-an-active-directory-domain-controller-with-windows-server-2012-step-by-step-ws2012-hyperv-itpro-vmware.aspx