log on locally user right assignment

This browser is no longer supported.

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

Allow log on locally - security policy setting

• 1 contributor

Describes the best practices, location, values, policy management, and security considerations for the Allow log on locally security policy setting.

This policy setting determines which users can start an interactive session on the device. Users must have this user right to log on over a Remote Desktop Services session that is running on a Windows-based member device or domain controller.

Note:   Users who do not have this right are still able to start a remote interactive session on the device if they have the Allow logon through Remote Desktop Services right.

Constant: SeInteractiveLogonRight

Possible values

• User-defined list of accounts
• Not Defined

By default, the members of the following groups have this right on workstations and servers:

• Administrators
• Backup Operators

By default, the members of the following groups have this right on domain controllers:

• Account Operators
• Enterprise Domain Controllers
• Print Operators
• Server Operators

Best practices

• Restrict this user right to legitimate users who must log on to the console of the device.
• If you selectively remove default groups, you can limit the abilities of users who are assigned to specific administrative roles in your organization.

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

Default values

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

Policy management

Restarting the device is not required to implement this change.

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

Modifying this setting might affect compatibility with clients, services, and applications. Use caution when removing service accounts that are used by components and by programs on member devices and on domain controllers in the domain from the default domain controller's policy. Also use caution when removing users or security groups that log on to the console of member devices in the domain, or removing service accounts that are defined in the local Security Accounts Manager (SAM) database of member devices or of workgroup devices. If you want to grant a user account the ability to log on locally to a domain controller, you must make that user a member of a group that already has the Allowed logon locally system right or grant the right to that user account. The domain controllers in the domain share the Default Domain Controllers Group Policy Object (GPO). When you grant an account the Allow logon locally right, you are allowing that account to log on locally to all domain controllers in the domain. If the Users group is listed in the Allow log on locally setting for a GPO, all domain users can log on locally. The Users built-in group contains Domain Users as a member.

Group Policy

Group Policy settings are applied through GPOs in the following order, which will overwrite settings on the local computer at the next Group Policy update:

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

Security considerations

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

Vulnerability

Any account with the Allow log on locally user right can log on to the console of the device. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.

Countermeasure

For domain controllers, assign the Allow log on locally user right only to the Administrators group. For other server roles, you may choose to add Backup Operators in addition to Administrators. For end-user computers, you should also assign this right to the Users group. Alternatively, you can assign groups such as Account Operators, Server Operators, and Guests to the Deny log on locally user right.

Potential impact

If you remove these default groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. If you have installed optional components such as ASP.NET or IIS, you may need to assign the Allow log on locally user right to additional accounts that are required by those components. IIS requires that this user right be assigned to the IUSR_ <ComputerName> account. You should confirm that delegated activities are not adversely affected by any changes that you make to the Allow log on locally user rights assignments.

Related topics

• User Rights Assignment

Additional resources

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

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

Description:.

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

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

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

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

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

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

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

Set or Grant Allow log on locally user rights via Powershell

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

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

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

Powershell output :

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

Set Allow log on locally user right via Command Line tool

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

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

Set Log on Locally user right

Revoke Log on Locally user right

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

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

LsaWrapper class file

Share this:

Related posts.

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

Leave a Comment Cancel reply

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

WinSecWiki  > Security Settings  > Local Policies  > User Rights  > User Rights In-Depth  > Allow log on locally

Allow log on locally

AKA: SeInteractiveLogonRight, Allow log on locally

Default assignment on workstations and member servers: Administrators, Backup Operators, Power Users, Users, and Guest

Default assignment on domain controllers: Account Operators, Administrators, Backup Operators, Print Operators, and Server Operators

This right controls who can logon interactively at the local console of the computer. This right should have been named “Allow log on interactively” since the term “interactive” is used everywhere else in Windows for this type of logon. Allow log on locally has nothing to do with local user accounts in the SAM. Only allow this right for user who you wish to be able to logon at the local keyboard and monitor of computer. Note that by default any user in the forest can logon to any workstation or member server because the local Users group includes Domain Users as a member. And even on domain controllers this right’s default assignments are too lax for most environments given that they allow operators to logon locally.

In Windows 2000 (pre SP2) this right also allows you to logon via Terminal Services. In Windows 2000 SP2, XP and 2003, Microsoft added the  Allow logon through Terminal Services  right and removed Terminal Services logon ability from Allow log on locally.

The  Deny logon locally logon  right overrides this right.

Use of this right does not generate a  Privilege Use  event in the Windows security log but local logons do generate event ID  528 / 4624  with logon type 2. 

Changes to these logon rights assignments are logged by event IDs 621 / 4717  and 622 / 4718 .

More information at  Logon Rights .

Back to top

At the edge of tweaking

Advertisement

To Allow User or Group to Sign in Locally in Windows 10,

• In the next dialog, click  Add User or Group .

• From the list, select the user account or group to allow log on locally for it. You can select more than one entry at once by holding the Shift  or  Ctrl  keys and clicking on the items the list.

• Click on the  OK button to add the selected items to the policy list.

You are done.

If your Windows edition doesn't include the  secpol.msc  tool, you can use the  ntrights.exe  tool from  Windows 2003 Resource Kit . Many resource kit tools released for previous Windows versions will run successfully on Windows 10. ntrights.exe is one of them.

