Front cover - IBM Redbooks

Define a schema
The directory schema has three main components. They are:
► Object classes: This refers to the type of object being stored. An object may
use multiple object classes providing the classes are not mutually exclusive.
We discussed this type of component in more detail in 8.3.2, “Object classes”
on page 316.
► Attributes: These are the record “fields” of data for an object. For example,
an OrganizationPerson object may have a “Title” attribute value. In this case,
the Title attribute is optional. Attributes can also be mandatory for a given
object class, for example a Person object must have CN (common name) and
SN (surname) attribute values. We discussed this type of component in more
detail in 8.3.3, “Attributes” on page 320.
► Directory Information Tree (DIT): LDAP directory data uses a hierarchical
tree organizational structure. As with any hierarchy, there is at least one root,
with the potential for multiple branches with leaves, also known as end nodes.
Each node in the tree, the root itself, branch points and leaves, is a
Distinguished Name, DN. From the root, you define branches of the tree,
which are either containers (for example, CN=users), or organizational units
(OU=). Note that a single LDAP directory can have multiple roots with
different access lists and tree structures beneath them. The actual feasibility
of this is dependent on the scalability of the LDAP directory. Typically, a
single root is used for all user objects to keep administration as simple as
possible.
Although the DIT is not technically part of the “schema”, the hierarchical tree
structure has a direct relationship to every object's Distinguished Name (DN).
The DN is the fully qualified hierarchical name. For example, a DN might be
“CN=john q public,OU=sales,O=acme,C=us,” or another typical form is
“UID=jsmith4,CN=users,DC=acme,DC=com.” In the first example, the tree
follows a more traditional X.500 structure, with a country “C=US” as the root. The
second example illustrates a root that follows DNS naming conventions with
domain components “DC=acme, DC=com” as the root. DNs must be unique, so
“flatter” trees dictate the use of unique identifiers, such as in the second
example, where the UID (user ID) is used instead of the CN (common name).
Generally, our experience has been that flatter trees, despite the burden of
needing methods to generate unique identifiers or names, are ultimately easier
to administer. But there is a trade-off in large organizations (over 10,000 users).
A flat tree structure in a large organization requires a non-intuitive user naming
scheme that often forces the use of additional identifying attributes. For example,
consider if there are two unique users such as the following:
DN= uid=bhinkle,cn=users,dc=acme,dc=com
cn=Brendan C Hinkle
mail=b_c_hinkle@acme.com
Chapter 8. Directory strategies 345