user right assignment policies

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 is the relationship between User Rights Assignment Policies vs. Membership of Local Groups

I just spent the better part of this morning on a support call with a vendor where we eventually resolved our issue by manually adding the service account their application was using to the following Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/User Rights Assignment policies which were being set by a Domain GPO:

• Back up files and directories
• Log on as a batch job
• Restore files and directories

After rebooting the server and getting the updated GPO our service account no longer generated the following Event 4625 - Logon Type 4 audit events when attempting to start the application:

The vendor's documentation instructed us to add the service account to the Backup Operators and Power User Local Groups - which we did. Reading the Explain tab for each one of the required User Right Assignment policies indicates that the Backup Operators have those Rights by default (TechNet seems to confirm this ). Incidentally, there's no mention of Power User being assigned those Rights that I can find so I'm not really sure why that was a requirement.

Why did we have to explicitly assign that service account those Rights ( Back up files and directories , Log on as a batch job , Restore files and directories ) when it already should of had them by virtue of being a member of the Backup Operators Local Group?

What is the relation between the User Rights Policies and the builtin Local Groups? Are User Rights Polices the constituent parts that make up the "meta"-rights of each builtin Local Groups? If so, where can I find which Rights belong to which bultin Local Groups?

As stated we resolved this issue by adding our service account to the Group Policy Object that is manually assigning a number of service accounts these specific Rights. I got the sense from the vendor's engineer that this GPO is interfering with the mapping of these constituent Rights to Local Groups. Is this hunch correct? Is assigning constituent User Rights this way a Bad Idea (TM)?

• windows-server-2008-r2
• group-policy
• windows-authentication

Members of local built-in groups (as well as domain groups) have whatever rights are assigned to the group. The default rights on a server for local built-in groups are set in the local security settings. To access the local security settings, click Start, type secpol.msc and hit enter. In the Local Security Policy editor, expand Local Policies, and click on User Rights Assignment. There you will see what groups/users are granted which rights.

The local User Rights Assignment settings can be overriden by domain group policy. If you create a domain group policy that grants certain groups/users a certain right, such as "Logon as a batch job", this will override the local policy for which users have that right.

From what you have written, here is what I am guessing happened: You had a GPO in your domain that granted certain users the rights that you mentioned. This policy did not grant these rights to local machine Backup Operators group. This policy overwrote the default policy on the server. Thus, adding the user to the Backup Operators group did not give them those rights because, due to the Domain GPO, the Backup Operators do not have them.

As to whether or not the vendor's solution is a good idea: I have found that it is usually easier to manage rights by using well-organized groups rather than granting them to individual accounts. This way, when you add a new user, you add the user to the logical groups to which he belongs, and he will immediately have all of the rights he needs rather than having to assign him each right one-by-one. That is what the Built-in groups were intended to do.

Instead of granting those three rights to an individual user, you could have granted the "Backup Operators" group those three rights in the GPO. Then adding the user to that group would have the intended effect.

I am curious why you would have a domain policy managing those rights in the first place. If the purpose was to grant certain users access to perform backup operations, it might have been a better idea to use the domain built-in Backup Operators group.

You must log in to answer this question.

• The Overflow Blog
• Why configuration is so complicated
• 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

• How to politely say that I am not doing extra work after back to the office policies?
• How to read a floral diagram?
• Are Catholics supposed to make the sign of the Cross during the Sanctus?
• What do these bars and timer on defense missions indicate?
• What is the point of knowing symmetries, conservation quantities of a system?
• Variable scope issue in scratch buffer?
• Is mathematical truth empirical?
• Are interlocked "traffic signals" possible/in use for taxiing?
• How do I find broken symbolic links in macOS?
• Why are dragons and not fire ferrets considered the original fire benders?
• What is the best statistical test to compare the survey Response rate for a control and treatment group?
• What type of cable is this (optic fiber) connecting to router?
• Why these insulated wire ferrules have the same dimensions for different wire gauge?
• Accuracy of Этимологический словарь иранских языков (Etymological Dictionary of Iranian Languages) by Rastorgueva and Edelman
• Is there a way to make a series change signs every 2 terms?
• \phantom and \obeylines
• How do I auto-start tmux, setting the status bar to a system-unique color?
• Was Jesus physically anointed by someone?
• Can my username include a D&D monster?
• How can the knight traverse a chessboard to make a path that sums to 100
• In simple words, how does UK's Conservative party manage to retain dominance?
• Make the number 606 50 percent bigger
• Understanding the Need for Positive Sync Polarities in Sony PVM Monitors
• What is this strake near the nose of the MD-80 for?

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

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
• Why configuration is so complicated
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network
• Google Cloud will be Sponsoring Super User SE

