Lesson 1: Defining OU Structures

The first step in creating an OU plan is to define OU structures. When you define OU structures, you define the OUs needed for each domain in your organization. This lesson discusses how to define OU structures, which includes defining OU structures to delegate administration, defining OU structures to hide objects, and defining OU structures to administer group policy.


After this lesson, you will be able to

  • Identify the three reasons for defining an OU
  • Explain the guidelines for defining OU structures
  • Identify the factors in an organization's environment that impact its need for OUs
  • Identify the tasks in the process of defining OU structures
  • Analyze an organization's environment to define its OUs

Estimated lesson time: 30 minutes


Understanding OUs

Recall that an organizational unit (OU) is a container used to organize objects within one domain into logical administrative groups. An OU can contain objects such as user accounts, groups, computers, printers, applications, file shares, and other OUs from the same domain. There are three reasons for defining an OU:

  • To delegate administration
  • To hide objects
  • To administer group policy

OUs can be added to other OUs to form a hierarchical structure; this process is known as nesting OUs. Each domain defines its own OU structure—the OU structure within a domain is independent of the OU structures of other domains.

Defining OUs to Delegate Administration

The primary reason for defining an OU is to delegate administration. Delegating administration is the assignment of IT management responsibility for a portion of the namespace, such as an OU, to an administrator, a user, or a group of administrators or users. In Windows 2000, you can delegate administration for the contents of an OU container (all users, computers, or resource objects in the OU) by granting administrators specific permissions for an OU on the OU's access control list. An access control list (ACL) is the mechanism for limiting access to certain items of information or certain controls based on users' identity and their membership in various groups. Access control entries (ACEs) in each ACL determine which users or groups can access the OU and what type of access they have.

Because ACEs are inherited by child OUs in an OU hierarchy by default, you can apply permissions to an entire tree of OUs, as shown in Figure 5.1. Inherited ACEs apply only to one domain and do not flow down to child domains. To prevent permissions from being inherited by child objects, you can clear the Allow Inheritable Permissions From Parent To Propagate To This Object check box on the Security tab of the Properties dialog box for the OU.

Figure 5.1 Inheriting permissions and blocking inheritance

To delegate administration, you can use the Delegation of Control Wizard or manually modify the access control entries on the Security tab of the Properties dialog box for the OU.

OU Hierarchy Models for Delegation of Administration

Once you determine the OUs needed for your organization, you can add OUs to other OUs to form a hierarchy of administrative control. Hierarchies for delegating administration can reflect various organizational models:

  • Location. This structure may be used if administration within a domain is handled by location, as shown in Figure 5.2. The top-level OUs—West, Central, and East—correspond to the regions set up for the microsoft.com organization. The second-level OUs represent the physical locations of the company's eight offices.

    click to view at full size

    Figure 5.2 An OU structure based on location

  • Business function. This structure may be used if administration within a domain is handled by business function, as shown in Figure 5.3. The top-level OUs—Admin, Devel, and Sales—correspond to microsoft.com's business divisions. The second-level OUs represent the functional divisions within the business divisions.

    click to view at full size

    Figure 5.3 An OU structure based on business function

  • Object type. This structure may be used if administration within a domain is handled by the types of objects being managed, as shown in Figure 5.4. The top-level OUs—Users, Computers, and Resources—correspond to the types of objects used at microsoft.com. The second-level OUs represent further detailing of the object types.

    click to view at full size

    Figure 5.4 An OU structure based on types of objects

  • A combination of location, business function, and object type. This structure may be used if administration within a domain is handled by a combination of hierarchy models, as shown in Figure 5.5. The top-level OUs—North America and Europe—correspond to the continents on which microsoft.com has offices. The second-level OUs represent the functional divisions within the company.

    click to view at full size

    Figure 5.5 An OU structure based on location and business function

Defining OUs to Hide Objects

Your organization may require that certain domain objects be hidden from certain users. Although a user may not have the permission to read an object's attributes, the user can still see that the object exists by viewing the contents of the object's parent container. You can hide objects in a domain by creating an OU for the objects and limiting the set of users who have List Contents permission for that OU.

Defining OUs to Administer Group Policy

Recall that group policies are collections of user and computer configuration settings that can be linked to computers, sites, domains, and OUs to specify the behavior of users' desktops. To create a specific desktop configuration for a particular group of users, you create group policy objects (GPOs), which are collections of group policy settings. By linking GPOs to OUs, GPOs can be applied to either users or computers in the OU.

How Group Policy Is Processed

Group policy settings are processed in the following order:

  1. Local GPO
  2. Site GPOs
  3. Domain GPOs
  4. OU GPOs

