System Policies to Group Policies: Issues, Improvements, and Best Practices, Part 2

84-02-07

DATA SECURITY MANAGEMENT SYSTEM POLICIES TO GROUP POLICIES: ISSUES, IMPROVEMENTS, AND BEST PRACTICES, PART 2

Melissa Yon

INSIDE Dealing with Existing NT4 System Policies; Comparing System Policy to Group Policy; Windows 2000 Clients Without Active Directory, or Active Directory with Downlevel Clients; Group Policy Best Practices

INTRODUCTION Part 1 (84-02-06) of this article series discussed the planning and designing of group policies. The goal was to make you aware of Group Policies, how to conﬁgure Group Policies, and how to link Group Policies to sites, domains, or organizational units (OUs) so they will be processed. This article is a continuation of Part 1 (84-02-06) but addresses issues with clients who already process System Policies, applying a security policy to downlevel clients, and best practices when enabling Group Policies on Win- dows 2000 Active Directory.

DEALING WITH EXISTING NT4 SYSTEM POLICIES PAYOFF IDEA NT4 System Policies are the precursor If one’s company has never used System Policies, to Windows 2000 Group Policies. In then one is starting with a clean slate. However, if NT4, there are greater than 70 differ- implementing System Policies, there may be sev- eral things in the registry that no longer need to be ent settings through System Policy to a there. You will need to evaluate your environment machine, user, or a NT group of users. and decide if you want to implement Group Poli- While this addition to Windows is a cies over the System Policies, or if you need a very big step in the right direction, it clean install of the operating system before applying Group Policies. When working with Group had many limitations. First, the System Policies, keep all of the best practices in mind. Policies are saved in a .POL ﬁle. This Think about Group Policy design while designing ﬁle must be in the NETLOGON direc- the Active Directory. The easiest Group Policy de- tory on the Domain Controller that au- sign is the design that follows the organizational unit structure.

thenticated the users. If the file does not exist on the machine that authenticated the user, then the System Policy is not applied. To ensure that System Policies are available on all Domain Controllers, administrators typically set up the File Replication Service in NT4. They then configure it so that the NETLOGON directory replicates to receive the latest System Policies. This works well, provided the file replication service works correctly, which it did not always do in the past. Once the System Policies reside on all Domain Controllers, the System Policies for the machines and users will be processed when the machine and users are authenticated. The machine policy loads at boot-up and the System Policy for the user or any groups the user is a member of processes at logon. As the System Policy processes, the registry is tattooed. This means that the registry settings are changed based on the System Policy for the machine and the user. The machine System Policies are set under HKEY_LOCAL_MACHINE and the user System Policies are set under HKEY_CURRENT_USER. The System Policies change the actual registry keys. The registry is tattooed because if the System Policy is deleted, it will not remove the settings from the machine’s registry. If one wants to reset the client’s registry, one needs to reconfigure the System Policy to the settings needed. The client’s machine must be rebooted and the user needs to log in for the change to take place in the client’s registry.

COMPARING SYSTEM POLICY TO GROUP POLICY Many of the settings found in System Policies are also in Windows 2000 Group Policies. The interface to configure the policy, however, is different. System Policies are edited using the Sysedit tool from Windows NT4 (see Exhibit 1). Group Policies are edited by using the Group Policy tool in the Microsoft Management Console. System Policies (Exhibit 2) has more than 70 configurable settings, while Group Policy (Exhibit 3) has more than 680 configurable settings. System Policies are applied to machines, users, and groups of users. Group Policy, however, is applied at the site, domain, and OU levels. To

EXHIBIT 1 — System Policy Editor in Windows NT

EXHIBIT 2 — Systems Policies Has More Than 70 Conﬁgurable Settings

apply to only certain users or machines in a site, domain, or OU, one must filter the Group Policy. Because Group Policies are applied differently, one cannot upgrade the NT4 System Policies to Windows 2000 Group Pol- icies; one must configure Windows 2000 Group Policies using the Group Policy Tool. Unlike System Policies, Group Policies do not tattoo the registry. If the Group Policy is unlinked or deleted, the machine’s registry removes all the settings that were added to the registry by that Group Policy. System Poli- cies are unable to do this because System Policies write directly to the registry under the specific key. Group Policies write to a specific key in the registry designed for Group Policies. It is located in:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\ CurrentVersion\Group Policy

