Roles

Active Directory has a large impact on the organization. Similar to early LAN/WAN designs for connecting the organization, Active Directory is a pervasive horizontal service in the organization used by some users unknowingly.

To support this new service, a new administration group should be formed. Although you can make the argument that directory services are an extension of existing network administration responsibilities, the reality is that Active Directory is pervasive, and Microsoft's implementation has integration requirements with a variety of services. Some of the requirements might be outside the typical Network Administrator's responsibilities.

The other key reason for implementation of a separate group responsible for the directory is that you will then have a driving force for the advocacy of the use of the directory, guidance in application implementation of the directory, and development of the policies and processes necessary to leverage this technology. It would be all too easy for Active Directory to mimic early directory services as a simple repository for network file- and print-service directory requirements. The objective with an Active Directory implementation is to create a value for the directory that is used in many aspects of the computing environment, which leverages the organizational and business objectives.

With the advent of a new group, there needs to be clear role definition. The roles are defined so that they can be integrated. We define roles that, in larger organizations, might require three staffs, and in small organization might need to be combined with other directory service roles to create a single position. This section outlines the need for specific roles in the management of the directory and relationships with existing functions in most corporate and computing organizations.

First, the roles and responsibilities are described, followed with an example in a fictional company.

Directory Services Manager/Lead

Depending on the size of the organization, either a directory services manager or a lead position should exist. The directory services manager provides the single point of contact for all aspects of Active Directory implementation, as well as some influence, if not participation, in the design, implementation, and operational procedures for other directory services that exist in the organization. The directory services manager should manage the following services:

• Design of Active Directory

• Identification of the business requirements for the implementation of Active Directory and related services

• Implementation of Active Directory

• Customization of Active Directory

• Project plan for

  Design enhancement

  Business requirements gathering

  Enhancements

• Development of the interaction with use of Active Directory

  Develops standards for the organization and use by applications

  Quality Assurance program for application use of Active Directory

• Operations and maintenance

• Backup and disaster recovery

• Staffing of the directory services team

• Organizational alliances

• Program for Active Directory service use within the organization and externally in support of e-business connectivity

Although the directory service manager surely cannot perform all the functions describe in the preceding list, the directory services manager is responsible for driving these tasks and programs to completion and general use by the organization.

Directory Services Management Emphasis

The top five priorities of Active Directory tasks previously described are the initial design, proper implementation, operations, disaster recovery, and application use of the directory. Although it might be easy for the directory services manager to be distracted with all the responsibilities and requirements, this section is designed to help identify and explain the top priorities of the directory services manager.

Design of Your Active Directory Environment

The design of Active Directory is critical to its use and function. By designing Active Directory properly, the user is able to use the directory intuitively. Although future chapters discuss the design in more depth, it is safe to say that creating a metaphor for the directory is important. The directory design should reflect some design that makes sense for the end users. An example of a common metaphor for an Active Directory design is the physical locations of the organization. Another example is the organizational structure of the company.

Administration of the directory is also affected by the design. The performance of centralized or decentralized administration is impacted by the Active Directory design. The administrators should consider the topology, bandwidth, and delegation of administration as part of the design.

Proper Implementation

After the design of your Active Directory is complete, the implementation is important as with any complex technology. The implementation must adhere to the designs or the design must be changed to reflect the implementation. An implementation of this nature requires some adjustments.

You can do several things to ensure a proper implementation. Again, these topics will be covered in more detail in later chapters, but the high-level of intent of "proper implementation" is to develop a process in the implementation. Hardware should be consistent and within specification. Validation testing should be performed to demonstrate key features of the design as the implementation moves forward. As an example: Is the directory replicating properly? Can remote users access their accounts from a distant location? Does the training add value to the understanding of the technology?

Operations

The focus on operations by the directory services manager is to emphasize the need for process and validation. This relates to the need for a design that can be administered. In addition, there is the need for reviewing capacity, performance, and "what if" scenarios.

The Operations group needs to ensure availability for the enterprise-critical service, predict future needs, and plan appropriately. Regular reporting and trend analysis on the system goes a long way toward keeping the focus on the operational environment.

Disaster Recovery

Disaster recovery of Active Directory is important for the survival of the directory services manager. Regardless of the reason for the disaster, you must be prepared to get the system up and running again. As part of your design, you should consider how you would recover from a disaster. This includes everything from a downed server to some loss of data or functionality in the system.

Because Active Directory is a horizontal service that traverses the entire organization, it is important to remember that a simple outage of service can affect a large community. The capability to recover quickly, or at a minimum to be able to communicate a process and timeline for recovery, has prevented the need for many resume updates.

Application User of Active Directory

Leveraging Active Directory naturally follows an implementation. First, users rely on it for everyday use. Active Directory provides applications with an enterprise-wide repository of information. Applications have the capability to use standard interfaces for access to information that remains consistent throughout the organization.

Some examples of the use of the directory by applications would include a Human Resources (HR) benefits application, or any type of business application that would include or integrate workflow.

Active Directory Engineer

The Active Directory engineer is the primary design engineer for Active Directory. He works to create and re-create the design as appropriate, based on the changing business requirements of the organization.

Active Directory Operations Specialist (ADOS)

The ADOS is responsible for the on-going support of Active Directory. The ADOS should have a firm understanding of the underlying architecture for the project. With the architectural understanding, the ADOS provides information on the stability, performance, and capacity of the environment.

The ADOS's daily tasks include the following items:

• Adding/deleting users and other objects

• Implementing directory design changes, as decided by the directory services engineer

• Performing backups

• Performing backup fire drills

• Reporting on performance and utilization

• Implementing changes to the directory based on design changes made by the directory services engineer

The ratio of ADOS is about 1 per 1000 end users. This ratio might change based on the wide range of locations an organization might have and the mature use of the Active Directory implementation. Simplification of directory tools and use can reduce the ratio of ADOS to end users.

Directory Services Application Specialist (DSAS)

The DSAS is the technical specialist for application development using Active Directory. This responsibility requires the ability to understand and influence the design of Active Directory in collaboration with the directory services engineer. Although the directory services engineer focuses on the function of Active Directory, based on both the underlying architecture and the information that end users need and want, the ADAS also focuses on how to use this information in conjunction with application goals.

The ADAS should understand the requirements for Active Directory. These requirements map to the features and ultimately the design. The ADAS's responsibilities include understanding the Active Directory design of the organization, developing, documenting, and reviewing applications development standards for the use of Active Directory in the organization. This should be clearly stated in the Active Directory architecture document. (The Active Directory architecture documents the business requirements for the implementation and the implementation details of the installation.)

The primary goals of the ADAS is to improve the ongoing use of the directory and to ensure that the directory provides for a consistent service. Working collaboratively with his or her peer, the directory services engineer, the Directory Services Application Specialist (DSAS) is responsible for the consistent use of Active Directory. As Active Directory becomes a horizontal service of the organization, the DSAS provides guidance for the development teams in how to use Active Directory and leverage it as an enterprise repository.

There might be the need for compromises between the DSAS and the directory services engineer to create a robust environment that provides desired performance levels for applications and end users, and ease of use for application developers, end users, and administration.

The DSAS should be responsible for identifying initiatives around the following areas.

Working with the Directory Services Engineer

The DSAS should work with directory services engineers to clearly understand the Active Directory implementation and provide insight into application use. This is a collaborative effort.

Establish Application Development Standards

The DSAS should develop standards for application development. Application use of the directory is a key leveraging point for Active Directory. The hope is to have clearly defined use of the Active Directory to ensure consistent use and support easier modifications should interfaces change later. This effort includes documenting the standards, providing sample code for typical uses, and even internal training on lessons learned from projects implemented in the organization.

Define High-Level Application Functionality Requirements

This effort is to provide the directory services engineer and developers with a clear understanding of the high-level functionality required by applications. This is particularly beneficial if setting expectations as to what can be accomplished with directory interfaces. In addition, should there be a need to migrate to another interface/technology; the migration should be identified in the context of the current high-level functionality requirements, and eventually, to the specific interface translations.

Examples of high-level functionality requirements are: 1) the capability to search the directory based on any field; 2) the capability to update the directory; and 3) the capability to limit access of directory fields based on application security context. Again, the capability to establish high-level requirements helps to support any future migrations or application programming interface changes. The high-level definitions also provide a clear way to communicate the functionality available in the interface without diving into the detailed specifications. The DSAS provides guidance for the development teams in how to use Active Directory. Figure 1.1 depicts the organization of the directory services team.