Active Directory Back to Basics - FSMO Roles

Overview

Active Directory runs in a multi-master model meaning that each domain controller within the domain (assuming we are talking about DC’s and not RODC) holds a writeable copy of the AD database. However some functions can’t be achieved easily or practically in a muli-master environment so there is a need to have specific DC’s perform specific roles. These roles are known as flexible single master operations roles, also known as FSMO. In this back to basics posts I’m going to cover the various roles and their associated functions.

There are five roles altogether, some are domain wide while others are forest wide roles. The table below shows the roles and their placement.

PDC Emulator	Domain
Infrastructure Master	Domain
RID Master	Domain
Domain Naming Master	Forest
Schema Master	Forest

We are going to cover each of these in detail.

While each of the roles performs a critical function within AD don’t automatically think that if the server holding one or more of the roles fails your AD will instantly break. I’m going to cover the impact of each role not being unavailable in the relevant sections.

PDC Emulator

Do not get confused with the Primary Domain Controller (PDC) from NT4 days. While the PDC Emulator role (PDCE) does provide some functions the old PDC did, it is in no way the same. Also a common response I hear is that the PDCE is the first domain controller in the domain. Whilst this is true, it is also true of every other domain FSMO role. The first installed domain controller in a brand new standalone domain will get all the FSMO roles associated with it, but it doesn’t mean they need to stay there – moving roles is generally a fairly easy and seamless process.

The PDCE has many key functions including acting as a primary domain controller for down level clients such as windows NT. However two of the more commonly known functions are Time Source and Password Chaining.

Each domain controller in your domain should by default talk to the local PDCE role holder to synch their time. The windows clients will then talk to their local DC for their time. This ensures that all computers and servers have an accurate time source and are in synch across the domain. This is really import for correct functioning of various AD services.

The PDC role holder needs to keep an up to date copy of all passwords. When a user updates their password on a domain controller that is not holding the PDC role, that domain controller notifies the PDC of the password change. It does this through the netlogon service and an RPC call to the PDC. The reason for this is to allow password chaining to occur. Password chaining comes into effect when a user attempts authentication, but the DC picking up the request doesn’t believe the password is correct. That DC then chains the authentication attempt to the PDC to check if the password matches. This feature can be disabled if required by modifying the netlogon registry keys – you can find how to this here.

Additional functions the PDC role holder performs are, being the primary domain controller used by most group policy management tools. This is to reduce the risk of the same policy being edited in different ways across multiple servers.

The PDC role holder is also responsible for running the SDProp process to ensure that all users with the adminSDHolder role have got correct permissions set on their accounts. You can read more about the adminSDHolder function here. 

In Server 2012 the PDC holder is also responsible for domain control cloning requests. For this to function correctly the PDC needs to be running Server 2012 or higher.

Out of all the roles the PDC emulator is probably the most important and the one you would see the quickest impact if it becomes unavailable. Time synch won’t work correctly, group policy management tools will complain, password changes cannot be verified, and if you are using older applications / nt4 clients, they will soon start to have issues.

How does the PDC Emulator FSMO role impact the password policy.

Suppose you had an OU which was blocking inheritance of group policy, and your default domain policy didn’t have any enforcement settings enabled, how do the computers in that OU get to know about the default domain policy password settings?

Lets take a look at one of the other functions of the PDCE FSMO role.

We will start by taking a look in Active Directory using the LDP tool, after connecting and binding to the domain we want to take a look at the domain naming context. To do this we can select the tree from the View menu in LDP.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb12.png

You should now see a your various password settings in the main LDP window. I’ve highlighted the key areas we are interested in.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb13.png

These should be familiar as they have initially been read from the Default Domain Group Policy.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb14.png

Ok, so now lets shutdown the DC holding the PDCE FSMO role and see what happens when we change the password policy within the Default Domain Policy.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb15.png

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb16.png

So we have changed the enforce password history setting from 24 to 12 and the maximum password age from 42 to 30 days.

We will run a GPUPDATE /Force and also restart the DC to ensure all the changes we have made will have applied.

Now lets take another look in LDP at the domain NC.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb17.png

We can see the settings shown in the domain NC are the same as before.

Now lets power DC1 holding the PDCE role back on and see what happens.

Launching LDP and again connecting to the domain and looking at the domain NC we can now see the new password settings have been written to the domain.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb18.png

So there we have it, we can see that the PDCE role also copies the password settings for the domain to the domain NC.

Infrastructure Master

The primary purpose of the Infrastructure Master is to keep objects from other domains up to date. When we reference an object from another domain we reference the GUID / SID and the DistinguisedName. Lets say we had two one forest with two domains. Domain 1 and Domain 2. We had a group in Domain 1 which contains users from both domains. The role of the infrastructure master in Domain 1 is responsible for keeping track of any changes made to the users in Domain 2. It then replicates this information round to any other domain controller that is not a Global Catalog server.

