Creating the Data Management Delegation Model

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

The data owners of each business unit should create an administrative delegation model to distribute and delegate administrative responsibility among the data administrators.

Creating a delegation model involves the following steps:

1. Determine your role requirements and determine the number of instances and scope of administrative authority of each data management role.

2. Plan an OU hierarchy based on the administrative delegation and Group Policy requirements of the business unit.

3. Assign specific administrators or administrative groups to the role instances.

4. Document the model.

At the end of this process, business unit data owners should have a documented administrative delegation model that ensures the following:

• Administrative coverage has been provided for all aspects of content management.

• Administrative responsibilities have been distributed according to sound security practices among the instances of the various roles.

• Administrators and administrative groups have been mapped to the various instances of the data administration roles.

Responsibilities for each category of data administration tasks are delegated by using administrative roles that are instantiated as security groups. As mentioned earlier, organizations can choose to create their delegation model around Microsoft recommended roles or around custom created roles which might or might not depend on Microsoft-recommended roles.

Determining Role Requirements

The first step in the creation of your delegation model is to determine the following:

• The number of instances and the scope of administrative authority of each data management role.

• The specific set of administrators that will be assigned to each role instance.

Required Data Management Roles

The following are the recommended set of roles for Active Directory data management:

• Business Unit Admins

• Account Admins

• Workstation Admins

• Server Operators

• Resource Admins

• Security Group Admins

• Help-Desk Operators

• Application-Specific Admins

Business Unit Admins

One instance of this role will be required for every business unit.

Account Admins

One instance of this role will be required for every administrative group that needs the ability to manage user accounts. For each such administrative group, document the scope of authority by documenting the set of users that should be managed by this group. Also, for each instance, determine the set of administrative tasks that incumbents of the role should be allowed to perform.

The following is a list of common administrative tasks that belong to this category:

• Create user accounts

• Delete user accounts

• Move user accounts

• Reset a user’s password

• Unlock user accounts

• Modify non-security sensitive information, such as phone numbers

• Modify security-sensitive information

• Examples of security-sensitive information include whether or not a password is required on the account, whether the account is trusted for delegation, and modifying the UPN of the user account.

• Authorize access to the account

For each instance, evaluate the needs for and document the set of administrative tasks that incumbents of the role should be allowed to perform. This information will be used during the implementation phase to delegate each of these administrative role instances.

Workstation Admins

One instance of this role will be required for every administrative group that needs the ability to manage workstations. Most organizations have one or more administrative groups for every location that houses workstations. For each such administrative group, document the scope of authority by documenting the set of workstations that should be managed by this group.

Workstation management typically includes being able to manage all aspects of workstations; thus, incumbents in this role typically are Local Administrators on member workstations.

Server Operators

One instance of this role will be required for every administrative group that requires the ability to manage servers. Most organizations have one or more administrative groups for every location that houses servers. For each such administrative group, document the scope of authority by documenting the set of servers that should be managed by this group.

Server management typically includes being able to manage all aspects of member servers; thus, incumbents in this role typically are Local Administrators on member servers.

Resource Admins

One instance of this role will be required for every administrative group that needs the ability to manage resources (services or applications being hosted on a set of one or more servers and collectively managed by a single group of administrators). For each such administrative group, document the scope of authority by documenting the set of servers and the specific service that constitute the resource that should be managed by this group.

Resource management typically includes being able to manage all aspects of the service and manage all aspects of the servers on which the service is being hosted, although this might not always be the case. In some cases, the responsibility might be restricted to being able to manage only the service that is being hosted on or more servers.

Security Group Admins

There should only be one instance of this role for every business unit. Depending on the specific administrative needs of the business unit, the business unit data owners might decide to create more than one instance of this administrative role. For each instance determine the set of administrative tasks that incumbents of the role should be allowed to perform.

The following is a list of common administrative tasks that belong to this category:

• Create security groups

• Modify the membership of security groups

• Modify other properties, such as managed-by information

• Delete security groups

For each instance evaluate the need for and document the set of administrative tasks that incumbents of the role should be allowed to perform. This information will be used during the implementation phase to delegate each of these administrative role instances.

Help Desk Operators

One instance of this role will be required for every administrative group that needs the ability to provide account support to a subset of user accounts or to all user accounts. For each such administrative group, document the scope of authority by documenting the set of users for whom this group will provide account support.

The following is a list of common administrative tasks that belong to this category:

• Reset passwords on user accounts

• Unlock user accounts

• Optionally, a business unit might also decide to grant its help desk operators the ability to modify certain attributes on user objects; these attributes will typically be non-security sensitive attributes that users cannot themselves modify

For each instance, evaluate the need for and document the set of administrative tasks incumbents of the role should be allowed to perform. This information will be used during the implementation phase to delegate each of these administrative role instances.

Application-Specific Admins

One instance of this role will be required for the administrative group of every Active Directory–enabled or Active Directory–integrated application that requires the ability to manage application-specific data stored in Active Directory. For each such administrative group, document the scope of authority by documenting the set of application-specific data that this group will require the ability to manage.

The nature of administrative tasks in this category is typically a function of the specific Active Directory–enabled or Active Directory–integrated application deployed and the specific administrative requirements of that application. The administrators of these applications should have a good understanding of these administrative requirements. The business unit data owners should understand these requirements and plan for facilitating the required access to enable these administrators to carry out their administrative tasks.

Assigning Administrators to Role Instances

For each instance of every data management role required, document the identities of all administrators who will be assigned to these role instances.

Planning an OU Hierarchy

Planning an OU hierarchy based on the administrative delegation and Group Policy requirements of the business unit is one of the first steps in creating a delegation model. A well-designed OU hierarchy should adequately address an organization’s Group Policy requirements while also facilitating the delegation of administrative authority based on the organization’s administrative requirements.

This section provides recommendations for creating a well-designed OU hierarchy.

An OU for every Business Unit

In the section “Implementing Your Data Management Delegation Model” later in this document, as part of the handoff process wherein service owners hand off data management delegation to data owners, a single high-level OU named Business Units will be created with the purpose of creating a subtree to contain a single high-level OU for each business unit. That way, all domain data can be contained within this one OU subtree rooted at the Business Units OU instead of at the Domain root. This recommended approach has the following advantages:

• This facilitates delegation of administration of each business unit to the respective business unit administrator while allowing the specification of any permissions that might be required to delegate administrative authority over data across all business units at the Business Units OU instead of at the Domain root. This prevents the inheritance of any ACEs applied in the System container and in the DNS containers, thereby substantially reducing the number of ACEs, which might impact the size of that database significantly in Windows 2000. In Windows 2003, the concept of single-instances makes this a non-issue. For example, if the administrative needs of Contoso Pharmaceuticals required that a single centralized administrative group be delegated the authority to provide Account support for all business units in the domain, their administrators would typically grant the security group representing the operators in the Account support role inheritable permissions expressed in three or four ACEs applied on the domain root object. While this would have the effect of the ACEs flowing down to all user objects in all business units, it would also result in these ACEs flowing down on all DNS record objects in the DNS container; assuming that there are about 5000 records in the DNS container, this approach would result in 5000 additional ACEs in Windows 2000, significantly impacting the database size. On the other hand, if these inheritable ACEs were applied on the Business Units OU in the recommended approach, they would only be inherited by objects stored in the subtree rooted at the Business Units OU.

• This also increases the manageability of domain data by eliminating the need to create multiple OUs that are peers of the OUs that exist by default. It increases manageability because it leaves the top-level OU hierarchy unchanged with the exception of the addition of a single OU, thereby minimizing the possibility of confusion.

Each business unit is then represented by an OU directly under the Business Units OU, and as is presented in the Implementing Your Data Management Delegation Model section, the handoff process also involves granting the Business Unit Admins of each business unit full control over their OUs. Business unit data owners and Business Unit Admins are then free to create their own OU sub-structure to manage business unit content.

The next issue to consider is the creation of an OU structure for the business unit so that responsibility for managing business unit content can be delegated while also taking into account Group Policy requirements. The general approach is to first create an OU sub-structure for the business unit based on delegation of administration requirements, and then apply Group Policy on existing OUs or add additional OUs, possibly in various parts of the OU tree, for the purpose of applying Group Policy. There should be a well-understood reason for the presence of every OU in the OU structure.

An OU for Storing Delegated Roles

An organization that plans to create and implement a roles based delegation model will require an OU to store the security groups representing the various roles. Dedicating one OU to storing the security groups allows the Business Unit Admins to easily identify all delegated roles and have a single point of administration to control the set of administrative roles and the set of administrators assigned to each administrative role. Thus it is recommended to create an OU dedicated to storing all administrative roles, as a child object of the OU representing the Business Unit.

Creating the First Level of OUs

The following recommendations are aimed at creating an OU structure that meets your organizations needs while remaining simple and flexible, thereby allowing room for change, extensibility, and any modifications that might be needed to address changing administrative needs. To create the first level of OUs, perform the following tasks:

1. Create a single OU under the Business Unit OU for storing all business unit user accounts.

   You should plan on storing all your user accounts in this OU. Recommendations for how to create an OU hierarchy within this OU to address specific administrative requirements for account management are provided later in this section.

2. Create a single OU under the Business Unit OU for storing all business unit security groups

   You should plan on storing all security groups required to meet the authorization needs of your IT resources in this OU. Recommendations on how to create an OU hierarchy within this OU to address specific administrative requirements around account management are provided later in this section.

3. Create a single OU under the Business Unit OU for storing all business unit user resources

   You should plan on storing computer accounts for all your workstations and servers within this OU. Recommendations on creating an OU hierarchy within this OU to address specific administrative requirements around workstation and server management and facilitate delegation of resource management to specific administrative groups are provided later in this section.

Figure 2 shows a representative OU structure based on the recommendations presented earlier in this section. Note that Product Development and Business Management are the two Business Unit OUs, one for each of the two business units in the fictitious organization represented in the example.

The OU structure thus far can be used to perform the following delegations:

• An organization can delegate account management of all business unit accounts to a single administrative group by granting appropriate permissions on the Accounts OU. This is sufficient for a small organization with a single location and a relatively small number of users.

• An organization can delegate workstation management of all business unit security groups to a single administrative group by granting appropriate permissions on the Security Groups OU. This is sufficient for a small organization with a single location and needing relatively small numbers of security groups to address its authorization requirements.

• An organization can delegate overall resource management of all business unit IT resources to a single administrative group by granting appropriate permissions on the Resources OU. This is sufficient for a small organization with a single location and a relatively small number of IT resources to manage.

• An organization can delegate account support for all business unit user accounts to a single administrative group by granting appropriate permissions on the Accounts OU. This is sufficient to meet the needs of an organization of any size that has a single administrative group that provides centralized account support.

Creating OUs to Delegate Account Management

For most small organizations where there is only one group responsible for account management, the OU structure for account management described earlier in this section should be sufficient to delegate account management to that administrative group.

Depending on your administrative needs for delegating account management, an OU subtree can be created under the Accounts OU to facilitate distribution of account management responsibilities among various groups.

For every Account management role identified earlier in this section that requires the ability to manage a specific set of users, create a single OU under the Accounts OU and store in this OU the user accounts of the specific set of users that this group is responsible for managing. For example, if the business unit contains four divisions, and each division requires the ability to manage its own users, create one OU for each division and store all user accounts that should be managed by the administrators of a specific division in the OU corresponding to the division.

The creation of an additional level of OUs will enable the delegation of account management to the Account Admins of each division. In some cases, the Account Admins of a division might want to sub-delegate account management to other Account Admins within the division, one for each sub-division. An organization can create an additional set of OUs under each divisional OU to sub-delegate account management to other Account Admins within the division.

In general, an OU typically corresponds to a unit of delegation, in that it can be used to apply a set of permissions that become effective on all objects in the subtree rooted at the OU. From that perspective, a new OU or a new level of OUs can be added to facilitate delegation of administrative responsibility.

The following are some common scenarios of administrative requirements that can be addressed by the recommendations described earlier in this section:

• Assume that your organization is spread across multiple locations and your IT model requires delegation of account management to locally based administrative groups. In this scenario, you can create an additional set of OUs, one for each location, and then store user accounts in the OU representing the physical location where the user account is based. You can then distribute and delegate account management by specifying permissions on these OUs.

Figure 3 illustrates the three-location OU structure that accommodates user accounts that must be managed separately in Locations A, B, and C.

Each location in Figure 3 has a different set of administrators in the role of Account Admins. To implement this scenario, the Business Unit Admin creates four instances of the Account Admins role, each represented by a unique security group. The Business Unit Admin can grant either Full Control over their respective OUs or specific permissions to delegate specific administrative tasks within the Accounts OU to each instance of Account Admins.

• Assume that your IT model requires that different categories of users be managed by separate administrative groups. For example, suppose your IT model requires that all user accounts for contracting employees are to be managed by one administrative group while all user accounts for full-time employees are to be managed by another administrative group. You can create an additional level of OUs, one representing contracting employees and the second representing full-time employees.

• Taking this one step further, suppose that an additional constraint requires that all user accounts for all company executives are to be separately managed by yet another administrative group. In this case, you can create a third level of OUs under the OU representing full-time employees, separate regular full-time employees from executives, and accordingly grant permissions on both OUs to delegate account management to different groups.

• You can use the same OU structure to apply a different Group Policy to contractors and full-time employees. Thus, most of the time, you can also derive the additional benefit of being able to meet your administrative requirements and address Group Policy requirements.

• Assume that you have no requirements for further distributing account management. You can still create a second level of OUs to meet Group Policy application needs. For example, assume that corporate policy dictates that a stricter user policy be applied to user accounts of all users who travel extensively. You could create a second level OU structure for the purposes of applying Group Policy to a specific set of users.

These scenarios are only meant to illustrate the creation of an OU structure for addressing administrative and policy enforcement requirements. Other administrative requirements similar to those illustrated here can also be similarly addressed by the creation of an appropriate OU structure.

Creating OUs to Delegate Security Group Management

Most organizations can benefit from the creation of an additional level of OUs within the OU assigned for storing and managing security groups. A well-designed OU subtree within the Security Group OU can also make managing security groups for administering IT resources more tractable.

The following is a recommended structure for OUs within the Security Group OU

Create the following OU structure under the Security Group OU:

• An OU for storing common account groups; a suggested name is Common Account Groups.

• An OU for storing Account and Resource groups for specific IT resources; a suggested name is Resource Specific Groups.

Use the Account Groups OU to store and manage common account groups for your business unit. Examples include Business Unit Users, Location A, Division B Users, Division C Managers, Business Unit Executives, and Business Unit Executive Assistants.

• Use the Resource Specific Groups OU to manage resource-specific account and resource groups as follows. Within the Resource Specific Groups OU, perform the following steps to create the OU structure:

• Create one OU for the different kinds of resources in your organization. Examples include Web-Servers, File-Servers, Application servers, and Database servers.

• Within each resource-specific OU, create one OU for each specific resource. For example, within the OU for Web server security groups, create an OU for the Web servers hosting the Human Resources Web application and another OU for the Web servers hosting one of the Intranet Web sites.

Within the OU for a specific resource, create one OU for storing the account groups and another OU for storing the resource groups that resource administrator might require to authorize access to the resource. For example, the administrator of a Web portal will require at least multiple resource groups to specify who can access the Web portal and to what extent. The resource administrator will also require the ability to specify a collection of users that can access the Web portal in a particular way. For instance, the Web portal administrator might use an account group FT to collect all full-time employees and a separate account group CT to collect all contractors. The administrator would then make the FT group a member of the resource group that was used to specify to the Web application all users who have unrestricted access to all parts of the portal, while making the CT group a member of the resource group that was used to specify to the Web application all users who have restricted access to all parts of the portal.

The OU structure recommended earlier in this section can be used to simplify security group management and make it more tractable.

Figure 4 shows an example OU structure that collects account groups in the Account Groups OU and separates resource groups into OU trees according the resources. This OU structure associates the groups with their respective resources for easier management.

Note that the recommendations described earlier in this section are by no means the only way to facilitate management of security groups. Organizations should take their specific administrative needs into account when designing their OU structures. For example, one alternative to storing resource specific security groups in the Security Groups OU is to create an OU to store all security groups for a specific resource under the specific OU representing this resource in the Resource OU subtree, as presented later in this section. This has the additional advantage of storing the security groups associated with a resource along with the servers representing the resource, thereby storing all aspects of a resource in one small subtree.

What is important is to understand how an OU enables delegation of administrative authority and to apply this understanding to the creation of an OU structure that addresses your organization’s administrative delegation and Group Policy requirements.

Creating OUs to Delegate Resource Management

The benefits of a well-designed OU structure are most evident in the delegation of resource management. This section describes a recommended structure to facilitate delegating resource management.

Note that the recommendations presented here are by no means the only way to facilitate resource management. Organizations should take their specific administrative needs into account when designing their OU structures.

To create the recommended OU structure for delegating resource management, within the Resources OU, perform the following steps to create the OU structure:

• Create one OU to store all workstation accounts; a suggested name is Workstations.

• Create one OU each for every type of resource in your business unit; examples include file servers, Web portals, applications and databases.

Workstation management

The Workstations OU can be used to store computer accounts for all workstations in your business unit. An additional level of OUs can be used to address specific administrative requirements. Workstation management is typically delegated to local administrative groups. Thus, an organization could create an additional level of OUs, one for each physical location where the business unit has a presence, and all workstations for a specific physical location can be stored in the OU representing that physical location. Such an OU structure can be used to easily delegate workstation management to all administrative groups. In general, the various instances of the Workstation Admins role will usually correspond to the OUs under the Workstations OU; this is because in general, each OU serves to separate workstation accounts for the purpose of provisioning management of these accounts by a separate administrative group.

Delegating workstation management typically involves granting complete control over the computer account representing the workstation and using the restricted groups feature of Group Policy to make an administrative group a member of the administrators group on these workstations. Since OUs can facilitate both the granting of full control and the application of Group Policy, they can be used to delegate workstation management.

Figure 5 shows the OU structure that illustrates this decentralized approach to managing workstations.

Resource Management

A well-designed OU structure can also be used to manage servers and to delegate management to the respective administrative groups of the various IT resources that are hosted by a collection of servers. The recommendation earlier in this chapter to create one OU for every type of resource under the Resources OU aids in increasing manageability of resources.

Under the OU created for each resource type, introduce an additional level of OUs with each OU in this level representing a specific resource. For example, under the Web Servers OU, create a specific OU for storing the computers of all servers on which the Human Resources Web portal is collectively hosted. Figure 6 illustrates such an OU structure.

The OU hierarchy structure for resource management that is recommended earlier in this chapter offers the following benefits:

• It allows you to delegate administrative authority for all resources of a specific type to a specific administrative group. For example, you could delegate overall management of all file servers to an administrative group responsible for overall file-server management by granting sufficient permissions on the File Servers OU. This group will then be able to manage all file servers within the organization.

• It allows you to delegate administrative authority of specific IT resources to only those administrative groups that have been assigned the responsibility to manage that specific resource. For example, you could specify appropriate permissions on the various OUs representing specific file servers to delegate management of those file servers to specific administrators.

These recommendations are by no means the only way to facilitate resource management. Organizations should take their specific administrative needs into account when designing their OU structures.

After you have created your OU hierarchy structure based on your organization’s administrative requirements and needs, you should then consider your organization’s Group Policy application requirements.

Considering Group Policy Application Requirements

An OU hierarchy structure should be based on administrative delegation requirements and Group Policy application requirements. Group Policy can be associated with OUs and is applied onto all user and computer accounts stored in the OU. Thus, Group Policy application requirements also impact the OU structure.

It is recommended that the OU hierarchy be first designed based on delegation of administration requirements, and then be appropriately modified to address Group Policy application requirements. The following examples illustrate this guideline. Assume that an organization has decided on the OU structure presented in Figure 7.

First Example

In the first example, assume that Group Policy requirements for this organization include that a location-specific Group Policy be applied to all computers based on their location, irrespective of the role of the computers. To accommodate this requirement, the OU hierarchy structure in Figure 7 can be modified as follows:

• In the Resources OU, directly below the Resources OU, introduce a single level of OUs, one for each physical location in the business unit. Within each such OU representing a physical location, recreate the same set of OUs as initially designed. Thus, each OU representing a specific location should have one child OU for Workstations and one child OU each for the different types of resources within the business unit. Each of these OUs in turn should continue to have the same sub-structure as was initially created. The primary difference in the modified OU hierarchy structure is that an additional level of OUs has been introduced for the sole purpose of applying Group Policy. Note that these OUs are not being used for delegating administrative authority, although nothing prevents using them for this additional purpose if necessary.

Second Example

In the second example, assume that Group Policy requirements for this organization include that a location-specific Group Policy be applied to all workstations, based on their location:

• To accommodate this requirement the OU hierarchy structure will not need to be modified, because an organization might already typically have in place a level of OUs separating workstation accounts based on their location. These OUs can then be used to apply Group Policy to workstations based on their location

Third Example

In the third example, assume that Group Policy requirements for this organization include that a specific Group Policy be applied to all users that belong to a specific division within the business unit:

• In this case, depending on the OU structure within the Accounts OU, an additional level of OUs could be introduced to separate the accounts by division, if they are not already separated, and Group Policy can then be applied to the specific OUs representing each division with the business unit.

These examples illustrate how an OU hierarchy model primarily based on delegation of administration requirements can be suitably modified to address Group Policy application requirements.

Having gained an understanding of how OUs can be used to both delegate administrative authority and meet Group Policy application requirements, you can proceed to create an OU hierarchy based on your administrative delegation requirements and your Group Policy application requirements. After you have created the OU hierarchy, you are ready to document your delegation model and move to the implementation phase.

Documenting Your Delegation Model

Before proceeding to the implementation phase, be sure to document your administrative roles requirements, your OU hierarchy, and your Group Policy requirements. Table 6 is a template that you can use to document your role instances.

Table 6 Template to Document Specific Role Instances (With Example Values)

Field	Assignment Information
Instance of:	Account Admins
Instance Number:	1 of 4
Assigned Administrators:	Clair Hector
Assigned Tasks:	Create user accounts Manage all properties Control access to accounts Delete user accounts Sub-delegate Refer to document located at: document location
Security Group	To be filled during Implementation phase
Permissions Assigned	To be filled during Implementation phase
Notes	Sub-delegation allowed Most group members based out of Chicago Group contact: (555)-123-4567 e-mail: DIAccAdm

In addition, for each OU in the OU hierarchy structure, document the following:

• Primary purpose – Delegation and/or Group Policy application.

• Secondary purpose (if any) – Also being used for Delegation and/or Group Policy application.

• Details – Document all necessary details.

• Administrative Contact – Provide administrative contact details.