Arquitectura de controladores de dominio virtualizados
Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012.
En este artículo se describe la arquitectura de clonación de controles de dominio virtualizados y la restauración segura. Se mostrarán los procesos de clonación y restauración segura con diagramas de flujo y, después, podrás ver una explicación detallada de todos los pasos del proceso.
Arquitectura de clonación de controles de dominio virtualizados
Arquitectura de restauración segura de controladores de dominio virtualizados
Arquitectura de clonación de controles de dominio virtualizados
Información general
La clonación de controles de dominio virtualizados depende de la plataforma del hipervisor para exponer un identificador llamado identificador de generación de VM a fin de detectar la creación de máquinas virtuales. AD DS almacena inicialmente el valor de este identificador en su base de datos (NTDS.DIT) durante la promoción de controladores de dominio. Cuando se arranca la máquina virtual, el valor actual del identificador de generación de VM de esta se compara con el valor de la base de datos. Si los dos valores son distintos, el controlador de dominio restaurará el identificador de invocación y descartará el grupo RID, lo que evita que USN reutilice o pueda volver a crear entidades de seguridad duplicadas. El controlador de dominio buscará el archivo DCCloneConfig.xml en las ubicaciones invocadas en el paso 3 en Procesamiento detallado de clonación. Si encuentra el archivo DCCloneConfig.xml, asume que se ha implementado como clon, por lo que inicia la clonación para aprovisionarse como controlador de dominio adicional (para ello, se vuelve a promocionar mediante los contenidos de NTDS.DIT y de SYSVOL copiados desde el medio de origen).
En un entorno mixto, donde algunos hipervisores admiten VM-GenerationID y otros no, es posible que se implemente por error un medio clonado en un hipervisor que no admita VM-GenerationID. La presencia del archivo DCCloneConfig.xml indica el intento administrativo de clonar un controlador de dominio (DC). Por tanto, si se encuentra un archivo DCCloneConfig.xml durante el arranque, pero el host no proporciona ningún valor VM-GenerationID, el controlador de dominio clonado se iniciará en el modo de restauración de servicios de directorio (DSRM) para que no afecte al resto del entorno. El medio clonado se puede mover posteriormente a un hipervisor que admita VM-GenerationID y, después, se puede volver a intentar la clonación.
Si el medio clonado se implementa en un hipervisor que admite VM-GenerationID, pero no se proporciona el archivo DCCloneConfig.xml, cuando el controlador de dominio detecta un cambio de VM-GenerationID entre su DIT y el de la nueva VM, activará medidas de seguridad para evitar que se vuelva a usar USN y que se creen SID duplicados. Pero la clonación no se iniciará, por lo que el controlador de dominio secundario sigue en ejecución con la misma identidad que el controlador de dominio de origen. Este DC secundario debe quitarse de la red lo antes posible para evitar incoherencias en el entorno.
Procesamiento detallado de clonación
En el diagrama siguiente puedes ver la arquitectura de una operación de clonación inicial y de una operación de reintento de clonación. Estos procesos se explican con más detalle posteriormente en este tema.
Operación de clonación inicial
Operación de reintento de clonación
En los pasos siguientes se explica el proceso con más detalle:
Un controlador de dominio de máquina virtual existente se inicia en un hipervisor que admite el identificador de generación de VM.
Esta VM no tiene ningún valor de identificador de generación de VM existente establecido en el objeto de equipo de AD DS después de la promoción.
Incluso aunque esté vacío, si vuelve a crearse un equipo, este se clonará, ya que el nuevo identificador de generación de VM no coincidirá.
El identificador de generación de VM se establece después del siguiente reinicio en el controlador de dominio y no se replica.
Después, la máquina virtual lee el identificador de generación de VM proporcionado por el controlador VMGenerationCounter. Compara los dos identificadores de generación de VM.
Si los identificadores coinciden, significa que no se trata de una máquina virtual nueva y, por tanto, no se realizará la clonación. Si existe un archivo DCCloneConfig.xml, el controlador de dominio cambiará el nombre del archivo con una marca de fecha y hora para evitar la clonación. El servidor continuará con el arranque normal. Así funcionan los reinicios de todos los controladores de dominio virtuales en Windows Server 2012.
Si los identificadores no coinciden, significa que se trata de una máquina virtual nueva que contiene un NTDS.DIT de un controlador de dominio anterior (o que es una instantánea restaurada). Si existe el archivo DCCloneConfig.xml, el controlador de dominio realizará las operaciones de clonación. En caso contrario, continuará con las operaciones de restauración de instantánea. Consulta Arquitectura de restauración segura de controladores de dominio virtualizados.
Si el hipervisor no proporciona ningún identificador de generación de VM para compararlo, pero existe un archivo DCCloneConfig.xml, el invitado cambia el nombre del archivo y, después, se inicia en el modo DSRM para evitar que se cree un controlador de dominio duplicado en la red. Si no existe el archivo DCCloneConfig.xml, el invitado se inicia en modo normal (con la posibilidad de que se cree un controlador de dominio duplicado en la red).
El servicio NTDS comprueba el nombre del valor DWORD del Registro VDCisCloning (en HKEY_Local_Machine\System\CurrentControlSet\Services\Ntds\Parameters).
Si no existe, este será un primer intento de clonar la máquina virtual. El invitado implementa las medidas de seguridad de duplicación de objetos de VDC, que consisten en la invalidación del grupo RID local y la configuración de un nuevo identificador de invocación de replicación para el controlador de dominio
Si ya se ha establecido en 0x1, este será un intento de clonación de "reintento"; es decir, cuando no se ha podido completar una operación de clonación anterior. No se toman las medidas de seguridad de duplicación de objetos de VDC, ya que deberían haberse ejecutado anteriormente y esto modificaría varias veces y de manera innecesaria el invitado.
Se escribirá el nombre del valor DWORD del Registro IsClone (en Hkey_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters)
El servicio NTDS cambia la marca de arranque de invitado para que se inicie en el modo de reparación de DS para reinicios posteriores.
El servicio NTDS intenta leer el archivo DcCloneConfig.xml en una de las tres ubicaciones aceptadas (directorio de trabajo de DSA, %windir%\NTDS o medios extraíbles de lectura/escritura, ordenados por letra de unidad, en la raíz de la unidad).
Si el archivo no existe en ninguna ubicación válida, el invitado comprueba que la dirección IP no esté duplicada. Si la dirección IP no está duplicada, el servidor se inicia en modo normal. Si existe una dirección IP duplicada, el equipo se inicia en el modo DSRM para evitar que se cree un controlador de dominio duplicado en la red.
Si el archivo existe en una ubicación válida, el servicio NTDS validará su configuración. Si el archivo está en blanco (o alguna de las opciones está en blanco), NTDS configurará valores automáticos para dichas opciones.
Si existe el archivo DcCloneConfig.xml, pero este contiene entradas no válidas o no se puede leer, la clonación dará error y el invitado se iniciará en el modo de restauración de servicios de directorio (DSRM).
El invitado deshabilita el registro automático de DNS para evitar que pueda modificarse de forma accidental el nombre de equipo y las direcciones IP de origen.
El invitado detiene el servicio de Netlogon para evitar la publicación o respuesta de solicitudes de AD DS de red por parte de clientes.
NTDS comprueba que no haya servicios ni programas instalados que no formen parte de DefaultDCCloneAllowList.xml o de CustomDCCloneAllowList.xml
Si hay servicios o programas instalados que no se especifican en la lista de permitidos de exclusión predeterminada o en la personalizada, la clonación no se completará y el invitado se iniciará en el modo DSRM para evitar que se cree un controlador de dominio duplicado en la red.
Si no existen incompatibilidades, se continuará con la clonación.
Si se usa el direccionamiento IP automático porque la configuración de red del archivo DCCloneConfig.xml está en blanco, el invitado habilitará DHCP en los adaptadores de red para obtener la concesión de dirección IP, el enrutamiento de red e información de resolución de nombres.
El invitado busca y contacta con el controlador de dominio que ejecuta el rol FSMO del emulador de PDC. Este usa DNS y el protocolo DCLocator. Establece una conexión RPC e invoca el método IDL_DRSAddCloneDC para clonar el objeto de equipo del controlador de dominio.
Si el objeto de equipo de origen del invitado tiene el permiso extendido de encabezado de dominio “Permitir a un DC crear un clon de sí mismo”, se continuará con la clonación.
Si el objeto de equipo de origen del invitado no tiene ese permiso extendido, se produce un error en la clonación y el invitado se inicia en el modo DSRM para evitar que se cree un controlador de dominio duplicado en la red.
El nombre de objeto de equipo de AD DS se establece para que coincida con el nombre especificado en el archivo DCCloneConfig.xml (si existe); en caso contrario, se genera automáticamente en el PDCE. NTDS crea la opción de NTDS correcta para el sitio lógico apropiado de Active Directory.
En el caso de una clonación de PDC, el invitado cambiará el nombre del equipo local y se reiniciará. Después del reinicio, volverá a completar los pasos del 1 al 10 y, después, continuará con el paso 13.
Si esto es una clonación de controlador de dominio de réplica, no se reiniciará en esta fase.
El invitado proporciona la configuración de promoción al servicio de servidor de roles de DS, que iniciará la promoción.
El servicio de servidor de roles de DS detendrá todos los servicios relacionados con AD DS (NTDS, NTFRS/DFSR, KDC, DNS).
El invitado forzará la sincronización de hora de NT5DS (NTP de Windows) con otro controlador de dominio (en una jerarquía de Servicio de hora de Windows, se usará el PDCE). El invitado contactará con el PDCE. Se eliminarán todos los vales de Kerberos existentes.
El invitado configura los servicios DFSR o NTFRS para que se ejecuten automáticamente. El invitado elimina todos los archivos de bases de datos de DFSR y de NTFRS existentes (valor predeterminado: c:\windows\ntfrs y c:\system volume information\dfsr\<GUID_de_base_de_datos>) para forzar la sincronización no autoritativa de SYSVOL cuando vuelva a iniciarse el servicio. El invitado no elimina el contenido de los archivos de SYSVOL para preinicializar el SYSVOL cuando se inicie posteriormente la sincronización.
Se cambiará el nombre del invitado. El servicio de servidor de roles de DS en el invitado comenzará la configuración de AD DS (promoción) con el archivo de base de datos NTDS.DIT existente como origen, en lugar de la base de datos de plantilla incluida en c:\windows\system32, como suele hacerse en una promoción.
El invitado contacta con el propietario del rol FSMO para obtener una nueva asignación de grupo RID.
El proceso de promoción crea un nuevo identificador de invocación y vuelve a crear el objeto de configuración de NTDS para el controlador de dominio clonado (independientemente de la clonación, esto forma parte de la promoción de dominios al usar una base de datos NTDS.DIT existente).
NTDS se replica en objetos no encontrados, más nuevos o que tienen una versión superior de un controlador de dominio asociado. El archivo NTDS.DIT ya contiene objetos del momento en que el controlador de dominio de origen estaba sin conexión, y estos se usarán como objetos posibles para reducir la entrada de tráfico de replicación. Se rellenan las particiones del catálogo global.
Se inicia el servicio DFSR o FRS y, como no existe ninguna base de datos, SYSVOL sincroniza de forma no autoritativa la entrada desde un asociado de replicación. Este proceso reutiliza datos existentes en la carpeta SYSVOL para reducir el tráfico de replicación en la red.
El invitado vuelve a habilitar el registro del cliente DNS ahora que el equipo tiene un nombre único y está conectado a la red.
El invitado ejecuta los módulos de SYSPREP especificados en el elemento <SysprepInformation> del archivo DefaultDCCloneAllowList.xml para eliminar los datos de referencias al nombre de equipo y el SID anteriores.
Se completa la promoción de la clonación.
El invitado elimina la marca de arranque de DSRM para que el siguiente reinicio se realice en el modo normal.
El invitado cambia el nombre del archivo DCCloneConfig.xml (anexa una marca de fecha y hora) para que no vuelva a leerse en el siguiente arranque.
El invitado elimina el valor DWORD del Registro VdcIsCloning en HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters.
El invitado establece en 0x1 el valor DWORD del Registro “VdcCloningDone” en HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters. Windows no usa este valor, sino que lo proporciona como un marcador para terceros.
El invitado actualiza el atributo msDS-GenerationID en su propio objeto de controlador de dominio clonado para que coincida con el identificador de generación de VM actual del invitado.
Se reinicia el invitado. Ahora es un controlador de dominio de publicación normal.
Arquitectura de restauración segura de controladores de dominio virtualizados
Información general
AD DS depende de la plataforma del hipervisor para exponer un identificador llamado identificador de generación de VM a fin de detectar la restauración de instantáneas de máquinas virtuales. AD DS almacena inicialmente el valor de este identificador en su base de datos (NTDS.DIT) durante la promoción de controladores de dominio. Cuando un administrador restaura una máquina virtual a partir de una instantánea anterior, el valor actual del identificador de generación de VM de esta se compara con el valor de la base de datos. Si los dos valores son distintos, el controlador de dominio restaurará el identificador de invocación y descartará el grupo RID, lo que evita que USN reutilice o pueda volver a crear entidades de seguridad duplicadas. Existen dos escenarios en los que se puede producir una restauración segura:
Cuando se inicia un controlador de dominio virtual después de restaurar una instantánea cuando esta estaba apagada
Cuando se restaura una instantánea en un controlador de dominio virtual en ejecución
Si el controlador de dominio virtualizado en la instantánea se encuentra en estado suspendido, en lugar de apagado, tendrás que reiniciar el servicio AD DS para activar una nueva solicitud de grupo RID. Puedes reiniciar el servicio AD DS mediante el complemento Servicios o mediante Windows PowerShell (Restart-Service NTDS -force).
En las secciones siguientes se explica en detalle la restauración segura para cada escenario.
Procesamiento detallado de restauración segura
En el diagrama de flujo siguiente puedes ver cómo se produce una restauración segura cuando se inicia un controlador de dominio virtual después de restaurar una instantánea cuando esta estaba apagada.
Cuando se inicia la máquina virtual después de una restauración de instantánea, tendrá un nuevo identificador de generación de VM proporcionado por el host del hipervisor debido a la restauración de la instantánea.
El nuevo identificador de generación de la máquina virtual se compara con el identificador de generación de VM de la base de datos. Como los dos identificadores no coinciden, usa medidas de seguridad de virtualización (vea el paso 3 de la sección anterior). Cuando se termine de aplicar la restauración, se actualizará el VM-GenerationID establecido en el objeto de equipo de AD DS para que coincida con el nuevo identificador proporcionado por el host del hipervisor.
El invitado usa medidas de seguridad de virtualización para:
Invalidar el grupo RID local.
Establecer un nuevo identificador de invocación para la base de datos del controlador de dominio.
Nota
Esta parte de la restauración segura se superpone con el proceso de clonación. Aunque este proceso trata sobre la restauración segura de un controlador de dominio virtual después de arrancar una restauración de instantánea, también se realizan los mismos pasos durante el proceso de clonación.
En el diagrama siguiente se muestra cómo las medidas de seguridad de virtualización evitan la divergencia inducida por la reversión de USN cuando se restaura una instantánea en un controlador de dominio virtual en ejecución.
Nota:
La ilustración anterior se ha simplificado para explicar los conceptos.
En la hora T1, el administrador del hipervisor realiza un instantánea del DC1 virtual. En ese momento, DC1 tiene un valor USN (highestCommittedUsn, en un caso real) de 100, InvocationId (representado como el identificador en el diagrama anterior) tiene un valor de A (en un caso real, esto sería el GUID). El valor de savedVMGID es el VM-GenerationID en el archivo DIT del DC (almacenado para el objeto de equipo del DC en un atributo llamado msDS-GenerationId). El VMGID es el valor actual del VM-GenerationID obtenido por el controlador de la máquina virtual. Este valor es proporcionado por el hipervisor.
Posteriormente, en T2, se agregan 100 usuarios a este DC (esto es tan solo un ejemplo de las actualizaciones que podrían realizarse en este DC entre T1 y T2; estas actualizaciones podrían ser una combinación de creación de usuarios, creación de grupos, actualizaciones de contraseña, actualizaciones de atributos, etc.). En este ejemplo, cada actualización consume un USN único (aunque, en la práctica, la creación de un usuario podría consumir más de un USN). Antes de aplicar estas actualizaciones, DC1 comprueba si el valor de VM-GenerationID de la base de datos (savedVMGID) coincide con el valor actual disponible en el controlador (VMGID). Coinciden, ya que no se ha realizado ninguna reversión, por lo que se aplican las actualizaciones y USN sube hasta 200, lo que indica que en la siguiente actualización se puede usar el USN 201. No se producen cambios en InvocationId, savedVMGID ni VMGID. Estas actualizaciones se replican en DC2 en el siguiente ciclo de replicación. DC2 actualiza su límite máximo (y UptoDatenessVector), que aquí se representa simplemente como DC1(A) @USN = 200. Es decir, que DC2 conoce todas las actualizaciones de DC1 en el contexto de InvocationId A hasta USN 200.
En T3, se aplica en DC1 la instantánea realizada en T1. DC1 se ha revertido, por lo que su USN se revierte a 100, lo que indica que podría usar USN a partir del 101 para asociarlos con próximas actualizaciones. Sin embargo, en este punto, el valor de VMGID sería distinto en hipervisores que admitan el VM-GenerationID.
Como consecuencia, cuando DC1 realice una actualización, comprobará si el valor de VM-GenerationId que contiene su base de datos (savedVMGID) coincide con el valor del controlador de la máquina virtual (VMGID). En este caso no es el mismo, por lo que DC1 detecta esto como una reversión y activa las medidas de seguridad de virtualización; es decir, restablece su valor InvocationId (Id. = B) y descarta el grupo RID (que no se muestra en el diagrama anterior). Después, guarda el nuevo valor de VMGID en su base de datos y aplica las actualizaciones (USN 101 - 250) en el contexto del nuevo InvocationId B. Cuando se produzca el siguiente ciclo de replicación, DC2 no conocerá nada de DC1 en el contexto de InvocationId B, por lo que pedirá toda la información de DC1 que esté asociada al InvocationID B. Como resultado, las actualizaciones realizadas en DC1 después de la aplicación de la instantánea convergirán de forma segura. Además, el conjunto de actualizaciones que se realizó en DC1 en T2 (que se perdieron en DC1 después de restaurar la instantánea) se volverían a replicar en DC1 en la siguiente replicación programada, ya que se replicaron a DC2 (como indica la línea de puntos que vuelve a DC1).
Después de que el invitado use las medidas de seguridad de virtualización, NTDS replica las diferencias del objeto de Active Directory de entrada de forma no autoritativa desde un controlador de dominio asociado. Como resultado, se actualiza el vector de actualización del servicio de directorio de destino. Después, el invitado sincroniza SYSVOL:
Si se usa FRS, el invitado detiene el servicio NTFRS y establece el valor del Registro BURFLAGS de D2. Después, inicia el servicio NTFRS que, de forma no autoritativa, realiza una replicación entrante y, siempre que sea posible, vuelve a usar los datos de SYSVOL no modificados.
Si se usa DFRS, el invitado detiene el servicio DFSR y elimina los archivos de bases de datos de DFSR (ubicación predeterminada: %systemroot%\system volume information\dfsr\<database GUID>). Después, inicia el servicio DFSR que, de forma no autoritativa, realiza una replicación entrante y, siempre que sea posible, vuelve a usar los datos de SYSVOL no modificados.
Nota
- Si el hipervisor no proporciona ningún identificador de generación de VM para poder compararlo, no admitirá las medidas de seguridad de virtualización y el invitado funcionará como un controlador de dominio virtualizado que ejecuta Windows Server 2008 R2 o anterior. El invitado implementa la protección de cuarentena de reversión de USN si se intenta iniciar una replicación con unos USN no superiores a los últimos USN detectados por el DC asociado. Para obtener más información sobre la protección de cuarentena de la reversión de USN, consulta USN y reversión de USN