user rights assignment regedit

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

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.

How can I locate Registry key for Group policy settings?

How can I locate the registry entry for the below values

• Perform volume maintenance tasks
• Lock pages in memory

under Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\User Rights Management .

I tried the below 3 ways.

• Find the Registry key for corresponding Group Policy : (1)Final Link broken (2)Couldn't locate above in reference guide or MSDN doc.
• Which Registry Settings a Group Policy Object Modifies : No policy-related registry key located in Procmon
• How Settings are Stored : Nothing insightful in the .ini file.

End goal is to automate configuration thru Powershell [ Set-ItemProperty ]

• group-policy
• windows-server-2016

3 Answers 3

As you can see in the Group Policy Settings Reference Guide (see your 1st link; in particular, Windows10andWindowsServer2016PolicySettings.xlsx document ), most of security settings (e.g. User Rights , Password Policy , Audit Policy etc.) are not registry keys . Those are stored in the Secedit.sdb database.

For your task, you can use Microsoft's secedit command line tool (at least, export and import):

secedit Configures and analyzes system security by comparing your current configuration to specified security templates. Syntax secedit [/analyze /db <database file name> /cfg <configuration file name> [/overwrite] /log <log file name> [/quiet]] [/configure /db <database file name> [/cfg <configuration filename>] [/overwrite] [/areas [securitypolicy | group_mgmt | user_rights | regkeys | filestore | services]] [/log <log file name>] [/quiet]] [/export /db <database file name> [/mergedpolicy] /cfg <configuration file name> [/areas [securitypolicy | group_mgmt | user_rights | regkeys | filestore | services]] [/log <log file name>]] [/generaterollback /db <database file name> /cfg <configuration file name> /rbk <rollback file name> [/log <log file name>] [/quiet]] [/import /db <database file name> /cfg <configuration file name> [/overwrite] [/areas [securitypolicy | group_mgmt | user_rights | regkeys | filestore | services]] [/log <log file name>] [/quiet]] [/validate <configuration file name>] Parameters Secedit: analyze Allows you to analyze current systems settings against baseline settings that are stored in a database. The analysis results are stored in a separate area of the database and can be viewed in the Security Configuration and Analysis snap-in. Secedit: configure Allows you to configure a system with security settings stored in a database. Secedit: export Allows you to export security settings stored in a database. Secedit: generaterollback Allows you to generate a rollback template with respect to a configuration template. Secedit: import Allows you to import a security template into a database so that the settings specified in the template can be applied to a system or analyzed against a system. Secedit: validate Allows you to validate the syntax of a security template.

Answer : Look for the below keys/entries under [Privilege Rights] section in the exported configuration file (you can add/change them easy using Powershell):

• SeLockMemoryPrivilege     Lock pages in memory
• SeManageVolumePrivilege  Perform volume maintenance tasks

Read (and follow) Windows Security Baselines as well:

A security baseline is a group of Microsoft-recommended configuration settings that explains their security impact. These settings are based on feedback from Microsoft security engineering teams, product groups, partners, and customers.

• Is there a way to read and write to Secedit.sdb using the Get-PolicyFileEntry cmdlet in the PolicyFileEditor module? –  Ayan Mullick May 8, 2018 at 14:34
• 1 PolicyFileEditor module = commands and DSC resource for modifying Administrative Templates settings in local GPO registry.pol files. Nothing about Secedit.sdb afaik. –  JosefZ May 8, 2018 at 19:37

You can use GPSearch resource to get corresponding keys: https://gpsearch.azurewebsites.net/

Also, you can try to apply the policy and track the changes in the registry with Process Monitor: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

• The above policies don't show up on the GPSearch site probably since they aren't stored in the registry... –  Ayan Mullick May 18, 2018 at 18:36

While this answer isn't applicable for the policies specified in the question, I just wanted to throw https://admx.help in the ring for finding any registry keys relating to administrative templates policies. I prefer it over GPSearch mentioned by batistuta09 as it is much easier to read the information relating to the key/s, in my opinion.

To locate a desired key, scroll to and click on your OS of choice, then the policy categories trees for administrative templates we're all familiar with will appear on the right-hand side to be explored.

For example, I wanted to locate any keys associated with enabling the policy "Specify settings for optional component installation and component repair" locally on my Windows 10 machine (Local Computer Policy > Computer Configuration > Administrative Templates > System). On the website home page, you navigate as follows:

Windows 10 and Windows Server 2016 > Administrative Templates (Computers) > System > Specify settings for optional component installation and component repair

Once the policy is selected, any associated keys and their details are displayed clearly.

2022 edit: Updated url from getadmx.com to admx.help. Thanks, @Henke.

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged powershell group-policy windows-server-2016 automation ..

• The Overflow Blog
• Want to be a great software engineer? Don’t be a jerk.
• Climbing the GenAI decision tree sponsored post
• 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 manager ask me to find someone to cover shifts AFTER I quit?
• G has a element of order 2 not lying in center
• How important was the US steel industry to the allies during World War II?
• Why did Nicaragua file a case against only Germany at the ICJ?
• A nightmarish short story where a man finds that all the people he knew do not exist anymore
• Can I make attacks non-lethal?
• Do Bell’s inequalities assume determinism?
• Temporal difference formula Sutton & Barto tic-tac-toe
• Detailed derivation for the log likelihood of a logistic multinomial model
• To what extent can citizens of democracies be held responsible for the acts of their governments?
• Short story. Humans and machines have co-operated in peace and prosperity on Earth for hundreds of years. Aliens attack and begin slaughtering humans
• Differences Between `/dev/null` and Devices Under `null_blk` Driver
• Metastability concern in bang-bang phase detector
• AirBnB: cancel confirmed booking with low price as a host
• Why is remote desktop very slow when host monitor is off unless HDMI cable is used?
• Adding event listeners in the Constructor of LWC
• What is SpaceX doing differently with their Falcon 9 so that it doesn't cost as much as the Space Shuttle?
• People who frequently travel in planes are called…?
• Noun phrase with adjective
• Is it possible to stop weeping between threaded copper joint on sprinkler system?
• Professor Rackbrane: Count the triangles
• Bash 4: unexpected EOF while looking for matching `)'
• Can I mark a local variable as safe for a single file only?
• Why does a goddess put a low limit on the number of priests?

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.

Which registry key is modified by Security Policy SeDebugPrivilege?

I'm trying to find the registry key(s) that are modified by the Security Policy "Debug Programs" - aka SeDebugPrivilege in Windows 8.

I remember once seeing a web page that would identify each registry key based on a policy setting, but cannot seem to find it.

All my searching for the SeDebugPrivilege registry key doesn't seem to provide any additional insight.

Does anyone know what key(s) are modified by this setting and/or how to find out?

• windows-registry
• group-policy

3 Answers 3

You can establish the registry key(s) a policy links to by consulting the reference lists given out by Microsoft:

Group Policy Settings Reference for Windows and Windows Server

According to that list you won't find this one in the registry, as the "User Rights security settings are not stored in registry keys".

Privileges are not in the registry (because that would leave a hole).

According to this page, it is possible (with suitable current privileges) to adjust privileges for a given process: Topic: Tip: Easy way to enable privileges

For reference:

• User Rights
• Privilege Constants

SeDebugPrivilege is not a security policy at all. It's a user privilege.

The association between accounts and user privileges is stored in the SAM database. When you authenticate to an account that holds a privilege, that privilege is reflected in your process's security access token. This enables processes running with that token to use the debugging APIs.

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged windows-8 windows-registry group-policy ..

• The Overflow Blog
• Want to be a great software engineer? Don’t be a jerk.
• Climbing the GenAI decision tree sponsored post
• 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

• Bash 4: unexpected EOF while looking for matching `)'
• What is a safe way to transport an e-bike battery on planes?
• What is the correct formulation of Newton's Second Law of Motion?
• What is this glyph on Feb 23 1940 in a Finnish military calendar?
• What does an ADC (add with carry) instruction following ADD do?
• Can religions die?
• Do you say "my car is high on fuel" as a counterpart of "my car is low on fuel"?
• Water heater leak increasing when main water line is turned on , but the valve is shut off
• Western politicians who accused Israel of starving Gaza
• Adding event listeners in the Constructor of LWC
• Detailed derivation for the log likelihood of a logistic multinomial model
• Noun phrase with adjective
• Can I make attacks non-lethal?
• What is the apparent size of the Earth and Sun from Moon
• Do intutionists think the law of the excluded middle is universally, metaphysically false?
• Find highest number of swaps within a set of possible duty swaps with networkx and PuLP
• Is this super soldier viable and grounded?
• Almost sure probability in convergence, versus 0 probability in reality
• Is it possible to find sum of x^x from a to b without using summation but rather a less computationally heavy method?
• Can you launch a pellet created with Dust of Dryness to smash it at range?
• Proving a Grassmann integral identity
• A nightmarish short story where a man finds that all the people he knew do not exist anymore
• Is/was there something in US law that terrorists could not benefit from funding/aid "even inadvertently"?
• incomplete table borders, truncated, watertight

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 .

