user rights assignment in windows 10

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

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Facebook (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Reddit (Opens in new window)

32 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

We have the same case, did you resolve it?

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

Hello, What do you mean when you say “you should apply a counter policy with the default configuration” ? Can you post a screenshot ?

Regards Olivier

Hi Olivier, I mean that you should configure the same policy, but with the default configuration that is available on the devices within your environment. 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

I know this has been a bit since you created this article, but have you been able to automate the AllowLocalLogOn to only the primary user?

I’ve been looking into this my self, but I don’t seem to be able to automate it via policy. The only way seems to be script based?

That is correct. If you want to match it with the primary user, you would need to use some custom scripting. Regards, Peter

Is there a way to rollback this policy once implemented?

Hi Ninad, You can always counter the policy by configuring the original values. 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 .

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

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

Get early access and see previews of new features.

How to assign user rights to a local user account through powershell?

I want to modify the user rights associated with a local user account.I want to add groups and users to a particular User Rights. This is done by opening the group policy and opening the following folder in the console tree: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Then click on the required user Right and add the user or group to it.

Is it possible to do the same through powershell scripts?

4 Answers 4

What I would do is open SecPol.msc, make your modifications via the GUI to a baseline computer and export an .inf template for installation via powershell.

The template can be installed with secedit.exe. If you want, you can open the inf file in a text editor and scroll until you see the [Privilege Rights] section. Here is one for example.

Run this command and reboot. Edit .inf and .db names as appropriate.

Found a third party command line solution. ntwrongs.exe

http://forums.mydigitallife.info/threads/57557-NTWrongs%99

Here is a purely powershell method - https://stackoverflow.com/a/26393118

To build upon @Knuckle-Dragger's answer:

I couldn't add my user to the secreatesymboliclinkprivilege setting ( Computer Configuration > Windows Settings > Security Settings > Local Policies > ** User Rights Assignment** > Create symbolic links ), always with the error "The specified domain either does not exist or could not be contacted", and it worked with his method, for my DOMAIN\user account from the whoami output:

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged windows powershell or ask your own question .

• The Overflow Blog
• Detecting errors in AI-generated code
• Featured on Meta
• User activation: Learnings and opportunities
• Preventing unauthorized automated access to the network
• Announcing the new Staging Ground Reviewer Stats Widget

Hot Network Questions

• Is double possessive applicable in “the names of the parents’ in the film”?
• How do cafes prepare matcha in a foodsafe way, if a bamboo whisk/chasen cannot be sanitized in a dishwasher?
• Red dwarfs and red giants
• What is the meaning of 其 in 以色列军队称其“几乎完全瓦解”了真主党领导层?
• Can I still access the potato dimension?
• The 12th Amendment: what if the presidential and vice-presidential candidates are from the same state?
• Does General Relativity predict Mercury's orbital precession without other planets?
• Can Inductors be thought of as storing voltage?
• Is the Extensionality Axiom circular?
• How safe is the runastool.exe, any known issues?
• Better Methods to Find a Point's Coordinates with Three Collinear Points
• Compactness with respect to topology induced by TV distance
• What effect will a planet’s narcotic atmosphere have on sound of music at rave parties?
• Why is it surprising that the CMB is so homogeneous?
• Is ext4 and xfs only for usage with internal file systems?
• Can artistic depictions of crime (especially violence) be used as evidence?
• Does AI use lots of water?
• What is the book/author about preserved heads/brains?
• Why is the "scan backwards" method of parsing right-associative operators considered to be anti-pattern? What alternatives are recommended?
• Numerical integration of ODEs: Why does higher accuracy and precision not lead to convergence?
• "immer noch" meaning "still"
• Why do you even need a heatshield - why not just cool the re-entry surfaces from inside?
• Tomatoes measured in quarts
• Enhancing my RSA implement in Python

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

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

How to get it.

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
• containerapps

• NIST 800-53
• Common Controls Hub

Orphaned security identifiers (SIDs) must be removed from user rights on Windows 10.

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.

User Rights Assignment Back To Not Defined

Is it possible to put a Local Policy User Rights Assignment back to Not Defined? There is not a checkbox to mark it as Not Defined. Is it possible to set any of the User Rights Assignments back to Not Defined?

I am trying to find an area of a Group Policy that is causing an issue with the installation of a Windows Feature. I have removed the computer from the domain and many parts of the GPO remains on the computer including User Rights Assignment. I am suspicious that this is causing the error I am getting. I would like to go through the User Rights Assignment to see what is causing the issue. If I can se it back to Not Defined per item them I can see what is causing the issue. But I do not see a way to check a box to put it back. I can remove everyone from the list of users/groups but that just makes the list blank and doesn't set it to Not Configured.

• group-policy
• security-policy

• If a local policy is configured as "Not Defined", it means the current value is the default value, which is either the value for enabled or the value for disabled. There a reason you cannot simply just set the value of the policy back to "not defined' using the group policy editor? Encourage you to provide more information, perhaps even explain what problem you are trying to solve, so we can answer your question. –  Ramhound Commented Sep 8, 2017 at 20:10
• @Ramhound I added some information. I am trying to find a piece of URS causing errors on the installation of a windows server feature. –  JukEboX Commented Sep 8, 2017 at 20:28
• Tell us the exact policy. What it modified in the registry should be easy to determine removing the keys will be how this is done –  Ramhound Commented Sep 8, 2017 at 21:32

User Right Assignment don't have a "default" configuration.

This is due to the fact that these settings are modified by when certain Windows roles and features are installed. Other applications can also modify these rights, creating a situation where a one-size-fits-all definition of default would leave many systems half functional.

Further, the User Right Assignments fall into a broader category of GP settings that cannot be conveniently reverted to a default state due to an effect known as Group Policy tattooing.

You must apply your own "default" settings

If you only have a few User Rights to modify , edit the settings through the Local Group Policy editor ( gpedit.msc ) and refer to another workstation that has the desired rights assignments for your configuration.

If you have many User Rights to modify , then consider using the Secedit command-line tool to export the settings from a computer with the desired configuration and then apply them into the target machine. Example commands:

Export the current machine's User Rights Assignments:

Apply the exported User Rights Assignments to the local machine:

More Information

This Microsoft support article explains why it's not possible to restore Windows Security settings to a so-called default state and offers some possible workarounds.

This and this article discuss Group Policy tattooing and its implications for Windows Security Settings.

You must log in to answer this question.

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

• The Overflow Blog
• Detecting errors in AI-generated code
• Featured on Meta
• User activation: Learnings and opportunities
• Preventing unauthorized automated access to the network

Hot Network Questions

• Can you perceive when a creature "starts its turn"?
• Numerical integration of ODEs: Why does higher accuracy and precision not lead to convergence?
• How fast to play Rachmaninoff’s Études-Tableaux, Op. 33 No. 5 in G minor?
• Why does Leviticus 11 say that the rabbit chews the cud?
• Email from Deutsche Bahn about a timetable change - what do I need to do?
• How do cafes prepare matcha in a foodsafe way, if a bamboo whisk/chasen cannot be sanitized in a dishwasher?
• Why can't I modify/repair Enclave Hellfire Power Armour Pieces with the AWKCR mod installed?
• Is the Extensionality Axiom circular?
• Why is it surprising that the CMB is so homogeneous?
• Red dwarfs and red giants
• Is Wild Shape affected by Moonbeam?
• What is the meaning of 其 in 以色列军队称其“几乎完全瓦解”了真主党领导层?
• What is this general prohibition/slash symbol on my Xcode app
• Why is China's Tiangong space station inaccessible from Russia's launch sites?
• If a non-provisional application claims multiple provisional applications, will there be multiple priority dates?
• What purpose is the GND screw serving in this vanity lighting setup?
• Better Methods to Find a Point's Coordinates with Three Collinear Points
• "Some" depicted
• Threshold percentage for power ratings of resistors?
• Why does lottery write "in trust" on winner's cheque?
• Compactness with respect to topology induced by TV distance
• Change style of True/False everywhere
• Why are NSolve and Solve not working for ArcTan?
• Which tool has been used to make this puzzle?

How to Change User Account Type and Permissions on Windows 10

What are User Accounts Types?

How to change a user account type, what are the permissions for user accounts, how to change the user permissions.

As is known to us all that unlike Windows 7, 8, Windows 10 has removed Guest account. But how much do you know about the User account on Windows 10?

This article would let you be familiar with some facts about the user account on Windows 10, for instance, what types user account can be divided into, what user account permissions are and how to modify user permissions on Windows 10.

You should bear in mind that each PC needs at least a user account.

From one perspective, Windows 10 user account can be classified into two types namely, Administrator account and User standard account. The administrator account is formed as long as you have installed and logged on to Windows 10 for the first time. And the User standard account is usually used by children with which people have rather limited rights on Windows 10.

From another perspective, it can be divided into Microsoft account and local user account. Microsoft account enables you to sign in many apps with the same account, such as Xbox and Hotmail.

No matter what kind of account you would use, you have to make one so long as you want to log on to your PC. You can refer to how to create a user account on Windows 10 . Or some of you are fond of making use of Microsoft account as to login Windows 10, choose to add a Microsoft account to Windows 10.

Here you can move on to learn more about user account permissions.

Do you know for sure whether your account is an administrator or standard account on Windows 10? And have you mastered the way about how to change from standard user account to administrator? For many users, you may someday have the very need to change user account type. Not only change to the administrator but change from the local user account to Microsoft account on Windows 10.

Below are the specific steps for you to change user account type in different occasions. Just select one way most available for you.

1: Change User Account Type in Settings

2: Change User Account Type in User Accounts

3: Change User Account Type in Command Prompt

Way 1: Change User Account Type in Settings

In the first place, you can simply change the account type in account settings new in Windows 10. You can change from local account to Microsoft account and vice versa.

1. Go to Start > Settings > Accounts .

2. Then under Family & other people, locate Other people and hit the account to Change account type .

3. You can choose to make the account an Administrator or a Standard User .

Click OK and reboot Windows 10 to take effect. If you changed this user account type into administrator, it will possess the administrative privileges.

Way 2: Change User Account Type in User Accounts

It also makes sense to change the account type in User Accounts.

1. Press Windows + R to elevate the Run box and then enter netplwiz in the box. Hit OK to get into User Accounts.

2. In User Accounts window, under Users for this computer , choose your account and then hit Properties .

3. Then under Group Membership , tick the box the account type you want to change to, such as Standard user , Administrator , and Other .

Tips: Here if you choose neither Standard user nor Administrator, it is also accessible to choose another account type in Others , such as Guests and Hyper-V Administrators .

Way 3: Change User Account Type in Command Prompt

Either shifting from Standard user to Administrator or from Administrator to Standard user, you can enter the command to achieve that shift if you like simply in Command Prompt with administrative privileges.

Change from Administrator to Standard User in CMD command-line:

1. Type Command Prompt in the search box and then try to right click the result to Run as administrator .

2. In Command Prompt , copy and paste the command below and then hit Enter to run it.

net localgroup Administrators “ACCOUNT-NAME” /delete

Here remember to change Account-Name to the real account name you are using on your PC.

Change from Standard User to Administrator in CMD command-line:

In Command Prompt , enter the following command and press Enter key to run it as well.

net localgroup Administrators “ACCOUNT-NAME” /add

Tips: Bear in mind to change to the real account name as well.

Now you can also check in Command Prompt your account type with the command net user ACCOUNT-NAME .

On the same note, replace the ACCOUNT-NAME with the real one you are using.

After that, maybe it is time for you to learn something about User account permissions.

Just like Windows 7, 8, Windows 10 user files make it possible to allow more than one person or account to use the same PC. And it is common when an administrator account and standard account are logging at the same time. But you may have little understanding that administrator accounts have the high-level permissions. Whereas the Standard user accounts possess low-level permissions on Windows 10.

Specifically, the Administrator account has the permissions to complete the following system actions.

1. Change all the settings controlling the PC .

2. Create, remove and delete the account .

3. Get access to applications .

4. Execute system actions to affect other User accounts .

For the standard User accounts, you can do the actions below.

1. Change password for local user accounts .

2. Change desktop settings or theme .

Now that you have mastered the permissions you can do with your Administrator account or standard user account, you may also hope to modify the administrator or standard user account.

Some people reported that they are unable to modify the user account permissions for Windows 10, here in this post, you will find the way to solve this issue.

1. Hit Windows + R to open Run box. Enter or copy wmimgmt.msc into the box and stroke OK .

2. Right-click WMI Control and choose Properties .

3. Under Security tab, click Security .

4. In Permissions for Users tab, tick the box which you would like to add to the permissions. Here you can also choose Advanced to make more changes to User permissions. Or there is another option you can select, which is to Add or Remove Authenticated Users.

In this process to change security settings or reset permissions for a user account, you must log on to PC with an administrator account.

Now from this post, you can know exactly how user account can be divided into, what the permissions for the administrator account are and how to modify these permissions for Windows 10.

Related Articles:

Fixed: We Can’t Sign into Your Account on Windows 10

Fix: Your Account Has Been Disabled on Windows 10

How to Use Microsoft Account on Windows 10

Leave a Response Cancel reply

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

You Might Also Like

Download and Update CanoScan LiDE 120 Driver On Windows and Mac

3 Ways To Roll Back NVIDIA Driver On Windows 11/10/8/7

3 Ways To Access ASUS Desktop/Laptop Boot Menu

How to Connect Beats Headphones to Android, iPhone, Windows, and Mac

[3 Ways] Download and Update HP LaserJet P1007 Driver On Windows 11/10/8/7

[5 Ways] How To Take Screenshot On Acer Laptop

Stack Exchange Network

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

Q&A for work

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

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

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

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

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

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

• active-directory

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

2 Answers 2

The defaults are documented in:

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

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

It depends on what you're asking.

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

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

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

You must log in to answer this question.

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

• The Overflow Blog
• Detecting errors in AI-generated code
• Featured on Meta
• User activation: Learnings and opportunities
• Preventing unauthorized automated access to the network

Hot Network Questions

• I have a problem about selection
• What is the meaning of 其 in 以色列军队称其“几乎完全瓦解”了真主党领导层?
• Is Wild Shape affected by Moonbeam?
• Hochschild cohomology and differential operators
• Is ext4 and xfs only for usage with internal file systems?
• ぎおんまつり　written with two different kanji for ぎ
• The 12th Amendment: what if the presidential and vice-presidential candidates are from the same state?
• Paired or unpaired t test in two samples of horses and their wound size
• If a non-provisional application claims multiple provisional applications, will there be multiple priority dates?
• Why can't I modify/repair Enclave Hellfire Power Armour Pieces with the AWKCR mod installed?
• Is the Extensionality Axiom circular?
• How can I insert a proper macron-A letter (`ā`) using pdftex?
• How safe is the runastool.exe, any known issues?
• Email from Deutsche Bahn about a timetable change - what do I need to do?
• How to copy and paste pixels in an image
• How do cafes prepare matcha in a foodsafe way, if a bamboo whisk/chasen cannot be sanitized in a dishwasher?
• How Does God Love?
• Adjusting water quanity according to whether I soak rice before cooking
• Recent Zombie apocalypse E-book or Web novel. MC at a college rescues a couple girls then they head to Gym where other students have gathered
• dd backup fails with "File too large" error despite ample free space on FAT32 partition
• Can Inductors be thought of as storing voltage?
• Numerical integration of ODEs: Why does higher accuracy and precision not lead to convergence?
• Threshold percentage for power ratings of resistors?
• Replacing "shall not", "shall be", "shall" etc. with "must" or other more imperative words

• Programming
• Virtualization
• Productivity

Understanding User Rights Assignment - How to lock down or unlock your user's actions

Final notes

• https://www.experts-exchange.com/articles/3360/Understanding-User-Rights-Assignment-How-to-lock-down-or-unlock-your-user's-actions.html copy
• Active Directory

Comments (1)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.

The Original Tech Community

• Server Hardening Automation
• PAC – Policy Analysis Center
• IIS – Hardening Automation

User Rights Assignment - User rights, User wrongs

What are user rights Assignment?

User rights assignments regulate access to computer and domain resources, with the ability to override permissions set on specific objects. Managed in Group Policy , each user right assignment has a constant name as well as a Group Policy name associated with it. The constant names are used when referring to the user right assignments in log events. In this section, they’re referred to as user rights, but they’re commonly known as privileges. Privileges are actions at the computer level that you can assign to users or groups.

User rights assignment is a vital part of IT security access and access control, referring to the permissions and privileges granted to individual users, or groups on a local computer or device level. These permissions dictate what actions users can perform on the system and what resources they can access.

Managed through either the local security policy or group policy settings, these settings define who can perform tasks such as logging on locally, making changes within the system such as the system time, accessing specific files or directories, shutting the system down and more.

Managing user rights assignment is vital for maintaining the security and integrity of Windows servers. By carefully controlling which users have access to which resources and what actions they can perform, administrators can reduce the risk of unauthorized access, data breaches, and other security incidents.

What user rights assignment allow you to do

Unlike file and folder permissions that control access to specific data, user rights govern what actions users can perform on a computer system. These special permissions go beyond basic access and determine a user’s ability to perform tasks as shown in the table below:

Why assign user rights?

User rights assignment act as the gatekeeper to the system, determining what is and is not allowed to access the system. If not correctly configured it can leave a system exposed to potential threats which have been known vulnerabilities in the past:

Privilege Escalation : In some cases, a vulnerability combined with a weak user rights assignment configuration could allow an attacker with some initial access to escalate their privileges to a higher level.

Unintended Access : Many services and applications require network access, if set too permissive an attacker on the network could potentially exploit that vulnerability to gain access to unauthorized information.

Assigning user rights on Windows servers is crucial for maintaining a secure, well-managed environment where access to resources is controlled, and users have the appropriate level of permissions to perform their duties effectively while minimizing security risks.

CIS Microsoft Windows Server 2019 Benchmark Hardening

Significance of rights and permissions

By allocating precise privileges to individual users based on their organizational roles or functions, it is possible to mitigate unauthorized access to sensitive data or restricted areas of a system. If designed well, users of a system have access only to resources they need to perform their job roles.

A system with predefined rights can increase efficiency, minimizing the need for a manager to manually assign individual rights and permissions and the chances of their being human error during configurations.

This also allows for greater scalability, giving a system the flexibility it needs to grow and evolve with a company through growth and restructuring phases. Additionally, each user has a unique customized experience specifically tailored to their needs and roles enhancing day to day activities.

How do user rights assignment work

Assigning user rights offers administrators more granular control over who can perform specific actions or access certain system resources. Taking advantage of the principle of least privilege, it implements a zero-trust approach, ensuring users only have the specific rights necessary to perform their tasks. This helps to minimize the potential impact of security breaches and maintain a more secure system through.

How to find user rights assignment?

To view and modify user rights assignments on a local system:

To view the current User Rights Assignment, open the Local Security Policy tool ( secpol.msc ) either via Start menu or Control Panel:

• Go to the Start Menu.
• Open Windows Administrative Tools.
• Go to Local Security Policy.
• Within the Local Security Policy application, navigate to Security Settings.
• Go to Local Policies.
• User Rights Assignments will be shown as follows:
• To view or modify the list of users and groups, that are assigned to a specific privilege/user right (column “ Policy “), select the item from the list and open the properties dialog:

To view and modify user rights assignments set by Domain Group Policy:

Below is a video explaining how to view and modify user rights assignment via Domain Group Policy:

CIS User Rights Assignment Security Policies

The Center for Internet Security (CIS) is a valuable resource for organizations providing a set of globally recognized best practices and security guidelines to help organizations bolster their security posture. CIS covers various aspects of system configuration, including user authentication, network access control, and user rights assignments.

Within user rights assignments there are 48 individual controls that need to be implemented based on the specific environment and deployment. However these settings are not a one-size-fits-all solution and must be configured individually along with the hundreds more security settings specifically to the needs of each system.

By carefully reviewing and implementing the relevant CIS controls, the overall security posture of a system can be significantly improved and make it more difficult for attackers to exploit vulnerabilities.

User Rights assignment best practices

Managing user rights is complex. Each user has multiple settings that control their actions, and these settings can impact other security measures across the system. Ensuring everything is configured correctly is crucial for robust system security.

Server hardening offers an effective solution. This process automates the configuration and ongoing reinforcement of security settings, reducing manual effort and safeguarding your system in today’s dynamic threat landscape.

Subscribe to Email Updates

• Center for Internet Security (20)
• Compliance (26)
• Configuration Settings (96)
• Domain Controller (3)
• PowerShell (7)
• Remote Desktop Protocol (4)
• Security Account Manager (5)
• Security Guides (16)
• Server Message Block (1)
• System Hardening (20)
• TLS SSL (4)
• Vulnerabilities (23)

You might be interested

Learn how our tools can help you with hardening

• First Name *
• Last Name *
• Job Title *

Experience a personalized demo

Privacy overview.

Tim’s Tech Blurbs

Tim’s tech ramblings about Intune, Modern Management, Powershell and every thing else.

How to move Windows 10 User Rights Assignment to Endpoint Manager / Intune

Should you change the default user rights assignments in Windows 10? That’s the question. If you ask my college the AD expert, he will tell you to run away and don’t even think about changing the defaults. (He will back it up with some pretty funny stories as well about who someone did it and locked out a company and maybe even a ship)

If you ask the Security team, the answer is a yes. We should set them.

Let taks a look. We will start at my favourite site. The Windows 2004 security baseline. MS recommend quite a few setting to be applied. When we add another baseline from the Security team we end up with the table below.

First things first. Let’s check the CSP and see what we need to do. To note, you can user the nice name for the account. (i.e Administrators). But we have ever lanuguage under the sun. So we need a better way to define the accounts. Lets check the Well know SID Structures for what we need.

Lets start with the local administrator. When you check for the SID, be sure to look for the BUILTIN groups and not the domain Groups. Looking at the table the SID is S-1-5-32-544.

Now we check the local account and we get S-1-5-113.

So Lets set up a polcy. Lets open Endpoint Mananger.

Goto Devices -> Configuration Profiles. Select Add new.

Select “Windows 10 and Later” and Custom in the profile

Let’s enter in a Logical name. “Windows 10 User Rights Assignment” and select Save.

Lets Start with “Load and unload device drivers.” Select Add on the next Page. Enter in the name for the setting. I am preceding the name with URA (for User Rights Assignment). In the OMA-URI after in ./Device/Vendor/MSFT/Policy/Config/UserRights/LoadUnloadDeviceDrivers The Data Type should be string. Andter in the desired SID for the setting. In this case it will be *S-1-5-32-544. (Add the * in before to distinguish its a SID) Pres Save.

Done. What’s next. Lets go “Access Credential Manager as a trusted caller”. According the baseline no one should have access to this. But how do we define it so no one can access it. Well don’t press save with a blank field. It will fail (I learn the hard way)

Add a new one and add in the name URA – Access Credential Manager as a trusted caller. Then for the OMA-URI enter in ./Device/Vendor/MSFT/Policy/Config/UserRights/AccessCredentialManagerAsTrustedCaller. Select String again. In the data field I have set the value as </>. If you leave it black you get an error when saving it. Its really annoying if you have added 20 on and then relies they have all failed.

Repeat until you have added them all in. Select Next, and then assign them to your test group. Sync your device, and reboot.

You should also do the testing on a test machine. Just in case you lock your self out.

How can you check the User rings assignments have worked? Lets ask Mark. He usually know these things.

Lets download AccessChk from here. https://docs.microsoft.com/en-gb/sysinternals/downloads/accesschk . It allows you to check various permissions fo r files register etc. We will use it with the -a to give us the Windows account right. Lets check SeSystemtimePrivilege or Change the System time. According to the baseline, only Admin and Local services should have this right. Lets run accesschk.exe -a SeSystemtimePrivilege

Great the values are as we expect. What about the checking all the permissions. Let’s run accesschk.exe -a * to show all the permissions.

Now all the rights look good. So lets plan to roll it out and hope we don’t become a funny storey for my college

Published by Tim Wood

Privacy overview.

This browser is no longer supported.

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

Local Accounts

• 21 contributors
• Applies to: ✅ Windows 11 , ✅ Windows 10 , ✅ Windows Server 2022 , ✅ Windows Server 2019 , ✅ Windows Server 2016

This article describes the default local user accounts for Windows operating systems, and how to manage the built-in accounts.

About local user accounts

Local user accounts are defined locally on a device, and can be assigned rights and permissions on the device only. Local user accounts are security principals that are used to secure and manage access to the resources on a device, for services or users.

Default local user accounts

The default local user accounts are built-in accounts that are created automatically when the operating system is installed. The default local user accounts can't be removed or deleted and don't provide access to network resources.

Default local user accounts are used to manage access to the local device's resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC). Computer Management is a collection of administrative tools that you can use to manage a local or remote device.

Default local user accounts are described in the following sections. Expand each section for more information.

Administrator

The default local Administrator account is a user account for system administration. Every computer has an Administrator account (SID S-1-5- domain -500, display name Administrator). The Administrator account is the first account that is created during the Windows installation.

The Administrator account has full control of the files, directories, services, and other resources on the local device. The Administrator account can create other local users, assign user rights, and assign permissions. The Administrator account can take control of local resources at any time by changing the user rights and permissions.

The default Administrator account can't be deleted or locked out, but it can be renamed or disabled.

Windows setup disables the built-in Administrator account and creates another local account that is a member of the Administrators group.

Members of the Administrators groups can run apps with elevated permissions without using the Run as Administrator option. Fast User Switching is more secure than using runas or different-user elevation.

Account group membership

By default, the Administrator account is a member of the Administrators group. It's a best practice to limit the number of users in the Administrators group because members of the Administrators group have Full Control permissions on the device.

The Administrator account can't be removed from the Administrators group.

Security considerations

Because the Administrator account is known to exist on many versions of the Windows operating system, it's a best practice to disable the Administrator account when possible to make it more difficult for malicious users to gain access to the server or client computer.

You can rename the Administrator account. However, a renamed Administrator account continues to use the same automatically assigned security identifier (SID), which can be discovered by malicious users. For more information about how to rename or disable a user account, see Disable or activate a local user account and Rename a local user account .

As a security best practice, use your local (non-Administrator) account to sign in and then use Run as administrator to accomplish tasks that require a higher level of rights than a standard user account. Don't use the Administrator account to sign in to your computer unless it's entirely necessary. For more information, see Run a program with administrative credentials .

Group Policy can be used to control the use of the local Administrators group automatically. For more information about Group Policy, see Group Policy Overview .

• Blank passwords are not allowed
• Even when the Administrator account is disabled, it can still be used to gain access to a computer by using safe mode. In the Recovery Console or in safe mode, the Administrator account is automatically enabled. When normal operations are resumed, it's disabled.

The Guest account lets occasional or one-time users, who don't have an account on the computer, temporarily sign in to the local server or client computer with limited user rights. By default, the Guest account is disabled and has a blank password. Since the Guest account can provide anonymous access, it's considered a security risk. For this reason, it's a best practice to leave the Guest account disabled, unless its use is necessary.

Guest account group membership

By default, the Guest account is the only member of the default Guests group SID S-1-5-32-546 , which lets a user sign in to a device.

Guest account security considerations

When enabling the Guest account, only grant limited rights and permissions. For security reasons, the Guest account shouldn't be used over the network and made accessible to other computers.

In addition, the guest user in the Guest account shouldn't be able to view the event logs. After the Guest account is enabled, it's a best practice to monitor the Guest account frequently to ensure that other users can't use services and other resources. This includes resources that were unintentionally left available by a previous user.

HelpAssistant

The HelpAssistant account is a default local account that is enabled when a Remote Assistance session is run. This account is automatically disabled when no Remote Assistance requests are pending.

HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it's initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the user's invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.

HelpAssistant account security considerations

The SIDs that pertain to the default HelpAssistant account include:

• SID: S-1-5-<domain>-13 , display name Terminal Server User . This group includes all users who sign in to a server with Remote Desktop Services enabled.
• SID: S-1-5-<domain>-14 , display name Remote Interactive Logon . This group includes all users who connect to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.

For the Windows Server operating system, Remote Assistance is an optional component that isn't installed by default. You must install Remote Assistance before it can be used.

For details about the HelpAssistant account attributes, see the following table.

HelpAssistant account attributes

DefaultAccount

The DefaultAccount account, also known as the Default System Managed Account (DSMA), is a well-known user account type. DefaultAccount can be used to run processes that are either multi-user aware or user-agnostic.

The DSMA is disabled by default on the desktop editions and on the Server operating systems with the desktop experience.

The DSMA has a well-known RID of 503 . The security identifier (SID) of the DSMA will thus have a well-known SID in the following format: S-1-5-21-\<ComputerIdentifier>-503 .

The DSMA is a member of the well-known group System Managed Accounts Group , which has a well-known SID of S-1-5-32-581 .

The DSMA alias can be granted access to resources during offline staging even before the account itself is created. The account and the group are created during first boot of the machine within the Security Accounts Manager (SAM).

How Windows uses the DefaultAccount

From a permission perspective, the DefaultAccount is a standard user account. The DefaultAccount is needed to run multi-user-manifested-apps (MUMA apps). MUMA apps run all the time and react to users signing in and signing out of the devices. Unlike Windows Desktop where apps run in context of the user and get terminated when the user signs off, MUMA apps run by using the DSMA.

MUMA apps are functional in shared session SKUs such as Xbox. For example, Xbox shell is a MUMA app. Today, Xbox automatically signs in as Guest account and all apps run in this context. All the apps are multi-user-aware and respond to events fired by user manager. The apps run as the Guest account.

Similarly, Phone auto logs in as a DefApps account, which is akin to the standard user account in Windows but with a few extra privileges. Brokers, some services and apps run as this account.

In the converged user model, the multi-user-aware apps and multi-user-aware brokers will need to run in a context different from that of the users. For this purpose, the system creates DSMA.

How the DefaultAccount is created on domain controllers

If the domain was created with domain controllers running Windows Server 2016, the DefaultAccount exists on all domain controllers in the domain. If the domain was created with domain controllers running an earlier version of Windows Server, the DefaultAccount is created after the PDC Emulator role is transferred to a domain controller that runs Windows Server 2016. The DefaultAccount is then replicated to all other domain controllers in the domain.

Recommendations for managing the Default Account (DSMA)

Microsoft doesn't recommend changing the default configuration, where the account is disabled. There's no security risk with having the account in the disabled state. Changing the default configuration could hinder future scenarios that rely on this account.

Default local system accounts

The SYSTEM account is used by the operating system and by services running under Windows. There are many services and processes in the Windows operating system that need the capability to sign in internally, such as during a Windows installation. The SYSTEM account was designed for that purpose, and Windows manages the SYSTEM account's user rights. It's an internal account that doesn't show up in User Manager, and it can't be added to any groups.

On the other hand, the SYSTEM account does appear on an NTFS file system volume in File Manager in the Permissions portion of the Security menu. By default, the SYSTEM account is granted Full Control permissions to all files on an NTFS volume. Here the SYSTEM account has the same functional rights and permissions as the Administrator account.

To grant the account Administrators group file permissions does not implicitly give permission to the SYSTEM account. The SYSTEM account's permissions can be removed from a file, but we do not recommend removing them.

NETWORK SERVICE

The NETWORK SERVICE account is a predefined local account used by the service control manager (SCM). A service that runs in the context of the NETWORK SERVICE account presents the computer's credentials to remote servers. For more information, see NetworkService Account .

LOCAL SERVICE

The LOCAL SERVICE account is a predefined local account used by the service control manager. It has minimum privileges on the local computer and presents anonymous credentials on the network. For more information, see LocalService Account .

How to manage local user accounts

The default local user accounts, and the local user accounts you create, are located in the Users folder. The Users folder is located in Local Users and Groups. For more information about creating and managing local user accounts, see Manage Local Users .

You can use Local Users and Groups to assign rights and permissions on only the local server to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a server, such as backing up files and folders or shutting down a server. An access permission is a rule that is associated with an object, usually a file, folder, or printer. It regulates which users can have access to an object on the server and in what manner.

You can't use Local Users and Groups on a domain controller. However, you can use Local Users and Groups on a domain controller to target remote computers that aren't domain controllers on the network.

You use Active Directory Users and Computers to manage users and groups in Active Directory.

You can also manage local users by using NET.EXE USER and manage local groups by using NET.EXE LOCALGROUP, or by using various PowerShell cmdlets and other scripting technologies.

Restrict and protect local accounts with administrative rights

An administrator can use many approaches to prevent malicious users from using stolen credentials such as a stolen password or password hash, for a local account on one computer from being used to authenticate on another computer with administrative rights. This is also called lateral movement .

The simplest approach is to sign in to your computer with a standard user account, instead of using the Administrator account for tasks. For example, use a standard account to browse the Internet, send email, or use a word processor. When you want to perform administrative tasks such as installing a new program or changing a setting that affects other users, you don't have to switch to an Administrator account. You can use User Account Control (UAC) to prompt you for permission or an administrator password before performing the task, as described in the next section.

The other approaches that can be used to restrict and protect user accounts with administrative rights include:

Enforce local account restrictions for remote access

Deny network logon to all local administrator accounts, create unique passwords for local accounts with administrative rights.

Each of these approaches is described in the following sections.

These approaches do not apply if all administrative local accounts are disabled.

User Account Control (UAC) is a security feature that informs you when a program makes a change that requires administrative permissions. UAC works by adjusting the permission level of your user account. By default, UAC is set to notify you when applications try to make changes to your computer, but you can change when UAC notifies you.

UAC makes it possible for an account with administrative rights to be treated as a standard user nonadministrator account until full rights, also called elevation, is requested and approved. For example, UAC lets an administrator enter credentials during a nonadministrator's user session to perform occasional administrative tasks without having to switch users, sign out, or use the Run as command.

In addition, UAC can require administrators to specifically approve applications that make system-wide changes before those applications are granted permission to run, even in the administrator's user session.

For example, a default feature of UAC is shown when a local account signs in from a remote computer by using Network logon (for example, by using NET.EXE USE). In this instance, it's issued a standard user token with no administrative rights, but without the ability to request or receive elevation. Consequently, local accounts that sign in by using Network logon can't access administrative shares such as C$, or ADMIN$, or perform any remote administration.

For more information about UAC, see User Account Control .

The following table shows the Group Policy and registry settings that are used to enforce local account restrictions for remote access.

You can also enforce the default for LocalAccountTokenFilterPolicy by using the custom ADMX in Security Templates.

To enforce local account restrictions for remote access

• Start the Group Policy Management Console (GPMC)
• In the console tree, expand < Forest >\Domains\< Domain >, and then Group Policy Objects where forest is the name of the forest, and domain is the name of the domain where you want to set the Group Policy Object (GPO)
• In the console tree, right-click Group Policy Objects > New
• In the New GPO dialog box, type < gpo_name >, and > OK where gpo_name is the name of the new GPO. The GPO name indicates that the GPO is used to restrict local administrator rights from being carried over to another computer
• In the details pane, right-click < gpo_name >, and > Edit
• Ensure that UAC is enabled and that UAC restrictions apply to the default Administrator account by following these steps:
• Navigate to the Computer Configuration\Windows Settings\Security Settings\Local Policies\, and > Security Options
• Double-click User Account Control: Run all administrators in Admin Approval Mode > Enabled > OK
• Double-click User Account Control: Admin Approval Mode for the Built-in Administrator account > Enabled > OK
• Ensure that the local account restrictions are applied to network interfaces by following these steps:
• Navigate to Computer Configuration\Preferences and Windows Settings , and > Registry
• Right-click Registry , and > New > Registry Item
• In the New Registry Properties dialog box, on the General tab, change the setting in the Action box to Replace
• Ensure that the Hive box is set to HKEY_LOCAL_MACHINE
• Select ( … ), browse to the following location for Key Path > Select for: SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
• In the Value name area, type LocalAccountTokenFilterPolicy
• In the Value type box, from the drop-down list, select REG_DWORD to change the value
• In the Value data box, ensure that the value is set to 0
• Verify this configuration, and > OK
• Link the GPO to the first Workstations organizational unit (OU) by doing the following:
• Navigate to the *Forest*\<Domains>\*Domain*\*OU* path
• Right-click the Workstations > Link an existing GPO
• Select the GPO that you created, and > OK
• Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy
• Create links to all other OUs that contain workstations
• Create links to all other OUs that contain servers

Denying local accounts the ability to perform network logons can help prevent a local account password hash from being reused in a malicious attack. This procedure helps to prevent lateral movement by ensuring that stolen credentials for local accounts from a compromised operating system can't be used to compromise other computers that use the same credentials.

To perform this procedure, you must first identify the name of the local, default Administrator account, which might not be the default user name "Administrator", and any other accounts that are members of the local Administrators group.

The following table shows the Group Policy settings that are used to deny network logon for all local Administrator accounts.

To deny network logon to all local administrator accounts

• In the console tree, expand < Forest >\Domains\< Domain >, and then Group Policy Objects , where forest is the name of the forest, and domain is the name of the domain where you want to set the Group Policy Object (GPO)
• In the console tree, right-click Group Policy Objects , and > New
• In the New GPO dialog box, type < gpo_name >, and then > OK where gpo_name is the name of the new GPO indicates that it's being used to restrict the local administrative accounts from interactively signing in to the computer
• Configure the user rights to deny network logons for administrative local accounts as follows:
• Navigate to the Computer Configuration\Windows Settings\Security Settings\, and > User Rights Assignment
• Double-click Deny access to this computer from the network
• Select Add User or Group , type Local account and member of Administrators group , and > OK
• Configure the user rights to deny Remote Desktop (Remote Interactive) logons for administrative local accounts as follows:
• Navigate to Computer Configuration\Policies\Windows Settings and Local Policies, and then select User Rights Assignment
• Double-click Deny log on through Remote Desktop Services
• Link the GPO to the first Workstations OU as follows:
• Navigate to the < Forest >\Domains\< Domain >\OU path
• Right-click the Workstations OU, and > Link an existing GPO

You might have to create a separate GPO if the user name of the default Administrator account is different on workstations and servers.

Passwords should be unique per individual account. While it's true for individual user accounts, many enterprises have identical passwords for common local accounts, such as the default Administrator account. This also occurs when the same passwords are used for local accounts during operating system deployments.

Passwords that are left unchanged or changed synchronously to keep them identical add a significant risk for organizations. Randomizing the passwords mitigates "pass-the-hash" attacks by using different passwords for local accounts, which hamper the ability of malicious users to use password hashes of those accounts to compromise other computers.

Passwords can be randomized by:

• Purchasing and implementing an enterprise tool to accomplish this task. These tools are commonly referred to as "privileged password management" tools
• Configuring Local Administrator Password Solution (LAPS) to accomplish this task
• Creating and implementing a custom script or solution to randomize local account passwords

Was this page helpful?

Additional resources