Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Active Directory: Operations Master Roles (contd.)

Continuation to my previous post on FSMO roles.

If the Schema Master role is down it isn’t crucial that it be brought up immediately. This role is only used when making schema changes. 

If the Domain Master role is down it isn’t crucial that it be brought up immediately. This role is only used when adding/ removing domains and new partitions. 

If the Infrastructure Master role is down two things could be affected – groups containing users from other accounts, and you can’t run adprep /domainprep. The former only runs every two days, so it isn’t that crucial. Moreover, if your domain has Recycle Bin enabled, or all your DCs are GCs, the Infrastructure Master role doesn’t matter any more. The latter is only run when you add a new DC of a later Windows version than the ones you already have (see this link for what Adprep does for each version of Windows) – this doesn’t happen often, so isn’t crucial. 

If the RID Master role is down RID pools can’t be issued to DCs. But RIDs are handed out in blocks of 500 per DC, and when a DC reaches 250 of these it makes a request for new RIDs. So again, unless the domain is having a large number of security objects being created suddenly – thus exhausting the RID pool with all the DCs – this role isn’t crucial either. 

Note

When I keep saying a role isn’t crucial, what I mean is that you have a few days before seizing the role to another DC or putting yourself under pressure to bring the DC back up. All these roles are important and matter, but they don’t always need to be up and running for the domain to function properly. Also, if a DC holding a role is down and you seize the role to another DC, it’s recommended not to bring the old DC up – to avoid clashes. Better to recreate it as a new DC. 

Lastly, the PDC Emulator role. This is an important role because it is used in so many areas – for password chaining, for talking to older DC, for keeping time in the domain, for GPO manipulation, DFS (if you have enabled optimize for consistency), etc. Things won’t break, and you can transfer many of the functions to other DCs, but it’s better they all be on the PDC Emulator. Thus for all the roles the PDC Emulator is the one you should try to bring back up first. Again, it’s not crucial, and things will function well while the PDC Emulator, but it is the most important role of all. 

Active Directory: Operations Master Roles (contd.)

This is a continuation to my previous post on AD FSMO roles. I had to wrap that up in a hurry as I was distracted by other things. 

Identifying the FSMO role holders

Easiest would be to use netdom or dcdiag

You could also use ntdsutil (if you can remember the long commands!)

The overall idea with all these commands is the same. You connect to a specified server or any sever in a specified domain. Then you query that server for the FSMO roles it knows of. 

If PowerShell is your friend, then the Get-ADDomain and Get-ADForest cmdlets are your friends. The output of these cmdlets show you the current FSMO role holders:

Finally, if a GUI is your weapon of choice, there’s three different places you will have to look:

  1. In AD Users and Computers, right click the domain and select “Operations Masters”. This will show the RID Master, PDC, and Infrastructure Master – the three domain specific FSMOs.
  2. In AD Domains and Trusts, right click on AD Domains and Trusts and select “Operations Masters”. This will show the Domain Naming Master. 
  3. Open a command prompt or run window, type regsvr32 schmmgmt.dll, then open MMC, add a snap-in called AD Schema and open it, and then right click on AD Schema and select “Operations Masters”. This will show the Schema Master. 

Transferring FSMO role holders

With a GUI transferring role holders is easy. In each of the screens above when you view the role holder there’s also an option to change it. 

To transfer/ seize a role with ntdsutil you first connect to the DC that will now hold the role, and issue a transfer/ seize command. As the names imply transfer is a “clean” way of moving the role, while seize is a seizing of the role. You seize roles when the DC that currently has the role is down/ unreachable and you can’t wait for a graceful transfer. For example: 

When you attempt a seize, ntdsutil attempts a transfer first and if that succeeds then a transfer is done instead of a seize.  

Things are much easier with PowerShell. One cmdlet, and you are done:

A neat thing about this cmdlet is that you don’t have to necessarily specify the role name. Each role has a number associated with it so you could simply specify the number instead of the role name as a parameter. 

  • PDCEmulator is 0
  • RIDMaster is 1
  • InfrastructureMaster is 2
  • SchemaMaster is 3
  • DomainNamingMaster is 4

This is quite convenient when you want to specify multiple roles to be moved. Much easier typing -OperationMasterRole 1,2,3 than -OperationMasterRole RIDMaster,InfrastructureMaster,SchemaMaster

I prefer ntdsutil over PowerShell as it gives confirmation and so I know the transfer/ seize has succeeded. 

The fsMORoleOwner attribute

The commands above show how to view and/ or transfer FSMO roles. But where exactly is the information on various roles stored in AD? Many places actually …

There is an attribute called fsMORoleOwner. Different locations have this attribute present, and the value of this attribute at these locations indicate which DC holds a particular role. (The attribute can be viewed using ADSI Edit or PowerShell).

  • In the domain partition, the DC=domainName container has this attribute. The value there points to the DC with the PDC Emulator role. 
  • In the domain partition, the CN=Infrastructure,DC=domainName container has this attribute. The value there points to the DC with the Infrastructure Master role. 
  • In the domain partition, the CN=RID Manager$,CN=System,DC=domainName container has this attribute. The value there points to the DC with the RID Master role.
  • In the configuration partition, the CN=Schema,CN=Configuration,DC=forestRootDomain container has this attribute. The value there points to the DC with the Schema Master role.
  • Lastly, in the configuration partition, the CN=Partitions,CN=Configuration,DC=forestRootDomain container has this attribute. The value there points to the DC with the Domain Naming Master role.

What this means is that you can change this attribute and effectively transfer the FSMO role from one DC to another. For instance: 

That said I wouldn’t generally transfer/ seize roles this way. For one, I am not sure whether ntdsutil and/ or PowerShell does anything else behind the scenes (maybe replicate the change with priority?). For another, occasionally I have got errors like “The role owner attribute could not be read” when trying to change the attribute. These errors seem to be related to corrupt DC entries in FSMO roles, so don’t push your luck. (Or maybe I wasn’t connecting to the DC currently holding that role – not sure. You have to be connected to the DC holding the role to change this attribute). 

Another thing to keep in mind is that after you transfer/ seize a role the change has to update through out the domain. Once you think of it in terms of the attributes above that makes sense. When a change is made the attribute is updated and that update as to replicate throughout the domain for other DCs to know.

Lastly, I hadn’t realized this before, but FSMO roles apply to each application partition too. They are not only for the domain partitions (as I had previously thought). To transfer/ seize FSMO roles of application partitions one must update the attribute directly as above. 

That’s all for now!

Update: When a DC holding one of the FSMO roles comes online after a reboot it will do an initial sync with its partners before advertising itself as a DC. During this initial sync it will check the fsMORoleOwner attribute to verify that it is still the FSMO role holder. If it still it, it will start advertising its services; if not, it will stop advertising that role. More here …

Active Directory: Operations Master Roles

Active Directory is a multimaster database. Which means it has no single master – any of the domain controllers (the read-write ones) can make changes to the Active Directory database. However, there are some tasks that necessarily need a single domain controller to be the one in charge. You can still make changes from any domain controller, but they will check with a select domain controller to ensure there’s no conflicts in making the change or perhaps ask this Domain Controller to actually make the change.

There are five such tasks where Active Directory behaves as a singlemaster database. For these tasks only a designated Domain Controller can update the database. Mind you, not all tasks need to be performed by the same Domain Controller. A Domain Controller that can carry out a particular task is one that holds the role to carry out that task. All five roles can be in a single Domain Controller, or they can be in separate Domain Controllers. Any Domain Controller holding a particular role is said to be the Flexible Single Master Operator (FSMO) for that task.

As you know a domain is part of a forest. A single forest can contain multiple domains. Two of these roles are held by a single Domain Controllers in the entire forest. Three of these roles are held by single Domain Controllers in the particular domain. Thus a forest with a single domain has 5 roles, while a forest with two domains has 8 roles (2 for the forest and 3×2 for each domain). The roles are automatically assigned when the forest/ domain is created. The first DC in the forest has the two forest roles assigned to it; the first DC in a domain has the three domain roles assigned to it. Administrators who have appropriate rights can then move these roles to other DCs.

