User rights assignment in Windows is the Group Policy area that controls what accounts can do at the operating system level: how they log on, whether they can back up every file, change the system clock, load drivers, debug processes, or shut the machine down. These settings live in security policy, entirely separate from the NTFS file and folder permissions most administrators work with daily. Get them right and least-privilege works. Get them wrong and an attacker has a short path to full system control.
Rights Are Not the Same as Permissions
A user right applies to the entire operating system. A file-system permission applies to a specific object. NTFS permissions sit in each object’s access control list and are checked against the account’s Security Identifier when access is requested. User rights are stored in security policy and checked before the account ever touches a file.
The practical consequence matters. Granting someone the “Back up files and directories” privilege lets them bypass every NTFS permission on the system for read purposes. No amount of careful folder-level ACL work protects data from an account that holds the wrong system-wide right. That is why user rights deserve their own review cycle, separate from permission audits.
Logon Rights and Privileges
Windows splits user rights into two buckets. Both are configured in the same policy container, but they do different things.
Logon Rights
Logon rights determine how an account connects to a machine. They say nothing about what the account can access once connected.
- Allow log on locally (SeInteractiveLogonRight) lets a user sit at the physical or virtual console and start a session.
- Log on as a service (SeServiceLogonRight) lets an account run a Windows service. Database engines, monitoring agents, and backup software all need this on whatever account drives them.
- Access this computer from the network (SeNetworkLogonRight) lets an account reach the machine over the network, which is the foundation for file shares, remote management, and most enterprise workflows.
- Allow log on through Remote Desktop Services (SeRemoteInteractiveLogonRight) lets an account connect via RDP. On servers, only Administrators get this by default.
Each right has a Deny counterpart. Deny rights always override the matching allow. If an account belongs to one group granted interactive logon and another group denied interactive logon, the deny wins. That makes deny rights a powerful lockout tool and a dangerous one when applied carelessly to broad groups.
Privileges
Privileges control specific system-wide operations rather than entry points. Common ones include:
- Back up files and directories (SeBackupPrivilege) bypasses all file permissions for read access, letting backup software archive data without needing ownership of every file.
- Change the system time (SeSystemtimePrivilege) adjusts the internal clock. Domain authentication depends on synchronized time, so unauthorized changes here can cause widespread login failures.
- Shut down the system (SeShutdownPrivilege) controls who can restart or power down the machine.
- Load and unload device drivers (SeLoadDriverPrivilege) allows installing or removing kernel-mode drivers, which run with the highest possible system trust.
Each privilege maps to a constant string the operating system checks at runtime when an action is requested. Granting one can quietly override every access control list on the box.
High-Risk Privileges to Restrict Tightly
Some privileges are so powerful that industry benchmarks recommend assigning them to no one, or restricting them strictly to Administrators. A single misconfiguration here can give an attacker full control of the machine without needing a kernel exploit.
Debug Programs (SeDebugPrivilege)
This right lets a process attach to and read the memory of any other process on the system, including those running as SYSTEM. Attackers who gain an account with SeDebugPrivilege can target the Local Security Authority Subsystem Service (LSASS), which caches authentication credentials in memory. From there they can harvest password hashes and Kerberos tickets without cracking anything. The CIS Windows Server benchmark recommends restricting this right to Administrators only, and many hardened environments remove it from everyone.
Act as Part of the Operating System (SeTcbPrivilege)
An account with this privilege can manipulate process tokens to impersonate SYSTEM, which effectively grants unrestricted control over the entire machine. No complex exploit is needed; the operating system already trusts the account at its highest level. The CIS benchmark recommends setting this right to “No One.” A non-system account holding SeTcbPrivilege should be treated as an active security incident.
Take Ownership and Restore Files
SeTakeOwnershipPrivilege lets an account seize ownership of any securable object on the system, including Active Directory objects, files, registry keys, and processes. SeRestorePrivilege grants write access to any file regardless of its ACL and allows setting arbitrary SIDs as file owners. Together they can dismantle an entire permission structure. Microsoft classifies both as sensitive privileges and recommends monitoring event 4672 whenever they appear in a logon token belonging to a non-administrative account.
Impersonate a Client After Authentication (SeImpersonatePrivilege)
This privilege lets a process assume the identity of another user. It exists legitimately so that services like IIS can act on behalf of connecting clients. Granted to the wrong account, it opens the door to privilege escalation attacks where a low-privilege process impersonates a high-privilege token. The CIS benchmark restricts this right to Administrators and a handful of built-in service accounts.
Defaults for Built-in Groups
Windows assigns a broad set of rights to built-in groups out of the box. Knowing what each group starts with is the first step toward trimming excess.
Administrators receive the widest defaults, including SeDebugPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeLoadDriverPrivilege, SeShutdownPrivilege, SeSystemtimePrivilege, SeImpersonatePrivilege, SeRemoteShutdownPrivilege, and SeSecurityPrivilege (manage auditing and security logs), among others.
Backup Operators receive SeBackupPrivilege, SeRestorePrivilege, SeShutdownPrivilege, and the ability to log on locally and as a batch job. The group is often overlooked in security reviews, but its members can read every file on the system through the backup privilege alone.
Print Operators get SeLoadDriverPrivilege by default, which means they can install kernel-mode drivers. On domain controllers, this group represents a meaningful attack surface that many organizations forget to lock down.
Remote Desktop Users starts with no members and no special privileges beyond the ability to log on through RDP once added. Members cannot install software or reboot the server, which makes this a relatively safe way to grant remote console access to non-administrators.
Assigning Rights Through the GUI
On a standalone machine or workstation, open the Local Group Policy Editor by running gpedit.msc from a command prompt or Run dialog. secpol.msc goes directly to the Local Security Policy snap-in, skipping the broader Group Policy tree.
For domain-wide changes, open the Group Policy Management Console from Administrative Tools and edit a Group Policy Object linked to the organizational unit containing the target computers. In either tool, navigate to Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
Double-clicking a policy such as “Allow log on locally” opens a properties window with an Add User or Group button. Enter the account or group name, click Check Names to validate against Active Directory or the local account database, then OK and Apply.
New settings do not take effect instantly. Group Policy refreshes in the background every 90 minutes, plus a random offset of up to 30 minutes. To force an immediate refresh, run gpupdate /force from an elevated command prompt. Even after the policy applies, some rights (particularly logon rights) require the user to sign out and back in before the updated security token takes effect.
Scripting Rights With Secedit and PowerShell
Managing rights across dozens of servers through a GUI does not scale. Windows includes secedit.exe for automating security policy from the command line, and community PowerShell modules fill the gaps.
To export the current assignments from a machine into a text file:
secedit /export /areas USER_RIGHTS /cfg C:\policies.txt
The output lists each right as a constant name followed by the SIDs of assigned accounts. Edit the file, change the assignments, and import it back with secedit /configure. This is useful for baselining a known-good configuration and replicating it across servers.
Native PowerShell does not include cmdlets for user rights directly. The open-source Carbon module adds Grant-Privilege, Revoke-Privilege, Get-Privilege, and Test-Privilege. A typical assignment looks like Grant-Privilege -Identity "DOMAIN\SvcBackup" -Privilege SeServiceLogonRight. Privilege names passed to Carbon are case-sensitive; SeServiceLogonRight works, seservicelogonright does not.
Troubleshooting When a Right Does Not Apply
When a user right does not behave as expected, the problem is almost always a Group Policy conflict. Multiple GPOs can target the same machine, and if two configure the same right, only one wins. Windows applies policies in LSDOU order: Local, Site, Domain, Organizational Unit. A GPO linked to a child OU overrides a conflicting setting at the domain level. Within the same container, link order determines priority.
The fastest way to see which GPO actually delivered a setting is gpresult /z, run from an elevated command prompt on the affected machine. Unlike gpresult /r, which only shows which GPOs applied, the /z flag reveals every GPO that configured a particular setting, including ones that were overridden, along with precedence values showing exactly which GPO won.
For a graphical view, open rsop.msc in logging mode. Right-clicking a specific setting and opening its Properties shows a Precedence tab listing every GPO that touched that setting, with the winner at the top. When a GPO that should apply does not show up at all, check whether its link is enabled, whether security filtering or a WMI filter is excluding the target, and whether inheritance is blocked at a parent OU.
Deny rights always override allow rights. If a user belongs to Group A (granted SeInteractiveLogonRight) and Group B (denied the same right), the deny wins regardless of GPO precedence. “Access denied” logon failures should start with a check of deny assignments, not just the allow side.
Audit Expectations
NIST SP 800-53 formalizes the principle of least privilege under control AC-6, which requires organizations to allow only the access necessary for assigned tasks. Its sub-controls push further: AC-6(5) requires restricting privileged accounts to defined personnel, AC-6(7) requires periodic review of assigned privileges to validate continued need, and AC-6(9) requires logging the execution of privileged functions. These controls map directly to user rights assignment, because every sensitive right like SeDebugPrivilege or SeRestorePrivilege is exactly the kind of privilege NIST expects organizations to inventory, justify, and monitor. Frameworks including the Sarbanes-Oxley Act and HIPAA impose similar access-control expectations on the systems in their scope.
In practice, auditors want documentation showing when a right was granted, who approved it, and the business justification. They expect logs proving changes are tracked and reviewed. Windows generates event 4672 every time an account logs on with sensitive privileges in its token, which gives security teams a built-in mechanism for monitoring privileged access without third-party tools. Retaining those logs for the period required by applicable regulations and reviewing them periodically is what separates organizations that pass audits from the ones that scramble through them.