mof service management function directory services ... · services is to ensure that through a...

MOF Service Management Function

Directory Services Administration

Microsoft®

Solutions for Management

ReleaseReadinessReview

OperationsReview

SLAReview

ReleaseApproved

Review

MOF

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred. 2002 Microsoft Corporation. All rights reserved. Microsoft, Active X, and Visio are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Contents Document Purpose.................................................................................................. 1 Executive Summary ................................................................................................ 1 Process and Activities ............................................................................................. 2

Directory Services Administration Overview ................................................. 2 Goals and Objectives....................................................................................... 3 Scope ................................................................................................................. 3 Key Definitions ................................................................................................ 3 Major Processes ............................................................................................... 5

Directory Types ................................................................................................... 8 General-Purpose or Standard Directories.................................................... 8 Special-Purpose (Application) and NOS Directories ................................. 9 Document Focus for Directory Operations.................................................. 9

Understanding the Directory Environment..................................................... 9 Knowing What One Has ................................................................................ 9 Directory Integration Challenges ................................................................ 10 Documenting the Directory Services Architecture ................................... 42 Monitoring Directory Components ............................................................ 48

Managing the Directory ................................................................................... 53 Hardware Management Overview............................................................. 54 Software Management Overview ............................................................... 54

Maintaining the Directory................................................................................ 55 Creating a Directory Backup and Restore Plan......................................... 55 Combining Traditional Backup and Replication Techniques for Data Protection........................................................................................................ 58 Directory Backup and Restore Plan Considerations ................................ 58

Troubleshooting Directory Architecture........................................................ 59 Discovering Problems................................................................................... 60 Types of Problems......................................................................................... 61 Troubleshooting Flow Chart........................................................................ 66

Roles and Responsibilities.................................................................................... 69 Directory Administrator................................................................................... 69 Directory Designer ............................................................................................ 70

Relationship to Other Processes .......................................................................... 71 System Administration..................................................................................... 71 Security Administration ................................................................................... 72 Service Monitoring and Control...................................................................... 72 Network Administration.................................................................................. 72 Print and Output Management ....................................................................... 72 Configuration Management............................................................................. 72 Availability Management................................................................................. 73 Capacity Management...................................................................................... 73 Failover and Recovery ...................................................................................... 73 Service Continuity Management..................................................................... 73

Contributors........................................................................................................... 74

Document Purpose This guide provides detailed information about the directory services administration service management function (SMF) for organizations that have deployed, or are considering deploying, Microsoft technologies in a data center or other type of enterprise computing environment. This is one of the more than 20 SMFs defined and described in Microsoft® Operations Framework (MOF). The guide assumes that the reader is familiar with the intent, background, and fundamental concepts of MOF as well as the Microsoft technologies discussed.

An overview of MOF and its companion, Microsoft Solutions Framework (MSF), is available in the Introduction to Service Management Functions guide. This overview guide also provides abstracts of each of the service management functions defined within MOF. Detailed information about the concepts and principles of each of the frameworks is also available in technical papers available at www.microsoft.com/solutions/msm/.

Executive Summary A directory is an information or data source used to store information about interesting objects. A telephone directory stores information about telephone subscribers. In a file system, the directory stores information about files.

Directory services allow users and applications to find network resources such as users, servers, applications, tools, services, and other information over the network. The goal of directory services is to ensure that through a simple and organized process, information is accessible through the network by any authorized requester.

Online directories are typically designed to be dynamic, flexible, secure, and personalized. They are dynamic because they change frequently as users and network resources move, flexible because they can be programmed to include new types of information, secure because individual objects within the directory can be restricted to specific users, groups, or types of access, and personalized because directory information can be tailored to provide customized responses to specific users or groups.

2 Service Management Function Guide

Process and Activities Directory Services Administration Overview A directory service is one of the most important components of an extended computer system. Although users and administrators frequently do not know the exact name of the objects they are interested in, they may know one or more attributes of the objects and can query the directory to get a list of objects that match the attributes.

A directory service can:

● Enforce security as defined by administrators to keep information safe from intruders.

● Distribute a directory across many computers in a network, providing increased performance.

● Replicate a directory to make it available to more users and resistant to failure.

● Partition a directory into multiple data sources (stores) to allow the storage of a very large numbers of objects.

A directory service is both a management tool and an end-user tool. As the number of objects in a network grows, a directory service becomes essential. The directory service is the hub around which a large distributed directory turns.

Traditionally, directory services are used for naming and locating network resources. These functions have been expanded and directory services are now becoming an important component in Internet/intranet infrastructure (reference directories, white and yellow pages, e-mail directories, and so on).

Directory services also enable e-mail delivery and integration between disparate e-mail systems. Directory services are becoming increasingly important for application integration�acting, for example, as the central repository of all application, access, and security information.

New directory-enabled applications are emerging that treat the directory as an essential piece of the network infrastructure. The directory is seen as a special-purpose, customizable database to which users and applications securely connect to be able to find, read, add, delete, and modify information. This information is then automatically distributed to other directory servers on the network.

These directory-enabled applications depend on mature directory services to perform the other three key roles:

Directory Services Administration 3

authentication and authorization, naming and locating, and administering and managing network resources.

Goals and Objectives

The goal of directory services administration is to ensure that

information is accessible through the network by any authorized requester via a simple and organized process.

Scope

Directory services allow users and applications to find network resources such as users, servers, applications, tools, services, and other information over the network. Directory services administration deals with the day-to-day operations, maintenance, and support of the enterprise directory. Directory services administration covers:

● Directory-enabled applications.

● Metadirectories.

● User, group, and resource creation and management.

● Daily support activities such as monitoring, maintaining, and troubleshooting the enterprise directory.

Key Definitions Alert. An indication of a significant event. Alerts are defined by processing rules.

Attribute. Computer characteristic, typically defined by a registry key or value.

Authentication. The method by which users prove to the system that they are who they claim to be. Authentication is used in passwords, smart cards, biometrics, and so forth.

Authorization. A process that verifies that the user has the correct rights or permissions to access a resource in a domain.

Backup. The term is most commonly used to refer to a copy of all the files on a computer�s disks that is made periodically and kept on magnetic tape or other removable medium (also called a �dump�).

Client. A computer system or process that requests a service of another computer system or process (a �server�) using some kind of protocol and accepts the server�s responses. A client is part of client-server software architecture. For example, a workstation requesting the contents of a file from a file server is a client of the file server.


Directory. A collection of computer files. Most common in systems that have a graphical user interface and provide a graphical file browser in which directories are traditionally depicted as folders (like small briefcases).

Event. Any significant occurrence in the system or an application that requires users to be notified or an entry to be added to a log.

Firewalls. A dedicated gateway machine with special security precautions on it. The idea is to protect a cluster of more loosely administered machines hidden behind it from crackers. The typical firewall is an inexpensive microprocessor-based Unix machine with no critical data, with modems and public network ports on it, but just one carefully watched connection back to the rest of the cluster. The special precautions may include threat monitoring, callback, and even a complete iron box keyable to particular incoming IDs or activity patterns.

Lightweight Directory Access Protocol (LDAP). LDAP allows an application to access any directory the same way regardless of the directory vendor or how it is implemented. Most general-purpose directories can be accessed using LDAP. Applications using LDAP have a simplified access to multiple pieces of information from disparate directories.

Metadirectory. Metadirectory products are essentially directories of directories. They provide a common infrastructure that sits on top of various directories, directing queries and returning responses through a single, transparent user interface. Metadirectories provide integration and unification of disparate directories.

Network operating system (NOS). An operating system that uses software to communicate with other computers via a network. This allows resources such as files, application programs, and printers to be shared between computers.

Server. A computer that provides some service for other computers connected to it via a network. The most common example is a file server, which has a local disk and services requests from remote clients to read and write files on that disk.

Simple Network Management Protocol (SNMP). SNMP allows a management application to monitor the status of an entity on a network. It is also possible for a management application to be asynchronously notified via the SNMP


trap mechanism when an event or error occurs (that is, if a server process terminates unexpectedly).

Major Processes

The directory services administration process is divided into five main processes and a number of sub processes:

● Directory types

● General-purpose or standard directories

● Special-purpose (application) and NOS directories

● Document focus for directory operations

● Understanding the directory environment

● Knowing what one has

● Directory integration challenges

● How are directory services used?

● Authentication and authorization

● Authentication

● Authorization

● Naming and locating network resources

● Standard naming

● Location independence

● Communities of interest

● Disparate directories and the metadirectory

● Metadirectory synchronization

● Controlling objects

● Master directory role

● Subordinate directory role

● Peer-to-peer role

● Attribute control

● Object and attribute filtering

● Directory information broker

● Metadirectory information flow

● The directory join

● Directory name space integration

● The problem of identity management

● The identity management challenge

● Common identity management scenarios


● Solution requirements

● Connectivity requirements

● Information management flow

● Change event processing

● Data aggregation capabilities

● Related object tracking

● Integrity management

● Ownership

● Failure management

● Referential integrity

● The metadirectory as a corporate solution

● Sources

● Content

● Management

● Documenting the directory services architecture

● Six sigma values

● Operations and documentation

● What and how to document

● Hardware and software vendors� manuals

● Operations manuals

● Service desk

● Directory operations

● Directory architecture

● Bottom-up documentation (physical design)

● Top-down documentation (logical design)

● Monitoring directory components

● Why monitor

● Introduction to monitoring

● Types of monitoring and monitoring systems

● Methods of monitoring

● General monitoring principles

● Monitoring unobtrusively

● Cascading failures

● Maintaining a problem history

● Maintain a written plan


● Notification techniques

● Taking action

● Managing the directory

● Hardware management overview

● Software management overview

● Maintaining your directory

● Creating a directory backup and restore plan

● Fundamentals of backing up and restoring a directory

● Backup and restore using traditional media

● Backup and restore using replication techniques

● Combining traditional backup and replication techniques for data protection

● Directory backup and restore plan considerations

● Troubleshooting directory architecture

● Discovering problems

● Types of problems

● Directory outages

● Causes of directory outages

● Implications of directory outages

● Resolving directory outages

● Performance problems

● Causes of performance problems

● Implications of performance problems

● Resolution of performance problems

● Problems with directory data

● Causes of directory data problems

● Implications of directory data problems

● Resolving directory data problems

● Troubleshooting flow chart

● Troubleshooting checklist


Figure 1 Directory services process flow diagram

Directory Types This next section is a high-level discussion of current directory technologies and types of directories one either already has or will most likely deploy in the near future.

General-Purpose or Standard Directories

General-purpose, or standard, directories are not tied to any one or specific application or service, are not uniquely associated with any specific network operation system (NOS), and are not deployed for any singular purpose. Rather, these directories are designed to meet the needs of numerous service requirements. An example is the Lightweight Directory Access Protocol (LDAP). LDAP is well suited to meet the needs of virtually any directory-enabled application.

Most general-purpose directories can be accessed via LDAP. LDAP allows an application to access any directory the same way regardless of the directory vendor or how it is implemented.

Directory types

Understandingyour directoryenvironment

directory

Maintaining yourdirectory

Troubleshootingyour directoryarchitecture

End

Start

Managing your


Applications using LDAP have a simplified access to multiple pieces of information from disparate directories.

Special-Purpose (Application) and NOS Directories

Special-purpose, or application, directories are directories that are uniquely tied to a specific application (or suite of applications). They are distinguished from general-purpose directories by their tight integration to a specific application and their use of proprietary interfaces and protocols. Typically, it is difficult or impossible to use these directories with any directory-enabled applications they were not designed to support.

Also falling within this category are NOS-specific directories: directories that are specifically tied to a particular operating system. While most NOS-based directories started out as proprietary products, today most are embracing Internet standards (that is, LDAP), thereby positioning themselves for broader support of directory-enabled applications.

Document Focus for Directory Operations

The material provided in this document is focused on post-deployment operations, support, management, and maintenance of the organizational directory. This is done with the recognition that most customers already have one or more general or special-purpose directories deployed to address business requirements. For example, a company may have an online (electronic) directory associated with their human resources management system, phone system, electronic mail system, or enterprise resource planning system.

From the operations standpoint, it is important to begin moving to a single point of management and operations for all directory solutions.

Understanding the Directory Environment The best way to understand the deployed directory solution is to make this aspect of the deployment as critical as any other�the solution deployment is not finished until each functional and tactical aspect of the directory is completely understood, documented, staffed, monitored, managed, supported, and funded.

