Managing local groups with Group Policy

Posted: April 11, 2011 in Group Policy, Security

 

Local group membership is used to manage access for a variety of reasons. Applications leverage local groups for access to system resources. Protective systems and support staff also require specific privileges that are granted using local groups.  The need to manage membership of these groups becomes an important goal in order to meet business objectives in the areas of security, manageability and availability.

The most typical need that comes up is the need to manage membership of the local Administrators group. This high privilege group that in many cases includes the ‘Domain Users’ group is now a potential security problem and needs to be restricted to protect the system. Often the desired membership is limited to the user who ‘owns’ the system along with support personnel and locked down otherwise to reduce the ability of malicious individuals and code to compromise the system.

My example and discussion will focus on the need to control the local Administrators group but most of the points will apply to other scenarios as well.

Group policy offers several approaches to meeting this goal and of course, they each work well in different scenarios. Let’s dig into the options and when they should be used or avoided.

Restricted Groups

The first mechanism I’m going to cover has been around in Group Policy for many years but is still frequently misunderstood.

The restricted groups configuration node can be found under Computer Configuration\Policies\Windows Settings\Security Settings\Restricted Groups. The component is configured by adding a group (you can either browse or type in a group name) and then configuring the members of the group or the groups this group is a member of.

This mechanism has one very important nuance (important enough to keep someone from getting fired!). If the group membership is controlled (using the top part of the configuration dialog), the existing group membership will be replaced by the configuration. This means that potentially important existing security principals are removed, that maintaining exceptions for specific machines is complex and that using multiple GPOs to configure this mechanism in a cumulative manner isn’t possible.

As a result, controlling group membership directly is rare and typically only used in environments where complete control is required and no further modification to the group’s membership is needed or anticipated.

The lower half of the configuration dialog, or the indirect configuration method, are much more useful in my experience. The behavior of this component is cumulative so any configuration changes are added to existing group membership.

Leveraging restricted groups to manage the Administrators group will therefore involve the following steps:

  • Create an AD group to contain privileged accounts that will be added to the local Administrators group
  • Create a GPO for local group management
  • Add the AD group created to the restricted groups interface
  • Add the local administrators group to the AD group configuration within restricted groups using the bottom, or ‘Member of’, section
  • Refresh the policy

Using this approach, a single GPO can contain multiple restricted groups entries and would manage local group membership for a collection of systems. This allows a decent level of basic local group management but it does leave a taste that something easier to use, more powerful and more flexible should be available these days. This is where group policy preferences come in…..

Local Users and Groups Extension

The introduction of group policy preferences (GPPs) with Windows Server 2008/Vista brought a whole new mechanism to manage local groups (and users). GPPs provide an extension to manage local users and groups that provides a lot of control and flexibility. Let ‘s take a look at what is possible:

First, the extension exists under both the user and computer configuration nodes under Preferences\Control Panel Settings\Local Users and Groups with some benefits to the user section that will be discussed below. Note that when using the user configuration section, the extension can be configured to be limited by the permissions of the user by selecting ‘Run in logged-on user’s security context’ on the Common tab.

Once the extension is selected and a new group is added, the administrator can use the interface to rename the group, remove existing users and groups from the membership list and add or remove specific security principals to/from the group’s membership.

In addition to these operations, the extension takes advantage of common (and powerful) GPP features like ‘Apply once’, item-level targeting and policy actions such as update/replace/create/delete  (which allows removal of a group or user account).

Another great features is available when using the user configuration version of the extension which can automatically manage membership for the ‘current user’ through the GPO making it easy to add the local user only to a local group.

In my opinion, all local user and group membership administration should be performed using GPPs and the Local Users and Groups extension. The improved interface, granular control and benefit of GPP mechanisms makes this the ideal choice for the task.

For more information about GPPs and what they require, check out my previous blog post: https://rdpfiles.com/2009/11/13/group-policy-preferences-aka-gpps-2/.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s