Module 3: Designing Active Directory to

Delegate Administrative Authority

Overview

Identifying Business Needs

Characterizing the IT Organization

Developing a Strategy for Administrative Design

Developing a Strategy for Delegation

Microsoft® Windows® 2000 Active Directory™ provides network architects with control over information access in Active Directory. By structuring the Active Directory hierarchy and then managing the permissions on directory objects and properties, you can precisely specify the accounts that can access the directory and the level of permissions that they can have. For example, you can give a person authority over user passwords in a particular organizational unit (OU), without giving that person any control over other objects or attributes in Active Directory. This precise specification allows administrators to delegate specific authority over portions of the directory to groups of users, without making directory information vulnerable to unauthorized access.

At the end of this module, you will be able to:

Identify the business needs of an organization that will impact the hierarchical design of Active Directory.

Develop a strategy for planning an administrative design that facilitates delegation.

Develop strategies for delegation of administrative authority.

Identifying Business Needs

Documenting the Administrative Process:Level of AdministrationWho Administers WhatBuild Flexibility Into Plan

AccountingAccounting

AccountsAccountsPayablePayable

OrganizationalChart

ITInfrastructure

InfrastructureInfrastructure

AtlantaAtlanta SeattleSeattle

NorthwestNorthwestNortheastNortheastSoutheastSoutheast

CharlotteCharlotte

Information Information TechnologyTechnology

PortlandPortland

Information Information TechnologyTechnology

AccountsAccountsReceivableReceivableLogisticsLogisticsPurchasingPurchasing

HumanHuman Resources ResourcesProductionProduction

CEOCEO

Organizations can delegate administrative authority by granting limited administrative permissions to trusted individuals. Delegation reduces the workload and responsibility of a single administrator. Delegation also safely separates administrative authority from other areas of the organization. Managers who have the appropriate administrative rights can, in turn, delegate administration of a subset of their accounts and resources to other individuals.

To support delegation of administrative authority, you should design the Active Directory structure to support the organization's desired administrative Information Technology (IT) structure.

Documenting the Administrative Process

Begin by documenting the existing structure of the organization. One strategy is to divide the administrative tasks into categories and then document the administrator or administrators responsible for each category.

Once the existing process has been documented, you should work with the planning team to identify areas for improvement. For example, it may be more cost-effective to combine several IT teams from different divisions. You may identify non-IT employees who can assist in the administrative process and reduce the IT staff workload. This allows the IT staff to focus on the areas where their expertise is most needed.

Once the existing and desired processes are identified, use the following as guidelines for your delegation plan:

Determine the level of administration. Decide what each group should control and at what level in the administrative hierarchy you will delegate administration. The delegation plan should define what permissions a group of users may have for that level of the hierarchy.

Identify the administrators and the users and resources they administer. This information will help determine the ownership and permissions assignment to the OUs you create to support the delegation plan. An administrator or the object owner must grant users access rights to an object in Active Directory before users can have access to the object.

Build flexibility into your delegation model. You can grant rights to administrators to manage a small set of users or groups within their area of responsibility and, at the same time, deny rights to manage accounts in other parts of the organization. For example, you may want to grant printer control rights to a small group of users. You may allow certain OU administrators to have Full Control over specific OUs and objects. You may restrict other administrators altogether, so that they are not able to view the OU.

Characterizing the IT Organization

Centralized IT

Centralized IT with Decentralized Management

Decentralized IT

Outsourced IT

Before designing the administrative structure of an organization, you must first characterize your IT organization. The most common IT organizations are:

Centralized IT. The centralized IT organization reports to a single individual, and is usually the group responsible for all network and information services, although some day-to-day tasks may be delegated to certain groups or departments.

Centralized IT with Decentralized Management. IT organizations often employ distributed management, where control is spread out across more than one location. In this model, a centrally located core IT team has responsibility for the base infrastructure services, but delegates most of the day-to-day operations to IT groups in branch offices, which provide local administrative support to their users.

Decentralized IT. This type of organization allows various business units to select an appropriate IT model to serve the needs of each individual unit. This type of organization may have multiple IT groups with varying needs and goals. Whenever there are organization-wide technology initiatives, such as an upgrade to an organization-wide messaging application, the IT groups must work together to implement changes.

Outsourced IT. Some organizations may choose to outsource all or part of their IT organization. When only parts of the IT organization are outsourced, it becomes imperative that a proper delegation model be implemented. Thus, the internal IT group maintains control of the organization without compromising the service level agreements the outsourced company has committed to provide. For example, if an outsourced company has committed to support the physical infrastructure of an organization's network, you may choose to create OUs to contain the routers, servers, and any other items over which they may need control.

Developing a Strategy for Administrative Design

Designing a Hierarchy Based on Location

Designing a Hierarchy Based on Organization

Designing a Hierarchy Based on Function

Designing a Hybrid Hierarchy by Location then Organization

Designing a Hybrid Hierarchy by Organization then Location

Design Guidelines

If your Active Directory design is accurately modeled after the needs of an organization's administrative IT model, then that design will best support delegation of administrative authority.

When planning the Active Directory administrative structure, it is important to accommodate for change and growth in the organization. Organizational changes should not impact the domain and high level OU structure, for example.

In this lesson you will learn about the following topics:

Designing a hierarchy based on location

Designing a hierarchy based on organization

Designing a hierarchy based on function

Designing a hybrid hierarchy by location then organization

Designing a hybrid hierarchy by organization then location

Design guidelines

Designing a Hierarchy Based on Location

Is Resistant to Change

Accommodates Mergers and Expansions

May Compromise Security

Takes Advantage of Network Strengths

OUNew New

EnglandEnglandNew New

EnglandEngland

BostonBostonBostonBoston HartfordHartfordHartfordHartfordna.nwtraders.msft asia.nwtraders.msft

Domainnwtraders.msft

If the IT organization is centralized, but network management is geographically distributed, then organizing the Active Directory structure by location may be the best strategy. For example, you may decide to create OUs for New England, Boston and Hartford within the same domain, such as contoso.msft.

Characteristics of Location-based Designs

A location-based OU or domain hierarchy possesses the following characteristics:

Resistant to company reorganizations. While divisions and departments may change frequently, location rarely does in most organizations.

Accommodates Mergers and Expansions. If an organization merges with or acquires another company, it is simple to add new locations to the OU or domain hierarchy.

Takes Advantage of Network Strengths. Typically, an organization's physical network topology will resemble a location-based hierarchy. If you create domains with this method, you can take advantage of areas where the network has high bandwidth, and limit the amount of data replicated across low bandwidth areas.

Possible Security Compromises. If a location includes multiple divisions or departments, an individual or group with administrative authority over that domain or OU may also have authority over any child domains or OUs.

Important: A location-based OU or domain hierarchy is recommended only if administrators are present at each location. If administrators from multiple departments or divisions are in the same location, they may need to cooperate with each other for certain administrative tasks.

Reflects Business Model

Is Vulnerable to Reorganizations

Maintains Departmental Autonomy

Accommodates Mergers and Expansions

May Affect Replication

Designing a Hierarchy Based on Organization

OUmanufacturingmanufacturingmanufacturingmanufacturing

engineeringengineeringengineeringengineering purchasingpurchasingpurchasingpurchasing

researchresearchresearchresearch

Domainnwtraders.msft

mfg.nwtraders.msftdistrib.nwtraders.msft

An organization that separates IT administration by department or division may choose to design Active Directory based on the structure of the organization. An architect must be very careful to follow the administrative structure, rather than the organizational chart, when designing an organization-based Active Directory. The organizational chart may not map to the administrative needs of an organization. If you design the Active Directory structure to reflect the organizational chart, it may be difficult to delegate administrative authority, because the objects in the Active Directory, such as printers and file shares, may not be grouped in a way that facilitates delegation of administrative authority. Because users never see the Active Directory structure, the design should accommodate the administrator's convenience instead of the users' convenience.

When deciding whether to organize the Active Directory structure by organization, consider the following characteristics of organization-based designs:

Reflects Business Model. An organizational structure tends to better reflect the organization's actual business practices than a structure based on location. However, users do not see the hierarchical structure.

Vulnerable to Reorganizations. Because the reorganization of the corporate structure can greatly alter the organization-based design, extensive IT resources may be needed to restructure Active Directory.

Maintains Departmental and Divisional Autonomy. An organizational hierarchy presents few security concerns, because there will likely be no crossing of departmental or divisional boundaries with this design. When trying to define the hierarchy design, the security requirements at the departmental level are an important factor.

Accommodates Mergers and Expansions. If an organization merges with or acquires another organization, additional departments can be easily added to the organization-based hierarchy.

May Impact Replication. Organization-based structures that are used to create domains may not make efficient use of the network, because the domain naming context may replicate across one or more low bandwidth areas.

Designing a Hierarchy Based on Function

Is Immune to Reorganizations

May Require Additional Layers

May Affect Replication

salessalessalessales

consultantsconsultantsconsultantsconsultants marketingmarketingmarketingmarketing

hardwarehardwarehardwarehardware

project1project1project1project1 project2project2project2project2

An organization with decentralized administration may choose to design the Active Directory structure based on the functions within the organization. A function-based hierarchy is an ideal choice for small organizations that have job functions that span several departments. For instance, an organization such as a consulting agency may have a cross-departmental team that is dedicated to supporting a particular customer. Such a company could benefit from a function-based design.

A function-based hierarchy considers only the business functions of the organization, without regard to geographical location, departmental or divisional barriers. Choose this approach only if the IT function is not based on location or organization.

Characteristics of Function-based Designs

When deciding whether to organize the Active Directory structure by function, consider the following characteristics of function-based designs: Immune to Reorganizations. A function-based hierarchy is not

affected by corporate or organizational reorganizations. May Require Additional Layers. When using this structure, it may be

necessary to create additional layers in the OU hierarchy to accommodate administration of users, printers, servers, and network shares.

May Impact Replication. Organization-based structures that are used to create domains may not make efficient use of the network, because the domain naming context may replicate across one or more areas of low bandwidth.

Important: Function-based hierarchies are only appropriate in small organizations because functional departments in medium and large organizations are often very diverse and do not group effectively into broad categories.

Designing a Hybrid Hierarchy by Location then Organization

Allows for Growth

Allows for Security Boundaries

Leverages Strength of Physical Network

May Require Lower Level Changes Aftera Reorganization

asia.nwtraders.msft

MfgMfgMfgMfg

researchresearchresearchresearch

HRHRHRHR

recruitingrecruitingrecruitingrecruiting trainingtrainingtrainingtraining

Some organizations combine various strategies to accommodate the most appropriate administrative structure. Designing a hybrid hierarchy combines strengths from several areas to meet the needs of the organization.

Designing the higher OUs or domains by location, and the lower OU or domain levels by organization works well in a highly distributed organization with a centralized IT function and strong departmental or divisional separation. Because the highest levels are based on location, this model is less likely to change, and therefore less likely to require a major effort in the event of a reorganization.

When designing a hybrid hierarchy by location then organization, consider that this type of hierarchy has the following characteristics:

Allows for additional geographic, departmental, or divisional growth.

Allows for distinct security boundaries by department or division.

May necessitate a new design of the lower OUs or domains if the IT function is reorganized.

May require administrators to cooperate with each other for some administrative tasks if they are in the same location but in different divisions or departments.

Designing a Hybrid Hierarchy by Organization then Location

Allows for Security Boundaries

Allows Administration by Location

Vulnerable to Reorganizations

sales.nwtraders.msft

New EnglandNew EnglandNew EnglandNew England

BostonBostonBostonBoston HartfordHartfordHartfordHartford

Designing the higher OUs or domains by organization and the lower OUs or domains by location works well in a large, highly distributed organization that has physically distributed distinct business units with a need for distinct security policies in each division. The upper organizational/lower location hierarchy supports the business organization, while still accommodating geographic distribution of the IT function.

When deciding whether to choose a hybrid hierarchy by organization then location, consider that this type of hierarchy has the following characteristics:

Allows for strong separation of administrative function between departments or divisions, while still allowing administrative delegation based on a physical location.

A reorganization will alter the design of the OU or domain hierarchy, which will in turn require an extensive amount of work for the IT department to reconstruct it.

If this method is used for domain creation, it may not make effective use of the physical network, because domains will likely be located in multiple sites.

Regardless of the hybrid hierarchy used, organizations can add additional OUs to facilitate function-based administration. For example, you can create additional OUs that divide the users, mail servers, domain controllers, and print servers into separate containers, if each is managed by a different group of individuals.

