NDS Schema Overview

Articles and Tips: article

JUDY WILSON
Technical Writer
Novell Products Group

01 Oct 1998

Describes the base schema, the schema configuration that is installed by NDS. Describes the components and structure, new features for NetWare 5, schema extensions, and the actual components (object class definitions, attribute type definitions, and attribute syntax definitions).

Introduction
Schema Components
Schema Structure
NDS in NetWare 5: New Schema Features
Schema Extensions
Object Class Definitions
Structure Rules
Naming Attributes
Containment Classes
Super Classes
Object Class Attributes
Object Class Flags
Default ACL Templates
Construction Rules for Object Classes
Attribute Type Definitions
Attribute Syntax Definitions

Introduction

Novell Directory Services, an object-oriented, distributed, hierarchical database, is based on a set of rules which define:

The types of objects that can exist in an NDS tree
The possible locations of these object in the NDS tree
The information (stored as attributes) that can be and must be maintained about the object

This set of rules is called the schema. This article describes the following features of the NDS schema:

General concepts (components and structure)
New features for NetWare 5
Schema extensions
Actual components (object class definitions, attribute type definitions, and attribute syntax definitions)

This Developer Note describes the base schema, the schema configuration that is installed by NDS. It does not include a description of any of the schema extensions that the NetWare operating system, NetWare utilities, and Novell products make to the NDS schema.

Schema Components

The NDS schema consists of three basic components:

Object Classes
Attribute Types
Attribute Syntaxes

The set of rules that controls the creation of a particular object is called an object class. Each object class is defined in terms of attributes. An attribute is a specific piece of information that can exist for an object. (NetWare utilities and documentation sometimes call attributes, properties.)

For example, NDS contains an object class for users, called User object. This User object class defines many attributes (over 80), including attributes for such items as the user's name, telephone number, address, and group memberships.

Attributes are defined in terms of a base set of data types called attribute syntaxes, and the attribute syntaxes define the primary data types for values stored in the NDS database.

For example, some attributes such as Password Minimum Length or Minimum Account Balance take integer values while other attributes such as a user's Full Name or Given Name take string values.

NDS has a set of built-in classes and attribute types that accommodate general categories of network objects such as organizations, users, and devices. This set is called the base schema. NDS developers can build on the base schema to create new classes and new attributes for objects. However, these new classes and attributes must be defined in terms of the existing syntaxes. Defining new syntaxes is not allowed.

Schema Structure

The schema defines the set of rules that govern the types of objects that can exist in an NDS tree. Each object belongs to an object class that specifies what attributes can be associated with the object. All attributes are based on a set of attribute types that are, in turn, based on a standard set of attribute syntaxes.

The NDS schema not only controls the structure of individual objects, but it also controls the relationship among objects in the NDS tree. The schema rules allow some objects to contain other subordinate objects. Thus the schema gives structure to the NDS tree.

Figure 1 shows how the schema components and the Directory components are interrelated. The vertical arrows indicate the structure dependencies from the basic building blocks up to the schema and the Directory, respectively. The horizontal arrows denote the schema rules that apply to the respective Directory components.

The attribute syntaxes define the primary data types for values stored in the NDS tree. Attribute types are defined from the attribute syntaxes and define the possible attributes an object can have. Object classes are defined using a subset of the possible attributes and determine the types of objects that can be in the tree. The tree structure rules define how the object classes can be organized and nested in the tree, and therefore determine the tree's structure.

Figure 1: Relationships between the Schema and the Directory Components.

Objects that can contain other objects are called container objects. Container objects are the building blocks of the hierarchal structure of the Directory tree. Objects that cannot contain other objects are known as non-container or leaf objects. Leaf objects comprise the actual network resources such as a user, a server, or a printer.

NDS in NetWare 5: New Schema Features

The base schema in NetWare 5 has added new attributes and an object class, made changes in containment rules and syntax matching, and modified the inheritance of ACLs. The following sections describe these new features.

Containment Changes

