8

I am building Group Policy for a new domain that we are migrating to. In our current environment the settings Log on as a Service is set at the Server OU level - which has about a hundred Service Accounts in that field for having access to this right.

I would like to set this lower down our OU tree structure (we separate out servers based on the application that they run), but a couple of our internal staff have want to not set this policy at all. IE: not checking the setting in Group Policy and let the local servers deal with what accounts are put into its local policy for this setting. Our internal security team want it set as I do, but the couple of people who don't want it set includes an Architect - hence the conflict.

I have consulted with Microsoft Premier Support (who didn't have an official answer for me), internal staff, external IT friend staff, and hours of internet research - but I cannot find any information on if this policy should be set at all. My instincts are to manage this via GPO so that it can be easily audited and managed from one place (our company goes through various external audits from time to time).

The Microsoft resource page: https://technet.microsoft.com/en-us/library/dn221981.aspx is about the only information I can find about it, but it says to minimize the number of accounts that are granted this user right. This seems a bit ambiguous to me...

Can someone please tell me what they think about this settings?

1
  • Thank you. This is matches all the research that I can find - I'm not sure why someone managing a fleet of servers would not want to set this policy via GPO. It just requires application support knowledge that the vendors should be providing. Thank you all for your comments.
    – The Woo
    Apr 19, 2016 at 0:33

2 Answers 2

4

The article you linked provides an explanation of what rights Log on as a Service provides:

The Log on as a service user right allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console.

In short, you only want to provide this right to the accounts that need it - by default, that's the Local System, Local Service and Network Service accounts, because those are what services run under by default.

If you wish to run a service under a different security context (like a service account you create), you would want to grant that service account Log on as a Service rights so that it could run your service without the need for a user to be logged in. The article you link provides IIS and ASP.NET as examples where additional accounts are granted this right; it applies to third-party programs that run as services as well.

If you don't want to you run every service as SYSTEM or NetworkService, you would setup service accounts for individual services and assign them this Log on as a Service right. The main advantage of using service accounts in this way is that if your service is compromised, it's running under the security context of the account running it, rather than the SYSTEM-level security context that SYSTEM and NetworkService have.

So, the best practice is to assign this right only to accounts that services run under, and to run individual services under service accounts that are configured according to principle of least privilege (only give them permissions they need to run; don't give them admin or SYSTEM privileges). I would add that controlling this by GPO is the more secure approach. If it's controlled locally on each server, then anyone who gets Administrative rights on a server can control what accounts can run services on that server, whereas enforcing it via GPO requires getting the appropriate domain rights at a domain level.

1
  • 1
    I would like to add to this answer that in practice, this often means reviewing vendor documentation for privileges. As applications generally set up these permissions during installation, and might not always be transparent when it comes to what permissions they are lacking. As an example, SQL Server grants all but one of its possibly ten accounts log on as a service, and with the GPO this means adding those ten accounts to the GPO. (Or better yet, a security group added to the GPO containing the service accounts)
    – Reaces
    Apr 18, 2016 at 6:36
1

"This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers. By default, no accounts have the privilege to log on as a service."

https://technet.microsoft.com/en-us/library/cc957141.aspx

Accounts that aren't in that list shouldn't be able to log in as a service, so if you clear the list, your services with service accounts shouldn't be able to start anymore.

I tend to create a service account group and put that into the policy. It reduces the number of times I need to make changes to the policy itself. And, as you said, it's way easier to audit than letting it get set server to server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .