windows group policy user rights assignment

Set and Check User Rights Assignment via Powershell

You can add, remove, and check user rights assignment (remotely / locally) with the following powershell scripts..

Posted by : blakedrumm on Jan 5, 2022

How to get it

Local Computer

Remote computer, output types.

This post was last updated on August 29th, 2022

I stumbled across this gem ( weloytty/Grant-LogonAsService.ps1 ) that allows you to grant Logon as a Service Right for a User. I modified the script you can now run the Powershell script against multiple machines, users, and user rights.

Set User Rights

All of the User Rights that can be set:

Note You may edit line 437 in the script to change what happens when the script is run without any arguments or parameters, this also allows you to change what happens when the script is run from the Powershell ISE.

Here are a few examples:

Add Users Single Users Example 1 Add User Right “Allow log on locally” for current user: . \Set-UserRights.ps1 -AddRight -UserRight SeInteractiveLogonRight Example 2 Add User Right “Log on as a service” for CONTOSO\User: . \Set-UserRights.ps1 -AddRight -Username CONTOSO\User -UserRight SeServiceLogonRight Example 3 Add User Right “Log on as a batch job” for CONTOSO\User: . \Set-UserRights.ps1 -AddRight -Username CONTOSO\User -UserRight SeBatchLogonRight Example 4 Add User Right “Log on as a batch job” for user SID S-1-5-11: . \Set-UserRights.ps1 -AddRight -Username S-1-5-11 -UserRight SeBatchLogonRight Add Multiple Users / Rights / Computers Example 5 Add User Right “Log on as a service” and “Log on as a batch job” for CONTOSO\User1 and CONTOSO\User2 and run on, local machine and SQL.contoso.com: . \Set-UserRights.ps1 -AddRight -UserRight SeServiceLogonRight , SeBatchLogonRight -ComputerName $ env : COMPUTERNAME , SQL.contoso.com -UserName CONTOSO\User1 , CONTOSO\User2

Remove Users Single Users Example 1 Remove User Right “Allow log on locally” for current user: . \Set-UserRights.ps1 -RemoveRight -UserRight SeInteractiveLogonRight Example 2 Remove User Right “Log on as a service” for CONTOSO\User: . \Set-UserRights.ps1 -RemoveRight -Username CONTOSO\User -UserRight SeServiceLogonRight Example 3 Remove User Right “Log on as a batch job” for CONTOSO\User: . \Set-UserRights.ps1 -RemoveRight -Username CONTOSO\User -UserRight SeBatchLogonRight Example 4 Remove User Right “Log on as a batch job” for user SID S-1-5-11: . \Set-UserRights.ps1 -RemoveRight -Username S-1-5-11 -UserRight SeBatchLogonRight Remove Multiple Users / Rights / Computers Example 5 Remove User Right “Log on as a service” and “Log on as a batch job” for CONTOSO\User1 and CONTOSO\User2 and run on, local machine and SQL.contoso.com: . \Set-UserRights.ps1 -RemoveRight -UserRight SeServiceLogonRight , SeBatchLogonRight -ComputerName $ env : COMPUTERNAME , SQL.contoso.com -UserName CONTOSO\User1 , CONTOSO\User2

Check User Rights

In order to check the Local User Rights, you will need to run the above (Get-UserRights), you may copy and paste the above script in your Powershell ISE and press play.

Note You may edit line 467 in the script to change what happens when the script is run without any arguments or parameters, this also allows you to change what happens when the script is run from the Powershell ISE.

Get Local User Account Rights and output to text in console:

Get Remote SQL Server User Account Rights:

Get Local Machine and SQL Server User Account Rights:

Output Local User Rights on Local Machine as CSV in ‘C:\Temp’:

Output to Text in ‘C:\Temp’:

PassThru object to allow manipulation / filtering:

I like to collaborate and work on projects. My skills with Powershell allow me to quickly develop automated solutions to suit my customers, and my own needs.

Email : [email protected]

Website : https://blakedrumm.com

My name is Blake Drumm, I am working on the Azure Monitoring Enterprise Team with Microsoft. Currently working to update public documentation for System Center products and write troubleshooting guides to assist with fixing issues that may arise while using the products. I like to blog on Operations Manager and Azure Automation products, keep checking back for new posts. My goal is to post atleast once a month if possible.

• operationsManager
• troubleshooting
• certificates

WinSecWiki  > Security Settings  > Local Policies  > User Rights

User Rights Assignments

Although in this section they are called user rights, these authority assignments are more commonly called privileges.

Privileges are computer level actions that you can assign to users or groups. For the sake of maintainability you should only assign privileges to groups not to individual users. Each computer has its own user rights assignments. In particular this means you should be cognizant of rights assignments on member servers which may easily differ from the rights assignments you find on your domain controllers. To centrally control user rights assignments on computers throughout your domain use group policy.

• Logon rights
• Admin equivalent rights
• Tracking user rights with the security log
• User rights in-depth
• Access this computer from the network
• Act as part of the operating system
• Add workstations to domain
• Adjust memory quotas for a process
• Allow log on locally
• Allow logon through Terminal Services
• Back up files and directories
• Bypass traverse checking
• Change the system time
• Create a pagefile
• Create a token object
• Create global objects
• Create permanent shared objects
• Debug programs
• Deny access to this computer from the network
• Deny logon as a batch job
• Deny logon as a service
• Deny logon locally
• Deny logon through Terminal Services
• Enable computer and user accounts to be trusted for delegation
• Force shutdown from a remote system
• Generate security audits
• Impersonate a client after authentication
• Increase scheduling priority
• Load and unload device drivers
• Lock pages in memory
• Log on as a batch job
• Log on as a service
• Manage auditing and security log
• Modify firmware environment values
• Perform volume maintenance tasks
• Profile single process
• Profile system performance
• Remove computer from docking station
• Replace a process level token
• Restore files and directories
• Shut down the system
• Synchronize directory service data
• Take ownership of files and other objects

Child articles:

• Logon Rights
• Admin Equivalent Rights
• Tracking User Rights with the Security Log
• User Rights In-Depth

Back to top

How to apply Group Policy settings to specific users on Windows 11

Do you have to change policy settings but only for some users? Here's how on Windows 11.

On Windows 11 (similar to previous versions), the Local Group Policy Editor is a Microsoft Management Console (MMC) snap-in that provides an interface to allow administrators (and power users) to manage every Group Policy Object (GPO) on the local computer. It enables you to configure and customize system settings and control user accounts, security, and other administrative tasks that are typically not possible to configure through the Settings app (or Control Panel).

The only drawback about this management console is that the settings configured through the method will apply to every user as it doesn't offer an option to configure settings for a specific user or group. However, it's possible to roll out system changes to only some users by creating a User-Specific Local Group Policy (LGPO) snap-in.

This how-to guide will walk you through the steps to use the Local Group Policy Editor to apply settings only to specific users on Windows 11.

How to apply settings to specific user with Group Policy

To configure system settings that will only apply to specific users on Windows 11, use these steps:

• Use the  "Windows key + R"  keyboard shortcut to open the Run command.
• Type  MMC  and click the  OK  button.

• Open the  File  menu and select the  "Add/Remove Snap-in"  option.

• Under the "Available snap-ins" section, select the  "Group Policy Object Editor"  snap-in.
• Click the Under the "Available snap-ins" section, and select the  "Group Policy Object Editor"  snap-in.
• Click the  Add  button.

• Click the  Browse  button.
• Click the  User  tab.
• Select the user or group to apply the new configurations.

• Quick tip: To change settings for users with a "Standard user" account, select  Non-Administrators  from the list.
• Click the  OK  button.
• Click the  Finish  button.
• Open the  File  menu and select the  Save As  option.

• Confirm a name for the snap-in.
• Select a location to store the custom console with the configurations.
• Click the  Save  button.

After you complete the steps, you can open the newly created Microsoft Management Console to configure the settings you want to apply to a specific user.

For example, you can use these instructions to configure custom settings or restrict access to certain features, such as Registry , Command Prompt, Settings app, and others, allowing users to make unwanted system changes.

More resources

For more helpful articles, coverage, and answers to common questions about Windows 10 and Windows 11, visit the following resources:

Get the Windows Central Newsletter

All the latest news, reviews, and guides for Windows and Xbox diehards.

• Windows 11 on Windows Central — All you need to know
• Windows 10 on Windows Central — All you need to know

Mauro Huculak is technical writer for WindowsCentral.com. His primary focus is to write comprehensive how-tos to help users get the most out of Windows 10 and its many related technologies. He has an IT background with professional certifications from Microsoft, Cisco, and CompTIA, and he's a recognized member of the Microsoft MVP community.

• 2 Bethesda director reveals new Fallout 4 connection to first game, making its main character complicit in a war crime [UPDATED]
• 3 Fallout franchise sees player count resurgence across all games thanks to sales, promotions, and an excellent TV series
• 4 Apple's dumb reasons for selling $1099 laptops with 8GB RAM proves why you should just buy a Windows laptop instead
• 5 A shooter that combines the ultra-violence of DOOM with the fast-paced gameplay of Hades? Sign me up

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

What are the defaults for the "user rights assignment" in an AD environment?

In a non-domain environment, gpedit.msc lets me associate various "user rights" (like "create a pagefile" or "create permanent shared objects") with users or accounts. This is in Computer Configuration | Windows Settings | Security Settings | Local Policies | User Rights Assignment.

Where exactly do I do this in AD? (Please don't just say e.g. "Group Policy Management Console". I've looked at all of the tools I can find, especially in GPMC, and I can't see it. I need either very explicit directions or screen snaps.

ADDED: Ok, I think I get it. You create a new GPO, click Edit, and this gets you to the Group Policy Management Editor where I find the familiar path. Then I link my new GPO to the domain or the OU or whatever where I want it to apply.

But I still have a question: none of the rights in the editor come pre-set to anything. Well, that makes sense because it's a brand new GPO. But is there any way to know what the defaults are, defaults that my new GPO will override? For example, what rights do members of the "Domain Admins" group get, by default?

• active-directory

• If the downvoter would like to explain the reason for the downvote, I'd love to read it. I've been looking for this answer for over an hour so "did not do any research" is not the case. –  Jamie Hanrahan Oct 17, 2018 at 20:10

2 Answers 2

The defaults are documented in:

Group Policy Settings Reference Spreadsheet https://www.microsoft.com/en-us/download/details.aspx?id=56946

On the Security tab. Covers all versions of Windows. (I don't believe it has been updated for 1809 yet).

It depends on what you're asking.

If you're asking for User Rights Assignment on a single computer, look for Local Security Policy.

If you're asking for User Rights Assignment as a group policy, well, it shows up just fine in my console. Are you using RSAT (Remote Server Administration Tools)? I'm using the RSAT available for Windows 10. Older versions of RSAT (or the version on the domain controller) may be missing some options.

• Yeah... I finally realized (after asking the first form of the question) that you can only see them when you open the Editor. It's surprising to me though that the Default Domain Policy comes with everything "Not defined" and yet the defaults are certainly being applied. Thanks! –  Jamie Hanrahan Oct 17, 2018 at 21:32

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged active-directory ..

• The Overflow Blog
• How to succeed as a data engineer without the burnout
• How do you evaluate an LLM? Try an LLM.
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network

Hot Network Questions

• Transaction got reverted Uniswap Universal Router
• Negated Fibonacci and the floor function
• Highlighting only text for google sheets
• How do Biblical inerrantists explain disagreements about the interpretation of the Bible?
• Password checker using Decorator Pattern
• Does scouring a stainless-steel pan cause it to release metals into food?
• Is a new Tourney rear hub better than a 15 year old Deore hub?
• C-130 supreme propulsion on thought experiments
• What is this circuit? (FM detector?) - LTspice
• Can the composition law of a group be defined only when considering a representation or realisation of the Group?
• After creating HTML, why did Tim Berners-Lee bother creating HTTP? Why didn't he just write a HTML renderer for a FTP client?
• LWC Global Uncaught Promise Error Handler
• Simple problems that calculators get wrong
• How was Rome able to conscript and equip 400k soldiers during 2nd Punic War in a pre-industrial society?
• What is the meaning of asymptotic security proofs in practice?
• When is it important for a practitioner to understand CIs?
• How to select an editor?
• How to make a device to randomly choose one of three possibilities, with caveat that sometimes one of them is not available?
• How do I scan my LAN for .local addresses?
• How many papers should I include in the literature review writing?
• Has Trump's political views changed on Israel's war in Gaza?
• Layover in Beijing extended by two days
• Finding a nilpotent, infinite, f.g., virtually abelian, irreducible integer matrix group
• Examples of concrete games to apply Borel determinacy to

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Can't edit Local Security Policy

I'm trying to add users to the Access this computer from the network User Rights Assignment policy but the 'Add' button is disabled:

I'm connecting to the machine via RDP using the local Administrator account (not a domain user). I've also tried to do the same with a domain user that is in the Administrators group but the result is the same.

How can I add a user to this policy?

The machine is running Windows 7.

• remote-desktop
• administrator
• group-policy

• You need to be using a domain user in the Administrator user group –  Ramhound Aug 27, 2015 at 12:38
• I am using it (the built-in account..), but I login via RDP. does it matter? –  etaiso Aug 27, 2015 at 12:38
• Your not using one, you indicated your using the local Administrator account, you need to be using a user connected to the domain with Administrator permissions. –  Ramhound Aug 27, 2015 at 12:44
• I also tried that . it's the same –  etaiso Aug 27, 2015 at 12:46
• Update your question; If I had know that; I could have saved time responding. –  Ramhound Aug 27, 2015 at 12:51

You cannot edit this User Rights Assignment policy because this setting is being managed by a domain-based Group Policy. In this case, the domain Group Policy setting has precedence and you are prevented from modifying the policy via Local Group Policy.

To modify this policy, either:

• Modify the policy in the applicable domain Group Policy Object.
• Prevent any domain-based GPOs from specifying this setting, then edit the computer's Local Group Policy.
• where can I find this policy in the GPO? –  marijnr Jun 13, 2018 at 13:15
• 2 Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment –  I say Reinstate Monica Jun 13, 2018 at 13:16

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged windows security remote-desktop administrator group-policy ..

• The Overflow Blog
• How to succeed as a data engineer without the burnout
• How do you evaluate an LLM? Try an LLM.
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network

Hot Network Questions

• Can a Venus-like planet be habitable if it was farther from the sun?
• Endomorphism ring of a generic elliptic curves in positive characteristic
• Why is my car paint not so "shiny"?
• Ghost Story set on a Victorian age ocean going liner. Everyone who has slept in a certain cabin for the last four voyages has jumped overboard
• To what extent can US police lie to a suspect?
• What is this circuit? (FM detector?) - LTspice
• Password checker using Decorator Pattern
• If a Dragonborn is affiliated with a particular dragon race, is it more likely to inherit that race's alignment?
• Why did the USA provide a $1 billion Patriot battery but not a $34 million F-16 to Ukraine?
• Has the handling of whitespace by \alltt changed recently (i.e. since 2021)?
• On track with my travel agent
• Can the composition law of a group be defined only when considering a representation or realisation of the Group?
• How to create grep output in the order of the input file?
• Short Story. Mouse is sent by a human scientist in a spaceship to moon. Intercepted by intelligent aliens. Given intelligence and speech. Named Mickey
• Relative inclination to LOS
• Finding a nilpotent, infinite, f.g., virtually abelian, irreducible integer matrix group
• Is Alzheimer’s disease evidence for the non-existence of the soul?
• How was Rome able to conscript and equip 400k soldiers during 2nd Punic War in a pre-industrial society?
• Expressing the area of an isosceles triangle as a function of one of its angles.
• Transaction got reverted Uniswap Universal Router
• Converting "4.8 million" into an actual number
• A tic-tac-toe game in C
• How does HTTP Keepalive handle multiple requests along with EOF from same origin?
• LWC Global Uncaught Promise Error Handler

Windows security encyclopedia

#microsoft #windows #security

Search form

User rights assignment, related content.

• About the Authors

Managing “Logon As a Service” Permissions Using Group Policy or PowerShell

“ Log on as a service ” is a security policy in Microsoft Windows operating systems that specifies which user accounts or groups are allowed to start and run Windows services. Services are programs running in the background and performing various tasks without user interaction. They are essential components of the Windows operating system and are used for networking, hardware management, and system monitoring tasks.

When a service starts, it must run under a specific user account, either a built-in system account or a custom user account. The “Log on as a service” policy defines which accounts or groups have the privilege to be assigned as the login credentials for these services. This policy is crucial for maintaining security and preventing unauthorized access to system resources.

Configuring the “Log on as a service” policy involves assigning specific accounts or groups the right to log on as a service. By default, only certain built-in accounts and groups have this privilege. Suppose an application or service requires a specific user account to function correctly. That account needs to be explicitly added to the “Log on as a service” policy to ensure it has the necessary permissions.

“Log on as a service” Rights vs. Privileges User Account

Assigning a specific user account to run Windows services using the “Log on as a service” privilege offers several advantages over using the built-in Local System account or other privileged user accounts:

• Principle of Least Privilege: The principle of least privilege suggests that users, processes, and services should have only the permissions necessary to perform their tasks. Assigning a dedicated user account to run a service allows you to grant precisely the required permissions for that service, reducing the risk of unintended actions or security breaches.
• Isolation of Services: By using individual user accounts for each service, you can isolate the privileges and resources associated with each service. This isolation helps prevent one compromised service from affecting other services or system components.
• Auditability: Using separate user accounts for services makes it easier to track and audit the activities of each service. In the event of security incidents or unauthorized access, it’s simpler to identify the responsible service when services are associated with distinct user accounts.
• Controlled Access: Assigning specific accounts to services allows you to control who has access to run those services. You can restrict the accounts with the “Log on as a service” privilege, reducing the attack surface and improving overall security.
• Password Management: Services associated with dedicated user accounts can manage their passwords separately. This is especially useful in scenarios where password changes are required periodically or when following password management policies.
• Compatibility: Some applications and services are designed to work best under a specific user context rather than the Local System account. Running them as the Local System might lead to compatibility issues or limited functionality.
• Granular Permissions: User accounts assigned to services can have finely tuned permissions. This is particularly important when services interact with specific network resources, databases, or other systems. Assigning the appropriate permissions ensures smooth service operation without granting excessive privileges.
• Debugging and Troubleshooting: When services run under a specific user account, troubleshooting issues becomes easier. You can log in with that account to test and diagnose problems directly, which can be more challenging when using the Local System account.

While there are definite benefits to using dedicated user accounts for services, managing these accounts effectively is essential. Proper management includes maintaining strong passwords, adhering to password policies, and ensuring that the accounts themselves are not susceptible to unauthorized access.

In some cases, certain services may require more extensive privileges, making using the Local System account necessary. But, when possible, using the “Log on as a service” privilege to assign specific user accounts to services is a recommended security practice that enhances control, accountability, and overall system security.

Managing “Log on as a service” Rights Assignments via Group Policy

You can configure the “Log on as a service” rights assignment via the local or domain group policy.

Note . When you deploy the “Log on as a service” policy via Group Policy Object (GPO), the policy settings you define in the GPO will overwrite the existing list of accounts on the target computers. The GPO settings for “Log on as a service” will replace any existing accounts or groups granted the privilege.

• If deploying via GPO, open the Group Policy Management console ( gpmc.msc ) and open the group policy object to modify or create a new one.
• If modifying the local machine’s group policy, open the local group policy editor ( secpol.msc )

Note . The “NT SERVICESERVICES” group is added to the “ Log on as a service ” policy by default on Windows Server 2016, Windows 10, and later.

• THEITBROS\CA IT Ops — domain group
• THEITBROS\jmiller — domain user
• PCX\localadmin01 — local user

Related post . Configure NTP Time Sync Using Group Policy

Managing “Log on as a service” Rights Assignments via PowerShell

Managing the “Log on as a service” rights assignments in the command line is beneficial for systems without a desktop environment, such as Windows Server Core, and when managing computers during remote PowerShell sessions.

There are no native PowerShell cmdlets to manage the “Log on as a service” policy as of this writing. The only native command line tool that can modify the local security policies is the secedit.exe tool.

Download the “Log on as a service” Management Scripts

So, we created three PowerShell script wrappers for secedit.exe that you can download from the following links:

• [ PS-Manage-Log-On-As-A-Service ] — The public GitHub repository.
• [ Get-ServiceLogonRight.ps1 ] — A script to retrieve the local machine’s current “Log on as a service” rights.
• [ Add-ServiceLogonRight.ps1 ] — A script to add a user and group to the “Log on as a service” policy.
• [ Remove-ServiceLogonRight.ps1 ] — A script to remove a user or group from the current “Log on as a service” policy.

Download the above scripts and store them in a folder on your computer. Then open an elevated PowerShell session (run as admin), and change the working directory to where you saved the scripts.

List the Current “Log on as a service” Rights Assignments

To list the current accounts in the “Log on as a service” policy, run the below script.

Add Users and Groups to the “Log on as a service” Policy

To add a user or group to the “Log on as a service” Policy, follow the below example commands.

# Add a local group .\Add-ServiceLogonRight.ps1 -UserOrGroup <local group>

# Add a domain user account .\Add-ServiceLogonRight.ps1 -UserOrGroup <DOMAIN\user>

# Add a domain group .\Add-ServiceLogonRight.ps1 -UserOrGroup <DOMAIN\group>

Confirm that the new users and groups were added to the “Log on as a service” policy.

What happens if you add a non-existing group or user to the “Log on as a service” policy? You’ll get this message.

Remove Users and Groups from the “Log on as a service” Policy

When a group or user is no longer viable for the “Log on as a service” policy, you can remove it using the Remove-ServiceLogonRight.ps1 script.

# Remove a local group .\Remove-ServiceLogonRight.ps1 -UserOrGroup localadmingroup02

# Remove a domain user .\Remove-ServiceLogonRight.ps1 -UserOrGroup ‘THEITBROS\ebrown’

# Remove a domain group .\Remove-ServiceLogonRight.ps1 -UserOrGroup ‘THEITBROS\CA Server Admins’

Run the .\Get-ServiceLogonRight.ps1 script to confirm that the users and groups have been removed.

What happens if you remove a user or group not existing in the “Log on as a service” policy? You’ll get the following message.

While there are scenarios where services necessitate greater privileges and the use of the Local System account, assigning specific user accounts through the “Log on as a service” policy is recommended to enhance control, accountability, and overall system security.

This article has also covered methods for managing “Log on as a service” rights assignments via Group Policy and PowerShell.

For PowerShell users, the article introduced scripts using the secedit.exe tool to manage these rights assignments. These scripts include Get-ServiceLogonRight.ps1 to retrieve current rights, Add-ServiceLogonRight.ps1 to add users or groups, and Remove-ServiceLogonRight.ps1 to remove them.

Lastly, minimizing the number of user accounts to which you grant the “Log on as a service” permissions is advisable. To reduce security risks, you should turn off interactive and remote interactive sessions for service accounts.

Cyril Kardashevsky

I enjoy technology and developing websites. Since 2012 I'm running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.

Understanding ProxyAddresses Attribute in Active Directory

Fix: unable to find a default server with active directory web services running.

Thank you. Literally NO ONE in Enterprise IT understands this about most of the stuff in the USer Rights Assignment of Group Policy. I’ve fixed so many outages due to admins settings this via GPO across many servers and overwriting what’s already set in there by x, y, z application that was installed who put accounts in there. Admins just blindly follow along application documentation or posts like this. I’m so tired of it.

– Angry Sr. Systems Admin LOL

Been like this for 20 years now.

Microsoft really needs to add switches for append, remove and replace for setting group policy objects, or just remove these from GPO management altogether as it’s half baked.

Please follow this up with how to set Logon As a Service for a user or group policy on Windows Server 2016 Core – there is no GUI, no control panel, no gpedit.msc, no gpmc.msc, no services.msc, etc etc.

For example, to setup Jenkins requires a user account with Logon As a Service enabled. Thank you

Leave a Comment Cancel Reply

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Windows User Rights Assignment Utility

jcasale/UserRights

Folders and files, repository files navigation.

The UserRights.exe utility is an application for managing the User Rights Assignment security policy settings.

UserRights.exe is similar to ntrights.exe from the Windows 2003 Resource Kit utility, with additional functionality making it more flexible for use in automation.

Use Case - Automating User Rights Assignment on Windows Servers

Managing user rights assignment with group policies is not trivial. The interface only allows either exclusively specifying all the principals that will be granted the right, or leaving the user right unmanaged. That is the only reasonable approach, the grants will vary depending on the roles or applications that are installed. There may be virtual accounts (e.g., IIS application pool accounts with security identifiers matching S-1-5-82-*) or NT service accounts (e.g., MSSQL accounts with security identifiers matching S-1-5-80-*) that are granted privileges.

This requires the creation and maintenance of unique and highly specific group policies for each platform and software combination. For example, a typical approach for managing the SeServiceLogonRight right might resemble:

• Create a new group policy object.
• Ensure the mode is set to Update .
• Ensure Delete all member users is enabled.
• Ensure Delete all member groups is enabled.
• Enable item level targeting, add an LDAP Query and configure it to pass only when the LDAP query does not return a value indicating the related directory group was not found (e.g., DOMAIN\allow-log-on-service-%ComputerName% ).
• Configure a single member by adding the related directory group using the variable based convention (e.g., DOMAIN\allow-log-on-service-%ComputerName% ).
• Enable item level targeting, add an LDAP Query and configure it to pass only when the LDAP query does return a value indicating the related directory group was found (e.g., DOMAIN\allow-log-on-service-%ComputerName% ).
• Add any required local users.
• Add any required local groups.
• Add any required virtual accounts.
• Add any required NT service accounts.
• Add the new local group created above, allow-log-on-service .
• Link the policy and configure the security and filtering as required.

When the policy executes, the %ComputerName% variable will be expanded and the applicable preference will create the local group, and the grants for the user right privilege will be overwritten. If the related directory security group is later provisioned, it will be added to the local group and the user rights will apply. While there is nothing wrong with this approach, it certainly is the most secure, but it has fairly high overhead.

An alternative approach without the local groups that uses UserRights.exe to grant the required directory group and revoke any inappropriate grants using a pattern is possible.

This example illustrates an approach for managing the SeServiceLogonRight right and can be applied to any of the user rights.

Copy the UserRights.exe utility to a network share that is accessible by all computer accounts.

Create an Active Directory security group for the server that should have the SeServiceLogonRight right managed. The group name must contain the sAMAccountName in addition to any conventions that are required. For example, to manage the SeServiceLogonRight privilege for a server named MyServer , create a security group named allow-log-on-service-MyServer and grant membership to all the required service accounts.

Create a group policy object, open it in the editor, and create a new scheduled immediate task:

Select the general tab and configure the task:

• Set the task to run in the NT AUTHORITY\System context.
• Set the task to run whether the user is logged in or not.
• Set the task to run with the highest privileges.
• Set the task to be hidden in the scheduled task console while it is executing.

Select the action tab and configure the task to execute the UserRights.exe utility.

Set the program to the full path to the utility. For example: \\example.com\NETLOGON\UserRights.exe .

Set the arguments to execute the utility in privilege mode, grant the SeServiceLogonRight privilege to a security group corresponding to the servers sAMAccountName value, and remove any other regular user accounts or groups. For example:

privilege SeServiceLogonRight --grant EXAMPLE\allow-log-on-service-%ComputerName% --revoke-pattern "^S-1-5-21"

Select the common tab and enable item level targeting.

Select the targeting button, and configure item level targeting to ensure the preference is only executed when the corresponding Active Directory security exists in the directory.

• Select New Item , then choose LDAP Query .
• Select Item Options , then choose IS .
• Set the filter to (&(objectCategory=group)(name=allow-log-on-service-%ComputerName%))
• Set the binding to LDAP:
• Set the attribute to the same type used in the filter name

The example above uses the groups name attribute type, which may be a better option than sAMAccountName in some environments.

Repeat all the above steps with the following changes to accommodate the case when the directory group does not exist:

Configure the action to execute the UserRights.exe utility with the following arguments:

privilege SeServiceLogonRight --revoke-pattern "^S-1-5-21"

Configure item level targeting to enable the preference when the LDAP query does not return a value.

Granting the privilege to a new user or service account only requires granting membership in the associated directory security group. Servers without a corresponding directory security will only have the user right privilege pruned according to the pattern.

If the privilege is later directly granted to a local or domain user account or group, group policy will revoke the grant. The pattern can be extended to prevent well-known security identifiers for built-in non-privileged contexts as well (use the dry-run flag to verify your regular expression).

Instrumentation

Diagnostic messages are emitted to the console and the Windows application event log.

Events originate from the UserRights source and have the following possible ids:

Manage a Principal

• Grant a privilege and revoke a different privilege from a principal:
• Grant multiple privileges, and revoke any other privileges assigned to a principal:
• Revoke a privilege from a principal:
• Revoke all privileges from a principal:

Manage a Privilege

• Assign a principal, and revoke all other principals matching a pattern (everything except builtin and virtual accounts) from a privilege in dryrun mode to only instrument the changes:
• Revoke all principals matching a pattern (everything except builtin and virtual accounts) from a privilege:
• Assign a principal and revoke a different principal from a privilege:
• Revoke a principal assigned to a privilege:
• Revoke all principals assigned to a privilege:

Enumerate Privileges and Principals

• List all principals and privileges in CSV format to STDOUT :
• List all principals and privileges in JSON format to STDOUT :
• List all principals and privileges in CSV format to a file:

Additional Info

Releases are provided in two formats that both target .Net 8.0:

• An archive containing a runtime-dependent executable and all the required libraries.
• An archive containing a single, self-contained executable to make deployment simple.

Useful Links

• User Rights Assignment
• Well-Known SID Structures
• Regular Expression Language - Quick Reference

Releases 12

Select Product

2204 LTSR (initial release)

Known issues

New UI (Technical Preview)

Install, set up, upgrade, and uninstall

Plan your StoreFront deployment

User access options

System requirements

Install StoreFront

Citrix Customer Experience Improvement Program

Citrix Analytics

Secure StoreFront with HTTPS

Secure your StoreFront deployment

Configure email based account discovery

Create a new deployment

Join an existing server group

Upgrade StoreFront

Reset a server to factory defaults

Uninstall StoreFront

Configure authentication and delegation

Configure authentication

Smart card authentication

Domain pass-through authentication

Gateway pass-through authentication

SAML authentication

User name and password authentication

Federated Authentication Service configuration

Configure and manage stores

Create a store

Configure a store

Remove a store

Export store provisioning files for users

Advertise and hide stores to users

Configure Kerberos Delegation

Manage the resources made available in stores

Manage remote access to stores through Citrix Gateway

Certificate Revocation List (CRL) checking

Configure two StoreFront stores to share a common subscription datastore

Manage subscription data for a store

Store subscription data using Microsoft SQL Server

Enable or disable favorites

Citrix Virtual Apps and Desktops configuration

Advanced store settings

Optimal HDX Routing

Subscription synchronization

Configure session settings

Ica file signing

Citrix Workspace app configuration

Manage a website

Create a website

Configure website

Category settings

Customize appearance

Featured app groups

Authentication methods

Website shortcuts

Deploy Citrix Workspace app

Session settings

Workspace control

Client interface settings

App Protection

Remove website

Configure Citrix Workspace app website

Configure server groups

Integrate with Citrix Gateway and NetScaler ADC

Configure Citrix Gateways

Import a Citrix Gateway

Load balancing with NetScaler ADC

Configure Citrix Gateway and StoreFront for Delegated Forms Authentication (DFA)

Authenticate using different domains

Configure beacon points

Create a single FQDN used internally and externally

Export and import the StoreFront configuration

End user guide

StoreFront SDK

Troubleshoot StoreFront

Third party notices

Document History

This content has been machine translated dynamically.

Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)

Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)

Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)

此内容已经过机器动态翻译。 放弃

このコンテンツは動的に機械翻訳されています。 免責事項

이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인

Este texto foi traduzido automaticamente. (Aviso legal)

Questo contenuto è stato tradotto dinamicamente con traduzione automatica. (Esclusione di responsabilità))

This article has been machine translated.

Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)

Ce article a été traduit automatiquement. (Clause de non responsabilité)

Este artículo ha sido traducido automáticamente. (Aviso legal)

この記事は機械翻訳されています. 免責事項

이 기사는 기계 번역되었습니다. 책임 부인

Este artigo foi traduzido automaticamente. (Aviso legal)

这篇文章已经过机器翻译. 放弃

Questo articolo è stato tradotto automaticamente. (Esclusione di responsabilità))

Translation failed!

This article highlights areas that may have an impact on system security when deploying and configuring StoreFront.

• Communication between end users and StoreFront

Citrix recommends securing communications between users’ devices and StoreFront using HTTPS. This ensures that passwords and other data sent between the client and StoreFront are encrypted. Furthermore, plain HTTP connections can be compromised by various attacks, such as man-in-the-middle attacks, particularly when connections are made from insecure locations such as public Wi-Fi hotspots. In the absence of the appropriate IIS configuration, StoreFront uses HTTP for communications.