Hot Network Questions

• Double parenthesis in academic writing
• Configure an op amp with 500 v/v gain with at least a 1k load
• To write letter Cyrillic letter 'Ж' in latex
• Is it safe to provide CVV number by property message in booking.com
• Why machine worlds?
• I forgot an item on board an airplane on a regular flight. Who should I contact to get it back?
• as an learning language app web, should we differentiate between display language and mother language?
• Why different translations of Luke 2:14?
• When I am pedaling harder on a slope, the chain sometimes skips or get detached
• How to deal with an advisor that refuses to accept my evidence for a negative result?
• The Planet of over a Hundred Moons
• Finding the area of a quadrilateral in this picture
• Can someone be awarded the title of doctor without having been a doctoral student?
• How may I find the string length of the index number of a bash array?
• STM32F4 TQFP100 part orientation
• How do I auto-start tmux, setting the status bar to a system-unique color?
• Would it be possible to invent the bicycle with pre-industrial technology?
• Bridget Riley - Movement in Squares and Circles
• How practical would it be to use a handgun-knife hybrid weapon?
• Variable scope issue in scratch buffer?
• Is it acceptable to not give someone credit in a math thesis for minor guidance?
• Was Jesus physically anointed by someone?
• Hand-/Zugtag - what is it?
• Can't restore SQL Server database

All about Microsoft Intune

Peter blogs about Microsoft Intune, Microsoft Intune Suite, Windows Autopilot, Configuration Manager and more

Restricting the local log on to specific users

This week is about restricting the local logon on Windows devices to specific users. Not because it is something particularly new, but simply because it is been an ask every now and then. Think about further locking down a kiosk device, for example. Restricting the local logon can be achieved by either only allowing specific users to log on, or by denying specific users to log on. In other words, whitelisting versus blacklisting. The allow-option is basically a whitelist and the deny-option is basically a blacklist. When looking at restricting the local logon, a whitelist is the easiest method to get quickly really restrictive, as only the users on the list are allowed to log on locally. Luckily, nowadays there is easy method for configuring such a whitelist with users that are allowed to log on locally on a Windows device. This post will provide some more details around that configuration, followed with the configuration steps. This post will end with showing the user experience.

Note : Keep in mind that this post is focussed on the local log on on Windows devices and not the remote log on.

Configuring the allow local log on setting

When looking at configuring the allow local log on configuration, the UserRights section in the Policy CSP is the place to look. That section contains many of the different policy settings of the User Rights Assignment Local Policies , including the Allow log on locally ( AllowLocalLogOn ) policy setting. That policy setting can be used to configure the users that are allowed to locally log on to the Windows device. Besides that, it’s also good to mention that with the latest Windows 11 Insider Preview Builds, this section of the Policy CSP, is getting more and more policy settings. Nearly all of the User Rights Assignment Local Policies are now available for configuration, including Logon as a service , Logon as a batch job , and many more. Maybe even better, all of these available policy settings – including the new policy settings that are currently still in preview – are now configurable via the Settings Catalog profile (as shown below in Figure 1).

After being familiar with the available policy settings and the configuration profile, the configuration of those policy settings is pretty straight forward. The following eight steps walk through the creation of a  Settings Catalog  profile that contains the required setting to configure the local logon, by using the Allow log on locally policy setting.

• Open the  Microsoft Intune admin center  portal and navigate to  Devices  >  Windows  >  Configuration profiles
• On the  Windows | Configuration profiles  blade, click  Create profile
• On the  Create a profile  blade, provide the following information and click  Create
• Platform : Select  Windows 10 and later  to create a profile for Windows 10 and Windows 11 devices
• Profile : Select  Settings catalog  to select the required setting from the catalog
• On the  Basics  page, provide the following information and click  Next
• Name : Provide a name for the profile to distinguish it from other similar profiles
• Description : (Optional) Provide a description for the profile to further differentiate profiles
• Platform : (Greyed out) Windows 10 and later
• On the  Configuration settings  page, as shown below in Figure 2, perform the following actions
• Select  User Rights  as category
• Select  Allow Local Log On  as setting
• Specify the required users and local groups – all on separate lines – and click  Next

• On the  Scope tags  page, configure the required scope tags and click  Next
• On the  Assignments  page, configure the assignment and click  Next
• On the  Review + create  page, verify the configuration and click  Create

Note : As these settings are now configurable via the Settings Catalog , that also takes away the challenges with multiple entries. No need to manually specify a delimiter, as Microsoft Intune takes care of that.

Experiencing the user rights configuration

After configuring the users that are allowed to log on locally to the Windows device, it’s pretty straight forward to experience the behavior. Simply try to log on to that device with a user account that is not allowed to log on locally. That will provide an experience as shown below in Figure 3. The user will receive the notification that the sign-in method is not allowed. Besides that, it’s also important to be familiar with the side effects of this configuration. The most important side effect is the impact on the self-service capabilities, like self-service PIN reset and self-service password reset. That’s simply because those capabilities rely on the temporary account defaultuser1 and that account won’t be able to log in, as only the specified users are allowed to locally log on to the Windows device. That experience is shown below in Figure 4. The user will either receive the status message of 0xc000015b , or will simply be switched back to the logon screen.

Note : The failed log on information is registered in the Security log in the Event Viewer with Event ID 4625 .

More information

For more information about the user rights configuration options, refer to the following docs.

• UserRights Policy CSP – Windows Client Management | Microsoft Learn
• Self-service password reset for Windows devices – Microsoft Entra | Microsoft Learn

25 thoughts on “Restricting the local log on to specific users”

I’d like to contribute to this.

This method does not inherently allow you to specify an EntraID group of users that you wish to deny local logon (at least it didnt use to) however i’ve found that if you use “account protection” policies populate the local group “Guests” with users from an EntraID group you can use the above stated policy to in effect acheive deny local logon for an EntraID group of users. (Via denying the local group “guests” as stated in your blog)

I use this in production, works well

Thank you for that suggestion, Temilit. Regards, Peter

I have not been able to replicate this. I followed inthecloud247’s blog post on this, but the only SID I was able to add to the Guests local group was the SID of an AAD directory role, and not one of an AAD security group.

Which version of Windows are you using? Regards, Peter

• Pingback: Microsoft Roadmap, messagecenter en blogs updates van 21-09-2023 - KbWorks

Can you use an AAD group here?

Not at this moment, Henrik. Regards, Peter

Is there currently a way to restrict interactive log in but allow elevation log in prompts? I would like to prevent Intune Admins from logging in locally but still allow elevation for installs/CMD.

Not sure you can achieve that with this policy, but I haven’t looked really deep in that use case yet. Regards, Peter

• Pingback: Intune Newsletter - 22nd September 2023 - Andrew Taylor
• Pingback: Enabling remote access for specific users on Azure AD joined devices – All about Microsoft Intune

Is there a way to specify an EntraID security group with this settings?

Hi Yoni, The last time I tried that was not possible yet. Regards, Peter

Is there a way sign in KioskUser0 automatically using User Rights?

Hi Mo, Can you provide some more details about what you’re trying to achieve? Regards, Peter

We have deployed Self-Deploy AutoPilot profile plus Kiosk Configuration Profile for single app and then assign to dynamic device group. The Self-Deploy AutoPilot process completes without any issues and Kiosk policy is applied to the device. However, the KioskUser0 should auto logging automatically after Self-Deploy AutoPilot process completes, but its not auto logging.

Any thought why KioskUser0 not auto logging automatically?

Hi Mo, That can be many things, but something I often see is the device lock configuration that is interfering. Regards, Peter

Hello Peter,

We have Azure AD Joined devices in our enviornment which are migrated from source tenant to target tenant as part of carve out project. Recently we observed that post autopilot build completition when user tried to sign in to device they were prompted error as Sign in method not allowed. However, if we tried to login to device with local admins then it allows.

Standard users not allowed to login, we do have AllowLocallyLogIn baseline policy deployed by security team but it contains Administrators and Users group both. Does on Azure AD joined devices this policy really gets validated when users trying to sign in with UPN ?

This issue is not for all users but 10% users are facing, as a workaround when we reimported hash of thier device again and reimaged device then sign in was allowed (bit strange).

Do you have any idea on this then please give some direction.

Hi Suraj, How did you migrate the devices from source tenant to the target tenant? Regards, Peter

I am seeing something similar for new devices. Again, not all, only a subset. quite often, the user can happily use the device for a period (a few days) then this occurs. LOgging onto the device locally, I am seeing the Allow Logon Locally being blank. very odd. This is using Windows 11 23H2

Hi Shaun, When that happens, do you see anything about (other) policies being applied and/or change? Regards, Peter

I tried to do the restriction as in your procedure, but I got the error 65000 in intune. Since then, it has been impossible to connect with ALL the accounts on the computer. Do you have a solution to go back?

Hi Simon, In that case, you should apply a counter policy with the default configuration. Regards, Peter

I’ve had a similar issue. What would the correct counter policy be to reset the default logon configuration or do you have an article that details that?

Hi Mike, Easiest is to check a different device an see what the default configuration is. Regards, Peter

Leave a Comment Cancel reply

Notify me of follow-up comments by email.

Notify me of new posts by email.

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

• Home  / 
• Uncategorized  / 

Configuring User Rights Policies in Intune via Custom Profile

To make a long story short: When configuring user rights policies in Intune with a device configuration (custom profile), you'll find that the sample provided in the docs won't fully work. It does the correct configuration on the clients, but it will show you a remediation error in the Intune portal, which is not very nice.

Credits: Big thanks to Mark Thomas , who helped me solving this one.

Note: There are upcoming changes to Intune announced that should simplify these configurations. Hopefully very soon.

Due to a bug in with the encoding of the delimiter used when following the CDATA syntax, the evaluation fails with an remediation failed error. The bug is due to the fact that the XML parser which handles the  delimiter only works for ADMX backed policies. Looking something like this:

To workaround the issue until the bug is fixed, skip using the CDATA syntax for now. So instead of using this documented syntax to grant Administrators and Users permissions to for example the Allow local LogOn user right:

Use this syntax instead:

Please note the  delimiter. To make sure you get the right character, go to https://coderstoolbox.net/string/#!encoding=xml&action=decode&charset=us_ascii and enter the below text in the input box and press enter.

Johan Arwidmark

I found it… 🙂 <Data></Data>

How is the format if you want to remove all assignments from a specific user right?

Using just <![CDATA[]]> works, but gives an error in Intune reports. According to your post, the CDATA should be left out, but then there is nothing left and a custom OMA URI does not accept an empty string value.

Session expired

Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.

For full functionality of this site it is necessary to enable JavaScript. Instructions how to enable JavaScript in your web browser.

Enumerating remote access policies through GPO

By William Knowles and Jon Cave on 30 January, 2018

William Knowles and Jon Cave

30 January, 2018

When attempting to remain covert as part of a simulated attack it is typically useful to enumerate policies that will influence the outcome of an action before attempting it. In part to avoid wasting time on unobtainable attack paths, and in part to minimise the risk of detection.

