Are you a technology junkie who is looking for security video cameras for your business? Surveillance camera systems, pan tilt and zoom cameras, and security video cameras are all great examples of cameras that can help improve security.

Understanding Windows 2000 Group Policies

By: Brien M. Posey, MCSE

If you’ve been using a Windows NT environment for a while, you’re no doubt familiar with system policies. Because of this, it may be a little disturbing to learn that the system policies have been done away with in Windows 2000. Instead, system policies have been replaced with group policies. In this article, we’ll introduce you to group policies. As we do, we’ll discuss the capabilities and limitations of group policies. We’ll also discuss some techniques that you can use to help you to implement group policies in your Windows 2000 environment.

What are group policies?

Probably the best way to begin explaining group policies is to say that they aren’t profiles. As you may recall, a profile is a user environment that defines such things as the desktop appearance. Instead, a group policy is more similar to a system policy. A group policy allows you to define what actions that a user is and isn’t allowed to perform on the network and on their own computer.

Group Policies VS. System Policies

As you may recall, in Windows NT, the system policies gave you great control over what users were and weren’t allowed to do. For example, you could make the Control Panel inaccessible to users, or prevent them from accessing the Run prompt. In Windows NT, the system policies were applied at the domain level. The restrictions defined within a system policy could be combined with the information defined in any other security definition to complete a comprehensive security structure.

As well as system policies functioned they did have their down side. For starters, the system policies were called in the registry. This means that if a poorly implemented security structure allowed a user to gain access to the registry, they could change the key that calls the system policy to call a less restrictive system policy or no system policy at all.

Another downside was that because the system policies were stored in the registry, they could outlive their useful life. For example, suppose that a user was promoted to a position that required a less restrictive security policy. The existing policy would remain in effect regardless to any group membership changes until the policy was manually changed. The final downfall of system policies is that they were pretty much limited to controlling desktop behavior.

In Windows 2000 on the other hand, the group policies are designed to be much more efficient and effective. Each windows 2000 machine contains its own local group policy object. This local group policy can be used in conjunction with any number of active directory based group policy objects. This means that group policy objects can be associated with sites, domains and organizational units just to name a few. As such, group policies represent the primary mechanism for enabling centralized security within Windows 2000.

In addition, group policies are secure. Only an administrator can change a group policy. The group policies are still stored in the registry. The locations are HKEY_LOCAL_MACHINE | Software | Policies and HKEY_LOCAL_MACHINE | Software | Microsoft | Windows | CurrentVersion | Policies. Although the registry stores group policies, the keys that we mentioned above are designed to be secure so that only an administrator may access them. Because group policies may be linked to groups, the system will automatically update these registry keys when a user changes security groups and the current policies are no longer valid.

The Anatomy of a Group Policy

The basic unit of a group policy is the group policy object. Although a group policy object may contain multiple security settings, it can only be used as a whole. You can enable a group policy object, or you may disable it. It’s impossible to only enable a subset of the security settings within an individual object. Because of this, you must combine multiple group policies to get the desired security settings for a specific user. For example, you might have a domain policy, a policy for each group that the user belongs to and a policy for the local machine that a user is logged into. All of these individual group policies combine together to form the user’s individual security policy.

Before we continue discussing the anatomy of group policies, it’s important to point out that each Windows 2000 machine contains one local group policy that enforces the restrictions placed upon the local machine. All other group policies are a part of the active directory. Throughout the duration of this article, we’ll be discussing non-local group policies unless otherwise noted.

As we mentioned earlier, group policies may be linked to sites, domains, or organizational units. If a group policy is implemented at the site level, it applies to all domains within the site. If a group policy is applied to a domain, the policy will apply to all users and computers within the domain. Such policies may also apply through inheritance to organizational units and the users and groups that they contain that fall under the active directory tree beneath the domain. Likewise, a group policy that’s applied to an organizational unit will effect all users, computers, and other organizational units that fall beneath it.

When it comes to applying a group policy, Windows 2000 begins by applying the local policy. It then applies site level policies in the administratively specified order. Next, Windows 2000 applies domain level group policies in the specified order. Finally, Windows 2000 will apply the group policies that are associated with the organizational units. It will do so by beginning with the group policy that resides at the highest point in the active directory hierarchy and working its way down. If a single organizational unit contains multiple group policies, the policies are applied in an administratively specified order.

Each security setting within a group policy can be set to either enabled, disabled, or not configured. As Windows 2000 assembles an individual user’s security policy the lower units overwrite the higher units. For example, suppose that the following settings exist within an active directory and apply to a specific user:

Site level:

Setting 1: Enabled

Setting 2: Disabled

Setting 5: Disabled

Domain level:

Setting 1: Disabled

Setting 2: Disabled

Setting 3: Disabled

Setting 4: Disabled

Organizational Unit:

Setting 3: Enabled

Setting 4: Not Configured

If such a combination of group permissions applied to a user, Windows 2000 would first look at the local policy and apply the settings contained within it. For the purposes of this example, let’s forget about the local policy. Next, Windows would look at the site level group policy. As you can see above, the site level group policy would enable setting 1 and disable settings 2 and 5. Next, Windows would overwrite overlapping portions of the site group policy with the domain group policy. In this particular example, setting 1 would be disabled because the site level group policy would be overwritten with the domain group policy. Setting 2 would remain disabled. Because the domain level group policy doesn’t contain a setting 5, setting 5 would remain in the disabled state that it was set to in the site level. The permissions in effect at the domain level for the user would be as follows:

Setting 1: Disabled

Setting 2: Disabled

Setting 3: Disabled

Setting 4: Disabled

Setting 5: Disabled

Finally, the organizational unit group policies would be applied. Because the organizational unit group policies doesn’t specify a setting for settings 1,2, or 5, these settings remain in effect from the domain level group policy. Setting 3 is enabled in the organizational unit which means that it will now be enabled for the user. Setting 4 is not configured, which means that the domain level group policy for setting 4 remains in effect. In the real world, the settings that we omitted from the various levels would be treated as if they existed but were set to not configured. By the time all is said and done, the following group policy would apply to the user:

Setting 1: Disabled

Setting 2: Disabled

Setting 3: Enabled

Setting 4: Disabled

Setting 5: Disabled

Managing Group Policy Objects

Group Policy Objects are created and managed through the Group Policy snap in for Microsoft Management Console. Before you attempt to play with the group policy objects, it’s important to point out that there is no save feature when working with group policy objects. As with the Registry Editor, group policy changes take effect immediately at the time that you make them. We should also point out that it’s impossible to open group policy objects in read only mode.

Modifying the Group Policy

You can create or edit a group policy through the Group Policy snap in for Microsoft Management Console. To access this snap in, select the Run command from the Start menu. Next enter MMC at the Run prompt. When you do, the Microsoft Management Console will Load. At this point, select the Add/Remove Snap In command from the Console menu. Now, you’ll see the Add/Remove Snap In dialog box. Click the Add button to see a list of available snap ins. Select Group Policy from the list and click OK. You’ll now see a screen that asks which group policy object that you want to work with. For the purpose of this example, click the Browse button and select the Domain Controller Policy and click OK. Click Finish to close the dialog box. When you do, you’ll be returned to the list of available snap ins. Click Close to close this list Finally, click OK to load the Group Policy Editor snap in. 

The Group Policy Editor is divided into two basic sections, Computer Configuration and User Configuration. The computer configuration section specifies all computer specific policies that control the behavior of the operating system. For example, you can use this section to create policies that control things like desktop behavior, startup and shutdown scripts, and various application settings. The User Configuration section controls very similar settings to those of the Computer Configuration section. The main difference between the two is that the Computer Configuration section applies these settings on a per computer basis while the User configuration section applies the settings on a per user basis. For example, the Computer Configuration section allows you to control startup and shutdown scripts while the User Configuration section allows you to control logon and logoff scripts.

Both the Computer Configuration section and the User Configuration section contain three basic subsections. Beneath these are other keys for establishing the policies. These three sections are Software Settings, Windows Settings, and Administrative Templates.

The Software Settings section provides a place for third party developers to add policy settings related to their products. By default, this section contains no settings other than the software installation extensions provided by Windows 2000

The Windows Settings section allows you to establish the group policies that specifically relate to the Windows 2000 operating system. For example, this section allows you to specify the scripts that we mentioned earlier. You can also set things like minimum password lengths, account lockout duration, and maximum event log sizes. 

The last of these three sections is the Administrative Templates section. The items found in this section are reflections of registry based policy settings. You can actually add items to this template by creating an .ADM  file and installing it by right clicking on the Administrative Templates item and selecting the Add/Remove Templates command from the resulting context menu.

If you've found this article helpful then please consider making a donation to help with the cost of keeping this site going. To make a donation, please click on the PayPal link below.