Recursos para profesionales y entusiastas de IT

[ARTICULO] Active Directory Domain Services | Roles FSMO (Flexible Single Master Operation) de Active Directory desde Windows 2000

14 minutos de lectura

Active Directory es la implementación de Microsoft del servicio de directorio en una red distribuida de computadoras. Esta tecnología permite la existencia de muchos controladores de dominio atendiendo las peticiones de los usuarios y los cambios que se realicen dentro de la infraestructura. Sin embargo hay ciertas tareas que solo pueden ser ejecutadas por un único controlador de dominio que tenga la capacidad der realizarlas (o dicho rol). A estos roles los llamamos “Roles FSMO”.

En este artículo vamos a recorrer cuales y para qué sirven, además de entender cuál es el origen de los mismos y las diferencias con sus versiones anteriores de servicio de directorio.

 

Introducción

Objetivo

Esta publicación tiene como objetivo presentar para qué sirven los roles FSMO (Flexible Single Master Operation) que tiene Active Directory Domain Services a partir de Windows 2000 (hasta la actualidad, Windows Server 2016) y por qué son tan importantes en una organización.

Alcance

El alcance de esta publicación es la siguiente:

  • Se explicará en alto nivel cuál es el fundamento de los roles FSMO.
  • Se identificarán cuáles son estos roles.
  • Se indicará en alto nivel cómo impacta en una organización el faltante de cada uno.

Desarrollo del Artículo Roles FSMO de Active Directory Domain Services

Introducción a los roles FSMO

Si nos remontamos a la historia y antes de la existencia de Active Directory en Windows Server 2000, existía el modelo de dominio de Windows NT4 Server. Allí existía un equipo que se llamaba “PDC” (Primary Domain Controller) que cumplía la función de master. Por éste equipo se procesaban todos los requerimientos de cambio en el servicio de directorio. Esto significa que la creación de un usuario o la modificación de una política de seguridad tenían que pasar por este equipo antes de efectivizarse.

Desde el modelo de dominio de Windows 2000 Server en adelante, esto sufrió un cambio. Con la implementación de Active Directory, se conoció el concepto multi-master, donde todos los controladores de dominio pueden realizar cambios y escribirlos en la base de datos del servicio de directorio. Esto, por supuesto, permite mayor flexibilidad de administración y rapidez a la hora de realizar un cambio, ya que luego es el servicio de directorio quién replica los cambios al resto de los controladores de dominio. Si por alguna razón se realizó un cambio sobre un mismo objeto desde dos controladores de dominio distintos, permanecerá la más reciente.

Sin embargo, hay ciertas tareas para las cuales aún se sigue utilizando el modelo de “Single Master”, dadas la naturaleza crítica de las mismas. Esto da lugar a los roles FSMO, o “Flexible Single Master Operation”, o en español conocido como “Maestros de Operaciones”. Estos roles son 5 y los recorreremos en detalle en este artículo.

Desde Windows Server 2000 estos roles se mantuvieron, y son aplicables a Windows Server 2008 R2 y, en primera instancia, no sufrirán cambios en Windows Server 2012.

Roles FSMO de Boque y de Dominio

De los 5 roles FSMO existentes, hay algunos que operan a nivel Bosque y otros que operan a nivel Dominio de Active Directory. Esto significa que en un esquema de dominio/forest simple, van a existir:

  • 2 roles FSMO a nivel forest.
  • 3 roles FSMO a nivel dominio.

Sin embargo, en un esquema de un forest con más de 1 dominio (por ejemplo un dominio + un dominio hijo) vamos a tener más de 5 roles FSMO implementados:

  • 2 roles FSMO a nivel forest.
  • 3 roles FSMO para cada dominio implementado dentro del forest: 6 en total.

Detalle de roles FSMO

Los siguientes 2 roles FSMO operan a nivel forest:

  • Schema Master (Maestro de Esquema)
  • Domain Naming Master (Maestro de Nombres de Dominio)

Los siguientes 3 roles FSMO operan a nivel dominio:

  • Primary Domain Controller Emulator (Maestro Emulador de Controlador de Dominio Primario)
  • Relative ID (RID) Master (Maestro RID)
  • Infraestructure Master (Maestro de Infraestructura)

Vamos a recorrer uno por uno para ver cuáles son las funciones asignadas y cuáles son sus impactos si no están disponibles.

Schema Master (Maestro de Esquema)

Ubicación y Función
  • Solo un controlador de dominio a nivel bosque (del Forest Root Domain) lo puede albergar.
  • Es el responsable de procesar cualquier cambio que se realice en el Esquema de Active Directory, sin importar desde donde se lance el cambio (desde que equipo).
No disponibilidad
  • La ausencia de éste rol en la operatoria diaria puede pasar desapercibido, debe estar disponible cuando son necesarios realizar cambios en el Esquema de Active Directory.
  • La no disponibilidad del rol genera errores en los updates de esquema, por ejemplo si estamos realizando los cambios en una instalación de Exchange Server.

Domain Naming Master (Maestro de Nombres de Dominio)

Ubicación y Función
  • Solo un controlador de dominio a nivel bosque (del Forest Root Domain) lo puede albergar.
  • Es el responsable de procesar las adiciones y remociones de dominios y particiones de aplicación en un bosque.
No disponibilidad
  • La ausencia de éste rol en la operatoria diaria puede pasar desapercibido, debe estar disponible cuando se agregan o quitan dominios o aplicaciones que requieran cambios en la partición de aplicación.
  • La no disponibilidad del rol genera la imposibilidad de agregar o quitar dominios del forest o modificar la partición de aplicación.

Primary Domain Controller (Maestro Emulador de Controlador de Dominio Primario)

Ubicación y Función
  • Solo un controlador de dominio a nivel dominio lo puede albergar. En el caso de un esquema de varios dominios en un forest, habrá tantos controladores de dominio que albergan este rol como dominios existan.
  • Recibe las actualizaciones de contraseñas cuando son cambiadas por la computadora del usuario y por cuentas de usuario que están en el resto de los controladores de dominio.
  • Recibe consultas por el resto de controladores de dominio ante eventos de ingreso erróneo de contraseñas (recibe consultas para verificar la última contraseña del usuario vigente).
  • Es el controlador de dominio destino por defecto ante cambios en Políticas de Grupo.
  • Es el controlador de dominio destino por defecto para aplicaciones que realizan operaciones de escritura sobre el servicio de directorio.
  • Es el controlador de dominio destino por defecto para algunas herramientas administrativas de Active Directory que realizan operaciones de escritura sobre el servicio de directorio.
  • Mantiene la coordinación de hora para el dominio, en el que se basan las decisiones para identificar el último horario de escritura para objetos y resolver conflictos.
  • Es utilizado por equipos clientes que no soportan el esquema multi-master, como Windows 98.
No disponibilidad
  • La ausencia de éste rol en la operatoria diaria no pasa desapercibido y puede generar algunos dolores de cabeza a los administradores. Es recomendable que esté online las 24 horas del día los 365 días del año.
  • La no disponibilidad del rol genera:
    • Demoras ante ingresos erróneos de contraseña.
    • No-coordinación de horario entre controladores de dominio.
    • No-operación de algunas herramientas administrativas de Active Directory.
    • Errores en la herramienta “Entorno de Red” en equipos con hasta Windows 2003 y XP.
    • Otros dolores de cabeza en la operatoria diaria!

RID Master (Maestro RID)

Ubicación y Función
  • Solo un controlador de dominio a nivel dominio lo puede albergar.
  • Es el responsable de alocar los grupos activos y en espera de RID (Relative Identifier) a los restantes controladores de dominio en el mismo dominio.
No disponibilidad
  • La ausencia de éste rol en la operatoria diaria puede pasar desapercibido, debe estar disponible cuando se necesitan asignar RIDs a los controlares de dominio del mismo dominio.
  • Cuando un controlador de dominio tiene pocos RIDs disponibles, éste le debe solicitar al RID Master otro rango de RIDs. Si no está disponible y dicho controlador de dominio se quedan sin RIDs disponibles, la generación de objetos tendrá como resultado error desde dicho controlador de dominio.
  • Cuando se promueve un nuevo controlador de dominio en un dominio existente, de no estar disponible este rol dicho controlador de dominio generará errores.

Infraestructure Master (Maestro de Infraestructura)

Ubicación y Función
  • Solo un controlador de dominio a nivel dominio lo puede albergar.
  • Es el responsable de actualizar las referencias entre dominios.
  • Es el responsable de traducir los SID a nombres en las referencias de cuentas entre dominios.
No disponibilidad
  • La ausencia de éste rol en la operatoria diaria puede pasar desapercibido, salvo en casos de cambios de referencias o pertenencias a grupos de usuario entre dominios.
  • La no disponibilidad de este rol puede provocar que las referencias a objetos entre dominios no muestre los datos del usuario, sino su SID.

Ubicación y Disponibilidad de los Roles FSMO en la infraestructura de Active Directory

La instalación inicial de Active Directory ubica los roles en el primer controlador de dominio del forest/dominio.

Para infraestructuras “single-domain” con pocos controladores de dominio esta ubicación es frecuentemente correcta y la recomendada por Microsoft con el fin de mantener el esquema de operación y comprensión simple y fácil. Para infraestructuras con más controladores de dominio o más complejas, no siempre es lo aconsejado.

En términos generales, las siguientes son las recomendaciones generales para la ubicación de los roles FSMO:

  • Ubicar el Schema Master en el mismo lugar que el PDC Emulator del Forest Root Domain.
  • Ubicar el Domain Naming Master en el mismo lugar que el PDC Emulator del Forest Root Domain.
  • Ubicar el PDC Emulator en el controlador de dominio con mejor hardware y alta disponibilidad disponible, y en el mismo sitio donde exista otro controlador de dominio replica.
  • Ubicar el RID Master en el PDC Emulator del mismo dominio.
  • En relación al Infraestructure Master, es importante tener en cuenta lo siguiente:
    • En infraestructuras de tipo “Single Domain Forest”:
      • El Maestro de Infraestructura no tiene función.
      • Puede ser ubicado en cualquier controlador de dominio.
    • En infraestructuras de tipo “Multidomain Forest”:
      • Si todos los DC del dominio son Global Catalog, se puede ubicar en cualquiera de ellos.
      • Si no todos los DC del dominio son Global Catalog, se debería ubicar en un DC que no sea Global Catalog.

Por supuesto, la disponibilidad de los equipos que alojan algún rol FSMO es importante. Existe la posibilidad de transferir los roles entre controladores de dominio (role transfer) o de “robar” los roles FSMO ante algún fallo del DC que originalmente los aloja (Seize Roles). En el último caso, el controlador de dominio que originalmente tenía el rol “robado” no podrá ser vuelto a poner en línea, debiendo ser reinstalado.

Como saber dónde se encuentran los roles FSMO

Se puede conocer rápidamente cual es la ubicación de los roles FSMO en nuestra infraestructura de Active Directory. Para esto, y desde cualquier controlador de dominio, podemos ejecutar el siguiente comando en un CMD:

Éste comando arrojará los resultados con el siguiente formato:

Comando CMD para conocer ubicación de roles FSMO.

Comando CMD para conocer ubicación de roles FSMO.

En este caso, todos los roles están el en equipo PDC01.DILUX.LOCAL.

Conclusiones

Active Directory está formado por controladores de dominio con funciones multi-master. Esto significa que casi todas las operaciones pueden ser realizadas desde cualquier DC, y serán replicados a los restantes mediante mecanismos de replicación. Sin embargo hay algunas funciones que no pueden ser realizadas por cualquier controlador de dominio, debiendo realizarse desde solo uno. A esto se lo conoce como roles FSMO.

Los roles FSMO (Flexible Single Master Operation) tienen funciones críticas dentro de la infraestructura de Active Directory. Es importante conocer estas funciones y saber el impacto que pueden tener dentro de nuestra infraestructura la no-disponibilidad de alguna de ellas.

Referencias y Links

Para este artículo se han tenido en cuenta los siguientes links y referencias:

 

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.

Acerca del Autor

Pablo Ariel Di Loreto

Director at TecTimes
Mi nombre es Pablo Ariel Di Loreto, nací en Mayo de 1981 y soy oriundo de la Ciudad de Berazategui, Buenos Aires, Argentina.

Mis lazos con la informática comenzaron en el año 1998, cuando tenía 16 años, y comencé a aprender como administrar servidores bajo la plataforma Microsoft (Windows Server, Exchange Server, IIS, y otros) y a realizar desarrollos de software con tecnologías ASP y PHP. Un tiempo más tarde comencé a trabajar ya en forma productiva en la administración de plataformas y desarrollo de software.

Desde hace varios años he tenido una intensa actividad en las comunidades profesionales, a través de eventos, webcasts, foros y publicaciones diversas. En Abril de 2014 fui reconocido como Most Valuable Professional (MVP) por parte de Microsoft, estando hoy reconocido en las especialidades "Windows and Devices for IT" y "Microsoft Azure".

En la actualidad me desarrollo como Service Delivery Manager en Algeiba (http://www.algeiba.com), una compañía que brinda soluciones y servicios tecnológicos, dirigiendo un Equipo de Trabajo de más de 20 personas. También soy el Director de TecTimes, un Portal de Tecnología que nació en el año 2012 como parte de un proyecto personal de contribución a la comunidad tecnológica en español.
avatar

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.