- I. Overview
- II. RID Manager$ Object
- III. Viewing the RID Pools Assigned to Domain Controllers
- IV. Effects of Restoring a DC
- V. Other Behavior Observed when Restoring a DC
- VI. What Happens When RID Pool is Exhausted and RID Master is Offline?
- VII. Additional Reading
I. Overview
The RID Master is one of the five FSMO roles a DC can hold. The RID Master is responsible for assigning pools of RIDs to domain controllers in the domain.
When you create a security principal on a domain controller, that object is given a unique SID that is used to identify the object in the domain. That SID is then what is recorded in ACLs of resources such as shared files and folders to define the permissions granted to a specific user account for example.
The SID is actually made up of two components. The first is a domain identifier that identifies the domain the object was created in. All security principals in a domain share this component. The second part is the RID (or relative identifier) which is what ends up making a SID unique.
S-1-5-21-3246363495-775839057-2928970594–1157
The above SID, is an example I pulled from a user account in my test domain. All SIDs start with S-1-5-21. The italic portion (3246363495-775839057-2928970594) is specific to the domain. The bold portion (1157) is the RID in this case. On a side note, viewing the SIDs of objects can be a bit of a challenge. If you use ADSIedit, and view the properties of a security principal, there is an attribute called “sid” that as far as I know is always empty. What you are really looking for is the “objectSid” attribute and even this is tough to read because it is stored in an array.
I found a script posted by Richard Mueller over at http://forums.techarena.in/active-directory/434301.htm that lets you view the SID more easily.
Anyway, back to the RID Master. Obviously we need a way to keep track of what RIDs have been assigned so that when a DC tries to create a security principal it can be sure that the object will receive a unique SID.
The RID Master is the one DC in the domain that assigns all other DCs a pool of RIDs. In the case of Windows 2003 and later, the RID Master gives each DC a pool of 500 RIDs. Once the DC has a pool of RIDs, it can create security principals until the pool is exhausted. Once all the RIDs in a pool are used, the DC cannot create any more security principals until it receives a new pool of RIDs from the RID master. Actually in the case of Windows 2003 and later, the DC does not wait until it has exhausted all RIDs before requesting a new pool. The DC will actually request a new pool once it has used 250 of the RIDs from the current pool.
II. RID Manager$ Object
You can view the actual RID Master object in the directory by using ADSIedit. It is located at “CN=RID Manager$,CN=System,DC=domain,DC=tld”
An interesting property of this object is the fSMORoleOwner attribute whose value is the distinguished name of the NTDS Settings object of the domain controller that is currently assigned the role of RID operations master. When you transfer or seize the role, this will be updated accordingly to the new owner.
The other interesting attribute of the RID Manager$ object is the rIDAvailablePool
rIDAvailablePool is an attribute of the RID Manager$ object that is replicated to all DCs in the domain. It is this attribute that the RID master uses to keep track of what the next pool of RIDs that can be assigned to a requesting DC is. If you want to know this yourself, you will have to use LDP’s large integer converter tool. Plug in the rIDAvailablePool value and you will get two numbers: a high part and a low part.
The high part indicates how many RIDs can actually be created in the domain (which is constant). The low part indicates the starting RID for the next pool. In the case of the above picture, if a DC in my domain requested a new pool of RIDs, it would receive RIDs from 2103 – 2602 (remember RIDs are assigned in pools of 500).
III. Viewing the RID Pools Assigned to Domain Controllers
Each domain controller object has a child object called “RID Set” that keeps track of the RID pools it has been assigned as well as the last RID it used for the last security principal created on that domain controller. The “RID Set” object is located at “CN=RID Set,CN=domaincontrollername,OU=Domain Controllers,DC=domain,DC=tld”
Remember, a domain controller requests a new pool of RIDs even before it has exhausted it’s current pool. As a result, a DC needs to keep track of information about two pools.
The current pool being used to assign RIDs to newly created security principals is stored in the rIDPreviousAllocationPool attribute (kind of a misnomer right?). If you plug in the value of this attribute into the LDP large integer converter tool, you’ll get some information about the current pool.
In the above picture, the low part is the starting RID of the current pool and the high part is the last RID of the current pool.
The next attribute of interest when looking at RID pools is the rIDAllocationPool. This attribute actually stores the pool of RIDs that will be used once the current pool is exhausted. Again if you plug the value into the LDP large integer converter, you will see the starting and ending RID for this pool.
The rIDPreviousAllocationPool is not replicated. However, the rIDAllocationPool is replicated. This means that all domain controllers in the domain know what the last set of RIDs assigned to a particular domain controller was. This information is used when you seize the RID master role. You’ll see a message to the effect of “searching for highest RID pool in the domain” when trying to seize the role.
Finally, we have the rIDNextRID attribute. This is also a non-replicated attribute (meaning only the local DC knows about it). The value of this attribute is simply the last RID the domain controller assigned.
IV. Effects of Restoring a DC
When you restore a domain controller through a supported means such as restoring the System State with ntbackup, upon booting, the restored domain controller will request a new RID pool. Note please, the “supported means” portion of the previous sentence. This means not restoring from an image. DCs should not be restored from images for a variety of reasons one being that the DC will not mark it’s RID pool as invalid and thus won’t request a new RID pool from the RID master.
It should also be apparent then that when restoring a domain controller, the RID operations master must be online and reachable by the restored DC. If not, you will see event ID 16651 indicating that a request for a new account-identifier pool failed. If you try to create security principals on this domain controller, you will see the following error:
You won’t be able to create security principals on this domain controller until it can contact the RID master and receive a new pool of RIDs.
V. Other Behavior Observed when Restoring a DC
In testing, I had 3 DCs in a single domain environment called DC1, DC2, and DC3. Only DC1 was a global catalog and held all FSMO roles. I turned off DC1 and DC2 and did a restore of DC3 to see what would happen when I restored a DC and it could not contact any other domain controllers in the domain.
When no other DCs were available when the restored DC was brought back online, opening AD Users and Computers would give an error that the domain did not exist.
ADUC did allow me to connect to the local domain controller by choosing “Connect to Domain Controller,” but I could not create new accounts (obviously because the RID master wasn’t online to allocate a new pool of RIDs) or edit Group Policies. Also, clients could not log on to the domain and event ID 5719 was logged on the client:
I then powered on DC2 (again a non-GC, non-FSMO machine) and the restored DC replicated any changes since the backup and began acting as a domain controller again.
Thus, I would conclude when restoring a DC, it must replicate inbound changes when it boots up or AD will not operate. If it can only replicate with a partner that is not the RID master, replication will bring the restored DC up-to-date and the machine can function as a domain controller (ie, process authentication requests). However, as mentioned earlier if a RID master can’t be contacted, new accounts cannot be created on that DC.
Update: OK, this is foolish, but I just realized the reason the restored DC will not act as a domain controller is because the SYSVOL folder was not replicated. See, by default when you perform a non-authoritative restore of the System State, you also perform a non-authoritative restore of SYSVOL. Specifically, in my case when restoring with NTBackup, the BurFlags registry key was set to 0xCA (meaning a non-authoritative restore).
When the NTFRS service starts at the next boot, it sees that it is non-authoritatively restored and thus must replicate with partners to restore the SYSVOL share. Because no other DCs were online, no replication could take place and SYSVOL was unavailable. If the SYSVOL folder of a domain controller is unavailable, that DC will not advertise itself as a domain controller.
You can see this error from DCDiag and NetDiag:
If you want the restored domain controller to act as a DC when no other DCs are online, you will have to set BurFlags to a value of D4 indicating an authoritative restore. SYSVOL will then be available and the DC will act as a domain controller. Of course, if you bring your other DCs online, their SYSVOL will be overwritten by the contents of the restored SYSVOL folder since you marked it as authoritative.
VI. What Happens When RID Pool is Exhausted and RID Master is Offline?
Again, I had DC1, DC2, and DC3 in a single domain environment. DC1 held all FSMO roles and was the only GC. I turned off DC1 and DC2 and then on DC3, I exhausted the RID pool. After doing this, when trying to open ADUC, I would get an error that the domain did not exist.
I could use the “Connect to Domain Controller” option of ADUC to connect to the local server, however.
Also, clients would get a strange error message as well. First, logons would not be processed and in the event log, there was event ID 5790 stating “An NT4 or older domain controller is available.”
I tried restarting both the DC and client and got another strange response. After restarting, ADUC seemed to work and my client machine seemed to logon OK as my login script configured in a GPO was processed OK. However, in the event log, I saw event ID 3210 saying “this computer could not authenticate with” my domain controller.
So what to conclude from this? I would say, exhausting the RID pool and not being able to contact the RID master to get a new pool can have more of an impact than just being unable to create security principals on the local domain controller. From my tests, it seems that the ability to process logon requests is also unreliable on the local domain controller.
I am unsure as to why this behavior was experienced, especially the event logged about an NT4 domain controller being available and also the computer not being able to authenticate even though I was able to log on and group policy was processed OK. It is certainly not what I would have expected.
VII. Additional Reading
Description of RID Attributes in Active Directory
http://support.microsoft.com/kb/305475
Error message: “Windows cannot create the object because the Directory Service was unable to allocate a relative identifier”
http://support.microsoft.com/kb/822053
Event ID 16651 — RID Pool Request
http://technet.microsoft.com/en-us/library/cc756699%28WS.10%29.aspx
Event ID 16650: The account-identifier allocator failed to initialize in Windows 2000 and in Windows Server 2003
http://support.microsoft.com/kb/839879
standalonelabs 