5 FSMO Roles in Active Directory

Active Directory (AD) has been the de facto standard for enterprise domain authentication services ever since it first appeared in late 1999 (in Windows Server 2000). There have been several enhancements and updates since then to make it the stable and secure authentication system in use today.

In its infancy, AD had some rather glaring flaws. If you had multiple Domain Controllers (DC) in your domain, they would fight over which DC gets to make changes – and sometimes your changes would stick, and sometimes they wouldn’t. To level up AD and keep the DCs from fighting all the time, Microsoft implemented “last writer wins” – which can be a good thing, or it’s the last mistake that breaks all the permissions.

Then Microsoft took a left turn at Albuquerque and introduced a “Single Master Model” for AD. One DC that could make changes to the domain, while the rest simply fulfilled authentication requests. However, when the single master DC goes down, no changes can be made to the domain until it’s back up.

To resolve that fundamental flaw, Microsoft separated the responsibilities of a DC into multiple roles. Admins distribute these roles across several DCs, and if one of those DCs goes out to lunch, another will take over any missing roles! This means domain services have intelligent clustering with built-in redundancy and resilience.

Microsoft calls this paradigm Flexible Single Master Operation (FSMO).

FSMO Roles: What are They?

Microsoft split the responsibilities of a DC into 5 separate roles that together make a full AD system.

The 5 FSMO roles are:

• Schema Master – one per forest
• Domain Naming Master – one per forest
• Relative ID (RID) Master – one per domain
• Primary Domain Controller (PDC) Emulator – one per domain
• Infrastructure Master – one per domain

FSMO Roles: What do They do?

Schema Master: The Schema Master role manages the read-write copy of your Active Directory schema. The AD Schema defines all the attributes – things like employee ID, phone number, email address, and login name – that you can apply to an object in your AD database.

Domain Naming Master: The Domain Naming Master makes sure that you don’t create a second domain in the same forest with the same name as another. It is the master of your domain names. Creating new domains isn’t something that happens often, so of all the roles, this one is most likely to live on the same DC with another role.

RID Master: The Relative ID Master assigns blocks of Security Identifiers (SID) to different DCs they can use for newly created objects. Each object in AD has an SID, and the last few digits of the SID are the Relative portion. In order to keep multiple objects from having the same SID, the RID Master grants each DC the privilege of assigning certain SIDs.

PDC Emulator: The DC with the Primary Domain Controller Emulator role is the authoritative DC in the domain. The PDC Emulator responds to authentication requests, changes passwords, and manages Group Policy Objects. And the PDC Emulator tells everyone else what time it is! It’s good to be the PDC.

Infrastructure Master: The Infrastructure Master role translates Globally Unique Identifiers (GUID), SIDs, and Distinguished Names (DN) between domains. If you have multiple domains in your forest, the Infrastructure Master is the Babelfish that lives between them. If the Infrastructure Master doesn’t do its job correctly you will see SIDs in place of resolved names in your Access Control Lists (ACL).

FSMO gives you confidence that your domain will be able to perform the primary function of authenticating users and permissions without interruption (with standard caveats, like the network staying up).

It’s important to monitor AD in order to prevent brute force attacks or privilege elevation attempts – two common attack vectors for data theft. Want to see how to do it? We can show you. Get a demo to see how Varonis protects AD from both insider and external threats.