> developer > dnu > courses > beginning eDirectory page 21

eDirectory for the Beginner

February 2002

DeveloperNet University Course

Reader Rating    from ratings

eDirectory Concepts

Network resources, such as users, printers, and servers, are represented in the directory as objects. Each object has data associated with it- a property or attribute. These resource objects are either container or leaf objects.

Container and Leaf Objects

Objects like an Organization (O) or an Organizational Unit (OU) are container object- they can contain other objects. Objects like a User or a Printer are leaf objects, they cannot hold other objects.

Figure 13: Directory representaion showing container and leaf objects.

Some required objects, like the Root and O are created by NDS upon installation. The installer is prompted for this information. Some of the commonly found objects are listed below.

Root Object.  The name of the Root object is the name of the tree, ex. juanTwo_tree. The name of the tree is broadcast on the network, hence, the name of your tree must be unique. After creation, the name can only be changed with the DSMerge utility.

Organization Object.  Need to have at least one you can have more than one, but it is not really recommended (an OU should be able to take care of any need for 2 Os). Most people name the object after their company name, ex. o=novell.

Organizational Unit Object.  Objects that represent organizational structures or workgroups under your organization, ex. ou=engineering.o=novell, ou=hr.o=novell.

User Object.  One user object is created upon installation- the administrator object named admin. The installer is prompted for a password for this object. All rights to the tree are given to the object by default.

Organizational Role Object.  A role or position. Users assigned to this position have whatever rights are assigned to the position. If a user is removed from the object, those rights are revoked from the user.

Group Object.  A set of users. Manage rights as a group instead of individually. This is a great way to grant rights to a user.

Print Server, Printer, Queue Objects.  These objects represent the print server, the printer and the print queue that holds or does the print jobs.

Unknown Objects.  An object created by the server who's class is undefined in the schema, one of the mandatory attributes has been lost, or may be temporarily unknown if the tree is synchronizing.

Hierarchy and Inheritance

An Object and its Attributes.  NDS objects have attributes associated with them. These attributes are defined by the object's class. Object classes either have attributes that are directly associated with them, or they can inherit attributes from another class. For instance, when you create new classes, you don't have to directly associate all of the attributes the class needs to the class. Instead, you can designate a super class that hold the attributes the class needs. The new class will then inherit the attributes that are assigned to the designated super class and to all of its super classes. Super Classes pass attributes and other characteristics on to other classes.

Understanding inheritance and hierarchy comes in handy when extending the schema.

The Top Class.  The schema inheritance starts with the "Top" class. The Top class is a pre-defined class in the schema, and it's named "Top." All NDS object classes inherit characteristics from the Top class. The Top class passes one mandatory attribute to all the other classes beneath it: the Object Class. This means that all eDirectory classes will automatically have an Object Class attribute.

In addition, the Top class passes several optional attributes to all NDS classes, such as: ACL (Access Control List), Back Links, Last Referenced Time, Obituary, Used By, as well as other attributes. Basically, all object classes inherit from the Top class the ability to hold values that eDirectory needs to be able to authenticate and synchronize the object.

The Top class also defines a default ACL template that all object classes inherit. An Access Control List defines the access rights that objects have to each other. The default ACL provides only enough access rights to allow objects to be supervised by the object that created them. When you define an object, you can either use the default ACL that the object inherits from the Top class, or you can modify the ACL to fit your object's needs.

Types of Classes

Effective and non-Effective.  For inheritance purposes, the eDirectory schema defines two basic types of classes: effective and non-effective. You can create objects only from effective classes, while non-effective classes exist to provide inheritance. However, you can create other classes from non-effective classes. For example, Figure 14 shows the inheritance of the Printer class.

Figure 14: The inheritance fo the Printer class.

Auxiliary Class.  eDirectory includes a third type of class, called Auxiliary class. With the Auxiliary class, you can create a class definition, label it as auxiliary, and assign that class to a sub-set of objects. For example, suppose you want some of your users, but not all of them, to have certain rights to a database. You can create new attributes to give the rights to these users. However, if you assign this attribute to the User object class, all of your User objects will get the attribute.

Name	Base Class and Attributes	Auxiliary Class and Attributes
Kim	User Account Balance, Last Login Time, Password Required, etc.	Pager User Pager Number, Pager Codes, Pager Is Alphanumeric
Chris	User Account Balance, Last Login Time, Password Required, etc.	Pager User Pager Number, Pager Codes, Pager Is Alphanumeric
Lynn	User Account Balance, Last Login Time, Password Required, etc.
Terry	User Account Balance, Last Login Time, Password Required, etc.

Kim switches job assignments with Lynn and gives Lynn the pager. You remove the Pager User class from Kim and all the Pager User attributes are deleted from Kim. You then add the Pager User class to Lynn who gains the attributes required for pagers, enabling you to add the appropriate values. The objects would then have the following classes and attributes.

Name	Base Class and Attributes	Auxiliary Class and Attributes
Kim	User Account Balance, Last Login Time, Password Required, etc.
Chris	User Account Balance, Last Login Time, Password Required, etc.	Pager User Pager Number, Pager Codes, Pager Is Alphanumeric
Lynn	User Account Balance, Last Login Time, Password Required, etc.	Pager User Pager Number, Pager Codes, Pager Is Alphanumeric
Terry	User Account Balance, Last Login Time, Password Required, etc.

Partitions

NDS is a distributed database. In an NDS tree, information about the network is stored as data files on servers. These data files can be centralized on one server or distributed across two or more servers. No matter how many servers the data files are distributed across, the user sees a single view of the network information.

Figure 15: Example of an NDS tree.

Example of an NDS tree. It doesn't necessarily represent the physical layout of the network but rather the logical organization of the business or company

Defining Partitions

A partition is simply a subtree of the NDS tree. At installation, NDS creates one partition by default- the entire tree. You create partitions by defining them.

Figure 16: Defining Partitions.

A partition defines the logical structure of the directory data. For example, one partition in the figure above begins with the [Root] object and includes the Organization (O) object and three subordinate Organization Unit (OU) objects: Accounting, Accounts Payable, and Accounts Receivable. Partitions are named by the container that is at the partition's top. The three partitions in Figure 14 are [Root], Engineering, and Marketing.

Each partition must have only one superior container object at the top. Figure 17 shows an illegal partition.

Figure 17: Illegal partition.

The Purpose of Partitions

One purpose of partitions is to allow the NDS database to be distributed where necessary. A company with a small number of servers could centralize the NDS tree information and have it all reside on one or two network servers. As companies grow and gain more users and resources, they typically divide the NDS tree into partitions and distribute them to the appropriate network servers.

Another purpose of partitions is to improve network performance in organizations with multiple sites connected by WAN links. Usually, you place a partition (or a physical copy of the partition known as a replica) onto a server that is physically close to the users of that partition's data. The physical proximity ensures efficient network response. For example, you wouldn't want to place a partition or replica on a server that is physically located across a WAN link from the people who use it most. This results in extremely slow network response.

Rules for NDS Partitioning

• Partitions require a single container object at the top of the partition. This container object is called the partition root object. Each partition can have only one partition root object.
  
  
• Partitions cannot overlap. No one object will ever reside in two partitions.
  
  
• Partitions contain all of the information for the connected subtree. In other words, you can think of each partition as a section or subtree of the entire NDS tree.
  
  

Parent and child partitions help you logically organize the NDS tree so you can efficiently distribute network data across multiple servers. They also help maintain the tree's hierarchical organization.

Replicas

In eDirectory, the partition is a logical structure. The physical copy of a partition is called a replica. It's a good idea to have replicas in case a link to one server is down, directory resources are still available.

Note:

Replication is not a backup solution. It only replicates the directory objects, not the server data files

Why Use Replicas?

Fault tolerance.  If a server holding a replica goes down, users can use another replica on another server. Their network access is not interrupted.

Performance.  Placing replicas local to the users that require the information increases the network performance. Local replicas decrease the time needed to authenticate, update, search, and extract NDS information.

Name resolution.  When a user requests information, eDirectory must first locate the server that contains the information. This process is called name resolution or tree walking. If the information is not located on a server that the user is already connected to, eDirectory will walk the tree to locate the information and connect the user to the proper server.

Types of Replicas

Master

• first one created
  
  
• one master per partition
  
  
• accepts object changes and passes them on to other replicas during synchronization
  
  
• controls partition operations (splits, joins, etc)
  
  

Read/Write

• accepts object changes and passes them on to other replicas during synchronization
  
  
• fault tolerance for the partition
  
  
• increases eDirectory performance by putting replicas close to local users
  
  

Read Only

• accepts requests only, does not modify objects
  
  
• could use as a disaster recovery server
  
  

Subordinate Reference

A subordinate reference contains only one object- the partition root object. The partition root object is the top-most object in the partition and contains information that links together the partitions in a tree. eDirectory places subordinate references on servers that hold a parent partition, but not that partition's child partition. The subordinate reference holds the child partition's partition root object so that eDirectory can locate the child partition.

Figure 18: Subordinate reference pointing to Server 2.

• NDS creates and manages subordinate reference replicas
  
  

Filtered

Filtered Replication enables you selectively copy and distribute any part of a partition, including objects and their attributes. Benefits of filtered replication include reducing the amount of information stored in a particular NDS database and being able to tailor the information to a particular audience.

Replica Recommendations

• one master and 2-3 read/write replicas per partition
  
  
• keep partitions at the top of the tree to a minimum as to lessen the number of subordinate references
  
  
• place server replicas near users who need information to minimize WAN traffic- don't replicate accross a WAN
  
  

Replica synchronization Factors

The following effect the time synchronization on a server:

• Server's CPU speed
  
  
• Number of replicas
  
  
• Number of objects in each replica
  
  
• Size of each replica ring
  
  
• Location of the replicas (local or remote)
  
  
• WAN links speed
  
  
• Amount of RAM on server
  
  
• Frequency of inbound replica synchronizations