Depending on your configuration, users may access StoreFront via a gateway or load balancer. You can terminate the HTTPS connection at the gateway or load balancer. However in this case Citrix still recommends that you secure connections between the gateway or load-balancer and StoreFront using HTTPS.

To enable HTTPS, disable HTTP and enable HSTS, see Securing StoreFront with HTTPS .

• StoreFront communications with Citrix Virtual Apps and Desktops servers

Citrix recommends using the HTTPS protocol to secure data passing between StoreFront and your Citrix Virtual Apps and Desktops delivery controllers. See Install TLS server certificates on Controllers . StoreFront does not support TLS 1.0 or TLS 1.1 protocols between StoreFront and the delivery controller. Alternatively you can configure Windows to secure communication between the servers using IPSec.

You can configure the delivery controller and StoreFront to ensure that only trusted StoreFront servers can communicate with the delivery controller, see Manage security keys .

• StoreFront communications with Cloud Connectors

Citrix recommends using the HTTPS protocol to secure data passing between StoreFront and your Cloud Connectors. See How to Enable SSL on Cloud Connectors to Secure XML Traffic . StoreFront does not support TLS 1.0 or TLS 1.1 protocols between StoreFront and the cloud connectors. Alternatively you can configure Windows to secure communication between the servers using IPSec.

• Remote access

Citrix does not recommend exposing your StoreFront server directly to the internet. Citrix recommends using a Citrix Gateway to provide authentication and access for remote users.

• Microsoft Internet Information Services (IIS) hardening

You can configure StoreFront with a restricted IIS configuration. Note that this is not the default IIS configuration.

Filename extensions

You can use request filtering to configure a lists of allowed file extensions and disallow unlisted file name extensions. See IIS documentation .

StoreFront requires the following file name extensions:

• . (blank extension)

If download or upgrade of Citrix Workspace app is enabled for a store website, StoreFront also requires these file name extensions:

If Citrix Workspace app for HTML5 is enabled, StoreFront also requires these file name extensions:

You can use request filtering to configure a list of allowed verbs and disallow unlisted verbs. See IIS documentation .

Non-Ascii characters in URLs

If you ensure that the store name and website name only use ascii characters then StoreFront URLs do not contain ascii characters. You can use request filtering to disallow non-ascii characters. See IIS documentation .

You can remove OS shell MIME Types corresponding to the following file extensions:

See IIS documentation .

Remove X-Powered-By Header

By default IIS reports that it is using ASP.NET by adding a X-Powered-By header with value ASP.NET . You can configure IIS to remove this header. See IIS Custom Headers documentation .

Remove Server header with IIS version

By default IIS reports the IIS version by adding a Server header. You can configure IIS to remove this header. See IIS request filtering documentation .

Move the StoreFront website to a separate partition

You can host the StoreFront web sites on a separate partition from the system files. Within IIS you must move the Default Web Site , or create a separate site, on the appropriate partition prior to creating your StoreFront deployment.

IIS features

For the list of IIS features installed and used by StoreFront, see System Requirements . You can remove other IIS features.

Although StoreFront does not use ISAPI filters directly, the feature is required by ASP.NET so cannot be uninstalled.

Handler Mappings

StoreFront requires the following Handler Mappings. You can remove other handler mappings.

• ExtensionlessUrlHandler-Integrated-4.0
• PageHandlerFactory-Integrated-4.0

See IIS Handlers Documentation .

ISAPI filters

StoreFront does not require any ISAPI filters. You can remove all ISAPI filters. See IIS ISAPI Filters documentation .

.NET Authorization Rules

By default IIS servers have the “.NET Authorization Rule” set to Allow All Users. By default, the web site used by StoreFront inherits this configuration.

If you remove or change the .NET Authorization rule at the server level then you must override the rules on the web site used by StoreFront to add an allow rule for “All Users” and remove any other rules.

Application Pools

StoreFront creates the following application pools:

• Citrix Configuration Api
• Citrix Delivery Services Authentication
• Citrix Delivery Services Resources
• and Citrix Receiver for Web

Do not change the application pools used by each IIS application or the identity of each pool. If you are using multiple sites, it is not possible to configure each site to use separate application pools.

Under the Recycling settings, you can set the application pool idle time-out and Virtual Memory Limit. Note that when the “Citrix Receiver for Web” application pool recycles it causes users logged in through a web browser to be logged out, therefore it is set by default to recycle at 02:00 each day to minimize disruption. If you change any of the recycling settings this may result in users being logged off at other times of the day.

Required settings

• Do not change the IIS Authentication settings. StoreFront manages authentication and configures directories of the StoreFront site with the appropriate authentication settings.
• For the StoreFront server under SSL Settings , do not select Client certificates: Require . StoreFront installation configures the appropriate pages of the StoreFront site with this setting.
• StoreFront requires cookies for session state and other functionality. On certain directories, under Session State , Cookie Settings , Mode must be set to Use Cookies .
• StoreFront requires .NET Trust Level to be set to Full Trust . Do not set the .NET trust level to any other value.

StoreFront installation creates the following Windows services:

• Citrix Configuration Replication (NT SERVICE\CitrixConfigurationReplication)
• Citrix Cluster Join (NT SERVICE\CitrixClusterService)
• Citrix Peer Resolution (NT SERVICE\Citrix Peer Resolution Service)
• Citrix Credential Wallet (NT SERVICE\CitrixCredentialWallet)
• Citrix Subscriptions Store (NT SERVICE\CitrixSubscriptionsStore)
• Citrix Default Domain Services (NT SERVICE\CitrixDefaultDomainService)

These accounts log on as Network Service . Do not change this configuration.

If you configure StoreFront Kerberos constrained delegation for XenApp 6.5, this in addition creates the Citrix StoreFront Protocol Transition service (NT SERVICE\CitrixStoreFrontProtocolTransition). This service runs as NT AUTHORITY\SYSTEM . Do not change this configuration.

• User rights assignment

Modifying User Rights Assignment from the defaults may cause issues with StoreFront. In particular:

Microsoft IIS is enabled as part of StoreFront installation. Microsoft IIS grants the logon right Log on as a batch job , and the privilege Impersonate a client after authentication to the built-in group IIS_IUSRS. This is normal Microsoft IIS installation behavior. Do not change these user rights. Refer to Microsoft documentation for details.

When you install StoreFront, it creates Application Pools which IIS grants user rights Log on as a service , Adjust memory quotas for a process , Generate security audits , and Replace a process level token .

To create or change a deployment, the admin must have rights Restore files and directories .

For a server to join a server group, the Administrators group must have rights Restore files and directories , Access this computer from the network and Manage auditing and security log .

For users to log on with a username and password authentication (directly or via a gateway), they must have rights to “Allow log on locally”, unless you have configured StoreFront to validate passwords via the delivery controller.

This is not a comprehensive list and other user access rights may be required.

• Configure group memberships

When you configure a StoreFront server group, the following services are added to the Administrators security group:

• Citrix Cluster Join (NT SERVICE\CitrixClusterService). This service is only seen on servers which are part of a group, and only runs while the join is in progress.

These group memberships are required for StoreFront to operate correctly, to:

• Create, export, import and delete certificates, and set access permissions on them
• Read and write the Windows registry
• Add and remove Microsoft .NET Framework assemblies in the Global Assembly Cache (GAC)
• Access the folder Program Files\Citrix\ < StoreFrontLocation >
• Add, modify, and remove IIS app pool identities and IIS web applications
• Add, modify, and remove local security groups and firewall rules
• Add and remove Windows services and PowerShell snap-ins
• Register Microsoft Windows Communication Framework (WCF) endpoints

In updates to StoreFront, this list of operations might change without notice.

StoreFront installation also creates the following local security groups:

• CitrixClusterMembers
• CitrixCWServiceReadUsers
• CitrixCWServiceWriteUsers
• CitrixDelegatedAuthenticatorUsers
• CitrixDelegatedDirectoryClaimFactoryUsers
• CitrixPNRSReplicators
• CitrixPNRSUsers
• CitrixStoreFrontAdministrators
• CitrixSubscriptionServerUsers
• CitrixSubscriptionsStoreServiceUsers
• CitrixSubscriptionsSyncUsers

StoreFront maintains the membership of these security groups. They are used for access control within StoreFront, and are not applied to Windows resources such as files and folders. Do not modify these group memberships.

• Certificates in StoreFront

Server certificates

Server certificates are used for machine identification and Transport Layer Security (TLS) transport security in StoreFront. If you decide to enable ICA file signing, StoreFront can also use certificates to digitally sign ICA files.

For more information see Communication between end users and StoreFront and Ica file signing .

Token management certificates

Authentication services and stores each require certificates for token management. StoreFront generates a self-signed certificate when an authentication service or store is created. Self-signed certificates generated by StoreFront should not be used for any other purpose.

Citrix Delivery Services certificates

StoreFront holds a number of certificates in a custom Windows certificate store (Citrix Delivery Services). The Citrix Configuration Replication service, Citrix Credential Wallet service, and Citrix Subscriptions Store service use these certificates. Each StoreFront server in a cluster has a copy of these certificates. These services do not rely on TLS for secure communications, and these certificates are not used as TLS server certificates. These certificates are created when a StoreFront store is created or StoreFront is installed. Do not modify the contents of this Windows certificate store.

Code signing certificates

StoreFront includes a number of PowerShell scripts (.ps1) in the folder in < InstallDirectory >\Scripts. The default StoreFront installation does not use these scripts. They simplify the configuration steps for specific and infrequent tasks. These scripts are signed, allowing StoreFront to support PowerShell execution policy. We recommend the AllSigned policy. (The Restricted policy is not supported, as this prevents PowerShell scripts from executing.) StoreFront does not alter the PowerShell execution policy.

Although StoreFront does not install a code signing certificate in the Trusted Publishers store, Windows can automatically add the code signing certificate there. This happens when the PowerShell script is executed with the Always run option. (If you select the Never run option, the certificate is added to the Untrusted Certificates store, and StoreFront PowerShell scripts will not execute.) Once the code signing certificate has been added to the Trusted Publishers store, its expiration is no longer checked by Windows. You can remove this certificate from the Trusted Publishers store after the StoreFront tasks have been completed.

• Disabling legacy TLS versions

Citrix recommends that you disable TLS 1.0 and 1.1 for both client and server communication on the Windows server. You can do this via Group Policy or alternatively via Windows registry settings. See Microsoft documentation .

• StoreFront security separation

If you deploy any web applications in the same web domain (domain name and port) as StoreFront, then any security risks in those web applications could potentially reduce the security of your StoreFront deployment. Where a greater degree of security separation is required, Citrix recommends that you deploy StoreFront in a separate web domain.

• ICA file signing

StoreFront provides the option to digitally sign ICA files using a specified certificate on the server so that versions of Citrix Workspace app that support this feature can verify that the file originates from a trusted source. ICA files can be signed using any hash algorithm supported by the operating system running on the StoreFront server, including SHA-1 and SHA-256. For more information, see Enable ICA file signing .

• User change password

You can enable users logging on through a web browser with Active Directory domain credentials to change their passwords, either at any time or only when they have expired. However, this exposes sensitive security functions to anyone who can access any of the stores that use the authentication service. If your organization has a security policy that reserves user password change functions for internal use only, ensure that none of the stores are accessible from outside your corporate network. When you create the authentication service, the default configuration prevents users from changing their passwords, even if they have expired. For more information, see Enable users to change their passwords .

• Customizations

To strengthen security, do not write customizations that load content or scripts from servers not under your control. Copy the content or script into the website custom folder where you are making the customizations. If StoreFront is configured for HTTPS connections, ensure that any links to custom content or scripts also use HTTPS.

• Security Headers

When viewing a store website through a web browser, StoreFront returns the following security related headers that place restrictions on the web browser.

StoreFront uses several cookies. Some of the cookies used in the operation of the website are as follows:

StoreFront sets a number of other cookies to track user state, some of which need to be read by JavaScript so do not have HttpOnly set. These cookies do not contain any information relating to authentication or other confidential information.

• Additional security information

Note: This information may change at any time, without notice.

Your organization may want to perform security scans of StoreFront for regulatory reasons. The preceding configuration options can help to eliminate some findings in security scan reports.

If there is a gateway between the security scanner and StoreFront, particular findings may relate to the gateway rather than to StoreFront itself. Security scan reports usually do not distinguish these findings (for example, TLS configuration). Because of this, technical descriptions in security scan reports can be misleading.

In this article

This Preview product documentation is Citrix Confidential.

You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.

The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.

The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.

If you do not agree, select I DO NOT AGREE to exit.

Do you want to switch to the website in your browser preferred language?

Edit Article

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Policy CSP - UserRights

• 26 contributors

This CSP contains some settings that are under development and only applicable for Windows Insider Preview builds . These settings are subject to change and may have dependencies on other features or services in preview.

User rights are assigned for user accounts or groups. The name of the policy defines the user right in question, and the values are always users or groups. Values can be represented as Security Identifiers (SID) or strings. For more information, see Well-known SID structures .

Even though strings are supported for well-known accounts and groups, it's better to use SIDs, because strings are localized for different languages. Some user rights allow things like AccessFromNetwork, while others disallow things, like DenyAccessFromNetwork.

General example

Here's an example for setting the user right BackupFilesAndDirectories for Administrators and Authenticated Users groups.

Here are examples of data fields. The encoded 0xF000 is the standard delimiter/separator.

Grant a user right to Administrators group via SID:

Grant a user right to multiple groups (Administrators, Authenticated Users) via SID:

Grant a user right to multiple groups (Administrators, Authenticated Users) via a mix of SID and Strings:

Grant a user right to multiple groups (Authenticated Users, Administrators) via strings:

Empty input indicates that there are no users configured to have that user right:

If you use Intune custom profiles to assign UserRights policies, you must use the CDATA tag ( <![CDATA[...]]> ) to wrap the data fields. You can specify one or more user groups within the CDATA tag by using 0xF000 as the delimiter/separator.

&#xF000; is the entity encoding of 0xF000 .

For example, the following syntax grants user rights to Authenticated Users and Replicator user groups:

For example, the following syntax grants user rights to two specific Microsoft Entra users from Contoso, user1 and user2:

For example, the following syntax grants user rights to a specific user or group, by using the SID of the account or group:

AccessCredentialManagerAsTrustedCaller

This user right is used by Credential Manager during Backup/Restore. No accounts should've this privilege, as it's only assigned to Winlogon. Users' saved credentials might be compromised if this privilege is given to other entities.

Description framework properties :

Group policy mapping :

AccessFromNetwork

This user right determines which users and groups are allowed to connect to the computer over the network. Remote Desktop Services aren't affected by this user right.

Remote Desktop Services was called Terminal Services in previous versions of Windows Server.

ActAsPartOfTheOperatingSystem

This user right allows a process to impersonate any user without authentication. The process can therefore gain access to the same local resources as that user. Processes that require this privilege should use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned.

Assigning this user right can be a security risk. Only assign this user right to trusted users.

AdjustMemoryQuotasForProcess

Adjust memory quotas for a process - This privilege determines who can change the maximum memory that can be consumed by a process. This privilege is useful for system tuning on a group or user basis.

AllowLocalLogOn

This user right determines which users can log on to the computer.

Modifying this setting may affect compatibility with clients, services, and applications. For compatibility information about this setting, see Allow log on locally ( https://go.microsoft.com/fwlink/?LinkId=24268 ) at the Microsoft website.

AllowLogOnThroughRemoteDesktop

Allow log on through Remote Desktop Services - This policy setting determines which users or groups can access the sign-in screen of a remote device through a Remote Desktop Services connection.

BackupFilesAndDirectories

This user right determines which users can bypass file, directory, registry, and other persistent objects permissions when backing up files and directories. Specifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system:Traverse Folder/Execute File, Read.

Assigning this user right can be a security risk. Since users with this user right can read any registry settings and files, only assign this user right to trusted users.

BypassTraverseChecking

This user right determines which users can traverse directory trees even though the user may not have permissions on the traversed directory. This privilege doesn't allow the user to list the contents of a directory, only to traverse directories.

ChangeSystemTime

This user right determines which users and groups can change the time and date on the internal clock of the computer. Users that are assigned this user right can affect the appearance of event logs. If the system time is changed, events that are logged will reflect this new time, not the actual time that the events occurred.

When you configure user rights, it replaces existing users or groups that were previously assigned to those user rights. The system requires that the Local Service account (SID S-1-5-19 ) always has the ChangeSystemTime right. Always specify Local Service , in addition to any other accounts that you need to configure in this policy.

If you don't include the Local Service account, the request fails with the following error:

ChangeTimeZone

This user right determines which users and groups can change the time zone used by the computer for displaying the local time, which is the computer's system time plus the time zone offset. System time itself is absolute and isn't affected by a change in the time zone.

CreateGlobalObjects

This security setting determines whether users can create global objects that are available to all sessions. Users can still create objects that are specific to their own session if they don't have this user right. Users who can create global objects could affect processes that run under other users' sessions, which could lead to application failure or data corruption.

Assigning this user right can be a security risk. Assign this user right only to trusted users.

CreatePageFile

This user right determines which users and groups can call an internal application programming interface (API) to create and change the size of a page file. This user right is used internally by the operating system and usually doesn't need to be assigned to any users.

CreatePermanentSharedObjects

This user right determines which accounts can be used by processes to create a directory object using the object manager. This user right is used internally by the operating system and is useful to kernel-mode components that extend the object namespace. Because components that are running in kernel mode already have this user right assigned to them, it isn't necessary to specifically assign it.

CreateSymbolicLinks

This user right determines if the user can create a symbolic link from the computer he is logged-on to.

This privilege should only be given to trusted users. Symbolic links can expose security vulnerabilities in applications that aren't designed to handle them.

This setting can be used in conjunction a symlink filesystem setting that can be manipulated with the command line utility to control the kinds of symlinks that are allowed on the machine. Type 'fsutil behavior set symlinkevaluation /?' at the command line to get more information about fsutil and symbolic links.

CreateToken

This user right determines which accounts can be used by processes to create a token that can then be used to get access to any local resources when the process uses an internal application programming interface (API) to create an access token. This user right is used internally by the operating system. Unless it's necessary, don't assign this user right to a user, group, or process other than Local System.

Assigning this user right can be a security risk. Don't assign this user right to any user, group, or process that you don't want to take over the system.

DebugPrograms

This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications don't need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.

DenyAccessFromNetwork

This user right determines which users are prevented from accessing a computer over the network. This policy setting supersedes the Access this computer from the network policy setting if a user account is subject to both policies.

DenyLocalLogOn

This security setting determines which service accounts are prevented from registering a process as a service.

This security setting doesn't apply to the System, Local Service, or Network Service accounts.

DenyLogOnAsBatchJob

This security setting determines which accounts are prevented from being able to log on as a batch job. This policy setting supersedes the Log on as a batch job policy setting if a user account is subject to both policies.

DenyLogOnAsService

Deny log on as a service -This security setting determines which service accounts are prevented from registering a process as a service. This policy setting supersedes the Log on as a service policy setting if an account is subject to both policies.

This security setting doesn't apply to the System, Local Service, or Network Service accounts. Default: None.

DenyRemoteDesktopServicesLogOn

This user right determines which users and groups are prohibited from logging on as a Remote Desktop Services client.

EnableDelegation

This user right determines which users can set the Trusted for Delegation setting on a user or computer object. The user or object that's granted this privilege must have write access to the account control flags on the user or computer object. A server process running on a computer (or under a user context) that's trusted for delegation can access resources on another computer using delegated credentials of a client, as long as the client account doesn't have the Account can't be delegated account control flag set.

Misuse of this user right, or of the Trusted for Delegation setting, could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.

GenerateSecurityAudits

This user right determines which accounts can be used by a process to add entries to the security log. The security log is used to trace unauthorized system access. Misuse of this user right can result in the generation of many auditing events, potentially hiding evidence of an attack or causing a denial of service. Shut down system immediately if unable to log security audits security policy setting is enabled.

ImpersonateClient

Assigning this user right to a user allows programs running on behalf of that user to impersonate a client. Requiring this user right for this kind of impersonation prevents an unauthorized user from convincing a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they've created and then impersonating that client, which can elevate the unauthorized user's permissions to administrative or system levels.

By default, services that are started by the Service Control Manager have the built-in Service group added to their access tokens. Component Object Model (COM) servers that are started by the COM infrastructure and that are configured to run under a specific account also have the Service group added to their access tokens. As a result, these services get this user right when they're started. In addition, a user can also impersonate an access token if any of the following conditions exist. 1) The access token that's being impersonated is for this user. 2) The user, in this logon session, created the access token by logging on to the network with explicit credentials. 3) The requested level is less than Impersonate, such as Anonymous or Identify. Because of these factors, users don't usually need this user right.

