none
Best Practice for using GPO for "Logon as a Service" accounts

    Question

  • Having been part of 10 or more domains, I've seen this done several different ways and just wanted to get some input on what you all have landed on as a good approach.

    So at one large company, they have a root domain level GPO for global settings.  One of them is Logon as a Service and they put every single service account in that list that were known.

    I have a similar GPO for that setting and similar, but I have different GPOs and add them at the OU level where the OUs are broken out by site and or datacenter.  About 25 of them right now.

    I always felt this approach was best but after managing this set up for the last few years, I really wonder if that setting should be in a GPO at all.  Especially for large enterprises where there are segmented groups of administrators.

    The problem of course is that when you enable that policy setting, then every account needing that setting must be listed as the setting on the local security policy is grayed out.

    I suppose it makes a lot of sense in large environments where you might have dozens of servers and you don't want to micromanage each system when one policy can take care of it all.

    Anyway, I'd love some feedback.

    Friday, April 01, 2016 6:47 PM

Answers

  • > Would you mind elaborating on this set up a bit more?  You have created
    > a computer local group on your server(s). I'm assuming this group is
    > listed in the local security policy on the server?  You then have a GPP
    > defined to populate that group with service accounts.
     
    In our server default security GPO, we configure ALL security privileges
    like the following excerpt:
     
    Log on as a batch job BUILTIN\Administrators, seBatchLogonRight
    Log on as a service BUILTIN\Administrators, seServiceLogonRight
    [and so on...]
     
    This GPO applies to all computers in the domain except domain
    controllers. The groups do not exist initially, but that does not matter.
     
    In the same GPO, we create the groups and empty them out:
     
    Control Panel Settings
    Local Users and Groups
    Group (Name: seServiceLogonRight)
    seServiceLogonRight (Order: 2)
    Local Grouphide
    Action Update
    PropertiesGroup name seServiceLogonRight
    Description Allow logon as a service
    Delete all member users Enabled
    Delete all member groups Enabled
     
    So now we have a computer local group seServiceLogonRight which we
    empty. The same is true for all other local se-groups.
     
    And now we delegate GPO management on the service OUs (like SQL and IIS)
    to the people managing these services. The SQL admin simply goes ahead,
    creates a GPO and adds something like that to it:
     
    Control Panel Settings
    Local Users and Groups
    Group (Name: seServiceLogonRight)
    seServiceLogonRight (Order: 2)
    Local Grouphide
    Action Update
    PropertiesGroup name seServiceLogonRight
    Description Allow logon as a service
    Delete all member users Disabled
    Delete all member groups Disabled
    Add members %DomainName%\SQL server service account
     
    Done we are. BTW - the same we do for the local Administrators group -
    first, empty them out, then add members as required. Ok, here we
    implemented some more intelligence in the GPP - we use Item Level
    Targeting based on environment variables (we have a variable that tells
    us the server role) and WMI filters, and the global GPO adds domain
    groups matching the server or workstationrole.
     
    > Am I missing something, because it's granular but also seems like a lot
    > of work.
     
    It is not - setup your user privilege and default group member policy
    once, explain/document well and then forget about assigning privileges
    for the rest of your live.
     
    > Is there a global group for the different
    > application support groups?
     
    WE do have that, yes. We have groups en masse :-) And since we support
    170k seats in the financial business, we are required to have them.
     
    Thursday, April 07, 2016 8:14 AM

All replies

  • Hi,

    From what I know it really  makes sense to control this setting via a GPO. The reason being - ths is a best practice and a recommendation provided here: https://msdn.microsoft.com/en-us/library/cc875826.aspx

    As for your concern with manageability, it always depends on how independent departments are.

    - If OUs repreent absolutel independed structures with different rules and olicies managed by separate teams, an option to split them into separate child domains should be considered. Maintenance of those lists in GPOs can be delegated to respective teams and be out of global IT concern at all.

    - If OUs are managed by separate teams, but most of the policies are the same and they are not completely independent, then they shold be part of the same domain, but you still can use Delegate Control option and craete separate GPOs for each OU granting the "Change" permissions on them to local IT. You wil ned to have some AD change Auditor software to have control over this structure then.

    - If you have a large environment with no administrative separation (you manage everything),then havng the single list of these accounts in one top level GPO is the simplest way from the maangement and control point of view. It is also convinient as it more transparent this way.

    Regards

    Friday, April 01, 2016 7:03 PM
  • Sylvr317, I am in the same boat.  I started off using a single GPO to control "Log on as Service" accounts, but with the rapid expansion of our server-based resources, the need for app-specific service accounts has started to turn my GPO into a monster.  Yes, there are a couple service accounts that need to be on every server, but most of the others are backup/SQL/Web/App specific, and should only go on a few servers.  And like you, it has become apparent to me that while having an app-specific service account that has "Log on as service" rights on *every* server might be an easy answer, it simply can't be the best practice.

    Unfortunately, Microsoft has kept the GPM console in the dark ages.  It's functionality and usability is extremely limited.  Ideally, just about every setting in a GPO should be able to be configured for any combination of: enabled/disabled/unconfigured with locked/unlocked with (where appropriate, as with the setting in question) with replace/merge.  Currently this setting can only be used for ENABLED/DISABLED and REPLACE.  Ideally, I would like each server to have a couple GPOs that were "MERGED".  Adding this capability should be easy, and would provide a powerful management tool, enabling the right accounts on the right server in a seamless and secure fashion.

    As it is, I saw a recommendation in another thread to create a security group (the thread said a local group--I am going to test with an AD group instead) and add that group via GPO, then simply manage the members of the group.  It should be a lot easier than that, but so far, that is the best potential kluge I have heard about.


    Wednesday, April 06, 2016 3:41 PM
  • > about every setting in a GPO should be able to be configured for any
    > combination of: enabled/disabled/unconfigured with locked/unlocked with
     
    This would lead most SMB/SOHO admins into mischief and big trouble...
     
    > As it is, I saw a recommendation in another thread to create a security
    > group (the thread said a local group--I am going to test with an AD
     
    That was probably me. We used to use an AD group, but then the members
    of this group have seLogonService on all computers the GPO affects. We
    wanted a more granular solution so that the SQL service account cannot
    logon as IIS, e.g. - each team responsible for a given application can
    now use their own service accounts by simply adding them to our
    ".\seLogonService" computer local group via GPP local users and groups.
     
    Using a local group makes things easy :-)
     
    Wednesday, April 06, 2016 4:07 PM
  • Martin,

    Would you mind elaborating on this set up a bit more?  You have created a computer local group on your server(s). I'm assuming this group is listed in the local security policy on the server?  You then have a GPP defined to populate that group with service accounts.

    Am I missing something, because it's granular but also seems like a lot of work.  Why use GPP at all?  Is there a global group for the different application support groups?

    Pat

    Wednesday, April 06, 2016 5:03 PM
  • > Would you mind elaborating on this set up a bit more?  You have created
    > a computer local group on your server(s). I'm assuming this group is
    > listed in the local security policy on the server?  You then have a GPP
    > defined to populate that group with service accounts.
     
    In our server default security GPO, we configure ALL security privileges
    like the following excerpt:
     
    Log on as a batch job BUILTIN\Administrators, seBatchLogonRight
    Log on as a service BUILTIN\Administrators, seServiceLogonRight
    [and so on...]
     
    This GPO applies to all computers in the domain except domain
    controllers. The groups do not exist initially, but that does not matter.
     
    In the same GPO, we create the groups and empty them out:
     
    Control Panel Settings
    Local Users and Groups
    Group (Name: seServiceLogonRight)
    seServiceLogonRight (Order: 2)
    Local Grouphide
    Action Update
    PropertiesGroup name seServiceLogonRight
    Description Allow logon as a service
    Delete all member users Enabled
    Delete all member groups Enabled
     
    So now we have a computer local group seServiceLogonRight which we
    empty. The same is true for all other local se-groups.
     
    And now we delegate GPO management on the service OUs (like SQL and IIS)
    to the people managing these services. The SQL admin simply goes ahead,
    creates a GPO and adds something like that to it:
     
    Control Panel Settings
    Local Users and Groups
    Group (Name: seServiceLogonRight)
    seServiceLogonRight (Order: 2)
    Local Grouphide
    Action Update
    PropertiesGroup name seServiceLogonRight
    Description Allow logon as a service
    Delete all member users Disabled
    Delete all member groups Disabled
    Add members %DomainName%\SQL server service account
     
    Done we are. BTW - the same we do for the local Administrators group -
    first, empty them out, then add members as required. Ok, here we
    implemented some more intelligence in the GPP - we use Item Level
    Targeting based on environment variables (we have a variable that tells
    us the server role) and WMI filters, and the global GPO adds domain
    groups matching the server or workstationrole.
     
    > Am I missing something, because it's granular but also seems like a lot
    > of work.
     
    It is not - setup your user privilege and default group member policy
    once, explain/document well and then forget about assigning privileges
    for the rest of your live.
     
    > Is there a global group for the different
    > application support groups?
     
    WE do have that, yes. We have groups en masse :-) And since we support
    170k seats in the financial business, we are required to have them.
     
    Thursday, April 07, 2016 8:14 AM
  • I'm trying a similar approach at the moment but the sticking point is assigning the local group log on as service rights.

    How did you go about doing this?  At the moment I'm trying via GPO with Local Accounts setting "Log on as Service" which picks up builtins and domain accounts but is not picking up a local custom group.

    Did you control this via GPO or script it, maybe placing it in the build configuration?

    Friday, June 23, 2017 12:58 AM
  • > I'm trying a similar approach at the moment but the sticking point is assigning the local group log on as service rights.

    Do not use the object picker ("Browse"  button), but simply type the name into the field. This will allow you to add ambiguous "groups" to the privilege.

    Friday, June 23, 2017 9:25 AM