user rights assignment setting

Set and Check User Rights Assignment via Powershell

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

Posted by : blakedrumm on Jan 5, 2022

How to get it

Local Computer

Remote computer, output types.

This post was last updated on August 29th, 2022

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

Set User Rights

All of the User Rights that can be set:

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

Here are a few examples:

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

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

Check User Rights

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

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

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

Get Remote SQL Server User Account Rights:

Get Local Machine and SQL Server User Account Rights:

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

Output to Text in ‘C:\Temp’:

PassThru object to allow manipulation / filtering:

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

Email : [email protected]

Website : https://blakedrumm.com

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

• operationsManager
• troubleshooting
• certificates

WinSecWiki  > Security Settings  > Local Policies  > User Rights

User Rights Assignments

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

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

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

Child articles:

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

Back to top

Stack Exchange Network

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

Q&A for work

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

Can't edit Local Security Policy

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

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

How can I add a user to this policy?

The machine is running Windows 7.

• remote-desktop
• administrator
• group-policy

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

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

To modify this policy, either:

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

You must log in to answer this question.

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

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

Hot Network Questions

• Embarrassment at work caused by a supervisor
• Use of "in" within "I'll blow your house in"
• How do you honour the principle to only do "one thing" in a method in reactive streams?
• How to measure q-factor?
• Is there a valid reason why Canon's webcam plugin asks to scan my external drives?
• Does the success of AI (Large Language Models) support Wittgenstein's position that "meaning is use"?
• How can I reserve a TGV seat on a Germany-Switzerland ticket purchased via Deutsche Bahn?
• The ltwoo shifter i bought is a 10 speed but only clicks 9 times, is it really like this or should it be 10 clicks
• Is there (anti-)correlation between antisemitic and islamphobic attitudes?
• Why don't Democrats let Representative Greene rename post offices, and how do they prevent her from doing so?
• Can you tile a 25 x 25 square with a mixture of 2 x 2 squares and 3 x 3 squares?
• Where would aurora borealis be visible if the earth was rotated to move its axis?
• Young's double slit experiment with two glass slabs
• A visualization for the quotient rule
• Is subjective gravity in the Astral Plane still a thing?
• Flip a coin in Lost
• Can two interfering light beams create radio waves?
• How could I manage data from serial device to RJ45
• How to evenly mix stir fried vegetables with noodles?
• Which word was used in formal speech instead of "bini" (pairs), if "bini" was impolite because of sounding like the Greek f-word?
• What is this vegetable?
• Why don't airports use different radio frequencies/channels for each plane to prevent communications from interfering with each other?
• Why is siunitx throwing an \endcsname inside newcommand?
• Why couldn't honey be sent up to Mir?

• NIST 800-53
• Common Controls Hub

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

Tim’s Tech Blurbs

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

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

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

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

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

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

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

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

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

Goto Devices -> Configuration Profiles. Select Add new.

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

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

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

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

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

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

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

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

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

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

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

Published by Tim Wood

Privacy overview.

All about Microsoft Intune

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

Restricting the local log on to specific users

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

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

Configuring the allow local log on setting

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

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

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

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

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

Experiencing the user rights configuration

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

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

More information

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

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

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

I’d like to contribute to this.

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

I use this in production, works well

Thank you for that suggestion, Temilit. Regards, Peter

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

Which version of Windows are you using? Regards, Peter

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

Can you use an AAD group here?

Not at this moment, Henrik. Regards, Peter

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

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

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

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

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

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

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

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

Any thought why KioskUser0 not auto logging automatically?

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

Hello Peter,

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

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

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

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

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

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

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

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

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

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

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

Leave a Comment Cancel reply

Notify me of follow-up comments by email.

Notify me of new posts by email.

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

• About the Authors

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Related post . Configure NTP Time Sync Using Group Policy

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

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

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

Download the “Log on as a service” Management Scripts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cyril Kardashevsky

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

Understanding ProxyAddresses Attribute in Active Directory

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

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

– Angry Sr. Systems Admin LOL

Been like this for 20 years now.

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

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

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

Leave a Comment Cancel Reply

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

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

How to manage user account settings on Windows 11

Here are the steps to add, change, and remove accounts on Windows 11.

View account details

• Add more email accounts
• Change sign-in options
• Control account sync settings
• Connect to organization
• Add multiple accounts
• Delete accounts

On Windows 11 , the "Accounts" page in the Settings app allows you to review and customize many aspects of your account. You can determine the account type, switch from a Microsoft to a local account, change how you sign in, and enable many features to make the experience more secure and easier to use.

In addition, when you need to share a device with other people, you can create an account for each person so that each has a personal space they can customize, apps with their own profile, and a different area to store files.

Furthermore, if you must let a young person use a computer, you can also create a special child account type that provides parental control to monitor and protect them from content that may not be appropriate for their age.

This guide will teach you the steps to manage user accounts on your computer running the latest version of Windows 11.

How to view account details on Windows 11

On Windows 11, the "Your info" settings page includes details about your account, such as the type of account and the Microsoft account associated with the current profile. It also houses the settings to switch from a Microsoft to a local account or vice versa and the option to change the picture profile.

To view the account information on Windows 11, use these steps:

Get the Windows Central Newsletter

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

• Open  Settings .
• Click on  Accounts .
• Click the  Your info  page on the right side.

• Confirm your account details, including account type (Administrator or Standard) and whether you have a local or Microsoft account. 

• Quick note:  If the page reads "Local account" under your name, there's a link to a Microsoft account. You have a Microsoft account configuration if your email address appears on this page.
• (Optional) Under the "Related settings" section, click the  "Accounts"  option to access the account online to change billing details, family and security settings, and other settings.

Once you complete the steps, the "Your info" page will give various pieces of information about the account.

In the "Accounts" section, you're also going to find the "Your Microsoft account" page, but it only includes details about your Microsoft 365 subscription.

Change to local account

If you have a Microsoft account and you prefer a local account, you can use these steps to switch:

• Under the "Account settings" section, click the  "Sign in with a local account instead"  option.

• Continue with the on-screen directions. 
• If you have a Microsoft account, click the  "Sign in with a local account instead"  option to switch to a local account.
• Continue with the on-screen directions.

After you complete the steps, the account will no longer be associated with a Microsoft account. 

You can also use the instructions outlined above to switch to a Microsoft account if you have a local account.

Change account picture

To change the account picture on Windows 11, use these steps:

• Click the  Browse files  button in the "Choose a file" setting. 

• Quick tip:  You can also use the  Camera  option to take a picture and set it as the new profile photo.
• Select a new image for the account.
• Click the  Choose Picture  button.

Once you complete the steps, the picture will apply to the account.

How to link additional emails to an account on Windows 11

You can also add other email accounts in advance, so you don't have to enter the information on other apps (such as Mail & Calendar) and services.

Add accounts for apps

To add additional email accounts on Windows 11, use these steps:

• Click the  Email & accounts  page on the right side.

• Under the "Accounts used by email, calendar, and contacts" section, click the  Add an account  button.

• Quick note:  If you want to add another Microsoft account, the system will list it under the "Accounts used by other apps" section.
• Select the service provider (such as Outlook, Google, or iCloud).

After you complete the steps, the accounts will be available to set up other apps and services.

Add accounts for work

To add work accounts for apps on Windows 11, use these steps:

• Under the "Accounts used by other apps" section, click the  "Add a Microsoft account"  or  "Add a work or school"  account.

• Select the correct service.

Once you complete the steps, the account will be added, giving you quick access to work applications, such as OneDrive for Business.

How to change sign-in options on Windows 11

Windows 11 also includes the "Sign-in options" page that includes the different ways you can customize the preferences to sign into your account. For example, on this page, you can configure Windows Hello, change your local account password, and enable other features like Dynamic lock.

Change account password

If you use Windows 11 with a Microsoft account, you can only change the password  online  by changing your Hotmail, Live, or Outlook password. You can change the password through the Sign-in options page if you have a local account.

To change the account password on Windows 11, use these steps:

