The Administrator Shortcut Guide to Active Directory Security Chapter 3

{LANG_NAVORIGIN} Operating System Microsoft
By: Derek Melber, Dave Kearns, and Beth Sheresh, 04/14/2005

Effective OU Design Is Critical

With this knowledge of the key aspects of GPO basics, we’re ready to switch directions to the foundation for implementing GPOs. Without an OU design and structure to link GPOs, there is little that can be done to control security, software, and other OS settings that are controlled by GPOs.

As you consider your OU design, don’t forget about the overall AD design, which includes other domains and possibly other forests. You will need to consider how GPOs in these other domains will be updated and stay consistent across the entire company.

The OUs are the most important aspect of the AD design when considering the implementation of GPOs. We can’t negate the other reason that OUs are organized and created, which is for delegation of administration. As you start to design your OUs, you will need to make a list of all of the delegation that needs to occur. This list will include delegation for user, group, and computer accounts, as well as for OU, GPO, and AD administration. The result of these considerations will be an OU structure. Next, the full list of GPOs and GPO settings will need to be established. This list will include categories of what needs to be controlled by GPOs. The following list provides all the areas that a GPO can control:

• Application management
• Disk quotas
• EFS recovery
• Folder redirection
• Internet Explorer (IE) settings
• IP Security (IPSec)
• Registry settings (administrative templates)
• Scripts
• Security

>From these possible GPO areas of configuration, you will determine how the GPOs should be applied and to which target objects. You need to consider only the placement of computer and user accounts, because these are the only two objects that can receive GPOs. When you consider which GPO settings will affect which target objects, consider the following categories (and potential OUs) for organizing the GPO application:

Computer account categories

• Server role (IIS, Exchange, SQL, and so on)
• Client computers
• IT staff client computers
• Secured client computers
• HR servers
• Branch office client computers

User account categories

• IT staff
• Developers
• Executives
• Service accounts
• Employees
• Branch office employees

After considering both the delegation of administration and the GPO implementation factors for the OU design, the two OU structures need to be merged. For smaller organizations, this task will not be difficult if there are only a few delegations and GPO categories. For larger organizations, this task can result in a very complex structure that consists of many conflicting OUs, where an OU contains accounts for delegation reasons that break the GPO implementation strategy.

For areas of the AD design in which delegation and GPO considerations conflict, there are some possible solutions:

• Create a hierarchy of OUs in which the top-level OU consists of the delegation and the sub-OUs are where the GPOs are linked. This setup will provide a solution for both delegation and GPO implementation for specific accounts.
• Use GPO security group filtering to control which accounts in the OU will receive the settings in the GPO. This option is not the preferred method, but in some cases, it is the only possible solution.

When a conflict can’t be resolved, the delegation should win the conflict, because GPOs can be filtered with security groups.

Even for the small AD implementations, the complexity of delegation and GPO administration can overwhelm the built-in administration tools. Microsoft has developed the GPMC to help with the administration of many of the GPO tasks, but there are still holes. To fill these holes, you should look into other GPO management tools from companies such as ScriptLogic, Full Armor, and Quest Software. These tools can provide options that the Microsoft tools lack. The following list highlights some of the capabilities that these tools can provide:

• GPO version control
• Offline GPO change management
• Documentation
• Auditing

In the next couple of sections, we will discuss the need for some of these capabilities and why they should be considered to ensure a secure AD environment.

Implementing Group Policy

A single GPO has 766 policy settings. The new Windows XP SP2 will include an astounding additional 609 GPO policy settings. With all of these settings, a test environment is essential. If you couple the raw number of GPO policy settings with the complex interaction of GPOs from LSDOU, block inheritance, and no override, you can clearly see that a test lab environment is essential for stable and correct GPO application. Unfortunately, native AD tools don’t provide this lab environment to test settings before they are rolled out. The test lab environment will provide the following benefits for GPO implementation:

