Schema Enhancements for NDS 8
Articles and Tips: article
Technical Writer
Novell Product Group
BRIAN JARVIS
Senior Software Engineer
Novell Product Group
01 Jun 1999
NDS 8 has made a number of significant changes to the NDS operational schema. Most of these changes were made to make the NDS schema more conformant to the LDAP schema.
Introduction
NDS 8 has made a number of significant changes to the NDS operational schema. NDS now supports
Auxiliary classes
A new container class, domain
A new super class, ndsLoginProperties
Most of these changes were made to make the NDS schema more conformant to the LDAP schema. LDAP uses auxiliary classes, the new container class is an LDAP class, and the new super class supports LDAP login features which allow objects such as Organization, Organizational Unit, and Organizational Person to log in to the tree.
Auxiliary Classes
Auxiliary classes are a special type of object class definition that have been added to the schema in NDS 8.
Auxiliary classes are dynamic classes that can be added to the Object Class attribute of individual objects. When the auxiliary class is added, the object inherits all the attributes of the auxiliary class while retaining all of its own attributes. When the auxiliary class is removed from the object, the auxiliary class attributes are removed from the object and the object is no longer permitted to use those attributes.
In other words, the attributes allowed on an object are the union of the attributes defined for the following:
Object's base class
Current auxiliary classes
Super classes of its base class and auxiliary classes
For example, NDS 8 adds a dcObject auxiliary class to the schema. This auxiliary class allows all objects in the NDS database to support the dc attribute for LDAP naming conventions. When added or removed, this attribute has the following effects:
Add this auxiliary class to the containers that are in a user's distinguished name, and LDAP applications can find the user with a domain name search.
Remove the dcObject class from the container objects, and the dcObject attributes (mandatory or optional) and their values are removed from the objects.
The following sections describe the major differences between auxiliary classes and standard object class definitions:
Attribute additions with auxiliary classes
Auxiliary classes and object class rules
Required rights
Backwards compatibility
Attribute Additions with Auxiliary Classes
NDS allows mandatory attributes for a class definition such as User to be added only when the class definition is first created, and once attributes are added to a class definition, NDS does not allow them to be removed. Auxiliary classes add flexibility by allowing attributes to be added and removed, but they are added to and removed from an existing NDS object rather than to, or from, the class definition.
Auxiliary classes are added to individual instances of the object in the database. For example, suppose you have the following conditions:
An auxiliary class called Pager Users with attributes for Pager Number, Pager Codes, and Pager Is Alphanumeric
Four users: Kim, Chris, Lynn, and Terry
Two users with pagers: Kim and Chris
As system administrator, you assign the Pager User class to Kim and Chris. The objects would 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. |
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. |
Two months later, 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. |
Auxiliary Classes and Object Class Rules
The object class rules have been modified to allow auxiliary classes to have features that no other class type can have in the NDS schema. The following paragraphs explain how auxiliary classes use object class flags, super classes, containment classes, mandatory and optional attributes, and naming attributes.
Object Class Flags. Auxiliary classes do not support all the possible object class flags. When creating an auxiliary class, the only flag that should be set is the auxiliary class flag. If developers attempted to turn on any of the following flags when the auxiliary class is defined, creation of the auxiliary class fails:
Container an auxiliary class cannot be a container class. Since auxiliary classes can be added and removed from an object, an auxiliary class cannot contain other objects. Object containment rules need to be stable.
Effective an auxiliary class cannot be an effective class.
The operational, ambiguous containment, and ambiguous naming flags can be set, but NDS ignores their settings.
Super Classes. Auxiliary classes are not required to have a super class. They may declare other classes as their super class, but auxiliary classes should not declare Top as their super class.
If an auxiliary class does have a super class, NDS adds the super class to the object's Object Class attribute and flags them and the base auxiliary class so that they can be deleted only if the base auxiliary class is removed from the object. The object inherits all the attributes defined for the super classes of the auxiliary class.
Containment Classes. Auxiliary classes cannot define containment.
Mandatory and Optional Attributes. Auxiliary classes can have mandatory attributes, optional attributes, or both. If you add mandatory attributes to an auxiliary class, the application that allows the user to add the auxiliary class to an object must also prompt the user for values or supply the values for the mandatory attributes. NDS will not add an auxiliary class to an object without values for all mandatory attributes.
Naming Attributes. Auxiliary classes can define naming attributes, which can be either optional or mandatory. If an auxiliary class attribute is used to name an object, the object must be renamed to use a non-auxiliary class attribute before the auxiliary class can be removed.
Required Rights
To add the auxiliary class to the schema, the user needs the standard rights required to extend the schema: Write rights to a Read/Write partition of the root partition of the NDS tree.
To add an auxiliary class to, or delete an auxiliary class from, an object in the NDS database, the user needs Write rights to that object's Object Class attribute.
Backwards Compatibility
NDS versions prior to NDS 8 do not know about auxiliary classes. NDS 8 servers will send auxiliary class information and auxiliary attribute information only to NDS 8 servers. To non-NDS 8 servers, NDS modifies the information to make it compatible. Special modifications have been made for the following operations.
Replica Synchronization in a Mixed Replica Ring. Changes to objects are synchronized to all servers in a replica ring. If the replica ring contains both NDS 8 servers and servers with previous versions of NDS, NDS must send the auxiliary class information in a manner that is compatible with the previous releases. Since an auxiliary class adds attributes to an object that the non-NDS 8 server considers illegal, NDS 8 servers make the following modifications before sending objects with auxiliary classes to the non-NDS 8 servers:
Object Class. The object's class is changed to Unknown object.
AuxClass Object Class Backup. This attribute is added to the object and all the information from the object's Object Class attribute is stored in the attribute.
When an NDS 8 server receives an Unknown object with an AuxClass Object Class Backup attribute, the server has the information needed to restore the object to its base class and to restore the object's auxiliary class information.
If many objects are using auxiliary classes, replicas on the non-NDS 8 servers will not be particularly useful because they will contain so many Unknown objects. If system administrators are going to add auxiliary classes to objects, they should be encouraged to include only NDS 8 servers in the replica ring.
Schema Synchronization in a Mixed NDS Tree. Schema changes are synchronized from the root of the NDS tree down to its branches. Since an NDS tree can have NDS 8 servers near the root, with NetWare 5 or 4.x servers in the middle, and an NDS 8 server below them, NDS must be able to send information about auxiliary classes in a manner that is compatible with previous versions of NDS and with sufficient clues that an NDS 8 server can recreate an auxiliary class from the information. To accomplish this, NDS must make three characteristics of auxiliary classes compatible with previous versions:
Auxiliary Class Flag. This is a new object class flag for NDS 8, and NDS 8 uses it to recognize which classes are auxiliary classes. Since previous versions of NDS do not recognize this flag, NDS 8 servers send auxiliary class definitions as standard class definitions with one additional attribute, the Auxiliary Class Flag attribute, that contains the auxiliary class flag information. When an NDS 8 server receives a class definition with this attribute, the NDS 8 server knows it should remove the attribute from the class definition and recreate an auxiliary class from the class definition.
Super Classes. Versions of NDS previous to NDS 8 require all classes to have a super class. To make auxiliary classes compatible with these rules, NDS 8 servers send Top as the super class of any auxiliary class which has declared no super class. When a NDS 8 server receives a class definition with the Auxiliary Class Flag attribute and with Top as its super class, the NDS 8 server removes Top as its super class.
Object Class Attribute. In versions of NDS previous to NDS 8, the Object Class attribute is a Read-Only attribute. When NDS 8 servers send the definition of this attribute to non-NDS 8 servers, the NDS 8 servers include the Read-Only constraint. When NDS 8 servers receive the definition for this attribute from a non-NDS 8 server, they remove the Read-Only constraint from the definition.
Backup. The backup routines in NDS 8 are compatible with existing backup applications. They perform the same data conversions that NDS uses for replica and schema synchronization: the replica synchronization conversions for backing up objects and attributes, and the schema synchronization conversions for backing up the schema definitions. Information backed up in this manner can be restored, without loss of data, to either an NDS 8 server or a server running an earlier version.
Class Definitions. Since existing applications that read class definitions do not understand auxiliary classes, the read class definition routines have been modified. These routines perform the same data conversions as the schema synchronization routines and display auxiliary classes as regular class definitions with an Auxiliary Class Flag attribute. Only applications that have been updated to be compatible with NDS 8 can display auxiliary class definitions with an auxiliary object class flag.
New Container Class
Objects that can contain other objects are called container objects or parent objects. Container objects form the branches of the NDS tree. NDS 8 adds a new container class called domain. The domain class allows you to add Internet or domain objects to an NDS tree. Since these objects are identified by name, this class has only one mandatory attribute, a domain-style naming attribute. Containment rules have been modified to allow you to place the domain object almost anywhere in the NDS tree.
To accommodate this class, NDS 8 modifies:
Containment class rules
Containment class inheritance for leaf objects
Containment Class Rules
The following table shows the classes that can contain other objects and the object types that they can contain. Notice that the new container class domain can be contained by all previous container classes and can contain all these classes except for Tree Root.
|
Object Class
|
Contained Class
|
|
Tree Root |
CountrydomainOrganization |
|
Country |
domainLocalityOrganization |
|
Locality |
domainLocalityOrganizationOrganizational Unit |
|
Organization |
domainLocalityOrganizational UnitLeaf objects |
|
Organizational Unit |
domainLocalityOrganizationOrganizational UnitLeaf objects |
|
domain |
domainCountryLocalityOrganizationOrganizational UnitLeaf objects |
The ability for Country, Locality, Organization, and Organizational Unit objects to contain domain objects comes with the installation of NDS 8. The ability of domain objects to contain Country, Locality, Organization, and Organizational Unit objects does not come through installation. The schema must be expanded to this functionality with a schema option in DSRepair.
The following figure presents a graphical view of the NDS containment structure. This figures shows the containment classes and the object classes that they can contain and that can contain them. Object classes that cannot contain other objects (leaf objects) are collectively shown as noncontainer classes. The object class Top is not shown in the graphical view because Top is used for schema hierarchy and inheritance but not for NDS tree hierarchy.
Figure 1: NDS 8 containment structure.
Tree Root, Organization, and Country are shown on the same level because they all can be the topmost object in the tree. Tree Root has arrows pointing to both Country and Organization because Country and Organization can be, but are not required to be, subordinate to Tree Root.
Lines that have arrows pointing up indicate that these objects can contain each other. For example, an Organizational Unit object can contain a Locality object, and a Locality object can contain an Organizational Unit object.
Objects with circular lines indicate that they can contain objects of the same type as themselves. For example, one Organizational Unit object can contain another Organizational Unit object.
The operational schema in NDS 8 adds one new container object, domain. A domain can be contained by all the other containers in the operational schema: Tree Root, Country, Organization, Locality, Organizational Unit, and domain. It can contain all the leaf objects that Organization Unit and Organization can.
The domain object can also contain all the other operational container objects, except Tree Root. This containment is shown with a dotted red line with an arrow pointing up to these objects. The line is not solid because this functionality is not automatically added to the schema with an NDS 8 upgrade. This functionality must be added to the schema by running a schema option in DSRepair, and the other servers in the NDS tree must be running NDS 5.17, 6.01, or higher.
Containment Class Inheritance for Leaf Objects
Most leaf classes and noneffective classes in the operational schema are contained by the domain, Organization, and Organizational Unit classes. The following table lists the exceptions.
|
Object Class
|
Classes Contained By
|
Class Defined For
|
|
Alias |
Special case |
Inherits containment from referenced object. Since an alias can reference a container object, it can inherit the containment rules of the container object. |
|
Partition |
Special case |
Inherits containment from the object that is the root object of the partition. In NDS 8, partition becomes an Auxiliary class and no longer requires any containment rules. |
|
Unknown |
Special case |
Any. |
Noneffective classes cannot be used to create objects in NDS, but they are often used to define containment classes for other object classes to inherit. Effective classes can define containment for themselves and for subordinate classes.
The following figure provides a graphical view of how the leaf objects obtain their containment classes. The arrows pointing up to the container objects indicate which object class declared the containment class. Arrows pointing down to a leaf object indicate the objects that inherit the containment classes.
Figure 2: NDS 8 containment of leaf objects.
One effective object class is unique: Alias. It is shown at the bottom of the figure because Alias inherits its containment classes from the object that it references. Since all leaf objects have domain, Organization, and Organizational Unit as their containment classes, an Alias will usually inherit these containment classes. However, an Alias can reference a container class, and when it does, the Alias inherits the container's containment classes.
The Partition class is like the Alias class. Since any container class can be the root object in a partition, the Partition class inherits its containment classes from that root object.
The ndsLoginProperties class is not shown because it is a noneffective class, defines no containment classes, and inherits no containment class from its super class, Top. Thus, ndsLoginProperties is like Top in that they both do not affect containment classes of any objects in the NDS tree.
Super Class Hierarchy
Super classes create the hierarchy of the schema and determine the characteristics that an object class can inherit from another object class. The following figure provides a graphical view of the NDS operational schema, showing the object classes in the structure of the class hierarchy. In this view of the object classes, the arrows show the direction of flow for inheritance from super classes. An object class inherits the rules and attributes defined by all its super classes, but does not inherit from its subordinates.
Figure 3: NDS 8 class inheritance.
The Top class is an effective class, but it is a special super class because it cannot be used to define an instance of an object.
The figure above illustrates the purpose of noneffective classes. For example, the Server class (noneffective) defines those characteristics shared by all servers; the effective classes (AFP server, NCP Server, Print Server, etc.) define only those characteristics that are particular to that type of server.
Effective classes can inherit from effective classes. In NDS 8, ndsLoginProperties is a new noneffective class. It contains all the attributes required for an object to authenticate to NDS. The Person and Organizational Person classes are effective in NDS 8, and because they now inherit the required login attributes, Person and Organizational Person objects can log in to the NDS tree.
Conclusion
Auxiliary classes, the domain class, and the ndsLoginProperties class make the NDS schema in NDS 8 more conformant to the LDAP v3 schema. LDAP v3 is installed with NDS 8 and makes additional schema modifications by adding class and attribute definitions. For complete information on how the NDS schema maps to the LDAP schema, see the Readme file for NDS 8.
The schema modifications allow LDAP applications to access the information in the NDS directory. If you write your applications to use LDAP, you have written your application to use NDS.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.