One of the things that I have always liked about Windows Server 2003 is how flexible it is in terms of security. Windows Server 2003 is flexible enough to accommodate even the most bizarre corporate security policy. Unfortunately though, the byproduct of such flexibility is complexity. Windows Server 2003 has so many different layers of security that it can be difficult to predict the outcome of policy changes or to track down unwanted security policy settings.
Because security policies have traditionally been so difficult to manage in Windows Server environments, Microsoft has included a tool with Windows Server 2003 that is designed to make security policy management a lot easier. This tool is called the Resultant Set of Policy console (RSOP). In this article, I will introduce you to this tool and explain how you can use it to make security policy management a lot easier.
Why Is It So Difficult To Manage Security Policies?
Before you can truly appreciate RSOP, you need to understand what makes security policies so difficult to manage. The problem stems from the hierarchical nature of group policies. As you probably already know, group policies are collections of individual policy elements known as group policy settings.
Normally, if you wanted to make a change to your corporate security policy, you would open the appropriate group policy, track down the group policy setting that controls the desired aspect of security, and then make and save your changes.
What makes this deceptively simple process so complex is that multiple group policies can apply to a single user. Often times, these policies will contain contradictory group policy settings. When such contradictions occur, you have to be able to figure out which group policy setting is dominant and which settings are over written.
So how do you figure out which group policy settings are dominant? You have to understand the group policy hierarchy. Group policies can exist at the local computer, site, domain, and organizational unit levels. Windows processes group policies in that order to obtain the effective policy. Elements from each policy are merged together. For example, if a local policy contained a setting saying that passwords must be eight characters long, and a site level policy indicated that passwords must be changed every 30 days, then the effective policy would indicate that passwords must be eight characters long and must be changed every 30 days.
Things work a little bit differently when contradictions occur though. When contradictions occur, the higher level policy overrides the lower level policy for the contradictory policy setting. Any policy settings that are not contradictory are merged together in the usual way. For example, if the local security policy indicated that passwords must be eight characters long and must be changed every 30 days, and the site level policy indicated that passwords must be 10 characters long, then the effective policy would be that passwords must be 10 characters long and must be changed every 30 days. The effective policy keeps the 30 day rule because the two policies are merged together. However, the ten character rule overrides the eight character rule because the policy requiring ten character passwords exists at a higher level of the group policy hierarchy (the site level) than the policy requiring eight characters.
Although this is a basic description of how the effective policy is calculated, it is actually a little bit more complex than that. Windows allows group policies to be applied to users and to computers. Therefore, it is possible that you could have both a user policy and a computer policy at each level of the group policy hierarchy. User and computer policies are merged together at each level of the hierarchy before higher level policies are processed.
So if the higher level policies are always dominant then you might be wondering why you shouldn’t just use high level policies exclusively and avoid all of the confusion. Well, there are a couple of reasons for this. The first reason for not using high level policies exclusively is that they apply broadly. For example, if you were to set the password length policy at the OU level, then you would lose the ability to have different minimum password lengths set for various domains.
A more important reason for not using high level policies exclusively is that when a user is not logged into a domain, then the local computer policy is your primary security mechanism. If you don’t assign a local security policy to each workstation, then it is possible for user’s to operate the machine in a very insecure manner. Sure, the higher level policies will kick in as soon as the user logs into the domain, but you need policies that will protect the machine prior to login.
Viewing The Resultant Set of Policy
Hopefully, after reading the previous section, you understand just how complicated group policies can be. I’m also hoping that you understand how this complexity can make it extremely difficult to determine the effective policy for a user. As I mentioned earlier in the article though, the RSOP tool can make your life a lot easier by automating the process of calculating the effective policy.
The RSOP console only ships with Windows Server 2003. This doesn’t mean that you are limited to using it in domains that are running Windows Server 2003 exclusively though. You can use the RSOP tool on domains running a mixture of Windows 2000 and Windows 2003 Servers.
The easiest way to use the RSOP tool is to open the Active Directory Users and Computers console and navigate to the Users container. Next, right click on the user whose account you want to analyze and then select the All Tasks | Resultant Set of Policy (Logging) commands from the resulting shortcut menus.
As I mentioned before, the effective policy is only partially based on the policies assigned to a user. The computer level policies also go into determining the effective policy. Therefore, the first screen that you will see asks you which computer you want to use in determining the effective policy. You can choose to use the computer that you are currently using, a different computer, or you can choose to ignore the computer portion of the policy all together. Figure A shows what this screen looks like.
Figure A: You must initially select which computer you would like the policy calculated for
Click Next and you will see a quick summary of the user and settings that you have chosen. Click Next one more time and the RSOP tool will gather the necessary information and display the Resultant Set of Policy console, as shown in Figure B.
Figure B: The Resultant Set of Policy console shows the user’s effective policy
As you can see in the figure, the Resultant Set of Policy console looks just like the Group Policy Editor. The difference is however, that the security settings that you are viewing through this console reflect the selected user’s effective policy.
Now that I have shown you how to view a user’s effective policy, you may be wondering what you can do if the effective policy doesn’t reflect the settings that you expect. For example, in Figure B, you will notice that the user Bob is configured to have his account locked out after 5 bad logon attempts. What if I had been expecting it to say three bad logon attempts though?
In such a situation, I would obviously need to know where the unexpected setting was coming from. To find out, simply right click on the setting and select the Properties command from the resulting shortcut menu. When you do, you will see a properties sheet that displays the security setting in greater detail. This properties sheet won’t let you change the setting, but if you select the Precedence tab, you can find out which group policy object contains the offending setting. For example, in Figure C, you can see that the policy setting is coming from the Default Domain Policy.
Figure C: The Precedence tab displays where the policy setting is coming from
Policy Planning
Earlier, when you right clicked on the user account and chose the All Tasks command from the shortcut menu, you might have noticed an option named Resultant Set of Policy (Planning). I don’t want to bore you with the details of using this option because it works similarly to the Resultant Set of Policy (Logging) option that I have already shown you. I did at least want you to be aware that this option exists though. The Policy Planning option allows you to see the effect of security changes before you make them. For example, if you were planning on moving the user to a different location on the network, the move could potentially cause drastic changes to the user’s effective policy. This tool allows you to view the consequences of such an operation without actually having to perform the operation.
Conclusion
In this article, I’ve explained that the hierarchical nature of group policy objects tends to make determining a user’s effective policy confusing. I then went on to demonstrate how to use the RSOP tool to determine the effective policy and to track down unexpected group policy settings if necessary.
