As you may know, group policy objects are the primary mechanisms for implementing security in Windows 2000. As with many new security mechanisms, it’s easy to make a mistake when setting up group policies. Such mistakes can cause all kinds of side effects ranging from too many restrictions on users to no restrictions at all. In this article, I’ll begin by discussing some of the best practices to use when implementing group policies. I’ll then go on to explain the causes of and solutions for some common group policy problems.
Many of the more common group policy problems can be traced to bad implementation practices. As I’ll discuss later, many of these practices can lead to some truly wicked and undesirable side effects. In this section, I’ll explain some techniques that you can use to reduce the number of group-policy related problems that occur in your organization.
One thing that you can do to prevent group-policy related problems is to disable the unused portions of group policy objects. As you probably know, group policy objects contain a User Configuration section and a Computer Configuration section. When you examine the policies on your system, you may discover that some of the policies use only one of these sections and not both. If this is the case, disable the portion of the policy that isn’t used. Doing so not only prevents potential group policy conflicts, but also decreases the amount of time that Windows 2000 takes to log in, because Windows is processing fewer settings within each group policy object.
Another helpful practice is to limit your use of the Block Policy Inheritance and No Override features. As I’m sure you’re aware, computer systems are generally much easier to troubleshoot when using a consistent set of rules. Normally, group policies behave in a standard manner using a very clear set of rules, thus providing a system that consistently performs.
When you use the Block Policy Inheritance and No Override settings, you disrupt this consistency. Using these features doesn’t necessarily cause a problem (assuming you know what you’re doing). However, it forces the system to behave in an unnatural manner and makes troubleshooting problems a lot more difficult. I’ll discuss how these settings can adversely affect the system in more detail later in this article. For now, just remember not to use them unless you have to.
To further minimize difficulties, try to store group policy objects in the domain in which they actually belong. I’ve seen systems in which all of the group policy objects are stored in one domain. Any time that a system logs in, it has to pull a group policy object off of this domain regardless of which domain the machine actually belongs to.
This organizational technique causes two problems. First, it slows things down tremendously. Having the policies located on a local domain controller instead of a foreign domain controller makes the login process go much quicker. Second, storing group policies in a foreign domain can result in the policies becoming unavailable if a failure should occur in the foreign domain or in the communications link between the domains.
Yet another helpful practice is to apply the group policy objects to security groups rather than to individual user accounts. Doing so will greatly expedite the login process, and it reduces the chances of having contradictory group policies applied to the user. For example, imagine that you have a network with five basic applications. Now imagine that each time that a user logs in, Windows 2000 has to process one massive group policy object that applies to the use of each application and to other settings within the application. Needless to say, this process could take some time to complete.
Now, imagine that you’ve broken the policy down into five much smaller policies. Suppose that you then associate the smaller policies with the security groups that relate to the individual applications. Finally, imagine that a particular user has access to three of the five applications. When the user logs on, Windows 2000 looks at the user’s group memberships and only process the three group policy objects that relate to the three groups to which the user belongs. This eliminates the need for processing two useless policies, and saves a lot of time during the login process.
It’s easy to get carried away and create a large number of policies all over the system. The biggest thing to remember is the more policies that apply to any one user or system, the longer it will take that user to log in, and the bigger the chance for a policy-related error (like the ones caused by overlapping permissions). The biggest trick to reducing the number of policies in effect is to avoid assigning policies directly to users, computers, domains, or organizational units, except for when absolutely necessary. As I mentioned, it’s a much better practice to assign policies on a group basis when possible.
Troubleshooting group policies
Now that I’ve discussed some of the best practices for implementing group policies, it’s time to address the issue of troubleshooting existing policy problems. Sure, you can clean up a messy policy scheme over time, but if you’re already having a problem, you’ll probably want to fix the problem first.
Group policy problems can be grouped into several areas. For example, you might have trouble creating or modifying a group policy. Another potential problem might be that a group policy isn’t taking effect. In the sections that follow, I’ll address some of the various group policy problems by grouping them by product categories.
Problems with the group policy snap-in
The biggest problem with group policy snap-ins is that sometimes administrators have trouble opening and/or modifying them. There are two basic causes for this problem. The first is insufficient rights. Believe it or not, users must have both read and write permissions to a group policy object before Windows will even allow them to open it in the group policy snap-in. Therefore, if you’re having trouble viewing a group policy object, make sure that you have the appropriate rights.
The other cause for not being able to open a group policy object is network problems. For example, a problem with a network link between you and the server that stores the group policy object could cause the group policy to not open. Keep in mind that Active Directory depends heavily on DNS. Therefore, if you have the correct permissions and all of the network components seem to be functional, check your DNS server. Certain types of DNS problems will generate an error message that says “Failed To Open Group Policy Object.”
Policies not taking effect
Problems relating to group policy objects not being applied correctly are a little harder to track down. In spite of this, these problems usually relate to a simple error in the policy or to the administrator misunderstanding how Windows 2000 processes the policy.
One example of a misunderstood policy process involves a situation in which a group policy object is linked to an organizational unit (OU). Suppose for a minute that the OU contains users, computers, and security groups. The problem comes in when the policy applies to only some of the members of the security groups. The reason for the problem is that a group policy at the OU level affects only users and computers, not security groups. Therefore, if the group contains users that aren’t directly affected by the OU’s group policy, then simply adding them to a security group within that OU won’t enact that policy. You must link a group policy directly to the security group for this to happen.
Another situation that involves group policies not being applied correctly is a situation in which multiple policies exist at all different levels. When multiple group policies exist, Windows 2000 uses a system of precedence to decide which policy is processed first. For example, Windows 2000 normally processes policies in the following order: local, site, domain, and OU.
Therefore, when a user logs on, Windows looks to see if a local group policy exists. If it does, Windows 2000 processes and applies that policy. Next, Windows looks for a site level policy. If a site level policy exists, it’s processed and applied. The trick is that any time a new level of group policies is applied, the new level overrides any policies set at the level below it.
For example, suppose that the site level policy gave a user read only permissions to a folder, but the domain level policy denied the user access. Because the higher-level policy takes precedence, the user would be denied access to the folder regardless of what the site or local policies dictated. Keep in mind though that in spite of the fact that the higher-level policies take precedence, it doesn’t mean that lower-level policies are completely overwritten. Any policy applied at the lower level remains in effect unless a higher-level policy changes it.
So, if this basic set of rules always applies, then you may be wondering how policy problems can ever happen. Earlier I cautioned against using the No Override setting. The No Override setting prevents higher-level policies from overriding lower-level policies. If you’re having trouble implementing a policy, you might check for the existence of this setting.
Another potential problem may be a security group membership. Keep in mind that when security group permissions overlap, they end up with a cumulative set of permissions. Therefore, if any of the permissions are set to deny access to a resource, the resource will be denied regardless of permissions assigned in other groups.
Still another common problem is that users or computers in a given Active Directory container aren’t affected by a particular group policy. If this happens to you, just remember that group policies tend to use the “trickle down” method. Simply apply the policy to the parent container and it will automatically be applied to the containers beneath it, in this case, the containers that hold the desired users and computers.
One final common problem is that sometimes group policies don’t seem to take effect on local machines. If this happens, remember that group policies are hierarchical and the local level group policies are the lowest man on the totem pole, so to speak. Since local policies are the weakest, it’s easy to accidentally overwrite them. Local machine problems such as this are almost always caused by higher-level group policies overwriting the lower-level local group policies. To correct the problem, simply review the higher-level group policies to determine which one is overwriting the local policy. In many situations, disabling a higher-level policy is out of the question. If this is the case, you may end up having to incorporate the settings from the local level group policy into a higher-level policy.
Because of the hierarchical nature of group policies, it’s easy to make one mistake that can trickle down through your entire organization. In this article, I’ve discussed some techniques that you can use to help reduce these common mistakes when setting up group policies. I then explained the causes and solutions for many common group policy errors.
Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it's impossible for him to respond to every message. However, he does read them all.)The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.