Using Active Directory as Part of a Distributed Directory

What do we mean by Distributed Directory?

This paper is looking at some specific types of “Distributed Directory”. While this covers a range of markets and applications, this paper is looking at directories which share the following characteristics:

1. The directory is based on the ITU (International Telecommunications Union) X.500 specification, or on the Internet Standard LDAP (Lightweight Directory Access Protocol) that uses the X.500 data model.
2. The directory is built with multiple servers (i.e., it is not a simple centralized directory).
3. Multiple organizations are providing data that is used in the directory, and may store data in different servers.

Some examples of distributed directories that have these characteristics are:

• A military directory, following the ACP 133 standard for military directories.
• An ATN (Aeronautical Telecommunications Network) directory following ICAO (International Civil Aviation Organization) standard DOC 9880.
• The directory supporting the US Federal PKI that spans multiple government organizations.

The term “distributed directory” is used in this paper to mean a directory of the characteristics described here.

Is AD LDAP Conformant?

The question “Is AD LDAP Conformant” is not as simple as it seems. Answering this question will show the key issues in using AD as part of distributed directory.

The first way to interpret this question is “Can a conformant LDAP client be used to access AD”. With this interpretation, the answer is a clear “yes”.

A second interpretation of the question is “Can AD be used to build an LDAP directory, operating according to an externally specified design that is LDAP conformant.” The answer to this question is “no”, due to constraints in AD that are described below. The reason that these constraints exist is that AD has a key function as a NOS (Network Operating System) directory to support information about Windows Servers, file stores, printers and other resources. This is complex and sophisticated functionality. As a consequence of this NOS role, a very large number of organizations run AD.

Although AD can work as a general purpose directory, its detailed functionality and management is often directly related to the NOS role.

The key constraints on AD are primarily as a consequence of its NOS role. The most important ones are:

These restrictions may conflict with requirements of the distributed directory, and this is why use of AD in the context of a distributed directory may cause problems.

What about ADAM?

ADAM (Active Directory Application Mode) is essentially AD, but not acting as a NOS directory. ADAM does not have the schema restrictions of AD. ADAM is in effect a general purpose LDAP directory based on AD.

Most users of AD are running it to support NOS functionality, and so ADAM is not a useful alternative.

If you need a general purpose LDAP directory, ADAM could be considered as an alternative to a more specialized product such as Isode’s M-Vault. ADAM may be attractive in some situations, for example because of the common management interfaces with AD. In other situations, the complexity that comes as a consequence of the NOS capabilities would be unnecessary baggage.

X.500

Where a single directory server is required, it is most likely that the requirement will be specified as LDAP. LDAP is a very widely supported open standard for directory access. Where multiple servers are required, X.500 may also be specified. The reason for this is that X.500 is the only open standard specification for a complete distributed directory including:

• Directory Replication.
• Directory Access Control.
• Directory Server to Directory Server requests.
• Administrative framework

Some directories mandate X.500. This includes the Military ACP 133 Directory and the Aeronautical ATN Directory, both of which are based on X.500. In other situations, particularly where replication is needed, X.500 is a sensible approach even if not mandated.

AD does not support the X.500 protocols or procedures, and so is not an option where X.500 is required.

Solution 1: Keep AD Separate

The first and simplest solution is to keep AD and the distributed directory separate. In this approach, AD is focused primarily on its role as a NOS directory. Information which does not need to be in AD is simply held in the distributed directory.

This approach will be ideal in situations where there is little or no information that has to be held in both AD and the distributed directory. Where there is overlap, for example because enterprise users need to have entries in both directories, this approach is less satisfactory as it would lead to a requirement to manage information in two places.

Because is it is so straightforward to run AD separately from the distributed directory, it is recommended that this approach is considered carefully.

Solution 2: Align Total System to AD

The second approach is to specify the distributed directory in a way that is in line with AD constraints, and so that AD can participate as a part of the distributed directory. The following table summarizes the constraints that need to be applied to the total directory.

If these constraints are acceptable, building a distributed directory with AD as an element of this is a good approach.

Solution 3: Synchronization

In some situations, the constraints of solution 2 will rule out this approach, and solution 1 will be undesirable because of duplicated data management. In this case a third approach of data synchronization is possible, this approach is illustrated below.

The first thing that can be seen from this diagram is that one way synchronization is used. Essentially, AD is used to master data that is local to the organization running AD. This data is passed into the distributed directory and held in one of the servers (here shown as Isode M-Vault) that is operating as a part of the distributed directory.

The tool connecting AD and M-Vault needs to:

• Extract data from AD and pass it to M-Vault.
• Note changes in AD, and efficiently transfer these over.
• Change the AD name structure to the one used in the distributed directory.
• Filter out AD attributes that are not needed (and may cause confusion) in the distributed directory.

There are a number of products that could be used for Directory Synchronization, including:

• The ExpresSync product from Isode partner MaXware. ExpresSync meets the requirements, and provides a low cost effective solution for this simple type of directory synchronization.
• MIIS (Microsoft Identity Integration Server) is a natural choice to use with AD, as it is from the same vendor.

A consequence of this structure is that data from AD held in M-Vault is treated as master data. This means that attributes needed for the distributed directory that are not needed in AD, may be added directly to M-Vault. A particularly important example of an attribute likely to require this is Certificate and other PKI related attributes. The reason for this is that Certificates reference directory distinguished names. This means that Certificates must be built and registered with appropriate names. Although directory synchronization can deal with basic name form changes and naming attributes such as “see Also”, the names in Certificates are signed and cannot be changed.

This means that where this approach is used for a directory that is used to support PKI, certificates will be published to M-Vault, rather than going through AD. This is illustrated below:

Conclusions

This paper has looked at the difficulties associated with integrating AD into a distributed directory. Three approaches to solving these problems are set out. The best choice will be dependent on the details of the system that is being put together.