• Test complex LSDOU interaction before implementing to production
• Determine the Resultant Set of Policy (RSoP) for the user and computer accounts to ensure compatibility with applications and network access
• Verify inheritance and control of inheritance is correct before moving GPOs to the production environment
• Test different domain interactions with consistent GPO configurations
• Provide a “central” location for developing GPOs that will be consistent across multiple domains and forests
• Different versions of the same GPO can be tested and the RSoP can be evaluated for optimum control over security and other GPO policy settings before being released to production
• New GPO settings, distributed with service packs and applications, can be tested for compatibility and stability before being placed into production

Migrating Group Policy Between Domains

During the design of AD, you will be forced to have a single domain, multiple domains, or possibly multiple forests. These decisions can be forced for a variety of security or political reasons. Even though you might have multiple domains for these reasons, many of the GPOs that are implemented will need to be consistent across the domains. GPOs can be created in one domain, or even in the test lab environment. They will eventually need to be moved, or migrated, to all of the domains to ensure consistency of security settings across the entire AD infrastructure. The following sections include items to consider when migrating GPOs between domains.

GPO Consistency

If you have multiple domains, you will want to have GPOs consistent through all of the domains (as much as possible). For administrative, security, and sanity reasons, you will need to have a process in place to ensure that GPOs are all the same. The reasons that GPOs need consistency between domains include:

• Security—The only method that provides consistent security settings for all computers in the enterprise is the use of GPOs. With 1000 policy settings, you don’t want to miss one single setting. The ability to migrate a single GPO for security to multiple domains will provide the coverage of security that the network deserves.
• Stability—Administrators are not without error, and with so many GPO policy settings to choose from, errors are easy to make. A single errant configuration can cause a computer to not communicate on the network, causing loss of time, money, and data.
• Efficiency—When it comes time to troubleshoot a network or application problem that is rooted with a conflicting GPO setting, administrators and Help desk professionals will benefit from consistent GPOs. When GPOs are migrated from one domain to another, allowing consistent configurations across all environments, the troubleshooting process is much easier.

GPO Tracking

When a GPO is created, it is given a unique identification number. This number is referred to as a Global Unique Identifier. GUIDs are not friendly to humans, as they are rather long. For example, the GUID for the Default Domain Policy GPO is {31B2F340-016D-11D2-945F- 00C04FB984F9}. Each GPO is given a GUID as it is created in the domain so that it can be tracked by the OS. The OS must track two locations for GPOs. One is in the AD and one is in the SYSVOL folder on the domain controllers. Each location refers to GUIDs—not the name of the GPO—for tracking GPOs.

When a GPO is migrated from one domain to another, this GUID needs to be created by the OS. Creating a new folder for the new GPO and copying the contents of the source GPO to the new folder will not suffice for migrating a GPO from one domain to another. Doing so will not create the required GUID and embed it in the AD for tracking purposes.

Tools, such as the GPMC and other GPO management tools from third-party vendors, provide an easy method to migrate GPOs from one domain to another. These tools handle the registration of the GPO, affording the creation of the GUID and correct entries in AD for tracking.

GPO Permissions

When a new object is created in a domain, it must be tracked by the OS. There is more to an object in AD than a GUID. There is also a Security Identifier (SID) that helps control access to resources. GPOs don’t have SIDs, but they do have an ACL, which contains lists of SIDs. This list of SIDs must be relative to the domain in which the object is created.

GPO management tools provide a seamless process to take care of this small, yet important detail. If the permissions for the GPO ACL were not fixed, the GPO would not be implemented to any computer or user account due to incorrect SIDs on the ACL.

GPO Management

After a GPO is migrated to the target domain or domains, there is still work that needs to be done. The GPO must be linked to the proper SDOU. Although the built-in tools provide this capability, they don’t make the task easy. You must remember all the considerations for GPO management:

• Linking to SDOU
• Block policy inheritance
• No override
• Security group filtering
• WMI filtering

If you have a multitude of GPOs that either reside in a single domain or are migrated from domain to domain, the standard tools for these tasks can cause more harm than good due to their inability to easily control these GPO functions. Third-party tools can provide a significant advantage to the management of these functions. The GUIs are designed around GPOs and incorporate small icons, color changes, and menu options that make management of these features easier.

















Your IP address will be sent with this e-mail

From e-mail to e-mail