User Rights Assignments
The accounts and groups the local policy gives user rights to, one subkey per SID.
Use it to find which accounts and groups hold user rights, and spot a right given straight to one account.
- SECURITY
- Accounts and RDP
What It Is
User rights decide how an account may sign in and which machine-wide actions it may take, such as signing in over Remote Desktop or debugging programs. Administrators assign them under User Rights Assignment in Group Policy, usually to groups. The Local Security Authority (LSA), the part of Windows that enforces local security policy, keeps an account object for each account or group given a right. In the SECURITY hive these sit under Policy\Accounts, one subkey per SID.
What It Proves
A subkey for a SID means the policy gives that account or group at least one right directly. A subkey for a single user account, not a group, is unusual and worth checking.
What It Does Not Prove
Microsoft does not document how the rights are stored inside each subkey, so read them on the live machine with secedit. A user also holds the rights of every group it belongs to, which this key does not show.
Where It Lives
User Rights Assignments lives in the SECURITY hive, which holds settings for the whole machine. Offline Hive shows the path inside the hive file, as Registry Explorer opens it, and Live System shows the same key as regedit shows it on a running machine. The line under the path is where the hive file sits on disk.
SECURITY\ Policy\ Accounts\ <SID>C:\ Windows\ System32\ config\ SECURITYWhat It Looks Like
These are three values from this key on ws-042, the fictional machine the wiki follows, decoded into plain English. Each row shows the value as Windows stores it, its name, type and data, then what it tells you. The first row is the key list in the hive, and the other two are lines from a secedit export, which names each right by its constant.
| Registry Value | What It Tells You |
|---|---|
| The policy gives support no right of its own. Its rights come from Administrators and Remote Desktop Users, so the SAM group keys show how it got them. |
| Only Administrators and Remote Desktop Users may sign in over Remote Desktop, the default on a workstation. support may too, through both groups. |
| Debug Programs belongs to Administrators only, the default. support holds it through Administrators, one more reason to treat the account as having full control. |
How to Read It
Each subkey under Policy\Accounts is named by a SID, such as S-1-5-32-555 for Remote Desktop Users, and RECmd reads the list. Resolve each SID to a name with the well-known SIDs and the machine and domain prefixes in the Domain Membership key. On the live machine, a secedit export of the USER_RIGHTS area lists every right with the SIDs that hold it. Then read the SAM groups, because most accounts get their rights through membership.
- When Windows Writes It
- When an administrator, Group Policy or a program assigns or removes a user right.
- Which Windows Versions
- Windows XP to 11
- Tools That Parse It
- secedit (live), RECmd, Registry Explorer
Hunt It
The rights sit in the SECURITY hive, which only SYSTEM can read on a running machine, so parse a copy or list the keys with Velociraptor. The Security log records each privilege assigned or removed in events 4704 and 4705, with Policy Change auditing on for authorisation changes.
Defender XDR advanced hunting has no table of user rights assignments. Read the policy live with secedit, or collect the SECURITY hive.
Parse the Hive Instead
- Collect
C:\Windows\ System32\ config\ SECURITY - Parse With
- secedit (live)RECmdRegistry Explorer
Confirm It With
One artefact can mislead on its own. These other records show the same activity, or pin down when it happened, so use them to back up what User Rights Assignments shows.
- SAM Local Group MembershipShows who is in each group the rights are given to.
- User Right Assigned, Security Event 4704Not in the RegistryNames the privilege, the account given it and who gave it, though not for logon rights.
- Special Privileges at Logon, Security Event 4672Not in the RegistryShows which sign-ins carried administrator-level privileges, and for which account.
Sources
The facts on this page come from these public pages, which say more on each point.