Forest-wide roles

These are roles held by a Domain Controller/ Domain Controllers across all domains in the forest. These roles can be on any DCs in the forest, not necessarily the forest root domain.

Schema Master

The DC holding the Schema Master role is the only one that can update the AD schema. The schema is Active Directory’s blueprint. It is what defines the sort of objects the directory can contain and what attributes can be set for these objects. The schema is set at the forest level and shared by all domains in the forest. Administrators rarely need to update the schema except when installing programs that add new attributes to the objects. For instance, Exchange installs require a schema update as the objects now contain additional attributes such as the email address.

The schema itself is stored in Active Directory in a separate partition and replicated to all DCs. The schema partition is an instance of a dMD (Directory Management Domain) class object. All DCs in the forest thus have a copy of the schema and can read it, but only the DC holding the Schema Master role can write to it. This way there can be no conflicts if multiple DCs try and update the schema.

The current version of the schema can be found using ADSI Edit, connect to the Schema context and check the objectVersion attribute.

objectVersion

Via command-line the schema can be checked using repadmin /showattr:

Or PowerShell:

My domain is at the schema version of Windows Server 2012 R2. If I were to install Exchange the schema version will change (each version of Exchange has its own schema version). When I extend the schema or run adprep /forestprep the DC with the Schema Master role is the one that’s responsible. In fact, the adprep /forestprep command must be run on the DC with the Schema Master role.

The “Change Schema Master” right is required to transfer/ seize the Schema Master role to a different DC. By default only the Schema Admins group members have this right.

More about schema and how it works can be found in this TechNet article.

Domain Naming Master

Remember my post on DCDiag where I introduced the Partitions container (CN=Partitions,CN=Configuration,DC=forestRootDomain) in the Configuration NC? This container has objects of class crossRef that are cross-references to all domain partitions/ naming contexts in the forest. Well, the DC holding the Domain Naming Master is the only one that can make changes to this container – which means it is the only one that can add/ remove/ rename/ move domains in the forest and authorize creation/ deletion of application NCs. This way there’s one DC in the forest who is responsible for the forest-wide namespace. Conflicts are avoided as multiple DCs can not make changes here. 

The “Change Domain Master” right is required to transfer/ seize the Domain Naming Master role to a different DC. By default only the Enterprise Admins group members have this right.

Domain-wide roles

These are roles that are held by Domain Controllers in each domain.

PDC Emulator

The PDC Emulator – so named because it emulates a Primary Domain Controller (PDC) of Windows NT domains – has many functions:

  • It tries to maintain the latest password for any account by having all other DCs forward password changes to the PDC. (This can be avoided for PDCs over WAN links via a registry key).
  • If a user authenticates with a DC and fails, before informing the user so the DC will check with the PDC whether password is valid. This avoids situations where the password was changed on a different DC and the one the user is authenticating against isn’t aware of the change.
  • Account lockouts are processed on the PDC.
  • Group Policy Management tools default to the PDC to make changes. (You can choose a different DC however).
  • The PDC in each domain is the primary source of time for that domain. The PDC in the forest-root domain is the primary time source for all these other PDCs – and hence the primary time source for the forest.
  • The AdminSDHolder process I blogged about earlier runs on the PDC.
  • Since Windows Server 2012 DC cloning is supported. This requires the PDC to be online, available, and running Windows Server 2012 or higher.

The “Change PDC” right is required to transfer/ seize the PDC Emulator role to a different DC. By default the Domain Admins and Enterprise Admins group members have this right.

RID Master

Before talking about the RID Master it’s important to talk about RIDs.

Every security principal (i.e. objects to which one can assign security rights – for e.g. users, computers, security groups; but not distribution groups) in Windows has a Security IDentifier (SID). These are unique identifiers used by Windows internally when referring to objects. Both domain and standalone objects have SIDs. 

