FSMO Roles

Flexible Single Master Operation Roles (FSMO)

                      Active Directory has five special roles which are vital for the smooth running of AD as a multimaster system. Some functions of AD require there is an authoritative master to which all Domain Controllers can refer to. These roles are installed automatically and there is normally very little reason to move them, however if you de-commission a DC and DCPROMO fails to run correctly or have a catastrophic failure of a DC you will need to know about these roles to recover or transfer them to another DC.

The forest wide roles must appear once per forest, the domain wide roles must appear once per domain.

The Roles    There are five FSMO roles, two per forest, three in every Domain. A brief summary of the role is below.

The Five FSMO roles are:

1. Domain Naming Master 
2. Schema Master 
3. PDC 
4. RID 
5. Infrastructure Master 

PDC Emulator  

The holder of the PDC Emulator role is responsible for the following tasks within a domain where it is authorative for:  

• Provide time service. An accurate time syncronisation is necessary for  Kerberos authentication. Per default, all Windows clients in a domain retrieve their time from the DC owning the PDC Emulator role in their domain. In a multi-domain environment, each PDC Emulator in a domain syncronizes its time with the PDC Emulator at the root of the AD forest. The root PDC Emulator is configured to gather the time from an external source. Windows DCs automatically follow this hierarchy, while Samba DCs ntpd must be configured accordingly.  
• Password changes performed by other DCs in a domain are replicated preferentially to the PDC Emulator.  
• All functionality provided by an NT4-style PDC, is handled by the PDC Emulator. Nevertheless, an AD DC owning this role, is something completely different than an NT4-style PDC! Windows 2000 or later clients don't use that functions.  
• Account lockouts are processed by the PDC Emulator.  
• Authentication failures on any DC in a domain caused of a wrong password are forwarded to the PDC emulator, before the password failure message is reported to the user.  
• The Group Policy Management Console contact the DC owning this rule per default.  

In large environments, the DC owning the PDC Emulator role, can have high CPU utilization because of pass-thru authentication, password changes and time sycronisation.  

There is one PDC Emulator per domain.  

This DC should, if possible, be available all the time, because an accurate time on all machines in a domain is required for Kerberos. If your clients are configured to use a different time source and you don't have pre-Windows 2000 clients, then the temporary absence may be less critical.  

RID Master  

The RID Master role owner is responsible for answering RID pool requests from all DC within a domain. It is also responsible for moving objects into another domain and removing them from a domain.  

All security objects like e. g. user/machine accounts and groups are identified by an SID. The objects SID containts the domain SID, which is equal for all objects within a domain, and an RID, that is unique in a domain.  

To allow security objects to be created on all DCs, each contain a so-called RID pool. This is a range of, per default, 500 domain-wide unique RIDs, assigned from the RID Master to each DC. If a security object is created on a DC, then the RID is taken from this pool, to ensure, that it's unique in the domain. If the threshold falls below 50%, then the DC send a RID pool request to the RID Master. This assignes unallocated RIDs and responds them to the requesting DC.  

There is one RID Master per domain.  

This DC must be online when a new DC is promoted in a domain, to assign a RID pool. Also it must be available, when existing DCs update their standby RID pool.  

On the other side, if the RID Master is offline, then it's only possible to create new security objects on each DC, until it's local RID pool is empty. If the RID pools on all DC gets empty, then no further objects can be created. Also it's not possible to join additional DCs while the RID Master of a domain is offline.  

Infrastructure Master  

The DC owning the Infrastructure Master role is responsible for updating objects SID and Distinguished Names in a cross-domain object reference. This is used for example, if a user from one domain is added to a security group of a different domain.  

There is one Infrastructure Master per domain.  

Even if a Infrastructe Master is irrelevant in a forest with just one domain, the role exists. If this DC is temporary offline, then cross-domain changes aren't possible. 

Schema Master  

The DC holding the role Schema Master is the only one in an Active Directory forest, that is allowed to update the directory schema. Once the update is completed, the changes are replicated to all other DCs in the forest.  

The schema partition, which is existing on all DCs, is named „schema naming context“ and located in CN=schema,CN=configuration,DC=<domain>. Updates are done only on the Schema Master.  

There is one Schema Master per forest.  

This DC must be online when schema updates are performed.  

Domain Naming Master  

The holder of this role is the only DC, that is responsible for changes in the forest-wide domain name space. This means that this DC is the only one which can add or remove a domain, trusts to external directories and application partitions to/from the forest.  

The domain naming information are stored in the partition „Configuration Naming Context“ in CN=Partitions,CN=Configuration,DC=<domain>. This partition exists on all DCs, but is only updated on the Domain Naming Master.  

There is one Domain Naming Master per forest.  

This DC must be online when trusts are established with external directories and domains and application partitions are added/removed to/from the forest.  

Important Note :

Unless there is only one DC in a domain the Infrastructure role should not be on the DC that is hosting the global catalogue. If they are on the same server the infrastructure master will not function, it will never find data that is out of date and so will never replicate changes to other DCs in a domain.

If all DCs in a domain also host a global catalogue then it does not matter which DC has the infrastructure master role as all DCs will be up to date due to the global catalogue.

What is FSMO

What are the FSMO Roles in Active Directory?

FSMO Video Explanation

Windows 2000/2003 Multi-Master Model

A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise, but it also introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise. One way Windows 2000/2003 deals with conflicting updates is by having a conflict resolution algorithm handle discrepancies in values by resolving to the DC to which changes were written last (that is, "the last writer wins"), while discarding the changes in all other DCs. Although this resolution method may be acceptable in some cases, there are times when conflicts are just too difficult to resolve using the "last writer wins" approach. In such cases, it is best to prevent the conflict from occurring rather than to try to resolve it after the fact.

For certain types of changes, Windows 2000/2003 incorporates methods to prevent conflicting Active Directory updates from occurring.

Windows 2000/2003 Single-Master Model

To prevent conflicting updates in Windows 2000/2003, the Active Directory performs updates to certain objects in a single-master fashion.

In a single-master model, only one DC in the entire directory is allowed to process updates. This is similar to the role given to a primary domain controller (PDC) in earlier versions of Windows (such as Microsoft Windows NT 4.0), in which the PDC is responsible for processing all updates in a given domain.

In a forest, there are five FSMO roles that are assigned to one or more domain controllers. The five FSMO roles are:

Schema Master:

The schema master domain controller controls all updates and modifications to the schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.

Domain naming master:

The domain naming master domain controller controls the addition or removal of domains in the forest. This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories. There can be only one domain naming master in the whole forest.

Infrastructure Master:

When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference. At any one time, there can be only one domain controller acting as the infrastructure master in each domain.

Note: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server (GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC's event log. If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role.

Relative ID (RID) Master:

The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.  Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain.