Virtually every administrator who works with Active Directory Domain Services is aware of the existence of operations wizards, abbreviated as FSMO. In addition, we all know that there are two roles for forest-level operations wizards (a schema master and a domain naming wizard), as well as three domain-level operations wizards (a relative RID identifier wizard, a PDC main controller emulator and an infrastructure master).

I suppose most system administrators are aware that the RID master role is used to manage a pool of RIDs in order to create security identifiers (SIDs) and is responsible for moving objects from one domain to another. Thus, the RID Operations Master is responsible for maintaining a pool of relative identifiers and providing groups of relative identifiers to each domain controller. In this article I plan to talk about what these relative identifiers are, how the relative identifier (RID) actually differs from the security identifier (SID), and also about how the RID pool can be managed.

Before defining relative identifiers, let us recall what are the objects of identification. Identification objects are representations of entities that perform some actions on the network. It turns out that computers or groups that perform various operations must be represented by identification objects. And before considering the assignment of relative identifiers, it is necessary to briefly indicate what the security identifiers are, which, of course, are closely related to the RID identifiers.

SID Security ID

A security identifier (SID) is a unique variable length value that is used to identify a principal or security group. For example, security identifiers are used in access tokens. What does this look like? In the access token, one SID will identify the user, and all its additional security identifiers should identify the security groups to which this user belongs. For example, to identify the security identifier for a user account on a computer, you can execute the command wmic useraccount get name, sid in the command window; sid) or in the registry editor, go to HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ ProfileList. Here you can also find the security identifier for your account 

Note that for user accounts or groups, the identifying SIDs are unique. Therefore, in the case of both local and domain user accounts or groups, you will not find identical security identifiers, even if we are talking about remote objects. Moreover, SIDs created in one enterprise domain will never match security identifiers created in another domain. Thus, even if the user who was assigned a specific security identifier, quit his job and his account was deleted, and then he decided to return, then when you re-create his account, a new SID will be generated.

In addition, SIDs are used in security descriptors and access controls. In the case of security descriptors, one SID will identify the object owner itself, and the other will identify the main group to which this object owner belongs. And in the case of access control access control entries (ACE), each such item will include a security identifier associated with the user or with a group for which access will be either allowed or, conversely, denied.

During the creation of a user or group account by the operating system, a security identifier is also generated, which in turn will identify this account. For local accounts, security identifiers are created on a computer using a local security system (LSA) and stored in a secure area of ​​the registry. In the case of Active Directory objects, SIDs are created by the domain security service and are stored in Active Directory as attributes of a User or Group.

What do security identifiers look like? If we look at the structure of security identifiers, we can find that SIDs are structured data represented in binary format and include a number of values. In fact, the SID itself can be considered as a very long identifier for a user account. First, the values ​​that define the structure of the security identifier are specified, and then the data defining the SID issuance service, the domain that issued the security identifier, and the security group are entered in a hierarchical order. Consider these values ​​in more detail on the example of SID.

Here we can highlight the following values.

  • Literal prefix with revision. The letter S is called a literal prefix; it indicates that the string is a SID. The following value, called revision, determines the version of the security identifier structure used in a particular SID. In all security identifiers created in Windows NT and all subsequent versions of Windows, the revision level is 1. Therefore, each SID starts with S-1.
  • Service ids. The following is a six-byte value, which is called an identifier service. This value represents the highest level of service issuing a SID for any security principal. Typically, the security service value for user accounts or groups created in operating systems starting with Windows NT is 5, that is, it is NT Authority.
  • Parts of the security identifier subauthority.This part of the SID is the most important and interesting. Typically, in this part of the security identifier you can find several such subauthority values, which in turn identify the organization’s domain. This part is also called the domain identifier. It turns out that the domain identifier is a series of subauthority values ​​from sub1-subn, usually consisting of the first value 21, which is the root value of the subsequent subauthority. It is followed by a 96-bit random number, which is divided into three blocks of 32 bits each. The benefit of this part of the security identifier is especially noticeable when several domains are created in the organization’s forest. The domain ID of the SID issued by one domain will necessarily be different from the domain ID of the SID issued by another domain. In other words, an organization cannot have identical domain identifiers for different domains. For example, in this example, the domain identifier is S-1-5-21-705789055-1138749243-1717242729. In order to get the domain security ID, you can run the following command on the PowerShell command line:
import-module activedirectory
(Get-ADDomain) .DomainSID.value;
  • Relative RID. The last 32-bit value of the security identifier impersonates a specific domain user or group account. This value is called a relative identifier. I will tell about it in more detail a little below, and now I will only note that it is thanks to the relative identifier that you can distinguish one account or group from all others in the domain. Please note that it is not possible to find two accounts that have the same relative identifier within the same domain. For example, in this case, the relative identifier 1108 is assigned to the DCAdmin account.

By convention, the SID can be broken down as follows:

S-1- <identifier service> -
   -- ... --

Please note that on every computer that is a member of both the domain and the regular workgroup, on Windows operating systems, starting from Windows NT, there are groups included in a specific Builtin domain. These groups include local Administrators groups or, say, Archive Operators. Since such groups have a local scope exclusively within the accounts of one computer, they must be identical on all computers. Therefore, the built-in user accounts and groups should always have the same value of the domain ID. This value is 32, and it implies an embedded domain. And in order for built-in accounts and groups, the operating system can be distinguished from each other within the local computer and the built-in domain,

Thus, in Windows operating systems, relative RIDs up to a value of 1000 are considered reserved by the system. For example, all local accounts from the built-in administrator groups are assigned RIDs ranging from 500 to 599. And for new user accounts and groups, RIDs are already assigned starting from 1001. For example, the security identifier for the Hyper-V Administrators local group looks like this: S-1-5-32-578.

If you look at security identifiers in terms of controlling access to resources, Windows doesn’t make any distinction between assigning a SID to a group or a user account. Please note that changing the name of the user, his computer, or even the domain does not change the base SID for such an account. Moreover, for this account, even the administrator will not be able to change the SID. As a rule, administrators do not even know the user security identifiers, as this is not necessary for them. In essence, security identifiers are primarily intended for the internal operation of the operating system and, as noted above, are responsible for ensuring the unique identification of accounts in the domain.

If you want to view the SID for an account in an Active Directory domain, you need to localize the objectSid attribute, the value of which is the security identifier generated for the account you selected or the sIDHistory attribute, which is the SID that was stored on the old domains.

Learning RID

We dealt with security identifiers; now we can proceed to the definition and assignment of relative identifiers Relative Identifier (RID).

As we found out, relative identifiers are part of the security identifiers that define the user or group accounts and guarantee their uniqueness. In addition, I mentioned RIDs reserved by the Windows operating system. As you understand, relative identifiers can be created in two ways: on the local computer, which is included in the working group, and in the domain environment. How exactly are RIDs generated?

In the case of local user accounts or groups, the process of generating relative identifiers is fairly transparent and should not raise any questions. On computers in a workgroup, all accounts (both users and groups) are stored in the accounts database, which in turn is managed by the Security Accounts Manager (SAM) Security Account Manager. Due to the small number of accounts and the lack of the need to replicate them to other computers, it will not be difficult for the SAM controller to track all relative identifier values ​​that have ever existed on this computer and create new identifiers that have never been used.

In turn, in the domain environment, the picture is somewhat different, and the process of generating RID identifiers itself is a more complicated and laborious procedure. As we know, all user accounts and groups in the domain environment are stored in a database on an Active Directory domain controller. As a rule, several domain controllers are located in each domain, and each such controller must keep an up-to-date database. You should also remember that on each domain controller, the account database is considered to be a primary copy rather than an additional one. Therefore, new user or group accounts can be created on any domain controller within their domain. Immediately after this, information about the new account should be replicated to each domain controller in the current domain.

In Active Directory, the domain-level operations wizard, the RID Relative Identifier Wizard (RID Master), is responsible for the process of creating relative RIDs. Such a master of operations is assigned to only one domain controller, and its main task is the distribution of a sequence of relative identifiers for each controller in the domain. It turns out that when a new account is created on the domain controller, this domain controller will assign a SID to it, and for this SID, the relative RID will be taken from the pool of relative identifiers issued to this domain controller. Since a unique RID is placed on this domain controller, after the account is replicated to other domain controllers, there will be no conflict with the assigned relative identifier.

