RID Master Recovery Features
Everyone knows that all domain controllers are equal, but some are more equal. These special controllers are called operation 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 support the Active Directory domain and some of the above for you news, I strongly recommend that you read the article on the link that I brought, or read about it in any other place.
However, there is one role that stands out from all - RID Master. Several times I saw how people forgot about the additional actions that are required when working with this role, and I had a desire to tell what is worth remembering when you restore your Active Directory environment from a backup or capture the role of RID Master.
If you want to remember, or, all the more, do not know what rIDAvailablePool and disability of the RID range are, then welcome to cat.
To begin with, let's remember why we, in general, need a RID Master and what troubles it helps us to avoid.
')
The security identifier (SID) of each object in the domain is - 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 generating the RID each time you create an object (by analogy with the schema and domain naming wizards), you lose the main plus multimaster of the Active Directory system — the ability to distribute and modify 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 the objects (after all, the unit is given to it for its sole use) and, if the RID Master is turned off or broken, the system will continue to work Because the block size allows Active Directory to function for some time without an active wizard.
What is so scary to get multiple objects with the same SID? To answer this question, let's take a look at how access control lists (ACL) and local groups work on domain servers and workstations. Both those and others distribute the rights to users based on their SID and not their name (which is why you can sometimes see the SID in graphical snap-ins - the system simply could not resolve it to your pleasant name and shows it as it is).
That is, if we imagine that there are two users in your environment, say, users with the same SID, then they will receive the same rights. And what is most unpleasant, if administrators in two different parts of your domain try to give these two users rights to different resources, then the rights will be granted to this matching SID and there will be no possibility, later, to determine who they were intended for. In general, it is very unpleasant and it is impossible to prevent this, with which RID Master copes successfully.
Everything is fine exactly until we try to restore the RID Master from the backup. Here you need to make a retreat. Restoring controllers from a backup is not necessary . In case of problems with the controller, it will be correct to remove it from the domain, rearrange the server completely and re-enter it into the domain as a controller. However, there are scenarios where backup is your only choice. For example, if your entire AD DS infrastructure has been destroyed and you need to restore it. What can go wrong?
RID Master stores the role data in the DOMAIN \ System \ RID Manager $ system object:
The attributes of this object let you know, for example, who the current RID Master is in your domain. We are also interested in the rIDAvailablePool attribute:
It is here that information is stored about which block was issued last and how many more RIDs remained in your domain. The problem is that if your AD infrastructure was restored from a backup, the value of this attribute will be 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, the new objects will receive the rights of old ones. To avoid this, we will have to manually change the rIDAvailablePool value. If you paid attention, then on the previous screenshot it has a strange very great value. The point is that this value is stored in a large integer format and includes both the upper and lower limits of the range. For viewing, you can use any tool for working with upper and lower parts of large integer values. For example, 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 to it a number that is obviously greater than the objects in the domain could be created after removing this backup. For this, no special utilities are needed - as much as you want to add to the bottom, as much as you add to the attribute, as a whole.
Now, our new master will display the RID ranges starting from the new value. Have we protected ourselves from conflicts? Not.
Despite the fact that we guaranteed that the new RID ranges will be issued correctly, we still have one problem - our restored domain controller, at the time of the backup, already had its own range. This range has not gone away after recovery and can cause us trouble if it is used.
In order to avoid this, we need to carry out the operation " invalidation " (if someone has met or knows a more suitable Russian word, then voice it, please, 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 it with administrator rights. 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 restoring our environment after what happened to us (for AD, for example, further it makes sense to clear the metadata and enter new controllers into the domain, etc.).
I hope the article helped you learn or brush up on why, of all the FSMO roles, it was the RID master that required special attention.
However, there is one role that stands out from all - RID Master. Several times I saw how people forgot about the additional actions that are required when working with this role, and I had a desire to tell what is worth remembering when you restore your Active Directory environment from a backup or capture the role of RID Master.
If you want to remember, or, all the more, do not know what rIDAvailablePool and disability of the RID range are, then welcome to cat.
RID Master
To begin with, let's remember why we, in general, need a RID Master and what troubles it helps us to avoid.
')
The security identifier (SID) of each object in the domain is - 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 generating the RID each time you create an object (by analogy with the schema and domain naming wizards), you lose the main plus multimaster of the Active Directory system — the ability to distribute and modify 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 the objects (after all, the unit is given to it for its sole use) and, if the RID Master is turned off or broken, the system will continue to work Because the block size allows Active Directory to function for some time without an active wizard.
What is so scary to get multiple objects with the same SID? To answer this question, let's take a look at how access control lists (ACL) and local groups work on domain servers and workstations. Both those and others distribute the rights to users based on their SID and not their name (which is why you can sometimes see the SID in graphical snap-ins - the system simply could not resolve it to your pleasant name and shows it as it is).
That is, if we imagine that there are two users in your environment, say, users with the same SID, then they will receive the same rights. And what is most unpleasant, if administrators in two different parts of your domain try to give these two users rights to different resources, then the rights will be granted to this matching SID and there will be no possibility, later, to determine who they were intended for. In general, it is very unpleasant and it is impossible to prevent this, with which RID Master copes successfully.
RIDAvailablePool attribute
Everything is fine exactly until we try to restore the RID Master from the backup. Here you need to make a retreat. Restoring controllers from a backup is not necessary . In case of problems with the controller, it will be correct to remove it from the domain, rearrange the server completely and re-enter it into the domain as a controller. However, there are scenarios where backup is your only choice. For example, if your entire AD DS infrastructure has been destroyed and you need to restore it. What can go wrong?
RID Master stores the role data in the DOMAIN \ System \ RID Manager $ system object:
The attributes of this object let you know, for example, who the current RID Master is in your domain. We are also interested in the rIDAvailablePool attribute:
It is here that information is stored about which block was issued last and how many more RIDs remained in your domain. The problem is that if your AD infrastructure was restored from a backup, the value of this attribute will be 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, the new objects will receive the rights of old ones. To avoid this, we will have to manually change the rIDAvailablePool value. If you paid attention, then on the previous screenshot it has a strange very great value. The point is that this value is stored in a large integer format and includes both the upper and lower limits of the range. For viewing, you can use any tool for working with upper and lower parts of large integer values. For example, 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 to it a number that is obviously greater than the objects in the domain could be created after removing this backup. For this, no special utilities are needed - as much as you want to add to the bottom, as much as you add to the attribute, as a whole.
Now, our new master will display the RID ranges starting from the new value. Have we protected ourselves from conflicts? Not.
RID Range Disability
Despite the fact that we guaranteed that the new RID ranges will be issued correctly, we still have one problem - our restored domain controller, at the time of the backup, already had its own range. This range has not gone away after recovery and can cause us trouble if it is used.
In order to avoid this, we need to carry out the operation " invalidation " (if someone has met or knows a more suitable Russian word, then voice it, please, 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 it with administrator rights. 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 restoring our environment after what happened to us (for AD, for example, further it makes sense to clear the metadata and enter new controllers into the domain, etc.).
I hope the article helped you learn or brush up on why, of all the FSMO roles, it was the RID master that required special attention.
Source: https://habr.com/ru/post/319330/
All Articles