I have a case where a developer computer is in a environment where the IT department have set up a forced group policy for the user rights assignment policy "Log on as a service". The policy is set to be forced and not editable and therefore replaces the local settings totally.

As this is a development computer with SQL Server Developer Edition installed and a running IIS, this user right is used by both the default SQL Server accounts as well as the virtual accounts for the applications pools (which av dynamically added/removed to/from this user right when an application pool is added or removed). Without the SQL Server service account added to this user right, the SQL Server will not even start.

Personally I find it strange to have a forced GPO that prohibits default behaviour for a local user right. The IT department have added a bunch of admin service groups as well as a bunch of special user groups that seems to have been added as a workaround for other developer departments in the organization. Purely security wise I also question why other development departments should get the access "Log on as a service" on my computer when they really just want that access to their local computers.


  1. Is it possible to deploy a GPO in way so it only adds the server settings to the local settings instead of replaces them?

  2. Is is possible to deploy a GPO and still let it be editable by the local user?

  3. Is possible to deploy the GPO in any other way so it doesn't affect the local settings?

  4. Would it work with a workaround where a user group is added to the server GPO and where the local admin on the developer machine has access to administrate and add local service accounts to this group?

  5. Would the method in no 4 work with the virtual accounts from the Application Pool or do they need to have direct access to the user right instead of implicitly through a user group?

  6. What is best practices regarding GPO's for the user right "Log on as a service"? Spontaniously it seems strange to handle the user right the way it is done by this IT department.


Developer Machine: Windows 8.1 Enterprise Eng

AD Server: domainControllerFunctionality: 5 = ( WIN2012 ); domainFunctionality: 4 = ( WIN2008R2 ); forestFunctionality: 4 = ( WIN2008R2 );

Don't know if this indicates a Win2008R2 or Win2012-server.

Would really appreciate both detailed information about what's possible when it comes to GPO deployment as well as best practices and creative solutions of the specific problem!

| improve this question | | | | |
  • You can use the GPO Preferences node instead of the Policies node to set GPOs which may be customised at the target computer. If the preference is set to replace, any customisations will be lost at next update however (and some other info you can get from the gpmc built in help file). – ErikE Sep 20 '15 at 6:46

Every GPO is "forced".

The answer to 1 to 3 is a resounding NO.

In this case, I'd ask them to create users for the SQL Server services. Those users should be added to the the group allowed to run as a service, then configure the local SQL machine to run using those credentials.

Microsoft has a Threats and Countermeasures guide. Look it up. I'll paste it here. I'm on mobile so forgive me for not formatting it properly.

Log on as a service

This policy setting determines which service accounts can register a process as a service. In Windows Server 2008 R2 and Windows 7, only the Network Service account has this right by default. Any service that runs under a separate user account must be assigned this user right.

Possible values: User-defined list of accounts / Not Defined Vulnerability

Vulnerability: Log on as a service allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. The risk is reduced by the fact that only users with administrative privileges can install and configure services. An attacker who has already attained that level of access could configure the service to run with the Local System account.

Countermeasure: By definition, the Network Service account has the Log on as a service user right. This right is not granted through the Group Policy setting. You should minimize the number of other accounts that are granted this user right.

Potential impact: On most computers, restricting the Log on as a service user right to the Local System, Local Service, and Network Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed optional components such as ASP.NET or IIS, you may need to assign the Log on as a service user right to additional accounts that are required by those components. IIS requires that this user right be explicitly granted to the ASPNET user account.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.