Each domain controller on which accounts were created ensures that after using the unique relative identifier from its pool, it will never assign the same RID to another account in the future. The RID Operations Wizard, in turn, ensures that after assigning a specific block of relative identifiers, it will not allocate these values ​​to anyone else. Thus, consistency of relative identifiers is implemented in the domain, and each account will have its own unique RID and, as a result, the SID.

The RID Operations Wizard can use the 31-bit global RID space and have 2 billion relative identifier values ​​(that’s 231, that is, 2,147,483,647). On operating systems prior to Windows Server 2012, the size of the global RID space was limited to 230 (that is, 1,073,741,823) RIDs. When this limit was reached, the creation of new security identifiers was possible only after the domain was migrated or the entire Active Directory forest was restored.

When the RID source is exhausted on the domain controller creating accounts, the domain controller sends a request to the RID master to get another block of relative identifiers. By default, Active Directory domain controllers are allocated a block with 500 relative RIDs, but this value can be increased, as discussed below. Thus, it is possible to calculate the number of allocated RIDs. For example, if five domain controllers are deployed in your organization, they will immediately be allocated 2500 relative identifiers.

Now, as a summary of this section of the article, based on all the above, let’s define what distinguishes the security identifier from the relative identifiers:

  • if the SID is intended to identify a user account or group, the RID is only a fragment of the security identifier responsible for the uniqueness of the SID itself for the entire domain;
  • the security identifier can be generated on any domain controller during the creation of the object itself, and relative identifiers in order to avoid conflicts during replication are issued by blocks to each domain controller by the RID master;
  • since each domain controller has a limited unique RID block, the generated security identifiers are never repeated and will not be reused after deleting and re-creating the account;
  • Each domain controller has a database of accounts, and each such database is considered to be the main one.

Relative ID Management

Now that we’ve covered the definition and assignment of security identifiers (SIDs) and relative identifiers (RIDs), we can proceed to the basic operations that are performed with relative identifiers. There are not so many RID management operations, so for convenience, you can divide them into the following categories:

  • checking available RIDs in the domain;
  • restriction on the block size of relative identifiers;
  • control of the upper threshold of the RID;
  • unlocking a pool of relative RIDs.

Consider each of the operations in order.

Check available RIDs in the domain

The operation associated with checking the available relative RIDs may be performed in different cases. Perhaps you are a new Active Directory administrator and want to find out how many RIDs were issued and how many more domains can give out. Perhaps you need to check whether the 31st digit has been unlocked in the domain to increase the global pool to 2 billion RIDs. The reasons may be different. This value is located in the SidCompatibilityVersion attribute in the context of the RootDSE of each domain controller. However, this attribute is hidden and you cannot view its value with a tool such as LDP or with the tools of the ADSIEdit editor. To do this, you should use the command line features.

You can enter the DCDiag.exe command with the / TEST parameters: RidManager and / v. In this case, the following data will be displayed:

  • available RID pool for your domain;
  • name of the RID operations master;
  • server availability;
  • the range of all available relative identifier pools;
  • range of the previous pool of RIDs;
  • the next RID to be issued.

If you only need to know the available pool of relative identifiers, then the rest of the information is not needed. In order to limit the output of the command to only one line, you need to use the additional parameter find / i “Available RID Pool for the Domain”, which should be specified after the pipeline. Thus, you should have such a command (Figure 3):

DCDiag.exe / TEST: RidManager / v |
   find / i “Available RID Pool for the Domain”

If you are trying to completely switch to Windows PowerShell to perform various operations and do not want to resort to command line capabilities, you should use the script written by Brad Rutkowski, or prepare such a script yourself. An example of such a scenario is shown in the listing .

Restriction on block size relative identifiers

As already noted, by default the RID relative identifier wizard allocates blocks of 500 identifiers to each domain controller. In principle, in most cases this amount is sufficient and can be not changed. However, you may need to increase the block size. To do this, make changes on each controller within your domain. Go to the registry editor and in the HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ NTDS \ RID Values ​​section, change the RORD Block Size value of the DWORD type.

