Delegating Administration of Account and Resource OUs

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Account OUs contain user, group, and computer objects. Forest owners must create an OU structure to manage these objects and then delegate control of the structure to the OU owner. Resource OUs contain resources and the accounts that are responsible for managing those resources. The forest owner is also responsible for creating an OU structure to manage these resources and delegating control of that structure to the OU owner.

Delegating Administration of Account OUs

Delegate an account OU structure to data administrators if they need to be able to create and modify user, group, and computer objects. The administrative capabilities of an account OU structure are similar to those of a Windows NT 4.0 Master User Domain. The account OU structure is a subtree of OUs for each account type that must be independently controlled. For example, the OU owner can delegate specific control to various data administrators over child OUs in an account OU for users, computers, groups, and service accounts, as shown in Figure 2.39.

Figure 2.39   Account OU Structure

Account OU Structure

Table 2.11 lists and describes the child OUs that you can create in an account OU structure.

Table 2.11   Child OUs in the Account OU Structure

OU Purpose


Contains user accounts for non-administrative personnel.

Service Accounts

Some services that require access to network resources run as user accounts. This OU is created to separate service user accounts from the user accounts contained in the Users OU. Also, placing the different types of user accounts in separate OUs enables you to manage them according to their specific administrative requirements.


Contains accounts for computers other than domain controllers.


Contains groups of all types, except for administrative groups, which are managed separately.


Contains user and group accounts for data administrators in the account OU structure, to allow them to be managed separately from regular users. Enable auditing for this OU so that you can track changes to administrative users and groups.

Figure 2.40 shows the administrative group design for an Account OU.

Figure 2.40   Delegation Model for Account OUs

Delegation Model for Account OUs

The owner of the Account OU is the acct_ou_OU_admins group, which is comprised of data administrators. This group has full control of the acct_ou_OU subtree, and is responsible for creating the standard set of child OUs and the groups to manage them.

Groups that manage the child OUs are granted full control only over the specific class of objects that they are responsible for managing. For example, acct_ou_group_admins has control only over group objects.

Note that no separate administrative group manages the Admins OU; rather, it inherits ownership from its parent OU, so it is managed by acct_ou_OU_admins. The OU owner might choose to create additional administrative groups, however. For example, the OU owner might create the optional group *acct_ou_*helpdesk_admins in the Admins OU to control password resets.

Administrative Group Types

The types of groups that you use to delegate control within an OU structure are based on where the accounts are located relative to the OU structure that is to be managed. If the admin user accounts and the OU structure all exist within a single domain, then the groups that you create to use for delegation must be global groups. Figure 2.41 shows the delegation of administration within a single domain.

Figure 2.41   Group Type for Delegation Within a Single Domain

Group Type for Delegation Within a Single Domain

If your organization has a department that manages its own user accounts and exists in more than one region, you might have a group of data administrators who are responsible for managing account OUs in more than one domain. If the accounts of the data administrators all exist in a single domain and you have OU structures in multiple domains to which you need to delegate control, make those administrative accounts members of global groups and delegate control of the OU structures in each domain to those global groups, as shown in Figure 2.42

Figure 2.42   Using Global Groups to Manage OUs in Multiple Domains

Use Global Groups to Manage OUs in Multiple Domain

If the data administrators accounts to which you delegate control of an OU structure come from multiple domains, you must use a universal group. Universal groups can contain users from different domains and can therefore be used to delegate control in multiple domains.

Figure 2.43 shows a configuration in which universal groups are used to manage OUs in multiple domains.

Figure 2.43   Using Universal Groups to Manage OUs in Multiple Domains

Using Universal Groups to Manage OUs

Delegating Administration of Resource OUs

Resource OUs are used to manage access to resources. The resource OU owner creates computer accounts for servers that are joined to the domain that include resources such as file shares, databases, and printers. The resource OU owner also creates groups to control access to those resources.

Figure 2.44 shows the two possible locations for the resource OU.

Figure 2.44   Resource OU Placement in a Domain

Resource OU Placement in a Domain

The resource OU can be located under the domain root or as a child OU of the corresponding account OU in the OU administrative hierarchy. If the domain spans across different countries or regions, or the domain owner is responsible for a large number of OUs, Windows NT 4.0 resource domain owners might prefer to control resource OUs that are subordinate to account OUs, to ensure that they have direct access to support from the account OU owner. Resource OUs do not have any standard child OUs. Computers and groups are placed directly in the resource OU.

The resource OU owner owns the objects within the OU, but does not own the OU container itself. Resource OU owners manage only computer and group objects; they cannot create other classes of objects within the OU, and they cannot create child OUs.


  • The creator or owner of an object has the ability to set the ACL on the object, regardless of the permissions that are inherited from the parent container. If a resource OU owner can reset the ACL on an OU, he or she can create any class of object in the OU, including users. For this reason, resource OU owners are not permitted to create OUs.

For each resource OU in the domain, create a global group to represent the data administrators who are responsible for managing the contents of the OU. This group has full control over the group and computer objects in the OU, but not over the OU container itself.

Figure 2.45 shows the administrative group design for a resource OU. The res_ou_OU_admin group manages its own membership and is located in the resource OU.

Figure 2.45   Resource OU Administrative Group Design

Resource OU Administrative Group Design

Placing the computer accounts into a resource OU gives the OU owner control over the account objects but does not make the OU owner an administrator of the computers. In an Active Directory domain, the Domain Admins group is, by default, placed in the local Administrators group on all computers. This means that service administrators have control over those computers. If resource OU owners require administrative control over the computers in their OU, the forest owner can apply a Restricted Groups Group Policy to make the resource OU owner a member of the Administrators group on the computers in that OU.