Service Management Functions

On This Page

	Document Purpose
	Executive Summary
	Process and Activities
	Roles and Responsibilities
	Relationship to Other Processes

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 http://www.microsoft.com/solutions/msm/.

Top of page

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, group's, or types of access, and personalized because directory information can be tailored to provide customized responses to specific users or group's.

Top of page

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:

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 integrationacting, 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: 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:

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:

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. 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 otherthe 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:

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 ones 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

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:

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

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 addressesall 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:

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 components physical location, nor does the application malfunction when the components 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 automaticfor 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 group's.

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:

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:

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
See full-sized image.

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 issuesfor 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 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
See full-sized image.

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 enterprise's 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).

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
See full-sized image.

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
See full-sized image.

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
See full-sized image.

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, 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
See full-sized image.

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 users 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.

Figure 8: Attribute filtering during import
See full-sized image.

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 servicenot to the metadirectory itselfare 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:

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
See full-sized image.

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 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 partsas 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.

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

Figure 11: The directory join
See full-sized image.

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 Freds relationship to the organization. On the other hand, Freds 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.

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:

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 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 enterprise's. 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 attributestheir location and the printing capabilities they support.

Figure 13: The identity management challenge
See full-sized image.

The Identity Management Challenge

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

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 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 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:

Figure 14: Connectivity requirements
See full-sized image.

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

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:

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 enterprise's, 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:

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 structurefor example, moving from the accounting department to the sales group.

Figure 17: Tracking related objects
See full-sized image.

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:

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.

Figure 18: Managing ownership relationships
See full-sized image.

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.

Figure 19: Managing failures
See full-sized image.

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 wayssuch as using log-based, desired-state mechanisms that continue to request changes until confirmedto 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.

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:

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 informationfor 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:

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:

The documentation created and used by the operations teams can usually be classified according to its source, such as hardware and software vendor's, 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:

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

Hardware and Software Vendor's 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, group's, 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:

Of course, this is entirely based upon the capabilities of the service desk, the size of the organization, and what other support group's 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:

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:

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:

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:

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:

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

Figure 20: Components of an active monitoring system
See full-sized image.

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 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 system's 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 system's 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: