Having spoken with customers and techies from the community I’ve been surprised as to a number of misconceptions around the Group Policy Restricted Groups security setting. This isn’t all the surprising I guess as the documentation is a little confusing and possible misleading. I’m going to try and set the record straight here. First off, we’ll start with a little background.
Having spoken with customers and techies from the community I’ve been surprised as to a number of misconceptions around the Group Policy Restricted Groups security setting. This isn’t all the surprising I guess as the documentation is a little confusing and possible misleading. I’m going to try and set the record straight here. First off, we’ll start with a little background.
What, exactly, is restricted groups?
Restricted groups is a security setting that is configured via domain-based group policy (as opposed to local group policy). You add a group and then configure either one or both of the two properties available to you: member and member of.
- "Member" (labelled in the UI as “Members of this group”) is a way of mandating strict membership of the defined group. This means that any security principals added to the list of members are the only members of that group. Any other current members, configured outside of this policy, are removed.
- "Member of" (labelled in the UI as “This group is a member of”) is a way of appending the membership of the defined group. This means that any security principals added to the member of list are added to the group without affecting the existing members. It does not have anything to do with the memberOf [back-link] attribute that you’ll find on security principals in Active Directory (this isn’t really designed to be applied to domain-based groups but can, of course).
Let’s further clarify those points with two reasonably well known examples. Firstly, you have an OU that contains a bunch of workstations and you’re concerned that users, through access to the local administrators account, have manipulated the membership of the [local] administrators group, e.g. adding their domain account so that they have local administrator access on their workstation. Such practices invalidate your security policy so you want to set it right. This is where the “member” property of the restricted groups security setting comes into play. You can create and link a GPO (or modify an existing one) to this OU and add the administrators group to the restricted groups portion of the Group Policy Editor (you need to ensure that the name of the domain, followed by a slash, isn’t pre-pended to the name to ensure it’s the local administrator account that we’re referencing). You can then define the membership by adding the domain admins group (DOMAIN-NAME\Domain Admins) to the “member” portion of the UI and closing the editor. When the workstations within scope of this GPO next refresh their policy the membership of the local administrators group will be reset to the [local] Administrator account as well as the groups that you defined in the “member” property which, in our case, is Domain Admins.
A second example is that you need to grant some users and service accounts administrative rights to all workstations in the domain, but not the servers, e.g. a desktop administrators group and maybe a group for the systems management software that manages workstations. In this case you don’t wish to reset the membership of the groups that you want to change (again, the administrators) for obvious reason. To achieve this setting you use the “member of” property of restricted groups and not the “member” property. Whereas the “member” property enforces the defined membership by erasing the current settings and only applies those defined in the GPO, the “member of” property simply appends the security principals defined in the GPO to the existing group. Therefore, assuming you make this change in a GPO that is scoped such that it only applies to computers (perhaps via security filtering, OU or WQL) the result will be that the security principal you add to the “member of” property, e.g. DOMAIN-NAME\Desktop Admins, is added to the existing membership of Administrators on all machines within scope.
The first example can also go horribly wrong when the person configuring the GPO intended to achieve that of example two but used the “member” property as opposed to the “member of” property. This brings me to the purpose of this blog – the behaviour changes between Windows 2000 and Windows XP and Server 2003 and Server 2008 or, more specifically, the service packs. Let me explain using an example that possibly more of the readers of this blog would like to admit they have seen:
A security principal, for the sake of example DOMAIN-NAME\Desktop Admins, is added to the Administrators group via the “member” property of a GPOs Restricted Groups security setting. The reason is that the person configuring the change is thinking about the relationship of member and memberOf in relation to an Active Directory security principal. Regardless, the change is made and the GPO applies to every machine (for the sake of the example we’ll control the extent of the damage to an OU at 1830 on a Thursday) in the “South” OU. Wide-scale damage isn’t picked up immediately at 0800 on the Friday because it’s early in the day and the desktop support guys haven’t started making administrative changes to PCs yet, however sever support realise that during the night the backups of all servers in the “South” OU failed with access denied errors. The reason? The only members of the Builtin Administrators group on all computer objects in the OU now contain the following:
|
Operating System and Service Pack
|
Builtin\Administrators membership
|
|
Windows 2000 Professional RTM, SP1, SP2 & SP3
|
DOMAIN-NAME\Desktop Admins
|
|
Windows 2000 Server RTM, SP1, SP2 & SP3
|
DOMAIN-NAME\Desktop Admins
|
|
Windows XP Professional RTM, SP1
|
DOMAIN-NAME\Desktop Admins
|
|
Windows 2000 Professional SP4
|
Administrator; DOMAIN-NAME\Desktop Admins
|
|
Windows 2000 Server SP4
|
Administrator; DOMAIN-NAME\Desktop Admins
|
|
Windows XP Professional SP2
|
Administrator; DOMAIN-NAME\Desktop Admins
|
|
Windows Server 2003 RTM
|
Administrator; DOMAIN-NAME\Desktop Admins
|
|
Windows Server 2008 RTM
|
Administrator; DOMAIN-NAME\Desktop Admins
|
Notice the difference that Windows 2000 Service Pack 4 and Windows XP Service Pack 2 bring to the table. The security policy (SCECLI) client side extension (CSE) has been revised in the code stream that applies to Windows 2000 SP4, XP SP2 and 2003 RTM and beyond has been modified to always ensure that the Administrator group is maintained as a member of the group. And that’s not all, restricted groups now supports rollback.
Automatic rollback of restricted groups settings
If you ever deployed restricted groups, using the member property, in Windows 2000 (pre-SP4) you’ll probably have noticed that when you move a machine out of scope of the GPO that contains the settings the effects of the restricted groups settings stay the same. This caused a number of Microsoft customers major problems, mainly around the above example (an erroneous configuration due to poor change control). This explains the two pretty major changes: administrator remains, regardless, and falling out of scope now results in the group membership reverting to its previous state. The underlying mechanics of this can be saved for another day, suffice to say that the settings are written to a Jet database (secedit.sdb).
Summary
So, what am I telling you all in all?
- The “member” portion of a GPOs restricted groups policy mandates, or enforces, the membership of the group.
- The “member of” portion of a GPOs restricted groups policy appends security principals to the existing membership of the group
- All current supported version of the Windows operating system that are capable of processing restricted groups policy are able to revert to the previous settings when they are no longer in scope of a restricted groups policy.
|
