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—if the class is added to the object. 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 auxiliary 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 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 the 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.
Table 1-4 Example Explaination
|
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. |
|
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 re renamed to use a non-auxiliary class attribute before the auxiliary class can be removed from the object.
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.
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 servers running previous versions, 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 previous versions on NDS consider illegal, NDS 8 servers make the following modifications before sending objects with auxiliary classes to servers with previous versions of NDS:
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 servers with previous versions of NDS 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.11 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 an 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 servers with previous versions of NDS, the NDS 8 servers include the Read-Only constraint. When NDS 8 servers receive the definition for this attribute from a server with previous versions of NDS, 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 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 classes 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.
Auxiliary classes have the following advantages over modifying existing class definitions:
Efficient. Auxiliary classes can be applied to some instances of a class definition and not applied to other instances of that class definition. For example, if you are developing a laptop management utility and want to add a few attributes to the users who have laptops, adding these attributes to the User class would not be as efficient as creating an auxiliary class with the attributes. Since all users in a company might not be laptop owners, modifying the User class definition adds attributes that will never be used by some objects. The auxiliary class option is efficient because the attributes are added only to the objects that have laptops.
Flexible. Auxiliary classes can be used on objects from multiple class definitions. In NetWare 4.x, all logged in users were User objects. With the changes made in NDS 8 and higher, users can now authenticate as other object types such as Person, inetOrgPerson, and residentialPerson objects. An auxiliary class allows you to add your attributes to objects from any of these classes or any other class in the schema.
Separate from Class Definitions. Auxiliary classes and their attributes are added to the objects rather than to the class definitions. Therefore, when the auxiliary class is removed from the objects, the class definition doesn't retain any unnecessary, unused attributes. The auxiliary class attributes were never added to the class definition, so they don't need to be removed.
Removable. The attributes in an auxiliary class are removable from the schema. When you modify an existing class definition, the attributes you add cannot be removed without deleting the class definition. All the classes in the base schema, such as User and Person, are nonremovable. Thus, any attributes added to these classes are permanent additions.
As your product evolves and you change your attributes, you cannot remove your obsolete attributes from base schema classes.With an auxiliary class, you can find all the objects in the NDS tree with your auxiliary class, add your new auxiliary class to these objects, transfer any old attribute values to the new attributes, and then delete your old auxiliary class and its obsolete attributes.
LDAP Conformance. Modifying objects with auxiliary classes conforms to LDAP standards. LDAP expects class definitions to remain unmodified once the definition of the class has been published. NDS has allowed a more dynamic schema, with the notion that the attributes defined for the User object in one tree will probably never match all the attributes defined for the User object in another tree. Applications in this environment must read the schema definitions rather than assuming schema definitions.
The NDS method for conforming to LDAP standards is to use auxiliary classes where possible, and when not, to modify a non-effective super class which allows the child class to inherit the attributes without the attributes becoming part of its definition.
Auxiliary classes cannot be used in products that require the following:
Compatibility with NDS trees in which all the servers are using versions of NDS earlier than NDS 8
The new attributes will be used in every instance of a class definition