LDAP compliance involves a number of issues. LDAP is a protocol, but its specification also includes a directory schema and methods for extending its functionality through extensions and controls.
The following table compares the protocol features of the newest release of the LDAP server in NDS 8.2x with two previous releases of the LDAP server in NDS 8 version 8.1x and NDS version 7.xx.
Table 1-2 Protocol Compliance
Even though NDS version 7.xx is limited in its LDAP functionality, it complies with the LDAP v3 protocol specification because the LDAP server correctly responds to requests for unsupported features. NDS has increased its support of LDAP with each subsequent release.
For more information on LDAP and eDirectory see the NDK: LDAP and eDirectory Integration Integration Guide.
eDirectory and LDAP have had numerous differences in naming conventions, structural rules for containment, leaf versus containment classes, and supported syntaxes. Since NDS version 7.09, each release of NDS/eDirectory has extended its support of the LDAP schema.
For example, NDS and LDAP naming conventions for attribute and class definitions are quite different:
Each release of the LDAP server has made these differences less significant. The first release of the LDAP server mapped the LDAP class and attribute names to their corresponding NDS class and attribute definitions. In NDS 8 version 8.1x, if the schema name is a valid LDAP name, mapping is no longer required. Missing attributes or classes have been added to the NDS schema using LDAP naming conventions, and classes have been modified to include the new LDAP attributes. In NDS 8, the schema supports auxiliary classes, and service packs make the auxiliary class feature compatible with earlier versions of NDS.
eDirectory supports several LDAP extensions and controls, and handles unsupported controls according to the LDAP specifications. To determine supported extensions and controls query the server rootDSE.