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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.

1. 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.
2. If modifying the local machine’s group policy, open the local group policy editor (secpol.msc)
3. Navigate to Security Settings → Local Policies → User Rights Assignments and double-click the “Log on as a service” policy.
   
4. Click Add User or Group.
   

   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.

   

5. Specify the groups or users (domain or local) to give “Log on as a service” rights and click OK.
   
6. As you can see in the below example, four objects were added:
   • THEITBROS\CA IT Ops — domain group
   • THEITBROS\jmiller — domain user
   • PCX\localadmin01 — local user
   • PCX\localadmingroup01 — local group

     Click OK to save the list.
     

7. Wait for the group policy update or run gpupdate /force to force the update immediately. This step is applicable only if you’re deploying the “Log on as a service” policy via GPO.
   
   

   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.

Related post. Navigating the Filesystem with PowerShell Change Directory сommands

Push-Location <Script Folder> 
Get-ChildItem *.ps1

Related post. How to use the PowerShell Get-ChildItem сmdlet

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.

.\Get-ServiceLogonRight.ps1

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 user account 
.\Add-ServiceLogonRight.ps1 -UserOrGroup <local user> 

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

.\Get-ServiceLogonRight.ps1

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 user 
.\Remove-ServiceLogonRight.ps1 -UserOrGroup localadmin02 

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

Conclusion

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.