• Click the  Sign-in options  page on the right side.
• Under the "Ways to sign in" section, click the  Password  setting.
• Click the  Change  button.

• Confirm the current password.
• Confirm the new password.

• Quick note:  You can't re-use a previous password. You must enter a new password.
• Click the  Next  button.
• Continue with the on-screen directions (if applicable).

After you complete the steps, you can sign out and sign back in to start using the new password.

Configure or change Windows Hello authentication

On Windows 11, you have multiple ways to configure Windows Hello. You can set up facial or fingerprint recognition if you have the hardware that supports the feature. You can use a physical security key (usually used in organizations). And the most common form of authentication is the PIN option since it doesn't require special hardware and is more secure than a traditional password.

Usually, Windows 11 will prompt you to create a PIN during the initial setup, but if you are still using a password, you can use these steps to set up a Windows Hello PIN:

• Under the "Ways to sign in" section, click the  PIN (Windows Hello)  setting.
• Click the  Set up button.

• Confirm your current password (if applicable).
• Click the  OK  button.
• Create a new numeric PIN that you will remember. 

• (Optional) Under the "Additional settings" section, turn on the  "For improved security, only allow Windows Hello sign-in for Microsoft accounts on this device"  toggle switch.
• Quick note:  This feature will turn on Windows Hello for all authentications across Windows 11, so you are never asked for your account password.

Once you complete the steps, you can start using the PIN to sign in instead of a password.

Change current PIN

If you already have a PIN, you will only find the option to change or remove it.

To change the current account PIN, use these steps:

• Under the "Ways to sign in" section, click the  PIN (Windows Hello)  setting.
• Click the  Change PIN  button.

• Confirm the current PIN.
• Create a new PIN.
• Confirm the new PIN.

• (Optional) Under the "Additional settings" section, turn on the  "For improved security, only allow Windows Hello sign-in for Microsoft accounts on this device"  toggle switch.

•   Quick note:  This feature will turn on Windows Hello for all authentications across Windows 11, so you are never asked for your account password. However, if enabled, you won't be able to remove the PIN.

After you complete the steps, the Windows Hello information will change to the new PIN.

Enable sign-in upon waking up

As part of the account settings, you can decide whether the system should prompt you for a password upon waking the device or after some time you have been away from your desk.

To require a sign-in after waking up or specific time period, use these steps:

• Under the "Additional settings" section, use the  "If you've been away, when should Windows require you to sign in again?"  setting to automatically select how long the system should wait before locking the account.

This setting replaces the "Require sign-in" option that lets you decide whether Windows 11 should ask you to sign in when the device wakes up from sleep mode. If you want to disable the option, select the  Never  option.

Enable Dynamic lock

"Dynamic lock" is a feature that locks your device when you step away from the room automatically. The feature uses proximity technology, meaning you'll need to connect a Bluetooth device like a phone or wearable before you can configure it. Once enabled, if you step away from the computer after 30 seconds, Windows 11 will lock the profile automatically.

To enable Dynamic lock, use these steps:

• Click on  Bluetooth & devices .
• Click on  Add device  button.

• Click on  Bluetooth .

• Turn on Bluetooth on the device you want to pair.
• Select the device from the list.

• Continue with the on-screen directions to complete the pairing.
• Click the  Sign-in options  page on the right side.
• Under the "Additional settings" section, click the  Dynamic lock  setting.
• Check the "Allow Windows to automatically lock the device when you're away"  option.

Once you complete the steps, you can step away from the desk with the Bluetooth device, and then after 30 seconds, when you return, the computer should be locked.

Stop restarting apps on startup

Some apps are able to restart automatically at startup if you don't close them before turning off the computer. If you don't like this behavior, you can disable the feature. 

To prevent apps from restarting at startup, use these steps:

• Under the "Additional settings" section, turn off the  "Automatically save my restartable apps and restart when I sign back in"  toggle switch. 

After you complete the steps, apps will no longer restart automatically on startup.

How to control account sync settings on Windows 11

