Testing Level of Administrative Access

It is always a recommended best practice to test changes that will affect Active Directory. Because administration has direct implications for network security, it is paramount that delegations of administration changes are made to withstand rigorous test procedures. This section will highlight some methods by which to ensure such delegations are made in a secure manner.

Testing Changes in a Lab Environment

It is commonly understood that testing is a necessary stage in any IT deployment scenario. The test lab is an investment that can pay for itself many times over in reduced support and redeployment costs that arise from poorly tested solutions. You should always be sure to test your proposed design in an environment that simulates, as well as protects, your production environment. You can verify your design by devising and conducting tests that reflect the conditions of your production IT resources. Although this truism is usually incorporated into the deployment plans of large migrations, it is just as important to keep your testing environment in service post-deployment for ongoing testing of changes that affect security and administration in Active Directory.

The prototype lab environment should resemble the production environment insofar as primary components such as a Windows Server 2003 domain controller, file server, network equipment, and test workstations are represented. Lab components of course will vary depending on services in use and the complexity of the production architecture. The lab network should be isolated from the production network so as not to cause potential naming conflicts, replication errors, or database corruption. Though isolated, good lab environments will contain real data and applications. Data can be copied from live production servers, or data from tape can be restored into the testing environment.

When Testing Delegation of Control and Group Policy Results...

it is helpful to have the same security principles in both the test and production directories. You will get better results if group names and group memberships from both environments match.

It is important to keep your lab environment up to date with the latest patches and changes that are deployed in the production environment. If your lab domain computers are at a different revision level in service pack from the production domain computers, your test results might be inconsistent with the real world.

Documenting Test Processes and Results

When testing modifications to the default administrative settings in the lab environment, it is important to document the processes by which the tests were conducted . If problems result in the production domain that did not manifest in the lab domain, you can return to your test procedures documentation to verify whether the correct steps were followed. Documenting the procedures and maintaining a database of the tests that have been performed will help you when similar tests are required at a later date.

Carefully Documenting Test Procedures Is Extremely Important

Carefully documenting test procedures is extremely important if the testing is being carried out by a different group than the one responsible for implementing the changes. The documentation will serve as the step-by-step procedures used to replicate the test procedures in the production environment. If the documentation is not followed, the results of the production implementation might have different results than discovered in the test process.

As changes are implemented in the production environment, documentation should be maintained to precisely log when and what has been implemented. Although individual tests and directory modifications made at discreet times might prove successful, the combination of different changes made over time might have unexpected results. Also, the ramifications of some changes are not completely flushed out immediately. It might take days or weeks before a problem manifests itself. Keeping a log of the changes that have been made over time will expedite any troubleshooting should a conflict arise.

Group Policy Modeling

Windows Server 2003 provides tools for testing and troubleshooting your group policy changes. These are Group Policy Modeling (also referred to as Resultant Set of Policy Planning Mode) and Resultant Set of Policy. Although these tools are detailed in Chapter 6, it is important to highlight them here as tools to test and troubleshoot Delegation of Control and Group Policy settings.

Integrated into the Group Policy Management Console, Group Policy Modeling (also referred to as Resultant Set of Policy-Planning Mode) enables you to simulate a policy deployment that would be applied to users and computers before actually applying the policies. The Group Policy Modeling Wizard can be opened from the Group Policy Modeling container, the domain node, or from any OU. When the Group Policy Modeling Wizard is started from one of these containers, the wizard automatically passes the scope of management data to the wizard and pre-populates the User and Computer Selection page of the wizard.

After you run a simulation, an HTML report is generated that gives a summary that contains the GPOs and security group memberships. The simulation also generates a Settings report, shown in Figure 4.9, that shows the simulated Resultant Set of Policy given the policies that were chosen in the wizard. For more information on Group Policy modeling, turn to Chapter 6.

Figure 4.9. Simulating Policy assignment through Group Policy Modeling.

Resultant Set of Policy (RSoP)

This feature enables you to determine the resultant set of policy that was applied to a given computer and ( optionally ) user that logged on to that computer. The data that is presented is similar to Group Policy Modeling data; however, unlike Group Policy Modeling, this data is not a simulation. It is the actual resultant set of policy data obtained from the target computer. Unlike Group Policy Modeling, the data from Group Policy Results is obtained from the client, and is not simulated on the DC. The client must be running Windows XP, Windows Server 2003 or later.

Group Policy Results Data

It is not possible to get Group Policy Results data for a Windows 2000 computer. However, with Group Policy Modeling, you can simulate the RSoP data.

Resultant Set of Policy is an ideal tool for documenting the Group Policy settings that affect administration in a Windows Server 2003 Active Directory as it generates easy-to-use HTML reports . The tool can also be used to troubleshoot access and permissions problems in environments where multiple GPOs and delegated permissions are assigned to various containers in the directory. For more information on RSoP, see Chapter 6.