and

EXHIBIT 3 — Group Policy Has More Than 680 Conﬁgurable Settings

HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Group Policy

Settings conﬁgured under these keys win over any other registry keys. This means if the user sets the background and Group Policy speciﬁes the background under:

HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Group Policy

then the background under:

HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Group Policy

takes precedence. If using System Policies to specify the background, the background would write to the same registry key whether the user or System Policies set it. There is no way, by just looking at the registry, to determine if the user or if System Policies set the setting.

WINDOWS 2000 CLIENTS WITHOUT ACTIVE DIRECTORY, OR ACTIVE DIRECTORY WITH DOWN-LEVEL CLIENTS Unfortunately, one must have a Windows 2000 client that authenticates to Active Directory to use Group Policy. Therefore, if one has Windows 2000 Active Directory installed but the client is a Windows 98 or Windows NT4 workstation, or if one has a Windows 2000 client that authenticates to a Windows NT4 domain, one must use System Polices. One needs the Sys- edit tool from the Windows NT4 Server to conﬁgure the System Polices. The System Policies will perform as explained above. Remember: System Policies tattoo the registry. To return the registry to its default state, set all System Policies to NOT CONFIGURED. The next time the machine is rebooted and the user logs on, the policy will be refreshed.

GROUP POLICY BEST PRACTICES 1. Communicate One of the most important best practices when implementing Group Pol- icies is to communicate. Users tend to believe that their personal computer on their desk is just that, their computer. When an administrator attempts to lock down that machine, users feel the company is trying to infringe on their property. It is important from the beginning to communicate the rea- son for Group Policies. The reasons could be:

• Group Policies will enable the company to run more efﬁciently. • There will be X less number of workstation visits. • There will be X less number of help desk calls. • Users will have X more time to do work because the workstation will not need to be serviced as often.

2. Consider the Group Policies Needed When Designing the Active Directory Structure Because Group Policies are applied to site, domain, and OU levels, it is important to design the site, domain, and OU by the way Group Policy needs to be applied. For example, there may be different Group Policies for different departments. There may be different Group Policies for dif-

ferent types of users in those departments, such as User and Expert. The design could be either of the ones in Exhibit 4.

3. Use Descriptive Group Policy Names Create a naming scheme for the Group Policies. There should be a descriptive name for each Group Policy created, so that one knows the con- ﬁguration of the Group Policy without having to traverse the Group Policy tree.

Creating a New Group Policy with a Descriptive Name:

1. Click Start>Run. 2. Type mmc. 3. Press Enter. 4. Click Console>Add/Remove Snap-In. 5. Click Add. 6. Click AD Users and Computers. 7. Click OK. 8. Click Finish. 9. Click Close. 10. Expand the AD Users and Computers Snap-in. 11. Right-click the Domain or OU you are linking the GPO to. 12. Click Properties. 13. Click the Group Policy tab. 14. Click New. 15. Enter the New Group Policy Name. 16. Press Enter. 17. Click Edit to Conﬁgure the Group Policy.

Changing the Group Policy Name:

18. Click Start>Run. 19. Type mmc. 20. Press Enter. 21. Click Console>Add/Remove Snap-in. 22. Click Add. 23. Click AD Users and Computers. 24. Click OK. 25. Click Finish. 26. Click Close. 27. Expand the AD Users and Computers Snap-in. 28. Right-click the Domain or OU you are linking the GPO to. 29. Click Properties. 30. Click the Group Policy Tab.

EXHIBIT 4 — Group Policies for Different Departments and for Different Types of Users

EXHIBIT 5 — Naming the Group Policy

31. Click twice slowly on the existing Group Policy. 32. Enter the New Group Policy Name. 33. Press Enter.

Each Group Policy should have a descriptive name such as “Auditing” (see Exhibit 5).

4. Link a Default Group Policy to the Domain One can only conﬁgure some security settings in Group Policy at the domain level. For example, the password length will be deﬁned for the entire domain. If this setting is set at the OU level, it will not be applied; it must be set at the domain level. Any Group Policy settings that should be applied to all users should be set at the domain level.

Linking Group Policies: 1. Click Start>Run. 2. Type mmc.

3. Press Enter. 4. Click Console>Add/Remove Snap-in. 5. Click Add. 6. Click AD Users and Computers. 7. Click OK. 8. Click Finish. 9. Click Close. 10. Expand the AD Users and Computers Snap-in. 11. Right-click the Domain or OU to which the GPO is linked. 12. Click Properties. 13. Click the Group Policy Tab. 14. Click Add. 15. Click the GPO. 16. Click OK.

Some security settings can only be conﬁgured at the domain level (see Ex- hibit 6).

5. Consider the Group Policy Design When There Are WAN Links When a Group Policy is created, it can be linked to multiple sites, domains, and OUs. If the company has WAN links to other locations, one will need to consider Group Policy links across the WAN links. When a Group Policy is created, the Group Policy resides in the Active Directory on the Domain Controller where it was created. Let’s link Group Policy to a Do- main that crosses a WAN link. Every time a machine boots or user logs into the linked domain, Active Directory must traverse the link to pull that machine’s and user’s Group Policy, which means additional trafﬁc across the WAN link.

6. Limit the Use of No Override and Block Inheritance One can set “No Override” on a policy; this means settings defined in this Group Policy that are processed after the “No Override” Group Policy will not change (see Exhibit 7). One can also set a “Block Inheritance,” which will prevent applying any policies processed before this Group Policy. “No Override” and the “Block Inheritance” are specified on the Group Pol- icy tab at the site, domain, and OU levels. If a Group Policy is not being processed, one will have to look at every site, domain, and OU to see if a “No Override” or “Block Inheritance” is enabled. Also, the more “No Over- rides” and “Block Inheritances” that are configured, the more processing time is wasted.

Setting No Override: 1. Click Start>Run. 2. Type mmc.

Security Settings at the Domain Level EXHIBIT 6 —

Setting “No Override” EXHIBIT 7 —

3. Press Enter. 4. Click Console>Add/Remove Snap-in. 5. Click Add. 6. Click AD Users and Computers. 7. Click OK. 8. Click Finish. 9. Click Close. 10. Expand the AD Users and Computers Snap-in. 11. Right-click the domain or OU to which the policy is linked. 12. Click Properties. 13. Click the Group Policy tab. 14. Click the Group Policy where you want to set the No Override option. 15. Click Option. 16. Click No Override (see Exhibit 8). 17. Click OK. 18. Click OK.

EXHIBIT 8 — Setting Default Domain Policy Options to “No Override”

Setting Block Inheritance: 1. Click Start>Run. 2. Type mmc. 3. Press Enter. 4. Click Console>Add/Remove Snap-in. 5. Click Add. 6. Click AD Users and Computers. 7. Click OK. 8. Click Finish. 9. Click Close. 10. Expand the AD Users and Computers Snap-in. 11. Right-click the domain or OU to which the policy is linked. 12. Click Properties. 13. Click the Group Policy tab. 14. Click the Group Policy where you want to set the Block Inheritance option. 15. Click Block Inheritance (Exhibit 9). 16. Click OK.

EXHIBIT 9 — Blocking Policy Inheritance

7. Limit the Use of Nested Group Policies Windows 2000 is very scaleable. One can nest many OUs inside of an OU. However, do not assign a Group Policy to the site, domain, and 20 nested OUs. Doing so could have a user in an OU that is nested 20 levels deep and a Group Policy is linked at every OU level. The Group Policy is exe- cuted at logon. The user will not be logged in until all 20 Group Policies for that user are processed. It is recommended to have no more than ten Group Polices for each machine or user. If the Active Directory has been conﬁgured correctly, this should not be a problem.

8. Limit Linking Multiple Group Policies to the Same Domain or OU Level Each Group Policy at a domain or OU level must be processed before a machine can boot up or a user can login. Keep in mind that Group Policies are processed from the bottom up in the list, so be sure to have them in the correct order.

9. When Delegating Group Policy Control, Use the Most Restrictive Control One big advantage to Windows 2000 is the granularity in administration. If one has a dispersed administration team in which each department has its own administrator, one may want to give that administrator rights to the Group Policy for their OU (see Exhibit 10). If one is giving rights, give the most restrictive rights, and only the rights they need to do their job (see Exhibit 11).

10. Create Group Policies in which only the User or Computer Configuration is Processed When designing an Active Directory, use OUs to organize the environment. Create an OU for users and a separate OU for computers. Then, when creating Group Policies, configure only the user or computer portion of that Group Policy. Also configure the Group Policy to process only that portion of Group Policy that was configured; otherwise, both sections of Group Policy will be processed.

Conﬁguring the Group Policy to only process the computer conﬁguration: 1. Click Start>Run. 2. Type mmc. 3. Press Enter. 4. Click Console>Add/Remove Snap-in. 5. Click Add. 6. Click AD Users and Computers. 7. Click OK. 8. Click Finish. 9. Click Close. 10. Expand the AD Users and Computers Snap-in.

EXHIBIT 10 — Granting Administrators Rights to the Group Policy for Their OU

11. Right-click the domain or OU to which the policy is linked. 12. Click Properties. 13. Click the Group Policy tab. 14. Click the Group Policy that should only process the computer conﬁguration. 15. Click Properties. 16. Click Disable user conﬁguration settings (see Exhibit 12). 17. Click OK. 18. Click OK.

11. Configure Loopback Processing for Kiosk Machines When an employee uses a Kiosk machine, one may not want their user settings applied to the machine (see Exhibit 13). Group Policy contains settings that will not process the user’s conﬁguration. There are two choic-

Assigning Only the Rights Needed for the Administrator’s Jobs Assigning Only the Rights Needed for Administrator’s EXHIBIT 11 —

EXHIBIT 12 — Disabling User Conﬁguration Settings

es for Loopback processing: Enabled and Disabled. If Loopback processing is enabled, then one must choose “Replace” or “Merge.” “Replace” will replace any user’s group policies with the computer policies. No user con- figurations are applied. “Merge” will merge the user’s configuration with the computer’s configuration. If the user’s and the computer’s configuration conflict, the computer’s configuration is applied.

Conﬁguring the Loopback Feature: 1. Click Start>Run. 2. Type mmc. 3. Press Enter. 4. Click Console>Add/Remove Snap-in. 5. Click Add. 6. Click AD Users and Computers.

Loopback Conﬁgured on Kiosk Machines EXHIBIT 13 —

7. Click OK. 8. Click Finish. 9. Click Close. 10. Expand the AD Users and Computers Snap-in. 11. Right-click the domain or OU to which the policy is linked. 12. Click Properties. 13. Click the Group Policy Tab. 14. Click the Group Policy that contains the computer conﬁguration. 15. Click Edit. 16. Expand Administrative Templates under the Computer Conﬁguration portion. 17. Expand System. 18. Click on Group Policy. 19. Double-click User Group Policy loopback processing mode. 20. Click Enable. 21. Click Replace or Merge in the drop-down list. 22. Click OK. 23. Close Group Policy.

12. Use Third-Party Group Policy Tools Group Policy is an important feature with Windows 2000 that should be implemented. However, it is very limited in what it can do. You cannot search on the Group Policy settings or even get the RSOP (Resultant Set of Policies). You cannot even back up Group Policies without backing up all of Active Directory. Third-party tools, such as Full Armor, can do all of this and more. If one’s company has never used System Policies, one is starting with a clean slate. However, if System Policies has been implemented, one may have many things in the registry that do not need to be there anymore. One will need to evaluate the environment and decide whether to implement Group Policies over the System Policies or if there needs to be a clean install of the operating system before applying Group Policies. When working with Group Policies, keep all of the best practices in mind. Think about Group Policy design while designing the Active Directory. The easiest Group Policy design is the design that follows one’s OU structure.

Melissa Yon, MCSE, MCT, MCP+I, CTT, is currently a technical trainer for Lucent Technologies Worldwide Ser- vices. She has nine years of experience in designing and implementing desktop, server, and enterprise solutions and conducting training. In the last two years, she has designed training materials and delivered training and solutions for Lucent Technologies.