NetWare 4 allowed either an Organization object or a Country object to be the root of the NDS tree. NetWare 5 allows a user to select the tree root from the following object classes:

Tree Root
Country
Organization

The Tree Root object can contain Country and Organization objects.

Syntax Matching Changes

NetWare 4.x versions of the NDS schema documented only two syntaxes that supported approximate matching: Object ACL and Octet List. The NetWare 5.x schema supports approximate matching for all syntaxes with lists of strings and with distinguished names of objects. The approximate match allows two strings to match without requiring all strings in the list to match. It also allows the distinguished names of objects such as servers, volumes and users to match while ignoring the other fields in the syntax.

New Object Classes

The NDS base schema added only one new object class: Tree Root. This object allows the tree name to be part of the objects distinguished name. When a NetWare 4.11 tree is upgraded to NetWare 5, Tree Root becomes the base object of the NDS tree.

New Attribute Definitions

Attributes were added for transitive synchronization (which allows the NDS database to synchronize in mixed IPX and IP networks), guaranteed globally unique IDs, bindery restrictions, and password management. The following attributes are new:

Bindery Restriction Level
GUID
Obituary Notify
Other GUID
Password Management
Purge Vector
Synchronized Tolerance
T (Tree Name)
Timezone
Transitive Vector
Used By
Uses

ACL Enhancements Effecting Attributes

NetWare 4.x allows the inheritance of ACLs granted to [All Attribute Rights] to flow down the NDS tree but blocks the inheritance of ACLs granted to specific attributes.

NetWare 5.x allows the network supervisor to select whether ACLs granted to specific attributes or [All Attribute Rights] are inherited. The control comes with the Inheritance Control right that has been added to the rights bit mask. This right controls whether the privilege set in the ACL flows to subordinate objects.

Allowing the inheritance of ACLs to specific attributes enables the network supervisor to set up mangers who can manage specific attributes, such as phone numbers, addresses, and passwords, without granting Supervisor rights to the objects. If the ACL to a specific attribute is granted at the container level, the right can be inheritable to an entire branch of an NDS tree.

For example, you can create a telephone number manager by granting the manager an ACL to the Telephone Number attribute of an NDS container object. The privilege set should include the Read, Write, and Inheritance Control rights. The Password Management attribute was added specifically so that network supervisors could set up password managers for the entire NDS tree or portions of the tree.

ACL Enhancements Effecting Objects

In NetWare 4.x, when a user, or trustee, is given [Entry Rights] to a container object, the trustee is given the same rights to all of the subordinate objects of that container. These rights automatically flow down the tree unless an Inherited Rights Filter blocks them.

In NetWare 5.x, [Entry Rights] can behave just as they did in NetWare 4.x, but NetWare 5.x allows them to be configurable. An Inheritance Control right has been added to the bit mask for entry rights, and it controls whether the trustee of the ACL can inherit the rights.

This enhancement has only specialized uses because most of the time the network administrator granting entry rights will want the trustee to inherit the rights. However, this functionality allows the network administrator to create a partition manager who has the rights to create and manage replicas but does not have the rights to modify objects in the containers of the partitions.

Schema Extensions

The NDS schema is extensible. Developers can define new object classes and attributes in addition to those provided by the base schema. In fact, the NetWare operating system and NetWare utilities extend the schema.

When developers define new attribute types or new object class definitions, they must register them with Developer Support to ensure uniqueness. To clear new types and definitions, call Developer Support at 1-800-REDWORD (1-800-733-9673). If you cannot use an 800 number, the international number is 801-861-5588. Correspondence can be sent by Fax to 801-861-2990. You can also register at Novell's Developer Support Web site: http://developer.novell.com/support/schreg2c.htm.

When you register, you receive a unique prefix that you prepend to the names of your new attribute and object class definitions. You also receive an ASN.1 (Abstract Syntax Notation One) ID for object classes and one for attribute definitions. These IDs can be expanded to include as many unique IDs as you need for object classes and attributes.

In NetWare 4.11 and below, object classes and attributes may have, but are not required to have, an ASN.1 ID. In NetWare 5, ASN.1 IDs are required for applications to pass Novell certification. ASN.1 serves as a common syntax for transferring information between two end systems.

Object Class Definitions

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 extended the schema are removable.

An object class is defined by its characteristics, which consists of the following kinds of information:

Structure rules for naming and containment
Super classes
Object class attributes
ACL templates
Object class flags

An object class does not have to specify definitions for all characteristics because it can inherit characteristics from super classes. See "Object Class Inheritance Rules" for more information.

Structure Rules

All object classes possess two types of structure rules:

Naming attributes which determine how objects of the class are named
Containment classes which determine where in the NDS tree hierarchy objects can be placed

The structure rules for an object class define the possible structural relationships of objects in the NDS tree. The structure rules are either explicitly defined by the class or inherited from a super class. If the class defines them, the class definitions take precedence over inherited definitions.

Naming Attributes

Objects are identified by their own name and the name of their parent objects. An object's name is called its partial name or relative distinguished name (RDN). An object's RDN is determined by its naming attribute.

The object's full name (with all its parent names included) is called the complete name or distinguished name (DN). An object's DN is determined by all the objects it is subordinate to. Hence, containment rules, which control subordination in the tree, effectively control the formation of distinguished names.

The sections below describe the following characteristics of naming attributes:

Naming attribute rules
Multi-valued naming attributes
Shareable naming attributes
Inheritance of naming attributes

Naming Attribute Rules

Each class has one or more attributes designated as naming attributes. These attributes can be either mandatory or optional attributes, but at least one must be given a value when creating an object of that class. If the only naming attribute is declared as optional, it is, in effect, mandatory.

Naming attributes specify the rules for the partial name of the object. For example, Organization objects are named by the O (Organization Name) attribute. This attribute is the only attribute value that can appear in an organizational entry's partial name.

Multi-valued Naming Attributes

Naming attributes can be multi-valued; in other words, more than one name (value) can be added to the naming attribute. For example, an organization can have both "Testing" and "Engineering" as values for the O (Organization Name) attribute. However, only one value will be flagged as the naming value, and that value is used in search operations.

Some object class definitions specify multiple naming attributes. For example, the Locality object class is named by the L (Locality Name) and S (State or Province Name) attributes. Thus, an RDN for locality can include just a L (Locality Name) attribute, just a S (State or Province Name) attribute, or both attributes.

For example, the name for the Provo, Utah locality could be

L=Provo
S=Utah
L=Provo + S=Utah

The last example uses both attributes with a plus sign (+) to indicate where the second attribute's value begins. When the type specifiers (in this case L and S) are used as shown, the name is referred to as a typed name. A typeless name has the following format: "Provo+Utah".

Shareable Naming Attributes

A naming attribute does not necessarily reflect the class an object belongs to. Many classes, such as Computer, User, and Server, are named by their CN (Common Name) naming attribute. In fact, CN is the recommended naming attribute for leaf objects. In such cases, the naming attribute itself does not indicate which class the object belongs to, but the value of the naming attribute may suggest the nature of the object. However, some naming attributes are closely tied to specific classes. For example, the C (Country Name) naming attribute is used to name only Country objects in the base schema.

Inheritance of Naming Attributes

Naming attributes for effective classes must follow the inheritance rules. Effective classes can inherit naming attributes only if the naming attributes of the super classes are identical and do not conflict. If they are different and therefore ambiguous, the effective class must define its own naming attributes. Noneffective classes may have ambiguous naming attributes, but often define the naming attributes so subordinate objects can inherited them. For example, the Server class defines naming attributes that are inherited by the AFP Server, NCP Server, CommExec, Messaging Server, and Print Server classes.

Containment Classes

Objects that can contain other objects are called container objects or parent objects. Container objects are the branches of the NDS tree and provide a structure that is similar to a directory in a file system. Objects that cannot contain other objects are called noncontainer or leaf objects. Leaf objects represent the actual network resources that perform some function in the NDS tree, such as users, printers, modems, servers, or volumes.

