What does 'Log on as a Service' actually mean?
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?
Solution 1:
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.
Solution 2:
"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.