☰ ×

FSMO Roles in Active Directory – What are They & What do they do?

Last Updated: October 22nd, 2020 by in Guides

fmso roles definition and tutorial

Active Directory is the central database where an enterprise’s objects and its attributes are stored.

It is a systematic hierarchy structure that can contain myriads of objects. And, any changes done to the database can be processed at any DC within an enterprise, even if it is disconnected from the network. But for this, your Active Directory requires FSMO roles.

So lets jump into this and go over everything about FSMO Roles in Active Directory including What are they and what exactly do they do:

What is FSMO?

Active Directory was launched in late 1999 for Windows Server 2000 and since then it has been the go-to solution for enterprises’ domain authentication services. AD was upgraded multiple times to be more secure and reliable for authentication and authorization.

Back then, the most concerning issue was the changes made to AD with multiple Domain Controllers (DCs).

The Domain Controllers would have a dispute over which DC will process the changes.

After a period of consideration, Microsoft launched a “Single Master Model” for their Active Directory to prevent conflicting upgrades in Windows.

This implied that only one Master DC gets to process changes to the domain, and others handle authentication procedures. But again the problem with this model was that if the master DC goes down, you cannot make any changes to the domain until it’s connected again.

To tackle this issue, Microsoft divided the roles for Domain Controllers.

Admins will be able to assign roles across Domain Controllers and if any DC goes down, the other one will fulfill its role.

In short, Microsoft employed intelligent clustering within domain services featuring resilience and redundancy.

It is known as Flexible Single Master Operation (FSMO).

What are FSMO Roles?

Now that we know what exactly FSMO is, let’s see what its roles are.

Active Directory lets you create, upgrade or remove objects via any authorized DC. Every DC within Active Directory has a copy of the partition of its own domain, excluding read-only DCs. Once the changes are processed, they are automatically reflected across other Domain Controllers via ‘Multi-master replication’ process. This is what makes DCs more reliable with higher accessibility and redundancy.

Now, a particular domain controller processes sensitive operations within AD, and this behavior is only specific to that certain AD. Such confidential operations are processed through a special set of roles, known as FSMO roles.

Types of FSMO Roles:

Microsoft’s AD system comprises 5 FSMO roles. 3x Domain-level roles and 2x Forest-level ones.

They are as follows:

Domain-Wide FSMO Roles:

  • Primary Domain Controller (PDC) Emulator
  • Relative Identifier (RID) Master
  • Infrastructure Master

Forest-Wide FSMO Roles:

  • Schema Master
  • Domain Naming Master

In a new AD forest domain, all these 5 FSMO roles are assigned to the primary DCs.

If a new domain is added within an already existing forest, only 3 domain-level FSMO roles are attributed to the primary DCs in this new domain, the remaining two enterprise-level FSMO roles are already present in the forest domain.

Note: FSMO roles are assigned to the primary Domain Controllers, but you can transfer roles if needed. FSMO roles allow the domain to perform authentication processes as its primary function, without any hurdles.

5 FSMO Roles: What are they and what do they do?

Schema Master

Schema Master FSMO Role is assigned to a special Domain Controller that processes updates to the schema within the Active Directory.

It manages the read-write copy of the schema of your directory. Once the changes are processed, it is replicated to all the other DCs in the Active Directory.

The AD Schema defines email address, employee ID, login name, phone number and other such attributes of an object in your AD.

Know that there can only be one Schema Master DC per directory.

Domain Naming Master

Domain Naming Master FSMO Role is assigned to a DC that can process changes to the Forest-Wide domain name space of the Active Directory.

Only this DC is allowed to add or delete a domain from the directory. In addition to this, it can also delete or add cross references to domains within external directories.

Domain Naming Master ensures there are NO same domain names in the same forest.

RID Master

RID Master FSMO Role is for the single DC that will process RID Pool requests from all the Domain Controllers in a domain. It can also remove or move an object from its domain.

When a DC creates a user or group, it assigns a unique Security ID (SID) to the object.

This SID comprises a domain SID – which is common for all SIDs in a domain, and a RID (Relative ID) – which is unique for every security principal SID present in a domain.

Every single Domain Controller within a domain is given a pool of RIDs which they can assign to each new security principal created.

If a DC’s RID pool goes below a preferred limit, it requests for extra RIDs from the RID master of the domain.

The RID master then retrieves unused RIDs from the domain and allocates them to the pool of the DC that’s requesting. Each directory has one RID master per domain.

PDC Emulator

PDC Emulator is a crucial FSMO Role needed to sync time across an enterprise.

Windows features the W32Time (Windows time) service when using Kerberos authentication protocol.

This time service uses hierarchical relationship to control authentication and use of proper common time across computers. All Windows-based PCs use a common time across an enterprise.

The PDC Emulator in the root of the forest is authoritative for the enterprise and you need to configure it to collect time from an external source.

On the other hand, the PDC emulator of a domain is authoritative for that domain. All PDC FSMO role domain controllers follow the hierarchy of domains to select their in-bond time partner.

There is one PDC Emulator present in every domain of an AD, as it is a domain-wide role.

In a domain, the PDC Emulator Role holder handles following functions:

  • Password Change Updates:
    Password changes done by DCs in the domain are copied to the domain’s PDC emulator. If any account tries to authorize against DC that is not yet updated with recent password change via scheduled replication process, then this request is passed through the domain’s PDC Emulator. This PDC Emulator will instruct the requesting DC to either grant or reject the authentication request. Such behavior ensures reliability, even if the password changes are yet to be updated through replication.
  • Group Policy Objects:
    All GPO (Group Policy Object) updates are handled by the PDC Emulator in the domain. This prevents versioning disputes between domains.
  • Backward Compatibility:
    The PDC Emulator works similar to single-master behavior of primary DC in Windows NT. To solve the backward compatibility problems, the PDC Emulator registers as the target DC for specific admin tools that do not know multi-master behavior of DCs and legacy applications that carry out writing operations.
  • Time Synchronization:
    Each PDC Emulator is the master time source of its domain. And, the PDC Emulator in the forest root domain is the preferred NTP server in the forest. In every domain within a forest, the PDC Emulator will sync it’s time to the PDC Emulator in the forest root. Other non-PDC domain controllers sync their time with the PDC Emulator in their domain. And lastly, the domain-joined hosts sync the time with their preferred DC.
  • PDCE also handles authentication failures occurring at a DC in a domain due to incorrect passwords. These failures are sent forward to the PDC emulator. Then later on, the bad password failure message is shown to the user.
  • PDC emulator processes account lockouts, as the entire failed password authentications go through it.
  • It performs all functionalities performed by previous PDCs for Windows NT 4.0 or earlier clients.
  • Infrastructure Master

When an object references another object in another domain, it is denoted by the GUID (Globally Unique Identifiers), SID (Security ID), and DN (Distinguished Names) of the object that is being referenced.

So the Infrastructure FSMO role holder is the DC that will update the SID of an object and its distinguished name in the cross-domain object reference.

The Infrastructure Master role does the job of translating GUID, SIDs, and DN between domains.

Note: The IM FSMO role should be held by a DC that does not run on a Global Catalog server. Because if it does, it won’t be able to update object information as it doesn’t have any references to cross-domain objects. This is due to the fact that a Global Catalog server has a partial copy/replica of each object in the root of the forest.

Wrap Up

FSMO makes sure that the given domain is powered with adequate functionalities to perform its primary function of authentication efficiently. It makes sure the domains in your AD perform authentication and authorization procedures without any interruptions.

Every FSMO role is present only once in a domain or forest, hence, it is important to learn their individual responsibilities, location, and how their presence impacts the performance of the domain.

With this post, we hope you’ve got deeper insights into the FSMO roles and how they work in Windows Active Directory.