Design Considerations for Organizational Unit Structure and Use of Group Policy Objects

Design Considerations for Organizational Unit Structure and Use of Group Policy Objects

OU Structure

• 
  To enable delegation of administration.
  
• 
  To scope the application of GPOs.
  

In most organizations, OU structure is likely to fall into one of the following categories:

• 
  Flat OU structure: 1 or 2 levels
  
• 
  Narrow OU structure: 3 to 5 levels
  
• 
  Deep OU structure: more than 5 levels
  

For organizations with moderate administration requirements, it is recommended that administrators use a narrow OU structure and Group Policy objects are linked at the site, domain, or OU level as necessary. Limited use of the Block Policy Inheritance options, the Enforce Policy options, and security groups to filter GPOs is recommended.

For organizations with complex administration requirements, the Active Directory namespace may use flat, narrow, or deep OU structures. In such cases, administrators should consider the following issues:

• 
  Flat OU model: use security groups and DACLs to filter effects of GPOs as a primary method, and Block Policy Inheritance and Enforce Policy options as secondary methods.
  
• 
  Narrow OU model: link to GPOs at site, domain, and OU. As a secondary method, use Block Policy Inheritance and Enforce Policy options, and security groups and DACLs for filtering effects of GPOs.
  
• 
  Deep OU model: link to GPOs at site, domain, and OU with security groups filtering and DACLs. As a secondary method, use Block Policy Inheritance and Enforce Policy options.
  

Design Principles

Administration of Group Policy Objects

Delegation of authority, separation of administrative duties, central versus distributed administration, and design flexibility are important factors you’ll need to consider when designing Group Policy and selecting which scenarios to use for your organization.

How you design your OU structure and GPOs will depend on the administrative requirements and roles in your corporation. For example, if administrators are organized according to their duties (such as security administrators, logon administrators, and so on), you may find it useful to define these policy settings in separate Group Policy Objects.

Delegation of authority will depend largely on whether you use centralized or distributed administration in your corporation. Based on their particular corporate requirements, network administrators can use security groups and Discretionary Access Control List permissions to determine which administrator groups can modify policies in Group Policy objects. Network administrators can define groups of administrators (for example, Software Installation administrators), and then provide them read and write access to selected Group Policy objects, allowing the network administrator to delegate control of the Group Policy object settings. Administrators who have read and write access to a Group Policy Object can by default control all of the contents of that Group Policy Object; however, you can restrict access by setting policy to control which MMC snap-ins can be loaded by that user, as previously described in the Delegating Group Policy section.

Separate Users and Computers into Different OUs

It’s recommended that you separate users and computers into separate OUs. This is useful for these reasons:

• 
  This simplifies GPO design because you need to focus on only configuration of either user or computers.
  
• 
  Typically users and computers are administered differently, perhaps by different groups within your organization, which facilitates administration.
  
• 
  You can reduce group policy processing time because you can disable the unused half of the GPO. It is possible to disable only the User or Computer portion of the GPO. To do this, right-click the GPO, click Properties, click either Disable Computer Configuration settings or Disable User Configuration settings, and then click OK. These options are available on the GPO Properties page, on the General tab.
  
• 
  This type of design is required to enable loopback processing. See the Group Policy Loopback Support section for more information.
  

Functional versus Geographical OU Structure

When organizing OUs, there are two basic models to start with: functional and then geographical, or geographical and then functional. The key is never to implement a structure that forces an artificial layering, which means that the OU structure for computers may be very different than that for users—it all depends on how they are administered.

Minimize the Number of Group Policy Objects Associated with Users or Computers

You should note that the number of Group Policy objects that are applied to a user affects the logon processing time. (Similarly, the number of GPOs applied to a computer affects boot time). The greater the number of associated Group Policy objects, the longer logon will take to process them. During logon time, each GPO from the user’s site, domain, and OU hierarchy is applied, provided the user has both the Read ACE and the Apply Group Policy ACE. Note that if the Apply Group Policy ACE is not set, but the Read ACE is, the GPO will still be processed (although not applied), thus impacting logon time. Therefore, if you implement filtering based on security groups, you should also clear Read Access for those users that you clear Apply Group Policy for.

Minimize the Use of the Block Policy Inheritance Feature

As mentioned previously, you can prevent Group Policy settings of parent Active Directory containers from affecting users and computers in lower-level parent Active Directory containers. This is a useful and powerful feature that you should use judiciously only when a particular situation requires it. Blocking the inheritance of policy from parent Active Directory containers can complicate troubleshooting policy.

Minimize the Use of the No Override Feature

You can also ensure that the policy settings you specify in a given Group Policy object at a higher-level parent Active Directory container are enforced on lower-level parent Active Directory containers by using the No Override option. Only use this powerful feature when circumstances require it. Overuse of this feature with other related features, such as Block Policy Inheritance, can complicate troubleshooting policy.

Use Loopback Processing Only When Necessary

You can set User Configuration per computer and thus override user-specific policies with computer-specific policies. This is useful when you want to provide a specific desktop configuration regardless of which users log on to the computer. To set User Configuration per computer, you would use the Administrative Templates node under Computer Configuration in the Group Policy snap-in. For more information on this feature, see Group Policy Loopback Support.

Avoid Using Cross-Domain GPO Assignments

Although you can assign Group Policy objects from different domains to a single Active Directory container if a particular situation requires it, you should note that in such cases Group Policy processing would be slower. This is because domain boundaries are crossed.

Design Examples

This section presents several models of GPO design. These examples are not intended as guidelines, but they do illustrate various ways to approach GPO design. In most corporate environments, administrators may use a combination of these or similar models, tailored to their business requirements.

The key overriding approaches are either functional or geographic models. The rest are usually variants of those.

Layered GPO Design Model

The objective of this design model is to create Group Policy objects based on a layered approach. This approach optimizes maintenance of Group Policy objects and facilitates delegation.

The following graphic illustrates an example of this model.

Monolithic GPO Design Model

The objective of this design is to create Group Policy objects based on a monolithic design—an approach that reduces the number of Group Policy objects that apply to a user and/or computer but may not be optimal for delegation.

The following graphic illustrates an example of the monolithic GPO model.

Single Policy Type GPO Design Model

The objective of this design is to create Group Policy objects that deliver a single type of Group Policy, for example, policy for security settings. Such a design optimizes separation of duties for administrators; however, it may increase the number of GPOs that are applied to a given user or computer.

Each Group Policy object delivers only one type of policy (security Group Policy objects are different from script Group Policy Objects, for example). Large corporations often create separate administrator groups based on administrative duties; this scenario would be useful in such corporate environments.

The following graphic illustrates an example of the single policy type GPO model.

Multiple Policy Types GPO Design Model

The objective of this design is to create Group Policy objects that deliver multiple types of policy. This is a hybrid of the single policy and monolithic models. Each Group Policy object delivers several types of policy settings.

For example, you can create a Group Policy object that includes Group Policy settings for software settings and application deployment and create another GPO that includes security and scripts settings, and so on. A Group Policy object design that supports multiple policy types is useful in delegating administration environments and can reduce the number of Group Policy objects that apply to a user and/or computer.

The following graphic illustrates an example of the multiple policy types GPO model.

Teams or Matrix Organizations GPO Model

This model applies to organizations that leverage the virtual team concept. Individuals within the organization form teams to perform a task or project and each individual is a member of multiple teams. Each team has specific Group Policy requirements. The OU architecture does not reflect the team structure. This model works by using security group filtering.

The following graphic illustrates an example of the team GPO design model.

Public Computing Environment GPO Model

This scenario applies to environments were you want the computer Group Policy settings to always have precedence over the user Group Policy settings. This scenario is useful for training classes and kiosk-type environments in which you want to provide the same desktop environment regardless of which user logs on to the computer.

The following graphic illustrates an example of the GPO design for a public computing environment. The loopback policy feature with Replace mode is used in this example. See Group Policy Loopback Support for more information.

N
ormal Group Policy processing specifies that users in the Sales OU get these GPOs: Domain Policy GPO, Accounting GPO, and Sales GPO. With the loopback policy enabled in Replace mode, when users from the Sales OU log on to a computer in the Kiosks OU, the user will process only these GPOs: Domain Policy GPO, Accounting GPO, Resources GPO, and Kiosks Loopback Policy GPO—the users’ list of GPOs is not gathered in this case. More specifically, the user settings specified in the Kiosks OU (and those inherited) are the only GPOs processed for the user logging onto computers in that OU. Those in the Users OU tree are not processed.

Delegation with Central Control

This model applies to organizations that choose to delegate administration of GPOs, but would like to enforce certain Group Policy settings throughout the domain (for example, specific security policies).

The following graphic illustrates an example of GPO delegation with centralized control, and use of the No Override option.

Delegation with Distributed Control

This scenario applies to organizations that want to allow administrators of organizational units to prevent Group Policy settings from being applied to their OU. The administrator of an OU can block Group Policies that have been assigned at higher levels in the hierarchy from applying to his or her OU. However, the administrator cannot block group policies that are marked as No Override.

This feature allows organizations to minimize the number of domains without sacrificing autonomy.

Download 4.15 Mb.