Object classes define the types of objects that can exist in the NDS database. Database entries are created by selecting an object class and then supplying the required attribute information for the entry. For example, to create an entry for a user, you must select the User object class and then supply a name for the user.
In the base schema, all object classes are nonremovable; that is, they cannot be deleted or in any other way removed from the schema. Object classes that extend the schema are removable.
An object class is defined by its characteristics and consists of the following kinds of information:
An object class does not have to specify definitions for all characteristics, because it can inherit characteristics from super classes. See Class Inheritance Rules.
Object classes can be either effective or noneffective.
Effective class—you can actually create an instance of the defined object in the NDS tree.
Noneffective class—the class is used only to define other classes. You cannot create an object of a noneffective class
The Computer class, for example, is an effective class. You could create a Computer object on the NDS tree using the Computer class. The Device class is a noneffective class. You could not create a Device object because it would have no real function. However, the Device class is a super class of the Computer class and helps to define the attributes needed by the Computer class.
Most of the object classes in the base schema are effective classes. Since effective classes are the active building blocks from which an NDS tree is created, their structure rules must be complete. This means that the naming attributes and containment classes cannot be ambiguous.
For example, if naming attributes or containment classes are not specified for a new effective class, they are inherited from the new class’s super classes. If the new effective class inherits from multiple super classes, the naming attribute and containment classes must be identical. If they aren’t identical, the structure rules conflict and are ambiguous. In this case, an effective class must define its naming attributes and containment classes.
If the structure rules are incomplete or ambiguous, NDS automatically flags the class as noneffective. The effective or noneffective flag is assigned to a class when it is originally defined. The value cannot be modified after the class is created.
The noneffective classes are not active and thus cannot be used to create objects in an NDS tree. They are typically used as super classes to define class information that is shared by multiple effective classes. The effective classes can then inherit the class information from the noneffective super class rather than repetitively defining it.
The base schema defines the following noneffective classes:
Device
ndsLoginProperties
Resource
Server
Top is the one special case for the Effective flag. Although Top is flagged as an effective class, no object can be created from the Top class.
The Novell Object Class Extensions section lists the name of each class in alphabetical order. The name is followed by a brief description of the purpose of the class and whether the class is effective or noneffective.
Each object class has the following information defined:
The class flags determine whether the object is a leaf or container object and whether object class is effective or noneffective. See Section 1.7, Object Class Flags for a description of these flags.
Objects inherit information from classes listed in this section. All object classes must have one or more super classes, except Top, which is a super class to all classes. The super classes are listed in a hierarchical manner, with the super class at the bottom of the list being the immediate super class from which the current class inherits.
Objects of the class can be created only as subordinates in the NDS tree to objects of the classes listed here. An object of the class cannot be subordinate to any object of a class that is not listed here.
The partial name or Relative Distinguished Name (RDN) of objects of the class consists of at least one of the attributes listed here. These attributes can be either mandatory or optional attributes, but at least one must be given a value when creating an object of the class. If the only Named By attribute is optional, it is in effect mandatory.
Attributes listed in this section will also be listed in the Mandatory Attributes and Optional Attributes sections. For example, a User object is named by Common Name, which is a mandatory attribute.
Every expanded class definition has an ACL attribute (inherited from Top). This attribute holds information about which trustees have access to the object itself (entry rights) and which trustees have access to the attributes for the object. This information is stored in sets of information containing the trustee name, privileges, and the affected attribute (entry, all attributes, or a specific attribute). For example, the default template for AFP Server is that the creator of an object has the supervisor right on [Entry Rights].
Some object classes define a default set of values for their ACL. Objects also inherit default ACL values from their super classes. Therefore, every object class inherits a default ACL template from Top. When an object is created, its ACL contains the values that are in the default ACL template for that object. There are two cases where the ACL values are different:
Your code overrides the default values.
The creator of the object has effective rights comparable to those in the default template. In this case, the rights are not granted explicitly.