X.500 Standard status
X.509 Related activities
How to be involved
Tutorial section 1
Tutorial section 2
Other PKI organizations
This whitepaper has been cross-posted from the Isode website.
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.
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.
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 (Lightweight Directory Access Protocol) is a good choice for the following types of directory application accessing the enterprise directory:
CLDAP (Connectionless LDAP) is a good choice for the following types of directory application accessing the enterprise directory:
X.500 DAP is a good access protocol for the following types of directory application accessing the enterprise directory:
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.
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.
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:
The way in which these requirements are met is discussed in the rest of this paper.
There are two basic strategies for deploying a directory with open access protocols:
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:
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.
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:
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.
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.
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.
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:
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.
X.500 provides high functionality standardized mechanisms to solve all of these administrative problems. These include:
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.
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:
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:
These configurations lead to more detailed requirements on replication function, which include:
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.
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.
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.
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.
The recommendations for deployment of an enterprise directory service are simple: