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

In Windows, you can use the “Log on as a service” Group Policy option to allow services to run under user accounts, and not in the context of a Local System, Local Service, or Network Service.

This policy allows certain accounts to start a process as a Windows service on behalf of a user. When this process starts, it is registered as a service.

The “Log on as a service” user right allows to start Windows network services that run continuously on the computer under the user account, even if no one is logged into the console of the computer (server). Also, this method allows you to safely start third-party services for which you don’t want to grant Local System privileges. It is much safer to run third-party services on behalf of non-admin user. The risk of using service accounts to run services is reduced because only local users with administrator permissions can install and configure Windows services.

Enable Logon as a Service Group Policy Option

Run the local (gpedit.msc) or domain (gpmc.msc) Group Policy Editor and go to the following GPO section: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. Find the Log on as a service policy.

Note that in Windows Server 2022, 2019, 2016, and Windows 10, the “NT SERVICE\ALL SERVICES” group is added to this policy by default.

When installing the Hyper-V role in Windows, the “NT VIRTUAL MACHINES\Virtual Machines” group (SID S-1-5-83-0) is additionally added. When installing web server IIS with the .NET Framework, then the IIS APPPOOL.NET v4.5 account is added.

Installing the IIS Web Server with .NET Framework adds the “IIS APPPOOL\.NET v4.5” and “IIS APPOOL\DefaultAppPool” accounts.

Hint. You can also change the local Logon as a service policy through Local Security Policy console. To do this, open the Windows Control Panel > Local Security Policy > Security Settings > Local Policies > User Rights Assignments (or run the secpol.msc command) and modify the policy.

Double-click on the Logon as a service policy, click the Add User or Group button and specify the account or group to which you want to grant the permissions to run Windows services.

To apply the new settings, run the gpupdate command:

gpupdate /force

Referer. Learn how to configure NTP time synchronization using Group Policy.

How to Start a Service Under a Specific Account?

Now you can start the service management console (services.msc), and try to configure the launch of any service from behalf of a user account: select service > Properties > Log on tab > Log on as > This account > select account and set a password.

A message appears:

The account .\admin has been granted the Log On As A Service right.

When using this policy, make sure that the user or group is not added to another policy called “Deny log on as a service”. In this policy, you can specify which user accounts are not allowed to run services. If the user is simultaneously added to the “Deny log on as a service” and “Logon as a service” policies, the deny policy will take precedence. Those, when the service starts, a message appears:

Services

Windows could not start the xxxx service on Local Computer.Error 1069: The service did not start due to a logon failure.

Note. Learn how to export all Group Policies to HTML report.

You can also change the account under which a particular service runs from the command line. You can activate this task using the built-in sc.exe console tool. To start the MyWallService service under the ca_srvsvc domain account, run the command:

sc.exe config "MyWallService" obj= "theitbros\ca_srvsvc" password= "userpassword5" type= own

* Where userpassword5 – is the service account password.

If you entered everything correctly, a message will appear:

[SC] ChangeServiceConfig SUCCESS.

You can also use PowerShell to set user account credentials in service settings. In this example, we will use the Service Management API via WMI (only applies to Windows PowerShell 2.x – 5.1):

$account="theitbros\ca_srvsvc"

$password="userpassword5"

$service="name=MyWallService"

$svc=gwmi win32_service -computer [computername] -filter $service

$svc.StopService()

$svc.change($null,$null,$null,$null,$null,$null,$account,$password,$null,$null,$null)

$svc.StartService()

Note that WMI allows you to change the credentials to run a service remotely. Just replace [computername] with the name of the remote computer where you want to configure the service or use a dot (.) if you want to change the credentials on the local computer.

Note. Check our fix for The processing of Group Policy failed issue.

To remotely change only the password of the account under which the service is running, use the following PowerShell script:

$svc=gwmi win32_service -computer . -filter $service

$svc.StopService()

$service.change($null,$null,$null,$null,$null,$null,$null,$password)

$svc.StartService()

The following UserAccountControl attributes are typically enabled for a service account in Active Directory:

• Password never expires.
• User cannot change password.

Hint. In modern versions of Windows Server in an Active Directory domain, it is preferable to use special types of service accounts: Managed Service Accounts (MSA, object of type msDS-ManagedServiceAccount) or Group Managed Service Accounts (gMSA, object of type msDS-GroupManagedServiceAccount). These are special types of AD objects created specifically to securely run system services, scripts, and scheduler jobs. For these service accounts, a complex password is generated in Active Directory and automatically changed every 30 days (by default). Such service accounts can independently change their passwords in Active Directory. In this case, the password is not stored on the local computer (cannot be retrieved from LSAS process), it cannot be used for interactive login, and the secure Kerberos protocol is used for authentication (Getting Started with Group Managed Service Accounts).

It is advisable to minimize the number of user accounts to which you grant the “Logon as a service” permissions. To minimize security risks, you should disable interactive and remote interactive sessions for service accounts. This is often described in best practices.