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 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, you can use OUs 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:
NOTE OUs are used to contain objects within a domain. They can’t, however, contain objects from other domains.
TIP An inetOrgPerson object is used for LDAP compatibility and is defined in Request For Comments (RFC) 2798. Except for having a different object name, you manage inetOrgPerson objects the same way as user objects.
For administrative purposes, you can use OUs in two key ways. First, you can use OUs to delegate administrative rights. You can use this approach 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 might recall, the DC= identifier is used to reference domain components. This means that the Sales OU in the imaginedlands.com domain has a DN of OU=Sales,DC=imaginedlands,DC=com.
Because OUs can contain other OUs, you can have multiple levels of OUs. For example, if you had a United States OU and a Europe OU within the Sales OU, the DNs of these OUs would be OU=USA,OU=Sales,DC=imaginedlands,DC=com and OU=Europe,OU=Sales,DC=imaginedlands,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. Because OUs aren’t a part of the DNS structure, users don’t have to reference OUs when they log on, when they’re authenticating, or when they perform searches of Active Directory. This makes multiple OUs much easier to work with than multiple domains. Also, it’s 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, you can delegate many other administrative tasks related to Active Directory 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 how you configure delegation, and they include allowing someone to perform the following actions:
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 if the need arises. Because 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 Chapters 14 and 15, 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 Management Console (GPMC). Group Policy is a very important part of Active Directory. Not only can you use it to manage the functionality available to users, but you can also use it to enforce security, to standardize desktop configuration, to install software, to specify scripts that should 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 an OU structure, you should plan the structure before you try to implement it. You’ll often 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. Before trying to implement a design, it’s a good idea to go through several possible scenarios on paper. Through 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 might need to redesign the OU structure.
In the example shown in the figure, 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 have only 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, top-level OUs represent the largest geographic units, such as continents, and the lower-level OUs represent successively smaller geographic units, such as countries/regions.
This model has several advantages. A geographic structure is stable. Many companies frequently reorganize internally, but they rarely change geographic structure. Also, when you use a geographic model, it’s easy to determine where accounts and resources are physically located.
The disadvantages of 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. In a company where budget is the top priority, the cost center model might 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 it could also be a disadvantage. Cost center structure is not a structure well known to most administrators, and it might be confusing.
With an administration model, you use OUs to reflect the way resources and accounts are managed. Because this model reflects the business structure of a company, it’s 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 the business structure. 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 might 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 of this model is that it is designed around the way administrators work and represents the business structure of the company. The disadvantage of this model is that when the company (or divisions within the company) restructures, you might need to redesign the OU structure.
Organizational units (OUs) are logical administrative units that can help you limit the scope of a domain. They can contain many types of objects, including those for computers, contacts, groups, printers, or users. Because they can also contain other OUs, you can build a hierarchy of OUs within a domain. You can also use OUs to delegate administrator privileges on a limited basis.
Several tools are available for creating OUs. Typically, the tool you use depends on what other administrative tasks you might need to perform. For example, if you are creating an OU to add resources to it, you might want to use either Active Directory Users And Computers or Active Directory Administrative Center. If you are creating an OU to apply Group Policy to it, you might want to use Group Policy Management.
As long as you use an account that is a member of the Administrators group, you’ll be able to create OUs anywhere in the domain. The only exception is that you can’t create OUs within the default containers created by Active Directory.
NOTE You can create OUs within the Domain Controllers container. This is possible because this container is created as an OU. Creating OUs within Domain Controllers is useful if you want to organize domain controllers.
When you work with Active Directory Users And Computers, you are connected to your login domain by default. If you want to create OUs in a different domain, right-click the Active Directory Users And Computers node in the console tree and then select Change Domain. In the Change Domain dialog box, type the name of the domain to which you want to connect and then click OK. Alternatively, in the Change Domain dialog box, you can click Browse to open the Browse For Domain dialog box so that you can find the domain to which you want to connect.
You can now create the OU. If you want to create a top-level OU (that is, an OU that has the domain container as its parent), right-click the domain node in the console tree, point to New, and then select Organizational Unit. If you want to create a lower-level OU, right-click the OU in which you want to create the new OU, point to New, and then select Organizational Unit.
In the New Object–Organizational Unit dialog box, type a new name for the OU and then click OK. Although the OU name can be any string of up to 256 characters, the best OU names are short and descriptive.
When you create a new OU, the Protect Container From Accidental Deletion check box is selected automatically. This prevents any user or administrator in the domain from deleting the OU accidentally. Before you can delete a protected OU, you must clear this protection flag. In Active Directory Administrative Center, this is a standard property in the Properties dialog box.
In Active Directory Users And Computers, this is an advanced property in the Object tab, and you must enable the Advanced Features view by choosing Advanced Features from the View menu before you can clear or select it. Therefore, to delete an OU, you must complete the following steps:
252. In Active Directory Users And Computers, enable the Advanced Features view by choosing Advanced Features from the View menu.
253. Right-click the OU and then select Properties.
254. In the Object tab of the Properties dialog box, clear the Protect Object From Accidental Deletion check box and then click OK.
255. In Active Directory Users And Computers, right-click the OU and then select Delete.
256. When prompted to confirm, click Yes.
Working with OUs in Active Directory Administrative Center is similar. In Active Directory Administrative Center, you are connected to your login domain by default. If you want to create OUs in a different domain, click Manage and then select Add Navigation Nodes.
In the Additional Navigation Nodes dialog box, you’ll see available domains for the forest in the Columns list. To add a node for a listed domain, select it in the Columns list, click the Add (>>) button, and then click OK. To add a node for a domain that isn’t listed, click Connect To Another Domain, enter the fully qualified domain name, and then click OK. Either way, a management node for the domain should be added to the console.
If you want to create a top-level OU in Active Directory Administrative Center, right-click the domain node in the console tree, point to New, and then select Organizational Unit. If you want to create a lower-level OU, right-click the OU in which you want to create the new OU, point to New, and then select Organizational Unit. In the Create Organizational Unit dialog box, type a new name for the OU and then click OK.
OUs have properties that you can set to add descriptive information. This helps other administrators know how the OU is used.
To set the properties of an OU in Active Directory Users And Computers, right-click the OU and then select Properties. This displays the OU’s Properties dialog box.
Similar options for setting the properties of an OU are available in Active Directory Administrative Center. Right-click the OU and then select Properties to open the OU’s Properties dialog box. COM+ and Attribute Editor options are available on the Extensions panel.
After you create an OU, you might want to place accounts and resources in it. In either Active Directory Users And Computers or Active Directory Administrative Center, you follow one of these procedures:
When you create domains and OUs, you’ll often want to be able to delegate control over them to specific individuals. This is useful if you want to give someone limited administrative privileges for a domain or OU. Before you delegate administration, you should carefully plan the permissions to grant. Ideally, you want to delegate the permissions that allow a user to perform necessary tasks while preventing your delegate from performing tasks he or she should not. Often, figuring out the tasks that a user with limited administrative permissions should be able to perform requires talking to the department or office manager or to the individual.
You delegate control of Active Directory objects to grant users permission to manage users, groups, computers, OUs, or other objects stored in Active Directory. You can grant permissions in the following ways:
When you delegate permissions, be sure to keep in mind how inheritance works in Active Directory. As you might recall from previous discussions of permissions, lower-level objects inherit permissions from top-level objects. In a domain, the top-level object is the domain object itself. This has the following results:
To delegate administration of a domain or OU, follow these steps:
257. In Active Directory Users And Computers, right-click the domain or OU for which you want to delegate administration and then select Delegate Control. When the Delegation Of Control Wizard starts, click Next.
258. On the Users Or Groups page, click Add to display the Select Users, Computers, Or Groups dialog box.
259. The default location is the current domain. Click Locations to see a list of the available domains and other resources that you can access. Because of the built-in transitive trusts, you can usually access all the domains in the domain tree or forest.
260. Type the name of a user or group account in the selected or default domain and then click Check Names. The options available depend on the number of matches found as follows:
When a single match is found, the dialog box is automatically updated as appropriate and the entry is underlined.
When no matches are found, you either entered an incorrect name part or you’re working with an incorrect location. Modify the name and try again, or click Locations to select a new location.
If multiple matches are found, select the name or names you want to use and then click OK.