GPOs linked to the OU highest in the Active Directory hierarchy are processed first, followed by GPOs linked to its child OU, and so on. Finally, the GPOs linked to the OU that contains the user or computer are processed. At the level of each OU in the Active Directory hierarchy, one, many, or no GPOs can be linked. If several group policies are linked to an OU, they are processed synchronously in an order specified by the administrator.

Figure 5.6 provides an example of how group policy is processed.

click to view at full size

Figure 5.6 Group policy processing

Group Policy Inheritance

In general, group policy is passed down from parent to child containers. Group policy is inherited in the following ways:

  • If a policy is configured for a parent OU, and the same policy is not already configured for its child OUs, the child OUs, which contain the user and computer objects, inherit the parent's policy setting.
  • If a policy is configured for a parent OU, and the same policy is configured for a child OU, the child OU's group policy setting overrides the setting inherited from the parent OU.
  • Policies are inherited as long as they are compatible. If a policy configured for a parent OU and a policy configured for a child OU are compatible, the child OU inherits the parent's policy, and the child's policy setting is also applied. For example, if the parent OU's policy causes a certain folder to be placed on the desktop and the child OU's policy calls for an additional folder, the users in the child OU see both folders.
  • If a policy configured for a parent OU is incompatible with the same policy configured for a child OU, the child OU does not inherit the policy setting from the parent OU. Only the setting configured for the child OU is applied.
  • If any of the policy settings of a parent OU are disabled, the child OU inherits them as disabled.
  • If any of the policy settings of a parent OU are not configured, the child OU does not inherit them.

Exceptions to Processing Order

The following are exceptions to the default processing order of group policy settings and may affect how GPOs are processed for OUs:

  • Member Computer of a Workgroup. These computers process only the local GPO.
  • No Override. Any GPO linked to a site, domain, or OU (not the local GPO) can be set to No Override with respect to that site, domain, or OU, so that none of its policy settings can be overwritten. When more than one GPO has been set to No Override, the one highest in the Active Directory hierarchy (or higher in the hierarchy specified by the administrator at each fixed level in Active Directory) takes precedence. No Override is applied to the GPO link.

    In Figure 5.7, No Override has been applied to the GPO 4 link to the Users OU. As a result, the policy settings in GPO 4 cannot be overwritten by other GPOs. Processing remains the same.

  • Block Policy Inheritance. At any site, domain, or OU, group policy inheritance can be blocked by selecting the Block Policy Inheritance check box on the Group Policy tab of the Properties dialog box for the site, domain, or OU. However, GPO links set to No Override are always applied and cannot be blocked by using Block Policy Inheritance.

    Block Policy Inheritance is applied directly to the site, domain, or OU. It is not applied to GPOs, nor is it applied to GPO links. Thus, Block Policy Inheritance deflects all group policy settings that reach the site, domain, or OU from above (by way of linkage to parents in the Active Directory hierarchy) no matter what GPOs those settings originate from.

    In Figure 5.7, Block Policy Inheritance has been applied to the Computers OU. As a result, GPOs 1 and 2, which are applied to the site and the domain, are deflected and do not apply to the Computers OU. Therefore, only GPOs 6 and 7 are processed for the Servers OU.

  • Loopback. Loopback is an advanced group policy setting that is useful on computers in certain closely managed environments such as kiosks, laboratories, classrooms, and reception areas. Loopback provides alternatives to the default method of obtaining the ordered list of GPOs whose user configuration settings affect a user.

click to view at full size

Figure 5.7 Applying No Override and Block Policy Inheritance

Guidelines for Defining OU Structures

Guidelines for defining OU structures include the following:

  • Design OUs for simplicity. Previous chapters emphasized the use of minimal numbers of forests and domains in your Active Directory design. However, it is likely that your domains will require a number of OUs to meet administrative requirements. The best practice is to begin with one OU and then add only those OUs that you can justify. You should note the specific reason for creating each OU that you add to your OU plan.
  • Assign control to groups rather than users to simplify management tasks. You should also delegate to local groups, rather than global or universal groups. Local groups are ideally suited for resource permissions because, unlike global groups, they can have members from any trusted domain and, unlike universal groups, local group membership is not replicated to the global catalog.

When defining OU structures for your organization, it's also important to keep the following in mind:

  • OUs are not security principals. That is, you cannot assign access permissions based on a user's membership in an OU. Access control is the responsibility of global, domain local, or universal groups.
  • Users will not use the OU structure for navigation. Although users can see the OU structure of a domain, the most efficient way for users to find resources in Active Directory is to query the global catalog. Therefore, you should define OUs with administration, not users, in mind.

Design Step: Defining OU Structures

To define OU structures, you must complete the following tasks:

  1. Define OU structures to delegate administration.
  2. Define OU structures to hide objects.
  3. Define OU structures to administer group policy.

IMPORTANT


Because there is only one way to delegate administration and there are multiple ways to administer group policy, you must define OU structures to delegate administration first. After an OU structure is defined to handle delegation of administration, you can define additional OUs to hide objects and to administer group policy.

Defining OU Structures to Delegate Administration

To define OU structures to delegate administration, you must complete the following tasks:

  1. Assess the organization's IT administration requirements to determine the type of administrative responsibility to delegate.
  2. Define OUs to delegate full control.
  3. Define OUs to delegate control for object classes.

Assessing IT Administration Requirements

To determine the type of administrative responsibility to delegate, you must first consult the IT Management Organization Worksheet compiled earlier by your design team and analyze how administrative tasks are accomplished. In addition to assessing the information compiled in this worksheet, it is imperative that you assess changes currently planned for IT management to address growth, flexibility, and the ideal design specifications of the organization. You will use these findings to determine the type of administrative responsibility to delegate.

NOTE


A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

There are two types of administrative responsibility you can delegate for an OU:

  • Full control
  • Control for object classes

By default, only domain administrators have full control over all objects in a domain. Domain administrators are responsible for creating the initial OU structure, repairing mistakes, and creating additional domain controllers. It is usually sufficient to allow only domain administrators full control over objects in a domain. However, if there are units in the organization that need to determine their own OU structure and administrative models, you can provide them with this permission by delegating full control.

When determining whether to delegate full control for an OU, you must determine which areas in the organization need to be allowed to change OU properties and to create, delete, or modify any objects in the OU.

If additional OUs are necessary to delegate more restrictive control, you can accomplish this by delegating control of specific object classes for an OU. Although there are many object classes in the schema, you need to consider only the object classes in which administrators will create objects. Such object classes typically include user account objects, computer account objects, group objects, and organizational unit objects. When determining whether to delegate control of object classes, for each object class that your administrators will create in Active Directory you must determine the following:

  • Which areas in the organization should be granted full control over objects of this class in the OU
  • Which areas in the organization should be allowed to create objects of this class and thus have full control over these objects
  • Which areas in the organization should be allowed to modify only specific attributes for or perform specific tasks pertaining to existing objects of this class

Defining OUs to Delegate Full Control or Control of Object Classes

After you determine the type of administrative responsibility to delegate, you can create OUs to delegate full control or control of object classes.

To define OUs to delegate full control or control of object classes

  1. Diagram the desired OU.
  2. Diagram a security group and list administrators who require full control or control of a specific object class in the group.
  3. If the OU is allowed to set its own membership, place the administrator group inside the OU. If the OU is not allowed to set its own membership, place the administrator group outside the OU.

Defining OU Structures to Hide Objects

To define OU structures to hide objects, you must complete the following tasks:

  1. Assess the organization's IT administration requirements to determine the need to hide objects from users.
  2. Define OUs to hide objects.

Assessing the Need to Hide Objects

To define OU structures to hide objects, you must first consult the Technical Standards Worksheet compiled earlier by your design team to determine the objects that must be hidden from users and the users from which the objects must be hidden. In addition to assessing the information in this worksheet, it is imperative that you assess changes currently planned for IT management to address growth, flexibility, and the ideal design specifications of the organization. You will use these findings to determine whether to define OUs to hide objects.

NOTE


A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

When determining whether to define OUs to hide objects, you must assess the following:

  • Which objects need to be hidden
  • Which groups need to access the OU where the hidden objects reside to perform specific administrative tasks
  • Which groups need read access to the OU where the hidden objects reside
  • Which groups need full control of the OU where the hidden objects reside

Defining OUs to Hide Objects

After you determine whether it's necessary to define OUs to hide objects, you can define the necessary OUs.

To define an OU to hide objects

  1. Diagram the OU in which you will place the objects to be hidden.
  2. List the groups that you want to have full control of the OU.
  3. List the groups that you want to have generic read access to the OU and its contents.
  4. List any groups that you want to have specific permissions, such as creating a specific object class, for the OU.
  5. Specify the objects that you want to hide in the OU.

Defining OU Structures to Administer Group Policy

To define OU structures to administer group policy, you must complete the following tasks:

  1. Assess the organization's group policy requirements and the existing OU structure you created to delegate administration to determine which group policies require the creation of additional OUs for administration.
  2. Define OU structures to administer group policy.

Assessing the Need to Define OU Structures to Administer Group Policy

To define OU structures to administer group policy, you must first consult the Technical Standards Worksheet compiled earlier by your design team and the existing OU structure you created to delegate administration and hide objects to determine which group policies require the creation of additional OUs for administration. In addition to assessing the information in this worksheet, it is imperative that you assess changes currently planned for IT management to address growth, flexibility, and the ideal design specifications of the organization. You will use these findings to determine whether to define additional OUs to administer group policy.

NOTE


A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

When determining whether to define OUs to administer group policy, you must determine the following:

  • What group policy settings are necessary for the domain
  • To which users or computers do the group policy settings apply
  • Which of the group policy settings are not handled by GPOs linked to the site, domain, or existing OUs created to delegate administration or hide objects

Defining OUs to Administer Group Policy

After you determine whether to create OUs to administer group policy, you can define the necessary OUs.

To define OUs to administer group policy

  1. Diagram the OU that will administer the desired group policy settings.
  2. List the users or computers to which the group policy setting(s) for the OU apply.
  3. Diagram a security group and place administrators who require control of the OU in the group.
  4. Diagram the GPO and indicate its group policy settings.
  5. Indicate the groups that have administrative control for the GPO.
  6. Indicate any processing exceptions (such as No Override or Block Policy Inheritance) for the GPO.
  7. Link the GPO to the OU.

Design Step Examples: Defining OU Structures

The following scenarios are examples of defining OU structures to delegate administration, defining OU structures to hide objects, and defining OU structures to administer group policy.

Defining OU Structures to Delegate Administration

Figure 5.8 shows an example of defining an OU structure to delegate full administrative control of the OU. The Silk unit of Miller Textiles was a recent acquisition, with locations in Tokyo and Osaka. The Silk unit is maintaining its own IT Management department. Therefore, Silk has become its own OU in the asia.m-100times.com root domain. The Silk Admins group is allowed to set its own membership and is set inside the Silk OU. The Tokyo Admins and Osaka Admins groups are not allowed to set their own memberships and are set in the Silk OU, outside of their respective OUs.

click to view at full size

Figure 5.8 Defining OUs to delegate full administrative control

Figure 5.9 shows an example of defining an OU structure to delegate control of object classes. The Tokyo location for the Silk unit of Miller Textiles currently contains two Windows NT 4 resource domains, Natural and Synthetic. When the organization migrates to Windows 2000, the resource domains will be consolidated and replaced by OUs. The Natural and Synthetic administrators currently use their domains to share files controlled by group membership and to reset passwords for team members. Groups were created to administer group objects and user objects and then granted the appropriate level of control for the Natural and Synthetic OUs.

click to view at full size

Figure 5.9 Defining OUs to delegate control of object classes

Defining OU Structures to Hide Objects

Figure 5.10 shows an example of defining an OU to hide objects. The na.m-100times.com domain has locations in San Francisco, Kansas City, and Raleigh. The OUs in the top half of the diagram were already defined to delegate administration. Because Miller Textiles requires administrative accounts in each location to be hidden from users, it was necessary to create three new OUs to hide the accounts.

click to view at full size

Figure 5.10 Defining OUs to hide objects

Defining OU Structures to Administer Group Policy

Figure 5.11 shows an example of defining OUs to administer group policy. The na.m-100times.com domain has locations in San Francisco, Kansas City, and Raleigh. The OUs in the top half of the diagram were already created to delegate administration. Because Miller Textiles requires one group policy to provide folder redirection for users in the Managers group and another group policy to publish software on management workstations, six new OUs were necessary to administer the group policies. Group Policy 1 redirects the My Documents folder for the Managers group only. Group Policy 2 publishes software for installation on managers' workstations only.

click to view at full size

Figure 5.11 Defining OUs to administer group policy

Lesson Summary

In this lesson you learned that defining OU structures is a three-step process: (1) define OU structures to delegate administration, (2) define OU structures to hide objects, and (3) define OU structures to administer group policy. Because there is only one way to delegate administration and there are multiple ways to administer group policy, you must define the OU structures to delegate administration first. After an OU structure is defined to handle delegation of administration, you can define additional OUs to hide objects and to administer group policy.

You learned how OU structures to delegate administration can be arranged in a hierarchy to reflect various organizational models: location, business function, object type, or a combination of any of the models. You also learned how you can hide objects in a domain by defining an OU for the objects and limiting the set of users who have List Contents permission for that OU. Finally, you learned how you can link GPOs to OUs to apply group policy settings to either users or computers in the OU.



MCSE Training Kit Exam 70-219(c) Designing a Microsoft Windows 2000 Directory Services Infrastructure
MCSE Designing a Microsoft Windows 2000 Directory Services Infrastructure Readiness Review; Exam 70-219 (Pro-Certification)
ISBN: 0735613648
EAN: 2147483647
Year: 2001
Pages: 76

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net