System Policies to Group Policies: Issues, Improvements, and Best Practices, Part 2
Total Page:16
File Type:pdf, Size:1020Kb
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 configure Group Policies, and how to link Group Policies to sites, domains, or organizational units (OUs) so they will be processed. This ar- ticle is a continuation of Part 1 (84-02-06) but addresses issues with clients who already process System Policies, applying a security policy to down- level 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 ap- plying 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 file. This Think about Group Policy design while designing file 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. 08/01 Auerbach Publications © 2001 CRC Press LLC 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 ser- vice 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 set- tings 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 differ- ent. 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 08/01 Auerbach Publications © 2001 CRC Press LLC EXHIBIT 2 — Systems Policies Has More Than 70 Configurable 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 reg- istry 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 08/01 Auerbach Publications © 2001 CRC Press LLC EXHIBIT 3 — Group Policy Has More Than 680 Configurable Settings HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Group Policy Settings configured under these keys win over any other registry keys. This means if the user sets the background and Group Policy specifies the background under: HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Group Policy then the background under: 08/01 Auerbach Publications © 2001 CRC Press LLC 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 configure 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 re- booted 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 efficiently. • 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- 08/01 Auerbach Publications © 2001 CRC Press LLC 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 de- scriptive name for each Group Policy created, so that one knows the con- figuration 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 Configure 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. 08/01 Auerbach Publications © 2001 CRC Press LLC EXHIBIT 4 — Group Policies for Different Departments and for Different Types of Users 08/01 Auerbach Publications © 2001 CRC Press LLC EXHIBIT 5 — Naming the Group Policy 31. Click twice slowly on the existing Group Policy. 32. Enter the New Group Policy Name.