Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.
Creative Commons
Isode's whitepapers are licenced under a Creative
Commons Licence.
Purpose
There are many situations that require large distributed directories using LDAP (Lightweight Directory Access Protocol) and/or X.500, such as Government, Military and Aviation. Organizations building these distributed directories will often be making use of Microsoft Active Directory (AD). AD provides a number of key functions in a Microsoft server network, which impact its use as part of a distributed directory. This paper explains these issues, and then looks at three different approaches to using AD in the context 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:
- 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.
- The directory is built with multiple servers (i.e., it is not a simple centralized directory).
- 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 9705.
- 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:
| Restriction | Notes |
|---|---|
| Name Form Restrictions | The top level of the DIT (Directory Information Tree) in AD is named in a manner that is compatible with Windows domain naming, and Internet domain name service. This means that the directory names use the DC (domain component) attribute type for top level naming. So an organization might be named: DC=XXXCorp, DC=COM Other name forms, such as the Country/Organization structure that is often used in LDAP and X.500 directories cannot be used. For example: Organization=XXXCorp, Country=US Cannot be used with AD. |
| Significant Attributes | AD is used to control key Windows resources and information. It makes use of some standard attributes to achieve this, and also defines a number of special attributes. These attributes are referred to as “significant”, as they control Windows functionality. These attributes have to be used and managed in the way that AD requires. |
| Special Syntaxes | AD defines a number of special attribute syntaxes, in order to support some NOS functionality, such as 64 bit integers. These syntaxes may not be understood by some LDAP clients and other directory servers. |
| Strong Authentication Mechanisms | AD’s preferred secure authentication mechanisms is SASL (Simple Authentication and Security Layer) with Kerberos authentication. AD does not support SASL EXTERNAL, and so strong authentication using X.509 (Public Key Infrastructure approach) is not possible |
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.
| Restriction | Notes |
|---|---|
| Top level naming | The top level of the DIT for the distributed directory
needs to be structured to allow or require the DC (domain component)
name form that AD uses (e.g. DC=XXXCorp, DC=COM). |
| Client Compatibility | LDAP clients that are to be used as part of the distributed directory should be able to connect to AD and deal with the AD schema extensions. |
| Client Authentication | Acceptable client authentication mechanisms must include a mechanism that is supported by AD. AD will only authenticate clients whose information is stored in AD. Anonymous access must be acceptable and configured for other clients, which should not attempt authenticated access to AD. |
| Distributed Operation | Because there is no common directory server to directory server communication, resolution of distributed operations must be handled by referrals. Chaining of queries between servers will not generally be possible. Use of high replication, the usual choice of military directory, is not possible as there is no standard replication protocol available. AD will need to be configured with external references, so that queries which cannot be resolved locally return appropriate continuation references to other servers that can resolve the query. Where LDAP clients cannot support referrals, use of a directory server that supports LDAP Chaning (where a query is chained using LDAP to a remote server) such as Isode’s M-Vault is a useful option. |
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.
