====== Validación de la Replicación y Movimiento de Roles FSMO ====== ===== Paso 1: Validar la replicación ===== Primero, asegúrate de que la replicación entre los controladores de dominio esté funcionando correctamente. * **Ejecuta `dcdiag`**: Este comando realiza un diagnóstico completo del controlador de dominio. dcdiag /v /c /d /e /s:DC_NAME - `/v`: Verbose mode (modo detallado). - `/c`: Realiza una verificación exhaustiva. - `/d`: Incluye los eventos de diagnóstico. - `/e`: Realiza pruebas en todos los DCs del bosque. - `/s:DC_NAME`: Especifica el DC a probar. * **Ejecuta `repadmin`**: Este comando te permitirá verificar el estado de la replicación. repadmin /replsummary repadmin /showrepl - `/replsummary`: Muestra un resumen de la replicación. - `/showrepl`: Muestra los detalles de la replicación. Se pueden exportar los GPOs a un archivo html: Get-GPOReport -All -ReportType Html -Path "C:\Temp\All-GPOs.html" Si todo está en orden y no ves errores, puedes proceder con el movimiento de los roles FSMO. ===== Paso 2: Mover los roles FSMO ===== ==== Identifica los roles FSMO ==== Primero, necesitas saber en qué controlador de dominio están actualmente los roles FSMO. netdom query fsmo ==== Mover los roles FSMO ==== Puedes mover los roles usando la consola GUI o comandos PowerShell. === Usando la consola GUI === * **RID, PDC, y Infrastructure**: - Abre "Active Directory Users and Computers". - Haz clic derecho en el dominio y selecciona "Operations Masters". - En cada pestaña (RID, PDC, Infrastructure), selecciona "Change" para mover el rol al nuevo servidor. * **Domain Naming Master**: - Abre "Active Directory Domains and Trusts". - Haz clic derecho en "Active Directory Domains and Trusts" y selecciona "Operations Master". - Haz clic en "Change". * **Schema Master**: - Abre "Active Directory Schema" (necesitarás registrar el `schmmgmt.dll` si no lo has hecho antes). regsvr32 schmmgmt.dll - Abre "MMC" (Microsoft Management Console) y añade el complemento "Active Directory Schema". - Haz clic derecho en "Active Directory Schema" y selecciona "Operations Master". - Haz clic en "Change". === Usando PowerShell === Abre una ventana de PowerShell como administrador y ejecuta los siguientes comandos para mover cada rol FSMO: * **Schema Master**: Move-ADDirectoryServerOperationMasterRole -Identity "Nuevo_DC" -OperationMasterRole SchemaMaster * **Domain Naming Master**: Move-ADDirectoryServerOperationMasterRole -Identity "Nuevo_DC" -OperationMasterRole DomainNamingMaster * **RID Master**: Move-ADDirectoryServerOperationMasterRole -Identity "Nuevo_DC" -OperationMasterRole RIDMaster * **PDC**: Move-ADDirectoryServerOperationMasterRole -Identity "Nuevo_DC" -OperationMasterRole PDCEmulator * **Infrastructure Master**: Move-ADDirectoryServerOperationMasterRole -Identity "Nuevo_DC" -OperationMasterRole InfrastructureMaster ==== Consideración adicional ==== Para mover el Schema Master, necesitas iniciar PowerShell elevado con un usuario que sea Schema Admin. Si usas un usuario Domain Admin, dará un error de acceso denegado. ===== Paso 3: Verificación ===== Después de mover los roles, es importante verificar que todo esté funcionando correctamente. * **Verifica los roles FSMO**: netdom query fsmo * **Ejecuta nuevamente `dcdiag` y `repadmin`** para asegurarte de que la replicación y los roles FSMO estén en orden. ===== Consideraciones finales ===== * **Backups**: Asegúrate de tener backups recientes antes de realizar cualquier cambio. * **Tiempo de inactividad**: Trata de realizar estos cambios fuera del horario de producción para minimizar el impacto. ===== ¿Qué son los roles FSMO? ===== Los roles FSMO (Flexible Single Master Operations) son roles críticos en un dominio de Active Directory. Existen cinco roles FSMO, distribuidos en dos categorías: * **Roles de dominio**: - **PDC Emulator (Emulador de PDC)**: Maneja la sincronización de tiempo y compatibilidad con NT4. - **RID Master (Maestro RID)**: Asigna identificadores únicos (RIDs) a cada objeto creado. - **Infrastructure Master (Maestro de Infraestructura)**: Actualiza referencias de objetos de otros dominios. * **Roles de forest**: - **Schema Master (Maestro de Esquema)**: Controla las actualizaciones y modificaciones del esquema de AD. - **Domain Naming Master (Maestro de Nombres de Dominio)**: Controla la adición y eliminación de dominios en el bosque. ===== Buenas prácticas para FSMO y AD ===== ==== Agrupación de roles FSMO ==== * **Centralización**: Para simplificar la administración y la recuperación ante desastres, agrupa todos los roles FSMO en un solo servidor si tienes una infraestructura pequeña o mediana. * **Distribución**: En infraestructuras más grandes, distribuye los roles FSMO para balancear la carga y aumentar la redundancia. Por ejemplo, podrías mantener los roles de dominio en un DC y los roles de forest en otro. ==== Número de réplicas de controladores de AD ==== * **Redundancia**: Mantén al menos dos controladores de dominio por dominio para garantizar la alta disponibilidad y la redundancia. * **Ubicación**: Coloca controladores de dominio en diferentes ubicaciones físicas, si es posible, para asegurar la continuidad del servicio en caso de fallos en una ubicación. ==== Sucursales con conexiones lentas o intermitentes ==== * **Controlador de dominio adicional**: Considera desplegar un controlador de dominio adicional en la sucursal para que maneje las autenticaciones y solicitudes locales. * **RDP o VDI**: Si la infraestructura lo permite, utiliza escritorios remotos o infraestructura de escritorios virtuales (VDI) para reducir la dependencia de la conexión de red. * **Réplica de sólo lectura (RODC)**: En sucursales con conexiones no confiables, usa un RODC para mejorar la seguridad y el rendimiento de autenticación. ====== Seize de roles FSMO (modo desastre) ====== Cuando un Domain Controller con roles FSMO deja de funcionar y **no es posible hacer un `demote` limpio**, hay que tomar los roles por la fuerza desde otro DC. Esta es la versión *menos agraciada* del traspaso. ===== Pasos ===== ==== 1. Seize de roles FSMO con `ntdsutil` ==== Desde una consola en el nuevo DC que va a tomar los roles (ej: `BIODC01`): ntdsutil roles connections connect to server BIODC01 quit Luego, para cada rol: seize schema master seize naming master seize rid master seize pdc seize infrastructure master Ignore los errores `ldap_modify_sW error 0x34 (...)`, son esperables si el DC original está muerto. Podés verificar qué roles tiene el servidor con: netdom query fsmo ==== 2. Borrar el viejo DC desde Sites and Services ==== dssite.msc Navegar a: ''Sites > Planta > Servers > PDC'' Click derecho sobre `PDC` → **Delete**. Aceptar la eliminación de "NTDS Settings" si lo pide. ==== 3. Limpieza opcional (pero recomendada) con `ntdsutil` ==== ntdsutil metadata cleanup connections connect to server BIODC01 quit select operation target list domains select domain list sites select site list servers in site select server quit remove selected server ==== 4. Borrar registros DNS obsoletos ==== Desde la consola de DNS, revisar las zonas: * `bio4.local` * `_msdcs.bio4.local` Borrar: * Registros A que apunten a `PDC` * Registros de SRV (`_ldap`, `_kerberos`, `_gc`, etc.) * Entradas como Nameserver (NS) que mencionen al viejo DC ==== 5. Verificación final ==== netdom query fsmo repadmin /replsummary dcdiag /v nltest /dclist:bio4.local Si todo se ve bien, podés eliminar o archivar la VM del viejo DC. 💀🧟‍♂️ ===== Comentario ===== Este procedimiento debe usarse **solo si no es posible restaurar ni encender el DC original**. Una vez hecho el `seize`, ese DC **no debe volver a encenderse en la misma red**. Guardar este procedimiento como referencia en caso de futuros eventos catastróficos.