If you enable this setting, programs that previously had the Impersonate privilege may lose it, and they may not run.

IncreaseProcessWorkingSet

Increase a process working set. This privilege determines which user accounts can increase or decrease the size of a process's working set. The working set of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.

Increasing the working set size for a process decreases the amount of physical memory available to the rest of the system.

IncreaseSchedulingPriority

This user right determines which accounts can use a process with Write Property access to another process to increase the execution priority assigned to the other process. A user with this privilege can change the scheduling priority of a process through the Task Manager user interface.

If you remove Window Manager\Window Manager Group from the Increase scheduling priority user right, certain applications and computers won't function correctly. In particular, the INK workspace doesn't function correctly on unified memory architecture (UMA) laptop and desktop computers that run Windows 10, version 1903 or later and that use the Intel GFX driver.

On affected computers, the display blinks when users draw on INK workspaces such as those that are used by Microsoft Edge, Microsoft PowerPoint, or Microsoft OneNote. The blinking occurs because the inking-related processes repeatedly try to use the Real-Time priority, but are denied permission.

LoadUnloadDeviceDrivers

This user right determines which users can dynamically load and unload device drivers or other code in to kernel mode. This user right doesn't apply to Plug and Play device drivers. It's recommended that you don't assign this privilege to other users.

This user right determines which accounts can use a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk. Exercising this privilege could significantly affect system performance by decreasing the amount of available random access memory (RAM).

LogOnAsBatchJob

This security setting allows a user to be logged-on by means of a batch-queue facility and is provided only for compatibility with older versions of Windows. For example, when a user submits a job by means of the task scheduler, the task scheduler logs that user on as a batch user rather than as an interactive user.

LogOnAsService

This security setting allows a security principal to log on as a service. Services can be configured to run under the Local System, Local Service, or Network Service accounts, which have a built in right to log on as a service. Any service that runs under a separate user account must be assigned the right.

ManageAuditingAndSecurityLog

This user right determines which users can specify object access auditing options for individual resources, such as files, Active Directory objects, and registry keys. This security setting doesn't allow a user to enable file and object access auditing in general. You can view audited events in the security log of the Event Viewer. A user with this privilege can also view and clear the security log.

ManageVolume

This user right determines which users and groups can run maintenance tasks on a volume, such as remote defragmentation. Use caution when assigning this user right. Users with this user right can explore disks and extend files in to memory that contains other data. When the extended files are opened, the user might be able to read and modify the acquired data.

ModifyFirmwareEnvironment

This user right determines who can modify firmware environment values. Firmware environment variables are settings stored in the nonvolatile RAM of non-x86-based computers. The effect of the setting depends on the processor. On x86-based computers, the only firmware environment value that can be modified by assigning this user right is the Last Known Good Configuration setting, which should only be modified by the system. On Itanium-based computers, boot information is stored in nonvolatile RAM. Users must be assigned this user right to run bootcfg.exe and to change the Default Operating System setting on Startup and Recovery in System Properties. On all computers, this user right is required to install or upgrade Windows.

This security setting doesn't affect who can modify the system environment variables and user environment variables that are displayed on the Advanced tab of System Properties.

ModifyObjectLabel

This user right determines which user accounts can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. Processes running under a user account can modify the label of an object owned by that user to a lower level without this privilege.

ProfileSingleProcess

This user right determines which users can use performance monitoring tools to monitor the performance of system processes.

ProfileSystemPerformance

This security setting determines which users can use performance monitoring tools to monitor the performance of system processes.

RemoteShutdown

This user right determines which users are allowed to shut down a computer from a remote location on the network. Misuse of this user right can result in a denial of service.

ReplaceProcessLevelToken

This security setting determines which user accounts can call the CreateProcessAsUser() application programming interface (API) so that one service can start another. An example of a process that uses this user right is Task Scheduler. For information about Task Scheduler, see Task Scheduler overview.

RestoreFilesAndDirectories

This user right determines which users can bypass file, directory, registry, and other persistent objects permissions when restoring backed up files and directories, and determines which users can set any valid security principal as the owner of an object. Specifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system:Traverse Folder/Execute File, Write.

Assigning this user right can be a security risk. Since users with this user right can overwrite registry settings, hide data, and gain ownership of system objects, only assign this user right to trusted users.

ShutDownTheSystem

This security setting determines which users who are logged-on locally to the computer can shut down the operating system using the Shut Down command. Misuse of this user right can result in a denial of service.

TakeOwnership

This user right determines which users can take ownership of any securable object in the system, including Active Directory objects, files and folders, printers, registry keys, processes, and threads.

Assigning this user right can be a security risk. Since owners of objects have full control of them, only assign this user right to trusted users.

Related articles

Policy configuration service provider

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources