Directory Structure "Novell NetWare"

Directory Structure
Directories like Novell’s that use the X.500 standard are hierarchical in nature and use a structure called the Directory Information Tree (DIT). In a DIT, the top level of the structure is called the [Root], which leads to the fact that the DIT is commonly referred to as an inverted tree. Making up the structure below the [Root] are intermediate objects and leaf objects.

NOTE:

Leaf objects are also called terminating objects because they are at the “ends” of the tree.

To easily find objects in the Directory, it must be further organized through the use of intermediate objects. They can be likened to alphabetized subsections of a telephone book (A, B, C, and so on).
Leaf objects represent resources in your organization (such as people, devices, applications, services, and so on) and can be likened to each name in a telephone book (Smith, Chang,
Moreau, and so on).

     Each object in the tree has attributes, which are properties that define the object. Information stored in an attribute is called a value. An example of an attribute in a telephone book is phone
number, and the value is the number itself. Objects can have many different attributes.
     Each object (depending on its type) can be located only in certain places within the DIT.
Labels are used to identify object types and thus their possible locations in the tree. Each label is a one- or two-character abbreviation of the object type or of an object attribute. Each object is also graphically represented in the tree. A Leaf Object’s graphical representation varies depending on the type of Leaf Object (for example, user, printer, and application).
Object types, where in the tree an object is allowed to reside, and object attributes follow rules called the schema.
      Table 5.3 describes each of the possible object labels in an NDS tree, the associated object type, and the possible location of the object in the tree.

TABLE 5 . 3 Labels, Object Types, and Object Locations in the Tree

When accessing a particular object, you must understand the idea of context. An object’s context is its exact location within the tree, taking into account all of the containers that it is in. For example, if a user, Connie, was in the sales organizational unit, which in turn was in the Acme organization, the user object Connie would have the context of

OU=SALES.O=ACME

Because it has the OU= and O= labels, this name is known as a typefull context. This type of name is used when there must be no doubt about the type of container that exists at a particular level.

In addition, Connie’s typefull distinguished name (the name of an object plus its context) would be

.CN=CONNIE.OU=SALES.O=ACME.

NOTE:

Contexts and names can also be used without their container labels, like so: SALES.ACME (for a context) .CONNIE.SALES.ACME (for an object’s distinguished name)

This is known as a typeless context and is used most often because it’s easier to remember.