Distinguished Names and LDAPSearch#

Wildcards as part of a Distinguished Name are not supported and will NOT work.



DNs are stored in eDirectory as a local entry ID, so to resolve this, two searches would have to take place - first one to resolve every possible local EID for an object, and second, "n" searches to search for all matching DNs. This doesn't scale well for values of "n" that are even somewhat large.

Distinguished Names and IdM Events#

On referenced objects, there is no event when a Distinguished Name is renamed.


If a user is renamed, any groups he is a member of, there will NOT be an event on the groups. There will be an event on the user.

This is because DNs are stored in eDirectory as a local entry ID reference.

Matching Rules#

eDirectory has no matching rules.

Edirectory has a loose analogy of matching rules that emulate matching rules form other vendors.

Not Defined By Novell#

The only references we can find are on occasion, there will be a short blurb in the syntax definition that provides a meager explanation of how matching occurs on attributes with syntax.

Not Defined in Schema#

And, matching rules are NOT defined within the schema.

Subtree Searches (Prior to EDirectory 8.8)#

There are three primary elements in a directory client's search criteria:
  • Base of the search
  • Scope of the search
  • Search filter
The scope parameter can be base, one level, or sub (indicating a subtree). The combination of base of the search and the scope parameters serve to constrain the search to a certain area of the DIT (Directory Information Tree). See the eDirectory Administration Guide (http://www.novell.com/documentation/edir88/index.html) for a more exhaustive treatment of this.

A frequent complaint by some eDirectory customers concerns subtree search performance of eDirectory. For a large tree with a deeply nested tree structure, eDirectory subtree search performance remains flat, irrespective of where the base of the search is located. So, a client searching a subtree with a small number of entries below it is comparable in performance to a client searching a subtree with a large number of entries. The client is not ensured of a faster search because the subtree is smaller. However, a one-level search does display performance characteristics that are a function of the number of entries below the base of the search.

The reason for the eDirectory Subtree Search Problem#

The above problem manifests itself because of how the subtree search over LDAP or NDAP is translated into a query to the database layer of eDirectory. Let's examine this with an example: an LDAP client sends a search to eDirectory with parameters as follows:
  • base of ou=engineering,ou=directory,o=novell
  • search filter of cn=*
  • scope of subtree
This search will translate into a query to the database with presence assertion on the CN attribute. As you can see, only the filter part of the search criteria is translated to database query. The other part of the client's search criteria - the base of the search and the scope - is left out of the query passed to the database layer. Thus in our example, each entry in the database with a CN attribute is returned by the database layer in response to the query.

These entries are further processed by the upper directory service layer, called the DS Agent, to see if they meet the base and scope criteria. To do this, the DS Agent traverses up the hierarchy from the entry until a) the base of the search is reached (in which case the entry passes the criteria and is added to the search result set to be sent back to the client), or

b) until the root entry of DIT is reached (in which case the entry fails the criteria and is left out of the search result set).

There are two problems with this approach:

  1. . The determination of the base and scope criteria outside of the database layer implies that this computation is devoid of any use of database index, and thus is slower.
  2. . For a query such as CN=* (or for that matter any other that matches a large number of objects), the database query is likely to throw a lot more entries than what may end up in the final search result set, depending on the base and scope criteria.

A Single-Level Search#

In contrast, a single-level search scope does not suffer from the same problem as a subtree scope. So, if our example uses a one-level scope search, it will be translated into a database query with a presence assertion on CN, "anded" with an value assertion on the Parent ID attribute, where the value being the entry ID of the base of the search. The Parent ID is an indexed operational attribute on each entry. It stores the entry ID (a 32-bit integer value which uniquely identifies each entry in the database) of the parent of an entry. Since the entire search criteria is passed to the database, which in turn evaluates entries using the Parent ID index, the computation of the search result set is done entirely in the database layer. This means it is performed much faster than the subtree search.

See How it is fixed in Subtree Searches in eDirectory 8.8

Syntax Definitions are Vague#

Generally Novell has done a vary poor job in documenting details of eDirectory for any development work.

A particular example is the complete lack of definitions about attributes as to the design usage. As one of MANY examples, is the DirXML-EntitlementRef attribute.

The DirXML-EntitlementRef attribute is not defined anywhere we could find other than references to the Entitlement DTD. Further the DirXML-EntitlementRef is defined in the schema as being of syntax type "path" yet fails follow Novell's own definition of the path syntax.

The DirXML-EntitlementRef attribute shows in the schema to be of type 2.16.840.1.113719. which shows as "path", Novell shows this component name should be path and not path.xml. I suppose that the component is really based on the component number and not the name. This activity makes programmatic deciphering of the attributes really hard as "path" is used in some attributes and "path.xml" {as in|DirXML-EntitlementRef] is used on others with no programmatic method to determine which it which.

Poor Support for Controls#

eDirectory has poor if any support for the industry standard in regards to LDAP controls. The biggest one is the Virtual List View And Server Side Sort Controls