Managing Group Membership via Group Policy - Part 1

In yesterday's post I covered one of the Group Policy objects that I use in the "Jameson Datacenter" (a.k.a. my home lab), specifically one that automatically enables Remote Desktop (Terminal Services) whenever I add a new server to my Active Directory domain. This post introduces a Group Policy object that enforces group membership on a specific set of servers.

To understand the value of this kind of Group Policy, consider a scenario where you have a Development organization that manages its own Development Integration Environment (DEV). Standard operating procedures state that certain individuals within the Development organization -- say, for example, the team leads -- are given full administrative access to the servers in this environment. These individuals are members of the Development Admins domain group. In order to avoid having to explicitly add this domain group to the local Administrators group on each server in DEV, you can instead manage the group membership through Group Policy. Thus, whenever the Development team "spins up" a new server for their environment, all of the Development team leads are granted administrative access as soon as the server is joined to the domain.

To address this scenario in the "Jameson Datacenter", I have defined a Group Policy (named Development - Restricted Groups Policy) with the following settings:

• Computer Configuration
  • Policies
    • Windows Settings
      • Security Settings
        • Restricted Groups
          • Group Name: Administrators
          • Members: TECHTOOLBOX\Development Admins, TECHTOOLBOX\Domain Admins

By linking this Group Policy to the appropriate OU (i.e. Development/Resources/Servers) the members of the local Administrators group are automatically configured as soon as I join a new DEV server to the domain and reboot.

See Part 2 of this post for an alternate method of managing group membership through Group Policy.