RIDs and the RID Master role

This excerpt from Chapter 5 of "The definitive guide to Windows 2000 security" explains how Windows tracks the uniqueness of relative identifiers (RIDs).

Get a glimpse inside Paul Cooke's e-book "The definitive guide to Windows 2000 security" with this series of book excerpts, courtesy of Realtimepublishers.com. This excerpt is from Chapter 5, "Configuring access control." Click for the book excerpt series or get the full e-book.

RIDs and the RID Master role

While some RIDs are hard-coded to create what is known as well-known SIDs, Windows 2000 needs to keep track of all RIDs to guarantee their uniqueness. For a standalone computer on which accounts and security groups are stored in the SAM database, SAM keeps track of all the RIDs that it's used before and makes sure that it never uses them again. Unfortunately, the situation isn't quite so simple for a Windows 2000 domain infrastructure.

Because a Windows 2000 domain can have several domain controllers, the ability to keep track of which RIDs have already been generated gets a bit more complicated. Remember that in Windows 2000, each domain controller can accept requests to create a new account or security group, and each has a replica of AD.

Let's say that Windows 2000 generates RIDs in a domain environment just like it does in a standalone environment except that instead of looking at the local SAM, it looks to AD to determine which RIDs have already been allocated. You and another administrator both want to create a new security group, but you do it on two different domain controllers. When your requests is processed, the domain controller does a quick search and decides that the new RID will have the value 42. At about the same time, the other administrator's request is processed, and another domain controller also searches its copy of AD and sees that the value 42 has yet to be used and decides to use it. Now there are two security groups, in the same domain, with the same RID; thus, there are two security groups with the exact same SID. What happened? Aren't SIDs supposed to be unique within their scope?

The problem lies in the delay in searching AD, picking a new RID, writing the RID, and replicating the change to all AD instances. If you remember the discussions in earlier chapters, this problem sounds like a situation in which a Flexible Single Master Operation (FSMO) role can be used. (For those of you who missed it, I covered FSMO roles in Chapter 2.) In fact, this situation is exactly the type in which an FSMO role, specifically the RID Master role, is used. This role is responsible for allocating sequences of RIDs to each domain controller in its domain. When a new account or security group is created in a domain controller's instance of AD, the domain controller pulls a RID from its allocation of RIDs to construct the new object's SID. As the domain controller uses up its allocation of RIDs, it has to request another block of values from the RID Master.

The RID Master role greatly simplifies things because each domain controller only has to make sure that once it uses a RID from its allocated block, it never uses that value again. Similarly, the RID Master only has to make sure that once it allocates a block of RIDs, it never allocates those values again. This coordination between the RID Master and each domain controller in a domain ensures that each account and security group created in the domain has a unique RID, and therefore a unique SID.

Click for the next excerpt in this series: Well-known SIDs

Click for the book excerpt series or get the full e-book.

Read more on Antivirus, firewall and IDS products