1.2 LDAP and eDirectory Terminology

The following sections describe some of the terminology and conceptual differences between LDAP and eDirectory:

1.2.1 Objects and Entries, Attributes and Properties

In LDAP documentation, an entry consistently means a record in the directory database. In eDirectory documentation, such a record is fairly consistently called an object. Since object becomes ambiguous when describing object-oriented programming languages, eDirectory developer documentation is beginning to use the LDAP term, entries. However, some functions, attribute names, and class names use object as part of the name. Novell product documentation for eDirectory utilities and applications continue to use the eDirectory term, objects.

In most directory documentation, attributes refer to the fields of a record. LDAP and X.500 conform to this standard. However, a lot of LDAP documentation also uses the word attribute to refer to the attribute's value. eDirectory programming documentation uses attribute. However, Novell product documentation for eDirectory utilities and applications use the term properties to describe fields in a record. The following table highlights some of these differences:

Table 1-1 Different Terminologies

LDAP Term

eDirectory Developer Term

eDirectory Product Term

Meaning

Entry

Both Object and Entry

Object

A record in a database

Attribute

Attribute

Property

A field in a database.

The value of the field.

1.2.2 Naming Conventions

Distinguished Names: eDirectory and LDAP support the same character set for entry names and their distinguished names. However, eDirectory supports a number of styles for rendering distinguished names. For example, a DN for an eDirectory function can:

  • Be typeful or typeless

    • CN=Kim.OU=Eng.O=Novell or Kim.Eng.Novell
  • Contain dots or slashes as the delimiter.

  • Use Unicode or the code-page character set of the computer

LDAP supports one convention: typeful names with a comma delimiter and code-page characters.

  • "CN=Kim, OU=Eng, O=Novell"

When using LDAP to access eDirectory, distinguished names must always be typeful and in LDAP format.

Schema Names: eDirectory and LDAP support different character sets for object class definitions and attribute definitions. For more information, see Schema Naming Rules.

1.2.3 LDAP Naming Contexts and eDirectory Partitions

NOTE:The naming context terminology is now obsolete.

In LDAP, a naming context is the same thing as an eDirectory partition. Just as an eDirectory partition is a branch of the eDirectory tree with only one parent, an LDAP naming context specifies a branch of a hierarchical tree. The following figure illustrates a simple hierarchical tree with three naming contexts ("O=Novell"; "OU=Engineering, O=Novell"; and "OU=Marketing, O=Novell").

Illustrates a simple hierarchical tree with three naming contexts.

Just as with eDirectory partitions, the naming context is named by the distinguished name of the root container.

1.2.4 Access Control and Effective Rights

Access control determines who has rights to entry information in a directory. In an eDirectory tree, every entry has an ACL (access control list) attribute which contains the explicit trustee assignments that have been made to the entry and its attributes. In addition, eDirectory allows rights to be inherited, so that an assignment in a parent container can allow additional trustees to have access to an entry. Functions that calculate effective rights gather information from these parent containers as well as from the ACL attribute. LDAP queries for eDirectory effective rights return the explicit assignments as well as the inherited rights. Directories that do not allow the inheritance of rights implement the functions to return only explicit trustee assignments.

1.2.5 Containment in Flat and Hierarchical Directories

Flat directories allow an entry to be added without specifying a location. Hierarchical directories require a location to be specified, and the purpose of the distinguished name is to fully describe the location of the entry. However, not all hierarchical directories have rules about where entries can be located. Many directories, such as eDirectory, require a location and enforce rules about where classes of entries can be located in the directory. For example, user or inetOrgPerson entries cannot be created in a Country container. Directories without such rules allow entries to be created any where in the tree. Sometimes these directories give the appearance of hierarchy, but in reality place all entries in flat database with a link to the entry's assigned parent.