On Windows 11, Microsoft is referring to the sync settings as the new "Windows Backup" feature. On this page, you can choose what folders are backed up in the cloud using OneDrive . You can decide whether the system should remember your apps so you can restore them on another installation. And you can control the settings you want to sync across devices associated with the same Microsoft account.

To control the sync settings on Windows 11, use the steps:

• Click the  Windows backup  page on the right side.

• Click the  Set up syncing  button for the "OneDrive folder syncing" setting.

• Select the folders (Desktop, Documents, or Pictures) to upload and back up on the cloud. (You must have enough space to enable this feature.)

• Click the  Start backup  button.
• (Optional) Turn on the  "Remember my apps"  toggle switch if you want the system to remember the Microsoft Store app on your computer so that you can restore them later on another computer. 
• Turn on the  "Remember my preferences"  toggle switch to allow your settings to sync across devices.
• Click the "Remember my preferences" setting.
• Check the settings you want to sync across devices, including passwords, language preferences, and other Windows settings.

Once you complete the steps, the settings and files will sync to the cloud and across devices, depending on your configuration.

How to connect account to an organization on Windows 11

The "Access work or school" page has the settings to connect to an organization to access shared resources, such as network resources, apps, and emails. If you are part of an organization, your network administrator will provide the information.

To connect a device to the network, use these steps:

• Click the  Access work or school  page on the right side.

• Click the Connect button.
• Confirm your work or school account. 

• Quick note:  You can also select the option to join an Azure Active Direction or local Active Directory domain from this page.

After you complete the steps, you will have access to the organization's resources as configured by the network administrator.

How to add multiple accounts on Windows 11

Although most computers are set up for single users, Windows 11 allows you to share the device with multiple people through the "Family & other people" page, which includes the settings to add, remove, and manage multiple user accounts.

Add family members 

On the page, under the "Your family" section, you can manage family members to allow each person to have their desktop, settings, apps, and a place to store files separately from everyone else.

You can have two family account types, including "Child" and "Adult," and each account type provides different features.

Create a child account

A  Child  account offers a controlled environment with features to keep young members safe while using apps, playing games, and browsing the internet. If you choose to create a child account, the person can use the device, personalize the desktop, work with apps, create files, and safely browse the web with Microsoft Edge. 

Also, when using this account type, the organizer can control their activities, enforce limits on apps and games, control screen time, and more using the Microsoft family dashboard online.

To create a child account on Windows 11, use these steps:

• Click the  Family & other users  page on the right side.

• Click the  Add account  in the "Add a family member" setting. 

• Confirm the email address of the young person you want to add.

• Quick note:  If the young person doesn't have an account, choose the "Create one for a child" option and continue with the on-screen directions.
• Click the Next button.
• Select the Member option.
• Click the Invite button.

• Open the invitation email in the child's account online.
• Click the Accept Invitation button.

• Click the Join now button.

• Sign out of the main account.
• Select the child account from the Lock screen.
• Sign in with the child's Microsoft account credentials.
• Click the Skip for now option (if applicable).
• Create a PIN for the account.

• Click the OK button.
• Continue with the on-screen directions to finish the setup.

Once you complete the steps, Windows 11 will create the account, and the user will be able to sign in immediately.

Create an adult account

When using the family settings, an adult account is the same as a traditional local account, but members can also control child accounts.

To add a new member to the family group on Windows 11, use these steps:

• Click the  Add account  in the "Add a family member" setting. 
• Confirm the family member's email address.

• Click the  Next  button.
• Select the  Organizer  option.
• Click the  Invite  button.

After you complete the steps, the account will be created, but the new member will need to accept the email invitation before they can use the device and manage parental control settings for child accounts.

Add non-family member 

On Windows 11, you can also create accounts for other people not necessarily part of your family. Using these settings, you can create a Microsoft or traditional local account. 

Create a Microsoft account

Using a Microsoft account is recommended because it's easier to configure, the user can choose to sync their settings across devices, and password recovery is straightforward.

To create a profile with a Microsoft account, use these steps:

• Under the "Other users" section, click the  Add account  button for the "Add other user" setting.

• Confirm the email address or phone number of the new user.

