In last post, we have discussed about Infrastructure Master. In this post, we will understand the 2nd Domain level role – the RID (Relative IDentifier) Master. RID Master is mainly responsible to create SID (Security IDentifier) for each and every objects in Active Directory. So before understanding RID, we first need to understand SID. Let’s understand SID.
Let’s assume that we have an Active Directory user named “John Cena”, resides in “WWE” OU and the password is “John@123”. John having read & write access in a folder called “Wrestlemania”. It means John can access all data inside Wrestlemania folder and make any changes.
Now somehow, the user “John Cena” got deleted by mistake. What will happen if I create a new user with same name John Cena, in same OU WWE, with same password “john@123”? Will the new John Cena be able to access Wrestlemania folder? The answer is NO. Now you may ask that when everything is identical in old and new users, why new user won’t be able to access the folder? Let’s know the exact reason.
First of all always remember – Active Directory damn care about your name. AD can identify any object only by a unique identity, called SID (Security IDentifier). That unique identity automatically creates along with the object. Means whenever you create any user, a new ID automatically get created and attached to that user. SID lives and dies with the object. So when you delete any user, by default you delete that unique SID. Since Active Directory only understands SID, it can’t identify the object which has already deleted.
In the above example, all the details in both the users are exactly same except one thing – the SID (and it can’t be). When we try to access anything, for us both users are John Cena only, but for Active Directory both users are different because their SIDs are different.
SID will look like: S-1-6-11-58986841-816247326-1801674531-1766965. We definitely can’t remember that big string, hence we give every object a name so that we (human) can understand and remember it.
So always remember, AD understands only SID which is unique in the entire forest and it lives and dies with the object.
Now how RID Master is related to SID? When we have thousands or object in Active Directory and all are associated with different unique SIDs, definitely there should be a mechanism to to create those IDs. That mechanism is RID (Relative IDentifier). SID can be created with the help of RID and the RID Master controls the process.
When we create our first Domain Controller, by default all roles including RID Master will be in that server only. As we add another Domain Controller, it will immediately ask the bunch of RIDs from RID Master so that it can create objects (along with SIDs). RID Master always provides 500 RIDs in one pool so that the DC can create objects locally. Suppose we have 5 Domain Controllers in a Domain, RID Master will provide a pool of 500 RIDs to every DC. Means every DC can create up to 500 SIDs (objects) with the help of 500 RIDs.
Now the question comes, can a DC only create 500 objects? No, a DC creates hell lot of objects. As any DC consumes 50% (250 RIDs) of the RID pool, it will again request the RID Master for new RID pool and get another 500 RIDs. So, the total RIDs that DC will now have have is 250 + 500 = 750. Again as DC consumes 325 RIDs, it will request another pool of RID and RID Master will give another 500 RIDs which will make total: 325 + 500 = 825 RIDs. This process will go on for every Domain Controller in the domain. So you can say that if any DC is quite old in the infrastructure, it will have good amount of RIDs to create objects.
What if my RID master is down? Well it’s not a mission critical FSMO role as every DC usually has enough RIDs to create new objects. If RID Master is down, DC will continue to create objects till the time it consumes all it’s available RIDs. If a DC has consumed all RIDs and RID Master is still down, you will not be able to create any new object in that DC because DC can’t get another pool of RIDs since RID Master is down. However it’s a very rare scenario.
This is all for this post. Next post will cover the last Domain Level role, the PDC Emulator. Meanwhile your feedback and questions are welcome.