SIDs have a format like this: S-V-X-(48 bits of domain or standalone machine IDentifier)-(32 bits of Relative IDentifier (RID) value)

  • The underlined part can be thought of as a base SID. It is common for all objects in the same domain or standalone machine. 
  • The “S” is the letter “S”. It identifies what follows as a SID.
  • The “V” stands for the version of the SID specification.
  • The “X” is a number from 0-9. It defines the identifier authority value. For example, some objects (like Everyone) has the same SID everywhere. These are issued by a “World Authority” whose X number is 1. Most other objects – domain and standalone – have a value of 5 which stands for “NT Authority”. This Wikipedia page lists the values and authority.
  • The 48 bits of domain/ standalone machine ID are either assigned by the domain of which the object is a member (in which case it is generated at random when the domain was first created) or are assigned by the standalone computer of which the object is a member (in which case it is generated at random by Windows Setup when the OS was installed). All objects of the same domain/ standalone computer have this part common.Every domain in a forest has a unique ID (this domain ID is actually the machine SID of the first DC of the domain). 
    • There are some exceptions where the ID isn’t unique. For instance, if the object is a built-in user or group, the domain ID is 32 (irrespective of what domain it belongs to). That’s because these are built-in objects and so the domain/ standalone machine part doesn’t really matter. 
  • All the values mentioned above are common to all objects of the same domain/ standalone computer. What follows next – the 32 bits RID – is unique for each object. This is generated as follows:
    • For objects that are part of a standalone machine RIDs are assigned by the machine itself. Some accounts have a standard RID. For example the Administrator account always has RID 500. All user & group accounts start from RID 1000. RIDs are unique within the context of the machine and are assigned by the Local Security Authority (LSA) of the machine. 
    • For objects that are part of a domain the RIDs are assigned by the domain controller where the object was created. Some accounts have a standard RID. For example the Administrator account always has RID 500; Guest account always has RID 501; built-in Administrators group has RID 544; built-in Users group has RID 545; and so on (see this TechNet page for an exhaustive list). RIDs are unique within the context of the domain

And thus we come to the RID Master role. For domain objects the base SID is common for all objects. What varies is the RID. This needs to be unique in the domain. If every Domain Controller could assign a RID of its own there’s no guarantees of uniqueness. So what is required is some way of assigning each Domain Controller a block of RIDs it can assign to objects created on it. And in turn we need one DC that can hand out these block of RIDs and keeps track of what’s free for giving out next. The DC that performs this role is known to have the RID Master role. This DC hands out blocks of 500 RIDs to other DCs in the domain (the value 500 can be modified via registry).

This blog post by Mark Russinovich is a good intro to SIDs (as is this clarification by another blogger – must read if you read Mark’s post). This TechNet page is a good intro to SIDs and RIDs and definitely worth a read. From the latter I learnt that even though SIDs are used by Windows and Active Directory to grant/ deny permissions, Active Directory actually uses its own Globally Unique ID (GUID) to identify objects. These are globally unique (i.e. across the world), and although Active Directory can use GUIDs instead of SIDs it continues to use SIDs for backward compatibility. An object’s SID is stored in the objectSID property; an object’s GUID is stored in the objectGUID property. And, while the GUID is unique for life, the SID changes if the object is moved to a different domain (as that domain has its own domain ID and RID assignments). In case of such SID changes the past SIDs are stored in a property called sIDHistory

Some more bits and pieces on the RID Master:

  • Although there are 32 bits allocated for a RID, prior to Windows Server 2012 only 30 bits could be used. Thus the maximum RID value was 2^30 = 1073741823 (roughly a billion). 
  • The DCDiag command can be used to see RID allocation. The command is: dcdiag /test:RidManager /v – the /v switch is required to see the additional details. 
  • Starting from Windows Server 2012 it is possible to unlock the 31st bit for RID allocation. This requires modifying a hidden attribute. See this TechNet page for more info. Note, however, that Windows Server 2003 and 2008 cannot use these RIDs (Windows Server 2008 R2 can use these RIDs if a hotfix is applied). 
  • Server 2012 also warns for every 10% of the RID space usage (i.e. for every 100 million RIDs allocated). Also, it applies an artificial ceiling of 10% to the RID block – i.e. you can only allocate up to 90% of the roughly 1 billions RIDs. Once this ceiling is reached it has to be manually removed for further RIDs to be allocated (this gives administrators a chance to identify why their RID pool could be nearing exhaustion).  

The “Change RID Master” right is required to transfer/ seize the RID Master role to a different DC. By default the Domain Admins group members have this right.

Update: This is an interesting post worth reading. 

Infrastructure Master

A domain can contain references to objects in other domains. For instance, group members could be users in other trusted domains. If those objects have changes made to them (renames, deletions) in their domain, the domain which contain references to these objects wouldn’t know about these changes. So what is required is for someone to regularly check these references and update the other local DCs accordingly – that’s where the DC with the Infrastructure Master role comes in. 

When a group has members from another trusted domain, the group contains “phantom objects” in place of the actual object of the other domain. These phantom objects cannot be seen in LDAP or ADSI and they contain the Distinguished Name (DN), GUID, and SID of the referenced object in the other domain. When the remote object is added to a group the local DC where it is added creates the phantom object. Every 2 days (the period can be changed via a registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters) the DC holding the Infrastructure Master role goes through all the phantom objects in its domain and checks them against the Global Catalog (GC) (because the Global Catalog contains partial information of all objects across all domains in the forest). If there are changes or deletions it informs the other DCs of this. 

Here’s how the changes are passed on to the other DCs: 

  • The DC with the Infrastructure Master role creates an object of class Infrastructure-Update in the CN=Infrastructure,DC=DomainName container. 
    • If the original object was renamed, then the DNReferenceUpdate attribute of this object contains the new value. 
    • If the original object was deleted, then the DN is updated with a suffix (esc)DEL:GUID. (This is what happens when an object is usually deleted – even in the local domain. It is not really deleted, only “tombstoned” – wherein the object is moved to a special container, its DN is updated like above, and all its other attributes are removed. This way other DCs know the object is now deleted. Only after a certain period is this tombstoned object really removed from the database. Hopefully by this time the information has replicated to all other DCs and they know the object is to be deleted). See this blog post for a screenshot of how the DN looks.  
  • The DC now deletes the object it created. This tombstones the object as I described above (i.e. the DN of this object now has its DN suffixed with (esc)DEL:GUID and all other attributes – except the ones added above – are removed).  
  • The tombstoned object is now replicated to all other DCs in the domain. 
  • The other DCs see this deleted object of class Infrastructure-Update and update their copies of the phantom object accordingly. 

A side effect of the above process is that the Infrastructure Master role cannot be on a DC that’s a GC. If the Infrastructure Master were on a GC, it does not store phantom objects because it already knows of the remote objects (by virtue of being a GC). So there’s nothing to compare, and other DCs won’t be updated with any changes. 

That said, if all DCs in the domain are also GCs, then the placement of the Infrastructure Master role doesn’t matter (as all DCs will all have up-to-date info on remote objects). 

Also, if the Recycle Bin feature is enabled in the forest (for this all DCs must be Windows 2008 R2 and the forest functional level should be Windows Server 2008 R2 or above (as part of raising the functional level the schema is upgraded with some new attributes)) objects aren’t deleted via tombstoning as I described above. Instead, when an object is deleted it is only “logically deleted“. The object is moved to a special container and DN changed as before, but now its other attributes are not wiped, and a flag is set indicating the object that it is deleted and some additional attributes are set indicating how long the object will be kept in the logically deleted state (during which period it can be restored from the Recycle Bin without losing any of the attributes). Moreover, links to the “logically deleted” object are still maintained (because the object can be un-deleted any time). Because of these changes every DC is now responsible for updating references to objects in other domains by itself (I am not sure why!). Thus the Infrastructure Master role is no longer relevant once the Recycle Bin feature is enabled.  

The “Change Infrastructure Master” right is required to transfer/ seize the Infrastructure Master role to a different DC. By default the Domain Admins group members have this right.

The DC with the Infrastructure Master role is where you usually run the adprep /domainprep command. This command prepares the domain for any new DCs of a later version (for example installing a Windows Server 2008 DC in a Windows Server 2003 domain).

There’s some more stuff I wanted to write in this blog post. If I get a chance I’ll make another post with those …