There is always discussions surrounding the placement of the Infrastructure master role. I will cover the Global Catalog (GC) in more detail in another post, but it’s main purpose is to keep an up to date record of a subset of all the attributes for every object within the entire forest. Since the purpose of the Infrastructure master is to keep track of changes to phantom object (objects from other domains), if it is running on a GC it will never see any differences as by its nature the GC should always be up to date. So in essence the Infrastructure Master should not be held on a domain controller which is also a GC. The exception to this is if its a single domain, or if every DC in the domain is also a GC. The table below shows where the IM can be placed. If the AD Recycle Bin is enabled each DC is responsible for updating cross-domain object references.

	Single Domain Forest	All DC’s are GC	All DC’s are NOT GC	AD Recycle Bin Enabled
IM Relevant	No	No	Yes	No
IM OK on GC	Yes	Yes	No	Yes

If the IM role holder becomes unavailable you will see a varying degree of impact to very little or more serious depending on your domain structure. If your domain relies upon having the IM functioning correctly (see table above) you could over time start to see varying degrees of anomalies with objects from cross-domain trusts. You should be aware that adprep /domainprep operations will fail if the role holder can’t be contacted.

RID Master

The RID master plays an important role in the process of object creation. Every security principal in Active Directory requires a SID. A SID is a unique identifier which is made up of several parts. Part of the SID is the RID, which is assigned by the domain controller that created the security principal.

In order to ensure the SID remains unique, each Domain Controller is assigned a pool of RIDS, by default 500. When it has issued half of it’s pool it requests another 500 RIDS to the DC holding the the RID Master role. It then keeps these in a standby pool until the primary set is used.

The RID pool size in Windows 2012 was doubled from approximately 1 to 2 billion RIDS. Once the RID master has issued all it’s RIDS the Domain can no longer create any new objects. This really is a prevention is better than cure type scenario – if you have exhausted all your RIDS you can not create any more security principals in your domain – this would include users, groups, computers and trusts to other domains. If you hit zero RIDs it is pretty much time over for your current domain. There is some very useful information on monitoring RIDS on this blog post.

Its possible to increase the default RID pool size that each DC gets by modifying the registry HKLM\System\CurrentControlSet\Services\NTDS\RID. This is done on the RID master, but should also be done on any other server you may promote to be the RID master.

If the RID master becomes unavailable your domain will continue to function without error. You will only start to see issues when your domain controllers have used their allocated RID pool and can no longer request any additional RIDs from the RID master.

It is recommended that following a domain recovery the RID pool is increased. My AD recovery guide explains how to do this.

Domain Naming Master

The Domain Naming Master is a forest wide role so only one role holder exists per forest. Its primary purpose is to ensure that all domain names are unique. When you promote a domain controller as a DC for a new Domain, the Domain Naming master is consulted to ensure the domain is unique. If the role holder is unavailable you will not be able to create a new domain. It is also used when renaming a domain name or moving a domain within the forest and also when new application partitions are created or deleted.

Although this is a forest wide role it does not need to reside in the forest root domain. It can be on any domain controller within the forest.

Schema Master

I’ve already posted an article about what the Active Directory Schema is. If you haven’t read it you can check it out here. This role is another forest wide role which can exist on any domain controller in the forest. It is responsible for making changes to the AD Schema. When any application, script, or user requests for a schema change / extension the schema master is the domain controller which makes the change.

Its unlikely that if the Schema master is unavailable you will see much impact to your domain / forest until which time you attempt to make any schema changes. If the role holder is unavailable the change will fail.

Role Holder Placement

Many AD administrators panic about the placement of the FSMO roles. My recommendation and preference is to put all the roles on your most current, most powerful DC. It makes managing the roles simpler. If that one DC becomes unavailable you instantly know which services will be affected. However the official Microsoft guidance can be found here.

Moving and Seizing FSMO Roles

There are a few ways to move and seize a FSMO role. Moving a FSMO role happens when both domain controllers, source and target, are available. You seize a role when the source server is no longer available.

GUI tools can be used to move FSMO roles. The Domains and Trust snapin allows moving the Domain Naming role, the schema snapin for the schema, and the remaining three through AD users and computers.

You can only seize roles using the NTDSUtil command, you can find details on my Active Directory Recovery post – section 4 – FSMO recovery. 

Summary

Whilst the majority of functions in Active Directory can be performed by any domain controller, some processes must only be managed by one domain controller. The five FSMO roles play an important part in your Active Directory domains and the servers holding them should be treated with high regard. While most services will continue to function without issue at first it will soon become apparent if you lose one or more roles in your environment.