Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

How to Build an Enterprise Directory with LDAP and X.500

Building an LDAP/X.500 Enterprise Directory

This Isode paper looks at the key architectural issues relating to deployment of a directory based on LDAP and/or X.500 within an enterprise. The nature of such a service is considered briefly, and how users and systems will access the directory. The core of this white paper focuses on is the protocol support required by the client and server elements of an enterprise directory, and how the whole system can be connected together to establish a coherent and effective service.

Evaluate Today
You can evaluate M-Vault, Isode's LDAP/X.500 Directory Server today. Visit the evaluation page here for more details.

An LDAP/X.500 enterprise directory is ideal for supporting white pages services, message system configuration, X.509 security, and other enterprise wide information needed by users and systems. The starting point of this paper is that a directory of this nature is being deployed and so the benefits of this type of service are not discussed. This paper looks at structure within the enterprise, rather than issues relating to interconnecting enterprises and building a global directory.

Access into the Enterprise Directory

LDAP and X.500 are built on a common information model and have the same basic operations. There are also a number of proprietary directory protocols which have quite similar characteristics. Thus it is useful to consider a core enterprise directory based on the LDAP/X.500 information model and services, independent of any specific protocol. A key characteristic of a directory service, which will typically be provided by many directory servers, is that the directory provides a single enterprise view onto the directory data, and that the result of a query is independent of the server asked. Because of this 'location independence' an LDAP/X.500 enterprise directory can be modeled very simply:

There are three open protocols which can be used to access an LDAP/X.500 directory infrastructure, which are illustrated above. A typical enterprise directory will choose to mix and match these three protocols to suit its operational requirements and to give an appropriate choice of directory clients. The benefits of each of the open directory access protocols is described below.

LDAP

LDAP (Lightweight Directory Access Protocol) is a good choice for the following types of directory application accessing the enterprise directory:

• General purpose directory access tools for end users and system integration.
• Integration with applications requiring directory access. It is particularly suitable for this, because of the simplicity of the protocol and the API.

CLDAP

CLDAP (Connectionless LDAP) is a good choice for the following types of directory application accessing the enterprise directory:

• System processes requiring read access to low volumes of data. For these applications, CLDAP offers very high performance, because it does not require establishment of a connection (TCP or OSI). CLDAP is a good choice for applications such as messaging servers.

DAP

X.500 DAP is a good access protocol for the following types of directory application accessing the enterprise directory:

• General purpose directory access tools for end users and system integration.
• Applications which are integrated with OSI applications or an OSI environment.
• Applications that need signed operations, which is the only significant DAP feature not supported by LDAP. Signed operations are important in the case where strong authentication is needed and chaining is required. This might be the case for an organization using a firewall DSA, to provide directory connectivity across an organizational level boundary. The authentication could be needed either to verify the client to the server (e.g., to support access control) or to verify the (chained to) server to the client.

DAP vs LDAP

There are many types of application for which both LDAP and DAP are suitable. For users of applications, the choice will be made by the provider of the application (which might be to support both).

For companies building directory enabled products, the primary consideration will be market demand (from the market that the product addresses). The lower complexity of LDAP and the standard LDAP APIs will make it more attractive, particularly for simple applications, but this consideration is secondary to market demand. Performance of good implementations of both protocols is similar, and should not be a primary consideration.

Enterprise Requirements

All three of these directory access protocols have environments where their use is appropriate. An enterprise directory can easily be constructed to support any combination of these. An enterprise selecting a directory configuration should decide which of these access mechanisms is needed (or may be needed in the future) and select them as a part of the access protocol requirements. For most enterprises, support of all three protocols will give the most flexibility, and this is straightforward to procure.

The Structure of an Enterprise Directory

A typical enterprise will not wish to have all of its data stored in a single location, and for this reason an enterprise directory will be built using many servers. Even a small enterprise with a very centralized approach will need to have multiple servers for performance and resilience. A typical enterprise will have a two level structure of directory servers:

The core of an enterprise directory will be provided by a directory backbone. It is this 'backbone' which will be the focus of most of this white paper. In some cases, the backbone will comprise the entire enterprise directory. In other cases, there will be the need to have additional subsidiary directory servers. The reason that subsidiary directory servers are needed, and the approach to their integration is discussed in the next section.

The enterprise directory backbone is needed for a number of reasons. These include:

• Ensuring that there is genuine location transparency, so that a client's query will be resolved consistently. If this is not done, there will be various directory 'islands' within the enterprise.
• Allowing protocol transparency, so that when a client uses any of the open directory access protocols supported by the enterprise (LDAP, CLDAP, or DAP), that the query will be correctly resolved irrespective of the protocol set supported by a specific directory server.
• Ensuring transparent integration of subsidiary directory servers.
• Ensuring that data can be managed in a coherent and consistent manner across the enterprise.
• To provide a consistent approach to security, in particular to access control and authentication.
• To ensure an appropriate level of performance and robustness across the enterprise.

The way in which these requirements are met is discussed in the rest of this paper.

Subsidiary Directory Servers

Requirements

There are two basic strategies for deploying a directory with open access protocols:

• Deploy an open directory service, and then enter data or load it in from existing sources. This is utilizing the directory backbone.
• Add an open directory access protocol as a front end to an existing database or directory, and deploy this as a subsidiary directory server to connect it into the backbone.

Most of this paper considers choices in the context of the directory backbone. For services where a directory backbone approach can be used, it will lead to a more uniform and higher performance service. Because of this, use of the directory backbone is the preferable approach when it can be achieved. However, there are cases where subsidiary directory servers must be used. These include:

• Access to legacy databases.
• Access to legacy directories.
• Access to vendor proprietary directories, where the vendor chooses not to base its directory products on open protocols. There are many vendors that claim to have open directories, where they support open access (using X.500 DAP or LDAP) to a proprietary directory. The limitations of this semi-open approach will be made clear in the discussion on replication.

Integration of a subsidiary directory server can be achieved with either LDAP or X.500 DSP (Directory System Protocol). There are two benefits to use of LDAP to achieve this.

• The simplicity of LDAP will make the implementation easier.
• LDAP is defined so that it can be used as an access mechanism to any service (provided that the client is given a view which conforms to the LDAP specifications), whereas DSP is defined only as a mechanism to implement an X.500 directory.
• This, coupled with the broad acceptance of LDAP as an access protocol, make LDAP the most common choice to support subsidiary directory servers.

Integrating Subsidiary Directory Servers into the Backbone

Most enterprises will end up with a deployment where some data is held in the directory backbone and other data is held in subsidiary directory servers which can be accessed by LDAP. It is highly desirable to enable all of these servers to appear as a single integrated enterprise directory to the end user. To achieve this, many of the capabilities of the backbone are required, including:

• Protocol transparency. LDAP, X.500 DAP, and CLDAP clients should all be able to access all data.
• Data location transparency. All data needs to be integrated into a single Directory Information Tree (DIT), with all entries correctly accessible by name.

The subsidiary directory server is likely to support only a single access protocol (probably LDAP) and have limited capabilities to deal with 'knowledge' of other servers and replicated data in the enterprise directory. The server becomes a subsidiary directory server because it lacks the functionality for full backbone participation.

Where the subsidiary directory server supports X.500 DSP, it can be configured simply into an X.500 backbone. In the more common case where the subsidiary directory server supports LDAP, a backbone directory server will need to support 'LDAP Chaining', in order to connect in the subsidiary directory server. LDAP chaining means that the backbone directory server will contact the subsidiary directory server on behalf of the client making the original request. This gives the required transparency to the client, and protects the subsidiary directory server from the complexities of backbone operation.

The Backbone: Data Management

This section looks at issues relating to data management on the enterprise directory backbone, and how this can be achieved in a transparent and coherent manner.

Access Control

There is a need for a wide range of access rights to data in an enterprise directory. Often entries or items of data within entries (attributes) will need to have access restricted to specific users or groups of users. There is often need for sophisticated control of modification rights. A viable enterprise directory needs to have a coherent model of access control.

Administrative Control of Data

When managing a simple directory, considering each entry in isolation is fine. When handling larger volumes of data, it is often important to consider collections of entries and manage them together. This might be applied to subtrees or to more arbitrary collections. Some examples of the importance of this type of functionality:

• Often entries have common information (e.g., a shared telephone number). It is useful to manage this information in one place.
• Data in one part of the DIT may have a high degree of symmetry, and it will be useful to apply a generic access control to this data.
• An enterprise manager will wish to delegate some aspects of controlling data within the enterprise.

Configuration and Knowledge

When deploying a large enterprise directory, there will be a non-trivial configuration of many directory servers. For directory services, this configuration information is often referred to as 'knowledge'. The representation of this configuration information in the directory is important, as it gives the basis for a collection of directory servers to share this configuration information, which is vital to enable the coherent management of a unified service.

The X.500 Solution

X.500 provides high functionality standardized mechanisms to solve all of these administrative problems. These include:

• Access control functionality (including X.500 Basic Access Control and Simple Access Control).
• Management by use of X.500 Administrative Areas.
• Standards for representation of knowledge and configuration information.

The LDAP Approach

LDAP is an attractive access protocol, and a major part of this attraction is its simplicity. One element of this simplicity is that there is no function for administrative control of data, no standardized knowledge definitions, and no access control. Vendors of 'pure LDAP' directory servers are therefore forced to define proprietary solutions to address these requirements in order to build LDAP based directory services.

The Backbone: Replication

Replication Requirements

Experiments with directory services often make use of single servers. An operational directory service requires the replication of data in multiple servers for a number of reasons including:

• Ensuring data availability in the event of server failure.
• Providing local access to data in a distributed environment.
• Ensuring that master data is close to the administrators responsible for its control.
• Providing sufficient copies of the data to meet overall performance requirements, and to prevent overload of individual servers.

It is useful to consider the sorts of replication configurations than an enterprise might require. A common configuration will be to have all of the enterprise data mastered in a single server, with some number of replicas shadowed from this in a simple star configuration. This configuration will be appropriate for most organizations as a starting point and will be a good longer term solution for many small organizations. This simple and flexible configuration is illustrated below:

The basic replication configuration might be extended in a number of ways to meet more complex enterprise requirements:

• Adding further 'levels' to the star configuration, either to reduce load on the master server, or to optimize data flow to be aligned with the enterprise Intranet.
• Putting one or more levels of hierarchy into the replication. Effectively, units of the enterprise will be managed in the simple manner described above, with the top level organizational information connecting all of this together by use of multiple replication agreements. This would be appropriate for enterprises that have highly autonomous business units. The higher level of information is likely to be managed centrally and highly replicated.
• Structuring replication so that subtrees of data are mastered in a server local to the site where it is most frequently updated. This might be done for reasons of update performance, autonomy, or robustness. This could be achieved by an approach such as 2. However, it may well still be required that all of the enterprise data is contained in all directory servers. This would require significantly more complex control of the replication configuration. This would seem to be a useful configuration for an enterprise with many large and fairly independent sites. A large organization of this nature might have 100-1,000 such sites.
• Placing subsets of data into servers that have a specialized purpose (e.g., servers that support message routing will only need to hold data relevant to this purpose). This may be optimized by data replication configuration.

These configurations lead to more detailed requirements on replication function, which include:

• Flexible and straightforward to configure.
• Highly robust.
• Supports addition of new replicas.
• Deals with incremental changes, with high performance and low latency.
• Replication can be 'push' or 'pull'.
• Replication must be secure. Using replication to extract all of the data out of an organization's directory is a severe security threat.

Data Administration, Knowledge and Replication

Replication has an important tie-in to the data administration functions discussed above. If data is to be replicated, either by a replication protocol or by data caching, it is essential that the data administration is common to the servers. For example, if one server has a specific mechanism for controlling which users can access data, it only makes sense to replicate this data into servers which have the same access control mechanisms.

Because of this effect, the requirement for a uniform approach to data administration becomes much stronger, as it will be required in any environment where there is a need to replicate data between servers.

Replication

X.500 provides a standard replication mechanism for replication called DISP (Directory Information Shadowing Protocol). This is a high functionality replication protocol, which meets all of the major requirements of the scenarios described above. It is a sound and open mechanism for supporting the replication required in an enterprise directory.

Other Replication

Where LDAP is used as a front end onto an external database or directory, it is likely that any replication which is used will be provided by the back end. For example, an SQL database package might support replication across multiple servers and each of these servers can be independently accessed through LDAP.

Some vendors are choosing to use LDAP as a replication protocol. This is a technique where a server holding data knows where replicas of the data are held. When data is changed, it will update (by an incremental 'push' mechanism) the replica copies using LDAP to make the changes.

All of these techniques are fine for simple replication configurations, provided that all of the servers in the enterprise that need to share data follow the same replication techniques, and provided that the enterprise has only a subset of the replication requirements described here.

Why X.500 is the best choice for the Directory Backbone

If an enterprise is building a directory using only servers from a single vendor (and expecting to continue single vendor), an X.500 backbone will be a good choice because of the high functionality offered. There are other reasonable options, using vendor specific techniques to provide the service.

If an enterprise wishes to build its directory backbone using directory servers from multiple vendors, an X.500 backbone is the only viable option, as there are no other vendor independent solutions available.

Conclusions

The recommendations for deployment of an enterprise directory service are simple:

• Provide LDAP, CLDAP, and X.500 DAP access to the enterprise directory infrastructure, to enable the flexible selection of directory clients.
• Use X.500 as the enterprise directory backbone, because of the powerful and open functionality that it contains which are appropriate and useful for deployment of an enterprise directory.