This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(195.2, 76%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMT%3C/text%3E%3C/svg%3E)
In the case of AD accounts, each domain controller has the rIDNextRID attribute, so it is known which RID value is assigned to the next new AD security principle (user, computer, and group) that is created on that domain controller. How to know the same on Windows that is not a domain controller? How to know which RID value the next local account (user and group) will get? If we create a new local account, we can check what RID value it has, so we can know what is the next RID value that the next new account would get. How can we know the next RID for a new local account before we create that account?
is there any particular reason to know RID in advance?
Yes, of course there is a reason. If you do not have an answer to this specific question, refrain from making useless comments.
wouldn't you mind to share that reason? I'm just curious about use case.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(256, 74%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERM%3C/text%3E%3C/svg%3E)
I'm not sure why a PowerShell tag is present in your question. The issuance of RIDs is a function of the Active Directory.
I don't think there's a way to do what you ask. RIDs aren't issued to new AD objects by the RID FSMO holder. Each domain controller asks the RID FSMO holder for a block of RIDs (default is to get 500 at a time), and then uses the RIDs as necessary. To predict what the "next" RID value to be used might be depends on which DC creates the next AD object.
Maybe one of the AD folks can provide a better answer.
The DCDiag tool might be of some help, but I don't think it gets a fine-grained as "what RID will be used next".
My question was not about Active Directory accounts, but about local Windows accounts. I mentioned AD accounts only as an example that shows how the RID value for the next new AD account is known on the domain controllers based on the value of the rIDNextRID attribute. The value of this attribute on a domain controller can be easily obtained using the "dcdiag /Test:Ridmanager /v" command. The question is whether the RID value for a new local Windows account (not an AD account) can be known in advance in a similar way. Windows certainly knows it because each subsequent account gets a RID value increased by 1 compared to the last created account. If we know the last created account, and if it still exists, then we know the RID for the next account - the RID value of the last created increased by 1. If we do not know what the last created account is, or we know, but it has been deleted, then we cannot know the RID value for the next new account. However, Windows "knows" it. How? Where in the operating system is this information recorded? I put "powershell" as one of the tags for this question because I'm interested in the possibility of getting this information through a powershell script, or a script of some other type. If I made a mistake setting this tag, I apologize.
Sorry. I guess I didn't read the question very carefully.
I don't know precisely where that information is kept, but I'd guess it's in the registry, probably in the HKEY_LOCAL_MACHINE\SECURITY or HKEY_LOCAL_MACHINE\SAM key.
To open those keys you'd have to run using the LOCALSYSTEM account. If you'd like to poke around in those keys this is one way to have a look: https://techgenix.com/HowtobreakintoregistrytoexploreHKLMSAMandHKLMSECURITYkeys/
Thank you. I have already searched the registry location HKEY_LOCAL_MACHINE\SAM, but I could not find the required information. Maybe I will look again at the same location, but also at this 2nd one. I used Regedit as a system account using the psexec.exe tool.
I'm curious: can you explain why you need the next RID?
I think the chances of exhausting the number of available RIDs for local users is pretty slim, so keeping track of how many are available probably isn't the reason.
The RID would be immediately knowable after creating a new local user or local group.
Suppose we have a task to create local accounts based on a given list in which accounts are specified by RID and name. The list can be relatively long, but let's assume for example that we have the following list, which we have sorted by RID value:
Account Name AccountRID
UserAccount30 30
UserAccount31 31
GroupAccount32 32
UserAccount33 33
Let's assume that the next free RID on the system is 32, but we don't know that. The first step would be to create an account called UserAccount30. After we create it, we will see that it got a RID value of 32, but that value is inappropriate for this account. Of course, even if we knew which is the next free RID on the system, we would not be able to create this account. We wouldn't be able to create UserAccount31 either, but we would be able to create GroupAccount32. However, now we have already used RID 32 and the next free RID is 33, so now we cannot create GroupAccount32 either, although at the beginning of the task the next free RID was exactly the RID corresponding to this group, but we did not know that.
Your next question could be why it would be necessary to create local accounts with a given RID at all :).
Well, as long as we're dealing in hypothetical situations, how would you handle the synchronization between two processes (or groups) creating users/groups concurrently?
Your supposition that my next question would be why this assignment of RIDs is necessary is correct. To that question, the only thing I can think of is that you have a *nix system (which uses UID and GID numbers to identify objects) and you want to record that information on the Windows system. The Active Directory can accommodate that requirement using the properties "uidNumber" and "gidNumber". A local user, however, is just that: local. It isn't expected to hold information about its identity on external/networked systems.
If that's not the reason you may have to do such a thing, please elaborate.
Suppose we have a Windows server with multiple local accounts and multiple disks. On the file system of these disks, permissions are assigned to local accounts. It is an extremely large amount of data, several TB, and an extremely large number of files. It is necessary to migrate Windows to a new version. In-place upgrade is not an option. If we create local accounts of the same name on the new system, their SIDs will be different from the accounts on the old system. So, if we connect the disks from the old system to the new one, the local accounts will no longer have the permissions they had. One solution is to replace the SIDs of the old local accounts with the SIDs of the new ones on all files and folders where they appear. Due to the huge amount of data and the huge number of files, it is a process that takes an extremely long time. Another solution would be to change the SID of the newly installed Windows so that it corresponds to the SID of the old Windows (this can be achieved using the sysprep tool) and then create local accounts with the same name and the same RID on the new system. I made scripts for export/import of local accounts with RID preservation. Inside the script it would be good to know what is the next free RID on the system. This information is not important on a new system where no local accounts have been created, but in order to cover the case when some local accounts have been created and deleted on the new system, it would be good to know which is the next free RID . This is also useful information when testing the mentioned scripts on another Windows.
I'm answering this question because there's a "PowerShell" tag on it. NOT because I have any great experience with Windows security and not because I'm any kind or authority in account migration.
The answer to the question I asked is not necessary for me at this moment. The script I created to import local accounts does its job correctly when no accounts have been created or deleted on the destination system before running the script. The script also works in the case when local accounts were created and deleted on the destination system before starting the script, but in this case there is a possibility that one of the local accounts from the given list cannot be created because we did not know which is the next free RID, and otherwise it could be created. This is a special case that I illustrated with the previous hypothetical example, but it is not too important to me. Thank you for your efforts.
NewSID has been retired and is no longer available for download. But it is not necessary because, as I said before, sysprep can be used for the same purpose.