Design Guidelines

Hierarchy

Location

Organization

Function

Hybrid Hierarchy

By Location then Organization

By Organization then Location

The table summarizes various design strategies for hierarchical design and the characteristics of each. The following flow chart represents a decision tree that is useful for determining the appropriate hierarchical strategy for an organization.

Design strategies for hierarchical design and the

Developing a Strategy for Delegation

Determining Delegation Methods

Determining Object Ownership

Creating a Strategy for Object-Based and Task-Based Delegation

Creating a Strategy for Delegating Authority

Creating Strategies for Inheritance of Permissions

Design Choice Guidelines

Demonstration: Using Visio 2000

Delegation of administration is the process of decentralizing the responsibility for container ownership and administration from a central administrator to other people or groups within the organization. You can use several methods to delegate authority, and assign to users and groups different categories of ownership. The ability to establish separate access to sites, domains, and OUs is an important security feature in Active Directory.

Use the following to identify the important factors to consider when planning administrative delegation:

Determining methods used for delegating authority.

Examining object ownership.

Creating strategies for object-based and task-based ownership.

Creating strategies for delegating authority at different administrative levels.

Creating strategies for planning inheritance of permissions.

Documenting the delegation plan.

Examining guidelines for designing delegation of authority.

Determining Delegation Methods

Delegating Authority Includes:

Changing Container Properties

Creating, Changing, and Deleting Child Objects

Updating Object Attributes

Creating New Users or Groups

Managing Small Groups of Users or Groups

When you are planning to delegate administration, you should decide what permissions you want to assign to various users in your organization. You may apply permissions to an object, a branch of the Active Directory tree, a particular object type, or an attribute. The following are types of permissions you may want users to have:

Change container properties. Designated users will be able to change properties on a particular container, such as the GPOs set on an OU.

Create, change, and delete child objects. Designated users will be able to create, change, and delete child objects of a specific type within a container, such as users, groups, or printers.

Update object attributes in a certain class. Designated users will be able to update specific attributes on child objects of a specific class within a container, for example, the right to set passwords on user objects.

Create new users or groups. Designated users will be able to create new users or groups within the container.

Manage a small group of users or groups within a given area of responsibility. Designated users will be able to manage a small set of users or groups within their area of responsibility, such as a container in the Active Directory structure. For example, a user can be given the ability to manage printer queues and file resources within a particular OU or among several OUs.

Determining Object Ownership

1. Creator Grants Permission1. Creator Grants Permission to User to Take Ownership to User to Take Ownership

1. Creator Grants Permission1. Creator Grants Permission to User to Take Ownership to User to Take Ownership

CreatorCreator

User AccountUser Account

2. User Takes2. User TakesOwnershipOwnership

2. User Takes2. User TakesOwnershipOwnership

3. New Owner3. New Owner3. New Owner3. New Owner

Every object in Active Directory has an owner. The person who creates the object automatically becomes the owner and, by default, has Full Control over the object. When assigning permission to create objects, remember that the owner of an object controls how permissions are set for an object and to whom permissions are assigned, even if the owner is not listed in the discretionary access control list (DACL).

Owners can assign the Take Ownership permission to any user or group account. When creating a plan to delegate administrative authority, remember that a user or group account with this permission can take ownership of the object, and will retain ownership until the permission is removed.

Note: Members of the Domain Admins group always have the ability to take ownership of any object in the domain and then change the permissions. This is one reason to limit the number of users in the Domain Admins group. If a member of the Administrators group creates an object or takes ownership of an object, the Administrators group becomes the object's owner. For tracking purposes, the name of the specific Administrators group member who created the object or took ownership is also listed as owner.

Creating a Strategy for Object-Based and Task-Based Delegation

OUAdminsFull Control

Entire OUEntire OU

OUAdminsReset password

Object-Based Task-Based

Users Only

Administrative delegation can be based on objects, such as sites, domains, and organizational units, or on tasks. An example of a task is "change all passwords for all user objects in this organizational unit." Determining whether the object-based or task-based delegation is best depends on the administrative model used in the organization.

In general, avoid assigning permissions at the task or attribute level. Assigning permissions at this level is time-consuming, thereby increasing administrative overhead. It is also difficult to document administrative authority. Consider placing objects in separate OUs based on how they will be managed. This allows for inheritance, easier documentation, and better troubleshooting.

Creating a Strategy for Delegating Authority

Domain-Level Delegation Affects All Objects in the Domain

OU-Level Delegation Can Affect Parent OU Only, or Parent and All Child OUs

Site-Level Delegation May Affect Multiple Domains

The goal of delegating the ability to grant permissions wherever possible is to conserve administrative effort and cost, thus reducing the total cost of ownership (TCO). Assigning permissions to users in an organization involves deciding who can and cannot gain access to an object and its contents, and the type of access that a person may or may not have.

Creating Strategies for Inheritance of Permissions

Full ControlOU

OU

OU

Full Control

Full Control

Objects Inherit Existing Permissions

Inheritance Can Be Blocked

The following methods can be used to assign permissions to users in an organization:

Delegating the ability to assign access control permissions for objects to users or groups of users; in other words, delegating the ability to delegate.

Controlling which users can gain access to individual objects or object attributes, and the type of access these users have.

Assigning common or special permissions on objects.

Using inheritance to allow access control permissions to flow to child objects.

Note: The object type defines the available permissions and varies from one object type to another.

When deciding whether to delegate authority at the site, domain, or organizational unit level, remember the following points:

Authority delegated at the site level will likely span domains, or conversely may not include targets within the domain.

Authority delegated at the domain level will affect all objects in the domain.

Authority delegated at the organizational unit level can affect that object and all of its child objects, or just the object itself.

Careful planning of permissions can eliminate the need to assign permissions to individual objects in Active Directory. Objects that are created inherit the permissions that are assigned to the parent object. The advantage of inheritance is that an administrator can manage permissions of all objects in a container without having to manage all of the child objects separately.

Permissions can be applied to an object only; an object and all of its child objects; child objects only; or specific types of child objects, such as computers, users, or groups.

Inheriting Existing Permissions

In Active Directory, the permissions on directory objects are stored as attributes of the objects. When an object is created, its DACL contents are determined, based on the default permissions for the type of object in the schema and the permissions on the parent container.

Blocking Inheritance of Permissions

At times, you may need the specific permissions on an object to override the permissions that might be inherited from a parent. You can prevent a child object from inheriting permissions set on the parent object. Future changes to the parent object's permissions will not change the DACL on the child object. Blocking inheritance makes it difficult to document and troubleshoot permissions on an object. Try to avoid blocking inheritance of permissions.

Note: To change the permissions for an entire hierarchy, change the permissions for the top parent object and specify that the change should also affect child objects. The permissions will be added automatically to the DACL of every object in the hierarchy.

Design Guidelines

Assign Permissions at the OU Level When Possible

Avoid Assigning Permissions at Property or Task Level

Use a Small Number of Domain Administrators

Assign Access Permissions to Groups

The following guidelines should be considered before planning delegation of administrative control in your organization:

Assign control at the OU level and take advantage of inheritance whenever possible. By assigning control at the highest OU level possible rather than on individual objects, managing permissions will be much easier and more efficient. It is a simpler trail for administrators to audit, and there is less chance for disaster if an administrator makes a mistake while logged on with an administrative account.

Avoid assigning permissions at the property or task level as much as possible to simplify administration. Consider placing objects in separate OUs based on how they will be managed, before deciding to manage properties with separate DACLs for objects in a single OU.

Use a small number of domain administrators. The Domain Admins group has special abilities within a domain, including the ability to take ownership of any object in the domain and define security policies for the entire domain. In situations where the domain administrator privileges need to be tightly controlled, you could grant administrative rights to users for the various OUs, and limit membership in the Domain Admins group.

Assign access permissions to groups, rather than to individuals, to grant or deny access to users. Group permissions makes it easier to keep DACLs current on networks that have many users and objects. Also, assigning permissions to groups is very powerful because groups can be nested within one another. Nesting groups reduces the total number of objects that need to be administered, and therefore reduces administrative overhead.

Demonstration: Using Visio 2000

Lab A: Designing Delegated Administration

Review

Identifying Business Needs

Characterizing the IT Organization

Developing a Strategy for Administrative Design

Developing a Strategy for Delegation