Group Policies

The Basics

 

I’m writing a series of articles about group policies. This because I often see policies implemented wrongfully, rendering them to be ineffective. These articles are strictly written on my point of view and from my experiences. I hope they are informative for whoever takes time to read the articles.

The main scope of these articles is represented towards Windows Server 2003 as Windows server 2008 has only been released a few months ago. Yet knowing these basics will help you even in a Windows Server 2008 environment.

 

The basics

For a detailed description of what group policies are, you can consult http://en.wikipedia.org/wiki/Group_Policy for more detailed information. But I guess the reader is aware of what they are and what they are used for. Before explaining the basics of Group Policies, I will advice which tools you can use to manage your group policies.

Tools:

I will jump off by representing some tools that are used to manage group policies.

Basically in Windows 2000 and Windows Server 2003 (R2) policies where only managed by using the “Users and Computers” (DSA.msc) and “Sites and Services”(DSSITE.msc) snap-ins , in the MMC Console (Microsoft Management Console).   From there you would open the “Group Policy Editor” (GPEDIT.msc) at the appropriate level to edit your policies. Since the release of Windows Server 2003 (April 2003) Microsoft introduced the “Group Policy Management Console” (GPMC.msc) as a separate download to manage group policy, which is now included in Windows Server 2008.

If you want to use group policies there is really no reason why to not use the” group policy management console”. More information on “Group Policy Management Console” can be found here: http://www.windowsecurity.com/articles/Group-Policy-Management-Console.html.

Although “Group Policy Management Console” is the tool to use, you cannot manage local policies with it. As local policies can only be set local on the machine.

More useful tools:

http://www.gpoguy.com/Tools.htm

Be sure to have a look!

 

Policies

You can divide policies in two groups, local and Active Directory Based policies.

Local policies are applied locally and in generally apply to all users who log on to the system. You do not need Active directory to support them, as these policies run local and are saved locally. The policy stored in a hidden folder at %SystemRoot%\System32\GroupPolicy.

 When opening the folder you will see 3 folders and the gpt.ini file.

The gpt.ini file controls the GPO template version number and the Client site extensions that are configured in the policy.

[General] gPCFunctionalityVersion=2 gPCUserExtensionNames=[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}] Version=196608

The Adm folder holds five .adm files, which are called “Administrative templates”.

These templates files are loaded in the group policy editor.

 

Administrative templates, (or .adm files), enable administrators to control registry settings using Group Policy. Windows comes with a predefined set of Administrative template files, which are implemented as text files (with an .adm extension), that define the registry settings that can be configured in a GPO.

Windows Server 2003 includes the following .adm files: System.adm, Inetres.adm, Conf.adm, Wmplayer.adm, and Wuau.adm, which contain all the settings initially displayed in the Administrative Templates node.

.Adm file	Contains	For Use on	Description
System.adm	Settings to configure the Operating System	Windows 2000 or Windows Server 2003	Loaded by default.
Inetres.adm	Settings to configure Internet Explorer	Windows 2000 or Windows Server 2003	Loaded by default.
Conf.adm	Settings to configure NetMeeting v3	Windows 2000 or Windows Server 2003. Note: This tool is not available on Windows XP 64-Bit Edition and the 64-bit versions of the Windows Server 2003 family.	Loaded by default.
Wmplayer.adm	Settings to configure Windows Media Player	Windows XP, Windows Server 2003. Note: This tool is not available on Windows XP 64-Bit Edition and the 64-bit versions of the Windows Server 2003 family.	Loaded by default.
Wuau.adm	Settings to configure Windows Update	Windows 2000 SP3, Windows XP SP1, Windows Server 2003	Loaded by default.

 

The admfiles.ini contains the list of the administrative templates that should be available in the local policy.

Besides the ADM folder you also have the Machine and User folders. In general these folders are used to store scripts and software distributed by GPO’s.  But as software distribution is not available in local policies (because there’s no use for it), you will not find the Applications folder in a local policy. The Application folder is therefore only available in policies applied through Active Directory.  When looking further to the Machine folder you will see that this folder contains a subfolder called scripts, which is again subdivided in a startup and shutdown folder. These folders are used to store local scripts that run through the local policy either at startup or at shutdown.

Note: If you configure a (local) policy to use a script (User and Machine), a file “Scripts.ini” is created. This “Scripts.ini” is a hidden file which is placed in the folder to which settings (user or machine) the script is applied to. This “ini” file holds the paths and scripts that are configured within the policy.

[Logon] 0CmdLine=\\%Domainname%\SysVol\%Domainname%\scripts\Sales.bat 0Parameters=

 

The User folder in a local policy is by default empty, and will only be populated when a user logon script is created. This seems kind of logic as the local logon script is applied locally on the computer.

The local policy is managed by opening the “Group Policy Editor” on the machine where you want to place the local policy. Open the Microsoft Management Console (Start -> Run -> MMC), click File -> Add Snap-ins, and select Group Policy Editor from the list (For short Start -> Run -> GPedit.msc).

When you open the group policy editor, it will always open with the default policy.

 

When looking closer to the policy you will see that the policy is divided in two main sections.

1.       The computer configuration

2.       The user configuration.

In General the two sections are explained by the following:

•	Computer Configuration Administrators can use Computer Configuration to set policies that are applied to computer, regardless of who logs on to the computers. Computer Configuration typically contains sub-items for software settings, Windows settings, and administrative templates.
•	User Configuration Administrators can use User Configuration to set policies that apply to users, regardless of which computer they log on to. User Configuration typically contains sub-items for software settings, Windows settings, and administrative templates.

But as we are speaking about local policies the above explanation is not strictly true.  In fact, when using local policies, the settings defined in the local policy are always applied no matter who logs on to the computer. 

The settings you define are kept in a file called Registry.pol, this file is stored in the Machine folder if it are computer settings, or the user folder if it are user settings.

The next time you open the policy, the registry.pol is processed against the administrative templates, and thus showing you which settings are selected or configured.

 

Filtering out the local policy.

 

As stated previously, the settings applied in a local policy apply to every user who logs on to the computer.  Now there are several ways to avoid the policy to be applied to a specified user or group.

First of all the Microsoft supported Solution:

Apply Local Policies to All Users Except Administrators

To implement local policies to all users except administrators, follow these steps:

1.	Log on to the computer as an administrator.
2.	Open your local security policy. To do this, do one of the following: • Click Start, click Run, type gpedit.msc, and then press ENTER. -or- • Click Start, click Run, type mmc, press ENTER, add the Group Policy Object Editor, and then configure it for the local security policy. If the removal of the run command is one of the policies that you want, Microsoft recommends that you edit the policy by means of Microsoft Management Console (MMC), and then save the results as an icon. Then, you do not need the run command to reopen the policy.
3.	Expand the User Configuration object, and then expand the Administrative Templates object.
4.	Enable whatever policies that you want (for example, Desktop for "Hide My Network Places" or "Hide Internet Explorer Icon on Desktop"). NOTE: Make sure that you select the correct policies; otherwise, you may restrict the ability of the administrator to log on to the computer (and to complete the necessary steps to configure the computer). Microsoft recommends that you record any changes that you make (you can also use this information for step 10).
5.	Close the Gpedit.msc Group Policy snap-in. Or, if you use MMC, save the console as an icon to make it accessible later, and then log off the computer.
6.	Log on to the computer as an administrator. You can verify in this logon session the policy changes that were made earlier, because, by default, the local policies apply to all users, which includes administrators.
7.	Log off the computer, and then log on to the computer as all of the other users for this computer for whom you want these policies to apply. The policies are implemented for all of these users and the administrator. NOTE: Any user account that is not logged on to the computer at this step cannot have the policies implemented for that account.
8.	Log on to the computer as an administrator.
9.	Click Start, point to Control Panel, and then click Folder Options. Click the View tab, click Show Hidden Files and Folders, and then click OK so that you can view the Group Policy hidden folder. Or, open Windows Explorer, click Tools, and then click Folder Options to view these settings.
10.	Copy the Registry.pol file that is located in the %Systemroot%\System32\GroupPolicy\User folder to a backup location (for example, to a different hard disk, floppy disk, or folder).
11.	Open your local policy again by using either the Gpedit.msc Group Policy snap-in or your MMC icon, and then enable the exact features that were disabled in the original policy that was created for that computer. NOTE: When you do this, Policy Editor creates a new Registry.pol file.
12.	Close your policy editor, and then copy the backup Registry.pol file that you created in step 10 back into the %Systemroot%\System32\GroupPolicy\User folder. When you are prompted to replace the existing file, click Yes.
13.	Log off the computer, and then log on as an administrator. You can verify that the changes that were originally made are not implemented for you because you have logged on to the computer as an administrator.
14.	Log off the computer, and then log on as another user (or users). You can verify that the changes that were originally made are implemented for you because you have logged on to the computer as a user (not an administrator) to that computer .
15.	Log on to the computer as an administrator to verify that the local policy does not affect you as the local administrator to that computer.

 

More information:

http://support.microsoft.com/kb/325351

 Second: My way ;)

Create a local policy template on a machine that has the same Operating system + SP as the target machine. Copy the GPT.ini from the template to the target machine and place it in its corresponding folder on the target computer. \\%Computername%\C$\Windows\System32\Grouppolicy\ .

And copy the Registry.pol to the corresponding locations on the target machine.

“If Machine configuration \\%Computername%\C$\Windows\System32\GroupPolicy\Machine\”

“If User configuration \\%Computername%\C$\Windows\System32\GroupPolicy\User\”

Modify the NTFS security so that the ones who need to have the policy applied have read and Modify rights to the Registry.pol file, and the ones who do not have no permission to read the file.

Beware of group nesting: If you set the Authenticated users to read and modify, you have to specify deny rights to the ones who do not need to get the policy applied.

 

More reading:

http://technet2.microsoft.com/windowsserver/en/library/eb0042e3-699b-4c49-abcc-e3526dbecc0e1033.mspx?mfr=true

http://support.microsoft.com/kb/325351

http://www.gpoguy.com/