How To Add Local User To Domain Group Policy Log On As A Service

In Windows, y'all tin use the "Log on as a service" Group Policy selection to allow services to run under user accounts, and not in the context of a Local Arrangement, Local Service, or Network Service.

This policy allows certain accounts to start a process every bit 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 beginning Windows network services that run continuously on the computer under the user account, fifty-fifty if no i is logged into the console of the computer (server). Also, this method allows yous to safely start 3rd-party services for which you don't want to grant Local System privileges. It is much safer to run third-political party services on behalf of non-admin user. The risk of using service accounts to run services is reduced because but local users with administrator permissions tin install and configure Windows services.

Enable Logon as a Service Group Policy Choice

Run the local (gpedit.msc) or domain (gpmc.msc) Grouping Policy Editor and go to the following GPO department: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Consignment. Find the Log on equally 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 office 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 .Internet Framework, then the IIS APPPOOL.NET v4.five account is added.

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

Hint. Y'all can also change the local Logon as a service policy through Local Security Policy panel. To do this, open up 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 Grouping button and specify the account or group to which you desire to grant the permissions to run Windows services.

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

gpupdate /force

How to Commencement a Service Under a Specific Business relationship?

At present you tin can start the service management panel (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 business relationship and set a password.

A bulletin appears:

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

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, y'all tin specify which user accounts are not allowed to run services. If the user is simultaneously added to the "Deny log on equally a service" and "Logon equally a service" policies, the deny policy will take precedence. Those, when the service starts, a bulletin appears:

Services

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

Y'all tin can also modify the business relationship under which a particular service runs from the command line. Yous can actuate this task using the congenital-in sc.exe console tool. To offset 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 business relationship password.

If you entered everything correctly, a bulletin will appear:

[SC] ChangeServiceConfig SUCCESS.

You can too utilise PowerShell to set user business relationship credentials in service settings. In this example, we will use the Service Management API via WMI (only applies to Windows PowerShell 2.x – v.1):

$account="theitbros\ca_srvsvc"  $countersign="userpassword5"  $service="name=MyWallService"  $svc=gwmi win32_service -computer [computername] -filter $service  $svc.StopService()  $svc.change($goose egg,$zip,$null,$nix,$nix,$naught,$business relationship,$password,$null,$null,$zip)  $svc.StartService()

Note that WMI allows yous to change the credentials to run a service remotely. Simply replace [computername] with the name of the remote reckoner where yous 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($naught,$nix,$zero,$null,$null,$null,$null,$password)  $svc.StartService()

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

Password never expires.
User cannot change countersign.

Hint. In modern versions of Windows Server in an Agile Directory domain, information technology is preferable to employ special types of service accounts: Managed Service Accounts (MSA, object of type msDS-ManagedServiceAccount) or Grouping Managed Service Accounts (gMSA, object of type msDS-GroupManagedServiceAccount). These are special types of Ad objects created specifically to securely run organisation services, scripts, and scheduler jobs. For these service accounts, a complex password is generated in Active Directory and automatically changed every thirty days (past 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 hallmark (Getting Started with Grouping Managed Service Accounts).

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

Author
Recent Posts

I enjoy engineering science and developing websites. Since 2012 I'k running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.