Knowing What One Has

Before one can effect any positive or meaningful control over a directory, one must first know what one has, how it works, what pieces cooperate or interoperate with other components, systems, or applications, and who has responsibility for which piece. It is simply astounding how many organizations employ one or more


directory services without a complete understanding of these elements. Most directory deployments experience budget, time, and resource constraints from the start, and it is this crucial documentation and control element that suffers.

Many organizations have good intentions of going back after-the-fact to document their deployment and implement appropriate control mechanisms (monitoring, delegated administrative responsibilities, a helpdesk offering, and so on.). However, this is difficult due to rapid growth and the dynamic nature of the business environment.

The previous two paragraphs state that this level of proactive knowledge capture and operational readiness does not always happen for a variety of reasons. Regardless, it must be done, and it must be done before the deployed solution gets so far out of control that it no longer meets the needs for which it was originally implemented. The crisis-point exhibits the following symptoms:

● IT is in constant crisis mode, bouncing from one disaster to the next.

● Deployed solutions simply do not stand up to the reliability and availability goals established when the solution was defined.

● Capacity and/or bandwidth concerns are always issues.

Most companies fall somewhere between pure operating nirvana and a total crisis management state. Regardless of one�s position, the remainder of this document should be of value in helping assess one�s operational readiness and assist with making the changes necessary to achieve the solution goals: availability, reliability, manageability, and supportability, that is, �ARMS.�

Directory Integration Challenges

This section describes how directories are used and introduces the concept of directory integration.

With the introduction of numerous, disparate general and special-purpose directories, the task of managing these directories has become a problem. Managing disparate directories is expensive, redundant, and nonstandard in approach and technique.

Directory technologies have matured to the point that directory technologies can support directory-enabled office automation including electronic commerce, and general enterprise computing.


How Are Directory Services Used?

Traditionally directory services were used for naming and locating network resources. New directory services applications include corporate electronic phone books, Internet white/yellow pages, e-mail delivery and integration between disparate e-mail systems, and the central repository of user information.

Directory services products utilize security services to track access rights to network resources and information. The directory services provide an efficient way to manage resource security, since the directory offers a logical representation of all resources in the enterprise. In addition, the directory services can act as a single point of entry into the network. Users can receive access to allowed resources by authenticating themselves a single time to the directory services.

The use of directories can be categorized into four primary areas:

● Authentication and authorization

● Naming and locating network resources

● Administering and managing network resources

● Enabling applications

Authentication and Authorization

The application-specific tools that allow network operating systems and e-mail programs to keep track of users, their passwords, and a variety of application-related preferences and configuration information were the forerunners of general-purpose directories.

Directory and security services are becoming distinct components within the network services model. Still, these two services are inextricably linked, providing authentication and authorization functions. Security and directory services operate in tandem. Initially, the directory must provide authentication and access controls that govern who can access and modify the directory. In addition, the directory provides a foundation for emerging general-purpose security mechanisms.

Authentication

Authentication allows users and applications to identify themselves by invoking security services that can vouch for or validate their identities. Historically, network operating systems and applications have used system-specific, password-based authentication methods. However, the advent of corporate intranets and the growth of the Internet require a general-purpose security infrastructure.

Directories must provide authentication mechanisms that govern access to the directory database. Directories are capable of


authenticating clients through a variety of methods, including anonymous connections, clear-text passwords, or sophisticated password hashing and session encryption routines. While these may be important safeguards for the directory�s contents, they represent more of a traditional system-specific, rather than a general-purpose, authentication mechanism.

With the explosion of e-commerce and communication on the Internet further increasing the focus on general-purpose authentication mechanisms, Public Key Infrastructure (PKI) technology is emerging as the de-facto standard for authenticating users and applications. PKI is well suited to this form of distributed computing environment. PKI is an important tool for authentication in a variety of security applications, such as Secure Sockets Layer (SSL), Secure/Multimedia Internet Mail Extensions (S/MIME), Secure Electronic Transactions (SET), and code-signing services for both Java and Microsoft ActiveX® controls. The directory plays an important role in supporting the security service, since PKI products will use the directory to store, distribute, find, and retrieve digital certificates and public (and in some cases private) keys.

In addition to storing and managing components for PKI services, the directory assists other authentication mechanisms by playing a supporting role in the delivery of the service. In the case of secret key systems like the Kerberos version 5 protocol, the directory provides the storage location for unique ID (UIDs), and is in itself authenticated by the Kerberos service. Moreover, as general-purpose directories become more widely available, security administrators will use the directory�s inheritance properties to enforce corporate security policies stored in the directory.

As these interoperable authentication mechanisms improve, a single logon that will authenticate a user to all the operating systems, services, and applications on the network becomes more realistic. Even though the fully interoperable authentication is still somewhat of an emerging service, directory services can be used to implement a single sign-on �look and feel� by using metadirectory services to implement logging on by proxy to heterogeneous environments. More detail about metadirectories, their capabilities, and their importance is provided later in this document.

Authorization

After security services have authenticated clients and applications to the network, the access to resources needs to be authorized. As is the case with authentication, operating systems, messaging systems (for example, e-mail), and other servers


perform authorization (also known as access control) functions in a system-specific fashion. When they authenticate the user, such systems can also check their internal systems to determine the level of access a given user has to a given resource, such as a file system directory. However, as general-purpose authentication mechanisms emerge, the directory will play a less-important role in access control.

There are two methods by which the directory can support access control:

● Provide the repository applications needed to store, distribute, find, and retrieve access control lists (ACL).

● Use the directory to define objects and attributes of objects that authorize applications and users to access a particular network resource.

For example, a security administrator may declare that �all members of the accounting group may use the payroll application� or that �only employees with managerial salary grades of �X� can approve travel reimbursement forms.� Although both of these methods represent acceptable forms of authorization control, the latter offers an easier, more consistent approach to authorization and policy enforcement.

As directory standards bodies continue to work on standard access control list (ACL) mechanisms, developers will have two choices. They can write to platform-specific access control mechanisms and create platform-specific dependencies in their products. Or, they can write their own directory-enabled, but application-specific, access control mechanisms.

If platform independence is of primary concern, the latter approach provides a compromise between ease of use (leveraging the directory to provide a manageable, scalable infrastructure) and application flexibility (allowing the developer to tailor the specific authorization requirements to match the application). On the other hand, writing to platform can save time and effort, even though creating a platform dependency makes supporting multiple platforms more difficult.

Naming and Locating Network Resources

The directory�s core competency and traditional role is to find things. Naming and locating network resources is a significant function that directories play on the network.


The three key aspects of naming and locating resources function are:

● Standard naming

● Location independence

● Communities of interest

Standard Naming

Directories impose a standard naming convention on an organization. That naming convention provides the context within which network applications, services, and people meet and find one another.

The advantage of standard naming is that it separates the physical from the logical. Rather than understanding the detailed characteristics of the network (for example, buildings, routers, hubs, subnets, and IP addresses�all subject to change without notice), naming conventions describe network resources in user (and application) friendly terms. Consequently, users and applications can navigate the network and its resources more holistically than geographically. People and directory-enabled applications can search for and locate resources without needing to know the layout of the network. They can search for them by name. Alternatively, they can search for them by attribute. This ability frees resources from a specific topography and gives resources location independence.

Location Independence

Location independence significantly impacts many aspects of the network. The directory enables location independence in two ways:

● The directory stores and replicates, on behalf of application preferences, personal address books, bookmarks, profiles, security keys, and other user information.

● The directory works with policy servers and other systems management tools that replicate desktop settings.

While the directory does not contain all of this information, it will know where the information is stored and will assist the services that store information to apply it appropriately. This capability improves conditions for both the end users and the system administrators. Users and applications will have a single point of reference. IT administrators, on the other hand, will be able to centrally manage and control corporate desktops, software licensing, and distribution. IT administrators can also move, load-balance, or replace services without reconfiguring the underlying applications or visiting every desktop. This ability to


handle services without reconfiguration simplifies the job of the administrator and makes the network more manageable and scalable.

For the corporate desktop, for example, location independence means that users can connect to the network from any device, while maintaining their own personal preferences and settings.

The directory also allows other entities, such as applications or network services, to locate the resources they need. In a distributed application, a given application may need to find and use a software component, such as a COM or CORBA object. By including an object�s definition, attributes, and methods in the directory, developers can produce distributed applications that can be managed and modified centrally via the directory, rather than by changing and redistributing the underlying application.

Likewise, applications can find the components they need by searching for them in the directory. The application does not need to know the component�s physical location, nor does the application malfunction when the component�s physical location changes.

Communities of Interest

In addition to providing a standard naming convention and enabling location independence, directories also store additional information about people and organizations. This additional information allows the directory infrastructure to enable a sense of community within a new corporate paradigm that involves customers, suppliers, partners, colleagues, and teams. The directory enables participation across time zones and geographic barriers, including participation from within an organization that must span both intranets and extranets.

In some cases, a person�s inclusion in a community is automatic�for example, all secretaries in a company or all people who work in a particular building. In other instances, users select communities they wish to join, such as buddy lists or hobby and interest groups.

Directories have played a role with electronic communities for a long time. The first groupware application community was based on e-mail, the most simple of asynchronous communications. More recently, synchronous connections, or so-called instant messaging, are extending messaging systems even further. As more advanced forms of real-time collaboration emerge, such as videoconferencing, group authoring tools, and Internet telephony, the directory will continue to play a role as the meeting point for these network services, allowing people and applications to find each other based on names and attributes.


Disparate Directories and the Metadirectory

Metadirectory products are essentially directories of directories. They provide a common infrastructure that sits on top of various directories, directing queries and returning responses through a single, transparent user interface. Metadirectories play the role of integration and unification of disparate directories.

Customers will have to support multiple directories, at least in the foreseeable future, because many directories serve specific functions. Metadirectory services address fundamental implementation issues that every enterprise directory product must address.

Metadirectories can offer a number of advantages over stand-alone directory services for very large, highly distributed organizations:

● Metadirectory services provide a universal way of naming, finding, accessing, and protecting resources not only over space and time, but also across system boundaries as well.

● In many cases it is too costly, complex, and impractical to merge all current directories into one enterprise directory. Metadirectory services integrate existing disparate and proliferating directories by addressing the technical and organizational problems created by directory implementation.

However, the advantages of metadirectories diminish considerably as the number of directories and/or complexity of the directory infrastructure decreases. It is necessary to evaluate the IT organization to determine whether metadirectories should be implemented.

In order to better understand metadirectory technology, this paper covers metadirectory concepts including:

● Synchronization

● Information brokering

● Information flow

● The directory join

● Multiple name space support

Metadirectory Synchronization

Synchronization allows the metadirectory to aggregate content in the metadirectory database.

Under the synchronization method, the metadirectory must interoperate with other connected directories via well-established relationships. The management control over the relationships between directories is a significant issue when it comes to the


day-to-day management of the directory infrastructure. The task of aggregating directory content via synchronization and replication clearly illustrates that challenge. The key question is who creates and deletes the objects in the join, and how.

These are basic control issues. Metadirectory services must support a great deal of flexibility when it comes to how an organization implements and delegates control. Network planners must create specific relationships between the metadirectory and the connected directories with which it interoperates.

Controlling Objects

The enterprise directory contains a variety of objects. These objects represent a variety of resources, including people, physical locations, applications (such as database and messaging servers), and systems (such as servers and workstations). The question is: How does the administrator create objects and attributes in the enterprise directory that actually represent objects and attributes that exist throughout the network?

In cases where connected directories are managed centrally from the enterprise directory, directory services managers can create objects in the enterprise directory. The enterprise directory then propagates those objects to the connected directory.

However, other departments or divisions may manage other connected directories locally. In such cases, the connected directory must be able to create objects in the enterprise directory.

In still other cases, corresponding objects, such as user IDs, will already exist in both the enterprise directory and in a connected directory. Thus, the enterprise directory must also be capable of establishing firm relationships between existing objects in connected directories and objects in the enterprise directory. The metadirectory must enable object creation in all of these circumstances. To clearly understand these different dynamics, it is useful to think of the metadirectory in one of three roles: master directory, subordinate directory, or peer directory.

Master Directory Role

In the master directory role, the metadirectory creates objects in the connected directory and manages the connected directory. The master role allows companies to use the enterprise metadirectory to manage and control any connected directory centrally. The figure below illustrates the master directory role.


Figure 2. The master directory role

In such cases, the metadirectory services allow the enterprise directory to completely manage the content of an integrated directory. Metadirectory services automatically propagate any changes, such as adding and deleting users, that administrators make in the enterprise directory to the affected connected directory. The enterprise directory becomes the management tool used to administer the connected directory, replacing directory management tools native to that network or application environment.

The master role raises important synchronization issues�for example, what if users of the connected directory make changes in the connected directory, using the management tools native to that network or application environment? In such cases, the metadirectory must again be flexible, allowing the administrator to determine the best course of action.

Subordinate Directory Role

While many IT organizations would like to control all systems centrally, that goal is often unattainable.

In many organizations, autonomous departments and divisions control their own systems. It is usually difficult or impossible for centralized information technology departments to force such divisions to participate in any technology initiative that eliminates their autonomy. There are also systems, such as the human resources database, from which directory services managers need to get information, but for which they have not been given complete access.

In such cases, however, it is usually still important for at least some directory information to flow from locally managed directories to the metadirectory and on to other connected

Metadirectory ServiceApplication

or NOS Directory

The metadirectory is used to create, delete, and modify objects in the connected directory. As master, the metadirectory controls object creation/deletion.

ServiceApplication

or NOS Directory

Master RoleMetadirectory


directories. Many companies, for example, want to use the HR database as the master source for all user objects. The user objects may be created using the management tools native to that network or application environment. Therefore, the metadirectory must be capable of accepting objects created in the connected directories. The metadirectory simply imports objects from the connected directory, including them in the enterprise directory and propagating them to other connected directories as appropriate.

The metadirectory synchronizes any changes made locally in the connected directory with its own data store to ensure data integrity.

In such cases, the metadirectory assumes a subordinate server role because it is only reflecting the objects created in the connected directory. The figure below illustrates this.

Figure 3 The subordinate server role

Peer-to-Peer Role

In both roles, either the metadirectory or the connected directory actually creates objects in the metadirectory database. In the ongoing maintenance of the directory both of these roles are important. Most enterprises have already created a number of directory objects in many systems, many of them representing the same resource or person.

Take user ID, for example. If a company has e-mail, building security badges, and a human resources (HR) database, it is highly likely that any given employee exists in several of those environments, if not all of them. It is also likely that the naming conventions these systems use are not identical. Each individual directory will also contain user attributes; some of which will be similar (such as address and telephone number), and some that will be different (such as application-specific attributes).

The HR directory creates, deletes, and modifies objects

creation/deletion while the metadirectory controls internaland external access.


or NOS Directory

Metadirectory HR DatabaseMaster Role

in the metadirectory. Human Resources controls object

Service


It is unreasonable to expect the administrators of all these connected directories to change existing naming conventions or accept a bunch of new attributes that they will have to manage. Such a change might not be technically possible or practical. Some application-specific directories are incapable of supporting the rich naming conventions or extensive attributes companies are likely to use in the metadirectory, for example. The best practice is to preserve local naming conventions and directory structures.

The metadirectory must be able to establish relationships between objects in the metadirectory and existing objects in different connected directories. This relationship is often referred to as a peer relationship, or an association, because it equates, or associates, existing objects with each other. The figure below shows the peer-to-peer relationship.


Figure 4 The peer-to-peer relationship

For example, the metadirectory can equate an object in a connected directory that uses a different naming convention with an object in the metadirectory, establishing a firm and clear relationship between them.

For example, as shown in the following figure, the metadirectory can understand that Jeff Smith, as the metadirectory defines him, is the same person as �jsmith� in the STMP address and �Jeff Smith� in the HR database.

Figure 5 The peer-to-peer relationship functionality


or NOS Directory

Metadirectory E-mailDirectory

PeerRelationship

The metadirectory creates and maintains a relationship

in connected directories.between objects in the metadirectory and existing objects

Service

Jeff Smith Jeff jsmith

HRDatabase

Jeff Smith

DominoDirectory

Netware NDS

STMPAddress

Jeff_Smith

Metadirectory


Attribute Control

Objects in the metadirectory name space can have one of three roles in relation to the connected directory: master, subordinate server, or peer. The metadirectory should not force the attributes of those objects to inherit those same relationships. In some cases, local administrators or users need to control object attributes locally from within the connected directory, even when the metadirectory has a master role for the objects in that directory.

At the same time, administrators need flexible control over attributes in the metadirectory itself. For example, in many cases the address and telephone number attributes of a user object should be user-definable. It does not make sense for a central administrator to have to change a user�s home address and telephone number.

Even if the directory service manager creates the user object centrally in the metadirectory name space and then propagates the user object to the connected directory (which makes sense from a security point of view), the user might be granted permissions to control some of his or her attributes. This could be done either from the metadirectory or locally through a connected directory. The following figure shows this level of attribute control.

Figure 6 Attribute control

The HR database is a good example of how flexible attribute control can benefit enterprise metadirectory implementations. Many companies want to make the HR database the authoritative source for user creation. When new employees are hired and added to the HR database, the HR database can act as the master,

Metadirectory

User ControlsAddress and

Phone Number

USER- Address and Phone

HR ControlsName, Title,and Salary

- Name, Title, and Salary Service


actually creating objects for those users in the metadirectory. But the metadirectory can give users control over their personal attributes, including home address, telephone number, and emergency contacts. When the user changes these attributes in the metadirectory, those changes can flow back to the HR database, even when the HR database is the master for user object creation.

Object and Attribute Filtering

Regardless of the relationship between any given connected directory and the metadirectory, an important aspect to consider is what information and how much will be joined in the metadirectory. There also must be a way of controlling what (and how much) information will be subsequently propagated to other integrated directories.

Since many directories have specific tasks, it is pointless to propagate all the information in each directory to every other directory. Objects specific to one directory are probably meaningless in another. Some connected directory objects may even be meaningless in the metadirectory, causing unnecessary clutter. There are cases in which data, such as salary information or network routing tables, should not be propagated to other connected directories.

The metadirectory must be capable of controlling levels of import and export on a case-by-case basis. It must be flexible enough to contain either all of a given connected directory�s content or a specified subset of its content. The metadirectory must also be capable of allowing the administrator to selectively propagate the content of the metadirectory to any given connected directory. Specifically, metadirectory services must support filtering in both import and export operations at both the object and object-attribute levels.

The metadirectory can import some objects, but exclude others, through object filters defined by the administrator. The following figure shows object filtering during import. For example, while the system administrator may want to import all of the user objects out of NetWare NDS into the metadirectory, he or she may not want to import the routing information NetWare stores in the directory. The metadirectory must support these object filters during export operations as well.


Figure 7 Object filtering during import

Similarly, the metadirectory can import some attributes, but exclude others, through attribute filters the administrator defines. For example, the administrator may want to import a user�s name, address, telephone number, and title from the HR database, but he or she may want to exclude the user�s salary and benefits information. The metadirectory should support these attribute filters during export operations as well. The following figure shows attribute filtering during import.

Import TheseObject Types

NetWareUsers

Filter OutThese

Object Types

RoutingTables

The metadirectory can include and exclude objects.

NetWareNDSService

Metadirectory


Figure 8 Attribute filtering during import

Directory Information Broker

Information brokering allows the metadirectory to access data in other directories without actually containing the data. The metadirectory acts as a pointer to the required data.

The synchronization method provides a powerful set of capabilities for aggregating directory content within the join. Because the metadirectory replicates and synchronizes data across multiple locations, searches to the core directory service�not to the metadirectory itself�are usually localized, resulting in higher performance. Replicating data across several locations also ensures that there is no single point of failure, thereby increasing overall system reliability.

In spite of these advantages, synchronization and replication are not always the best means of directory integration. Creating multiple copies of directory data and replicating it over the network can be inefficient for large amounts of data, especially if users access that data infrequently.

The common approaches to solve these problems are:

● Creating client-side referrals.

● Building metadirectory functionality into clients and applications.

● Information brokering.

Import UserName, Address,Phone, and Title

Filter OutUser Salary

AttributeThe metadirectory can include and excludeattributes of specific objects.

ServiceHR

Database

USERName, Address, Phone Title, and Salary

Metadirectory


For example, LDAP version 3 includes client-side referrals. Under this model, a directory server can refer a client to another server if it does not have the information for which the client is searching. The client can then automatically continue its search by issuing subsequent queries to the referred server(s).

While these client-oriented methods are useful, they do not fully meet the need for an enterprise directory infrastructure. LDAP referrals are fine for referring clients to other directories, particularly directories that are outside the corporation, but they do not eliminate the need for an infrastructure that can rationalize (replicate) directory content. Also, placing the burden of data aggregation fully on the client and application developer still leaves an organization without an infrastructure capable of managing a large number of directories in an integrated fashion.

Therefore, using the metadirectory server as an information broker becomes more attractive. Broker services consist of both relatively static and an increasingly more dynamic set of operations.

The static broker functions are essentially equivalent to the chaining concept the X.500 standard defines. Chaining enables real-time connectivity to connected directories by allowing a directory server to access data in another directory on behalf of a client or server. If a directory server understands what information other directory servers contain, it can access that data on behalf of its clients. The following figure illustrates this concept.

Figure 9 Static directory information broker

A directory client requests information from the metadirectory server that is actually contained by an application or NOS-specific directory server. Because it has knowledge of the application or NOS directory�s content, the metadirectory can

Metadirectory Application

or NOSDirectory

1

3

2

4

Steps 1 and 2 are requestsSteps 3 and 4 are replies

Client


access the information on behalf of the client and then return the information to the client. The chained, or brokered, request is transparent to the client.

Chaining can occur within a single directory or between two different directories. It is based either on standard protocols or integration interfaces based on vendor specific protocols. In this way, the metadirectory server can transparently give clients access to information in other directories, reducing the need for replication and synchronization.

However, while static brokering, or chaining, requests eliminate the need for some replication and synchronization, it introduces problems of its own. For example, the connections between directories must be up and available, and performance across WANs and LANs may be an issue.

If a WAN or LAN link is down, then directory data accessible via the broker are not available. Caching of data could solve this problem, but the difference between synchronizing replicas and synchronizing caches can become an issue unto itself.

Searches across WAN or even larger LANs can be problematic. Making a logical set of directory information that includes brokered content easily searchable across a large enterprise can be difficult. For these reasons the brokered model cannot guarantee performance reliability and access across the WAN or larger LAN.

Information brokering also includes the ability to support more dynamic and real-time functions. When combined with a general-purpose event and object model, a directory services can broker a variety of dynamic functions. Applications can register for specific types of directory events, such as logging on to the network or changing particular attributes of a given object. These events can trigger specific operations, such as database lookups or the reconfiguration of the parameters associated with a given router or switch.

Metadirectory Information Flow

The metadirectory can either replicate or synchronize data with connected directories, or it can act as a broker, transparently accessing data in other directories on behalf of clients and other services.

Under the synchronization method, directory service managers can import the contents of a connected directory into the metadirectory. When data is imported, the metadirectory synchronizes itself with the connected directory. When an administrator makes changes in the metadirectory, the metadirectory propagates those changes to the connected


directory as appropriate. Likewise, when local managers make changes in the connected directory, the metadirectory can reflect those changes. The metadirectory can also propagate information in a connected directory to other connected directories when and where it is appropriate.

Under the broker method, entries (often called aliases) in the metadirectory database provide pointers to data in other connected directories. When clients search for and access that data, the metadirectory server acts as a broker, retrieving that data on behalf of clients and other services transparently.

The metadirectory performs these management and access operations with multiple connected directories simultaneously, creating a directory that is greater than the sum of its parts�as shown in the following figure.

Figure 10 Metadirectory information flow

End users can search the metadirectory and find the resources they need regardless of which directory those resources are in. Users can also place and modify information in the metadirectory when and where appropriate.

The Directory Join

The metadirectory is the join of all directories in an organization. The �join� functionality enables the creation of a total picture of all the resources in an organization. By creating the join, the metadirectory can create an authoritative �big picture� of the organization, its people, and its other resources.

B

DirectoryA

Metadirectory

DirectoryC

OtherDirectory

Directory


The following figure shows this concept by using a person/user object as an example.

Figure 11 The directory join

The objects in each connected directory define only some of the user�s aspects/attributes specific to that system. The e-mail directory, for example, defines Fred only as he relates to the e-mail system. It does not take into account the HR or network directories that define other aspects of Fred�s relationship to the organization. On the other hand, Fred�s object in the metadirectory represents Fred fully, aggregating all his attributes from each connected directory, assembling an object that represents Fred and his relationship to the enterprise. The metadirectory creates the join through two methods of directory integration: synchronization and brokering.

Local data sets support applications and enable local control of data. This distribution of data is appropriate not only from a geographic and business perspective, but also from a performance and application standpoint.

While the join consists of data from many sources, it is as much a virtual join as it is a physical join of all directory information. The metadirectory database contains data from other directories and may actually replace some directories. It also synchronizes with data stored in other directories. There are also cases in which the metadirectory contains pointers to data in other directories instead of the data itself.

Fred'sSMTP

AddressNotes

Attributes

Fred's NetWare Attributes

Fred'sHR

Attributes

Metadirectory Attributes

STMP Address Notes Attributes

NetWare Attributes HR Attributes

SMTP MailDirectory Object

NotesDirectory Object

NetWare Directory Object

HRDatabase Object

The Metadirectory Join

Fred's

Fred's


Directory Name Space Integration

The name space is the set of rules that defines how the objects in the directory are named. The differences in name spaces are usually the most visible variances in directory implementations. For example, directories can differ in both the number of allowable levels in the hierarchy and the length (in characters) of each portion of the name.

In order to effectively support varied directory services requirements, the metadirectory must support multiple directory name spaces within its data store. Specifically, the metadirectory database should support the metadirectory name space and the name space native to each connected directory.

The metadirectory name space is the point at which all of the directories in an organization intersect, forming the enterprise, or global, directory.

In addition to the metadirectory name space, there is a connected directory name space for each connected directory. It is important to understand the distinction between the connected directory itself and the connected directory name space in the metadirectory database. The connected directory name space in the metadirectory database contains some or all of the content of a connected directory, whereas the connected directory is the discreet directory from which one extracts information.

Each connected directory name space contains only the objects and attributes from a specific type of connected directory. In other words, each connected directory name space supports the native name space of the environment from which the content originates. The following figure shows this concept.


Figure 12 Multiple name space support

Think of these various name spaces as a different �view� of the data in the metadirectory database. The metadirectory name space provides an inclusive view of the enterprise directory designed by the administrator. The various connected directory name spaces give an exclusive view of specific types of objects and attributes in the database just as they would appear in the connected directory. The content of the connected directory name space appears to the administrator just as it does in the connected directory itself. The main reasons for the connected directory name space are:

● Day-to-day needs of the systems administrator

● Directory-enabled management

● Centralized directory management

Consider an administrator using the metadirectory to manage a connected directory. If there are problems with that directory, the administrator should not have to comb through the entire metadirectory name space just to manage the connected directory. The administrator should use a view of the metadirectory that allows him or her to go straight to the problem. The connected directory name space allows administrators to deal with a system-specific subset of the metadirectory.

Support for multiple name spaces is also necessary for a fully directory-enabled management model. Support for multiple

B

A

DirectoryC

OtherDirectory

A B COther

Metadirectory

Directory

Directory


name spaces gives administrators a place to put connected directory objects before they actually integrate those objects with the metadirectory name space. Administrators can then view a connected directory in its native format, as well as the metadirectory name space. For example, when the metadirectory is up and running, it is likely that NOS-based and application-specific directories will be gradually integrated with the metadirectory, one at a time. The administrator should be able to integrate the content of a target directory into the metadirectory name space in a way that does not damage the metadirectory.

Multiple name space support is also necessary to enable a centralized directory management model. Because it supports both the metadirectory name space and a name space for each connected directory, the metadirectory database can contain directory objects that do not reside in the metadirectory name space. While it does not propagate these objects to other connected directories, the metadirectory does give the administrator a place to manage those objects from the connected directory name space.

The Problem of Identity Management

The metadirectory also provides a solution to the problem of identity management. The information provided in this section continues to expand upon the previous discussion.

As shown in the figure below, identity is the summary of information about people, applications, and resources scattered in directories and databases throughout most IT enterprises. Examples of identity data associated with people include names, mailboxes, salaries, and job titles. Application identity information includes the network addresses where clients can find servers. It also includes lists of services that applications can provide. Network resources, such as printers, also have identity attributes�their location and the printing capabilities they support.


Figure 13 The identity management challenge

The Identity Management Challenge

The diversity of identity data and the number of places where such data reside raise a number of management challenges:

● Not all identity data is kept in directories or exposed through a directory service interface such as Lightweight Directory Access Protocol (LDAP). For example, many systems only expose identity information through specialized application programming interfaces (APIs).

● Identity information frequently is duplicated in multiple places, and versions tend to drift out of synchronization over time if left unchecked.

● The number of places where companies must manage identity data increases with each additional application and platform.

● Typically, there is no single place where administrators and applications can access or manage identity information.

● These challenges make it difficult for companies to implement comprehensive and integrated identity management solutions. Leaving an enterprise environment in this state increases cost and complexity.

Common Identity Management Scenarios

Most large companies are already starting to grapple with some form of identity management project. Common efforts include:

Global address book applications. Synchronizing mailbox information between the different e-mail directories within a company enables users to locate other users and send them e-mail across differing systems.

Hire/fire solutions. Propagating information about a newly hired employee to all systems that require identity data enables speedy establishment of services. In order to

Users�� Privileges� Profiles� Policy

Client Machines� Mgmt profile� Network info� Policy

Server Machines� Mgmt profile� Network info� Services � Printers � File shares � Policy

Firewall Services� Configuration� Security Policy� VPN policy

E-Mail Servers� Mailbox info� Address book Internet

Applications� Configuration� Single Sign-On� App-specific

directory info� Policy

Network Devices� Configuration� QoS policy� Security policyIdentity

Account info


prevent breaches of security, systems also must quickly perform many of the same processes in reverse when employees leave.

E-commerce applications. Synchronizing enterprise identity information, such as digital certificates for suppliers and extranet users, is enabled with directories that reside outside of firewalls.

Single sign-on initiatives. Managing user name, password, and access right information across many different platforms and applications.

Solution Requirements

In the past, many companies have tried to create a single directory to hold all enterprise identity information. Most of these efforts failed for several simple reasons:

● Many applications cannot be modified easily to use directories.

● There are good reasons, such as replication and security requirements, why some applications need to keep identity in their own formats.

● Political boundaries inhibit complete consolidation regardless of what is technically possible.

This suggests that identity data will continue to exist in many places. Companies need to find ways to make different directory services and application repositories work together. Assuming that there will be many identity repositories, an identity management solution must provide:

● Connectivity to many forms of identity data.

● Management of identity flow between repositories.

● Mechanisms for maintaining data integrity throughout the identity management infrastructure.

Connectivity Requirements

The more directory services, databases, and applications to which an identity management solution can connect, the more useful the solution. As illustrated in the following figure, unknown data in one repository may be obtained from another. An identity management solution can connect to a given repository if it is able to:

● Obtain information about what has changed in the repository.

● Add new objects to the repository.

● Delete objects from the repository.


● Change an existing object�s attributes to different values.

Figure 14 Connectivity requirements

A comprehensive solution should be able to connect to data in:

● Standards-based directory services via LDAP version 3.

● Popular existing e-mail applications and non-LDAP directory services.

● Enterprise resource planning (ERP) applications.

● Databases by means of access methods such as Microsoft SQL Server�.

● Applications through an application programming interface (API).

Information Management Flow

Information management flow is the process of managing the movement of identity information between repositories. In order to manage this movement of identity information between repositories, information management flow must be able to:

● Detect changes to identity data and propagate updates to other repositories.

● Aggregate data from different repositories into metadirectories that contain a holistic view of identity data from across the enterprise.

● Track related objects as they change their positions in directory trees and other repositories due to periodic reorganization.

Human Resources

Database

Directory

Other NOS

Database

Directory

?

ERP


Change Event Processing

Change events occur any time that administrators, users, or applications add, delete, or modify a piece of identity data in a repository. Unmanaged, identity data changes quickly become disorganized. Identity management solutions therefore must provide features to detect changes, perform necessary data format translations, and then update all repositories that should reflect the changes. For example, if an administrator adds a new employee to the human resources (HR) database, this change event needs to cause systems used by that person to reflect the addition. In the figure below, the change is propagated to other directories and applications.

Figure 15 Change event processing

Data Aggregation Capabilities

While identity information resides throughout most enterprises, directories that contain an aggregation of identity data from many other repositories can offer great value. This metadirectory concept was pioneered by The Burton Group, which used the term join to represent an aggregated view of an enterprise�s identity data.

With a metadirectory, applications can access a variety of information in one place by using a single access method and security model, instead of interacting with each of the source repositories.

Metadirectories also maximize performance because data can be stored in indexed form. At run time, there is no need to fetch data from sources that may reside across wide area network (WAN) connections. To offer the greatest value, data aggregation capabilities must be able to:

ManagementEngine

HumanResources

Database

Directory

OtherNOS

Database

Directory

Add User

ERP

Information


● Gather and incorporate information from many sources including directories, databases, and applications.

● Group related information together even though it may be stored in different ways in different places. For example, data about a user named Jeff Smith might be stored under such names as Jeff Smith, jsmith, and smithj in different systems, as seen in the following figure.

● Push changes back out to sources when users or applications make changes to the aggregated view. This means that metadirectories must be integrated with change event processing infrastructures.

Figure 16 Data aggregation in a metadirectory

Related Object Tracking

When administrators deploy identity management solutions, they must be able to tell the identity management flow engine that Jeff Smith, jsmith, and smithj are all the same person. Then, as seen in the following figure, the engine must be able to track relationships as identity data is periodically reorganized. Solutions must not lose track of users simply because they change position in a directory tree structure�for example, moving from the accounting department to the sales group.

Name: Jeff SmithEmail: jsmithPicture: Smithj.jpg

User

Metadirectory

Database

E-mail Directory

SQL Database

User

User

ERP

Applications


Figure 17 Tracking related objects

Integrity Management

Integrity management is the process of ensuring that identity data does not become corrupted or out of synchronization between repositories as changes occur. Integrity management functionality must be able to:

● Maintain identity data ownership relationships.

● Act appropriately when failures occur.

● Maintain referential integrity within identity data.

Ownership

An important aspect of enterprise identity management is recognizing ownership relationships that must be maintained between applications and data. For example, a person�s mailbox name is owned by the e-mail system that hosts the mailbox. Within most companies, the HR system owns the data identifying whether a person is an active employee. With no enterprise identity management infrastructure in place, these ownership relationships are preserved by default because no other applications have the ability to access and update e-mail and HR data. With synchronization connectors and information flow management deployed, however, the situation changes.

Consider a case in which mailbox information is being synchronized with the HR directory by a connector as illustrated in the figure shown below.

Directory 2

Accounting

User 1

User 3

User 5

Sales

User 2

User 4

User 6

Users User 1 User 2 User 3 User 4 User 5 User 6

?

Directory 1

User


Figure 18 Managing ownership relationships

If the connector is not configured correctly, a user could change the mailbox attribute in the HR system and the connector would overwrite the mailbox value in the e-mail directory, causing tremendous confusion. Solving the problem is not as simple as just preventing changes from flowing backwards to the e-mail directory. The HR system may own information, such as the name of a person�s manager, which also must flow back to the e-mail directory.

Other attributes, such as a person�s office number, may have no clearly defined ownership and these should be data that anyone can update.

As a solution requirement, administrators must be able to define and enforce ownership relationships at the attribute level. If a change is in accordance with the ownership rules, it is allowed to pass through, otherwise it is blocked or reversed. For example, if a person changed a mailbox attribute in the HR directory, the identity management solution would simply set the attribute back to the value contained in the e-mail directory.

Failure Management

The ability to propagate a change to multiple repositories is a key requirement for identity flow management technologies. Yet, any time an engine makes multiple updates, the opportunity exists for one or more of the updates to fail and for data in different repositories to become inconsistent, as shown below.

E-mail Name: MasterRoom #: PeerManager: Slave

Object

Applications

E-mail Name: SlaveRoom #: Peer Manager: Master

Object

E-Mail Directory Human ResourcesDirectory

Applications


Figure 19 Managing failures

For example, if a person�s title, salary, and spending limit are changed, but the metadirectory is unable to update the user�s title in applications, identity data will be left in a state of confusion. Typically, this means that an administrator must investigate the situation and make corrections.

In database systems, this challenge is usually addressed with transactions that ensure all updates occur successfully or are rolled back as a unit. Unfortunately, most directory services and application programming interfaces do not support transactions. This means that identity management solutions must find other ways�such as using log-based, desired-state mechanisms that continue to request changes until confirmed�to ensure that all repositories eventually reflect changes.

Referential Integrity

Another challenge that identity management solutions share with databases is maintaining referential integrity between repositories. Referential integrity refers to the need to maintain relationships between the values of related pieces of data in different locations. For example, identity management solutions must be able to ensure that a person�s title listed in the human resources system is consistent with the person�s spending limit in the procurement system. Databases solve this challenge by providing stored procedure and trigger features that enable administrators to execute a business rule each time a data value changes.

Directory services do not provide similar features today. Therefore, identity management solutions must provide the capability to execute business rules, which reject changes that do not meet referential integrity requirements. Only a metadirectory solution addresses all these issues.

TitleSalarySpending Limit

Application

Directory

Database

User X Applications


The Metadirectory As a Corporate Solution

If Internet/intranet, proprietary e-mail, and other directories contain identity information about only some people, somewhere, the metadirectory is capable of containing identity information about everybody, everywhere. The metadirectory lets one integrate any number of disparate identity repositories in virtually any format. Thus, the metadirectory becomes the object root of identity information within the enterprise. The metadirectory provides the rationalized and unified view of identity objects that consists of attributes from a variety of directories. This integration enables one to lower administrative costs, eliminate duplication, reduce discrepancies, and make the identity information widely available. The metadirectory is flexible enough to adapt itself to any enterprise�s organization, structure, politics, and management styles, and dynamic enough to change as they change.

Sources

The metadirectory collects its identity information from the other connected directories and repositories in the enterprise. Nearly all e-mail, database, and other directory applications can export their contents in some form. The metadirectory can collect this data through file exchange, in an e-mail message, or through an online, protocol-driven transfer. The directory administrator or end user can add other metadirectory identity information.

Content

Directories are usually thought of as containing identity information about people, such as e-mail addresses, but this is a limited view. The metadirectory can contain much more information about any real-world objects. Objects may be:

● Physical objects, such as people or computers.

● Conceptual objects, such as organizations or departments.

● Geographic objects, such as countries or cities.

● Digital objects, such as documents and files for online viewing.

The only requirement of the metadirectory is that these objects be organized in some sort of hierarchical structure. For example, a person might be described as part of a department that is part of an organization that is located in an Internet domain or a country. Or, in a multi-national corporation, an employee might be part of a division located in a country that falls under the corporation in the organizational tree.

A person is not necessarily the lowest level of the hierarchy. For example, a document or a portable computer belonging to that


person might also be represented by a directory entry below the person entry in the tree.

Management

The management of metadirectory contents and security can be centralized, distributed, or a combination of both. The metadirectory can be created so that changes to certain entries can be made only in the connected directory and then imported into the metadirectory. Changes to other entries may be made only in the metadirectory and then propagated to the connected directory. Different people can manage different portions of the metadirectory. This level of control extends, not just to the entries themselves, but also to the individual attributes. Therefore, end users can manage parts of their own identity information�for example, telephone numbers or addresses. The metadirectory does not impose any management model. It lets one create a directory whose management matches the realities of the organization and its security and access control requirements.

Documenting the Directory Services Architecture

Accurately documenting directory services deployment is fundamental to managing, supporting, operating and maintaining a directory solution. Before one can proactively manage, operate, support or maintain anything, one must first understand what it is, how it operates, who is responsible for which piece, and how it functions under normal load.

Six Sigma Values

Six sigma values, taken from the book by the same name (Harry, Mikel, Ph.D., and Richard Schroeder. Six Sigma. Doubleday Press, February 2000.) states the following:

● You don�t know what you don�t know.

● You can�t do what you don�t know.

● You won�t know until you measure.

● You don�t measure what you don�t value.

● You don�t value what you don�t measure.

These values clearly represent the need to understand what you have and the value associated with being able to affect what you have in meaningful ways. These values also illuminate responsibility and accountability of IT assets. The following section discusses documentation and operations.

Operations and Documentation

Accurate documentation of the directory and its support services is critical. Complete and accurate documentation of directory


architecture and schema is the first step in keeping a directory healthy.

Documentation is not a one-time process; directory documentation is a living work that must be updated when change occurs. Apart from the obvious day-to-day requirements of managing a company�s directory, there are the higher-impact issues when faced with business acquisition and divestiture.

Good documentation provides a number of benefits:

● Increased guidance for operations

● More highly maintainable systems

● Easier system enhancement

● Better training within the operations team

The documentation created and used by the operations teams can usually be classified according to its source, such as hardware and software vendors, service desk, application development, and support.

What and How to Document

It is important to point out that documenting directory architecture consists of numerous related pieces. These include, but are not limited to:

● Diagrams illustrating where directory servers are physically located.

● Diagrams indicating the logical flow of data around and through the directory.

● Copies of configuration files with explanations of their use.

● Step-by-step instructions for operations.

● Service desk and technical support organizations.

● Troubleshooting flow charts and custom application systems.

● Third-party hardware and software manuals.

Examples of what some of these should entail are included below.

Hardware and Software Vendors� Manuals

It is imperative that copies of all vendor product manuals for directory products and solutions (for both hardware and software) be kept and maintained. These should be stored in a library central to the support organization in order to be accessible by all individuals, groups, or departments who have responsibility for operating, administering, or maintaining the directory. It is imperative that these be updated as the versions of hardware and software change.


Operations Manuals

Operations manuals take different forms based upon the group targeted. This next section illustrates some examples of how documentation may be compiled into a working manual dependant upon the group�s needs.

Service Desk

Assume, for example, a service desk (tier-1 support) that responds to customer problems and acts as the high-level watchdog for the monitoring system. A very clear set of documentation needs to be established for this group. It should include:

● Information on where directory servers and components are located on the network.

● Initial troubleshooting steps (to the extent this type of activity is appropriate for this group) in the event of a directory issue.

● Clear escalation procedures in the event that the issue is beyond the scope or capabilities of tier-1 support.

● Instructions on appropriate customer notification if the failure will affect end users.

Of course, this is entirely based upon the capabilities of the service desk, the size of the organization, and what other support groups are in place to monitor and respond to directory issues.

Directory Operations

Directory operations (tier-2 support) is the group responsible for server maintenance, backup and restore, and monitoring (performance, health, and so on.).

Directory operations should be provided with clear, consistent, and up-to-date manuals detailing:

● Information on where directory servers and components are located on the network.

● Information on how data logically flows through the directory.

● Information on all processes and programs running in support of the directory services.

● Information on all hardware running in support of the directory services.

● Troubleshooting steps (to the extent this type of activity is appropriate for this group) in the event of a directory issue.

● Clear escalation procedures in the event that the issue is beyond the scope or capabilities of tier-2 support.


● Instructions on appropriate customer notification if the failure will affect end users.

Directory Architecture

Directory architecture comprises system architects, engineers, and any third-party consultants or systems integrators that assist with the design, deployment, support, and upgrade of the directory. This group needs access to the following information in the form of a formal operations manual:

● Detailed information on where directory servers and components are located on the network.

● Detailed information on how data physically and logically flows through the directory.

● Detailed information on all processes and programs running in support of the directory services.

● Detailed information on all hardware running in support of the directory services.

● Detailed troubleshooting steps to be able to resolve any problem that might occur with the directory.

● Procedures for informing tier-1 and tier-2 support on how best to notify customers and management about problems, fixes, and time-to-repair.

Not all support organizations may be built exactly like the above examples, but it is critical that each support tier has correct and up-to-date information in order to best execute their jobs in support of the production directory solution.

Bottom-up Documentation (Physical Design)

It is important to first understand the physical layout (architecture) of the directory deployment. If one has more than one directory and is moving toward a metadirectory solution to simplify and centralize management and to consolidate services to better facilitate directory-enabled applications, one will need to carefully document all directory solutions that fall into this scope.

Most likely, the systems integration firm, value-added reseller, and consultancy or directory vendor that assisted with the initial design and deployment will be able to help with this important step. In the best-case scenario, one has already been provided with a diagram of the physical design (infrastructure design, architectural layout, location of servers, services, and so on) as part of the directory design and deployment engagement. If not, request any and all documentation they have from the project.


There are a variety of tools and utilities that can assist with the diagramming of the directory solution. As an example, Microsoft Visio® Technical Edition drawing and diagramming software has been used for years to create drawings of computer and network-based deployments. Although an excellent choice, there are also many other programs available that do a good job, are easy to use, and are easy to update. However one captures this information, it is paramount that it be accurate and up-to-date at all times.

Top-down Documentation (Logical Design)

Understanding the logical flow of data through a directory (processes, applications, automation tools, and so on) is just as important as understanding the physical design (where servers are located on the network). If one does not know exactly how the directory works, both logically and physically, one will not be able to proactively monitor for performance, integrity, and reliability. Also, one will not be able to accurately troubleshoot when problems are experienced.

When the physical architecture has been diagramed, the next step is to go back and document:

● Where the data resides (the location of the databases).

● Where specific processes are located and executed.

● Where configuration files are located.

● Order of operation for all processes and functions.

● The method by which data is entered into the directory. This includes every possible source of input�from high-level programmatic entries or modifications to low-level user-specific changes.

● All directory-enabled applications, tools, and utilities that either support or use the directory directly.

In addition to documenting all the process components that comprise the directory, one should also map out exactly how the data flows through the system and which directory processes and applications are dependent upon others. To elaborate on which information is important to document, one should, at a minimum, know the following information:

● Location of the databases. One must understand the location and function of all databases associated with the directory, if they are centralized or distributed, their size, the file system upon which they reside, the database engine that supports the data (vendor and version), and the target user population for which the database provides services.


● Where specific processes are located and executed. One must also be aware of all directory-specific or related processes that run within the context of the directory, providing services, automation routines, maintenance, or application support. If these were developed in-house, one should have all related support and program information. The same holds true for third-party applications, tools, utilities, and programs that have been integrated into the directory solution. Be sure to capture all version, service pack, patch and fix, and upgrade information related to the program or process.

● Where configuration files are located. This is part of the disaster recovery plan, but it is important enough to reiterate here; one needs an accurate and up-to-date dump of all directory-related configuration information (for example, the schema, specialized server settings, configuration files, and so on).

● Order of operation for all processes and functions. Every process or program that runs in the directory space is subject to an order of operation, and many contain contingencies with other programs, processes, and/or applications. It is important that one knows what these are and what the dependencies are. Careful documentation and understanding of this element greatly enhances troubleshooting and effecting a timely recovery in the event of a problem.

● How data is entered into and extracted from the directory. This element includes every possible source of input and output, from programmatic entries or modifications to user-specific changes. One must know where all data in the directory is coming from at all times. Automation of routine data input functions can save time and money and greatly limit the number of human-induced errors that can creep into the directory, but automation can also make troubleshooting more difficult. Know where data entered into the directory is coming from, as well as all possible sources of output for the content (a possible security issue!).

● All directory-enabled applications, tools, and utilities that either support or use the directory directly. One must also be aware of all applications, tools, and utilities that run within the context of the directory, providing services, automation routines, maintenance, application support, or end-user services. If these were developed in-house, one should already have all related support and program information. If they were purchased from or developed by a third party,


be sure to capture all version, service pack, patch and fix, and upgrade information related to the program or process.

Monitoring Directory Components Why Monitor?

Monitoring is the only indication as to the health and well being of the deployed directory solution. Experience proves that companies who do not initiate proactive monitoring always fall prey to crisis situations (disasters that could have been foreseen and avoided) and quickly fall into the unenviable position of constantly having to respond to situations where customers are impacted by failures or service interruption. How many times has a service interruption been first reported by a customer or end-user (usually by a call to the service desk indicating a problem connecting to or accessing a system or service)? With a little thought and a little more work, one can implement a proactive monitoring scheme that ultimately saves time and money and vastly improves customer satisfaction.

Introduction to Monitoring

The directory is the heart and soul of the computing environment, used by customers to log on to the network, authenticate to services and applications, and look up other users and resources network-wide. An interruption to these core directory services results in downtime for users and applications, which directly translates into lost productivity and money.

By monitoring the directory, one can learn of outages as soon as they occur, and in some cases, even before they occur. With more sophisticated monitoring tools, one can further anticipate failures, understand where performance degradation exists, and use the captured information for the purpose of system tuning.

A monitoring system consists of three elements:

● The monitored devices and services.

● The monitoring solution or system.

● The alert, notification, and escalation processes that determine how one responds to events.

These are depicted in the following figure and explained in further detail below.


Figure 20 Components of an active monitoring system

Device and application probing. This element is the function or process responsible for periodically checking the status of a monitored service, device, host, application, or other system. When a device fails to respond to a specified probe, an alert is generated that indicates the failed device and nature of the failure.

Event correlation module. This element receives input from the probing module and correlates the inputs to determine the root cause. It then suppresses any events that might have occurred as a result of other events. For example, a router might fail, affecting all hosts, systems, or devices downstream to the device and rendering them temporarily unavailable. After suppressing indirect events, the module constructs one or more alerts and forwards them to the notification module.

Notification module. This module receives alerts from the correlation module and generates notifications to the appropriate (pre-programmed) respondent or responsible party. Also, this module might generate a notification to an automated response system pre-programmed to restart a service or some other remedial action designed to address a failure.

The monitoring system shown in the figure above is a conceptual model. Humans or a software application could perform any of the model�s elements. The goal is to automate these elements as much as possible into a cohesive, predictable solution that addresses specific monitoring needs.

Types of Monitoring and Monitoring Systems

There are essentially three types of monitors: hard-error monitors, soft-error monitors, and performance monitors.

Hard errors occur as a direct result of a hardware or network failure (that is, when a directory server crashes or loses a disk, resulting in a loss of directory function or service).

Soft errors are typically caused by programming or data problems, resulting in incorrect or inconsistent data in the directory proper.

Performance monitors provide valuable feedback on the system�s performance, identifying bottlenecks, points of contention, and

ProbingModule

EventCorrelation

Alerts &NotificationSystem, App

Automated Response System

Operations, Administration,Helpdesk

Device,


performance degradation. Performance monitoring can also provide baseline information, allowing one to capture trend information useful in understanding when to perform capacity planning or execute an upgrade to the directory infrastructure.

There are a number of commercially available monitoring systems available that most likely contain all or most of the core elements described above. The solution chosen depends upon such factors as the directory solution, products, how it is built (centralized versus distributed), and the service-level agreements with management and customers.

Methods of Monitoring

There are a number of ways to implement monitoring. This section discusses the most popular and proven methods.

Simple Network Management Protocol (SNMP). Although SNMP has found its widest application in the management of networking hardware such as switches, hubs, and routers, it is also possible to use SNMP to monitor and manage applications and processes running on servers and other support devices. SNMP allows a management application to monitor the status of an entity on a network. It is also possible for a management application to be asynchronously notified through the SNMP trap mechanism when an event or error occurs (that is, if a server process terminates unexpectedly).

LDAP probing. One of the most straightforward and useful ways to monitor a directory is to probe it by connecting from a client and issuing LDAP commands and/or requests. For example, a simple probe tool might connect to a directory and search for a pre-determined entry (an entry established specifically for this purpose). If the response is within a pre-specified response window, the directory is considered to be functioning. If not, the probe tool can generate an error (or alert, or custom notification).

Operating system-specific probes. Most modern operating systems come with tools that provide for monitoring their respective services, including their native directory services. This type of information can assist in determining when a directory is experiencing a problem as a result of the operating system.

Indirect monitoring. Monitoring the applications that directly touch (use or access) a directory provides more of an end-user view of the responsiveness and reliability of the system.

Log file analysis. One can automatically scan a directory�s log files for events that indicate an error condition. Additionally, one can monitor for conditions that indicate performance problems. Log file analysis is also a great way to perform proactive monitoring.


General Monitoring Principles

This section details several concepts and principles fundamental to monitoring a directory.

Monitoring Unobtrusively

One should always understand the implications of a monitoring strategy. It is possible for a poorly designed or implemented solution to adversely affect the performance or operation of a directory solution. In general, strive to make the solution as unobtrusive as possible while allowing for the capture of the required information.

How to make the solution unobtrusive? One needs to implement a solution that is as lightweight as possible, while providing all relevant information. For example, if using a probe, it is sufficient to retrieve a single entry, indicating that the directory is functional, instead of multiple or numerous entries. Furthermore, only probe as often as absolutely necessary to provide adequate responsiveness. This limits the additional burden on the directory and seeks to limit additional load on the services. Probing the directory every five seconds returns failure data sooner, but may place an obtrusive burden on the service(s). Probing every minute, or even every 15 minutes, is usually a better window. The frequency is, of course, contingent upon the existing service level agreements.

Cascading Failures

If a failure occurs, it may also trigger other alerts in the monitoring solution. For example, if one set of replicated directory servers fails, this may place an additional load on the remaining servers, in turn generating alerts from the still-functioning servers. If this happens, one can respond by disabling non-critical services or applications to reduce the load on the remaining servers. Additionally, re-examine the capacity capabilities to proactively provide headroom in the event that this ever happens again.

Maintaining a Problem History

Design monitoring so that it provides an accurate history of events and problems. For example, if using a commercially available network management and monitoring system that logs events in a standard format, periodically extract the directory-related entries and compile and archive these logs in a central location for later, periodic review. These extracted logs provide critical trend data that help identify recurring problems (good cause-and-effect information), help with capacity planning, and provide solid information regarding the overall reliability and availability of the directory system.


Maintain a Written Plan

Finally, for every type or instance of a failure, event, or problem, create a written plan that provides timely, accurate, consistent, and reusable responses. The emphasis is on �reusable.� If one is not capturing information on recurring events and executing a consistent plan for addressing these issues, time, resources, and money are being wasted!

Notification Techniques

Actively capturing real-time event information is worthless if one does not notify the responsible parties so they can execute the action plan. Event notification accomplishes four important goals:

● Notifies the parties responsible for fixing the problem.

● Notifies the parties responsible for administration of the system.

● Notifies the parties affected by the event.

● Notifies each party in an appropriate way.

As soon as a problem is detected, the system should notify the person or persons responsible for fixing it. This is typically a higher-level resource, such as a systems architect, engineer, or consultant, who designed and deployed the solution. Based upon the nature and severity of the problem and the sophistication of the event-response capabilities, this may also be a system administrator or technician properly trained to respond to directory interruption events. This type of notification is typically urgent, especially in a situation where the directory is a mission-critical, 24/7 operation. This notification usually is in the form of a telephone call or page.

The notification system should also notify the group responsible for administration of the directory. This type of notification is advisory�it might take the form of e-mail�and lets the responsible group know there is a problem and that it is being worked. It is important that there be close coordination between the people responsible for fixing the problem and the group that provides administrative support.

Users and customers may also need to know there is an interruption�the very last thing one ever wants is a user or customer making the initial notification of a problem. Although customers don�t need to know specific details regarding the nature of the problem, it is best that they be apprised that there is an interruption (or anticipated interruption) and provided some indication as to the duration of the outage. This notification may be in the form of an e-mail; or, if the e-mail system is affected by


the event, possibly a Web page that lists system outage information, a global telephone voice mail message, or even simply a notification to the service desk personnel so that they can pass along the information when customers call for assistance.

Taking Action

When an event has been captured and the appropriate people notified in the appropriate ways, the following actions should be taken:

● Minimize the overall impact.

● Correct the problem.

● Determine what happened and why.

● Perform a root-cause analysis.

● Create a formal plan for providing a long-term solution and re-usable action plan should the event occur again.

This may seem like common sense, but this is a critical phase that is often left out because of constant crisis mode or resource constraints. Chances are, though, if the proactive steps outlined in the other sections of this document have been implemented, most of the work has already been done.

Aside from a root-cause analysis, most of the tools and techniques needed to provide a long-term and lasting solution are already found in the day-to-day operations techniques. More information on how to take appropriate action is covered in the �Managing the Directory� and �Maintaining the Directory� sections of this document.

Managing the Directory Managing the directory solution(s) has to do with the day-to-day process of providing for the safety, security, and functional operation of the software and hardware components. Safety and security of the hardware and software components are super-critical issues to address. They are covered in great detail in the MOF security document.

Directory services architecture comprises two basic realms: the physical (hardware) components and the programmatic (software) components. Proactive management provides the benefits of reliability, availability, supportability, and predictability. The following sections discuss how to care for directory hardware and software and realize these benefits.


Hardware Management Overview

Hardware management ties directly with the earlier section on documenting directory architecture. As has been previously stated, it is impossible to manage systems where their location, function, dependencies, and inter-relationships with other processes, functions, or applications are unknown. If one has not yet completed the documentation phase of the management plan, please go back and conclude that process prior to attempting any of the hardware or software management processes outlined in this section.

This topic also ties critically with the monitoring section, in that the ability to proactively manage a piece of hardware is only as good as the processes for monitoring the health and wellness of the system.

Software Management Overview

Software management also ties directly with the earlier section on documenting directory architecture. As has been previously stated, it is impossible to manage unknown systems. If not yet finished with the documentation phase of the management plan, please go back and conclude that process prior to attempting any of the hardware or software management processes outlined in this section.

As with hardware management summarized above, software management also ties critically with the monitoring section, in that the ability to proactively manage a program component is only as good as the processes for monitoring the health and wellness of the system.

To summarize, managing directory services hardware is all about knowing exactly what is in place, what it is doing, and how well it is performing the functions for which it was deployed. It is also about implementing processes whereby one can leverage available support resources in a hierarchical fashion in the event of a problem. This means defining a tiered support system appropriate for the architecture and aligned with available support groups. The major points to consider when designing a support model for a directory are as follows:

● How centralized or distributed is the directory architecture?

● What levels of redundancy and/or fault-tolerance are designed into each functional component of the system (both hardware and software)?

● Is there a central service desk available to provide front-line support in the event of a reported failure (either from the monitoring/notification solution or from an end user)?


● How delegated are the administrative roles for the directory?

Maintaining the Directory This section details the process of maintaining a directory and the services that support it. This phase of the management plan details the day-to-day process of protecting the directory by way of backup and restore and then addresses the broader issue of disaster recovery. With respect to disaster recovery, the plan must contain steps, processes, and methodologies that include disaster preparedness, disaster avoidance, and only then, disaster recovery. Molding the plan in such a way decreases the likelihood of ever needing the recovery portion of the plan.

Creating a Directory Backup and Restore Plan

The data contained in the directory is, or very soon will be, critical to the base operation and productivity of the organization. If the directory becomes unavailable for any reason (for example, equipment failure or data corruption), the business will suffer from lost productivity and financial loss. Developing sound backup and restore procedures for the directory and supporting system components ensures that no critical directory data and configuration information will be lost.

The development of the backup and restore procedures themselves is equally important. Simply having a tape backup process without having a clear, concise, and thoroughly executable restore plan that is regularly tested by the individuals responsible for the process places one in the position of being exposed to data loss and/or significant system downtime while attempting to engineer these details on-the-fly.

Fundamentals of Backing Up and Restoring a Directory

Like file systems, directory data is stored on mass storage devices like disk drives. This data can become damaged or corrupted for any of the following reasons:

● Disk drive media or controller failure (defined as the hardware failure of the disk device or disk controller)

● Software bugs or anomalies (defined as problems in the programs or directory operating code that comprise the directory service)

● Directory-enabled applications performing erroneous operations (defined as applications that directly access or manipulate the directory data, submitting erroneous information or incorrect delete, change, or add information)


● Operator error (self-explanatory�this is the most frequent cause of damage or loss!)

● Theft (defined as any unauthorized access or manipulation of the directory data or configuration�can be internal to the company or from an external attack)

● Disaster (these are typically natural disasters, including floods, fires, and earthquakes, but also human-generated such as sabotage)

If any of the above events affect the directory, one needs a way to recover back to a state of production operation. One can accomplish this by restoring the directory (data and configuration) from a backup taken at a time when the directory was whole.

There are two ways to back up a directory:

● Use traditional media like magnetic tape and disk mirroring technologies.

● Employ a replication technique.

Backup and Restore Using Traditional Media

Just like file systems stored on disk subsystems, directory data and configuration files can be backed up to a traditional media like magnetic tape. One can also back up to a separate disk drive that is local or on the network. These backups can be used to restore lost or damaged data in the event of a service interruption.

That said, backing up a directory differs from backing up file systems in the following ways:

● File systems are usually much larger than directories, requiring the protection of orders-of-magnitude more information. This means that while it may be feasible to archive a directory to an alternate disk drive, a larger file system may require the use of a higher capacity tape system. However, very large directories (some many gigabytes in size) may also require the use of higher capacity solutions (such as magnetic tape).

● Unlike file systems, directories are frequently replicated to provide load balancing, fault-tolerance, and localized access in a distributed environment (for performance reasons). It�s important to understand the implications of restoring a replica of the directory from tape. In most cases, it is better to rebuild the damaged replica from the data in its peer replicas; the data in the peer replicas should be more up-to-date.


● The tools provided to back up directories typically do not support incremental backup, in which only the data that has changed since the last backup is copied to tape. This may change in the future, but for now directories are typically backed up as a single unit.

● The directory service may be spread across a number of distributed servers. To protect the directory, one must either back up each server individually or back up all the directory data from a single, central location.

In addition to the magnetic tape media described above, one can also use a disk mirroring technique to protect data. Mirroring is a technology where any data written to the primary disk is also written to a secondary disk. Should the primary fail, the secondary can be used as a backup.

Regardless of the media or technique, it is imperative that one use media that can be transported off-site at regular intervals. A backup is of no use if it is also destroyed in the same disaster.

Backup and Restore Using Replication Techniques

Although traditional backup and restore techniques can protect against data loss, they have one major drawback: restoration of large amounts of data can take several hours to complete. This delay in bringing a production system back online may not be in line with established availability and reliability commitments. Using replication as a means of providing fault-tolerance and redundancy for data may help avoid the costly downtime associated with traditional restore technologies.

Replicas are online copies of the directory data. In the event of a server failure, peer replicas provide continued service and access to the data while the failed server is being repaired. When the server is recovered, it can be brought back into the fold as a replica server. If there is adequate capacity in the replica design (number of servers and how they are distributed around the architecture), users will not be impacted by any single-server failure (in reality, they should never know there was a problem).

Directory replication has another advantage: because directory replicas are typically always up-to-date, one doesn�t have to worry about restoring an older, out-of-date copy of the directory, then performing incremental updates, or re-syncing with other copies of the directory. Although this is a distinct advantage, one must also know that most directories support �loose� consistency where changes made to the directory are stored on one replica for an amount of time before being propagated to the remainder of the replica servers. Understand that there is no guarantee that all replicas will have the latest changes all the time. Consistency


and synchronization of replica data is a design issue and is based upon specific performance requirements.

Replication comes in two forms: single-master and multi-master. In a single-master operation, only one server (the master) can accept changes to the directory, all other replicas are read-only. If the master server fails, no changes can be made to the directory until the master is restored or another replica is promoted to the role of master (assuming the directory solution supports this promotion).

Multi-master is a much stronger and more flexible solution and is easier to recover in the event of a failure since any replica in the set can accept and process changes to the directory. In a multi-master environment, if a master fails, one simply takes it offline to repair it, and then re-establishes it as a replica when ready.

Combining Traditional Backup and Replication Techniques for Data Protection

While replication provides the best real-time, online form of data protection, traditional backup provides the best means of broad-based recovery, such as in the event of a site disaster or the ability to recover from corrupted or incorrect data in the directory.

The best approach is to combine the two techniques for the broadest, most flexible approach to data protection. Using replication for network-wide synchronization and update, load balancing, and fault-tolerance is the current state-of�the-art in distributed directory technology. However, also performing periodic centralized traditional media backups of the entire directory and configuration information provides the necessary additional layer of protection. Maintaining copies of these media at an off-site location ensures that, regardless of the nature of the disaster, one can eventually get back to a state of production wholeness. Some companies provide their own off-site storage and tape rotation, pickup, and delivery services. Others engage with a third party to provide these services for a fee. Regardless of how one decides to do it, just do it!

Directory Backup and Restore Plan Considerations

The first step in creating a data protection plan is to assess the current and anticipated production situation. When this has been done, one should be able to easily answer the following questions designed to help assess data protection needs.

● What are the potential failure scenarios? Given the specific environment, architectural and infrastructure considerations, administration model, design, previous failures and interruptions, and exposure to the disaster


elements indicated previously in this section, where is one most at risk for data loss or corruption?

● What and where is the critical data? Has the critical data (directory data and configuration files) been identified? Is the exact location of every replica server and all configuration files on the network known?

● How often should backups be performed? As previously mentioned, backup solutions vary contingent upon the specific directory solution being deployed. Most likely, the backup software vendor has best practices recommendations for backing up their directory (data, applications, and configuration files). However, closely scrutinize this issue and determine a schedule for performing backups based upon specific performance, reliability, availability, and risk mitigation needs.

● Will a hybrid of traditional and replication techniques be used? As described above, will traditional backup (tape) be combined with replication to protect the data? How will off-site storage of the traditional backup media be provided?

● How are backups being verified? Backups are absolutely worthless if one can�t restore them when the time comes; one must periodically test the restore data and process (the action plan for performing a restore) to guarantee the integrity of the backups, media, and especially, the team�s readiness and responsiveness with respect to the restore plan.

● How long will it take to perform a full restore in the event of a catastrophic failure? Is the time-to-recovery consideration part of the service level agreements with customers? Have time-to-recovery expectations (given a worse-case scenario failure) been communicated to the customers?

Troubleshooting Directory Architecture From time to time during the course of a directory�s lifetime, things will go wrong. Based upon the type and severity of the problem, one may experience anything from slight degradations in performance, to full failure of the directory service. When something does go wrong, the objective is to minimize the damage, return the directory to full service as quickly as possible, and understand the problem so that one can take steps to prevent its recurrence.


Directory problems can be broken down into three categories:

● Outages resulting from hardware or software failures

● Performance problems

● Problems with directory data

This section discusses each of these three categories with the express intent of raising awareness levels and enhancing the ability to respond proactively to problems through meaningful troubleshooting.

Discovering Problems

First things first: prior to working on the troubleshooting processes, it�s important to first understand how to discover problems within a directory. Following are a few of the more common means of discovering a problem within a directory service:

● The monitoring system (if present) may automatically detect a failure of degradation within the directory or support service and provide notification.

● The maintenance or operations team may notice a problem with the directory as they go about their routine directory maintenance functions.

● Administrators of dependent services (that is, messaging, human resources, and database) may notice and report problems with the directory or support services.

● End users may notice a problem and report it to the service desk. The failure may originally be reported as a problem with a dependent service (again, messaging), but may actually reside within the directory service itself.

A failure may be detected and reported by one, some, or all of the above simultaneously. For example, if a directory server becomes unavailable, the network management or monitoring solution may report a problem at the same time end users are calling the service desk. As stated above, end users may be the ones reporting access problems with dependent services.

The operations staff may report problems running a scheduled maintenance or data-update procedure. In any event, part of the problem-discovery process is to correlate events so that the root problem affecting the dependent processes is understood.

Ideally, one should strive to eliminate the possibility that end users will notice and report problems first. This is accomplished by way of a well-designed, well-thought-out monitoring and notification plan. This takes careful planning, but the payoffs are significant.


When one experiences a problem, one should appropriately communicate to the end users, service desk, operations staff, system administrators, and management responsible for the service level agreements for the affected system(s). Appropriate communications take the form of:

There is a known problem.

● Expected time to fix or restore the service.

● Any workarounds or alternate service sources that can be used until the primary is restored to service.

Plan well in advance how to notify all affected and interested parties when there is a failure or interruption. Common methods include publishing outage information to Web sites, sending global or group/application-specific messages by e-mail, posting outage information to Usenet newsgroups, and providing status information through a recorded telephone message.

Types of Problems

As mentioned previously in this section, there are three basic classifications of directory problems. This next section discusses these various problem types in greater detail, providing some root-cause and resolution information to help in dealing with these problems when they arise.

Directory Outages

The first type of problem is the directory outage. An outage can occur when all or part of a directory service becomes unavailable. This can occur when one or more of the directory servers becomes unreachable as a result of a network problem or because the directory server�s hardware or software has failed in some way. When an outage occurs, users receive no service whatsoever.

Causes of Directory Outages

Causes of directory outages fall into two broad categories: hardware failures and software failures. Hardware that can fail includes network components such as routers, switches, and network interface cards and cabling, and server components such as processors, memory, disk systems, and power supplies. An outage can also occur as a result of a power outage.

Software failures can include the operating system or the programs, applications, and services that support the directory. It is also possible that other software also running on the directory server can fail, causing an interruption in the directory service.


Implications of Directory Outages

When a directory outage occurs, users and directory-enabled applications receive no directory service at all. Because LDAP is a client-server protocol, the failure is noticed as a failure to connect to the directory service. Directory outages produce three basic symptoms: connection timeouts, connection refusals, and hung connections.

Resolving Directory Outages

If hardware failure is the underlying cause of an outage, the usual course of action is to replace and restart the failed system. For example, if the cause of the outage is a failed power supply, one simply needs to replace the failed unit and restart the server/service.

Outages are not always this easy to fix. Suppose the outage not only caused an interruption in the directory service, but also caused data corruption when the system failed. This presents quite a different challenge than simply replacing a failed component and restarting the device. In this case, one needs to plan for more than just hardware replacement. One needs to also consider data integrity, availability, reliability, and fault-tolerance within the context of the disaster recovery plan. All of these issues are bound by the service level agreements; consider the group�s tolerance for downtime and then plan hardware redundancy, spare parts stock at the location, and hardware failover into the design accordingly. Apart from the hardware outage, also coordinate the response to this type of outage with those responsible for the disaster recovery plan.

Performance Problems

Another common type of directory problem occurs when a directory performs poorly. Poor performance can manifest itself in a couple of ways: the overall performance of the directory may be poor, or a specific type of directory operation, such as a phone number update, may be slow. Performance problems can be consistent, or they may be intermittent. Troubleshooting these types of problems requires careful analysis and special attention to detail.

Causes of Performance Problems

Improperly configured software is the most common cause of poorly performing directory services. An improperly configured directory server might not perform optimally, or it might not function at all. For example, most directory server software uses a RAM-based cache to temporarily store frequently accessed commands or data. With a too-small cache, the server may be


sluggish to respond, or may not respond at all (seems to be hung).

On the other hand, with a too-large cache, the server�s virtual memory system may experience excessive paging. In either case, one needs to perform appropriate analysis of the system and �tune� all parameters affecting performance so that the overall system runs optimally. The directory product vendor is able to provide performance tuning specifications that will help improve performance. In addition, perform additional tuning to meet the specific requirements of the deployment (specifically how the solution is being used).

Another common problem results from not maintaining appropriate indexes for the types of directory searches the server handles. Most directory products support for searches on any attribute. However, search performance is poor on un-indexed attributes because the server might need to search through every entry in the database to locate matching entries. If the server takes a long time to respond to simple searches, check to see if clients are using un-indexed attributes in their search filters.

Finally, one may encounter performance-degrading bugs in the directory server software or the operating system. Software vendors are increasingly using the World Wide Web to inform customers of patches, upgrades, or fixes and to publish knowledge bases full of important and useful information regarding their product(s). Additionally, Usenet newsgroups are a tremendous resource for learning about known bugs, problems, workarounds, and patches. One should be familiar with all vendor and Web-based knowledge and troubleshooting resources specific to the product.

Implications of Performance Problems

The implications of performance problems can range from very slight degradations of the service to outright failure. The symptoms can affect all users equally, or they might adversely affect only a small subset of all users. For example, an improperly configured cache can result in poor performance for all users and directory-enabled applications, whereas a missing attribute index may only result in poor performance for the users who frequently query for that attribute.

Resolution of Performance Problems

When troubleshooting performance problems, it is critical to proceed logically and deliberately. Take careful notes that describe exactly the problem being reported, and then attempt to recreate the problem oneself. If the problem can�t be reproduced, consider the differences between the respective environments.


Are they connected to the same server? Are they authenticated or bound anonymously? Are they close to the server in the network? Try to eliminate each difference independently until the user�s problem can be exactly duplicated.

Fixing the problem may be a simple matter if a small configuration change is required, or it may be a detailed process if a software bug is found requiring an upgrade to one of the directory support applications.

If no fix is available, is there a short-term workaround? Can the effects be mitigated by reconfiguring the directory in some way?

No matter what the remedy, take the time to document the problem, the cause, any short-term fixes or workarounds, and the long-term, final solution. Software problems can be quite complex; and the more one can share troubleshooting findings with peers or the operations group, the more effective the group will be at delivering a high-quality solution to users.

Problems with Directory Data

Directory data problems may be the result of missing, extra, or incorrect information. In the worst case, a directory server�s database files may be corrupted by software bugs, operating system bugs, or operating system errors. Overall, this is the most common type of directory data problem.

Data problems are often a consequence of some other problem, such as improperly configured software. In other cases, data problems can result from incorrect actions by directory administrators (either root-level administrators or even directory-enabled, application-specific administrators). Problems with data itself can also be a cause of other problems. For example, if access control attributes have been erroneously changed, users may not be able to access data they are rightfully allowed to see, or they may be presented with the wrong information or information they should not have rights to see.

Causes of Directory Data Problems

When incorrect data appears in a directory, someone (or some process) must have put it there. For example, an entry for a valid employee may be deleted erroneously instead of deleting the entry for a terminated employee. On a larger scale, an automated update process that reconciles database records from a human resources database may, as the result of a bug, place incorrect employee information in the directory.

Typical monitoring software won�t detect this type of problem unless the data is so damaged that the server crashes or won�t start up. One usually learns about this type of problem from end


users unless one proactively monitors for data quality, which, at best, is difficult to do.

To be more proactive, consider developing tools to monitor the quality of data in the directory or build validation tools into the software used to synchronize the directory with external data sources. Such tools can detect problems before they are recognized and reported by end users or become a greater problem in preventing the directory from running at all.

Implications of Directory Data Problems

When incorrect data shows up in a directory, applications may start behaving erratically or incorrectly. For example, if the entry for a valid user is erroneously removed, the user�s e-mail might be returned to the sender because the user will be unrecognized by the look-up or forwarding agent in the directory service.

In general, if a directory appears to be working correctly, but users are reporting incorrect or erroneous behavior, one needs to start checking the contents of the relevant/corresponding directory entries.

Even more subtle errors can occur if the directory holds information about network resources such as file servers or printers. If the directory entries corresponding to these devices are removed or damaged, the services provided by these devices will not be available.

Additionally, if database files become corrupted, symptoms may be either very subtle or very obvious. All the entries in the directory may disappear (which is obvious), or certain entries or attributes may not be returned when certain types of queries or searches are performed. Robust server software may prevent most of these types of problems, but operator mistakes can introduce many types of data inconsistencies, wreaking havoc when users attempt to use the directory for normal operations.

If the corruption is subtle, it may go unnoticed for some time. When dealing with corrupted data, always be open to the possibility that the corruption actually happened some time ago and is just now being noticed.

Resolving Directory Data Problems

If it is determined that there is a problem with the data in the directory, the first thing to do is to determine the extent of the damage. To do this, one needs to have some idea of what truly should be in the directory. A good starting point is to look at the directory contents. Is the correct number of entries in the directory? If there are too few entries, which indicate that entries are being deleted, it may be prudent to shut down some or all of the automated or dependent services or applications. For


example, if entries for an entire department or group are missing, it would be prudent to shut down e-mail services for that group so that their mail is not returned to the senders when no valid directory entries are found for them.

If in doubt, the safest thing to do is to shut down the affected servers. Directory-enabled applications (well-written ones anyway) typically notice that the directory is unavailable, report a meaningful error, and then try the operation at some later time. If the problem server is not shut down and is missing or contains bad data, the application accessing or using the directory may also begin failing due to the use of bad data.

As soon as the extent of the damage is known, one needs to set about repairing it. How this is done depends upon the extent of the damage, how much is known about the cause, and the amount and accuracy of information relating to the directory�s contents. For example, if only a single user�s entry is missing, it is probably best to simply re-create the user and restore any security and application attributes. If the entire directory has been deleted by an erroneous process or too-tired operator, it is best to now move immediately into disaster recovery mode and begin restoring the directory by using the recovery plan.

When the directory is restored, one needs to fully understand what happened by performing a root-cause analysis as indicated in the following list:

● How was the data corrupted�through an automated process or operator error?

● Did a data merge, join, or synchronization fail causing the problem?

● Is there any information in the log files that points to the problem?

● Is there a security audit trail that sheds light on the cause of the problem?

Whatever the cause and however complex or time consuming it is to discover, one needs to see this critical step through until what happened is fully understood and appropriate steps can be taken to prevent it from happening again.

Troubleshooting Flow Chart

The following flow chart maps the steps necessary to perform corrective and appropriate problem management in the form of troubleshooting.


Figure 21 Troubleshooting flow chart

Troubleshooting Checklist

Use the following checklist whenever a problem is experienced with a directory. The checklist includes the three problem types covered above and also includes several questions related to security. Security is not covered in this document. For detailed information related to security, please refer to the MOF security administration white paper.

Directory Outages

● Are directory clients timing out, or is the server refusing their connections?

● Are all network components (routers, hubs, switches, cables) between the client and the server operational?

● Is the directory server machine operational? If not, can one determine whether this is a hardware or software problem?

● Are all hardware components on the directory server operational? If not, are there any operating system or server logs that point to a hardware failure?

● Is the directory server process running? If so, is it consuming higher-than-normal CPU cycles or causing excessive disk activity?

● If the directory server process is not running, did it fail when processing a specific or particular type of client request? Does it fail each time it receives/processes such a request? Such a request may represent a denial-of-service attack.

Assess the problemand notify affected

damage

Apply short-term fixor alternate solution

(if necessary)

Perform root causeanalysis to

understand theproblem

Implement long- term fix (with

change control)

Apply monitoring for the known problem

Fully document what happened

Contain the

users


Performance Problems

● Are specific types of directory operations performing poorly, or is the overall performance of the server poor?

● Are appropriate attribute indexes being maintained on the directory server?

● Is the size of the directory server process too large? Does it become large immediately upon startup or gradually over time?

● Are the cache sizes of the directory (if any) configured appropriately (neither too large nor too small)?

● Are other processes running on the directory server machine causing performance problems?

● Is the directory under a particularly heavy load? Is this load expected? If the load is excessive, is there one specific client or query process accounting for this load?

Problems with Directory Data

● Is the data missing or incorrect?

● Does the data appear to be corrupted in a catastrophic manner? Such damage indicates a serious hardware or software problem.

● Is the data damaged in some specific way? For example, have certain entries been erroneously deleted? Can the source of the erroneous modification be determined by examining the server or directory logs?

Security Problems

● Are there signs of a break-in, such as connections from an unexpected or unauthorized location or client? Are there unexpected modifications to directory entries?

● Do directory or server logs show unexpected activity or access?

● Is the directory experiencing a denial-of-service attack? Such an attack overwhelms available directory or server resources. Is the source of the attack known?


Roles and Responsibilities Principal roles and their associated responsibilities for directory services administration have been defined according to industry best practices. Organizations might need to combine some roles, depending on organizational size, organizational structure, and the underlying service level agreements existing between the IT department and the business it serves.

The following describes the roles and responsibilities related to directory services.

Directory Administrator The directory administrator is the process owner with end-to-end responsibility for the directory administration process. The directory administrator is part of the operations role cluster defined in the MOF team model.

With regard to process design and/or re-engineering efforts, the directory services manager has the most responsibility for the process, for it is the process owner who provides both leadership and accountability for this process and all of the activities performed during the execution of the directory administration process.

Thus, the directory administrator is responsible for all of the process improvement efforts affecting directory administration and its activities. The directory administrator should also be able to spend a considerable amount of time working on process improvement, as well as maintaining good relations with top managers in various business units and stakeholders with vested interests in the success of the process.

The directory administrator:

● Determines all directory administration, integration and operation strategies.

● Ensures that all application integration and dependencies are met.

● Ensures enterprise directory documentation is accurate and current.

● Ensures accurate representation of directory resources in the CMDB.

● Creates new directory objects.

● Manages directory database schemas.


● Monitors data replication to ensure it occurs in a timely fashion.

● Copies data to tape or other storage media.

● Monitors directory for capacity, availability, and performance.

Directory Designer The directory designer is responsible for creating a design that allows the directory to provide the correct information where it is needed most. A good design should provide information to users while requiring as little resources as possible in terms of network bandwidth, processor and memory resources, and operator time.

The directory designer:

● Designs the directory infrastructure to meet service level requirements.

● Creates the directory database schema.

● Creates a list of changes required to an existing database schema in order to meet new business requirements.

● Creates requirements for network infrastructure in order to ensure data replication.


Relationship to Other Processes As the directory becomes more central to the fundamental operation of the computing environment, it is important to understand how supporting the directory affects other operational processes. The graphic below depicts the relationship between directory services administration and the other MOF SMFs within the operating quadrant.

Figure 22 Relationship to other SMFs in the operating quadrant

System Administration System administration deals with the administration model used by an organization. Some organizations prefer a model where all IT functions are performed at a single site by a team of IT professionals collocated at that site. Other organizations prefer a distributed branch-office model where both technologies and support staff are geographically distributed. System administration examines the trade-offs of each model. Each type of system administration model has unique directory requirements. For example, user accounts stored in the directory may have to be located close to the users in order to minimize the time it takes to log in. A distributed management model may also require delegated access to objects in the directory.


Security Administration Security administration includes information required to plan, select, implement, manage, and review security controls. It also includes processes and procedures needed to respond to security events. This is especially important to the operation of a directory, since the directory now provides many security functions.

Service Monitoring and Control Service monitoring and control monitors the various aspects of system performance to ensure that service level agreements are being met. Administrators in charge of monitoring systems performance must ensure that the directory does not become too large or that it does not use an inordinate amount of network bandwidth.

Network Administration Network administration deals with the maintenance of the physical components that make up the organization�s network, such as servers, routers, switches, firewalls, and so on. Directory replication can require a significant amount of network bandwidth. The amount of network bandwidth available has an influence on the directory design.

Print and Output Management Print and output management deals with all data that is printed or compiled into reports, which are distributed to various members of the organization. Records of available printers and their locations are often stored as objects in a directory.

Configuration Management Configuration management deals with keeping track of the versions of internal software that are used. It is important for administrators to clearly understand and be in full control of which versions of the operating system, database management system, and all applications are running on network machines. With respect to directory services, configuration management controls specifically which version of the directory is running, which versions of directory-enabled applications are deployed, and which versions of support, custom-built, or third-party tools are running.


Availability Management Availability management deals with overall system availability versus downtime. Since most organizations today are essentially paralyzed when the system is down, it is extremely important that administrators properly configure and monitor the system to maximize uptime and mean time between critical failures. Availability management is tied directly to service level agreements and is essentially what has been promised to management and end users regarding the reliability and availability of the directory.

Capacity Management Capacity management is critical to the current and ongoing operation of a directory. Capacity management deals with planning for additional resources as current system resource use increases and begins to near the point of full capacity. It is critical that the directory perform (response time) and scale to meet the needs of both current and future users.

Failover and Recovery Failover and recovery deal with automatically changing to an alternate server when a server goes down temporarily, and then transferring back to the main server when it becomes available again. This is especially important as directories become more central to the fundamental operations of the computing environment.

Service Continuity Management Contingency planning is closely related to failover and recovery, but it deals with catastrophes on a larger scale. Contingency planning deals with what happens when an entire data center goes down, due to power outage, flooding, fire, terrorism, and so on. If a contingency plan must be implemented, restoring the directory is one of its primary concerns.


Contributors Many of the practices that this document describes are based on years of IT implementation experience by Accenture, Avanade, Microsoft Consulting Services, Fox IT, Hewlett-Packard Company, Lucent Technologies/NetworkCare Professional Services, and Unisys Corporation.

Microsoft gratefully acknowledges the generous assistance of these organizations in providing material for this document.

Program Management Team

Jeff Yuhas, Microsoft Corporation

William Bagley, Microsoft Corporation

Lead Writer

Stephen Barnard, Microsoft Corporation

Contributing Writers

Vicky Howells, Fox IT

Editors

Steve Morgan, Fox IT

Patricia Rytkonen, Volt Technical Services

mof service management function directory services ... · services is to ensure that through a...

Documents