The ntrights tool

The ntrights tool allows you to edit user account privileges from the command prompt. It is a console tool with the following syntax.

• Grant a right:  ntrights +r Right -u UserOrGroup [-m \\Computer] [-e Entry]
• Revoke a right:  ntrights -r Right -u UserOrGroup [-m \\Computer] [-e Entry]

The tool supports plenty of privileges which can be assigned to or revoked from a user account or group. Privileges are  case sensitive . To learn more about the supported privileges, type  ntrights /? .

To add ntrights.exe to Windows 10 , read this post: What is ntrights app and how you can use it . You can place the ntrights.exe file to the C:\Windows\System32 folder to quickly call it.

Deny log on locally with ntrights

• Open an  elevated command prompt .

Articles of interest.

• Deny User or Group to Sign in Locally in Windows 10
• Allow or Deny Users to Logon with Remote Desktop in Windows 10
• Allow or Prevent Users or Groups to Shut Down Windows 10

Winaero greatly relies on your support. You can help the site keep bringing you interesting and useful content and software by using these options:

If you like this article, please share it using the buttons below. It won't take a lot from you, but it will help us grow. Thanks for your support!

Author: Sergey Tkachenko

Sergey Tkachenko is a software developer who started Winaero back in 2011. On this blog, Sergey is writing about everything connected to Microsoft, Windows and popular software. Follow him on Telegram , Twitter , and YouTube . View all posts by Sergey Tkachenko

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Privacy Overview

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.

Allow logon locally option grayed out

We have a Domain Controller running on windows2012R2.

All local computers are on Windows10.

When i try to login to one of the client computer with Domain User Credentials i get an error

What could be the issue?

I tried to add users to " Allow log on locally " Policy on Local computer with Local admin login but im unable to add users or groups

Is there any work around?

please suggest.

• group-policy

• Probably UAC; use "Run as administrator" to launch the policy editor. Anyway, there already is "Everyone" listed... you can't really add much more. –  Massimo Apr 4, 2016 at 19:17
• i tried running with administrator even , no Luck. . if this is not the solution, what could be the issue "The sign in method . . . . " :/ –  Uday Sriramadas Apr 4, 2016 at 19:22
• 1 Seems like a user/computer GPO setting more than a local computer. Might want to check the GPO settings on the server more than on the local computer. –  Naryna Apr 4, 2016 at 19:22
• May be , Do you have any idea which GPO may cause this thing? #Brandyn –  Uday Sriramadas Apr 4, 2016 at 19:26
• You can use gpresult to find what GPOs are applied to the computer. –  Massimo Apr 4, 2016 at 19:28

You need to manage this element via Group Policy Management. Czerw11 did a good write up of the process of using Group Policy Management to update this on your domain controllers via the Default Domain Controller Policy, you can extend this to your client policy as well.

https://czerwsup.wordpress.com/2014/11/05/allow-log-on-locally-add-new-user-greyed-out-fix-via-domain-controller-policy-settings/

Summary Steps:

• Admin Tools
• Group Policy Management
• Navigate through your domain to Default Domain Policy in your case (not Default Domain Controllers Policy as in the example)

To improve this answer, the best practice is to not edit the Default Domain Controllers Policy, but to create a GPO with these policies changes and assign it to the narrowest OU you need to affect the servers. If you edit the Default Policies you remove all of the default permissions.

• Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies
• User Rights Assignment
• Double Click on Allow Log On Locally and add your users

You must log in to answer this question.

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

• The Overflow Blog
• Want to be a great software engineer? Don’t be a jerk.
• Climbing the GenAI decision tree sponsored post
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network

Hot Network Questions

• Can I make attacks non-lethal?
• How can you change up medieval feudalism while keeping the concept of 'houses'?
• Western politicians who accused Israel of starving Gaza
• To what extent can citizens of democracies be held responsible for the acts of their governments?
• Am I in my rights to ask a colleague to not take notes on everything I say outside a meeting?
• What is SpaceX doing differently with their Falcon 9 so that it doesn't cost as much as the Space Shuttle?
• Noun phrase with adjective
• Adding event listeners in the Constructor of LWC
• No stomach, how do I eat?
• How do I snap an object permanently to another object in animation?
• How do University-graduated Spanish 'Ingenieros' demonstrate their certification is actually a Bachelor's Degree?
• Connecting C-wire to 1989 Forced Air Electric Heater
• G has a element of order 2 not lying in center
• Can you launch a pellet created with Dust of Dryness to smash it at range?
• Do batteries have capacitance?
• Water heater leak increasing when main water line is turned on , but the valve is shut off
• Why is a peak in the gain a sign of instability in a closed loop op-amp circuit?
• Can religions die?
• Why isn't there financial safety if I am arrested illegally?
• alphanumerics in duration in sheets - how to convert to a number of minutes
• What is the correct formulation of Newton's Second Law of Motion?
• Temporal difference formula Sutton & Barto tic-tac-toe
• Do Bell’s inequalities assume determinism?
• Align cursor rotation to normal

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

• NIST 800-53
• Common Controls Hub

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