Conformance and Interoperability

Interoperability Tests

Unfortunately, conformance to a standard is no guarantee that two different implementations will inter-operate with each other. In practice, standards suffer from errata or wordings that can be interpreted in different ways.^10.1

The Open Group Directory Interoperability Forum^10.2 holds the annual DirConnect conference where directory vendors come together to test the interoperability of their products. To provide some guidance for these tests, the Basic LDAPv3 Interoperability Test Suite (BLITS)^10.3 is being used. The Open Group also offers the The Open Brand for LDAP 2000 certificate. This certificate is awarded to directory servers, which pass the VSLDAP [89] test suite.

Another implementation of BLITS is available from Public Works and Government Services of Canada^10.4. This Test Suite Utility (TSU) implements a subset of BLITS version 2.3 and additionally, the EuroSInet interoperability test for LDAPv2 [11] and X.500 (93) [10] are supported.

A subset of BLITS has also been used in compiling the overview presented in the next chapter.

Supported features in DSAs

The tables (Figure and Figure ) on the following two pages show which features the directory servers that have been introduced in cha:linux, and support.

Figure: Directory Servers, part 1

[IMAGE png]

Figure: Directory Servers, part 2

[IMAGE png]

Support for standard schema items

To evaluate how the different directory servers support the schema items defined for X.500 [44] and their application in LDAP [92], a migration of the AMBIX^10.5 data set was attempted. The data is currently mastered in a slapd from the University of Michigan LDAP 3.3 distribution, which only supports LDAPv2 and does only minimal verification of attribute syntaxes.^10.6 Therefore, the data had to be cleaned up first before it could be imported to an LDAPv3 compliant server. All entries and attributes that did not match the following schema items were removed to find a common ground. To structure the DIT, ``country'', ``locality'', ``organization'' and ``organizationalUnit'' as well as the auxiliary object class ``labeledUriObject'' were used. All entries referring to person have been modified to fit the ``inetOrgPerson'' object class [86]. Where non-ASCII characters appeared, the attribute value has been converted to the UTF-8 encoding as required by LDAPv3. Additionally, German Umlauts, which had been converted to the expanded representation, have been converted back to their canonical form for most non-ambiguous cases, e.g. from ``Universitaet'' to ``Universität''.

An initial attempt to load this data into eDirectory resulted in a large number of errors. Organizational units in Germany tend to have names, which are quite long. However, [44, Annex C] specifies that values of the ``ou'' attribute may at most have 64 characters. The same problems exist for the ``businessCategory'' attribute, whose length restriction of 128 characters could also be easily violated. eDirectory and Active Directory strictly uphold these restrictions. A manual relaxation is not possible. SecureWay Directory limits ``ou'' to 128 characters.<sup>10.7</sup> To allow further testing, all organizations and organizational units that did not meet the length restrictions were removed along with any ``person'' entries stored below them. While such a procedure is acceptable for a test, the need to include these organizations would preclude the use of Active Directory or eDirectory as a directory server for AMBIX.

Additionally, the following directory server specific problems were encountered:

Active Directory

In Active Directory many of the standard attributes were redefined to be single-valued instead of multi-valued. This included ``commonName'', ``givenName'', ``telephoneNumber'' and ``mail'', common attributes that often do have multiple values. In addition, if a multi-valued attribute is used to name an entry, the value used in the RDN has to appear before any other value of the same attribute.

Active Directory does not include the ``inetOrgPerson'' object class by default. Instead, the ``contact'' object class is intended to be used. However, a ``contact'' entry was not allowed below an ``organization'' or ``organizationalUnit'' entry. The containment rules for these object classes were therefore changed. Furthermore, ``locality'' was added to the possible superiors of ``organization''.

As Active Directory only supports auxiliary object classes by binding them to a structural object class. The ``labeledUri'' attribute was therefore added to the ``locality'', ``o'', ``ou'' and ``contact'' attributes. ``businessCategory'', which is an attribute of ``inetOrgPerson'' was also added to ``contact.

eDirectory

To allow ``inetOrgPerson'' entries to be added below a ``locality'' entry, the schema had to be modified. Novell offers a downloadable file, which contains schema extensions and mapping changes to implement the ``inetOrgPerson'' object class separate from the NDS ``user'' object class.^10.8 This file also makes the required changes to the containment rules.

SASL GSSAPI

A special interest during this thesis has been taken in the interoperability of the SASL GSSAPI mechanism for Kerberos (GSS-KRB5). The following products with support for this feature were identified:

Windows 2000. GSS-KRB5 is supported in Active Directory and the client library.

Windows 2000 Kerberos interoperability tools for Unix [66]. A GSS-KRB5 library is provided in source code. It requires the source code release of the Netscape LDAP C SDK (Mozilla) and MIT Kerberos 1.1 to build.

OpenLDAP. GSS-KRB5 is supported in the directory server and in client library with the help of the Cyrus-SASL library and a Kerberos 5 implementation (MIT or Heimdal).

SecureWay Directory. GSS-KRB5 is supported in the directory server and in client library (Windows platform only).

JNDI. The GSS-KRB5 mechanism^10.9 is implemented using the JCSI cryptographic toolkit^10.10.

Based on the GSS-KRB5 mechanism for JNDI, a SASL mechanism that works with Netscape Directory SDK for Java was implemented in the frame of this thesis.

Figure: LDAP GSSAPI Interoperability Matrix

[IMAGE png]

Figure shows the results from the interoperability tests conducted during this thesis. The following problems were identified:^10.11

(113)

Active Directory returned an empty serverSaslCreds^10.12 string instead of omitting this optional element. This was unusual but was not a direct violation of the protocol. A patch for OpenLDAP was developed in the frame of this thesis and submitted for inclusion.^10.13

(114)

Active Directory disregarded the client's maximum buffer size. This would becomes a problem, if security layers were negotiated and large result sets were returned. An workaround would to increase the client's maximum buffer size.

(115)

The Cyrus-SASL library employed by OpenLDAP had the maximum buffer size values hard coded to 0x0FFFFF. A patch has been proposed to the Cyrus-SASL mailing list.^10.14

(116)

By default, the Windows 2000 client library for LDAP uses the GSS-SPNEGO [2] SASL mechanism to negotiate the GSSAPI mechanism for use. However, it generated an incorrect encoding of the mechanism OID for GSS-KRB5. This problem can be circumvented by using ldap_set_option to set the preferred SASL mechanism to GSSAPI.

(117)

[93] specifieds that the SASL service name for LDAP is ldap, i.e. in lower-case. The respective Kerberos principal should therefore be ldap/host.domain@REALM. While Active Directory ignores case, the Windows 2000 client library as well as the SecureWay server and the client library create and accept only the upper-case form LDAP/host.domain@REALM.

By patching LDAP_PLUGIN_IBM_GSSKRB.DLL the SecureWay client could be modified to use the lower-case form. At an offset of 0x3F55 LDAP@ had to be changed to ldap@.

(118)

Due to a bug in the Java environment for Windows^10.15, no security layers were supported.

(119)

The GSSAPI security layer was not supported in SecureWay Directory. Connections were not encrypted.

(120)

Additionally to an external security layer provided by SSL or TLS, OpenLDAP tried to establish a SASL security layer. Active Directory claims to support this but actually does not. The connection therefore stalled after the security layer was negotiated. A workaround would have been to set the maximum SASL security strength factor to zero. (Use -O maxssf=0 for the OpenLDAP command-line tools.)