You can use LDAP to implement an application that works only on a specific type of LDAP server with a specific type of directory. No two LDAP servers and their directories function exactly alike. For example, the LDAP servers available from Novell, Netscape, IBM, and Oracle all function slightly differently. If you want your application to be generic and work with most LDAP servers and their directories, you need to be aware of differences and the causes of those differences.
The following guidelines are not a definitive list of the differences between Novell and other implementations of an LDAP server and directory. These are intended to help make you code your application so that it will work on more than one directory. The definitive list will come as you test your application against multiple directories. Our suggestions are divided into the following topics:
No two directory schemas contain the same class and attribute definitions. Be aware of the following schema operations.
The application should first read the schema definition before trying to use an attribute. For example, some non-standard LDAP attributes have not been added to the eDirectory schema. Therefore, if you code your application to expect a particular attribute, the application could fail.
In some schemas, the Person-type class definitions allows an entry to be a container object. In the eDirectory schema, person-type definitions allow only leaf entries. The schema specification for LDAP v3 includes support for auxiliary classes. If you select to add attributes to a Person-type entry through an auxiliary class rather than as objects subordinate to the Person class, the application can work with both LDAP servers.
If you define a class that references specific attributes, eDirectory verifies that all referenced attributes exist before it allows the class to be added. Therefore, when extending the schema, you must add the attributes before adding the class. Other directories perform no referential validation. To accommodate both types of directories, always add attribute definitions before adding class definitions.
LDAP servers have different rules for processing data. Be aware of the following.
The Novell LDAP server uses eDirectory security and supports eDirectory validity and integrity checking. eDirectory verifies all attribute values that are DNs, a feature that increases the security and integrity of the directory. For example, when the DN of a user is added to a group membership list, eDirectory verifies that this user exists in the directory and creates a reference from the user to the group. This reference is used to remove the user from the group when the user is deleted from the directory. The delete operation removes all references to that user. If the system administrator creates another user with the same name, there is no residual information from the old user for the new user to connect with.
Some directories do not do this type of verification, and without the implementation of a reference, the user can be deleted from the directory while the user's name remains in a group membership list. If the system administrator fails to manually remove the user from the group list and then later adds another user with the same name, that new user becomes a member of the group the old user belonged to, regardless of the system administrator's intentions.
In directories that do not verify DNs, users and groups can be added to the directory in any order. You can add the groups with their membership lists and then the users that are associated with the groups. eDirectory will not allow this. The users must be added first, and then the groups with their membership lists. You can make your application work with both types of directories if you order the operation to accommodate eDirectory integrity checking.
Novell has the overall philosophy of restricting rights and enforcing those restrictions. According to the LDAP specifications, clients should have an LDAP v3 bind in order to read the root DSE object. Novell's LDAP server enforces this restriction. Not all LDAP servers enforce this restriction. To make your application work with most LDAP servers, you need to request an LDAP v3 bind when reading the root DSE.
LDAP directories vary in structure and structure rules. Be aware of the following.
Some LDAP servers access a directory with a flat database structure on a single computer. Novell's LDAP server accesses eDirectory, which has a hierarchical database that is distributed on multiple computers.
In maintaining the hierarchical structure, eDirectory enforces
Containment rules that determine which types of objects another object can contain
Naming rules that determine which attributes can be used to name objects
Some LDAP directories, which claim to have containment and naming rules, do not enforce these rules. Therefore, do not build your application with the assumption that a certain entry must use a specific attribute for naming or with the assumption that certain entries can be located anywhere in a directory or only in one type of container. Applications built with such assumptions will not work with all LDAP directories.
eDirectory is a distributed database, which means that all available data is not usually local to an LDAP server. In most eDirectory trees, the data is stored in replicas on multiple servers. Therefore, the data that is local is the data that is in the replicas stored on the LDAP server, and the rest of the data is remote.
Because eDirectory has been designed to be distributed and to hide that fact from most end users, the LDAP server can be configured to search automatically for the data in remote locations. Such a search takes longer than a local search that returns referrals. To remove the impression that Novell's LDAP server is slow, the default configuration for the LDAP server in NDS eDirectory has been changed. It is now configured as most other LDAP servers, to return a referral when the data isn't local. Your application should be designed to handle referrals.
LDAP controls have not been implemented alike. See the documentation for each LDAP server you want your application to run on for a list of those restrictions.
LDAP extensions are specific to an LDAP server. For example, each LDAP server in an eDirectory could support different extensions. LDAP servers from different vendors will support different extensions. Currently, all LDAP extensions are in a draft state with the IETF and none has had the time to move from proposal to acceptance as a standard. Novell is proposing its naming context (partition) extensions to IETF.