Manage Learn to apply best practices and optimize your operations.

Using Group Policy settings to secure local admin groups on your desktops

Controlling local admin group memberships with Group Policy settings is relatively easy -- but you need to proceed with caution to avoid disastrous errors.

Granting users local administrative access to their desktop computers is a bad idea from a security standpoint....

These permissions give users free rein over their desktops, allowing them to modify system settings and install unauthorized applications. Until recently, this practice was the norm at many organizations. Administrators often had little choice in the matter, since many older apps would not run without administrative access.

While there are several ways to regulate group memberships, the easiest method is to use Group Policy settings. However, this can only be done if your desktops are domain members and you have at least one domain controller (DC) running Windows Server 2008 or Windows Server 2008 R2.

How to control group membership
From the Windows Server 2008 or higher DC, open the Group Policy Management Editor. Next, open a Group Policy that applies to the users within your domain, and navigate through the editor's console tree to User Configuration | Preferences | Control Panel Settings | Local Users and Groups. Right-click on the Local Users and Groups container, and choose the New | Local Group options from the shortcut menus, as shown in Figure 1.

Figure 1: Select New and then Local Group from the shortcut menus (click to enlarge)
Select New then Local Group from the shortcut menus

Windows will display the New Local Group Properties sheet, shown in Figure 2.

Note: Using this sheet incorrectly can severely damage your desktop operating system. Make sure you understand the consequences of your actions before using it.

Figure 2: Learn how the New Local Group Properties sheet works before using it (click to enlarge)
Select New then Local Group from the shortcut menus

The Action dropdown list applies the specified action to the group as a whole -- not to group members. In other words, if you choose the Delete action, you will delete the specified group, not the members within the group.

Here is a summary of what each of the four actions do:

  • Create: Creates a new local group
  • Delete: Deletes an existing local group
  • Replace: Deletes an existing local group, and then creates a new local group with the same name
  • Update: Modifies an existing local group

These options may not seem overly destructive at first, but remember that each local group has a unique security identifier (SID). If you delete and then manually recreate a local group, the new group's SID will be different from the one previously used. The same is true of the Replace option. Changing a group's SID can have serious consequences.

Therefore, to modify a group's membership, you must use the Update action . After selecting this action, select the Administrators group from the Group name dropdown list, as shown in the figure above.

Modifying a group's membership
Now you're ready to modify the group's membership. Use the Add button to specify user and group names. After names are added to the Members list, you can choose if they should be added to the group or removed from the group, as shown in Figure 3.

Figure 3: Add lets you add users to -- or remove users from -- the local group
Select new then local group from the shortcut menus

In addition, there are a series of radio buttons and check boxes above the Members list that you can use to quickly clear out the group's current membership. However, exercise extreme caution because it's easy to make a mistake.

Before implementing a large-scale lockdown of the local administrative groups, it's important to make sure this is a viable option for your organization. Controlling local group memberships with Group Policy settings is relatively easy -- but you must avoid disastrous errors.

Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO at a nationwide chain of hospitals and health care facilities and was once a network administrator for Fort Knox. You can visit his personal website at

Dig Deeper on Unified endpoint management