user right assignment registry

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

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 Commented 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 Commented May 8, 2018 at 19:37

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 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 Commented May 18, 2018 at 18:36

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
• The hidden cost of speed
• The creator of Jenkins discusses CI/CD and balancing business with open source
• Featured on Meta
• Announcing a change to the data-dump process
• Bringing clarity to status tag usage on meta sites

Hot Network Questions

• What qualifies as a Cantor diagonal argument?
• Why didn't Air Force Ones have camouflage?
• Applying to faculty jobs in universities without a research group in your area
• How to connect 20 plus external hard drives to a computer?
• What other crewed spacecraft returned uncrewed before Starliner Boe-CFT?
• Romeo & Juliet laws and age of consent laws
• Transform a list of rules into a list of function definitions
• Sub-/superscript size difference between newtxmath and txfonts
• An instructor is being added to co-teach a course for questionable reasons, against the course author's wishes—what can be done?
• What was IBM VS/PC?
• What's the statistical historical precedence for generalisation beyond overfitting?
• Pull up resistor question
• PCA to help select variables?
• Why is this bolt's thread the way it is?
• I'm not quite sure I understand this daily puzzle on Lichess (9/6/24)
• Which volcano is more hazardous? Mount Rainier or Mount Hood?
• Does a party have to wait 1d4 hours to start a Short Rest if no healing is available and an ally is only stabilized?
• What is this movie aircraft?
• How to go from Asia to America by ferry
• Is "She played good" a grammatically correct sentence?
• Nausea during high altitude cycling climbs
• What was the first "Star Trek" style teleporter in SF?
• Is there a non-semistable simple sheaf?
• How high does the ocean tide rise every 90 minutes due to the gravitational pull of the space station?

  Windows OS Hub / Windows 10 / Allow or Prevent Non-Admin Users from Reboot/Shutdown Windows

Allow or Prevent Non-Admin Users from Reboot/Shutdown Windows

In this article, we will look at several ways to manage non-admin user permissions to restart or shutdown Windows workstations or servers. By default, non-privileged users can only reboot and shut down desktop versions of Windows, and cannot restart a Windows Server host (shutdown and restart buttons are not available in the Start Menu). Is it possible to allow a user without local administrator privileges to restart Windows Server?  There is also a reverse task – how to prevent users from restarting a computer with Windows 10 or 11, which is used as an information kiosk, dispatch console, etc.

How to Allow or Prevent Shutdown/Reboot Options in Windows via GPO

Allow remote shutdown/restart without admin permissions, disable (hide) shutdown or restart options from windows, how to find out who restarted/shutdown a windows server.

You can set the permissions to restart or shutdown Windows using the Shut down the system parameter in the GPO section Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment. This GPO option allows you to specify which locally logged-on users can shut down an operating system.

Please note that the default restart/shutdown permissions for desktop versions of Windows 10/11 and Windows Server editions are different.

Open the Local Group Policy Editor ( gpedit.msc ) and navigate to the section specified above. As you can see, the members of local groups Administrators , Users and Backup Operators have the permission to shutdown/reboot a computer running Windows 10 or 11 .

On Windows Server 2022/2019/2016 , only Administrators or Backup Operators can shut down or restart the server. It is reasonable, since in most cases a non-admin user must not have the privileges to shutdown a server (even accidentally). Just imagine an RDS farm host that is often shuts down since users accidentally click on the “Shutdown” button in the Start menu…

On Active Directory domain controllers, the rights to shut down Windows are delegated to:

• Administrators
• Backup Operators
• Server Operators
• Print Operators

If the user does not have permission to restart/shutdown the operating system, then an error will appear when running the following command:

shutdown –r –t 0

If you want to allow a specific user (without administrator rights) to restart your Windows Server, you need to add their account to this policy and update the GPO settings on the computer .

You can manually grant permissions to shut down the computer locally using the legacy ntrights tool from the Windows Server 2003 Resource Kit:

ntrights +r SeShutdownPrivilege -u woshub\j.smith

To prevent a user from shutting down or restarting Windows:

ntrights -r SeShutdownPrivilege -u woshub\j.smith

Or, vice versa, you can prevent users of workstations running the desktop Windows 10/11 edition from restarting the computer that performs some kind of server function. In this case, just remove Users group from the local policy Shut down the system .

In the same way, you can prevent (or allow) shutdown/reboot operations for non-admin users on all computers in a specific Organizational Unit (OU) of an Active Directory domain using a domain GPO.

• Create the grpAllowRestartComputers user group in AD, to whom you want to grant the permissions to restart computers. You can create a new group using the ADUC snap-in ( dsa.msc ) or the New-ADGroup PowerShell cmdlet.  Add users to the group;

• Set the GPO name ( gpoAllowReboot ) and edit it;
• Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> User Rights Assignment;

• Update the GPO settings on the target computers and check the resulting GPO settings with the rsop.msc snap-in. Users in your group can now shut down or reboot this host;

You can allow some non-admin users to restart your Windows Server remotely using the shutdown command without granting them local administrator privileges, permission to log on through Remote Desktop (RDP) , or local logon permissions ( if this sign-in method is not allowed )

To do it, add a user account to the Force shutdown from a remote system Group Policy option in the same GPO section ( User Rights Assignment ).

By default, only administrators can shutdown/restart the server remotely. Add a user account to the policy.

ntrights +r SeRemoteShutdownPrivilege -u woshub\j.smith

After that, the user will get the SeRemoteShutdown privilege and will be able to restart the server remotely using the command:

shutdown -m \\hamb-rds01 -r -f -t 0

Or using the Restart-Computer PowerShell cmdlet:

Restart-Computer –ComputerName hamb-rds01 –Force

If WinRM (Windows Remote Management) is enabled on the remote computer, you can use WSman instead of WMI to connect:

Restart-Computer -ComputerName hamb-rds01 -Protocol WSMan

If the user does not have permission to connect to the WMI namespace, an error will appear:

You can use Group Policy to hide the Shutdown, Restart, Sleep and Hibernate options from the sign-in screen and Start Menu. This GPO option is called Remove and Prevent Access to the Shut Down, Restart, Sleep, and Hibernate commands and is located under User Configuration -> Administrative Templates -> Start Menu and Taskbar

After you enable this policy, a user will be able only to disconnect the current session or use the logoff command. The Shutdown, Sleep and Restart buttons will become unavailable.

You can use some registry tweaks to hide only a specific item from the Power/Shutdown menu in Windows. For example, you want to hide only the “Shut down” option in the Start menu, but keep “Restart”.

• Open the Registry Editor ( regedit.exe );
• Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\Start\HideShutDown ;

REG ADD "HKLM\SOFTWARE\Microsoft\PolicyManager\default\Start\HideShutDown" /v "value" /t REG_DWORD /d 1 /f

Or using PowerShell:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\PolicyManager\default\Start\HideShutDown" -Name "value" -Value 1

Also, you can hide other options in the Start Menu and Windows sign-in screen:

• Hide only thr Restart option in Windows: REG ADD "HKLM\SOFTWARE\Microsoft\PolicyManager\default\Start\HideRestart " /v "value" /t REG_DWORD /d 1 /f
• Hide Hibernate option from Start Menu in Windows: R EG ADD "HKLM\SOFTWARE\Microsoft\PolicyManager\default\Start\HideHibernate" /v "value" /t REG_DWORD /d 1 /f
• Hide Sleep from the Start Menu: REG ADD "HKLM\SOFTWARE\Microsoft\PolicyManager\default\Start\HideSleep" /v "value" /t REG_DWORD /d 1 /f
• To completely disable the Power button and remove the “Shut down or sign out” option from WinX menu: REG ADD "HKLM\SOFTWARE\Microsoft\PolicyManager\default\Start\HidePowerButton" /v "value" /t REG_DWORD /d 1 /f

Please note that in Windows Server 2019/2022, after assigning restart permission to a user, an error may appear:

In this case, you need to enable the UAC parameter “User Account Control: Run all administrators in Admin Approval Mode” in the GPO:

If you have granted permission to reboot a computer for a non-admin user, you may want to know who restarted a Windows Server : a user or one of the administrators.

Use the Event Viewer ( eventvwr.msc ) to search for shutdown logs in Windows. Go to Windows Logs -> System and filter the current log by the Event ID 1074 .

As you can see, there are server restart events in the log in chronological order. The event description includes the restart time, the reason, and the user account that restarted the host.

You can get information about recent Windows shutdown events using the same Event ID 1076 :

Use the following simple PowerShell script to list the last ten computer restart and shutdown events. This list contains the names of the users and processes from which the reboot was initiated.

Get-EventLog -LogName System | where {$_.EventId -eq 1074} |select-object -first 10 | ForEach-Object { $rv = New-Object PSObject | Select-Object Date, User, Action, process, Reason, ReasonCode if ($_.ReplacementStrings[4]) { $rv.Date = $_.TimeGenerated $rv.User = $_.ReplacementStrings[6] $rv.Process = $_.ReplacementStrings[0] $rv.Action = $_.ReplacementStrings[4] $rv.Reason = $_.ReplacementStrings[2] $rv } } | Select-Object Date, Action, Reason, User, Process |ft

Fix: Can’t Extend Volume in Windows

Fix: windows needs your current credentials pop-up message, related reading, get started with docker on windows (wsl2) without..., adding multiple alternate dns names for a windows..., how to hide or show the ‘safely remove..., enable hyper-v on windows 10/11 pro and home..., how to hide or show specific settings pages....

So sad that there’s no option to disable only shutdown. I have a need to allow user to restart their machines but not shutdown.

FYI you can hide shutdown from the start menu using HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\Start\HideShutDown

Thanks, but even so an advanced user would know to turn it off using other ways.

Thank you MT.. this helped..

On Windows 11, this did work, however, a user who is blocked from restarting/shutting down in this way, can still press Control-Alt-Delete and has the restart/shutdown option in the lower right hand corner. Is there a way to remove that, too?

I just actually tried it from a “non-privileged” account. The good news is that although the options appear, they don’t actually work. 🙃

Leave a Comment Cancel Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Current ye@r *

Leave this field empty

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

Setting user rights assignment of local security policy using powershell/cmd

I want to edit security settings of user rights assignment of local security policy using powershell or cmd.

i have tried ntrights command, but seems like not working Any command will be appreciated

• What exactly did you try and where did it fail? Please provide us with your code so that we can help you work out the kinks, not write the code for you. –  Nick Commented Jun 6, 2017 at 16:40
• i have tried "cmd ntrights +r SeSystemtimePrivilege -u Administrators" @Nick –  Shubham Agrawal Commented Jun 6, 2017 at 16:41
• wherea in cmd it shows ntright command does not exist –  Shubham Agrawal Commented Jun 6, 2017 at 16:42
• 1 ...that means you don't have 'ntrights.exe' that exists somewhere in your $PATH statement. Considering it's a tool from the W2K3 resource kit, you probably don't have it downloaded. –  thepip3r Commented Jun 6, 2017 at 16:51

2 Answers 2

Here is something i just wrote. You can make it more dynamic

• thanks for help, but my job solved [ gallery.technet.microsoft.com/scriptcenter/… ] –  Shubham Agrawal Commented Jun 6, 2017 at 17:39

• Some explanation in addition to code would assist users understanding the value of your answer. Code only answers are often consider impolite and unhelpful for learners. Please use the edit button to enhance your answer. –  Brian Tompsett - 汤莱恩 Commented Feb 7, 2019 at 21:54

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 powershell cmd or ask your own question .

• The Overflow Blog
• The hidden cost of speed
• The creator of Jenkins discusses CI/CD and balancing business with open source
• Featured on Meta
• Announcing a change to the data-dump process
• Bringing clarity to status tag usage on meta sites
• What does a new user need in a homepage experience on Stack Overflow?
• Feedback requested: How do you use tag hover descriptions for curating and do...
• Staging Ground Reviewer Motivation

Hot Network Questions

• Visuallizing complex vectors?
• How to truncate text in latex?
• Sum[] function not computing the sum
• Gravitational potential energy of a water column
• Are others allowed to use my copyrighted figures in theses, without asking?
• What is this movie aircraft?
• Approximations for a Fibonacci-Like Sequence
• Is "She played good" a grammatically correct sentence?
• Swapping touch digitizer from one Android phone to another
• What qualifies as a Cantor diagonal argument?
• How to clean a female disconnect connector
• In which town of Europe (Germany ?) were this 2 photos taken during WWII?
• What prevents random software installation popups from mis-interpreting our consents
• Why didn't Air Force Ones have camouflage?
• What was the first "Star Trek" style teleporter in SF?
• Questions about LWE in NIST standards
• Should Euler be credited with Prime Number Theorem?
• Applying to faculty jobs in universities without a research group in your area
• Is it a good idea to perform I2C Communication in the ISR?
• Does a party have to wait 1d4 hours to start a Short Rest if no healing is available and an ally is only stabilized?
• Pull up resistor question
• Which volcano is more hazardous? Mount Rainier or Mount Hood?
• An instructor is being added to co-teach a course for questionable reasons, against the course author's wishes—what can be done?
• Help identifying a board-to-wire power connector

Set Allow Log On Locally User Rights via Powershell, C# and CMD

Description:.

In this article, I am going to explain about how to set or configure Allow Log on Locally User rights/permission/privilege using Local Security Policy , Powershell , C# and Command Line tool.

Configure Allow log on locally user rights via Local Security Policy GUI

• Grant Allow log on locally user rights via Powershell
• Set Allow log on locally user rights via Command Line
• Set Allow log on locally user permission using C#

Follow the below steps to set Allow log on locally user rights via Local Security Policy

1. Open the Run window by pressing ‘ Windows’ + ‘ R’   keys. 2. Type the command secpol.msc in the text box and click OK.

3. Now the Local Security Policy window will be open, in that window navigate to the node User Rights Assignment ( Security Settings -> Local Polices ->User Rights Assignment ). In right side pane, search and select the policy Allow log on locally .

4. Double-click on the policy Allow log on locally , in the opened window click the button Add User or Group, select the user account you want to set Allow log on locally rights and click OK, and click Apply button to finish.

Set or Grant Allow log on locally user rights via Powershell

 We can set the  Allow log on locally user rights using Powershell by importing the third party DLL ( Carbon  ). Before you run the below script you need to the download latest Carbon files from here Download Carbon DLL .

Steps to follow to set Allow log on locally user rights  via Powershell  :

  1. Download latest Carbon files from here Download Carbon DLL .   2. If you have downloaded the files, extract the zip file and you could see the Carbon DLL inside bin folder (In my case: C:UsersAdministratorDownloadsCarbonbinCarbon.dll ).   3. Copy the below Powershell script commands and place it notepad or textfile.   4. Now you can replace your Carbon DLL path in following script for the variable $CarbonDllPath   5. You can also replace the user identity that you are going to set log on locally user rights in the variable $Identity   6. Now run as Powershell window with Admin Privilege ( Run as Administrator )   7. Copy the edited Powershell script and Run it in Powershell to configure Allow log on locally user rights.

Powershell output :

Other web site links for Carbon DLL:   https://bitbucket.org/splatteredbits/carbon/downloads   http://pshdo.com/   http://get-carbon.org/help/Grant-Privilege.html

Set Allow log on locally user right via Command Line tool

You can use the NTRights.exe utility to grant or deny user rights to users and groups from a command line or a batch file. The NTRights.exe utility is included in the Windows NT Server 4.0 Resource Kit Supplement 3. Use the below command to set log on locally user right using cmd.

Refer: http://support.microsoft.com/kb/266280

Set Log on Locally user right

Revoke Log on Locally user right

Set or Grant Allo Log on locally right/permission to user using C#

You can use the below function GrantLogonLocallyRights to set log on locally rights to user using C# code. This function uses the class LsaWrapper.

LsaWrapper class file

Share this:

Related posts.

• Change local system user account password using Powershell
• Remove user from local Administrator group using PowerShell
• Unlock AD User Account using Powershell script
• Check if AD user exists with PowerShell
• Set Office 365 user password via Powershell

Leave a Comment Cancel reply

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

Client, service, and program issues can occur if you change security settings and user rights assignments

Security settings and user rights assignments can be changed in local policies and group policies to help tighten the security on domain controllers and member computers. However, the downside of increased security is the introduction of incompatibilities with clients, services, and programs. This article describes incompatibilities that can occur on client computers that are running Windows XP, or an earlier version of Windows, when you change specific security settings and user rights assignments in a Windows Server 2003 domain or an earlier Windows Server domain. For information about Group Policy for Windows 7, Windows Server 2008 R2, and Windows Server 2008, see the following articles:

For Windows 7, see Group Policy management for IT pros

For Windows 7, and Windows Server 2008 R2, see What's New in Group Policy

Note: The remaining content in this article is specific to Windows XP, Windows Server 2003, and earlier versions of Windows.

To increase the awareness of misconfigured security settings, use the Group Policy Object Editor tool to change security settings. When you use Group Policy Object Editor, user rights assignments are enhanced on the following operating systems:

Windows XP Professional Service Pack 2 (SP2)

Windows Server 2003 Service Pack 1 (SP1)

The enhanced feature is a dialog box that contains a link to this article. The dialog box appears when you change a security setting or a user rights assignment to a setting that offers less compatibility and is more restrictive. If you directly change the same security setting or user rights assignment by using the registry or by using security templates, the effect is the same as changing the setting in Group Policy Object Editor. However, the dialog box that contains the link to this article does not appear. This article contains examples of clients, programs, and operations that are affected by specific security settings or user rights assignments. However, the examples are not authoritative for all Microsoft operating systems, for all third-party operating systems, or for all program versions that are affected. Not all security settings and user rights assignments are included in this article. We recommend that you validate the compatibility of all security-related configuration changes in a test forest before you introduce them in a production environment. The test forest must mirror the production forest in the following ways:

Client and server operating system versions, client and server programs, service pack versions, hotfixes, schema changes, security groups, group memberships, permissions on objects in the file system, shared folders, the registry, Active Directory directory service, local and Group Policy settings, and object count type and location

Administrative tasks that are performed, administrative tools that are used, and operating systems that are used to perform administrative tasks

Operations that are performed, such as the following:

Computer and user logon authentication

Password resets by users, by computers, and by administrators

Setting permissions for the file system, for shared folders, for the registry, and for Active Directory resources by using ACL Editor in all client operating systems in all account or resource domains from all client operating systems from all account or resource domains

Printing from administrative and nonadministrative accounts

Windows Server 2003 SP1

Warnings in gpedit.msc.

To help make customers aware that they are editing a user right or security option that could have adversely affect their network, two warning mechanisms were added to gpedit.msc. When administrators edit a user right that can adversely affect the whole enterprise, they will see a new icon that resembles a yield sign. They will also receive a warning message that has a link to Microsoft Knowledge Base article 823659. The text of this message is as follows:

Modifying this setting may affect compatibility with clients, services, and applications. For more information, see <user right or security option being modified> (Q823659) If you were directed to this Knowledge Base article from a link in Gpedit.msc, make sure that you read and understand the explanation provided and the possible effect of changing this setting. The following lists User Rights that contain the warning text:

Access this computer from network

Log on locally

Bypass traverse checking

Enable computers and users for trusted delegation

The following lists Security Options that have the warning and a pop-up message:

Domain Member: Digitally encrypt or sign secure channel data (always)

Domain Member: Require strong (Windows 2000 or a later version) session key

Domain Controller: LDAP server signing requirements

Microsoft network server: Digitally sign communications (always)

Network Access: Allows Anonymous Sid / Name translation

Network Access: Do not allow anonymous enumeration of SAM accounts and shares

Network security: LAN Manager Authentication level

Audit: Shut down system immediately if unable to log security audits

Network Access: LDAP client signing requirements

More Information

The following sections describe incompatibilities that can occur when you change specific settings in Windows NT 4.0 domains, Windows 2000 domains, and Windows Server 2003 domains.

User rights

The following list describes a user right, identifies configuration settings that may cause issues, describes why you should apply the user right and why you may want to remove the user right, and provides examples of compatibility issues that may occur when the user right is configured.

Background The ability to interact with remote Windows-based computers requires the Access this computer from network user right. Examples of such network operations include the following:

Replication of Active Directory between domain controllers in a common domain or forest

Authentication requests to domain controllers from users and from computers

Access to shared folders, printers, and other system services that are located on remote computers on the network

Users, computers, and service accounts gain or lose the Access this computer from network user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a computer account may be explicitly added to a custom security group or a built-in security group by an administrator, or may be implicitly added by the operating system to a computed security group such as Domain Users, Authenticated Users, or Enterprise Domain Controllers. By default, user accounts and computer accounts are granted the Access this computer from network user right when computed groups such as Everyone or, preferably, Authenticated Users and, for domain controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy Object (GPO).

Risky configurations The following are harmful configuration settings:

Removing the Enterprise Domain Controllers security group from this user right

Removing the Authenticated Users group or an explicit group that allows users, computers, and service accounts the user right to connect to computers over the network

Removing all users and computers from this user right

Reasons to grant this user right

Granting the Access this computer from network user right to the Enterprise Domain Controllers group satisfies authentication requirements that Active Directory replication must have for replication to occur between domain controllers in the same forest.

This user right allows users and computers to access shared files, printers, and system services, including Active Directory.

This user right is required for users to access mail by using early versions of Microsoft Outlook Web Access (OWA).

Reasons to remove this user right

Users who can connect their computers to the network can access resources on remote computers that they have permissions for. For example, this user right is required for a user to connect to shared printers and to folders. If this user right is granted to the Everyone group, and if some shared folders have both share and NTFS file system permissions configured so that the same group has read access, anyone can view files in those shared folders. However, this is an unlikely situation for fresh installations of Windows Server 2003 because the default share and the NTFS permissions in Windows Server 2003 do not include the Everyone group. For systems that are upgraded from Microsoft Windows NT 4.0 or Windows 2000, this vulnerability may have a higher level of risk because the default share and the file system permissions for these operating systems are not as restrictive as the default permissions in Windows Server 2003.

There is no valid reason for removing Enterprise Domain Controllers group from this user right.

The Everyone group is generally removed in favor of the Authenticated Users group. If the Everyone group is removed, the Authenticated Users group must be granted this user right.

Windows NT 4.0 domains that are upgraded to Windows 2000 do not explicitly grant the Access this computer from network user right to the Everyone group, the Authenticated Users group, or the Enterprise Domain Controllers group. Therefore, when you remove the Everyone group from Windows NT 4.0 domain policy, Active Directory replication will fail with an "Access Denied" error message after you upgrade to Windows 2000. Winnt32.exe in Windows Server 2003 avoids this misconfiguration by granting the Enterprise Domain Controllers group this user right when you upgrade Windows NT 4.0 primary domain controllers (PDCs). Grant the Enterprise Domain Controllers group this user right if it is not present in the Group Policy Object Editor.

Examples of compatibility problems

Windows 2000 and Windows Server 2003: Replication of the following partitions will fail with "Access Denied" errors as reported by monitoring tools such as REPLMON and REPADMIN or replication events in the event log.

Active Directory Schema partition

Configuration partition

Domain partition

Global catalog partition

Application partition

All Microsoft network operating systems: User Account authentication from remote network client computers will fail unless the user or a security group that the user is a member of has been granted this user right.

All Microsoft network operating systems: Account authentication from remote network clients will fail unless the account or a security group the account is a member of has been granted this user right. This scenario applies to user accounts, to computer accounts, and to service accounts.

All Microsoft network operating systems: Removing all accounts from this user right will prevent any account from logging on to the domain or from accessing network resources. If computed groups such as Enterprise Domain Controllers, Everyone, or Authenticated Users are removed, you must explicitly grant this user right to accounts or to security groups that the account is a member of to access remote computers over the network. This scenario applies to all user accounts, to all computer accounts, and to all service accounts.

All Microsoft network operating systems: The local administrator account uses a "blank" password. Network connectivity with blank passwords is not permitted for administrator accounts in a domain environment. With this configuration, you can expect to receive an "Access Denied" error message.

Allow log on locally

Background Users who are trying to log on at the console of a Windows-based computer (by using the CTRL+ALT+DELETE keyboard shortcut) and accounts who are trying to start a service must have local logon privileges on the hosting computer. Examples of local logon operations include administrators who are logging on to the consoles of member computers, or domain controllers throughout the enterprise and domain users who are logging on to member computers to access their desktops by using non-privileged accounts. Users who use a Remote Desktop connection or Terminal Services must have the Allow log on locally user right on destination computers that are running Windows 2000 or Windows XP because these logon modes are considered local to the hosting computer. Users who are logging on to a server that has Terminal Server enabled and who do not have this user right can still start a remote interactive session in Windows Server 2003 domains if they have the Allow logon through Terminal Services user right.

Removing administrative security groups, including Account Operators, Backup Operators, Print Operators or Server Operators, and the built-in Administrators group from the default domain controller's policy.

Removing service accounts that are used by components and by programs on member computers and on domain controllers in the domain from the default domain controller's policy.

Removing users or security groups that log on to the console of member computers in the domain.

Removing service accounts that are defined in the local Security Accounts Manager (SAM) database of member computers or of workgroup computers.

Removing non-built-in administrative accounts that are authenticating over Terminal Services that is running on a domain controller.

Adding all user accounts in the domain explicitly or implicitly through the Everyone group to the Deny logon locally logon right. This configuration will prevent users from logging on to any member computer or to any domain controller in the domain.

Users must have the Allow log on locally user right to access the console or the desktop of a workgroup computer, a member computer, or a domain controller.

Users must have this user right to log on over a Terminal Services session that is running on a Window 2000-based member computer or domain controller.

Failure to restrict console access to legitimate user accounts could result in unauthorized users downloading and executing malicious code to change their user rights.

Removal of the Allow log on locally user right prevents unauthorized logons on the consoles of computers, such as domain controllers or application servers.

Removal of this logon right prevents non-domain accounts from logging on at the console of member computers in the domain.

Windows 2000 terminal servers: The Allow log on locally user right is required for users to log on to Windows 2000 terminal servers.

Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003: User accounts must be granted this user right to log on at the console of computers that are running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003.

Windows NT 4.0 and later: On computers that are running Windows NT 4.0 and later, if you add the Allow log on locally user right, but you implicitly or explicitly also grant the Deny logon locally logon right, the accounts will not be able to log on to the console of the domain controllers.

Background The Bypass traverse checking user right allows the user to browse through folders in the NTFS file system or in the registry without checking for the Traverse Folder special access permission. The Bypass traverse checking user right does not allow the user to list the contents of a folder. It allows the user to traverse only its folders.

Removing non-administrative accounts that log on to Windows 2000-based Terminal Services computers or Windows Server 2003-based Terminal Services computers that do not have permissions to access files and folders in the file system.

Removing the Everyone group from the list of security principals who have this user right by default. Windows operating systems, and also many programs, are designed with the expectation that anyone who can legitimately access the computer will have the Bypass traverse checking user right. Therefore, removing the Everyone group from the list of security principals who have this user right by default could lead to operating system instability or to program failure. It is better that you leave this setting at its default.

Reasons to grant this user right The default setting for the Bypass traverse checking user right is to allow anyone to bypass traverse checking. For experienced Windows system administrators, this is the expected behavior, and they configure file system access control lists (SACLs) accordingly. The only scenario where the default configuration may lead to a mishap is if the administrator who configures permissions does not understand the behavior and expects that users who cannot access a parent folder will not be able to access the contents of any child folders.

Reasons to remove this user right To try to prevent access to the files or the folders in the file system, organizations that are very concerned about security may be tempted to remove the Everyone group, or even the Users group, from the list of groups that have the Bypass traverse checking user right.

Windows 2000, Windows Server 2003: If the Bypass traverse checking user right is removed or is misconfigured on computers that are running Windows 2000 or Windows Server 2003, Group Policy settings in the SYVOL folder will not replicate between domain controllers in the domain.

Windows 2000, Windows XP Professional, Windows Server 2003: Computers that are running Windows 2000, Windows XP Professional, or Windows Server 2003 will log events 1000 and 1202 and will not be able to apply computer policy and user policy when the required file system permissions are removed from the SYSVOL tree if the Bypass traverse checking user right is removed or is misconfigured.  

Windows 2000, Windows Server 2003: On computers that are running Windows 2000 or Windows Server 2003, the Quota tab in Windows Explorer will disappear when you view properties on a volume.

Windows 2000: Non-administrators who log on to a Windows 2000 terminal server may receive the following error message:

Userinit.exe application error. The application failed to initialize properly 0xc0000142 click OK to terminate the app.

Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Users whose computers are running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 may not be able to access shared folders or files on shared folders, and they may receive "Access Denied" error messages if they are not granted the Bypass traverse checking user right.  

Windows NT 4.0: On Windows NT 4.0-based computers, removal of the Bypass traverse checking user right will cause a file copy to drop file streams. If you remove this user right, when a file is copied from a Windows client or from a Macintosh client to a Windows NT 4.0 domain controller that is running Services for Macintosh, the destination file stream is lost, and the file appears as a text-only file.

Microsoft Windows 95, Microsoft Windows 98: On a client computer that is running Windows 95 or Windows 98, the net use * /home command will fail with an "Access Denied" error message if the Authenticated Users group is not granted the Bypass traverse checking user right.

Outlook Web Access: Non-administrators will not be able to log on to Microsoft Outlook Web Access, and they will receive an "Access Denied" error message if they are not granted the Bypass traverse checking user right.

Security Settings

The following list identifies a security setting, and the nested list provides a description about the security setting, identifies configuration settings that may cause issues, describes why you should apply the security setting, and then describes reasons why you may want to remove the security setting. The nested list then provides a symbolic name for the security setting and the registry path of the security setting. Finally, examples are provided of compatibility issues that may occur when the security setting is configured.

The Audit: Shut down system immediately if unable to log security audits setting determines whether the system shuts down if you cannot log security events. This setting is required for the Trusted Computer Security Evaluation Criteria (TCSEC) program's C2 evaluation and for the Common Criteria for Information Technology Security Evaluation to prevent auditable events if the audit system can't log those events. If the auditing system fails, the system is shut down, and a Stop error message appears.

If the computer cannot record events to the security log, critical evidence or important troubleshooting information may not be available for review after a security incident.

Risky configuration The following is a harmful configuration setting: The Audit: Shut down system immediately if unable to log security audits setting is turned on, and the size of the security event log is constrained by the Do not overwrite events (clear log manually) option, the Overwrite Events as needed option, or the Overwrite Events older than number days option in Event Viewer. See the "Examples of Compatibility Problems" section for information about specific risks for computers that are running the original released version of Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2, or Windows 2000 SP3.

Reasons to enable this setting If the computer cannot record events to the security log, critical evidence or important troubleshooting information may not be available for review after a security incident.

Reasons to disable this setting

Enabling the Audit: Shut down system immediately if unable to log security audits setting stops the system if a security audit cannot be logged for any reason. Typically, an event cannot be logged when the security audit log is full and when its specified retention method is either the Do not overwrite events (clear log manually) option or the Overwrite Events older than number days option.

The administrative burden of enabling the Audit: Shut down system immediately if unable to log security audits setting can be very high, especially if you also turn on the Do not overwrite events (clear log manually) option for the security log. This setting provides for individual accountability of operator actions. For example, an administrator could reset permissions on all users, computers, and groups in an organizational unit (OU) where auditing was enabled by using the built-in administrator account or other shared account and then deny that they reset such permissions. However, enabling the setting does reduce the robustness of the system because a server may be forced to shut down by overwhelming it with logon events and with other security events that are written to the security log. Additionally, because the shutdown is not graceful, irreparable damage to the operating system, programs, or data may result. While NTFS guarantees that the file system’s integrity is maintained during an ungraceful system shutdown, it cannot guarantee that every data file for every program will still be in a usable form when the system restarts.

Symbolic Name: CrashOnAuditFail

Registry Path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)

Windows 2000: Because of a bug, computers that are running the original released version of Windows 2000, Windows 2000 SP1, Windows 2000 SP2, or Windows Server SP3 may stop logging events before the size that is specified in the Maximum log size option for the security event log is reached. This bug is fixed in Windows 2000 Service Pack 4 (SP4). Make sure that your Windows 2000 domain controllers have Windows 2000 Service Pack 4 installed before you consider enabling this setting.  

Windows 2000, Windows Server 2003: Computers that are running Windows 2000 or Windows Server 2003 may stop responding and then may spontaneously restart if the Audit: Shut down system immediately if unable to log security audits setting is turned on, the security log is full, and an existing event log entry cannot be overwritten. When the computer restarts, the following Stop error message appears:

STOP: C0000244 {Audit Failed} An attempt to generate a security audit failed.

To recover, an administrator must log on, archive the security log (optional), clear the security log, and then reset this option (optional and as-needed).

Microsoft Network Client for MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Non-administrators who try to log on to a domain will receive the following error message:

Your account is configured to prevent you from using this computer. Please try another computer.

Windows 2000: On Windows 2000-based computers, non-administrators will not be able to log on to remote access servers, and they will receive an error message that is similar to the following:

Unknown user or bad password

Windows 2000: On Windows 2000 domain controllers, the Intersite Messaging service (Ismserv.exe) will stop and cannot be restarted. DCDIAG will report the error as "failed test services ISMserv," and event ID 1083 will be registered in the event log.

Windows 2000: On Windows 2000 domain controllers, Active Directory replication will fail, and an "Access Denied" message will appear if the security event log is full.

Microsoft Exchange 2000: Servers that are running Exchange 2000 will not be able to mount the information store database, and event 2102 will be registered in the event log.

Outlook, Outlook Web Access: Non-administrators will not be able to access their mail through Microsoft Outlook or through Microsoft Outlook Web Access, and they will receive a 503 error.

Domain controller: LDAP server signing requirements

Background The Domain controller: LDAP server signing requirements security setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing. The possible values for this policy setting are as follows:

None: Data signing is not required to bind with the server. If the client requests data signing, the server supports it.

Require signing: The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure Socket Layer (TLS/SSL) is being used.

not defined: This setting is not enabled or disabled.

Enabling Require signing in environments where clients do not support LDAP signing or where client-side LDAP signing is not enabled on the client

Applying the Windows 2000 or the Windows Server 2003 Hisecdc.inf security template in environments where the clients do not support LDAP signing or where client-side LDAP signing is not enabled

Applying the Windows 2000 or the Windows Server 2003 Hisecws.inf security template in environments where the clients do not support LDAP signing or where client-side LDAP signing is not enabled

Reasons to enable this setting Unsigned network traffic is susceptible to man-in-the-middle attacks where an intruder captures packets between the client and the server, modifies the packets, and then forwards them to the server. When this behavior occurs on an LDAP server, an attacker could cause a server to make decisions that are based on false queries from the LDAP client. You can lower this risk in a corporate network by implementing strong physical security measures to help protect the network infrastructure. Internet Protocol security (IPSec) authentication header mode can help prevent man-in-the-middle attacks. Authentication header mode performs mutual authentication and packet integrity for IP traffic.

Clients that do not support LDAP signing will not be able to carry out LDAP queries against domain controllers and against global catalogs if NTLM authentication is negotiated and if the correct service packs are not installed on Windows 2000 domain controllers.

Network traces of LDAP traffic between clients and servers will be encrypted. This makes it difficult to examine LDAP conversations.

Windows 2000-based servers must have Windows 2000 Service Pack 3 (SP3) or installed when they are administered with programs that support LDAP signing that are run from client computers that run Windows 2000 SP4, Windows XP, or Windows Server 2003.  

Symbolic Name: LDAPServerIntegrity

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)

Simple binds will fail, and you will receive the following error message:

Ldap_simple_bind_s() failed: Strong Authentication Required.

Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: On clients that are running Windows 2000 SP4, Windows XP, or Windows Server 2003, some Active Directory administration tools will not operate correctly against domain controllers that are running versions of Windows 2000 that are earlier than SP3 when NTLM authentication is negotiated.  

Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: On clients that are running Windows 2000 SP4, Windows XP, or Windows Server 2003, some Active Directory administration tools that target domain controllers that are running versions of Windows 2000 that are earlier than SP3 will not operate correctly if they are using IP addresses (for example, "dsa.msc /server= x.x.x.x " where x.x.x.x is an IP address).  

Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: On clients that are running Windows 2000 SP4, Windows XP, or Windows Server 2003, some Active Directory administration tools that target domain controllers that are running versions of Windows 2000 that are earlier than SP3 will not operate correctly.  

Domain member: Require strong (Windows 2000 or later) session key

The Domain member: Require strong (Windows 2000 or later) session key setting determines whether a secure channel can be established with a domain controller that cannot encrypt secure channel traffic with a strong, 128-bit session key. Enabling this setting prevents establishing a secure channel with any domain controller that cannot encrypt secure channel data with a strong key. Disabling this setting allows 64-bit session keys.

Before you can enable this setting on a member workstation or on a server, all domain controllers in the domain that the member belongs to must be able to encrypt secure channel data with a strong, 128-bit key. This means that all such domain controllers must be running Windows 2000 or later.

Risky configuration Enabling the Domain member: Require strong (Windows 2000 or later) session key setting is a harmful configuration setting.

Reasons to enable this setting

Session keys that are used to establish secure channel communications between member computers and domain controllers are much stronger in Windows 2000 than they are in earlier versions of Microsoft operating systems.

When it's possible, it is a good idea to take advantage of these stronger session keys to help protect secure channel communications from eavesdropping and from session hijacking network attacks. Eavesdropping is a form of malicious attack where network data is read or is altered in transit. The data can be modified to hide or to change the sender, or to redirect it.

Important A computer that is running Windows Server 2008 R2 or Windows 7 supports only strong keys when secure channels are used. This restriction prevents a trust between any Windows NT 4.0-based domain and any Windows Server 2008 R2-based domain. Additionally, this restriction blocks the Windows NT 4.0-based domain membership of computers that are running Windows 7 or Windows Server 2008 R2, and vice versa.

Reasons to disable this setting The domain contains member computers that are running operating systems other than Windows 2000, Windows XP, or Windows Server 2003.

Symbolic Name: StrongKey

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)

Examples of compatibility problems Windows NT 4.0: On Windows NT 4.0-based computers, resetting secure channels of trust relationships between Windows NT 4.0 and Windows 2000 domains with NLTEST fails. An "Access Denied" error message appears:

The trust relationship between the primary domain and the trusted domain failed. Windows 7 and Server 2008 R2: For Windows 7 and later versions and Windows Server 2008 R2 and later versions, this setting is not honored any longer and the strong key is used always. Because of that, trusts with Windows NT 4.0 domains do not work any longer.

Domain member: Digitally encrypt or sign secure channel data (always)

Enabling Domain member: Digitally encrypt or sign secure channel data (always) prevents establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data. To help protect authentication traffic from man-in-the-middle attacks, replay attacks, and other kinds of network attacks, Windows-based computers create a communication channel that is known as a secure channel through the Net Logon service to authenticate computer accounts. Secure channels are also used when a user in one domain connects to a network resource in a remote domain. This multidomain authentication, or pass-through authentication, allows a Windows-based computer that has joined a domain to have access to the user account database in its domain and in any trusted domains.

To enable the Domain member: Digitally encrypt or sign secure channel data (always) setting on a member computer, all domain controllers in the domain that the member belongs to must be able to sign or encrypt all secure channel data. This means that all such domain controllers must be running Windows NT 4.0 with Service Pack 6a (SP6a) or later.

Enabling the Domain member: Digitally encrypt or sign secure channel data (always) setting automatically enables the Domain member: Digitally encrypt or sign secure channel data (when possible) setting.

Risky configuration Enabling the Domain member: Digitally encrypt or sign secure channel data (always) setting in domains where not all domain controllers can sign or encrypt secure channel data is a harmful configuration setting.

Reasons to enable this setting Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client and then modifies them before forwarding them to the client. When this behavior occurs on an Lightweight Directory Access Protocol (LDAP) server, the intruder could cause a client to make decisions that are based on false records from the LDAP directory. You can lower the risk of such an attack on a corporate network by implementing strong physical security measures to help protect the network infrastructure. Additionally, implementing Internet Protocol security (IPSec) authentication header mode can help prevent man-in-the-middle attacks. This mode performs mutual authentication and packet integrity for IP traffic.

Computers in local or external domains do support encrypted secure channels.

Not all domain controllers in the domain have the appropriate service pack revision levels to support encrypted secure channels.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)

Windows NT 4.0: Windows 2000-based member computers will not be able to join Windows NT 4.0 domains and will receive the following error message:

The account is not authorized to log in from this station.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

281648 Error message: The account is not authorized to login from this station  

Windows NT 4.0: Windows NT 4.0 domains will not be able to establish a down-level trust with a Windows 2000 domain and will receive the following error message:

Existing down-level trusts may also not authenticate users from the trusted domain. Some users may have problems logging on to the domain, and they may receive an error message that states that the client cannot find the domain.

Windows XP: Windows XP clients that are joined to Windows NT 4.0 domains will not be able to authenticate logon attempts and may receive the following error message, or the following events may be registered in the event log:

Windows cannot connect to the domain either because the domain controller is down or is otherwise unavailable or because your computer account was not found

Microsoft Network: Microsoft Network clients will receive one of the following error messages:

Logon failure: unknown username or bad password.

There is no user session key for the specified logon session.

Microsoft network client: Digitally sign communications (always)

Background Server Message Block (SMB) is the resource-sharing protocol that is supported by many Microsoft operating systems. It is the basis of network basic input/output system (NetBIOS) and of many other protocols. SMB signing authenticates both the user and the server that hosts the data. If either side fails the authentication process, data transmission will not occur. Enabling SMB signing starts during SMB protocol negotiation. The SMB signing policies determine whether the computer always digitally signs client communications. The Windows 2000 SMB authentication protocol supports mutual authentication. Mutual authentication closes a "man-in-the-middle" attack. The Windows 2000 SMB authentication protocol also supports message authentication. Message authentication helps prevent active message attacks. To give you this authentication, SMB signing puts a digital signature into each SMB. The client and the server each verify the digital signature. To use SMB signing, you must enable SMB signing or require SMB signing on both the SMB client and the SMB server. If SMB signing is enabled on a server, clients that are also enabled for SMB signing use the packet signing protocol during all subsequent sessions. If SMB signing is required on a server, a client cannot establish a session unless the client is enabled or required for SMB signing. Enabling digital signing in high-security networks helps prevent the impersonation of clients and of servers. This kind of impersonation is known as session hijacking. An attacker who has access to the same network as the client or the server uses session hijacking tools to interrupt, end, or steal a session in progress. An attacker could intercept and modify unsigned SMB packets, modify the traffic, and then forward it so that the server might perform unwanted actions. Or, the attacker could pose as the server or as the client after a legitimate authentication and then gain unauthorized access to data. The SMB protocol that is used for file sharing and for print sharing in computers that are running Windows 2000 Server, Windows 2000 Professional, Windows XP Professional, or Windows Server 2003 supports mutual authentication. Mutual authentication closes session hijacking attacks and supports message authentication. Therefore, it prevents man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature in each SMB. The client and the server then verify the signature. Notes

As an alternative countermeasure, you can enable digital signatures with IPSec to help protect all network traffic. There are hardware-based accelerators for IPSec encryption and signing that you can use to minimize the performance impact from the server's CPU. There are no such accelerators that are available for SMB signing. For more information, see the Digitally sign server communications chapter on the Microsoft MSDN website. Configure SMB signing through Group Policy Object Editor because a change to a local registry value has no effect if there is an overriding domain policy.

In Windows 95, Windows 98, and Windows 98 Second Edition, the Directory Services Client uses SMB signing when it authenticates with Windows Server 2003 servers by using NTLM authentication. However, these clients do not use SMB signing when they authenticate with these servers by using NTLMv2 authentication. Additionally, Windows 2000 servers do not respond to SMB signing requests from these clients. For more information, see item 10: "Network security: Lan Manager authentication level."

Risky configuration The following is a harmful configuration setting: Leaving both the Microsoft network client: Digitally sign communications (always) setting and the Microsoft network client: Digitally sign communications (if server agrees) setting set to "Not Defined" or disabled. These settings allow the redirector to send plain text passwords to non-Microsoft SMB servers that do not support password encryption during authentication.

Reasons to enable this setting Enabling Microsoft network client: Digitally sign communications (always) requires clients to sign SMB traffic when contacting servers that do not require SMB signing. This makes clients less vulnerable to session hijacking attacks.

Enabling Microsoft network client: Digitally sign communications (always) prevents clients from communicating with target servers that do not support SMB signing.

Configuring computers to ignore all unsigned SMB communications prevents earlier programs and operating systems from connecting.

Symbolic Name: RequireSMBSignRdr

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature

Windows NT 4.0: You will not be able to reset the secure channel of a trust between a Windows Server 2003 domain and a Windows NT 4.0 domain by using NLTEST or NETDOM, and you will receive an "Access Denied" error message.

Windows XP: Copying files from Windows XP clients to Windows 2000-based servers and to Windows Server 2003-based servers may take more time.

You will not be able to map a network drive from a client with this setting enabled, and you will receive the following error message:

Restart requirements Restart the computer, or restart the Workstation service. To do this, type the following commands at a command prompt. Press Enter after you type each command.

net stop workstation net start workstation

Server Messenger Block (SMB) is the resource-sharing protocol that is supported by many Microsoft operating systems. It is the basis of network basic input/output system (NetBIOS) and of many other protocols. SMB signing authenticates both the user and the server that hosts the data. If either side fails the authentication process, data transmission will not occur. Enabling SMB signing starts during SMB protocol negotiation. The SMB signing policies determine whether the computer always digitally signs client communications. The Windows 2000 SMB authentication protocol supports mutual authentication. Mutual authentication closes a "man-in-the-middle" attack. The Windows 2000 SMB authentication protocol also supports message authentication. Message authentication helps prevent active message attacks. To give you this authentication, SMB signing puts a digital signature into each SMB. The client and the server each verify the digital signature. To use SMB signing, you must enable SMB signing or require SMB signing on both the SMB client and the SMB server. If SMB signing is enabled on a server, clients that are also enabled for SMB signing use the packet signing protocol during all subsequent sessions. If SMB signing is required on a server, a client cannot establish a session unless the client is enabled or required for SMB signing. Enabling digital signing in high-security networks helps prevent the impersonation of clients and of servers. This kind of impersonation is known as session hijacking. An attacker who has access to the same network as the client or the server uses session hijacking tools to interrupt, end, or steal a session in progress. An attacker could intercept and modify unsigned Subnet Bandwidth Manager (SBM) packets, modify the traffic, and then forward it so that the server might perform unwanted actions. Or, the attacker could pose as the server or as the client after a legitimate authentication and then gain unauthorized access to data. The SMB protocol that is used for file sharing and for print sharing in computers that are running Windows 2000 Server, Windows 2000 Professional, Windows XP Professional, or Windows Server 2003 supports mutual authentication. Mutual authentication closes session hijacking attacks and supports message authentication. Therefore, it prevents man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature in each SMB. The client and the server then verify the signature.

As an alternative countermeasure, you can enable digital signatures with IPSec to help protect all network traffic. There are hardware-based accelerators for IPSec encryption and signing that you can use to minimize the performance impact from the server's CPU. There are no such accelerators that are available for SMB signing.

Risky configuration The following is a harmful configuration setting: Enabling the Microsoft network server: Digitally sign communications (always) setting on servers and on domain controllers that are accessed by incompatible Windows-based computers and third-party operating system-based client computers in local or external domains.

All client computers that enable this setting directly through the registry or through the Group Policy setting support SMB signing. In other words, all client computers that have this setting enabled run either Windows 95 with the DS client installed, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional, or Windows Server 2003.

If Microsoft network server: Digitally sign communications (always) is disabled, SMB signing is completely disabled. Completely disabling all SMB signing leaves computers more vulnerable to session hijacking attacks.

Enabling this setting may cause slower file copy and network performance on client computers.

Enabling this setting will prevent clients that cannot negotiate SMB signing from communicating with servers and with domain controllers. This causes operations such as domain joins, user and computer authentication, or network access by programs to fail.

Symbolic Name: RequireSMBSignServer

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)

Windows 95: Windows 95 clients that do not have the Directory Services (DS) Client installed will fail logon authentication and will receive the following error message:

The domain password you supplied is not correct, or access to your logon server has been denied.

Windows NT 4.0: Client computers that are running versions of Windows NT 4.0 that are earlier than Service Pack 3 (SP3) will fail logon authentication and will receive the following error message:

The system could not log you on. Make sure your username and your domain are correct, then type your password again.

Some non-Microsoft SMB servers support only unencrypted password exchanges during authentication. (These exchanges also known as "plain text" exchanges.) For Windows NT 4.0 SP3 and later versions, the SMB redirector does not send an unencrypted password during authentication to an SMB server unless you add a specific registry entry. To enable unencrypted passwords for the SMB client on Windows NT 4.0 SP 3 and newer systems, modify the registry as follows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters Value Name: EnablePlainTextPassword Data Type: REG_DWORD Data: 1  

Windows Server 2003: By default, security settings on domain controllers that run Windows Server 2003 are configured to help prevent domain controller communications from being intercepted or tampered with by malicious users. For users to successfully communicate with a domain controller that runs Windows Server 2003, client computers must use both SMB signing and encryption or secure channel traffic signing. By default, clients that run Windows NT 4.0 with Service Pack 2 (SP2) or earlier installed and clients that run Windows 95 do not have SMB packet signing enabled. Therefore, these clients may not be able to authenticate to a Windows Server 2003-based domain controller.

Windows 2000 and Windows Server 2003 policy settings: Depending on your specific installation needs and configuration, we recommend that you set the following policy settings at the lowest entity of necessary scope in the Microsoft Management Console Group Policy Editor snap-in hierarchy:

Computer Configuration\Windows Security Settings\Security Options

Send unencrypted password to connect to third-party SMB servers (this setting is for Windows 2000)

Microsoft network client: Send unencrypted password to third-party SMB servers (this setting is for Windows Server 2003)

Note In some third-party CIFS servers, such as older Samba versions, you cannot use encrypted passwords.

The following clients are incompatible with the Microsoft network server: Digitally sign communications (always) setting:

Apple Computer, Inc., Mac OS X clients

Microsoft MS-DOS network clients (for example, Microsoft LAN Manager)

Microsoft Windows for Workgroups clients

Microsoft Windows 95 clients without the DS Client installed

Microsoft Windows NT 4.0-based computers without SP3 or later installed

Novell Netware 6 CIFS clients

SAMBA SMB clients that do not have support for SMB signing

Restart requirements Restart the computer, or restart the Server service. To do this, type the following commands at a command prompt. Press Enter after you type each command.

net stop server net start server

Network access: Allow anonymous SID/Name translation

Background The Network access: Allow anonymous SID/Name translation security setting determines whether an anonymous user can request Security Identification Number (SID) attributes for another user.

Risky configuration Enabling the Network access: Allow anonymous SID/Name translation setting is a harmful configuration setting.

Reasons to enable this setting If the Network access: Allow anonymous SID/Name translation setting is disabled, earlier operating systems or applications may not be able to communicate with Windows Server 2003 domains. For example, the following operating systems, services, or applications may not work:

Windows NT 4.0-based Remote Access Service servers

Microsoft SQL Server that are running on Windows NT 3.x-based computers or Windows NT 4.0-based computers

Remote Access Service that is running on Windows 2000-based computers that are located in Windows NT 3.x domains or Windows NT 4.0 domains

SQL Server that is running on Windows 2000-based computers that are located in Windows NT 3.x domains or in Windows NT 4.0 domains

Users in Windows NT 4.0 resource domain who want to grant permissions to access files, shared folders, and registry objects to user accounts from account domains that contain Windows Server 2003 domain controllers

Reasons to disable this setting If this setting is enabled, a malicious user could use the well-known Administrators SID to obtain the real name of the built-in Administrator account, even if the account has been renamed. That person could then use the account name to initiate a password-guessing attack.

Symbolic Name: N/A

Registry Path: None. The path is specified in UI code.

Examples of compatibility problems Windows NT 4.0: Computers in Windows NT 4.0 resource domains will display the "Account Unknown" error message in ACL Editor if resources, including shared folders, shared files, and registry objects, are secured with security principals that reside in account domains that contain Windows Server 2003 domain controllers.

Network access: Do not allow anonymous enumeration of SAM accounts

The Network access: Do not allow anonymous enumeration of SAM accounts setting determines which additional permissions will be granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of workstation and server Security Accounts Manager (SAM) accounts and of network shares. For example, an administrator can use this to grant access to users in a trusted domain that does not maintain a reciprocal trust. Once a session is made, an anonymous user may have the same access that is granted to the Everyone group based on the setting in the Network access: Let Everyone permissions apply to anonymous users setting or the discretionary access control list (DACL) of the object. Typically, anonymous connections are requested by earlier versions of clients (down-level clients) during SMB session setup. In these cases, a network trace shows that the SMB Process ID (PID) is the client redirector such as 0xFEFF in Windows 2000 or 0xCAFE in Windows NT. RPC may also try to make anonymous connections.

Important This setting has no impact on domain controllers. On domain controllers, this behavior is controlled by the presence of "NT AUTHORITY\ANONYMOUS LOGON" in "Pre-Windows 2000 compatible Access".

In Windows 2000, a similar setting called Additional Restrictions for Anonymous Connections manages the RestrictAnonymous registry value. The location of this value is as follows

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

Risky configurations Enabling the Network access: Do not allow anonymous enumeration of SAM accounts setting is a harmful configuration setting from a compatibility perspective. Disabling it is a harmful configuration setting from a security perspective.

Reasons to enable this setting An unauthorized user could anonymously list account names and then use the information to try to guess passwords or to perform social engineering attacks. Social engineering is jargon that means tricking people into revealing their passwords or some form of security information.

Reasons to disable this setting If this setting is enabled, it is impossible to establish trusts with Windows NT 4.0 domains. This setting also causes problems with down-level clients (such as Windows NT 3.51 clients and Windows 95 clients) that are trying to use resources on the server.

Symbolic Name: RestrictAnonymousSAM

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)

SMS Network Discovery will not be able to obtain operating system information and will write "Unknown" in the OperatingSystemNameandVersion property.

Windows 95, Windows 98: Windows 95 clients and Windows 98 clients will not be able to change their passwords.

Windows NT 4.0: Windows NT 4.0-based member computers will not be able to be authenticated.

Windows 95, Windows 98: Windows 95-based and Windows 98-based computers will not be able to be authenticated by Microsoft domain controllers.

Windows 95, Windows 98: Users on Windows 95-based and Windows 98-based computers will not be able to change the passwords for their user accounts.

Network access: Do not allow anonymous enumeration of SAM accounts and shares

The Network access: Do not allow anonymous enumeration of SAM accounts and shares setting (also known as RestrictAnonymous) determines whether anonymous enumeration of Security Accounts Manager (SAM) accounts and shares is allowed. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts (users, computers, and groups) and of network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. If you do not want to allow anonymous enumeration of SAM accounts and of shares, enable this setting.

In Windows 2000, a similar setting called Additional Restrictions for Anonymous Connections manages the RestrictAnonymous registry value. The location of this value is as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

Risky configuration Enabling the Network access: Do not allow anonymous enumeration of SAM accounts and shares setting is a harmful configuration setting.

Enabling the Network access: Do not allow anonymous enumeration of SAM accounts and shares setting prevents enumeration of SAM accounts and shares by users and computers that are using anonymous accounts.

If this setting is enabled, an unauthorized user could anonymously list account names and then use the information to try to guess passwords or to perform social engineering attacks. Social engineering is jargon that means tricking people into revealing their password or some form of security information.

If this setting is enabled, it will be impossible to establish trusts with Windows NT 4.0 domains. This setting will also cause problems with down-level clients such as Windows NT 3.51 and Windows 95 clients that are trying to use resources on the server.

It will be impossible to grant access to users of resource domains because administrators in the trusting domain will not be able to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously will not be able to list the shared network resources on those servers. The users must authenticate before they can view the lists of shared folders and printers.

Symbolic Name: RestrictAnonymous

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

Windows NT 4.0: Users will not be able to change their passwords from Windows NT 4.0 workstations when RestrictAnonymous is enabled on domain controllers in the users' domain.

Windows NT 4.0: Adding users or global groups from trusted Windows 2000 domains to Windows NT 4.0 local groups in User Manager will fail, and the following error message will appear:

There are currently no logon servers available to service the logon request.

Windows NT 4.0: Windows NT 4.0-based computers will not be able to join domains during setup or by using the domain join user interface.

Windows NT 4.0: Establishing a down-level trust with Windows NT 4.0 resource domains will fail. The following error message will appear when RestrictAnonymous is enabled on the trusted domain:

Could not find domain controller for this domain.

Windows NT 4.0: Users who log on to Windows NT 4.0-based Terminal Server computers will map to the default home directory instead of the home directory that is defined in User Manager for domains.

Windows NT 4.0: Windows NT 4.0 backup domain controllers (BDCs) will not be able to start the Net Logon service, obtain a list of backup browsers, or synchronize the SAM database from Windows 2000 or from Windows Server 2003 domain controllers in the same domain.

Windows 2000: Windows 2000-based member computers in Windows NT 4.0 domains will not be able to view printers in external domains if the No access without explicitly anonymous permissions setting is enabled in the local security policy of the client computer.

Windows 2000: Windows 2000 domain users will not be able to add network printers from Active Directory; however, they will be able to add printers after they select them from the tree view.

Windows 2000: On Windows 2000-based computers, ACL Editor will not be able to add users or global groups from trusted Windows NT 4.0 domains.

ADMT version 2: Password migration for user accounts that are migrated between forests with Active Directory Migration Tool (ADMT) version 2 will fail. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

322981 How to troubleshoot inter-forest password migration with ADMTv2

Outlook clients: The global address list will appear empty to Microsoft Exchange Outlook clients.

SMS: Microsoft Systems Management Server (SMS) Network Discovery will not be able to obtain the operating system information. Therefore, it will write "Unknown" in the OperatingSystemNameandVersion property of the SMS DDR property of the discovery data record (DDR).

SMS: When you use the SMS Administrator User Wizard to browse for users and groups, no users or groups will be listed. Additionally, Advanced clients cannot communicate with the Management Point. Anonymous access is required on the Management Point.

SMS: When you are using the Network Discovery feature in SMS 2.0 and in Remote Client Installation with the Topology, client, and client operating systems network discovery option turned on, computers may be discovered but may not be installed.

Network security: Lan Manager authentication level

Background LAN Manager (LM) authentication is the protocol that is used to authenticate Windows clients for network operations, including domain joins, accessing network resources, and user or computer authentication. The LM authentication level determines which challenge/response authentication protocol is negotiated between the client and the server computers. Specifically, the LM authentication level determines which authentication protocols that the client will try to negotiate or that the server will accept. The value that is set for LmCompatibilityLevel determines which challenge/response authentication protocol is used for network logons. This value affects the level of authentication protocol that clients use, the level of session security negotiated, and the level of authentication accepted by servers. Possible settings include the following.

Note In Windows 95, Windows 98, and Windows 98 Second Edition, the Directory Services Client uses SMB signing when it authenticates with Windows Server 2003 servers by using NTLM authentication. However, these clients do not use SMB signing when they authenticate with these servers by using NTLMv2 authentication. Additionally, Windows 2000 servers do not respond to SMB signing requests from these clients. Check the LM authentication level: You must change the policy on the server to permit NTLM, or you must configure the client computer to support NTLMv2. If the policy is set to (5) Send NTLMv2 response only\refuse LM & NTLM on the target computer that you want to connect to, you must either lower the setting on that computer or set the security to the same setting that is on the source computer that you are connecting from. Find the correct location where you can change the LAN manager authentication level to set the client and the server to the same level. After you find the policy that is setting the LAN manager authentication level, if you want to connect to and from computers that are running earlier versions of Windows, lower the value to at least (1) Send LM & NTLM - use NTLM version 2 session security if negotiated. One effect of incompatible settings is that if the server requires NTLMv2 (value 5), but the client is configured to use LM and NTLMv1 only (value 0), the user who tries authentication experiences a logon failure that has a bad password and that increments the bad password count. If account lock-out is configured, the user may eventually be locked out. For example, you may have to look on the domain controller, or you may have to examine the domain controller's policies. Look on the domain controller Note You may have to repeat the following procedure on all the domain controllers.

Click Start , point to Programs , and then click Administrative Tools .

Under Local Security Settings , expand Local Policies .

Click Security Options .

Double-click Network Security: LAN manager authentication level , and then click a value in the list.

If the Effective Setting and the Local Setting are the same, the policy has been changed at this level. If the settings are different, you must check the domain controller's policy to determine whether the Network Security: LAN manager authentication level setting is defined there. If it is not defined there, examine the domain controller's policies. Examine the domain controller's policies

In the Domain Controller Security policy, expand Security Settings , and then expand Local Policies .

Double-click Network Security: LAN manager authentication level, and then click a value in the list.

You may also have to check policies that are linked at the site level, the domain level, or the organizational unit (OU) level to determine where you must configure the LAN manager authentication level.

If you implement a Group Policy setting as the default domain policy, the policy is applied to all computers in the domain.

If you implement a Group Policy setting as the default domain controller's policy, the policy applies only to the servers in the domain controller's OU.

It is a good idea to set the LAN manager authentication level in the lowest entity of necessary scope in the policy application hierarchy.

Windows Server 2003 has a new default setting to use NTLMv2 only. By default, Windows Server 2003 and Windows 2000 Server SP3-based domain controllers have enabled the "Microsoft network server: Digitally sign communications (always)" policy. This setting requires the SMB server to perform SMB packet signing. Changes to Windows Server 2003 were made because domain controllers, file servers, network infrastructure servers, and Web servers in any organization require different settings to maximize their security. If you want to implement NTLMv2 authentication in your network, you must make sure that all the computers in the domain are set to use this authentication level. If you apply Active Directory Client Extensions for Windows 95 or Windows 98 and Windows NT 4.0, the client extensions use the improved authentication features that are available in NTLMv2. Because client computers that are running any of the following operating system are not affected by Windows 2000 Group Policy Objects, you may have to manually configure these clients:

Microsoft Windows NT 4.0

Microsoft Windows Millennium Edition

Microsoft Windows 98

Microsoft Windows 95

Note If you enable the Network security: Do not store LAN manager hash value on next password change policy or set the NoLMHash registry key, Windows 95-based and Windows 98-based clients that do not have the Directory Services Client installed cannot log on to the domain after a password change. Many third-party CIFS servers, such as Novell Netware 6, are not aware of NTLMv2 and use NTLM only. Therefore, levels greater than 2 do not permit connectivity. There also are third-party SMB clients that do not use extended session security. In these cases, the LmCompatiblityLevel of the resource server is not taken into consideration. The server then packs up this legacy request and sends it to the User Domain Controller. The settings on the Domain Controller then decide what hashes are used to verify the request and whether these are meeting the Domain Controller's security requirements.  

299656 How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases  

2701704 Audit event shows authentication package as NTLMv1 instead of NTLMv2 For more information about LM authentication levels, click the following article number to view the article in the Microsoft Knowledge Base:

239869 How to enable NTLM 2 authentication  

Nonrestrictive settings that send passwords in cleartext and that deny NTLMv2 negotiation

Restrictive settings that prevent incompatible clients or domain controllers from negotiating a common authentication protocol

Requiring NTLMv2 authentication on member computers and domain controllers that are running versions of Windows NT 4.0 that are earlier than Service Pack 4 (SP4)

Requiring NTLMv2 authentication on Windows 95 clients or on Windows 98 clients that do not have the Windows Directory Services Client installed.

If you click to select the Require NTLMv2 session security check box in the Microsoft Management Console Group Policy Editor snap-in on a Windows Server 2003 or Windows 2000 Service Pack 3-based computer, and you lower the LAN manager authentication level to 0, the two settings conflict, and you may receive the following error message in the Secpol.msc file or the GPEdit.msc file:

Windows cannot open the local policy database. An unknown error occurred when attempting to open the database.

For more information about the Security Configuration and Analysis Tool, see the Windows 2000 or the Windows Server 2003 Help files.

Reasons to Modify This Setting

You want to increase the lowest common authentication protocol that is supported by clients and domain controllers in your organization.

Where secure authentication is a business requirement, you want to disallow negotiation of the LM and the NTLM protocols.

Reasons to disable this setting Client or server authentication requirements, or both, have been increased to the point where authentication over a common protocol cannot occur.

Symbolic Name: LmCompatibilityLevel

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Windows Server 2003: By default, the Windows Server 2003 NTLMv2 Send NTLM responses setting is enabled. Therefore, Windows Server 2003 receives the "Access Denied" error message after the initial installation when you try to connect to a Windows NT 4.0-based cluster or to LanManager V2.1-based servers, such as OS/2 Lanserver. This issue also occurs if you try to connect from an earlier-version client to a Windows Server 2003-based server.

You install Windows 2000 Security Rollup Package 1 (SRP1).SRP1 forces NTLM version 2 (NTLMv2). This rollup package was released after the release of Windows 2000 Service Pack 2 (SP2).  

Windows 7 and Windows Server 2008 R2: Many third-party CIFS servers, such as Novell Netware 6 or Linux-based Samba servers, are not aware of NTLMv2 and use NTLM only. Therefore, levels greater than "2" do not permit connectivity. Now in this version of the operating system, the default for LmCompatibilityLevel was changed to "3". So when you upgrade Windows, these third party filers may stop working.

Microsoft Outlook clients may be prompted for credentials even though they are already logged on to the domain. When users supply their credentials, they receive the following error message: Windows 7 and Windows Server 2008 R2

The logon credentials supplied were incorrect. Make sure your username and domain are correct, then type your password again.

When you start Outlook, you may be prompted for your credentials even if your Logon Network Security setting is set to Passthrough or to Password Authentication. After you type your correct credentials, you may receive the following error message:

The login credentials supplied were incorrect.

A Network Monitor trace may show that the global catalog issued a remote procedure call (RPC) fault with a status of 0x5. A status of 0x5 means "Access Denied."

Windows 2000: A Network Monitor capture may show the following errors in the NetBIOS over TCP/IP (NetBT) server message block (SMB) session:

SMB R Search Directory Dos error, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Invalid user identifier

Windows 2000: If a Windows 2000 domain with NTLMv2 Level 2 or later is trusted by a Windows NT 4.0 domain, Windows 2000-based member computers in the resource domain may experience authentication errors.

Windows 2000 and Windows XP: By default, Windows 2000 and Windows XP set the LAN Manager Authentication Level Local Security Policy option to 0. A setting of 0 means "Send LM and NTLM responses." Note Windows NT 4.0-based clusters must use LM for administration.

Windows 2000: Windows 2000 clustering does not authenticate a joining node if both nodes are part of a Windows NT 4.0 Service Pack 6a (SP6a) domain.

The IIS Lockdown Tool (HiSecWeb) sets the LMCompatibilityLevel value to 5 and the RestrictAnonymous value to 2.

Services for Macintosh User Authentication Module (UAM): The Microsoft UAM (User Authentication Module) provides a method for encrypting the passwords that you use to log on to Windows AFP (AppleTalk Filing Protocol) servers. The Apple User Authentication Module (UAM) provides only minimal or no encryption. Therefore, your password could easily be intercepted on the LAN or on the Internet. Although the UAM is not required, it does provide encrypted authentication to Windows 2000 Servers that run Services For Macintosh. This version includes support for NTLMv2 128-bit encrypted authentication and a MacOS X 10.1-compatible release. By default, the Windows Server 2003 Services for Macintosh server permits only Microsoft Authentication.  

Windows Server 2008, Windows Server 2003, Windows XP, and Windows 2000: If you configure the LMCompatibilityLevel value to be 0 or 1 and then configure the NoLMHash value to be 1, applications and components may be denied access through NTLM. This issue occurs because the computer is configured to enable LM but not to use LM-stored passwords. If you configure the NoLMHash value to be 1, you must configure the LMCompatibilityLevel value to be 2 or higher.

Network security: LDAP client signing requirements

Background The Network security: LDAP client signing requirements setting determines the level of data signing that is requested on behalf of clients that issue Lightweight Directory Access Protocol (LDAP) BIND requests as follows:

None: The LDAP BIND request is issued with the caller-specified options.

Negotiate signing: If the Secure Sockets Layer/Transport Layer Security (SSL/TLS) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the caller-specified options. If SSL/TLS has been started, the LDAP BIND request is initiated with the caller-specified options.

Require signing: This is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed.

Risky configuration Enabling the Network security: LDAP client signing requirements setting is a harmful configuration setting. If you set the server to require LDAP signatures, you must also configure LDAP signing on the client. Not configuring the client to use LDAP signatures will prevent communication with the server. This causes user authentication, Group Policy settings, logon scripts, and other features to fail.

Reasons to Modify This Setting Unsigned network traffic is susceptible to man-in-the-middle attacks where an intruder captures packets between the client and the servers, modifies them, and then forwards them to the server. When this occurs on an LDAP server, an attacker could cause a server to respond based on false queries from the LDAP client. You can lower this risk in a corporate network by implementing strong physical security measures to help protect the network infrastructure. Additionally, you can help prevent all kinds of man-in-the-middle attacks by requiring digital signatures on all network packets by means of IPSec authentication headers.

Symbolic Name: LDAPClientIntegrity

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

Event Log: Maximum security log size

Background The Event Log: Maximum security log size security setting specifies the maximum size of the security event log. This log has a maximum size of 4 GB. To locate this setting, expand Windows Settings , and then expand Security Settings .

Restricting the security log size and the security log retention method when the Audit: Shut down system immediately if unable to log security audits setting is enabled. See the "Audit: Shut down system immediately if unable to log security audits" section of this article for more details.

Restricting the security log size so that security events of interest are overwritten.

Reasons to Increase This Setting Business and security requirements may dictate that you increase the security log size to handle additional security log detail or to retain security logs for a longer period of time.

Reasons to Decrease This Setting Event Viewer logs are memory mapped files. The maximum size of an event log is constrained by the amount of physical memory in the local computer and by the virtual memory that is available to the event log process. Increasing the log size beyond the amount of virtual memory that is available to Event Viewer does not increase the number of log entries that are maintained.

Examples of compatibility problems Windows 2000: Computers that are running versions of Windows 2000 that are earlier than Service Pack 4 (SP4) may stop logging events in the event log before reaching the size that is specified in the Maximum log size setting in Event Viewer if the Do not overwrite events (clear log manually) option is turned on.  

Event Log: Retain security log

Background The Event Log: Retain security log security setting determines the "wrapping" method for the security log. To locate this setting, expand Windows Settings , and then expand Security Settings .

Failing to retain all logged security events before they are overwritten

Configuring the Maximum security log size setting too small so that security events are overwritten

Restricting the security log size and retention method while the Audit: Shut down system immediately if unable to log security audits security setting is enabled

Reasons to enable this setting Enable this setting only if you select the Overwrite events by days retention method. If you use an event correlation system that polls for events, make sure that the number of days is at least three times the poll frequency. Do this to allow for failed poll cycles.

Network access: Let Everyone permissions apply to anonymous users

Background By default, the Network access: Let Everyone permissions apply to anonymous users setting is set to Not Defined on Windows Server 2003. By default, Windows Server 2003 does not include the Anonymous Access token in the Everyone group.

Example of Compatibility Problems The following value of

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 breaks trust creation between Windows Server 2003 and Windows NT 4.0, when the Windows Server 2003 domain is the account domain and the Windows NT 4.0 domain is the resource domain. This means that the account domain is Trusted on Windows NT 4.0 and the resource domain is Trusting on the Windows Server 2003 side. This behavior occurs because the process to start the trust after the initial anonymous connection is ACL'd with the Everyone token that includes the Anonymous SID on Windows NT 4.0.

Reasons to Modify This Setting The value must be set to 0x1 or set by using a GPO on the domain controller's OU to be: Network access: Let Everyone permissions apply to anonymous users - Enabled to make the trust creations possible. Note Most other security settings go up in value instead of down to 0x0 in their most secured state. A more secure practice would be to change the registry on the primary domain controller emulator instead of on all the domain controllers. If the primary domain controller emulator role is moved for any reason, the registry must be updated on the new server. A restart is required after this value is set.

Registry Path

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

NTLMv2 authentication

Session security Session security determines the minimum security standards for client and server sessions. It is a good idea to verify the following security policy settings in the Microsoft Management Console Group Policy Editor snap-in:

Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options

Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers

Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients

The options for these settings are as follows:

Require message integrity

Require message confidentiality

Require NTLM version 2 session security

Require 128-bit encryption

The default setting prior to Windows 7 is No requirements. Starting with Windows 7, the default changed to Require 128-bit encryption for improved security. With this default, legacy devices that don’t support 128-bit encryption will be unable to connect. These policies determine the minimum security standards for an application-to-application communications session on a server for a client. Note that although described as valid settings, the flags to require message integrity and confidentiality are not used when the NTLM session security is determined. Historically, Windows NT has supported the following two variants of challenge/response authentication for network logons:

LM challenge/response

NTLM version 1 challenge/response

LM allows interoperability with the installed base of clients and servers. NTLM provides improved security for connections between clients and servers. The corresponding registry keys are as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"

Risky configurations This setting controls how network sessions secured using NTLM will be handled. This affects RPC-based sessions authenticated with NTLM, for example. There are the following risks:

Using older authentication methods than NTLMv2 makes the communication easier to attack due to the simpler hashing methods used.

Using encryption keys lower than 128-bit allows attackers to break communication using brute-force attacks.

Time synchronization

Time synchronization failed. The time is off by more than 30 minutes on an affected computer. Make sure that the client computer's clock is synchronized with the domain controller's clock.

Workaround for SMB signing

We recommend that you install Service Pack 6a (SP6a) on Windows NT 4.0 clients that interoperate in a Windows Server 2003-based domain. Windows 98 Second Edition-based clients, Windows 98-based clients, and Windows 95-based clients must run the Directory Services Client to perform NTLMv2. If Windows NT 4.0-based clients do not have Windows NT 4.0 SP6 installed or if Windows 95-based clients, Windows 98-based clients, and Windows 98SE-based clients do not have the Directory Services Client installed, disable SMB signing in the default domain controller's policy setting on the domain controller's OU, and then link this policy to all OUs that host domain controllers. The Directory Services Client for Windows 98 Second Edition, Windows 98, and Windows 95 will perform SMB Signing with Windows 2003 servers under NTLM authentication, but not under NTLMv2 authentication. Additionally, Windows 2000 servers will not respond to SMB Signing requests from these clients. Although we do not recommend it, you can prevent SMB signing from being required on all domain controllers that run Windows Server 2003 in a domain. To configure this security setting, follow these steps:

Open the default domain controller's policy.

Open the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options folder.

Locate and then click the Microsoft network server: Digitally sign communications (always) policy setting, and then click Disabled.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows Alternatively, turn off SMB signing on the server by modifying the registry. To do this, follow these steps:

Click Start , click Run , type regedit, and then click OK .

Locate and then click the following subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

Click the enablesecuritysignature entry.

On the Edit menu, click Modify .

In the Value data box, type 0, and then click OK .

Exit Registry Editor.

Restart the computer, or stop and then restart the Server service. To do this, type the following commands at a command prompt, and then press Enter after you type each command: net stop server net start server

Note The corresponding key on the client computer is in the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters The following lists the translated error code numbers to status codes and to the verbatim error messages that are mentioned earlier:

error 5 ERROR_ACCESS_DENIED Access is denied.

error 1326 ERROR_LOGON_FAILURE Logon failure: unknown user name or bad password.

error 1788 ERROR_TRUSTED_DOMAIN_FAILURE The trust relationship between the primary domain and the trusted domain failed.

error 1789 ERROR_TRUSTED_RELATIONSHIP_FAILURE The trust relationship between this workstation and the primary domain failed.

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

324802 How to configure Group Policies to set security for system services in Windows Server 2003

816585 How to apply predefined security templates in Windows Server 2003

Need more help?

Want more options.

Explore subscription benefits, browse training courses, learn how to secure your device, and more.

Microsoft 365 subscription benefits

Microsoft 365 training

Microsoft security

Accessibility center

Communities help you ask and answer questions, give feedback, and hear from experts with rich knowledge.

Ask the Microsoft Community

Microsoft Tech Community

Windows Insiders

Microsoft 365 Insiders

Was this information helpful?

Thank you for your feedback.

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
• The hidden cost of speed
• The creator of Jenkins discusses CI/CD and balancing business with open source
• Featured on Meta
• Announcing a change to the data-dump process
• Bringing clarity to status tag usage on meta sites

Hot Network Questions

• Why didn't Air Force Ones have camouflage?
• Best approach to make lasagna fill pan
• How would you read this time change with the given note equivalence?
• Can reinforcement learning rewards be a combination of current and new state?
• Applying to faculty jobs in universities without a research group in your area
• Swapping touch digitizer from one Android phone to another
• Gravitational potential energy of a water column
• Is it helpful to use a thicker gauge wire for only part of a long circuit run that could have higher loads?
• Nausea during high altitude cycling climbs
• Romeo & Juliet laws and age of consent laws
• Fusion September 2024: Where are we with respect to "engineering break even"?
• Which volcano is more hazardous? Mount Rainier or Mount Hood?
• Does Psalm 127:2 promote laidback attitude towards hard work?
• Where is this railroad track as seen in Rocky II during the training montage?
• Investigate why packages are held back, and stop release upgrade
• What is the first work of fiction to feature a vampire-human hybrid or dhampir vampire hunter as a protagonist?
• What was the first "Star Trek" style teleporter in SF?
• Topos notions coming from topology and uniqueness of generalizations
• Why is this bolt's thread the way it is?
• When has the SR-71 been used for civilian purposes?
• \ExplSyntaxOn problem with new paragraph
• What's the purpose of scanning the area before opening the portal?
• Is there a way to read lawyers arguments in various trials?
• How does the phrase "a longe" meaning "from far away" make sense syntactically? Shouldn't it be "a longo"?

This browser is no longer supported.

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

Access this computer from the network - security policy setting

• 1 contributor
• Windows 11
• Windows 10
• Windows Server 2022
• Windows Server 2019
• Windows Server 2016
• Azure Stack HCI

Describes the best practices, location, values, policy management, and security considerations for the Access this computer from the network security policy setting.

If running Windows Server or Azure Stack HCI Failover Clustering, don't remove Authenticated Users from the Access this computer from the network policy setting. Doing so may induce an unexpected production outage. This is due to the local user account CLIUSR that is used to run the cluster service. CLIUSR is not a member of the local Administrators group and if the Authenticated Users group is removed, the cluster service won't have sufficient rights to function or start properly.

The Access this computer from the network policy setting determines which users can connect to the device from the network. This capability is required by many network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+).

Users, devices, and service accounts gain or lose the Access this computer from network user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a machine account may be explicitly added to a custom security group or a built-in security group, or it may be implicitly added by Windows to a computed security group such as Domain Users, Authenticated Users, or Enterprise Domain Controllers. By default, user accounts and machine accounts are granted the Access this computer from network user right when computed groups such as Authenticated Users, and for domain controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy Object (GPO).

Constant: SeNetworkLogonRight

Possible values

• User-defined list of accounts
• Not defined

Best practices

• On desktop devices or member servers, grant this right only to users and administrators.
• On domain controllers, grant this right only to authenticated users, enterprise domain controllers, and administrators.
• On failover clusters, make sure this right is granted to authenticated users.
• This setting includes the Everyone group to ensure backward compatibility. Upon Windows upgrade, after you've verified that all users and groups are correctly migrated, you should remove the Everyone group and use the Authenticated Users group instead.

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default values

The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.

Policy management

When you modify this user right, the following actions might cause users and services to experience network access issues:

• Removing the Enterprise Domain Controllers security group
• Removing the Authenticated Users group or an explicit group that allows users, computers, and service accounts the user right to connect to computers over the network
• Removing all user and machine accounts

A restart of the device isn't required for this policy setting to be effective.

Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.

Group Policy

Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:

• Local policy settings
• Site policy settings
• Domain policy settings
• OU policy settings

When a local setting is greyed out, it indicates that a GPO currently controls that setting.

Security considerations

This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.

Vulnerability

Users who can connect from their device to the network can access resources on target devices for which they have permission. For example, the Access this computer from the network user right is required for users to connect to shared printers and folders. If this user right is assigned to the Everyone group, anyone in the group can read the files in those shared folders. This situation is unlikely because the groups created by a default installation of at least Windows Server 2008 R2 or Windows 7 don't include the Everyone group. However, if a device is upgraded and the original device includes the Everyone group as part of its defined users and groups, that group is transitioned as part of the upgrade process and is present on the device.

Countermeasure

Restrict the Access this computer from the network user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the Administrators and Users groups, users who sign in to the domain can access resources that are shared from servers in the domain if members of the Domain Users group are included in the local Users group.

Note If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to Authenticated Users or Domain Computers meets this requirement.

Potential impact

If you remove the Access this computer from the network user right on domain controllers for all users, no one can sign in to the domain or use network resources. If you remove this user right on member servers, users can't connect to those servers through the network. If you have installed optional components such as ASP.NET or Internet Information Services (IIS), you may need to assign this user right to other accounts that are required by those components. It's important to verify that authorized users are assigned this user right for the devices that they need to access the network.

If running Windows Server or Azure Stack HCI Failover Clustering, don't remove Authenticated Users from the Access this computer from the network policy setting. Doing so may induce an unexpected production outage. This outage is due to the local user account CLIUSR that is used to run the cluster service. CLIUSR isn't a member of the local Administrators group and if the Authenticated Users group is removed, the cluster service won't have sufficient rights to function or start properly.

Related topics

User Rights Assignment

Additional resources