• NIST 800-53
• Common Controls Hub

The Allow log on locally user right must only be assigned to the Administrators and Users groups.

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.

User rights assignment in Group Policy Object using powershell?

Not able to grant user rights assignment in group policy object using PowerShell Is there any way or command to add user rights in group policy?

Manual steps:

• Open Group Policy Management
• Navigate to the following path in the Group Policy Object
• Select Policy
• Right click & Edit: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.
• Add/remove the necessary users.

Active Directory A set of directory-based technologies included in Windows Server. 5,793 questions Sign in to follow

Windows Server PowerShell Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications. PowerShell: A family of Microsoft task automation and configuration management frameworks consisting of a command-line shell and associated scripting language. 5,341 questions Sign in to follow

I realise this post is quite old, but there is a post that talks about a way you could do this by building up a GPO, the same way the export/import GPO works in Powershell: https://jigsolving.com/gpo-deep-dive-part-1/ Within that article, there's a bare bones example of this on Github: https://github.com/Jigsolving/powershell/blob/main/User%20Rights%20Assignment%20GPO/create-customURAGPO.ps1

It definitely works, and this is just one way it can be done. The article focuses on basically building up the raw bones of a GPO that resembles what an exported GPO looks like, and then imports it.

Give this a try.

https://learn-powershell.net/2015/06/03/managing-privileges-using-poshprivilege

Thanks @MotoX80 for sharing this module Tried this module but it didn't work as per my expectations I am looking to add user rights in group policy in group policy management of domain controller but this module gives user rights in local policy. If you have another module or command please share I also tried Set-GPPermission but it is giving user permission to edit settings, delete, modify security.

I no longer have access to an AD environment, so I am not able to test. Perhaps another forum user can provide assistance.

Have you seen this page?

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd759177(v=ws.11)?redirectedfrom=MSDN

https://www.ntweekly.com/2020/08/07/configure-a-group-policy-with-powershell/

Yes, already seen these pages And as per https://www.microsoft.com/en-au/download/details.aspx?id=25250 this link/sheet user rights assignment don't have registry keys.

Random thoughts from a retired sysadmin....

Well it has to be stored somewhere on the DC.

https://techgenix.com/group-policy-settings-part1/

Make a change to one policy and then search the sysvol folder and see if you can find the file that contains your update. If that's a text based file (not in binary format) then you might be able to update the policy just like you would update the content of any other text file.

I assume that you have already done the "Import-Module GroupPolicy" and searched for "GP" related commands as that page described. If you haven't, then you should start there.

Hi @ArpitShivhare-6858

I've had to do something similar in the past with automatic GPO generation, and the below was the only way I could find to do so. It basically creates the GPO manually, but it should work for your purposes

To add additional fields or users to the Local User Rights Assignments, I would recommend creating the GPO manually, then taking a look at the GptTmpl.inf file to see what format, values and syntax of the fields required. From my testing it uses SIDs, not the SamAccountName value, so you will have to pull the SID for each user that you need to add