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.

logon as a service gpo

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.

log on as a service gpo

To apply the new settings, run the Group Policy update command:

gpupdate /force

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.

gpo logon as a service

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.

gpo log on as a service

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.

logon as a service group policy

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.

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.

group policy logon as a service

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.

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.
Latest posts by Cyril Kardashevsky (see all)

3 comments

  1. It should really be noted that by creating a GPO, all existing entries in the “Log on as a service” policy will get overwritten with whatever is in the group policy. If you have SQL servers, or other servers that use service accounts that have already installed software/apps, those will be removed in place of what is in your group policy.

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

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

Leave a Reply

Your email address will not be published.

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