Restricted Groups Policy

A reader encounters a problem with a Restricted Groups policy.

Readers

May 26, 2004

3 Min Read
ITPro Today logo

A site administrator recently contacted me with a problem that developed after he used a Restricted Groups policy to lock down the local Administrators group. The administrator accounts from resource domains were being randomly added to the local Administrators group on the administrator's client machines. Some machines that the Restricted Groups policy affected showed trusted domain administrator accounts such as ResDom1Administrator and Res-Dom2Administrator. The local Administrators group also correctly showed global groups that the administrator had added to the Restricted Group Policy list from the machine's domain. The administrator account listed was random and changed with machine reboots.

I contacted Microsoft and learned that Group Policy is applied to clients through a policy template file. Active Directory (AD) compiles the settings you configure in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in into a plain text file that you can use any text editor to read. This file copies to the client's %systemroot%securitytemplatespolicies folder; the client then applies the settings at machine start-up and every 90 minutes thereafter (by default). The default domain policy ends in *.dom; other policies that apply to the machine end in *.inf.

When I checked the policy files on one of the problem machines, I found the text that Figure 1 shows. The second line in Figure 1 shows that the local machine's administrator account is renamed localadmin. The third line shows that a Restricted Groups policy is in place. In the fourth line, S-1-5-32-544 is the local Administrators group's SID. The fifth line shows the users and groups that the Restricted Groups policy specifies.

The policy file information helped me find the problem's cause. When the administrator applied the policy to restrict the local Administrators group during machine start-up or policy refresh, the machine added the SID values correctly but couldn't resolve the name administrator in the .inf file because the machine didn't have an account called administrator in the local SAM. In addition, I had renamed the administrator account on the domain the machine was a member of. The client machine couldn't resolve the name administrator against its SAM or its domain and was passing the name to the trusted domain list. The first resource domain that had an account named administrator responded with that account's SID. The account was then added to the local Administrators group. This process repeated during each policy refresh.

You don't need to specifically add the local administrator account to the local Administrators group when using Restricted Groups policies. You can't remove this account from this group; the account is a group member by default. The problem we encountered occurred because the site administrator used the free text field to add the names of users and groups rather than browsing to the user or group in AD. To prevent this problem, use the Browse button when you add users and groups to a Restricted Groups policy. The Active Directory Users and Computers snap-in will then resolve the name of the user or group to the SID you want to add. Removing the word administrator from the Restricted Groups policy solved the problem.

—John A. Rolstead
[email protected]

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like