As you build your organization's OU hierarchy, make sure it uses the most efficient layout possible. Designing the OU hierarchy can prove very challenging. If you build too many OUs with several child OUs beneath them, you could create problems when trying to apply group policies. If you create too few, you may find that you have to perform special actions against the group policies so that you are not applying them to the wrong accounts.
OUs are built based on three criteria: autonomy over objects, control object visibility, and efficient group policy application. The following sections describe controlling the autonomy over and visibility of OUs. Later in the chapter we'll discuss designing with group policies in mind.
Object autonomy should be the primary criterion 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, the members of that group can control the accounts to which administrative control within the OU tree can be granted.
Users do not usually have the ability to view OUs (and typically should not be given the ability, either). They use the global catalog to find objects that give them access to the resources within the network. OUs are designed to make administration easier for the administrative staff within the company. Keep this in mind when you are creating your OU structure. Build it with administration as the top priority; you can address other issues later.
Because so much power can be wielded when users are allowed to become OU owners, if you allow this, the users should be trained on the proper methods of delegation. This means that anyone who is allowed to delegate control to another user should understand the two methods of delegating permissions—object-based and task-based—as well as how inheritance affects the design. If OU owners are not properly trained on control delegation, the OU structure could be at a security risk if users have too much power or, at the opposite extreme, if users do not have the proper amount of authority to administer the objects they are supposed to control.
The OU owners are responsible for making sure that the appropriate users and groups have the ability to manage the objects for which they are responsible. In the following sections, we look at the options available to make sure those users and groups are properly configured for the access they need.
Object-based delegation grants a user control over an entire object type. Objects within AD DS comprise users, groups, computers, OUs, printers, and shared folders. If a user needs to have control over computer accounts, you can use the Delegation of Control Wizard to allow full-control permission over only computer objects within the OU. You might have another user who administers the user and group objects within the OU. This level of control can be delegated as well.
Task-based delegation grants a user the ability to perform specific functions against objects within the OU. Controlling objects at this level is more difficult to manage and maintain, but sometimes may be necessary. Take, for instance, a case in which a company has a help desk, and one of its job duties is to reset passwords for users. However, you don't want helpers to modify any of the user properties. If you delegate the ability to work with user objects, the help-desk personnel will have too much power. Instead, you can delegate the ability to reset passwords at the task level, thereby preventing the help-desk personnel from affecting the objects in any other way.
As mentioned earlier, however, it is much more difficult to manage the permissions granted at the task level than those at the object level. You will need to document the groups to which you are delegating permissions. Otherwise, you may find it problematic to track down where permissions are applied and troubleshoot access problems. As a best practice, design the OU structure so that you can take advantage of object-based delegation as much as possible.
In some Windows NT 4 directory service structures, the user accounts and resources are divided into their own domains, based on the administrative needs of the domain owners. Because the domain is the administrative boundary within NT 4, the user-account administrators have control over the account domain. Resource administrators have domains made up of the resources they are responsible for maintaining—usually systems that provide database, email, file, and print services, to name a few.
Depending on the administrative needs of the organization, delegation of the sublevel OUs should follow a couple of rules:
The OU owner will have full control. The OU owners will have the ability to work with any object within the OU tree for which they are the owners. Once the domain owner delegates full control to the top-level OU for the OU owner, the OU owner will be able to take ownership of any object within that OU tree.
The OU admins can control only objects for which they have been granted permissions.
The OU owner should delegate only the ability to work with the object types that the OU owner needs to modify. If the OU administrator is an account administrator, then only user and/or group object permissions should be granted. If the administrator is a resource administrator, only the appropriate object type should be delegated. OU administrators should not have the ability to affect OUs, but only the objects within them.
Account OUs and resource OUs can provide the same functionality that account and resource domains provided under NT 4. Account OUs will hold the user and group accounts that are used when accessing the resources. Resource OUs will host the resources that users will need to access within the domain. These could be computer accounts, file shares, shared folders, and contacts. You can build an OU structure that allows the user, group, and resource objects to be separated based on the staff that needs to have administrative control over them.
Inheritance allows the permissions set at a parent level to be assigned automatically, or propagated, to each child level. The inheritance of object permissions from the parent object to the child object eases some of the administration headaches. Any object created within an OU will inherit the applicable permissions from the OU. With this being the case, whenever an account is granted permissions at the OU level, all of the child OUs and objects within those OUs inherit the settings. OU owners can control all the objects within their OU tree after the domain owner delegates the appropriate permissions to the top-level OU.
Occasionally the permissions set at higher levels within AD DS are not the permissions needed at a lower level. If this is the case, inheritance can be blocked, which means that permissions set at the parent level will no longer pass to the child objects. When blocking the inheritance of permissions, the administrator who is initiating the block can choose whether to copy the inherited permissions to the object or to remove them completely. You may want to copy the permissions if the majority of the permissions will stay the same, but you may only want to change one or two permissions. This will allow you to keep the majority of the permission entries and simply remove the permission entries you do not want instead of recreating the entire permission list. If the inherited permissions are removed from the object, only the permissions that are explicitly set at the object level will apply. This could restrict an upper-level OU owner, OU administrator, domain owner, or forest owner from being able to perform actions against the object. If this happens, the OU owner, OU administrator, domain owner, or forest owner can reset the inheritable permissions on the object or objects that were affected.
The blocking of inheritance could be problematic for users or groups who do not have the power to change the inheritable-permissions setting. If inheritance is blocked to objects that a group needs to have control over, they will not be able to effectively maintain those objects. At this point, the OU owner could step in and change the inheritance on the OU or object, or change the effective permissions on the objects that the group needs to control. Trying to troubleshoot inheritance issues can be time-consuming and difficult, so limit the amount of inheritance blocking you use within your design.
Creating an OU structure for a brand-new design can be challenging. Developing a design that allows the administrative functions to be performed easily is of the utmost priority. However, few organizations have the option of creating a brand-new design. An infrastructure probably exists already.
You can use OUs to hide objects from users when they are searching within AD DS. By hiding the objects that users do not need to access, you 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. In this manner, you can hide printers that users do not need to access, and shares that should not appear in search results. You can also hide user and group objects from other administrators.
When you design the OU structure, always start with designing for administrative control, and then consider visibility of objects. 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 whose access is restricted to a few authorized users printing 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 for use exclusively by the 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 AD DS.
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 IT department is responsible for maintaining the objects in AD DS. 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 to grant other levels of control at the departmental level for the administrators who control a subset of resources. The initial design looks like Figure 4.14.
The objects that need to be hidden from users should be placed within an OU that will not allow users to view its contents. For users 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. Because this permission is included in the standard read permission, accounts with read permission will be able to see 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 the 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 accounts-payable administrators need to be able to maintain the objects within the OU, so either their permissions will have to be 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 removed. The final OU design for accounting will look like Figure 4.15.
As we have mentioned, the primary reason to create an OU structure is to have the ability to control administrative abilities and make resource administration more efficient. There is only one way to delegate administration of resources, yet there are many options to control group policies, as you will see in the next section. Remember, though, that the administrative design should take precedence.
OU design with OUs created for ease of administration
OU design with the OU created to control visibility corp.com
Accounting Admins Full Control
Accounts Receivable Full Control Authenticated Users Read
Accounts Payable Full Control Accounts Payable Users Read
AR Admins Full Control Authenticated Users Read
Was this article helpful?