The sections below describe the following characteristics of containment classes:

Containment class rules
Containment classes in the base schema
Containment of leaf objects
Containment classes and inheritance

Containment Class Rules

For each object class, a list of containment classes specifies where an object of that class may appear in the hierarchical structure of the NDS tree. An object can be immediately subordinate to only those objects whose classes appear in the containment list of the object's expanded class definition. An expanded class definition includes all the characteristics defined for the class plus all the characteristics that the class can inherit from super classes.

Effective classes can inherit containment classes from super classes only if the inheritance does not make containment ambiguous. If the inherited containment is ambiguous, the class must define containment. Class-defined containment overrides containment defined for super classes.

Effective classes are those object classes that can be used to create entries in the NDS database. Noneffective classes cannot be used to create entries and are used by the schema so that multiple object classes can inherit a common set of schema characteristics. Noneffective classes can have ambiguous containment.

Containment classes limit the possible location of an object in the Directory tree, thus restricting the order and types of partial names that appear in the object's complete name. Containment helps to ensure that the NDS tree expands in a consistent and logical fashion. For example, an Organization object can be the topmost object of the NDS tree or subordinate to the Tree Root object. A User object can be subordinate to an Organization object but not to a Tree Root object. Before users can be added to an NDS tree, the tree must contain either an Organization object or an Organizational Unit object which are the containment classes for the User object.

While helping to control the structure of the Directory, containment classes must also be flexible enough to accommodate a variety of organizational situations. An example is the relationship between the Organization and Locality classes. Each class specifies the other as a containment class. This allows an administrator to decide which hierarchical order best represents the company's organization.

Containment Classes in the Base Schema

The table below lists the classes in the base schema that can contain other objects and the object types that they can contain.

Object Class	Contained Classes
Tree Root	CountryOrganization
Country	LocalityOrganization
Locality	LocalityOrganizationOrganizational Unit
Organization	LocalityOrganizational UnitLeaf Objects
Organizational Unit	LocalityOrganizational UnitLeaf Objects

Figure 2 presents a graphic view of the NDS containment structure. This view shows the containment classes and the object classes that they can contain and that can be contained by them. Object classes that cannot contain other objects (the leaf objects) are collectively shown as noncontainer classes. The object class Top is not shown in this graphical view because Top is used for schema hierarchy and inheritance but not for the NDS tree hierarchy.

Figure 2: 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.

The base schema defines all effective leaf objects as subordinate to either Organizational Unit or Organization. Applications which extend the schema can define leaf objects that are subordinate to any container in the tree. They can also define new container objects. Such applications cannot, however, define new container objects for the root of the tree.

Containment of Leaf Objects

The following table lists the leaf objects (effective and noneffective), the object classes they can be their parent container, and the object that defined the containment.

Object Class	Contained By	Class Defined For
AFP Server	OrganizationOrganizational Unit	Server
Alias	Special case inherits containment from the referenced object	Alias
Bindery Object	OrganizationOrganizational Unit	Bindery Object
Bindery Queue	OrganizationOrganizational Unit	Queue
Comm Exec	OrganizationOrganizational Unit	Server
Computer	OrganizationOrganizational Unit	Device
Device	OrganizationOrganizational Unit	Device
Directory Map	OrganizationOrganizational Unit	Resource
External Entity	OrganizationOrganizational Unit	External Entity
Group	OrganizationOrganizational Unit	Group
List	OrganizationOrganizational Unit	List
Message Routing Group	OrganizationOrganizational Unit	Group
Messaging Server	OrganizationOrganizational Unit	Server
NCP Server	OrganizationOrganizational Unit	Server
Organizational Person	OrganizationOrganizational Unit	Organizational Person
Organizational Role	OrganizationOrganizational Unit	Organizational Role
Partition	Special case	Partition
Person	None	Top
Print Server	OrganizationOrganizational Unit	Server
Printer	OrganizationOrganizational Unit	Device
Profile	OrganizationOrganizational Unit	Profile
Queue	Organization Organizational Unit	Resource
Resource	OrganizationOrganizational Unit	Resource
Server	OrganizationOrganizational Unit	Server
Unknown	Special case	Any
User	OrganizationOrganizational Unit	Organizational Person

Noneffective classes cannot be used to create object in the NDS tree, but they are often used to define containment classes for other object classes to inherit.

Figure 3 presents a graphical view of how the leaf objects inherited their containment classes. The arrows pointing up to container objects indicate which object class declared the containment classes. Arrows pointing down to a leaf object indicate the objects that inherit the containment classes. Effective classes use shapes with solid lines and noneffective classes use shapes with dotted lines.

Figure 3: Container Inheritance for Leaf Objects.

A couple of effective object classes are unique: Alias and Partition. They are shown at the bottom of Figure 3. Alias inherits its containment classes from the object that it references. Since all leaf objects have Organization and Organizational Unit as their containment classes, an Alias will usually inherit these containment classes. However, an Alias can reference a container and when it does, the Alias inherits the container's containment classes.

Partition inherits its containment class from its root container object. Since a partition can be defined for any container object in the tree, a partition can have the containment rules of Tree Root, Country, Organization, Locality, and Organizational Unit in the base schema.

The Person 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, Person is like Top in that they both do not affect containment classes of any objects in the NDS tree.

Containment Classes and Inheritance

Containment classes create the hierarchy of the NDS tree and determine where an instance of an object can be created in the NDS tree. A special flag, [Nothing], allows the three objects, Tree Root, Country, and Organization, to have no superior object.

Once an instance of an object (or an entry) is created in the NDS tree, the entry inherits rights from its container objects and the container objects are part of the entry's distinguished name. However, the object classes in the schema do not inherit anything from their containment classes.

Object classes can inherit containment definitions, but such inheritances comes from the schema's super class structure.

Super Classes

Super classes create the hierarchy of the schema and determine the characteristics that an object class can inherit from another object class. Inheritance simplifies the rules of the schema because it allows some characteristics to be defined once, while multiple object classes can use and enforce these common characteristics.

The sections below describe the following characteristics of super classes:

Root schema object
Super class rules
Class hierarchy
Object class inheritance rules

Root Schema Object

The Top object class is the root of the schema. Since all other object classes inherit characteristics from the Top class, the Top class specifies information that pertains to all other classes. For example, the Top class defines the following optional attributes:

ACL
Back Link
Last Referenced Time
Obituary
Used By

NDS uses these attributes to maintain information. Since these attributes are defined for Top, all object classes inherit these attributes. Entries in the NDS tree have them available whenever NDS needs to assign a value to one.

Super Class Rules

Each object class must define an object class as its super class. Super classes cannot be recursive; therefore an object class cannot list itself as a super class. The complete definition of each object class is derived from the characteristics of the object class itself plus the characteristics of all classes in its super class lineage. Hierarchies of classes develop through class inheritance in this manner. The classes at the top of the hierarchy provide general characteristics, while those at the bottom become more and more specialized. The complete set of rules for an object class is called the expanded class definition.

The object class from which an entry is created is called the entry's base class. The expanded class definition for an object class includes the base class and the sum of the information specified by all its super classes. For the purpose of searching the NDS tree, an entry is considered a member of all of its super classes. For example, the base class for creating a user is the User class. The User class inherits from the following super classes: Organizational Person, Person, and Top.

Although the schema is stored with the rest of the NDS database, schema data is logically separated from the NDS tree and must be accessed through different functions. Also, the schema's class hierarchy does not necessarily form a simple tree graph because a class can list more than one class as a super class. Listing multiple classes as super classes is called multiple inheritance. (None of the objects in the NDS base schema uses multiple inheritance.)

Class Hierarchy

Figure 4 provides a single graphic view of the base schema, showing the object classes in the structure of the class hierarchy. This provides a visual view of the object classes, super classes, and inheritance. In this view, the arrows show the direction of flow for inheritance. An object class inherits the rules and attributes defined by all its super classes, but does not inherit from its subordinates.

Effective object classes are represented as shapes with solid lines, and noneffective object classes are represented as shapes with broken lines.

Figure 4: Super Class Inheritance.

The class Top is an effective class, but it is a special super class because it cannot be used to define an instance of an object.

Figure 4 illustrates the effective use 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.

Object Class Inheritance Rules

While a class automatically inherits some characteristics in the schema, a class can select to inherit or block the inheritance of other characteristics. The schema follows the following inheritance rules.

A class must declare another class as its super class. The class then automatically inherits any super classes of its defined super class. (Top is the only class that has no super class.)
A class may, but is not required to, define mandatory or optional attributes. The class, however, always inherits all the attributes, both mandatory and optional, of its super classes.
A class may, but is not required to, define a default ACL template. The class always inherits all the default ACL templates of its super classes. Classes that extend the schema cannot define new default ACL templates.
A class can inherit containment classes and naming attributes, but if the class defines them, any definitions made in super classes are not applied to the class.

Object Class Attributes

An attribute is a single piece of information that is stored in the database about an object. The attributes assigned to an object class can be mandatory or optional:

If an attribute is mandatory, a value must be assigned to the attribute before an instance of the object can be created.
If an attribute is optional, a value does not need to be assigned to create an instance of the object. The only exception is an optional naming attribute. If the optional naming attribute is the only attribute used for naming the object, this optional attribute becomes a mandatory attribute.

Both mandatory and optional attributes are always inherited from super classes. There is no way to block the inheritance. Also, mandatory definitions take precedence over optional designations. For example, a subordinate class can define an attribute as mandatory that is optional in a super class. For that class it is now mandatory. However, if a subordinate class tries to define an attribute as optional that a super class defines as mandatory, the attribute is still mandatory for the subordinate class.

A client cannot associate an attribute with an object unless the attribute is listed among the mandatory or optional attributes of the object's expanded class definition. If a client must associate an attribute with a particular object and the attribute is not specified by the object class, the client must extend the schema by:

Adding the new attribute to the class or a super class as an attribute
Defining a new class that inherits from the original class and adds the new attribute as an attribute

If the attribute is added to a nonremovable class, the attribute becomes nonremovable. Attributes are only removable when they are not assigned to any class.

Object Class Flags

There are five object class flags that can be "set" (turned On) or "not set" (turned Off). Applications extending the schema can set two: Container and Effective. NDS sets three: Nonremovable, Ambiguous Naming, and Ambiguous Container.

Container Flag

The Container flag indicates whether the object can contain other objects. The flag is turned On for those object classes that are designated as container classes. The flag is turned Off for all leaf object classes.

Effective Flag

The Effective flag indicates whether an object class is effective or noneffective. The Effective flag is turned On for those classes which can be used both to provide definition and to create objects. The Effective flag is turned Off for those classes which provide definition but cannot be used to create objects.

Only effective classes are:

Used to create entries in the NDS database
Assigned as base classes to the entries they create in the NDS database

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
Organizational Person
Partition
Person
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.

Nonremovable Flag

The Nonremovable flag indicates whether the object class can be removed from the schema. The flag is turned On for objects that cannot be removed. The flag is turned Off for object classes that can be removed. All base schema object classes are flagged nonremovable. Object classes added to extend the schema are the only classes that may have the nonremovable flag turned Off.

Ambiguous Naming Flag

The Ambiguous Naming flag indicates whether the object class has clearly defined naming attributes. As a general rule, noneffective classes can be created with ambiguous naming, but effective classes must have nonambiguous naming attributes. Only in special cases can effective classes be created with ambiguous naming. The Alias class object is one of these special cases since it needs to inherit the naming attributes of its reference object class.

For most object classes in the base schema, the Ambiguous Naming flag is turned Off. The only object classes where this flag is turned On are Top, Alias, Person, and Partition.

Ambiguous Container Flag

The Ambiguous Container flag indicates whether the object class has clearly defined containment classes. As a general rule, noneffective classes can be created with ambiguous containment, but effective classes must have nonambiguous containment. Only in special cases can effective classes be created with ambiguous containment. The Alias class object is one of these special cases since it needs to inherit the containment classes of its reference object class.

For most object classes in the base schema, the Ambiguous Container flag is turned Off. It is turned On for object classes Top, Alias, Person, and Partition.

Default ACL Templates

Every object in the NDS tree has an Access Control List (ACL) attribute. 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
The affected attribute [Entry Rights], [All Attributes Rights], or a specific attribute
The privileges

Default ACL templates are defined for specific classes in the base schema and provide a minimum amount of access security for newly created objects. Only base schema objects can have default ACL templates. Developers extending the schema cannot create default ACL templates for new objects.

Since the Top object class defines a default ACL template, all object classes inherit a default ACL template. The ACL defined for Top allows the object that creates another object the right to supervise the created object. This ACL ensures that every object added to an NDS tree has a supervisor.

An object inherits the default ACL templates that are defined for any of the object's super classes. For example, the NCP Server object inherits default ACL templates from Top and Server, and then defines one for itself.

Developers extending the schema cannot create templates that overwrite or add to the templates in the base schema. However, when an object is created in an NDS tree, the creation process can set the object's ACLs to any value, including one that changes a value that comes from a default ACL template.

Construction Rules for Object Classes

The following rules regulate the construction of new object classes. Developers that need to define the new object classes should pay close attention to these rules.

Object class definitions cannot be recursive. That is to say, an object cannot have itself as a super class.
Only classes with complete structure rules can be flagged as effective, and thus used to create objects. This means the super classes, containment, and naming attributes must be complete.
An effective class can be constructed in three ways:
- The class defines its own structure rules
- The class inherits structure rules from its super classes
- The class defines part of the structure rules (such as naming) and inherits the other part of the structure rules (such as containment) from a super class
Structure rules that might be inherited from its super classes are ignored for a class that defines its own structure rules.
If structure rules of an effective class are inherited, they must be nonambiguous.

Attribute Type Definitions

All attributes found in an NDS tree consist of an attribute type and an attribute value, which can be multi-valued. The attribute type identifies the nature of information the attribute stores, and the value is the stored information.

The attribute type definition:

Identifies the attribute syntax used for the value
Specifies the constraints that are imposed on the syntax

These constraints are also known as attribute flags. Attributes are assigned to objects according to the object's class definition.

An example of an attribute type is CN (Common Name) which uses the "Case Ignore String" syntax. CN (Common Name) constrains this syntax to a range from 1 to 64 Unicode characters. This attribute is used by many object classes, including Server, Person, Group, and Bindery Object.

Attribute types can be added to the NDS schema. However, once an attribute type has been created, it can't be modified.

Attribute types can be removed from the NDS schema, but only if the attribute is not part of the base schema and only if the attribute type isn't assigned to a class. All attribute types in the base schema are always flagged nonremovable.

Attribute Syntaxes

The attribute syntax controls the type of information that can be stored in the value (for example, integer, string, or stream data). The syntax must be selected from the set of predefined attribute syntaxes. The syntax also controls the type of compare operations that can be performed on the value. See "Attribute Syntax Definitions" for more information.

Attribute Constraints

The attribute constraints restrict the information that can be stored in the data type and constrain the operations of NDS and NDS clients. The constraints specify whether the attribute:

Allows only a single value or multiple values
Has a range or size limit to the value
Is synchronized immediately, at the next scheduled interval, or never
Is hidden or viewable
Is writable or read-only

The table below lists all of the attribute constraints.

Constraint	Description
DS_SINGLE_VALUED_ATTR	Indicates that the attribute has a single value, with no order implied.
DS_SIZED_ATTR	Indicates that the attribute has an upper and lower boundary. This can be the length for strings or the value for integers. The first number indicates the lower boundary and the second, the upper boundary.
DS_NONREMOVABLE_ATTR	Prevents the attribute from being removed from an object class definition. The client cannot set or modify this constraint flag and thus cannot modify the attribute. All base schema attribute type definitions have the nonremovable flag set.
DS_READ_ONLY_ATTR	Prevents clients from modifying the attribute. The NDS server creates and maintains the attribute.
DS_HIDDEN_ATTR	Marks the attribute as usable only by the NDS server. The client cannot set or modify this flag and thus cannot see or modify the attribute.
DS_STRING_ATTR	Labels the attribute as a string type. You can use attributes of this type as naming attributes.
DS_OPERATIONAL	Indicates that NDS uses the attribute internally and requires the attribute to function correctly.
DS_PUBLIC_READ	Indicates that anyone can read the attribute without read privileges being assigned. You cannot use inheritance masks to prevent an object from reading attributes with this constraint.
DS_PER_REPLICA	Marks the attribute so that the information in the attribute is not synchronized with other replicas. The client cannot set or modify this constraint flag and thus cannot modify the attribute.
DS_SCHEDULE_SYNC_NEVER	Allows the attribute's value to change without such a change triggering synchronization. The attribute can wait to propagate the change until the next regularly scheduled synchronization cycle or some other event triggers synchronization.
DS_WRITE_MANAGED	Forces users to have managed rights on the object that contains this attribute before they can change the attribute's value.
DS_SERVER_READ	Indicates that Server class objects can read the attribute even though the privilege to read has not been inherited or explicitly granted. You cannot use inheritance masks to restrict servers from reading attributes with this constraint.
DS_SYNC_IMMEDIATE	Forces immediate synchronization with other replicas when the value of the attribute changes. Attributes without this constraint are synchronized at the next synchronization interval. In NetWare 5 (NDS release 599 or later) all attributes have this constraint except Back Link, Bindery Property, Bindery Object Restriction, Bindery Restriction Level, Bindery Type, Last Login Time, Last Referenced Time, Login Time, Purge Vector, Reference, Synchronize Up To, Timezone, Transitive Vector, Unknown, and Unknown Base Class.

Attribute Syntax Definitions

An attribute syntax defines a standard data type which an attribute uses to store its values in the NDS tree. The syntax definitions are static definitions represented in basic C-code format. For example, the schema includes the following attribute syntaxes:

SYN_CI_STRING The Case Ignore String syntax is used by attributes whose values are strings and the case (upper or lower) is not significant.
SYN_INTEGER The Integer syntax is used by attributes whose values are signed integers.

An attribute syntax consists of a single data type for which syntax matching rules and qualifiers have been specified. Matching rules indicate the characteristics that are significant when comparing two values of the same syntax. There are three primary matching rules:

Equality To match for equality, two values must be identical, use the same attribute syntax, and conform to the data type of the attribute syntax. Most syntaxes specify a match for equality. NDS checks that the values being matched conform to the data type of the syntax. NDS will not attempt to match two values if the syntax does not specify a match for equality.
Ordering To match for ordering, a syntax must be open to comparisons of less than, equal to, and greater than. For example, 50 is less than 100, and N is greater than B.
Substrings To match substrings, a syntax must be open to search and comparison patterns that include the asterisk (*) wildcard. For example in a syntax using substring matching, n*v*l would match naval, navel, and novel.

An approximate comparison rule can be used in searches and comparisons on syntaxes with lists of strings and syntaxes with distinguished names:

Strings The approximate rule determines whether a string is present in a syntax with a string list.
Distinguished Names The approximate rule determines whether a distinguished name matches the distinguished name in a corresponding field while ignoring the other fields in the syntax. To increase performance, NDS replaces distinguished names with IDs in the comparison and search operations.

A syntax can specify one or more of these matching rules. For example, the Case Ignore String syntax specifies matching rules of equality and substrings.

A syntax can also specify qualifiers for comparison which ignore characters such as dashes, leading spaces, trailing spaces, and multiple consecutive internal spaces. All string syntaxes use comparison operations that ignore extra spaces. Other qualifiers allow only digits or only printable characters.

Attribute type definitions are built on attribute syntaxes. Developers extending the schema can create new attribute types using these syntaxes, but they cannot create any new syntax definitions.

* 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.