So far in this book, I've discussed domains, domain trees, and forests. These are the components of Active Directory that can help you scale the directory to meet the needs of any organization regardless of its size. Sometimes, however, what you want to do is not scale the directory but create hierarchical structures that represent parts of the organization or to limit or delegate administrative access for a part of the organization. This is where OUs come in handy.
An organizational unit (OU) is a logical administrative unit that is used to group objects within a domain. Within a domain, OUs can be used to delegate administrator privileges while limiting administrative access and to create a hierarchy that mirrors the business's structure or functions. So rather than having multiple domains to represent the structure of the organization or its business functions, you can create OUs within a domain to do this.
At its most basic level, an OU is a container for objects that can contain other OUs as well as the following objects:
Computers
Contacts
Groups
inetOrgPerson
Printers
Shared Folders
Users
Note
OUs are used to contain objects within a domain. They cannot, however, contain objects from other domains.
Tip
An inetOrgPerson object is used to represent user accounts that have been migrated from other directory services. Except for having a different object name, inetOrgPerson objects are managed the same way as user objects.
For administrative purposes, OUs can be used in two key ways. First, you can use OUs to delegate administrative rights. This allows you to give someone limited or full administrative control over only a part of a domain. For example, if you have a branch office, you could create an OU for all the accounts and resources at that office, and then delegate administration of that OU to the local administrator.
Second, you can use OUs to manage a group of objects as a single unit. Unlike domains, OUs are not a part of DNS structure. Within Active Directory, OUs are seen as container objects that are part of a domain. In the directory tree, they are referenced with the OU= identifier, such as OU=Sales for an OU named Sales. The distinguished name (DN) of an OU includes the path to its parent as well as its relative name. As you may recall, the DC= identifier is used to reference domain components. This means that the Sales OU in the cpandl.com domain has a DN of OU=Sales,DC=cpandl,DC=com.
Because OUs can contain other OUs, you can have multiple levels of OUs. For example, if you had a USA OU and a Europe OU within the Sales OU, the DNs of these OUs would be OU=USA,OU=Sales,DC=cpandl,DC=com and OU=Europe,OU=Sales,DC=cpandl, DC=com, respectively. When you nest OUs in this way, the nested OUs inherit the Group Policy settings of the top-level OUs by default, but you can override inheritance if you want to use unique Group Policy settings for a particular OU.
From a user perspective, OUs are fairly transparent. As OUs aren't a part of DNS structure, users don't have to reference OUs when they log on, during authentication, or for searches of Active Directory. This makes multiple OUs much easier to work with than multiple domains. Also, it is fairly easy to change the names and structures of OUs, which isn't the case with domains.
Although you will want to centrally manage Active Directory structure, many other administrative tasks related to Active Directory can be delegated to specific groups or individuals. Delegating administrative rights allows a user to perform a set of assigned administrative tasks for a specific OU. The tasks allowed depend on the way you configure delegation and include allowing an individual to perform the following actions:
Create, delete, and manage accounts
Reset user passwords and force password changes at next logon
Read all user information
Create, delete, and manage groups
Modify the membership of a group
Manage Group Policy links
Generate Resultant Set of Policy
One of the common reasons for delegating administrative rights is to allow an individual in a department or business unit to reset user passwords. When you delegate this right, you allow a trusted person to change someone's password should the need arise. As the right is delegated to a user within a particular OU, this right is limited to that specific OU. In many organizations, this type of right is granted to Help Desk staff to allow them to reset passwords while preventing the Help Desk staff from changing other account properties.
Group Policy allows you to specify a set of rules for computer and user configuration settings. These rules control the working environment for computers and users. Although I'll discuss Group Policy in depth in Chapter 37, the important thing to know about Group Policy is that you can use it to set default options, to limit options, and to prevent changing options in virtually every aspect of computer and user configuration.
Every domain you create has a default Group Policy rule set, referred to as the Default Domain Policy. Group Policy can also be applied to OUs, which makes OUs important in helping administrators manage groups of accounts and resources in a particular way. By default, OUs inherit the Group Policy settings of their parent object. For top-level OUs within a domain, this means that the Default Domain Policy is inherited by default. For lower-level OUs, this means that the OUs inherit the Group Policy of the OUs above them (and if the higher-level OUs inherit Group Policy from the domain, so do the lower-level OUs).
To manage Group Policy, you can use the Group Policy Object Editor or the Group Policy Management Console. Group Policy is a very important part of Active Directory. Not only can you use it to manage the functionality available to users, you can also use it to enforce security, standardize desktop configuration, install software, specify scripts that should be run when a computer starts or shuts down and when a user logs on or logs off, and so on.
Because Group Policy is so important in Active Directory, you should plan your OU structure with Group Policy in mind. You do this by grouping objects that require the same Group Policy settings. For example, if a group of users requires a specific environment configuration to use an application or if a group of users requires a standard set of mapped drives, you can configure this through Group Policy.
OUs simplify administration by organizing accounts and resources in ways that best fit the organizational structure. When designing OU structure, you should plan the structure before you try to implement it. Often you'll find that you need multiple levels of OUs. This is fine. The levels of OUs will form a hierarchy, much like the hierarchy formed when you use multiple levels of domains. The key thing to understand about any OU design is that it is really for administrators. As such, the design needs to be meaningful for your organization's administrators—and ideally, it should help make administration easier.
Creating a good OU design isn't always as easy as it seems. It is a good idea to go through several possible scenarios on paper before trying to implement a design. Through successive revisions on paper, you should be able to improve the design substantially. Common design models for OUs are discussed in the sections that follow.
With a division or business unit model, you use OUs to reflect the department structure within the organization. The advantage to this model is that users will know and understand it. The disadvantage to this model is that when the company restructures, you may need to redesign the OU structure.
In the example shown in Figure 34-2, OUs are organized by department within the company, and, to allow for separate controls for accounts and resources, the related objects are put in second-level OUs. If you want to only have one level of OUs, you could do this by putting all the objects in the top-level OU.
With a geographic model, you use OUs to reflect geographic location. In this model, toplevel OUs represent the largest geographic units, such as continents, and the lower-level OUs represent successively smaller geographic units, such as countries (see Figure 34-3).
There are several advantages to this model. A geographic structure is fairly stable. Many companies reorganize internally frequently, but only rarely change geographic structure. Additionally, when you use a geographic model, it is easy to determine where accounts and resources are physically located.
The disadvantages to this model have to do with its scope. For a global company, this design would put all accounts and resources in a single domain. As a result, changes made to Active Directory at any location would be replicated to every office location. Additionally, the OU structure doesn't relate to the business structure of the organization.
With a cost center model, you use OUs to reflect cost centers. In this model, top-level OUs represent the major cost centers within the organization and the lower-level OUs represent geographic locations, projects, or business structures, as shown in Figure 34-4. In a company where budget is the top priority, the cost center model may be an effective way to reflect this priority. Cost centers could also be independent divisions or business units within the company that have their own management and cost controls.
The ability to represent costs and budgets in this way is a definite advantage but could also be a disadvantage. Cost center structure is not a structure well known to most administrators, and it may be confusing.
With an administration model, you use OUs to reflect the way resources and accounts are managed. As this model reflects the business structure of a company, it is very similar to the division or business unit model. The key difference is that the top-level OU is for administrators and second-level OUs are for business structure (see Figure 34-5). If successive levels are needed, they can be organized by resource type, geographic location, project type, or some combination of the three.
In a large company, you may use multiple implementations of this model for each division or business unit. In this case, the top-level administrative group would be for the division or business unit and the second-level OUs would be for groups within the division.
The advantage to this model is that it is designed around the way administrators work and represents the business structure of the company. The disadvantage to this model is that when the company or divisions within the company restructure, you may need to redesign the OU structure.