• Quick note: If the user doesn't have a Microsoft account, choose the "I don't have this person's sign-in information" option to create an account and continue with the on-screen directions.
• Click the  Finish  button.

Once you complete the steps, the person should be able to sign in and start using the device.

Create a local account

On Windows 11, you can still create a local account without needing a Microsoft account, also called an offline account.

To create a local account on Windows 11, use these steps:

• Click the  "I don't have this person's sign-in information"  option.
• Click the  "Add a user without a Microsoft account"  option.

• Confirm the username.
• Create a password for the account.
• Complete the security questions to enable the reset option if you forget the password.

After you complete the steps, the user can log in and start using the standard local account on your Windows 11 computer.

Furthermore, the "Family & other users" page also includes an option to  set up a kiosk account . This feature is usually reserved for network administrators to turn a computer into a digital sign or interactive display or turn it into a device that only runs a specific application.

Change account type

As standard user account is the recommended type for most users, but if you want to change the type to administrator .

To change a user account type on Windows 11, use these steps:

• Click the  Family & other users  page on the right side.
• Under the "Other users" section, select the account to update.
• Click the  Change account type  button.

• Select the  Administrator  account type.

Once you complete the steps, the new account type will dictate the user's access privileges.

How to delete account on Windows 11

On Windows 11, when you no longer need an account, you can delete the profile and data, but the steps can differ depending on the account type.

Remove family account

To delete a family member account on Windows 11, use these steps:

• Under the "Your family" section, click the "Manage family settings online" option.
• Sign in with your credentials (if applicable).

• Under the "Your family" section, click the (three-dotted) menu button in the right corner of the user account and select the  "Remove from family group"  option.
• Click the  Remove  button.

• Quick note: If you are trying to remove a child account, you may first need to choose the "Manage consent" option and remove the consent before you can remove the account from the family group.

Once you complete the steps, the account and files will be deleted from the computer.

Remove non-family account

To delete a local account on Windows 11, use these steps:

• Under the "Other users" section, select the user account and click the  Remove  button.

• Click the  "Delete account and data"  button.

After you complete the steps, the profile and files will be deleted from the device.

More resources

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

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

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

• 2 Best Fallout 4 mods on PC
• 3 The Windows 10 Settings app is the latest attack vector Microsoft will use to push you to sign up for a cloud account
• 4 Microsoft eludes EU antitrust merger probe over its multi-billion dollar investment in OpenAI amid claims it's turned into 'a glorified IT department for the hot startup'
• 5 What are Progressive Web Apps (PWAs), and how do you install them on Windows 11?

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.

Select Product

2204 LTSR (initial release)

Known issues

New UI (Technical Preview)

Install, set up, upgrade, and uninstall

Plan your StoreFront deployment

User access options

System requirements

Install StoreFront

Citrix Customer Experience Improvement Program

Citrix Analytics

Secure StoreFront with HTTPS

Secure your StoreFront deployment

Configure email based account discovery

Create a new deployment

Join an existing server group

Upgrade StoreFront

Reset a server to factory defaults

Uninstall StoreFront

Configure authentication and delegation

Configure authentication

Smart card authentication

Domain pass-through authentication

Gateway pass-through authentication

SAML authentication

User name and password authentication

Federated Authentication Service configuration

Configure and manage stores

Create a store

Configure a store

Remove a store

Export store provisioning files for users

Advertise and hide stores to users

Configure Kerberos Delegation

Manage the resources made available in stores

Manage remote access to stores through Citrix Gateway

Certificate Revocation List (CRL) checking

Configure two StoreFront stores to share a common subscription datastore

Manage subscription data for a store

Store subscription data using Microsoft SQL Server

Enable or disable favorites

Citrix Virtual Apps and Desktops configuration

Advanced store settings

Optimal HDX Routing

Subscription synchronization

Configure session settings

Ica file signing

Citrix Workspace app configuration

Manage a website

Create a website

Configure website

Category settings

Customize appearance

Featured app groups

Authentication methods

Website shortcuts

Deploy Citrix Workspace app

Session settings

Workspace control

Client interface settings

App Protection

Remove website

Configure Citrix Workspace app website

Configure server groups

Integrate with Citrix Gateway and NetScaler ADC

Configure Citrix Gateways

Import a Citrix Gateway

Load balancing with NetScaler ADC

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

Authenticate using different domains

Configure beacon points

Create a single FQDN used internally and externally

Export and import the StoreFront configuration

End user guide

StoreFront SDK

Troubleshoot StoreFront

Third party notices

Document History

This content has been machine translated dynamically.

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

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

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

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

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

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

Este texto foi traduzido automaticamente. (Aviso legal)

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

This article has been machine translated.

Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)

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

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

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

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

Este artigo foi traduzido automaticamente. (Aviso legal)

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

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

Translation failed!

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

• Communication between end users and StoreFront

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

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

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

• StoreFront communications with Citrix Virtual Apps and Desktops servers

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

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

• StoreFront communications with Cloud Connectors

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

• Remote access

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

• Microsoft Internet Information Services (IIS) hardening

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

Filename extensions

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

StoreFront requires the following file name extensions:

• . (blank extension)

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

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

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

Non-Ascii characters in URLs

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

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

See IIS documentation .

Remove X-Powered-By Header

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

Remove Server header with IIS version

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

Move the StoreFront website to a separate partition

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

IIS features

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

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

Handler Mappings

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

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

See IIS Handlers Documentation .

ISAPI filters

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

.NET Authorization Rules

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

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

Application Pools

StoreFront creates the following application pools:

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

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

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

Required settings

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

StoreFront installation creates the following Windows services:

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

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

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

• User rights assignment

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

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

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

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

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

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

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

• Configure group memberships

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

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

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

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

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

StoreFront installation also creates the following local security groups:

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

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

• Certificates in StoreFront

Server certificates

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

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

Token management certificates

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

Citrix Delivery Services certificates

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

Code signing certificates

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

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

• Disabling legacy TLS versions

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

• StoreFront security separation

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

• ICA file signing

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

• User change password

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

• Customizations

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

• Security Headers

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

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

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

• Additional security information

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

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

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

In this article

This Preview product documentation is Citrix Confidential.

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

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

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

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

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

Edit Article

This browser is no longer supported.

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

Policy CSP - UserRights

• 26 contributors

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

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

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

General example

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

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

Grant a user right to Administrators group via SID:

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

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

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

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

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

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

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

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

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

AccessCredentialManagerAsTrustedCaller

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

Description framework properties :

Group policy mapping :

AccessFromNetwork

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

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

ActAsPartOfTheOperatingSystem

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

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

AdjustMemoryQuotasForProcess

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

AllowLocalLogOn

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

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

AllowLogOnThroughRemoteDesktop

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

BackupFilesAndDirectories

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

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

BypassTraverseChecking

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

ChangeSystemTime

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

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

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

ChangeTimeZone

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

CreateGlobalObjects

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

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

CreatePageFile

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

CreatePermanentSharedObjects

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

CreateSymbolicLinks

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

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

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

CreateToken

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

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

DebugPrograms

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

DenyAccessFromNetwork

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

DenyLocalLogOn

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

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

DenyLogOnAsBatchJob

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

DenyLogOnAsService

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

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

DenyRemoteDesktopServicesLogOn

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

EnableDelegation

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

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

GenerateSecurityAudits

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

ImpersonateClient

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

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

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

IncreaseProcessWorkingSet

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

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

IncreaseSchedulingPriority

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

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

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

LoadUnloadDeviceDrivers

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

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

LogOnAsBatchJob

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

LogOnAsService

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

ManageAuditingAndSecurityLog

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

ManageVolume

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

ModifyFirmwareEnvironment

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

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

ModifyObjectLabel

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

ProfileSingleProcess

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

ProfileSystemPerformance

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

RemoteShutdown

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

ReplaceProcessLevelToken

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

RestoreFilesAndDirectories

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

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

ShutDownTheSystem

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

TakeOwnership

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

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

Related articles

Policy configuration service provider

Was this page helpful?

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

Submit and view feedback for

Additional resources