What are Restricted Groups?

The Restricted Groups security setting in Group Policy allows an administrator to define two properties for security-sensitive groups (“restricted” groups). The two properties are Members and Member Of. In short it lets an Administrator decide which security principals are members of a restricted group, and which groups the restricted group is a member of. The Restricted Groups security setting can be found under Computer Configuration\Windows Settings\Security Settings\Restricted Groups in any Domain based GPO. The Members section enforces the membership of a group. Any existing members of the restricted group are removed and only the security principals listed in the Members section are members of the restricted group. Conversely, the Member Of section simply ensures that the restricted group is added to the groups listed in Member Of. It does not remove the group from other groups of which it is a member. This means that if you use the Members section; only the security principals you select will be members of a restricted group, all existing members of the group will be removed. If you use the Member Ofsection your group is only added to the restricted group.

Let’s say you want to add the domain group Domain Users to the local Administrators group on a set of computers. With Restricted Groups there are two approaches; using the Members section or using the Member Ofsection. In the first case, the restricted group is Administrators, and we add Domain Users as a member.

Figure 1: Using the Members section of Restricted Groups

When using the Memberssection like this, all existing members of the Administrators group will be removed for all computers where this policy is applied.

In the second case the Restricted Group is Domain Users, and we specify that it should be a member of Administrators.

Figure 2: Using the Member Of section of restricted Groups

When using the Member Ofsection like this, the existing membership of the Administrators group is preserved and Domain Users is simply added on all computers where this policy is applied.

In either case your policy should be linked to an OU where the computers on which you want the policy applied are located.

GptTmpl.inf

The Restricted Groups information, along with every other setting under the Security Settings container in a GPO, is stored in an INF file called GptTmpl.inf. Each GPO with security settings has one GptTmpl.inf file and its path is always:

%systemroot%\SYSVOL\sysvol\<DNS domain name>\Policies\<GUID of GPO>\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

The section where the Restricted Groups info is stored is called Group Membership.

[Unicode]
Unicode=yes
[Version]
signature=”$CHICAGO$”
Revision=1
[Group Membership]
*S-1-5-21-12345678-123456789-123456789-513__Memberof = *S-1-5-32-544
*S-1-5-21-12345678-123456789-123456789-513__Members =
*S-1-5-32-544__Memberof =
*S-1-5-32-544__Members = *S-1-5-21-12345678-123456789-123456789-513

Figure 3: Example GptTmpl.inf file

Notice that all the groups we selected in the interface have been resolved to SIDs and that those SIDs are prepended with an asterisk (*) character. This is important as we will see later.

Group Names and SIDs in Restricted Groups (to resolve, or not to resolve)

The problem with the Restricted Groups interface is that it allows you to either browse for a group name or enter one manually. It is very important to understand what happens in each case. If you browse; the SID of the group you selected will end up in the INF file in the policy. If you enter a name manually; the name ends up in the INF file.

[Unicode]
Unicode=yes
[Version]
signature=”$CHICAGO$”
Revision=1
[Group Membership]
*S-1-5-21-12345678-123456789-123456789-513__Memberof = Another Example Group,*S-1-5-32-544
*S-1-5-21-12345678-123456789-123456789-513__Members =
Manually Entered Group Name__Memberof =
Manually Entered Group Name__Members = *S-1-5-21-12345678-123456789-123456789-513,Another Example Group

Figure 4: Example GptTmpl.inf file demonstrating the difference between entering names manually and browsing

I this example GptTmpl.inf file we see this difference clearly. The group *S-1-5-21-12345678-123456789-123456789-513 (Domain Users) is resolved and has therefore been browsed for. Of its members one, Another Example Group, has been entered manually and the other, *S-1-5-32-544, has been browsed for. The group Manually Entered Group Name has been manually entered and of its members, one has been browsed for, *S-1-5-21-12345678-123456789-123456789-513, and the other, Another Example Group, has been manually entered.

Manually entered names, of either groups or users, are only valid if the computer applying the policy can resolve them. If you want to control the membership of the local Administrators group on computers and enter the name Administrators manually into the Restricted Groups interface; your policy will only work on computers where the local Administrators group is named exactly Administrators (not case-sensitive). Meaning that if the computer applying the policy is running a localized version of Windows, the policy will fail, because the Administrators group is not named Administrators, but has had its name translated into whatever language is running on the computer. In this scenario it is better to use well-known SIDs in Restricted Groups to guarantee that the policy works on all versions of Windows.

What are well-known SIDs and how to make sure you use them correctly in Restricted Groups?

A security identifier (SID) is a unique value of variable length that is used to identify a security principal or security group in Windows operating systems. Well-known SIDs are a group of SIDs that identify generic users or generic groups. Their values remain constant across all operating systems. A list of all well-known SIDs is available here:

Well-known security identifiers in Windows operating systems
http://support.microsoft.com/kb/243330

If you want to use a well-known SID in a Restricted Groups policy you must edit the policy on a machine that has access to that group and use the browse button to select it. As we have seen, browsing for a group guarantees that it is resolved to its actual SID, but to be able to browse for a group we must be on a machine that can see that group. Fortunately this is not a hard requirement to meet. For example, the SIDs of all default groups that exist both on domain member machines and on domain controllers, are the same. The SID of the local Administrators group and the Administrators group in an Active Directory domain is the same (S-1-5-32-544). The problem emerges when you edit the policy on a machine that can’t browse to the group you want. E.g. if you want to control the membership of the Power Users group on Windows workstations and you are editing the policy from a domain controller (which does not have a Power Users group). If you find yourself in this situation and decide to manually enter the name of the group; that policy will only work on machines where the local Security Accounts Manager (SAM) database contains a group with the exact same name you entered.

If you apply the policy to a machine with a localized version of Windows your policy will fail and the winlogon.log (%windir%\security\logs\winlogon.log) will report error 1332 (0x534) No mapping between account names and security IDs was done. This happens because the groups on that machine have names in the language of the version of Windows it is running. E.g. a German version of Windows XP will not have a local group named Administrators; instead it will be called Administratoren.

To work around this you can edit the policy on a machine that can browse to the group you want. Or you can manually edit the GptTmpl.inf file and add the well-known SID of the group you want. Follow the syntax in the examples above and remember the asterisk. You do not have to enter the members or which other groups that group should be a member of. You can do that in the Restricted Groups interface later. Any members you choose to enter can be either SIDs or group or user names (or computer names). They must be comma separated and groups containing spaces do not require brackets (“).

After the well-known SID is present in the policy you can edit it anywhere you like, but note that if that group is not present on the machine you are editing on; only the SID will be displayed. The policy works regardless.

Figure 5: Editing a group that is not resolvable on the local machine (in this case Power Users on a Domain Controller)

So what about entering the SIDs directly into the Restricted Groups interface? That would be nice so we don’t have to edit the GptTmpl.inf file or get another machine to edit the policy on.

Remember that Windows is built so that whenever you want to enter a raw SID it has to be preceded by an asterisk character (*). Trying to enter that in the restricted Groups interface fails.

Figure 6: Trying to enter a raw SID in the Restricted Groups interface

So your only option is editing GptTmpl.inf or editing the policy on a machine where you can browse to the group.

Importing

If you already have a nice security template (inf) file ready with the SIDs and membership information you want ready, you can import it directly into a policy. Any settings you have in the template that are already present in the policy will be overwritten.

Figure 7: Importing a template into a policy

This feature is very handy if you have groups with large membership lists and do not fancy adding them all manually again. Also, every other setting under the Security Settings container can be stored in security templates (inf), so they can be easily moved between servers and domains. Notice also that the Export policy option is grayed out on all domain based GPOs. It is, however, available when editing a local GPO. You can also use the Security Configuration and Analysis snap-in to create a security policy, export it, and then import it into a domain based GPO.