Note that for some time now (to be more precise, with the release of Windows Server 2012) it is forbidden to specify an arbitrary value for this parameter. Why is that? Previously, the only limitation was the limit value for the DWORD type, that is, 0xffffffff, which corresponds to 4,294,967,295. As we can see, this value is twice the total global size of the relative identifier space (and taking into account the unlocked pool). Consequently, it was possible to assign such a block size that when adding a new domain controller, the RID master simply could not assign it a block of relative identifiers. Now, this misstep is no longer possible. Starting with Windows Server 2012, the maximum threshold for this parameter is 15,000 in decimal notation. If you try to enter a value,

If you want to immediately predetermine the value of this registry key on all domain controllers, I recommend using the Group Policy features. To do this, in the Group Policy Management Editor, generate a new GPO object that will be linked to the Domain Controllers department, and in the Group Policy Management Editor snap-in, create a registry preference item, where as the values ​​for the parameters, specify the appropriate registry branch, the registry key and the above parameter. As its value, for example, you can specify 0x3A98 (which is 15,000 in the decimal number system). The dialog box for this preference item is 

RID high threshold control

To avoid problems associated with the issue of relative identifiers by domain controllers, a threshold for the global relative identifier space is provided in Active Directory. It works as follows.

Active Directory Domain Services has a default threshold of 10% of the remaining global relative identifier space available. In other words, when the RID master issues 90% of all its relative identifiers (by default it should give out 230 – 1 × 0.90 = 966 367 640 RID or, in the case of an unlocked 31-bit space, 1 932 735 282 relative identifiers) , it will stop allocating RID blocks to domain controllers until the upper threshold is redefined. At the same time, an event with the identifier 16 657 will be generated in the event log (in the System log from the Directory-Services-SAM source). Moreover, the relative identifier wizard sets the msDS-RIDPoolAllocationEnabled attribute to FALSE.

However, despite all this, domain controllers can continue to assign relative identifiers to new objects. When the value again reaches 10%, another event will be generated. Thus, in the case of 30 bits, 110 events can be created, and in the case of 31 bits, 117. The last event will be generated when the RID master has only 100,000 RID left to issue. After this stage, domain controllers will be able to generate as many objects as necessary until their RID identifier blocks run out.

Up to this point, when the RID master has 1% relative identifiers up to the threshold value, an event 16,656 will be generated on all domain controllers in the Directory-Services-SAM log, signaling to the system administrator that it is time to take some action. there is a possibility.

If necessary, you can unlock the issuance of RIDs after exceeding the threshold value, thereby allowing the domain controllers to continue issuing identifiers. For this, the above attribute is set to TRUE. However, remember that, although the threshold value will not be applied in the future, the global RID space may someday end, with corresponding consequences.

Do the following:

  1. Navigate to the domain controller that has the RID Operations Wizard role, and open the LDP.exe utility with administrative rights on it. Remember that this domain controller must have at least Windows Server 2012 operating system installed.
  2. In the utility menu, select “Connection” (Connection), and then “Connect” (Connect). In the dialog that opens, enter the name of the RID wizard in the corresponding text field and click OK. Then from the same section of the menu, select the binding option for the current user (note that if you are not logged in with a domain administrator account, then in the dialog box that opens, you will have to specify such an account).
  3. In order to be able to quickly localize the container you are looking for, select the Tree mode in the View menu and specify the naming context for your domain in the corresponding text box. In my case, this would be “DC = Biopharmaceutic, DC = local”.
  4. Now you can locate the object in the navigation pane. In this case, we need to expand the CN = System container, and then select the item to modify the CN object = RID Manager $ from the context menu.
  5. In the dialog box, in the Attribute text box, specify the msDS-RIDPoolAllocationEnabled attribute to change. In the Values ​​text box, specify the value TRUE. In order for the attribute to be changed, you need in the “Operation” group to set the switch to the “Replace” option and then press the “Enter” button. Changes should appear in the list of values ​​field. Next, make sure that you check the boxes next to the Synchronous and Advanced options (Synchronous and Extended), and then click the Run button. As shown in Figure 5, the following text should appear in the information output area:
*** Call Modify ...
   (ld, 'CN = RID Manager $, CN = System,
    DC = Biopharmaceutic, DC = local ',
   [1] attrs, SvrCtrls, ClntCtrls);
Modified "CN = RID Manager $,
   CN = System, DC = Biopharmaceutic,
   DC = local ".

This means that all actions are performed successfully.

Unlocking the pool of relative RIDs

The last operation in this article is related to unlocking the pool of relative identifiers. As already mentioned, by default in the Active Directory domains, the global RID space is set to 230 identifiers in the RID relative identifier wizard. Starting with Windows Server 2012, you have the opportunity, if necessary, to expand the size of the global RID space by unlocking the 31st digit. As mentioned above, in this case 2 147 483 648 relative identifiers will become available for you.

However, before unlocking this digit, pay attention to the fact that even in a company like Microsoft (according to an official source), a little more than 8 million RID identifiers are used. Therefore, as practice shows, in most cases you will not have to perform the steps listed below. Therefore, before performing these actions in a production environment, I would recommend that you first check how many RIDs have already been issued in your organization. Also note that once you unlock the 31st digit, you will not be able to undo these actions, and as the only possible way to undo the changes, you will have to restore from backup copies, which can obviously cause some inconvenience.

To perform an unlock operation, you will have to change the value of the SidCompatibilityVersion attribute, which initially you cannot find using standard tools. To change it, as in the previous case, the utility LDP.exe will be used.

So, to perform the unlock operation of the pool of relative identifiers, perform the following actions:

  1. Open the LDP.exe utility with administrator rights, connect to the server, the RID Operations Wizard, and bind to an account with the appropriate administrative rights.
  2. Without selecting any containers and objects, expand the Browse menu and select the change option.
  3. In the dialog box that is already familiar to the previous subsection, enter the name of the attribute SidCompatibilityVersion in the corresponding text field. Since in this example, the 31st digit is unlocked, the value for this attribute will be indicated 1. Unlike the previous example, the changes we make will not replace the values ​​of the existing attribute, but add a new one. Consequently, in the group of modes you need to set the switch to the option “Add” (Add), and then press the button “Enter” (Enter). Make sure that the changes you made were added to the list of records, and then, by analogy with the previous example, check the boxes for the Synchronous and Advanced options (Synchronous and Extended) and perform the operation. You will be informed about the successful execution of actions in the output area.

To ensure that the global relative identifier space has been expanded, you can go to the event log and look for the Directory-Services-SAM event with EventID 16655 in the System log. As shown in Figure 6, this event shows that -th digit was unlocked.

So, I briefly talked about the performance of various tasks related to relative identifiers (RID). The structure of the SID security identifiers was described in detail, as well as the relative identifiers (recall that the RID is part of the SID security identifier). In addition, we covered the basic operations that a system administrator can perform with an RID. Two methods were described for checking available RIDs in a domain: using a command line utility and a Windows PowerShell script. You also learned how you can change the limit on the size of the block of relative identifiers that are set by default using the group policy features. Next, we looked at the process of unblocking the issuance of RIDs after exceeding the threshold value set in the domain. Do not forget, that these actions are recommended to be carried out only when absolutely necessary. And finally, you learned how to unlock the 31st digit of the global space of the pool of relative RIDs.Listing. Script to view available RIDs

function Get-RIDsRemaining   
    param ($ domainDN)
    $ de = [ADSI] ”LDAP: // CN = RID Manager $, CN = System, $ domainDN”
    $ return = new-object system.DirectoryServices.DirectorySearcher ($ de)
    $ property = ($ return.FindOne ()). properties.ridavailablepool


$ totalSIDS = $ ($ property) / ([math] :: Pow (2.32))    


$ temp64val = $ totalSIDS * ([math] :: Pow (2.32))    


$ currentRIDPoolCount = $ ($ property) – $ temp64val     $ ridsremaining = $ totalSIDS – $ currentRIDPoolCount     Write-Host “RIDs issued: $ currentRIDPoolCount”     Write-Host “RIDs left: $ ridsremaining” }