Granting ‘Logon as a service’ Rights via GPO or PowerShell

7.1K

Log on as a service (SeServiceLogonRight) is a Windows user permission that enables specific applications or network services to run in the background on behalf of a user account, regardless of whether the user is logged in. In this guide, we’ll cover how to grant “Log on as a service” rights in Windows using the Local Security Policy, domain GPO, the command line, or PowerShell, along with configuring a service to run under a specific user account.

Keep in mind that the “Log on as a service” right only controls whether an account can start a Windows service (it does not restrict what the service can access once running). The actual security boundary depends on NTFS permissions, token privileges, and service config.

Log on as a service is different from Log on as a batch job (SeBatchLogonRight), which is used for scheduled tasks and automation jobs rather than Windows services.

What is “Log on as a Service” in Windows?

“Log on as a service” is a security policy that allows a specific user to launch network services or to register a process as a service running on the system, without the user being logged in locally. This policy is used when you need to run a specific application or service on a computer in the background, without user interaction and without granting local administrator or SYSTEM privileges.

Running Windows network services under a dedicated user or service account rather than a built-in system account, such as Local System, Network Service, or Local Service, improves security and management and enhances process isolation. According to security best practices, interactive and remote interactive sessions for such service accounts can be disabled.

Note that modern Windows services may also run under virtual service accounts (such as NT SERVICE). This provides service isolation without requiring password management.

Adhering to the principle of least privilege, a dedicated service account limits the potential damage that could be caused by a compromise, as the service cannot access the entire server or domain. To run a service, you can either use a separate non-privileged user account or gMSA (Group Managed Service Accounts) in the AD Domain.

We recommend using Group Managed Service Accounts (gMSA) over traditional service accounts because they eliminate password management. When a gMSA is configured correctly as the logon account for a Windows service, Windows may automatically grant the required Log on as a service right. In other deployment cases, you may need to assign the SeServiceLogonRight user right explicitly.

Configure ‘Log on as a Service’ Right via Group Policy

You can configure the “Log on as a service” rights assignment via the local or domain group policy. Use the Local Security Policy (secpol.msc) to configure the policy on a standalone computer. Or, use the Group Policy Management console (gpmc.msc), create and configure new GPO to set ‘Logon as service’ permissions for multiple domain computers.

1. Navigate to Security Settings → Local Policies → User Rights Assignments and double-click the “Log on as a service” policy.
   

   

2. By default, only the NT SERVICE\ALL SERVICES group is specified here. Click Add User or Group.

   

3. Specify the groups or users (domain or local) to grant “Log on as a service” rights and click OK. You can add local or domain users and groups.
   

   

4. Click OK to save the list.
   

   

5. Wait for the Group Policy update or run gpupdate /force to force the update immediately.
   

   

In order to verify the effective “Log on as a service” assignment on a machine, you should use Resultant Set of Policy (rsop.msc) and navigate to Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.

You can also export the effective local security policy with the command:

secedit /export /cfg C:\temp\secpol.cfg

Then search the exported policy file for the SeServiceLogonRight entry:

findstr /i "SeServiceLogonRight" C:\temp\secpol.cfg

Some tips

• The “Log on as a service” setting operates in Replace mode by default when managed via domain GPOs. This means that the domain GPO fully overwrites the existing list of accounts (whether local or prior policies) with its own defined accounts, rather than merging or appending them.
• Ensure that the user account has not been added to the ‘Deny logon as a service’ policy, since this policy setting takes precedence. This policy always takes precedence over “Allow log on as a service”, even in case both are configured through GPO/locally.
• In case multiple GPOs define “Log on as a service”, the final applied policy depends on Group Policy precedence and security filtering. Note that conflicts may result in accounts being removed unexpectedly from the effective policy list.
• Keep in mind that domain Group Policy overrides local security policy settings during Group Policy refresh. In case you configured SeServiceLogonRight through a domain GPO, local changes made with secpol.msc/secedit may be reverted automatically.

Granting Log on as a Service Right with PowerShell

Note that Microsoft does not provide a dedicated built-in PowerShell cmdlet to manage user rights assignments. We recommend you using secedit or LGPO-based automation in enterprise environments.

You can change the settings for the ‘Log on as a service’ policy from the PowerShell command line. Below we will use the built-in secedit.exe command to manage a computer’s local User Rights Assignment settings.

We have created three PowerShell script wrappers for the ‘secedit.exe’ tool. These can be used to check, grant, or revoke the SeServiceLogonRight for a user from the PowerShell console.

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

List the current accounts in the “Log on as a service” policy:

.\Get-ServiceLogonRight.ps1

Add a user or group to the “Log on as a service” policy:

.\Add-ServiceLogonRight.ps1 -UserOrGroup <DOMAIN\group>

Remove a user from a policy:

# Remove a local user .\Remove-ServiceLogonRight.ps1 -UserOrGroup localadmin02

Add Logon as Service Right for User from Command Line

In some cases, it may be necessary to grant SeServiceLogonRight permissions via a command prompt rather than the graphical MMC snap-in. This would be useful, for example, when managing a non-GUI Windows Server Core edition or a remote computer via CLI.

The easiest way to grant ‘Log on as a service’ permissions for a user is to use the NTRights.exe command line tool, which is part of the Windows Server 2003 Resource Toolkit. Unfortunately, the direct download link for this package has been removed from the Microsoft site, but you can still download it from WebArchive.

Keep in mind that NTRights.exe is deprecated and we don’t recommend it for modern Windows environments. You should only use it for legacy systems (where PowerShell/secedit-based methods are unavailable).

Install the Resource Toolkit on the computer and run a command prompt as an Administrator.

Navigate to the directory:

cd "C:\Program Files (x86)\Windows Resource Kits\Tools"

To grant the user CONTOSO\j.brion Log on service privileges, run the command:

ntrights +r SeServiceLogonRight -u CONTOSO\j.brion

Check that the user has been assigned rights in the Local Security Policy snap-in.

To remove a user from a policy, run:

ntrights -r SeServiceLogonRight -u CONTOSO\j.brion

Configure Windows Service to Run Under a User Account User

As we mentioned above, most Windows Services are, by default, running as a System, Network, or Local service account. Once you have granted a user the ‘Log on as a Service’ right, you can reconfigure the service to run in this user context.

1. Open the service management console (services.msc).
2. Find the service and open its properties.
3. Go to the Log on tab > select This account.
4. Select account name and type it password.
   

   

   The account svcSQL01@theitbros.local has been granted the Log On As A Service right

5. Try starting the service to check if it works correctly in the user’s context.

Note. If the SeServiceLogonRight has not yet been granted, this will also make changes to the User Rights Assignments security policy.

You can use PowerShell to reconfigure a service to run on behalf of a specific user account. The user credentials are defined directly in the script:

$account = "reslab\svcSQL01"

$credential = Get-Credential $account

$service = "name='MSSQL$SQLEXPRESS'"

$svc = Get-WmiObject Win32_Service -Filter $service

$svc.StopService()

$svc.Change(
$null,
$null,
$null,
$null,
$null,
$null,
$credential.UserName,
$credential.GetNetworkCredential().Password,
$null,
$null,
$null
)

$svc.StartService()

The example above uses the legacy WMI cmdlets available in Windows PowerShell 5.1. If you are using PowerShell 7, use the CIM cmdlets instead.

Note that you should avoid hardcoding passwords in PowerShell scripts. Instead we recommend using Get-Credential, gMSA accounts, or secure secret management solutions.

The Set-Service cmdlet in PowerShell 7.x includes the -Credential parameter, enabling interactive configuration of user credentials for running a service:

$ServiceName = 'MSSQL$SQLEXPRESS'
$creds = Get-Credential
Set-Service -Name $ServiceName -Status Stopped
Set-Service -Name $ServiceName -Credential $creds
Set-Service -Name $ServiceName -Status Running

Note that in newer PowerShell versions, Set-Service gives limited support for configuring credentials on some platforms/environments.

In order to list Windows services configured to run under accounts other than Local System, use this PowerShell command:

Get-CIMInstance -Class Win32_Service -filter "StartName != 'LocalSystem' AND NOT StartName LIKE 'NT Authority%' " | Select-Object Name, Caption, StartMode, StartName, State|ft

Troubleshooting Error 1069 (Logon Failure)

An error may occur when starting the service:

Could not start the <service name> service on Local Computer.
Error 1069: The service did not start due to a logon failure.

This can indicate that:

• Incorrect user credentials are specified
• The user account is disabled or locked out
• “Log on as a service” permissions are missing

Here are additional root causes for Error 1069:

• Expired password for service account
• Account locked due to failed logon attempts
• Missing “Deny log on as a service” override in higher priority GPO
• Service crash loop caused by dependency failure before logon validation

For traditional service accounts, you need to ensure that password rotation procedures are documented and synced with service config updates. In enterprise environments, we recommend using gMSA accounts, this will help to avoid password expiration and manual password management problems.

Note that you can audit “Log on as a service” assignments using Security event logs (Event IDs 4704/4705 depending on policy changes) and GroupPolicy Operational logs.