Comprender los roles FSMO en Active Directory

Si su organización funciona con Microsoft Active Directory, depende de uno o más controladores de dominio para mantener las operaciones de AD en marcha. En la superficie, Active Directory parece funcionar en un modelo de igual a igual en el que cada controlador de dominio (DC) tiene la autoridad para crear, modificar y eliminar objetos de AD. Esto se debe a que cada controlador de dominio contiene una copia editable de la partición de su dominio, siendo la única excepción los DC de solo lectura. Una vez que se realizan cambios o adiciones, se sincronizan con otros DC a través de la replicación multi-maestro. Sin embargo, algunas operaciones cruciales están limitadas a ciertos DC que se les asignan roles especiales conocidos como roles de Operaciones de Maestro Único Flexible (FSMO) o roles de maestro de operación.

A continuación, detallamos la importancia de los roles FSMO en Active Directory y compartimos algunas de las mejores prácticas para garantizar una gestión y protección efectivas.

Introducción a los roles FSMO

FSMO significa Operaciones de Maestro Único Flexible, un término que se originó a partir del trabajo de Microsoft para abordar las limitaciones del modelo de replicación multi-maestro en AD. Los roles FSMO aseguran el funcionamiento y la consistencia del Active Directory a través de un dominio de Windows al asignar una tarea crítica específica a controladores designados y proporcionar un proceso de cambio de autoridad único. Al centralizar estas operaciones dentro de controladores de dominio específicos, los roles FSMO ayudan a mantener la integridad y estabilidad de los entornos de Active Directory.

Hay cinco roles únicos de FSMO. Por defecto, cuando creas un dominio de Active Directory, todos los roles FSMO se asignan al primer controlador de dominio en el bosque. Los administradores de dominio pueden reasignar los roles FSMO a otros controladores de dominio si es necesario.

La necesidad de los roles FSMO

Antes de adentrarnos en los roles FSMO propiamente dichos, es importante comprender la arquitectura multi-maestro que crea la necesidad de los mismos.

Modelo multi-master frente a modelo single-master

La arquitectura de red inicial de Microsoft se construyó sobre un Modelo de Único Maestro en el que un solo servidor contenía la copia editable de la base de datos con todas las cuentas de objetos de usuario y computadora. Este servidor era el único responsable de realizar adiciones o modificaciones en la base de datos de cuentas. Otros servidores en la red mantenían copias de solo lectura de la base de datos. Aunque estos servidores podían autenticar usuarios, no podían cambiar la base de datos. Si el maestro se desconectaba o funcionaba mal, no se podían crear cuentas nuevas y las cuentas existentes no podían ser modificadas. Esto creaba un único punto de fallo.

Para abordar las limitaciones del Modelo de Único Maestro, Microsoft realizó la transición a un Modelo de Múltiples Maestros en Active Directory (AD), donde cada controlador de dominio (DC) mantiene una copia editable de la base de datos de cuentas. Este diseño asegura redundancia y resiliencia, ya que las operaciones pueden continuar incluso si un DC se vuelve no disponible. Sin embargo, este enfoque de múltiples maestros introdujo el potencial de conflictos, donde diferentes DCs podrían intentar realizar cambios en conflicto simultáneamente. Para prevenir tales inconsistencias y mantener la integridad y el rendimiento de AD, Microsoft introdujo los roles de Flexible Single Master Operations (FSMO).

Importancia de los roles FSMO en AD

Al asignar roles FSMO, Active Directory asegura que operaciones esenciales—como actualizaciones al esquema, nombramiento de dominio y sincronización de tiempo—se manejen de manera ordenada y consistente. Si el DC que sostiene un rol FSMO específico se cae, el rol puede ser transferido a otro DC, asegurando la continuidad. La distribución de roles FSMO es crucial para mantener una red equilibrada y eficiente, y las organizaciones pueden personalizar esta distribución basándose en sus necesidades específicas y las mejores prácticas para rendimiento y redundancia.

Las 5 funciones FSMO de Active Directory explicadas

Active Directory tiene cinco roles FSMO únicos:

• Schema Master (nivel de bosque)
• Maestro de Nombres de Dominio (nivel de bosque)
• Maestro de ID relativo (RID) (nivel de dominio)
• Emulador del Controlador de Dominio Primario (PDC) (nivel de dominio)
• Infrastructure Master (nivel de dominio)

Aprendamos más sobre cada rol FSMO y su función específica dentro de la infraestructura de Active Directory:

Maestro de Esquema

¿Qué es el rol FSMO de maestro de esquema?

El Schema Master es un rol FSMO a nivel empresarial, por lo que solo hay un Schema Master en un Bosque de Active Directory. El esquema define las clases de objetos (tipos de objetos, como usuarios, grupos y computadoras) y sus atributos que pueden existir en la base de datos de AD database.

Cuándo y cómo se utiliza el maestro de esquema

A veces, es necesario cambiar el esquema, por ejemplo, para agregar un nuevo tipo de objeto o atributo requerido. Para evitar actualizaciones superpuestas o conflictivas, solo el DC con el rol de Schema Master puede procesar cambios en el esquema de AD. Siempre que se realiza una actualización de esquema, el Schema Master asegura que los cambios se repliquen en todos los demás DCs del bosque.

Si se requiere una actualización de esquema, el Schema Master debe estar disponible. Sin embargo, los cambios de esquema son relativamente infrecuentes en la mayoría de los entornos. Las circunstancias que pueden requerir un cambio de esquema incluyen la actualización de Active Directory, la integración de ciertos tipos de software empresarial, elevar el nivel funcional del bosque y actualizar el sistema operativo de un DC a una versión más alta que la que actualmente existe en el bosque.

Maestro de Nombres de Dominio

Roles y responsabilidades del Domain Naming Master

El Domain Naming Master es un rol a nivel empresarial; solo hay un Domain Naming Master en un Bosque de Active Directory. Es el único DC capaz de agregar nuevos dominios y particiones de aplicación al bosque o eliminar los existentes del bosque.

Escenarios comunes que involucran Domain Naming Master

Puede que necesite modificar su bosque de AD a medida que su negocio evoluciona, o se pueden agregar dominios adicionales a su bosque debido a una fusión o adquisición. Dado que la adición y eliminación de dominios y particiones son operaciones poco frecuentes y raramente críticas en tiempo, el rol de Domain Naming Master tiene poca carga de trabajo, y se espera que su pérdida tenga poco o ningún impacto operativo.

RID Master

¿Qué es el rol de RID Master?

El Relative Identifier Master (RID Master) es un rol a nivel de dominio; hay un RID Master en cada dominio de un bosque de AD. Es responsable de asignar los grupos de RID a los DCs en el orden de su dominio para garantizar que cada principal de seguridad (como un usuario o grupo) tenga un identificador de seguridad único.

Un (SID) es una cadena alfanumérica de longitud variable que se ve así:

      `S-1-5-21-1234567890-1234567890-1234567890-1001`
      

La primera parte de la cadena es el SID del dominio, que es el mismo para todos los SIDs en un dominio. La última parte es el RID, que es único para cada SID en el dominio. En el ejemplo anterior, 1001 es el RID asignado a un principal de seguridad específico en el dominio.

Funcionalidad y uso del RID Master

El RID Master asigna grupos de RID a los DCs. Cada grupo consta de un rango único y contiguo de RIDs, que el DC puede utilizar para generar un SID único cuando crea un principal de seguridad. Al gestionar centralmente la distribución de RIDs, el RID Master garantiza que ningún controlador de dominio asigne el mismo RID a diferentes principales de seguridad, asegurando la unicidad de cada SID dentro del dominio.

Una vez que a un DC se le asigna un grupo de RID del RID Master, no necesita comunicarse con el RID Master cada vez que crea un objeto de AD. Sin embargo, perder el RID Master de un dominio eventualmente llevará a la incapacidad de crear nuevos objetos en el dominio ya que los grupos en los DCs se agotarán. En entornos de AD maduros, esto tomaría un tiempo considerable ya que se crean relativamente pocos objetos.

Generalmente, el rol de RID Master se asigna al controlador de dominio principal (PDC) en un dominio porque el PDC normalmente recibe la mayor atención de los administradores y, por lo tanto, tiene alta disponibilidad. En dominios maduros, la sobrecarga generada por el rol de RID Master es insignificante. Aunque este rol no es tan crítico como algunos de los otros roles, sigue siendo importante asegurar la conectividad con el RID Master.

PDC Emulator (PDCE)

Comprender el rol del Emulador PDC: explicación e historia

El Controlador de Dominio Primario (PDC) es un término de los tiempos de Windows NT, cuando un único DC tenía una copia editable del directorio. Hoy en día, la mayoría de los DCs en un dominio son editables, pero todavía hay un DC designado que emula el rol de un PDC. Cada dominio en un Bosque de Active Directory contiene un DC con el rol de PDCE.

Las funciones de PDC Emulator en AD

El Emulador del Controlador de Dominio Primario es responsable de lo siguiente:

• Sincronización de tiempo — El PDCE es la fuente autorizada de tiempo para el dominio; todas las estaciones de trabajo y servidores miembros sincronizan su tiempo con el emulador de PDC. En un bosque con múltiples dominios, el PDCE en el dominio raíz del bosque es el guardián del tiempo para todos los demás emuladores de PDC en el bosque. Para mantener una cronometría precisa en todo el bosque, el emulador de PDC en el dominio raíz debe configurarse para sincronizarse con una fuente de tiempo externa confiable. El tiempo es un asunto muy importante. Por ejemplo, la autenticación Kerberos fallará si la diferencia entre el reloj de un host solicitante y el reloj del DC autenticador supera el máximo especificado (5 minutos por defecto); esto ayuda a contrarrestar ciertas actividades maliciosas, como los ataques de repetición.
• Cambios de contraseña y autenticación—Cuando se cambia la contraseña de un usuario, el cambio se realiza inicialmente en el DC que autenticó al usuario. Esta actualización de contraseña comprometida se replica inmediatamente al PDCE del dominio. Si una cuenta intenta autenticarse contra un DC que aún no ha recibido un cambio de contraseña reciente a través de la replicación programada, la solicitud se pasa al PDCE del dominio, que procesará la solicitud de autenticación e instruirá al DC solicitante a aceptarla o rechazarla. Este comportamiento asegura que las contraseñas puedan procesarse de manera confiable incluso si los cambios recientes no se han propagado completamente a través de la replicación programada.
• Estado de bloqueo de cuenta — De manera similar, si una cuenta se bloquea debido a múltiples intentos fallidos de inicio de sesión, el bloqueo se procesa de inmediato en el emulador PDC, y el estado de bloqueo se replica en todos los DCs del dominio para asegurar que una cuenta bloqueada no pueda iniciar sesión en otro DC. Cuando un administrador desbloquea una cuenta, ese cambio se replica inmediatamente a través del dominio.
• Actualizaciones de Directiva de grupo — Si se realizan actualizaciones a un objeto de Group Policy (GPO), inicialmente se confirman en el DC con el rol de Emulador PDC. Esto previene conflictos de versiones que podrían ocurrir si un GPO fuera modificado en dos DCs aproximadamente al mismo tiempo.
• Compatibilidad hacia atrás — En organizaciones que aún cuentan con dispositivos o software heredados que dependen de Windows NT, el emulador PDCE puede funcionar como un PDC. Esto incluye actuar como el Master Browser, que recopila y distribuye información sobre aplicaciones y dispositivos en una red.
• Sistema de archivos distribuidos (DSF) — Por defecto, los servidores raíz DFS solicitarán periódicamente información actualizada del espacio de nombres DFS del PDCE. Este comportamiento puede provocar cuellos de botella de recursos, pero habilitar el Dfsutil.exe RootScalability parameter permitirá que los servidores raíz DFS soliciten actualizaciones del DC más cercano.

El rol de Emulador PDC debe colocarse en un DC altamente accesible, bien conectado y de alto rendimiento, ya que la pérdida del DC con este rol puede tener un impacto inmediato y significativo en las operaciones.

Maestro de infraestructura

Función del Infrastructure Master FSMO

El Infrastructure Master es un rol a nivel de dominio cuya función principal es manejar las referencias de objetos entre dominios en un bosque multi-dominio. El Infrastructure Master compara objetos en su dominio contra objetos en otros dominios en el mismo bosque y los sincroniza con los servidores de global catalog.

Cuándo y por qué se necesita Infrastructure Master

Estas acciones no son necesarias en ciertos casos. Obviamente, en entornos con solo un AD domain, no hay referencias cruzadas de dominio que manejar. Y si todos los DCs en un dominio son anfitriones de global catalog (lo cual es común hoy en día debido al mejor ancho de banda de red), todos tendrán información actualizada sin depender del Infrastructure Master.

El Infrastructure Master tiene asignadas las siguientes responsabilidades:

• Referencias cruzadas de objetos entre dominios — En un bosque con múltiples dominios, los objetos de un dominio pueden ser referenciados en otro dominio. Un ejemplo típico es cuando a un usuario de un dominio se le agrega a un grupo de seguridad en otro dominio. En este escenario, se crea un marcador de posición (llamado un “objeto fantasma”) en el dominio del grupo para representar al usuario del otro dominio. Los objetos fantasma rastrean y gestionan referencias persistentes a objetos eliminados y atributos de valor de enlace que se refieren a objetos en otro dominio del bosque.
• Actualizando referencias de grupo a usuario —El Infrastructure Master es responsable de actualizar el SID de un objeto y el nombre distinguido (DN) en una referencia de objeto entre dominios y de traducir GUIDs, SIDs y DNs entre dominios en un bosque.
• Limpieza de objetos obsoletos — El Infrastructure Master verifica regularmente su dominio en busca de objetos que ya no son válidos (como objetos de confianzas eliminadas) y los elimina.

Si un DC con el rol de Infrastructure Master falla, el impacto es principalmente administrativo. Aunque los nombres de enlaces de objetos entre dominios podrían no resolverse correctamente durante su ausencia, las membresías de grupos entre dominios seguirán funcionando.

Roles FSMO en contextos de bosque y dominio

Roles FSMO a nivel de bosque

Como puede ver en la lista anterior, los dos últimos roles FSMO operan en todo el bosque, lo que significa que solo un DC en el bosque puede ser el titular del rol. En otras palabras, cada Active Directory Forest tiene un único Schema Master y un único Domain Naming Master.

Roles FSMO a nivel de dominio

Los otros tres roles FSMO operan dentro de la jurisdicción de un único dominio. En cada dominio, hay un Maestro de Infraestructura, un Maestro RID y un Emulador de PDC. Cada dominio alojará estos tres roles FSMO en entornos con múltiples dominios en uno o más DCs.

Gestión de roles FSMO

Identificación de los titulares de roles FSMO

Saber cuáles DCs en su entorno de AD albergan los 5 roles FSMO es importante. Hay múltiples maneras de identificar los DCs que poseen los roles FSMO. Una forma rápida es utilizando el símbolo del sistema con el siguiente comando:

      netdom query fsmo /domain:<DomainName>
      

Aquí hay un ejemplo:

También puedes utilizar PowerShell usando el siguiente script:

      (Get-ADForest).Domains |

ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `

Select-Object Domain, HostName, OperationMasterRoles
      

Aquí hay un ejemplo a continuación utilizando PowerShell:

También puede encontrar qué DC están asignados a los roles FSMO utilizando las herramientas de Active Directory Tools. Usando Active Directory Users and Computers, haga clic derecho en su dominio y seleccione Maestros de operaciones como se muestra a continuación:

Luego haga clic en cada pestaña para encontrar los tres FSMOs de dominio.

You can use Active Directory Domains and Trusts to find which DC holds the Domain Naming Master role by right-clicking on Active Directory Domains and Trust and then selecting Operations Master, as shown below.

Lo que a continuación mostrará el siguiente mensaje emergente para identificar al actual titular del rol.

El proceso para identificar el FSMO del Schema Master es un poco más complejo. Puedes encontrar su identidad utilizando el complemento de Active Directory Schema, sin embargo, el complemento no aparece por defecto en Windows Server. Para acceder a él necesitas registrarlo usando el archivo Schmmgmt.dll. Para hacer esto, haz clic en Inicio > Ejecutar, y escribe regsvr32 schmmgmt.dll en el cuadro Abrir. Luego haz clic en Aceptar como se muestra a continuación.

Una vez registrado con éxito, necesita hacer lo siguiente:

1. En el menú de la consola, haga clic en Add/Remove Snap-in, haga clic en Agregar, haga doble clic en Esquema de Active Directory, haga clic en Cerrar y luego en Aceptar.
2. Haga clic con el botón derecho en Active Directory Schema en el panel superior izquierdo y luego haga clic en Operations Masters para ver el servidor que tiene el rol de maestro de esquema.

Se muestra un ejemplo en la captura de pantalla a continuación:

Esto le dará acceso al complemento desde el cual puede hacer clic derecho en Active Directory Schema y elegir Operations Master.

Transferencia y toma de roles FSMO

Cuándo y cómo transferir los Roles FSMO

Aunque Active Directory asignará automáticamente los roles FSMO a sus DCs, hay ocasiones en las que puede querer transferir un rol a otro DC. Por ejemplo, puede necesitar apagar un DC para mantenimiento que actualmente tiene asignado un rol. Tanto los administradores de dominio como los de empresa tienen la discreción de mover estos roles entre controladores de dominio según sea necesario.

Apropiándose de los roles FSMO

Para las transferencias de roles FSMO, tanto el poseedor actual como los roles del controlador de dominio objetivo deben estar activos y conectados a la red. Si el poseedor actual del rol FSMO no está disponible y no puede ser restaurado, un administrador de dominio o de empresa necesitará tomar control del rol. Dado que esta es una acción más abrupta, la toma de control de un rol FSMO solo debe realizarse cuando sea necesario.

Mejores prácticas y resolución de problemas

Optimización de la colocación de roles FSMO para una mayor eficiencia

Aunque no hay reglas estrictas y rápidas con respecto a la colocación de FSMO dentro de Active Directory, las siguientes recomendaciones te proporcionarán los mejores resultados:

• Coloque el Emulador PDC y el Maestro RID en un controlador de dominio confiable con buena conectividad, que esté fácilmente disponible para otros controladores de dominio, ya que sus roles son críticos para las actividades diarias de Active Directory.
• Si es posible, el Infrastructure Master no debe colocarse en un servidor de catálogo global. Esto no es posible, por supuesto, si todos los DCs son servidores de catálogo global.
• Coloque los dos roles del lado del bosque (Schema Master y Domain Naming Master) en el mismo DC, ya que no se utilizan muy a menudo.

Problemas comunes y soluciones

Existen algunas instancias clave que podrían indicar que un FSMO no está disponible. Por ejemplo, cualquier intento de actualizar el esquema de AD resultará en un error si el Schema Master está inactivo. También será imposible agregar o eliminar dominios en el bosque si el Domain Naming Master no es accesible. En estas circunstancias, necesitas confirmar qué DC tiene ese rol y verificar que esté accesible.

La incapacidad de acceder a un DC con un rol FSMO asignado puede resultar de múltiples factores, incluyendo:

• El servidor está fuera de línea o apagado
• Problemas de conectividad de red
• Errores o fallos en la configuración de DNS

La resolución de estos problemas puede requerir que utilices herramientas de diagnóstico de red para verificar la conectividad en toda la red, verificar la configuración de DNS incluyendo los registros SRV y asegurar la salud física y lógica del servidor que tiene el rol FSMO. Si el problema persiste, considera transferir el rol a otro DC saludable o, como último recurso, tomar el rol si el titular actual está permanentemente indisponible.

Monitoreo y auditoría de roles FSMO

Debido a que estos roles FSMO son tan críticos, deberías monitorear regularmente los servidores que contienen estos roles. A un nivel muy básico, puedes verificar los registros de eventos en tus controladores de dominio. Eventos específicos pueden indicar cuándo los roles FSMO fueron transferidos o tomados por la fuerza. Tu organización también puede utilizar software de monitoreo o gestión que podría tener datos históricos o alertas relacionadas con cambios en los roles FSMO. También existen herramientas de terceros que ofrecen mucha más funcionalidad. Un ejemplo es Netwrix Auditor for Active Directory automatiza el monitoreo de los roles FSMO y puede alertarte sobre cualquier cambio sospechoso o imprevisto. También se considera una mejor práctica documentar cuándo tienen lugar estos cambios de rol FSMO para que este tipo de historial pueda ser accedido si es necesario.

Cómo Netwrix puede ayudar

Como hemos visto, los roles FSMO son importantes tanto para la continuidad del negocio como para la seguridad. Por lo tanto, es vital auditar todos los cambios en sus roles FSMO. Netwrix Auditor for Active Directory automatiza este monitoreo y puede alertarlo sobre cualquier cambio sospechoso para que pueda actuar antes de que provoque tiempo de inactividad o una data breach.

Por supuesto, proteger los roles FSMO es solo una parte de una estrategia de seguridad. Netwrix Auditor for Active Directory ofrece una visibilidad y control completos sobre los sistemas centrales que necesita. Monitorea y analiza continuamente los cambios y otras actividades en Active Directory para detectar amenazas emergentes y le empodera para responder de manera rápida y efectiva para minimizar el impacto en los procesos de negocio, la productividad de los usuarios y la seguridad.

Conclusión

Los roles FSMO en AD son un ejemplo de cuánto ocurre bajo la superficie. Aunque los roles FSMO a nivel de bosque pueden no ser críticos todos los días, su negocio sí depende de sus roles y servicios FSMO de dominio. Además de la amenaza de fallos esperados que ocurren periódicamente, estos roles son objetivos ideales para actores de amenazas maliciosos que buscan interrumpir las operaciones comerciales. Esto significa que necesita visibilidad en las complejidades de su entorno de AD.

Los equipos de soporte de AD están adoptando cada vez más herramientas de monitoreo automatizadas para abordar estos desafíos. Estas soluciones pueden proporcionar:

• Mejor visibilidad del estado y rendimiento de los poseedores de roles FSMO
• Alertas en tiempo real sobre cualquier cambio o anomalía en las asignaciones de roles FSMO
• Identificación proactiva de posibles problemas antes de que puedan escalar
• Amplias capacidades de auditoría que pueden rastrear cambios históricos.

Este enfoque proactivo puede ayudar a los administradores de AD a mantener la salud y estabilidad de una infraestructura de AD y fortalecer la postura de seguridad general de la organización.

FAQ

¿Qué es FSMO?

FSMO significa Operaciones de Maestro Único Flexible. Estas operaciones son responsabilidades especiales asignadas a controladores de dominio específicos para prevenir conflictos y asegurar el funcionamiento fluido de la red.

¿Qué son FSMO y sus roles?

Active Directory se basa en un modelo multi-master en el que FSMO asigna autoridad designada a controladores de dominio designados.

¿Cuáles son los 5 roles FSMO y cómo verificarías los titulares de los roles?

Los 5 roles FSMO son los siguientes:

• Schema Master: Responsable de las actualizaciones al esquema de AD.
• Domain Naming Master: Controla la adición o eliminación de dominios en el bosque.
• RID (Relative ID) Master: Asigna grupos de RID a los DCs para crear identificadores de seguridad únicos (SIDs).
• Emulador de PDC (Controlador de Dominio Primario): Este maneja los cambios de contraseña y la sincronización de tiempo y actúa como respaldo para ciertos tipos de autenticación.
• Infrastructure Master: Administra referencias a objetos en otros dominios

Usando herramientas estándar de Active Directory y PowerShell, puede averiguar cuáles controladores de dominio son los poseedores de estos FSMOs.

¿Dónde se encuentran los roles FSMO?

De forma predeterminada, el primer controlador de dominio del dominio raíz de un Bosque de Active Directory alberga el Maestro de Esquema y el Maestro de Nombres de Dominio. El primer controlador de dominio de cada dominio alberga el Emulador de PDC, Maestro RID y Maestro de Infraestructura. Los administradores de Active Directory pueden trasladar estos roles a otros DC si así lo desean.

¿Por qué tomamos los roles FSMO?

Si un controlador de dominio se desconecta repentinamente, su rol FSMO se vuelve inaccesible. No es posible realizar una transferencia de rol si no hay conectividad con el titular original del rol. En ese caso, el rol tendrá que ser tomado y asignado a otro DC.

¿Cuál es el rol FSMO más importante?

Mientras que todos los roles FSMO son importantes, el Emulador PDC es el más crucial ya que gestiona el tiempo para el dominio, los cambios de contraseña y la configuración de group policy. En algunos casos, los sistemas heredados pueden depender de él como el único medio para manejar las solicitudes de autenticación.

¿Cómo encuentro los roles FSMO?

Hay varias maneras de averiguar qué controladores de dominio tienen los roles FSMO de Active Directory. Una es usar el comando “netdom query fsmo” mediante el símbolo del sistema. También puedes utilizar herramientas de Active Directory y PowerShell para descubrir qué servidor hospeda cada rol.

¿Dónde deben colocarse los roles FSMO?

Si solo tiene uno o dos controladores de dominio en su entorno de AD, no tiene muchas opciones al respecto. Todos los roles FSMO deben asignarse a un DC que tenga buena conectividad con todos los demás DCs en el bosque. Si es posible, el Infrastructure Master no debe colocarse en un servidor de catálogo global.

¿Qué roles FSMO deben estar juntos?

Los dos roles FSMO a nivel de bosque del Schema Master y del Domain Naming Master deben colocarse en el mismo DC, pero es solo una recomendación.

¿Qué son los roles FSMO en Active Directory?

Microsoft redujo el riesgo de conflictos designando controladores de dominio específicos como la única autoridad para cinco operaciones sensibles. Estas son las funciones Flexible Single Master Operations (FSMO), y entenderlas es fundamental para gestionar un entorno Active Directory estable y bien gobernado.

Active Directory funciona con un modelo multi-maestro en el que cada controlador de dominio mantiene una copia editable de su partición de dominio. Este diseño aporta resiliencia (las operaciones continúan incluso cuando algunos DCs están fuera de línea), pero también introduce la posibilidad de cambios conflictivos.

Esta guía explica cada uno de los cinco roles FSMO, cómo identificar qué controladores de dominio los tienen y proporciona los comandos necesarios para transferir o tomar roles cuando las circunstancias lo requieren.

Cada uno de los cinco roles FSMO pertenece a uno de dos ámbitos:

Por defecto, cuando promocionas el primer controlador de dominio en un bosque, los cinco roles FSMO se asignan a ese controlador. Los administradores pueden redistribuirlos a medida que el entorno crece y evolucionan las necesidades operativas.

FSMO significa Flexible Single Master Operations y se refiere a cinco operaciones de Active Directory que solo un controlador de dominio designado puede procesar a la vez. Al restringir estas operaciones a un único DC autorizado por ámbito, Active Directory evita colisiones de datos que ocurrirían si varios controladores intentaran realizarlas simultáneamente.

Netwrix Auditor supervisa las asignaciones de roles FSMO en Active Directory y alerta a su equipo cuando una transferencia o toma de rol ocurre fuera de una ventana de mantenimiento planificada. Solicite una demostración

Por qué la replicación multi-master requiere operaciones de un solo master

Los roles con ámbito forestal tienen exactamente un titular en todo el bosque de AD, sin importar cuántos dominios contenga el bosque. Los roles con ámbito de dominio tienen exactamente un titular por dominio de Active Directory, por lo que un bosque con tres dominios contiene tres RID Masters, tres PDC Emulators y tres Infrastructure Masters.

Importancia de los roles FSMO

Prevención de conflictos

Los primeros servicios de directorio de red se basaban en un modelo de maestro único: un servidor tenía la copia editable de la base de datos de cuentas mientras que los demás mantenían réplicas de solo lectura. Ese modelo evitaba conflictos pero creaba una dependencia fuerte en un solo servidor: si se desconectaba, no se podían crear nuevas cuentas ni modificar las existentes.

Los roles FSMO mantienen Active Directory consistente, seguro y recuperable. Su importancia solo se hace evidente cuando algo falla: un controlador de dominio falla, se necesita una transferencia de rol bajo presión o un atacante apunta a un titular de rol.

Active Directory reemplazó ese modelo con replicación multi-maestro. Cada controlador de dominio puede escribir en su copia local del directorio, y los cambios se propagan a todos los demás controladores mediante replicación programada. El diseño ofrece resiliencia, pero expone operaciones específicas donde dos controladores actuando simultáneamente podrían corromper el directorio. Los roles FSMO lo resuelven al imponer autoridad de maestro único precisamente donde el modelo multi-maestro no puede operar de forma segura.

Fiabilidad de la autenticación

Postura de seguridad

Sin autoridades designadas de maestro único, dos controladores de dominio podrían procesar operaciones conflictivas simultáneamente: uno asignando RID 1050 a una nueva cuenta de usuario mientras otro asigna el mismo RID a una cuenta diferente, o dos administradores extendiendo el esquema con definiciones de atributos incompatibles. Cualquiera de estos resultados produce corrupción del directorio sin una solución clara. Los roles FSMO garantizan que cada operación sensible tenga exactamente una fuente autorizada en todo momento.

Recuperación ante desastres

Cuáles son los 5 roles FSMO

La designación FSMO del PDC Emulator es la razón por la que tu mesa de ayuda puede desbloquear una cuenta y que el cambio surta efecto en segundos en todo el dominio. Sin ella, Kerberos authentication las decisiones se basarían en la versión de contraseña que un DC determinado tuviera en ese momento, creando condiciones de carrera entre cambios recientes de contraseña e intentos de inicio de sesión. El modelo de maestro único para el procesamiento de contraseñas proporciona a cada DC una ruta conocida de escalada para fallos de autenticación, y esa ruta solo funciona porque un DC tiene el rol de PDC Emulator.

Tres de los cinco roles FSMO están directamente en la ruta de escenarios de ataque de alto valor. El Schema Master controla si un atacante puede extender el esquema del directorio para introducir mecanismos de persistencia. El RID Master controla la asignación de SID, y la manipulación de RID es un vector conocido para privilege escalation y ataques de historial de SID. El PDC Emulator procesa la autenticación y los bloqueos de cuentas, convirtiéndolo en un objetivo principal para quien intente mantener el acceso al dominio o suprimir alertas de bloqueo.

Active Directory define cinco roles FSMO. El Schema Master y el Domain Naming Master operan a nivel de bosque. El RID Master, PDC Emulator y Infrastructure Master operan a nivel de dominio.

1. Maestro de Esquema

Cuando un controlador de dominio que posee un rol FSMO falla, la ruta de recuperación depende de si su equipo sabe qué roles tenía y si la falla es temporal o permanente. Las organizaciones que no rastrean las asignaciones de roles descubren la brecha bajo presión: no se pueden crear nuevas cuentas de usuario, la sincronización de tiempo se desvía o las actualizaciones de Group Policy dejan de propagarse. Documentar los titulares de roles y probar los procedimientos de transferencia son la base operativa para la resiliencia de AD.

Cada bosque tiene un Schema Master. El esquema de la base de datos de Active Directory database define cada clase de objeto (usuarios, grupos, equipos, impresoras y más) y cada atributo que esos objetos pueden tener. Solo el Schema Master puede escribir cambios en el esquema.

2. Maestro de Nomenclatura de Dominio

Cada bosque tiene un Domain Naming Master. Es el único controlador de dominio autorizado para agregar o eliminar dominios y particiones de aplicaciones del bosque.

Las actualizaciones del esquema son poco frecuentes. Ocurren cuando se eleva el nivel funcional del bosque, se actualiza Active Directory a una versión más reciente, se integra software empresarial que amplía el esquema (Exchange Server es un ejemplo común) o se introduce una nueva versión del sistema operativo Windows Server en el bosque. El Schema Master debe estar en línea y accesible para que cualquiera de estas operaciones tenga éxito.

Una vez confirmado, un cambio de esquema se replica en cada controlador de dominio del bosque. Si el Schema Master está desconectado cuando intentas una actualización del esquema, la operación falla hasta que el DC sea accesible nuevamente.

3. RID Master

Un SID sigue esta estructura:

Interactúas con el Domain Naming Master cuando cambia la estructura del directorio de tu organización: agregando un dominio hijo, eliminando un dominio obsoleto o absorbiendo dominios de una empresa adquirida. Debido a que estas operaciones son poco frecuentes y rara vez críticas en tiempo, el Domain Naming Master tiene requisitos de disponibilidad más bajos que los roles a nivel de dominio. Una breve interrupción del Domain Naming Master no afecta las operaciones diarias.

El RID Master mantiene esta unicidad asignando grupos de RID a los controladores de dominio. Cuando un DC necesita crear un nuevo principal de seguridad, toma un RID de su grupo asignado en lugar de contactar al RID Master por cada objeto. Cuando un grupo se agota, el DC solicita uno nuevo al RID Master.

Si el RID Master se desconecta, los controladores de dominio continúan creando objetos usando sus grupos RID existentes. En entornos maduros con grandes grupos, esto puede continuar durante un período prolongado. Finalmente, una vez que se agotan todos los grupos DC, la creación de objetos falla.

4. Emulador PDC

Cada dominio tiene un RID Master. Cada principal de seguridad en Active Directory (usuarios, equipos y grupos) requiere un Identificador de Seguridad (SID) único. Un SID consta de un prefijo de dominio seguido de un Identificador Relativo (RID). La parte RID es lo que hace que cada SID sea único dentro del dominio.

Cada dominio tiene un emulador PDC. Tiene más responsabilidades que cualquier otro rol FSMO y tiene el impacto más directo en las operaciones diarias del dominio. El emulador PDC maneja lo siguiente:

El SID del dominio es el mismo para todos los objetos en el dominio. El segmento final (1001 en este ejemplo) es el RID asignado a un principal de seguridad específico.

• Sincronización de tiempo: El Emulador PDC es la fuente de tiempo autorizada para su dominio. Todas las estaciones de trabajo y servidores miembros sincronizan sus relojes con él. En un bosque con múltiples dominios, el Emulador PDC en el dominio raíz del bosque actúa como el guardián del tiempo para todos los demás Emuladores PDC en el bosque. El Emulador PDC en el dominio raíz debe sincronizarse con una fuente de tiempo externa confiable. La autenticación Kerberos falla cuando la diferencia de tiempo entre un cliente y su DC autenticador supera los cinco minutos; el tiempo preciso no es opcional.
• Procesamiento del bloqueo de cuenta: Cuando ocurre un account lockout, el emulador PDC lo procesa inmediatamente y replica el estado de bloqueo a todos los DC en el dominio. Cuando un administrador desbloquea una cuenta, el emulador PDC replica el cambio de inmediato.
• Cambios de contraseña y autenticación: Cuando un usuario cambia una contraseña, el cambio se replica inmediatamente al PDC Emulator. Si un usuario intenta autenticarse en un DC que aún no ha recibido la contraseña actualizada mediante la replicación normal, ese DC reenvía la solicitud de autenticación al PDC Emulator. Esto garantiza que el dominio acepte credenciales válidas incluso cuando los cambios recientes de contraseña aún no se han propagado mediante la replicación programada.

Coloque el emulador PDC en un DC de alto rendimiento con buena conectividad de red a todos los demás controladores del dominio. Su falla tiene un impacto inmediato y visible en las operaciones.

• Sincronización del espacio de nombres DFS: Por defecto, los servidores raíz DFS solicitan información actualizada del espacio de nombres al PDC Emulator. En entornos grandes, esto puede crear cuellos de botella en los recursos. Habilitar el parámetro RootScalability en Dfsutil.exe permite que los servidores raíz DFS soliciten actualizaciones al DC más cercano.

5. Maestro de Infraestructura

• Actualizaciones de Group Policy: Los cambios en un Group Policy Object se registran inicialmente en el DC que tiene el rol de PDC Emulator. Esto evita conflictos de versiones que ocurrirían si dos administradores editaran el mismo GPO en diferentes DC al mismo tiempo.

Cada dominio tiene un Infrastructure Master. Su responsabilidad principal es mantener referencias precisas de objetos entre dominios en un bosque multidominio.

Si el Infrastructure Master se desconecta, los nombres de objetos entre dominios pueden no resolverse correctamente. Las membresías de grupos entre dominios continúan funcionando, por lo que el impacto operativo es principalmente administrativo.

Cómo encontrar a los titulares de roles FSMO

Dos condiciones hacen innecesario el Infrastructure Master: bosques de un solo dominio (no existen referencias entre dominios) y entornos donde cada DC también es un servidor de catálogo global (común en entornos modernos con suficiente ancho de banda de red). En ambos casos, todos los DC ya tienen información actualizada entre dominios sin depender del Infrastructure Master.

Cuando un usuario de un dominio se añade a un grupo de seguridad en otro dominio, Active Directory crea un objeto marcador de posición (llamado objeto fantasma) en el dominio del grupo para representar al usuario entre dominios. El Infrastructure Master mantiene actualizados esos objetos fantasma sincronizándolos con el catálogo global. También elimina objetos obsoletos quitando referencias a objetos de trusts o dominios.

Usando netdom query fsmo

Usando PowerShell

Reemplace <DomainName>Expand por el nombre de dominio completo del dominio objetivo. La salida muestra el nombre del host del DC que posee cada rol.

El comando netdomExpand se ejecuta en cualquier equipo Windows unido al dominio con RSAT instalado, o directamente en un controlador de dominio. Devuelve los cinco titulares de roles en una sola consulta:

Uso de herramientas administrativas de Active Directory

PowerShell ofrece un control más detallado y funciona bien en entornos con múltiples dominios. El siguiente script consulta todos los dominios del bosque y devuelve cada DC con una asignación de rol FSMO:

Saber qué controladores de dominio tienen los cinco roles FSMO es un requisito previo tanto para el mantenimiento planificado como para la respuesta a incidentes. Hay tres métodos disponibles usando las herramientas integradas de Active Directory management tools.

Para encontrar el RID Master, PDC Emulator y Infrastructure Master:

1. Abra Usuarios y equipos de Active Directory.

Para una consulta por dominio más sencilla, use Get-ADDomainExpand y Get-ADForestExpand directamente:

Las herramientas GUI en Active Directory Users and Computers muestran los tres roles FSMO a nivel de dominio.

1. Haga clic derecho en el nombre del dominio en el panel izquierdo y seleccione Operations Masters.
2. Abra Active Directory Domains and Trusts.

Para encontrar el Domain Naming Master:

1. El diálogo muestra el Domain Naming Master actual.
2. Revise las pestañas RID, PDC y Infrastructure, cada una mostrando el titular actual del rol.
3. Haga clic derecho en Active Directory Domains and Trusts en el panel izquierdo y seleccione Operations Master.

Para encontrar el Schema Master: El complemento de Active Directory Schema no se carga por defecto. Regístrelo primero:

Cómo transferir roles FSMO

1. Abra el cuadro Ejecutar (Win + R) e ingrese regsvr32 schmmgmt.dll. ExpandHaga clic en Aceptar.

3. Haga clic derecho en Active Directory Schema en el panel izquierdo y seleccione Operations Master para ver el Schema Master actual.

2. Abra MMC (mmc.exeExpand), vaya a Archivo > Agregar/Quitar complemento, y agregue Active Directory Schema.

Una transferencia mueve un rol FSMO de su titular actual a otro DC mientras ambos controladores están en línea y comunicándose. Use una transferencia para operaciones planificadas: desmantelar un DC, redistribuir roles por carga o redundancia, o reemplazar hardware obsoleto.

Transferencia vía PowerShell

Transferir un solo rol:

Transfiera los cinco roles a la vez:

Ambos DC deben estar en línea, accesibles y replicando correctamente antes de iniciar una transferencia. Verifique la salud de la replicación con repadmin /replsummaryExpand antes de continuar.

PowerShell es el método más eficiente para transferir roles, especialmente al mover varios roles a la vez. El Move-ADDirectoryServerOperationMasterRoleExpand cmdlet maneja los cinco roles.

Transferencia a través de la GUI:

Los cinco valores de nombre de rol son SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster y InfrastructureMasterExpand.

Cómo tomar los roles FSMO

Reemplace TargetDCName Expandcon el nombre NetBIOS o FQDN del DC de destino. PowerShell solicita confirmación antes de transferir cada rol. Agregue -Confirm:$falseExpand para suprimir las solicitudes en escenarios automatizados.

Después de cualquier transferencia, ejecute netdom query fsmoExpand para confirmar las nuevas asignaciones de roles.

Tomando roles con ntdsutil:

Antes de incautar, intente restaurar o recuperar el DC original. Si la recuperación no es posible, proceda con la incautación y asegúrese de no volver a unir el DC original al dominio sin antes degradarlo.

Para el RID Master, PDC Emulator e Infrastructure Master: abra ADUC, navegue a Operations Masters, seleccione la pestaña correspondiente y haga clic en Change. Para el Domain Naming Master: use Active Directory Domains and Trusts > Operations Master > Change. Para el Schema Master: use el complemento Active Directory Schema > Operations Master > Change.

Después de conectarse, tome cada rol individualmente:

Una incautación asigna forzosamente un rol FSMO a un nuevo DC sin coordinación con el titular original. Use una incautación solo cuando el titular actual del rol esté permanentemente fuera de línea e irrecuperable. No incautar un rol si el titular original podría volver a la red; volver a conectar un antiguo titular de rol después de una incautación provoca una condición de cerebro dividido que requiere remediación manual.

Abra un símbolo del sistema elevado en el DC que recibirá los roles y ejecute ntdsutilExpand. Luego siga estos pasos:

Escriba quit Expanddos veces para salir de ntdsutil después de completar todas las incautaciones.

Mejores prácticas para la colocación de roles FSMO

Confirme las nuevas asignaciones con netdom query fsmoExpand antes de volver a poner en línea cualquier servicio que dependa de esos roles.

La asignación de roles afecta directamente la estabilidad y el tiempo de recuperación de AD. Revise la guía de mejores prácticas de seguridad de Active Directory para recomendaciones más amplias de endurecimiento junto con estas directrices específicas de roles:

• Distribuya los roles en diferentes ubicaciones físicas cuando sea posible: En entornos multisede, asignar roles a los DC en su sitio principal reduce la dependencia de WAN para operaciones que dependen de roles. Combine esto con un plan de transferencia documentado para que los roles puedan moverse rápidamente si el sitio principal queda fuera de línea.
• Schema Master y Domain Naming Master juntos, en un DC menos utilizado: Estos roles a nivel de bosque se invocan raramente. Agruparlos en el mismo DC simplifica la administración sin crear un cuello de botella en el rendimiento.

Para obtener orientación sobre cómo configurar y ajustar los controladores de dominio para respaldar estas decisiones de ubicación, consulte la guía de implementación de controladores de dominio de Netwrix.

Cómo Netwrix Auditor le ayuda a supervisar y auditar los cambios de rol FSMO

• Emulador PDC y RID Master en el DC más fiable del dominio: Ambos roles requieren alta disponibilidad. La falla del Emulador PDC afecta inmediatamente a los usuarios; la falla del RID Master se acumula con el tiempo a medida que se agotan las reservas. Colóquelos en el DC más fiable y mejor conectado del dominio.
• Infrastructure Master fuera de un servidor de catálogo global: En entornos donde no todos los DC también son servidores de catálogo global, el Infrastructure Master debe ejecutarse en un DC que no tenga una copia del catálogo global. Un Infrastructure Master que también tiene un catálogo global nunca encuentra objetos fantasma para actualizar, por lo que no puede mantener las referencias entre dominios actualizadas. Si todos los DC en su dominio son servidores de catálogo global (común en entornos modernos), esta restricción no se aplica.

Alertas en tiempo real sobre cambios en roles FSMO

Netwrix Auditor para Active Directory cierra la brecha entre lo que capturan los registros nativos y lo que su equipo de seguridad necesita para actuar.

Active Directory registra las transferencias FSMO en el registro de eventos del Servicio de Directorio bajo el ID de evento 1458, registrado en el controlador de dominio que recibió el rol y nombrando al titular anterior. El evento confirma que se realizó una transferencia, pero no proporciona el contexto completo de la cuenta ni los detalles de la sesión que necesita una investigación.

Para tener una visión completa de qué monitorear en su directorio, las Active Directory auditing guidelines cubren todo el alcance de los eventos que vale la pena rastrear.

Una transferencia o toma no autorizada del rol FSMO es un vector de ataque confirmado en AD con consecuencias que van más allá de una interrupción operativa rutinaria. Un atacante que obtiene privilegios suficientes en un controlador de dominio puede tomar el rol de PDC Emulator para interceptar solicitudes de autenticación, manipular la sincronización de tiempo o controlar la distribución de Group Policy en todo el dominio. Estos cambios pueden no aparecer en los registros nativos de eventos de Windows con suficiente contexto para identificar al actor y la intención.

Registro completo de auditoría antes y después

Netwrix Auditor alerta en el momento en que se transfiere o toma un rol FSMO. Las alertas se activan independientemente de si el cambio se realizó mediante PowerShell, la GUI o ntdsutil, e incluyen la cuenta que inició el cambio, la estación de trabajo de origen y la marca de tiempo. Su equipo puede verificar las transferencias planificadas de inmediato y escalar los cambios no reconocidos antes de que ocurra más daño.

Informes listos para cumplimiento

Distinguir transferencias planificadas de incautaciones no autorizadas

Cada cambio de rol FSMO se registra con el titular anterior del rol, el nuevo titular, la cuenta que realizó la acción y la hora exacta del cambio. Los registros de eventos nativos de Windows omiten este contexto. Cuando un incidente requiere reconstrucción (para una investigación interna o una auditoría externa), el registro completo está disponible sin depender de la agregación de registros de múltiples controladores de dominio.

Porque Netwrix Auditor captura el contexto completo de la cuenta y la sesión, su equipo puede cotejar los cambios de rol con sus registros de gestión de cambios. Una transferencia realizada por una cuenta de administrador nombrada durante una ventana de mantenimiento programada se ve diferente de una toma ejecutada por una cuenta sin actividad administrativa previa. La auditoría hace que esa distinción sea clara y defendible.

Solicite una demostración para ver cómo Netwrix puede ayudarle a auditar cambios en roles FSMO, rastrear cada modificación de Active Directory y generar la evidencia lista para investigación que su equipo de seguridad necesita.

Las asignaciones de roles FSMO forman parte de la huella de acceso privilegiado que SOX, HIPAA, y las auditorías de ISO 27001 examinan. Netwrix Auditor genera informes predefinidos sobre cambios de privilegios en Active Directory que satisfacen las solicitudes de los auditores sin necesidad de extraer registros manualmente. El historial de cambios de roles se conserva y es buscable, por lo que la evidencia de cumplimiento está disponible bajo demanda en lugar de reunirse bajo presión.