RID Master Recovery Features

    Everyone knows that all domain controllers are equal, but some are more equal. These special controllers are called Operations Masters or FSMO Masters . Holders of these roles require special attention - you need to plan how to transfer them and when to capture them if something went wrong. If you maintain an Active Directory domain and any of the above is news for you, I highly recommend that you read the article by the link I provided or read about it elsewhere.

    However, there is one role that stands out from everyone - RID Master. Several times I saw people forget about those additional actions that are required when working with this role, and I had a desire to talk about what should be remembered when you restore your Active Directory environment from a backup or take on the RID Master role.

    If you want to remember or, moreover, do not know what rIDAvailablePool and invalidation of the RID range are, then welcome to cat.

    RID Master


    To begin with, let's remember why we generally need a RID Master and what troubles it helps us avoid.

    The security identifier (SID) of each object in the domain has the form - Domain SID-RID. Where the uniqueness of the relative identifier (RID), guarantees the uniqueness of the SID of the object within the domain. If each controller generated RID independently, it would be difficult to come up with a clear and simple mechanism to ensure their uniqueness. If you make one controller responsible for the generation of RID each time you create an object (by analogy with the wizards of the schema and domain naming), then the main plus of the Active Directory multimaster is lost - the ability to distributed storage and change data. Therefore, there is a RID Master in the domain, which allocates RID blocks to each controller and, as a result, each controller can create new SIDs for objects (after all, the block is given to it for sole use), and if the RID Master is turned off or broken, the system will continue to work ,

    Why is it so scary to get several objects with the same SID? To answer this question, let’s take a look at how access control lists (ACLs) and local groups work on domain servers and workstations. Both of them give users rights based on their SID and not their name (which is why sometimes you can see the SID in graphic snap-ins - the system simply could not resolve it to a name that is pleasant for you and shows it as it is).


    That is, if you imagine that in your environment there are two, let's say users, with one SID, then they will receive the same rights. Moreover, the most unpleasant thing is if administrators in two different parts of your domain try to give these two users rights to different resources, then the rights will be issued to this same matching SID and there will be no way to determine who they intended. In general, this is very unpleasant and this should not be allowed, which is what RID Master successfully handles.

    RIDAvailablePool attribute


    Everything is fine smoothly until we try to restore the RID Master from the backup. Here you need to make a digression. There is no need to restore controllers from a backup . In case of problems with the controller, it will be correct to remove it from the domain, rearrange the server cleanly and re-enter it into the domain as a controller. However, there are scenarios where the backup is your only choice. For example, if your entire AD DS infrastructure was destroyed and you need to restore it. What could go wrong?

    RID Master stores role data in the system object DOMAIN \ System \ RID Manager $ :


    The attributes of this object let you know, for example, who is the current RID Master in your domain. We are interested in the rIDAvailablePool attribute :


    It is here that information is stored about which block was issued last and how many more RIDs remain in your domain. The problem is that if your AD infrastructure was restored from a backup, the value of this attribute will become obsolete. At the same time, membership in local groups on servers or in applications is specified by the SID of users and groups. That is, if you leave everything as it is, then new objects will receive the rights of the old. To avoid this, we will have to manually change the rIDAvailablePool value. If you noticed, then in the previous screenshot it has a strange very big significance. The fact is that this value is stored in large integer format and includes both the upper and lower limits of the range. For viewing, you can use any tool for working with the upper and lower parts of large integer values. For instance,Large Integer Converter to ldp in the Utilities section :


    If we want to protect ourselves from conflicts, then the lower part needs to be changed by adding a number to it, obviously greater than the objects in the domain could be created after this backup was taken. For this, no special utilities are needed anymore - how much you want to add to the bottom, how much you add to the attribute, in general.

    Now, our new wizard will issue RID ranges starting from the new value. Are we safe from conflicts? Not.

    RID range invalidation


    Despite the fact that we guaranteed that the new RID ranges would be issued correctly, we still had one problem - our restored domain controller, at the time of the backup, already had its own range. This range has not gone anywhere after recovery and may cause us troubles if used.

    In order to avoid this, we need to carry out an “ invalidation ” operation (if someone has met or knows a more suitable Russian word, then please state it in the comments). To do this, we will use the iRIDPool.vbs script offered by Microsoft. We create this script on our controller and run as administrator. Microsoft kindly warns us that every time we perform such an operation, we reduce the number of theoretically available to us in the RID domain, since invalid identifiers can no longer be used.

    Now we are safe and can continue to restore our environment after what happened (for AD, for example, it makes sense to clear metadata and introduce new controllers into the domain, etc.).

    I hope the article helped you find out or refresh in your memory why, of all the FSMO roles, it is the RID master that requires special attention.

    Also popular now: