Group Policy Object modeling simplifies network security

When it comes to securing a network, simplicity is usually the best approach. Take Group Policies for example. Group Policy Objects (GPOs) can be applied at the organizational unit (OU), site and domain levels of the Active Directory, as well as the local computer level.

When a user logs in, Windows combines all of the different Group Policies that apply to the user account with those that apply to the computer that the user is logging in from. While this might not sound so bad at first, each level of the Group Policy hierarchy contains many of the same settings. That means there is a potential for the administrative staff to implement contradictory Group Policy settings.

In smaller companies, administrators might be able to avoid Group Policy contradictions by using a single GPO, but this usually isn't practical in larger organizations.

The problem isn't really the contradictory settings themselves. Windows uses a set of rules to determine which policy setting takes precedence in the event of a contradiction. What can be a problem is figuring out what the effective policy is going to be once all of the various GPOs are combined and you're dealing with the contradictions. I have personally run into situations in which completely unexpected Group Policy settings were being applied, and figuring out where those settings came from was a real challenge because of the complexity of the Group Policy structure being used.

Fortunately, you no longer have to troubleshoot Group Policy settings manually. Instead, you can use a technique called Group Policy Object modeling to troubleshoot your settings quickly and easily. More importantly, though, you can use this technique to test Group Policy settings before they are applied. That way, you know that the settings you are about to implement will have the intended effect.

You can perform GPO modeling from within the Group Policy Management Console (GPMC). When you open the console, right-click on the Group Policy Modeling container and select the Group Policy Modeling Wizard option from the shortcut menu.

When the wizard loads, click Next to get past the Welcome screen. That will take you to the wizard's Domain Controller Selection screen, as shown in Figure A. Pick the domain you want to run the simulation against and choose either the Any Domain Controller Running Windows Server 2003 or Later option. You can also choose a specific domain controller within your selected domain.

Normally, the Any Available Domain Controller option will work fine. The only time you would need to specify a particular domain controller would be in situations where DCs were connected by a slow network link or when a domain controller was having replication problems.

Figure A (click to enlarge)
 

The next screen will ask you to provide some information about the objects you want to run the simulation against. Since Group Policies can apply to user objects and computer objects, you must specify both in order to learn how your Group Policy settings are going to play out. As an alternative, you can specify the Active Directory container that stores the user and computer objects that you want to analyze.

Figure B (click to enlarge)

In most cases, you can get away with specifying an individual user and computer. This is especially true if your users and computers are configured in a uniform manner. In larger organizations, though, you may have multiple user containers or multiple computer containers within the Active Directory. In those situations, specify the distinguished name of the container that stores the user or computer objects that you want to run the simulation against. For example, if you wanted to run the simulation against the users container in the Contoso.com domain in Figure B, then the distinguished name of that container would be CN=Users,DC=Contoso,DC=com.

Click Next, and specify whether or not you want the test to assume that a dial-up connection is in use. You can also choose to use loopback processing. Be sure to take a look at the site drop-down list, because GPOs can be applied at the site level, and you may not get accurate results unless you select the correct Active Directory site from the list.

Even if you don't have any Group Policy Objects assigned at the site level, pay attention to the site setting. Site links typically reflect low-speed connections between network segments. Choosing the correct site ensures that the test queries a domain controller in your local site rather than a remote site.

Next, you will be prompted to select the security group memberships that you want to test. The Authenticated Users group and the Everyone group are both tested by default, but you can test any additional security groups by adding them to the list. Once you have populated the list of security groups, click Next. While the screen initially appears to be a duplicate, look closer. It actually gives you a chance to specify any computer-related security groups that you want to test, whereas the previous screen was dedicated to the user's group memberships.

You will be prompted to enter any Windows Management Instrumentation (WMI) filters that you want to use. Typically, you won't have to worry about WMI filters for general testing, so just move on past this screen.

Finally, the wizard takes you to a summary screen. Getting accurate test results depends on entering the correct information, so take a moment to make sure everything is correct. Click Next, followed by Finish to complete the process.

When you are done, Windows will create a container beneath the Group Policy Object Modeling container that bears the name of the users or computers you are testing. If you click on this container, you can see the results of your query, as shown in Figure C.

Figure C (click to enlarge)

The screen shown in Figure C gives you some basic summary information. For instance, you can see which security group memberships were used during the simulation. This is important, because there will probably be some security groups used, even if you don't specify any individually.

The Summary tab also shows you which specific Group Policy Objects were used in compiling the effective policy. Pay attention to that because it allows you to verify that it's reading all of the GPOs that should be applied to the situation.

If you want to drill down into the actual policy settings, the Settings tab will show you the effective policy settings and where they came from (see Figure D). In case you are wondering, the Query tab is there to remind you of the criteria used to achieve the test results (such as which users and computers the tests were based on).

Figure D (click to enlarge)

When Windows compiles multiple Group Policy Objects, it does so in a specific order, taking a "most recent change wins" approach to resolving conflicts. For example, if the local policy and a domain-level policy contained contradictory settings, then the domain-level settings would take precedence because the domain policy is processed later in the sequence than the local security policy.

In Figure D, you can see various policies and their corresponding settings listed. The "winning" GPO column tells you which Group Policy Object is responsible for applying those settings. Keep in mind that this will not always be the highest GPO in the hierarchy. It might list a lower-level Group Policy Object if it applies a setting and none of the higher-level policies address that particular setting.

ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.