Working with Group Policy Restricted Groups policies

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.


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.

[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.

[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

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.


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.

Exchange 2007 Anti-Spam updates and the Automatic Updates client

Exchange 2007 uses the Windows Operating System Automatic Updates Client as a proxy to download it’s anti-spam signatures and reputation lists. The Exchange component responsible for this is the Microsoft Exchange Anti-spam Update service (witht he somewhat confusing description The Microsoft Forefront Security for Exchange Server anti-spam update service.) This service is referred to in the Exchange documentation as the Microsoft Forefront Security for Exchange Server Anti-spam Update service, again, somewhat misleading. The content retreived by the service is data only, no executable binaries are downloaded.
To configure how Exchange gets it’s updates you use the Enable-Antispamupdates cmdlet. This cmdlet has a parameter called -MicrosoftUpdate which can opt the computer in to Microsoft Update and also set the mode of how updates are retreived. The mode set through this cmdlet applies to all content from MU, not just Anti-spam updates and reputation lists. The frequency of the anti-spam updates, however, are set with the -UpdateMode parameter and applies to anti-spam and reputation data only. The -MicrosoftUpdate parameters takes one of the following values:
  • RequestDisabled This value disables Automatic Update.
  • RequestNotifyDownload Automatic Update notifies you when new updates are ready for download.
  • RequestNotifyInstall Automatic Update downloads updates and notifies you when they are available for installation.
  • RequestScheduled This value sets download and installation of updates according to the configuration of the Automatic Update on the computer.

If you run the Get-AntispamUpdates you may see another value, Configured, for the MicrosoftUpdate parameter; like this:

UpdateMode                  : Disabled
LatestContentFilterVersion  : 3.3.4604.600
SpamSignatureUpdatesEnabled : False
LatestSpamSignatureVersion  : 3.3.4604.600
IPReputationUpdatesEnabled  : False
LatestIPReputationVersion   : 3.3.4604.001
MicrosoftUpdate             : Configured

Configred means that the Windows OS Automatic Updates client was already configured for the computer by other means before the Enable-AntispamUpdates cmdlet was run. In other words, when you set the MicrosoftUpdate parameter, you do not configure the Automatic Updates client schedule if you have already configured the Windows Automatic Updates schedule.

Great opening lines

Some books distinguish themselves by having exceptionally good opening lines. Here are some of my favorites:

  • The Gunslinger by Stephen King
    The man in black fled across the desert, and the gunslinger followed.
  • Neuromancer by William Gibson
    The sky above the port was the color of television, tuned to a dead channel.
  • Farenheit 451 by Ray Bradbury
    It was a pleasure to burn.

More to come.