The Basics of Organizational Units

Active Directory introduced one of the most useful objects into the Windows realm; the organizational unit (OU). This versatile tool allows administrators not only to organize resources within the Active Directory structure, but to delegate administrative control to users who are not members of any administrative group . When OUs are used within a domain, users can be granted control to resources that they need to manage and at the same time, gain autonomy over those resources. Users who do not have administrative control over OUs or objects within those OUs will not be able to affect resources within the OUs.

To have complete control over an OU, you must first be delegated Full Control permission. This delegation is provided by the domain owner and can be granted to users or groups. For efficiency s sake, you should create a group that will manage the OU and then delegate permissions to this group. You can then add user accounts that need to manage the objects, otherwise known as the OU owners , to the group with Full Control permissions.

OU owners control all aspects of the OU that they have been given authority over, as well as all of the objects that reside within the OU tree. Like the domain owner, they will not be isolated from outside influences, because the domain owner will have control if the need arises. However, this autonomy of control over the resources allows the OU owner to plan and implement the objects necessary to effectively administer their OU hierarchy. This includes delegating administrative control to those users who need to be OU administrators .

OU administrators are responsible for the specific objects within their OU. Usually they will not have the ability to create child OUs. Their control will more than likely be limited to working with a specific object type within the OU. For example, the OU owner could delegate the ability to work with computer accounts to the technical support staff. This would allow the technical support staff to create and delete computer objects within the OU, but they would not be able to control or modify user objects within the OU. Controlling user objects could be delegated to a Human Resources employee who is responsible for creating user objects when a person is hired , and disabling and deleting objects when a person is discharged.

In the following sections we take a look at some of the design options that are available when creating OUs. This includes the choices that should be made so that changes within the organization will not adversely affect the OU structure.

Understanding the OU Design Options

The OU design should be predicated on the administrative structure of the organization, not the departmental organization as seen on the company s organization chart. Most companies do not base the administration of resources on the organization chart. Usually, the IT department is responsible for objects within the company no matter which department is using the resource.

Although this centralized approach is the most basic method of controlling the objects within Active Directory, some organizations cannot utilize one single administrative group that has power over all of the objects. Other organizations will not have a centralized administrative team; instead they will have decentralized control over objects. In such cases, design decisions will have to be made that will dictate where the objects will reside within the OU structure. Microsoft has identified five design options when developing the OU design. These five allow the OUs to be designed by location, organization, business function, location then business function, or organization then location.

OUs Based on Location

If an organization has resources that are centralized, but the administrative staff is based at different geographic locations, the OU design should take on a location-based strategy. Using this strategy, the OU structure is very resistant to reorganizations, mergers, and acquisitions. Because all of the objects are located beneath the top-level OU, which is based on company location as seen in Figure 5.1, the lower-level OUs can be modified and the objects moved within the OUs to accommodate the changes. Consider the alternative: having domains that are used to host the objects. Moving objects between domains has many more implications because the security ID of the objects will have to change as will the domain owners.

Figure 5.1: OU structure based on Location

However, some disadvantages to the location-based strategy exist. Unless the inheritance of permissions has been blocked, administrative groups that are granted authority at an upper-OU level will have the ability to affect objects in the lower-level OUs.

The location-based strategy works well within organizations that are using the departmental model but have geographically dispersed resources. In this manner, administrators located in the same site as the resources will have control over the objects that represent them in Active Directory.

OUs Based on Organization

If the administrative structure has an administrative staff that reports to divisions and is responsible for the maintenance of the resources for that division, the OU structure can be designed so that is takes advantage of the departmental makeup of the company as seen in Figure 5.2. Using this design strategy makes the OU structure much more vulnerable to change within the organization should a reorganization occur. However, it does allow departments to maintain autonomy over the objects that they own.

Figure 5.2: OU structure based on Organization

This strategy is usually employed whenever the cost center, product/service-based or projectbased business models are employed. This allows for the resources to be grouped so that the cost centers are separate OU structures. The product, service, or project resources can likewise be isolated within an OU tree, and those administrators who are responsible for the resources can be delegated the ability to control the objects within Active Directory.

OUs Based on Function

Smaller organizations that have an administrative staff who has specific functions they provide to the organization typically use an OU design strategy based on job functions as seen in Figure 5.3. In these smaller organizations, the administrators will have several job responsibilities. Building the OU structure based on the job responsibilities allows the controlled objects to be grouped together based on the tasks that need to be administered. This type of OU deployment is resistant to company reorganizations, but due to the way the resources are organized, replication traffic may be increased.

Figure 5.3: OU structure based on Function

This strategy can be employed with any of the business models. Because it is usually implemented in smaller companies, a single administrative group such as Information Technology is responsible for maintaining all of the objects. The functions can be broken out based on the staff responsible for maintaining user objects, group objects, shared folders, databases, mail systems, and so on. Of course the administrative staff will have to be trusted by all divisions if this model is employed, but usually in the smaller companies, this is not as much of an issue.

OUs Based on Location and Organization

Two hybrid methods of organizing resources exist. Each one is based on a combination of the location of resources and the method the company uses to organize the objects.

OUs Based on Location, Then Organization     When you use an OU design strategy that is first based on location and then organization, the upper-level OUs are based upon the location of the objects within the directory, and the lower-level OUs are broken out by the organization s departmental structure as seen in Figure 5.4. This strategy allows the organization to grow if necessary, and has distinct boundaries so that the objects administration is based on local autonomy. Administrative staff will need to cooperate if administrative groups are responsible for the departments within the OU structure, because if this is the case, OU owners will have control over all of the objects within the OU tree.

Figure 5.4: OU structure based on Location, then Organization

Large companies that employ the departmental business model may have several locations within the company that have administrative staff controlling the resources. If this is the case, the OU owner for the location can control all of the accounts that are OU administrators for the individual departments within that location. This allows the OU owner to control users within the location for which they are responsible, while still maintaining control over their location. OU administrators would only be able to affect objects within their department at that location.

OUs Based on Organization, Then Location     With an OU design strategy that is first based on organization and then location, the OU trees are based upon the organization s departmental makeup with the objects organized based on location, as seen in Figure 5.5. Using this strategy, the administrative control of objects can be delegated to administrative staff responsible for objects at each of the locations, whereas all of the resources can be owned by a department s own administrative staff. This allows for a strong level of autonomous administration and security; however, the OU structure is vulnerable to reorganization because the departmental design of the company could change.

Figure 5.5: OU structure based on Organization, then Location

Very large companies using the cost center “based, product/service-based, or project-based business models may create an OU tree that is based on the organizational makeup of the company and then have a decentralized administrative staff that is responsible for the resources within different geographic regions . This allows for more efficient control of the resources while still allowing the OU owners to have a level of autonomy over the objects that represent their resources within the company.

Choosing the Best OU Design Approach

You will notice that each of the design options has its own unique set of advantages and disadvantages. To choose the best design for your company, you will have to weigh the pros and cons of each strategy so that you come up with a design that is the best fit for your environment. If your company is not going to undergo many reorganizations or mergers and acquisitions, you may want to choose a design that makes the delegation of control easiest for your current administrative model. Company reorganizations could force a reevaluation of the departmental makeup within the organization, thus forcing the OU hierarchy to change. Projects that are completed or abandoned will also force the OU structure to change. You may not want to rework the OU structure every time management decides they want to try running the business in a new fashion.

You will find that the adage The only constant is change will probably ring true no matter what strategy you employ, so try to employ the strategy that appears to be the least likely to change but reflects the way the administration is provided.

Understanding OU Design Criteria

Back in Chapter 1, Analyzing the Administrative Structure, we discussed the interviews that should take place and the information you should collect about who is responsible for controlling resources. This is where that information will start coming in very handy. As a matter of fact, OUs are built based on three criteria:

• Autonomy over objects

• Efficient Group Policy application

• Control object visibility

  Note  

  Designing the OU structure to take advantage of efficient Group Policy application will be discussed in Chapter 6.

Design Scenario ”Choosing the OU structure

Kentucky Clay manufactures ceramic fixtures such as sinks, bathtubs, and toilet bowls. They are in the process of migrating their Novell 3.12 “based network to Windows Server 2003 Active Directory. Currently they have a large Information Technology staff located at their headquarters in Prospect, KY. The Prospect plant is the original location for the company and they manufacture toilet bowls here. Over the past few years the company has expanded its operations by building two new plants and acquiring three competitors . Each of these plants, four of which are located in other cities in Kentucky and one in Ohio, manufacture different products.

The IT staff in Prospect is responsible for all operations. Most of the systems are centrally located within the data center at the headquarters. Each of the plants hosts their own systems that allow them to run their daily operations. The daily updates are then sent to the headquarters for processing. Kentucky Clay is not convinced that the wide area network links that they are leasing from the telecommunications companies are reliable enough to support a truly centralized approach, so the systems that are critical to the functioning of the plants are located onsite. These systems support the plant functions only, since all of the administrative processing is performed at headquarters. Each remote plant has an administrative staff who is responsible for the daily maintenance of their systems.

The design team would like to maintain a single domain structure if possible. They have determined that the changes they will be making to objects within Active Directory will be minimal, thus reducing the need for extensive replication throughout the locations. They are now looking at the OU design options and are trying to determine which strategy to employ.

1. Question: Which of the OU design strategies would you suggest that Kentucky Clay implement? Answer: Location-based.

2. Question: When you specify your strategy of choice, what explanation would you give them for your decision? Answer: Since the resources are going to be located at each plant along with the administrative staff who is responsible for maintaining them, the location-based option is the most optimal. This will allow you to organize the resources located at each plant into their own OUs and delegate permissions to the groups responsible for them.

 

Object Autonomy

Object autonomy should be the primary criteria by which most organizations design their OUs. Giving the OU owners the ability to control the objects for which they are accountable allows them to perform their job functions. At the same time, they will feel comfortable knowing those objects are not controlled by other OU owners or administrators from outside their OU structure, with the exception of the forest s and domain s service and data administrators. Once a group is identified as the OU owner, they can control the accounts to which administrative control within the OU tree can be granted.

Real World Scenario ”Delegating resonsibilities

The domain owner for domain corp.com has decided to create an OU structure for the Accounting department. Melissa is in charge of the group that is responsible for all of the servers, workstations, and resources within the Accounting department. Several people report to Melissa, all of whom are responsible for different resource types. The domain owner has decided that Melissa will become the OU owner and will be responsible for maintaining the Accounting OU structure. The domain owner creates an OU named Accounting and then delegates full control over the OU to Melissa. Melissa is now able to create additional OUs beneath her Accounting OU. She is also able to delegate control to members of her group. She will need to identify how she wants to organize the objects within the OU structure.

You will note that the top-level OU is based on the division of the organization that Melissa is responsible for. When a company is taking advantage of decentralized or hybrid administration, they can break the OU structure down into location-based or organization-based OUs, or a combination of the two, to effectively grant the administrative staff the permissions to manage their resources. Since Melissa is the owner of the OU and she has others who report to her, she can delegate permissions to those users so that they can perform their functions.

 

Controlling Visibility

When controlling object visibility , OUs can be used to hide objects from users when they are searching within Active Directory. By hiding the objects that users do not need access to, you can add a level of security to those objects. If users do not have the List Contents permission to an OU, they will not be able to view any of the objects within the OU. You can hide printers that they do not need to use and shares that should not appear in search results in this manner. You can also hide user and group objects from other administrators.

When you design the OU structure, you should always start with designing for administrative control, and then take visibility of objects into consideration. The primary goal of the OU design is to make administration of objects as efficient and easy as possible. Once you have completed the administrative design, you can address visibility requirements.

For example, take a company that has a printer that restricts users, with the exception of a few authorized individuals, from being able to print to it. This printer is used to print accounts payable and payroll checks. Only a few Accounts Payable employees are allowed to send print jobs to this printer. Also, some shares on the Accounts Payable server are exclusive for use by Accounts Payable staff. Because these resources need to be isolated from the rest of the organization, they should not show up when users from other departments perform searches within Active Directory.

The Accounts Payable department is part of the Accounting Division of the company. Because the company has all of the accounting resources located at the corporate office, the corporate Information Technology department is responsible for maintaining the objects in Active Directory. Other departments have staff located at other offices, and each of those offices has administrative staff responsible for maintaining the resources.

During the design phase, the design team decides to use the Location, Then Organization design approach. This allows them to assign control over all resources to the administrative groups that need to be owners of the OU hierarchy, and then grant other levels of control at the departmental level for those administrators that control a subset of resources. The initial design looks like Figure 5.6.

Figure 5.6: OU design for administrative purposes

The objects that were initially identified as needing to be hidden from users need to be placed within an OU that will not allow users to view its contents. For a user to be able to see the objects within an OU, at the very least they will need the List Contents permission granted to them. If they do not have this permission, the objects contained within the OU will not show up in their searches. Since this permission is included in the standard Read permission, accounts with Read permission will be able to list the contents of the OU.

Because users need to view objects within the Accounts Payable OU, the permissions to that OU cannot be changed. Instead, a child OU is created to control visibility of the objects. The users within Accounts Payable department who need to work with the objects will be able to see them when they access Active Directory tools or perform searches, but no one else will. It should be noted that the AP Admins still need to be able to maintain the objects within the OU, so their permissions will either need to be re-added to the access control list, or the existing permissions will need to be copied directly to the OU with the unnecessary accounts and permissions then removed. The final OU design for Accounting will look like Figure 5.7.

Figure 5.7: OU design with OU created to control visibility

As we have mentioned, the primary reason to create an OU structure is to have the ability to control administrative abilities and make administration of resources more efficient. Because there is only one way to delegate administration of resources and there are many options to control group policies, as you will be seen in Chapter 6, the administrative design should take precedence.