Gaining Group Control

You know how the story goes—power users don't like domain administrators to control their computers, so they remove any domain administrative groups from their local groups. This is a common ploy of administrative staff too, to kick out other domain administrators
from any local groups on their personal computers.

"So what's the problem?" you may ask. The problem lies with control over a
computer that is part of an Active Directory domain. If the Domain Admins group
isn't a member of the local Administrators group on a computer, then administrative
staff have no immediate control over that computer. Similarly, other groups
and users might need to have membership in the local Administrators group on
each computer—to update applications remotely, install security updates
or obtain documentation information for the system.

Never fear, Group Policy is here! Group Policy Objects (GPOs) provide a solution
for controlling groups, especially local groups, on any computer in the AD domain.
The solution is to use Restricted Groups. Restricted Groups gives you two options
for controlling the membership of groups, enabling you to ensure that the Domain
Admins group has membership in the local Administrators group on every computer
in the domain. The settings for Restricted Groups is located under the Computer
Configuration | WindowsSettings | Security Settings.

Tip
Box

Don't create a policy to configure
the members of a group in two different GPOs. This won't merge
the GPOs together—it will only take the last GPO configured.
If a GPO at the domain level states that Group1 should have
Group2 as a member and a GPO at the OU level states that Group1
should have Group3 as a member, only Group3 will be a member
when the GPOs finish applying to the computer.

Following are the two settings for every group listed under Restricted Groups
in a GPO.

Members of this group. This setting provides a text box for you to enter all members of the group, including user and group accounts from the local computer or from a domain. This setting doesn't append to the existing user and group accounts that have membership in the group. Instead, it first removes any account in the group, then adds the new list. If the policy is implemented and the list is blank, it will leave the group without any members.

This group is a member of. This setting provides a text box for you to enter all groups in which the specified group should have membership. The groups listed must meet the group nesting rules for the domain functional level you're working with, as well as standard group nesting rules. For example, you can't configure a local group to have membership in a global group. In addition, configuring this option won't remove current memberships for the group; it will just create additional memberships. If the policy is implemented and the list is blank, it will leave the current group memberships in place, and not provide any additional memberships.

When configuring the settings in the Restricted Groups, consider these tips:

Use one or the other of the above two settings across all GPOs, not both. For example, one GPO might say to make Group1 a member of Group2, but a different GPO states that Group2 should only have members including Group2. This causes a conflicting setting, which will most likely result in Group1 not having membership in Group2.

Link GPOs that use the Restricted Groups policy to OUs that contain only the target computer accounts. If the GPO is designed for clients, but configures servers, the server services might fail.

Type in the group name if you need to refer to a local group. For example, if you need to input the Power Users group, you will need to type it in, since you might not be able to browse for it.

If you need to refer to a domain that you don't have access to from the browser option, use the following syntax: \. With real names, it might look something like this: braincore\derekm.

Be mindful that pre-SP4 Windows 2000 domain controllers have a bug associated with leaving the Members section blank. For more information, refer to Knowledge Base article 810076.

Controlling local groups has never been so easy and powerful.

About the Author

Derek Melber (MCSE, MVP, CISM) is president of BrainCore.Net AZ, Inc., as well as an independent consultant and speaker, as well as author of many IT books. Derek educates and evangelizes Microsoft technology, focusing on Active Directory, Group Policy, security and desktop management. As one of only 8 MVPs in the world on Group Policy, Derek’s company is often called upon to develop end-to-end solutions regarding Group Policy for companies. Derek is the author of the The Group Policy Resource Kit by MSPress, which is the defacto book on the subject.