Los Flexible Single Master Operations, conocidos como «FSMO roles» o también «Operations Master Roles», no son roles como los que se instalan a través del Server Manager en Windows Server. Son una serie de funciones de Active Directory para prevenir conflictos de replicación.

Como sabemos, una de las grandes ventajas de AD es que para la mayor parte de la replicación, utiliza un sistema Multi-Master, es decir, podemos hacer cambios en cualquier Domain Controller y estos se replicarán al resto de los DCs que dispongamos.

Cambios como actualizar las propiedades de un objeto, cambiar la contraseña, crear OUs,…. Se pueden hacer desde cualquier DC de escritura. En este modelo los conflictos se resuelven dando prioridad al último que haga el cambio. Si por ejemplo, reseteamos la contraseña de un usuario desde 2 DCs diferentes, el último que lo haga prevalece.

Sin embargo, hay ciertos cambios que son demasiado importantes y críticos en AD para que se puedan hacer desde cualquier DC, y para evitar conflictos se recurre a un sistema Single-Master. Estos cambios tan importantes son llevados a cabo por los FSMO roles, que no tienen por qué estar en un mismo DC, pueden distribuirse entre varios DCs.

Existen 5 FSMO roles, 2 de ellos son a nivel de bosque, y 3 a nivel de dominio. En un bosque sólo puede haber un Schema Master y un Domain Naming Master. Y por cada dominio del bosque existirá un PDC Emulator, un RID Master y un Infrastructure Master.

FSMO roles a nivel de bosque:

• Schema Master (Maestro de Esquema): El DC que tenga este rol es el único autorizado para modificar el esquema de AD. Cualquier cambio en el esquema, no importa desde que DC lo hagamos, siempre estará «conectado» al DC con el FSMO rol de Schema Master. Y éste tiene que estar siempre online cuando actualicemos el esquema.

• Domain Naming Master (Maestro de Nombres de Dominio): Se encarga de autorizar el alta o baja de dominios en el bosque, así como de mantener una lista actualizada de todos los dominios existentes (para que, por ejemplo, no se dé el caso de intentar crear dos dominios con el mismo nombre al mismo tiempo). También tiene la función de añadir o eliminar particiones de aplicación en AD. Tiene que estar online cuando añadimos o eliminamos dominios o particiones de aplicación.

Es recomendable que el Schema Master, el Domain Naming Master y el PDC Emulator residan en el mismo DC del bosque raíz.

FSMO roles a nivel de dominio:

• PDC Emulator (Emulador de PDC – Primary Domain Controller). Tiene varias funciones:

– Recibe las actualizaciones de las contraseñas de usuarios y equipos.
– Crea y actualiza las políticas de grupo (cuando modificamos las políticas del dominio desde la GPMC (Group Policy Management Console), ésta trata de conectarse siempre al DC con el FSMO rol de PDC).
– Sincroniza tiempos, sólo él puede sincronizar la hora con un servidor externo. Los demás DCs sincronizarán la hora con él.
– Debe estar siempre online y accesible.

Es recomendable que el PDC Emulator y el RID Master residan en el mismo DC.

• RID Master (Relative Master ó Maestro de RID): En un dominio, cuando se crea un objeto (sea un usuario, un grupo o un equipo), se le asigna un SID (Security IDentifier) que es único y que nunca es reutilizado incluso aunque el objeto sea eliminado. Haciendo una analogía, es algo así como el documento de identidad personal. Un SID consta de tres partes:

– La primera parte (S-1-5-21-…) es un identificador asignado por ISO que especifica:

S-1 : Especifica que la cadena es un SID y la versión de revisión actual es 1.
5 : Identifica a la autoridad (5 es para NT Authority, indica que es un SID específico de Windows).
21 : Indica que lo que viene a continuación es un Domain ID.

– El «Domain IDentifier» (Domain ID) es un identificador del dominio, todas las cuentas de usuario, grupo y equipo de un mismo dominio comparten estos datos.

– El «Relative IDentifier» (RID) es un número que se asigna de forma secuencial a partir del número 1000 a cada nuevo objeto que se crea en el dominio. Para los objetos creados por defecto con el sistema existen una serie de RIDs estándar: 500 para el administrador, 501 para el usuario invitado, 502 para el Kerberos Key Distribution Center,…

Más información aquí.

El DC con el rol de RID tiene que estar online cuando promocionamos un DC para que éste pueda obtener un rango de RIDs que utilizará cuando se crean los objetos. El RID Master proporciona rangos de RIDs a los DCs de escritura (los asigna de 500 en 500), y cuando éstos comiencen a agotar ese rango (por debajo de 50 disponibles) volverán a solicitar al RID master un rango nuevo.

• Infrastructure Master (Maestro de Infraestructuras): En un entorno multidominio, es el responsable de actualizar las referencias de los objetos de un dominio en los objetos de otros dominios. En otras palabras, se encarga de traducir los GUIDs (Global Unique IDentifiers), los SIDs y los DNs (Distinguished Names) de los objetos de otros dominios. Si alguna vez habéis echado un vistazo a los miembros de un grupo local de un dominio el cual tiene miembros de otros dominios, a veces podéis encontraros con que esos usuarios y grupos del otro dominio se listan sólo por su SID, el Infrastructure Master del dominio en el que están esos objetos es el responsable de su traducción.

– Este rol sólo tiene «trabajo» cuando estamos en un entorno multidominio, y nunca debería estar ubicado en un DC que sea a su vez Global Catalog (GC, ó Catálogo Global). Cuando un DC es Catálogo Global, éste recibe actualizaciones periódicas de los objetos de todos los dominios mediante la replicación, de forma que la información sobre esos objetos siempre está actualizada.

– Si el maestro de infraestructuras encuentra objetos sin actualizar, solicita la información actualizada a un GC y después los replica a los otros DCs del dominio. 

– Si el maestro de infraestructuras y el GC se encuentran en el mismo DC, el maestro de infraestructuras no funcionará ya que nunca encontrará información no actualizada, por lo que nunca replicará los cambios a otros DCs del dominio.

– Si todos los DCs son GC, todos tendrán los datos más actuales y será irrelevante conocer el DC que disponga el rol de maestro de infraestructuras.

Podemos comprobar que DCs son GC de varias formas, en el siguiente ejemplo tenemos dos DCs y los dos son GC:

– Desde AD Users and Computers:

– Desde AD Sites and Services (podemos hacer que no sean GC desmarcando «Global Catalog»):

– Desde PowerShell con el cmdlet:

PS C:\Users\Administrator> Get-ADForest <forest_name> | fl GlobalCatalogs

Para saber dónde se ubican los FSMO Roles usamos el comando > netdom query fsmo desde CMD (buscará sólo en el dominio donde se lanza el comando, en el caso de tener varios dominios habrá que lanzarlo desde un DC de cada uno de esos dominios). En el ejemplo, los cinco FSMO Roles están en el DC1 del dominio ITadmins.es:

Decimos entonces que los FSMO Roles pueden distribuirse entre los distintos DCs que dispongamos aunque, por defecto, se ubicarán todos en el primer DC que promocionemos en el bosque y, en caso de tener un entorno multidominio, en el primer DC de cada dominio adicional (en este caso serían sólo los tres FSMO a nivel de dominio).

En el ejemplo vemos que todos los FSMO Roles están en el DC1, si queremos moverlos al DC2, tenemos que ir al DC2 y «cogerlos», es decir, la operación de moverlos se hace desde el DC de destino. Esto no quiere decir que tengamos que conectarnos necesariamente al servidor DC2 para hacerlo, quiere decir que la consola debe estar conectada al DC2.

Si habéis conseguido llegar hasta aquí sin dormiros, ¡enhorabuena! 🙂 Por hoy ya ha habido bastante teoría, así que la parte práctica la veremos en el siguiente artículo.

Saludos y gracias por leernos!