One such example of this is where local administrator password hashes or plain text credentials are obtained, and there is a desire to use them to authenticate elsewhere in an environment.  Two notable remote access policies within Windows which affect the outcome of such actions are User Account Control (UAC) and User Rights Assignment (URA).  Depending upon their configuration, each of these can lead to a failure to perform lateral movement, which in turn may generate artefacts that lead to an increased likelihood of detection. Such remote access policies can be enforced locally (e.g., as part of a gold image) or remotely (e.g., through group policy in Active Directory).  This post will provide two contributions in this latter domain:

•  It will provide a reference for how to enumerate group policy for particular policy settings, and then associate those with the computer objects on which they may be enforced. A use case of remote access policies is used.
•  It will introduce some proof-of-concept PowerView extensions to enable these activities.

For the red team this post will provide some operational security considerations and arm you with some tooling to aid targeted lateral movement.  For the blue team this will provide guidance on attacker tradecraft for your playbooks, and new material for generating indicators of compromise for your threat hunting teams.  If you want to skip to the code it has been made available on Github ( https://github.com/mwrlabs/gists/blob/master/PowerView-with-RemoteAccessPolicyEnumeration.ps1 ).  Alternatively, read on for a primer on UAC and URA, and the details on how group policy can be abused to map its settings to particular computer objects.

A use case of remote access policies: User Account Control and User Rights Assignment

This section highlights some of the UAC and URA configuration options which can be set through group policy and how they affect the remote authentication process.  Where they are stored and how they can be enumerated is explored later in this post.

User Account Control: LocalAccountTokenFilterPolicy, FilterAdministratorToken, and ... EnableLUA?

The purpose of  UAC  is to provide a means of isolating processes by enabling them to run at different integrity levels (or levels of trustworthiness).  The settings that affect UAC behaviour are stored as registry key properties at the following location within the HKEY_LOCAL_MACHINE registry hive:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

There are three notable properties which affect UAC behaviour during remote authentication.  Each of these settings determines how access tokens are filtered for remote connections by users within the local administrators group.  In practical terms, it controls whether it is possible to perform remote authentication and obtain a high integrity access token, or whether it is filtered to a lower integrity level.  From a security assessment perspective, a high integrity access token is required to establish remote administrative access.

• EnableLUA  – Used to enable (1, the default) or disable (0) “Admin Approval” mode for the computer. The effect of this setting is rarely mentioned within security literature; however, it is integral to the functioning of UAC.  If disabled, all UAC policies are also disabled.  When disabled, it is possible to perform privileged remote authentication with any member of the local administrators group using plaintext credentials or password hashes.  All access tokens for local administrators are set to high integrity during remote authentication.  When enabled, privileged remote authentication capability is determined by the settings of LocalAccountTokenFilterPolicy and FilterAdministratorToken.

• LocalAccountTokenFilterPolicy  – Used to control the policy for filtering the access tokens of remote connections for all local users within the local administrators group. When set to 0 (the default), remote connections with high integrity access tokens are only possible using either the plaintext credential or password hash of the RID 500 local administrator (and only then depending on the setting of FilterAdministratorToken).  For non-RID 500 local administrators access tokens for remote connections are filtered (i.e., medium integrity).  If set to 1, the policy allows remote connections with high integrity access tokens from any member of the local administrators group using either their plaintext credentials or password hashes.  Will Schroeder (@harmj0y) provides further detail on the role of LocalAccountTokenFilterPolicy within his  blog post  that clarifies the impact of KB2871997 on passing-the-hash (or lack thereof).   Note that even if LocalAccountTokenFilterPolicy is set to 0, if EnableLUA is disabled (0), EnableLUA takes precedence as there is no UAC enforced to provide filtering.
• FilterAdministratorToken  - Used to enable (1) or disable (0, the default) “Admin Approval” mode for the RID 500 local administrator. When enabled the access token for the RID 500 local administrator is filtered (i.e., medium integrity), and therefore, it is not possible to perform privileged remote authentication using the RID 500 local administrator using either plaintext credentials or password hashes.  In a standard Windows build, the default setting of LocalAccountTokenFilterPolicy and FilterAdministratorToken explain why it is only possible to perform privileged remote authentication with the RID 500 local administrator account.  Although this is disabled by default, an example situation which may occur is where FilterAdministratorToken is enabled through a gold image, but then selectively disabled through group policy for particular computer objects.  Such situations may enable lateral movement using any identified credential material for the RID 500 local administrator.

Although all three of these registry key properties reside within the same location in the Windows registry, there is a difference in the way that they are configured through group policy, and how they are stored within the group policy configuration files.  Understanding this is integral to understanding how they can be enumerated.

Configuring EnableLUA and FilterAdministratorToken

Both EnableLUA and FilterAdministratorToken have explicit configuration options within the Group Policy Management Editor.   For EnableLUA this is “User Account Control: Run all administrators in Admin Approval Mode” and for FilterAdministratorToken “User Account Control: Admin Approval Mode for the built-in Administrator account”.  These settings can be found at:

-> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “User Account Control: Admin Approval Mode for the built-in Administrator account” -> “User Account Control: Run all administrators in Admin Approval Mode”

The “Security Options” settings are stored within an INF configuration file with the name "gpttmpl.inf” in the relevant group policy container on the SYSVOL share hosted by each domain controller.

\\<Domain>\Policies\{<GUID>}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

The following figure shows a situation where “EnableLUA” is disabled.

Configuring LocalAccountTokenFilterPolicy

LocalAccountTokenFilterPolicy can not be set through an explicit configuration option within the Group Policy Management Editor.  Instead it needs to be set through the definition of a custom registry key property.  Within the Group Policy Management Editor this can be done at the following location:

-> Computer Configuration -> Preferences -> Windows Settings -> Registry -> <Custom Key and Property Definition>

The consequence of this is that the configuration is stored in a different location within the group policy container.  This time it is an XML document named Registry.xml.

\\<Domain>\SYSVOL\<Domain>\Policies\{<GUID>}\Machine\Preferences\Registry\Registry.xml

The following figure shows an example Registry.xml configuration where LocalAccountTokenFilterPolicy is enabled (1).

User Rights Assignment: SeDeny*?

The purpose of  URA  is to dictate the manner in which a user can authenticate to a system, while also providing a further means of granting that user certain privileges.   The settings that affect URA behaviour are not readily available to be queried within the Windows registry.

There are two notable URA settings which affect remote authentication.  Each of these begins with the SeDeny* prefix and can be configured through group policy.

• SeDenyNetworkLogonRight – Used to deny certain users or groups the ability to perform network authentication, which is used, for example, by the Remote Process Call (RPC) Endpoint Mapper and Server Message Block (SMB) services.
• SeDenyRemoteInteractiveLogonRight – Used to deny certain users or groups the ability to perform remote interactive authentication, which is used by the Remote Desktop Protocol (RDP) service.

If a user or group is associated with either of these settings, the required authentication for lateral movement over the associated protocols will not be possible.  That is, by associating them with the setting (or right), they are denied the ability to perform certain types of authentication.

One means of preventing the abuse of local credential material is by associating the built-in “Administrators” group these settings.  This does have a secondary effect which is commonly misunderstood, and is worth mentioning here.  Namely that this affects all objects within this group, including domain users and groups that have been included within it.  For example, as the “Domain Admins” group is by default placed within the built-in “Administrators” group on domain joined computer objects, it will also not be possible to authenticate over the relevant protocols using these accounts, despite their privileged nature within the wider domain.

In addition to the above URA settings, it should also be noted that similar SeDeny* settings exist for denying users or groups the ability to perform local authentication, authentication as a service, and authentication as a batch job.

Configuring SeDenyNetworkLogonRight and SeDenyRemoteInteractiveLogonRight

SeDenyNetworkLogonRight and SeDenyRemoteInteractiveLogonRight have explicit configuration options within the Group Policy Management Editor.   For SeDenyNetworkLogonRight this is “Deny access to this computer from the network” and for SeDenyRemoteInteractiveLogonRight “Deny log on through Remote Desktop Services”.  These settings can be found at:

-> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> “Deny access to this computer from the network” -> “Deny log on through Remote Desktop Services”

The “User Rights Assignments” settings are stored within the same "gpttmpl.inf” SYSVOL file as was used for “Security Options” with the UAC settings.

The following figure shows a situation where SeDenyNetworkLogonRight and SeDenyRemoteInteractiveLogonRight are configured to include the built-in “Administrators” group.  This group is automatically represented in the configuration by its well-known SID “S-1-5-32-544” rather than the group name.

Enumerating remote access policies with PowerView

With the understanding of UAC and URA policies and how they impact remote authentication, along with how these policies are stored within group policy containers, we can begin to enumerate them.  For this, the ever fruitful PowerView within the  PowerSploit framework  is used heavily (here the development branch is used as a base).  In addition, three functions have been created to facilitate the enumeration of remote access policies: Find-ComputersWithRemoteAccessPolicies, Get-DomainGPORemoteAccessPolicy, and Get-RegistryXML.  The code for these functions can be found on MWR Labs Github ( https://github.com/mwrlabs/gists/blob/master/PowerView-with-RemoteAccessPolicyEnumeration.ps1 ) are described in brief below.

Get-DomainGPORemoteAccessPolicy contains the core functionality of the additional functions, and identifies GPOs that establish the remote access policies of interest.  This functionality closely parallels the existing Get-DomainGPOLocalGroup.  The details of each GPO is retrieved using PowerView’s Get-DomainGPO, and the contents of each group policy container is inspected for the GptTmpl.inf and Registry.xml files.  PowerView makes this process painless by providing the path to the group policy container within the ”gpcfilesyspath” property of each GPO object as shown in the following figure.  As described in the previous sections, the files of interest then exist within a known subdirectory structure.

PowerView already provides a function for parsing the GptTmpl.inf file in Get-GptTmpl.  Therefore, Get-DomainGPORemoteAccessPolicy simply needs to examine the returned object for the registry keys of interest.  However, no such existing function exists for Registry.xml.  Despite this the required functionality closes parallels PowerView’s Get-GroupsXML.  Get-RegistryXML performs similar actions for Registry.xml but instead returns a list of PSObjects containing each registry modification.

The following code snippet shows a subset of Get-DomainGPORemoteAccessPolicy’s functionality for performing the above actions; namely, retrieving each GPO and checking if it disables UAC by setting the EnableLUA property to 0.

Get-DomainGPO @SearcherArguments | ForEach-Object { $GPOdisplayName = $_.displayname $GPOname = $_.name $GPOPath = $_.gpcfilesyspath # EnableLUA and FilterAdministratorToken check via GptTmpl.inf $ParseArgs = @{ 'GptTmplPath' = "$GPOPath\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf" } if ($PSBoundParameters['Credential']) { $ParseArgs['Credential'] = $Credential } # parse the GptTmpl.inf file (if it exists) for this GPO $Inf = Get-GptTmpl @ParseArgs if($Inf -and ($Inf.psbase.Keys -contains "Registry Values")) { $EnableLUA = $Inf["Registry Values"]["MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA"] if ($EnableLUA -and ($EnableLUA[0] -eq 4) -and ($EnableLUA[1] -eq 0)) { Write-Verbose "The following GPO enables pass-the-hash by disabling EnableLUA: $GPOdisplayName - $GPOname" # append to EnableLUA GPO list if it is not already there if ($RemoteAccessPolicies.EnableLUA -notcontains $GPOname) { $RemoteAccessPolicies.EnableLUA += $GPOname } } <snip>

Get-DomainGPORemoteAccessPolicy returns a hash table where the key is the name of each property being searched for (e.g., EnableLUA), and the value is a list of GPOs in which that property was set to the value of interest.

Get-DomainGPORemoteAccessPolicy was not intended to be called directly but to act as an auxiliary function for Find-ComputersWithRemoteAccessPolicies.  Find-ComputersWithRemoteAccessPolicies acts as a wrapper which takes the output of Get-DomainGPORemoteAccessPolicy, determines what organisational units the GPO is linked to, and then determines what computer objects are in those organisational units.  PowerView, once again, makes the process of establishing the link between organisational units and GPOs simple, as the objects returned by the Get-DomainOU function contains a “gplink” property which describes linked GPOs.

A code snippet from Find-ComputersWithRemoteAccessPolicies is shown below which performs the process described above.  The computer objects on which the remote access policies are set are added to a hash table, where the key is policy, and the value is a list of DNS hostnames.

$RemoteAccessPolicies = Get-DomainGPORemoteAccessPolicy @gpoSearchArguments $RemoteAccessPolicies.PSObject.Properties | ForEach-Object { $policy = $_.Name # EnableLUA, etc foreach ($guid in $RemoteAccessPolicies.$policy) { # set arguments for OU search (readding $SearchBase to limit the scope) $ouSearchArguments = @{} $ouSearchArguments = $ouSearchArguments + $SearcherArguments $ouSearchArguments['GPLink'] = $guid Get-DomainOU @ouSearchArguments | ForEach-Object { $compSearchArguments = @{} $compSearchArguments = $compSearchArguments + $SearcherArguments $compSearchArguments['SearchBase'] = $_.distinguishedname $OUComputers = Get-DomainComputer @compSearchArguments $OUComputers | ForEach-Object { if ($ComputerObjectsWithRemoteAccessPolicies.$policy -notcontains $_.dnshostname) { $ComputerObjectsWithRemoteAccessPolicies.$policy += $_.dnshostname } <snip>

The following figure shows this object returned by Find-ComputersWithRemoteAccessPolicies and how it can be leveraged to identify targets for lateral movement.

For this theoretical scenario, if a gold image with local administrative credential reuse is assumed for all computer objects, the results can be interpreted as follows.  UAC has been disabled (through EnableLUA) on three computer objects which creates the opportunity for reusing non-RID 500 credential material; however, the “Administrators” group is included within the SeDenyNetworkLogonRight settings for two of these hosts (“HR-COMPUTER-1” and “HR-COMPUTER-2”) which prevents lateral movement to them using network authentication (e.g., as is required with psexec).  This would also prevent lateral movement using the RID 500 “Administrator” account.  For the remaining computer object (“DEV-COMPUTER-1”) lateral movement through the reuse of any local administrative credentials (both RID 500 and non-RID 500) would remain possible.  For all computer objects, if the plaintext credentials for users in the built-in “Administrators” group could be obtained, these could be used for remote interactive authentication (e.g., RDP).  This is because such authentication has not been explicitly disallowed through the SeDenyRemoteInteractiveLogonRight. A flow chart visualisation of these attack paths is shown below.

This post set out to describe the process of enumerating group policy for particular policy settings, and determining computer objects to which they may apply.  The use case was one of remote access policies.  In particular, for determining computer objects to which local credential material may be able to be reused due to UAC and URA settings for remote authentication. A set of PowerView extensions were also produced to enable such activities, which have been made available on MWR Labs Github ( https://github.com/mwrlabs/gists/blob/master/PowerView-with-RemoteAccessPolicyEnumeration.ps1 ).

Although remote access policies were the core focus of this post, it provides a simple illustration of how the same approach could be applied to any other policy setting.  For example, this could be used by an attacker to identify computer objects that are running (or in certain circumstances potentially not running) a piece of software if the settings are enforced through group policy.  Such an approach would also be challenging for the blue teams to detect due to the quantity of legitimate traffic that interacts with SYSVOL.

There are two key limitations of the current implementation and opportunities for future work:

• The association between organisational units and GPOs is a simple associative relationship, and not a PowerShell reimplementation of Resultant Set of Policies (RSoP); therefore, it does not account for group policy hierarchy (e.g., one GPO overwriting the settings of another). A further implication of this is that targeted searches (e.g., through “-SearchBase <organisational unit>”) will not capture settings established in other organisational units.
• It also does not account for security filtering on GPOs, which are used to configure a GPO to apply to only a subset of objects within the organisational unit to which it is applied.

Despite these limitations, the approach does provide a means of rapidly triaging potential computer objects with interesting remote access policies for lateral movement.

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