The eDirectory Database Structure

     

This section discusses the components that make up the eDirectory database structure. For any kind of database, there exists a set of rules that govern the type of information the database can contain and possible relationships between the different data items contained within. This set of rules is known as the database schema .

In simple terms, eDirectory's schema is a set of rules that stipulate the type of objects that can exist in an eDirectory tree, the possible locations of those objects in the tree, and the information that can and must be maintained about the object. Each object belongs to an object class that specifies which attributes (that is, types of information) can be associated with the object. Every attribute is based on a set of attribute types that are, in turn , based on a standard set of attribute syntaxes .

REAL WORLD: Base Schema and Operational Schema

The term base schema refers to the built-in set of classes and attributes shipped with the eDirectory product itself (that is, it does not include extensions added by other Novell products, such as DirXML or BorderManager). Depending on the situation, the base schema may be extended to include new classes and new attributes for objects. These new definitions, however, must be defined in terms of the existing syntaxes; defining new syntaxes is not allowed. The user -added classes may be removed when they are no longer used, but base classes cannot be removed or modified.

The term operational schema refers to the set of schema rules that are required to be present for NDS /eDirectory to function correctly. If any of the operational schema definitions are deleted or otherwise damaged, DS will fail to function properly.

The eDirectory schema controls not only the structure of individual objects but also the relationship among objects within the DS tree. The schema rules allow some objects to contain other subordinate objects. Thus the schema gives structure to the DS tree. Furthermore, eDirectory implements an object-oriented structure made up of objects that can receive attributes from other objects; this idea is referred to as inheritance in object-oriented paradigms .

NOTE

The concept of inheritance is simple: Any property or attribute defined at a higher level of the hierarchy automatically flows down and is available for use at the lower levels.

NOTE

You can find the set of schema files used by eDirectory installation in the SYS:SYSTEM\SCHEMA directory on a NetWare server, C:\Novell\NDS folder in Windows, or under /usr/lib/nds-schema on Unix/Linux.

Classes

A class in eDirectory is a definition for an object type. Classes you are likely to be most familiar with are the User class, Print Queue class, and the NCP Server class. Each class definition contains a list of properties (known as attributes ) that are used to describe the class. In essence, the class definition is a blueprint or set of rules for how to make an object of a specified class.

REAL WORLD: What Is an eDirectory Object?

In a way, you can consider a class to be a skeleton or template for an eDirectory object; an eDirectory object is a class that has been populated with information. In other words:

Class + Data = eDirectory object

When you create an object in your eDirectory tree, you select a class as a starting point in defining the object. The class acts like a request form for a specific type of eDirectory object. After the class is selected, you in a sense fill in the "request form" with essential and specific information (such as the object name and any associated attribute values) on the new eDirectory object.

There are three categories of classes: the effective class, the non-effective class, and the auxiliary class.

An effective class is a class that can be used to make objects that actually show up in the eDirectory tree. User , Print Queue , and NCP Server are examples of effective classes; if you search the eDirectory tree using NetWare Administrator or ConsoleOne, you can find objects that are of these types.

A non-effective class is a class whose objects do not appear in the eDirectory tree but is used to build other non-effective and effective classes. This allows classes to simply inherit the class information from the non-effective superclass rather than repetitively define it. Examples of non-effective classes are the Person , Queue , and Server classes, as illustrated in Figure 2.2.

Figure 2.2. An example of the NDS/eDirectory class hierarchy.

You can use NDS Snoop to manage and examine your schema. You can download a copy of Snoop from www.novell.com/coolsolutions/nds/features/a_ndssnoop_nds.html. Because NDS Snoop can modify the schema and NDS objects, you need to be careful when using it. Figure 2.3 shows the class hierarchy of the User class, as viewed in NDS Snoop.

Figure 2.3. Viewing class hierarchy by using NDS Snoop.

NOTE

In essence, a non-effective class can be considered a placeholder for a group of attributes. A non-effective class cannot be used to create objects but can be specified as a class from which other classes can inherit attributes.

All objects of a given effective class carry the same set of properties associated with the effective class and its parent classes (which are referred to as superclasses ). There are, however, circumstances in which a set of attributes needs to be added to only a subset of objects of a given class rather than to all the objects of that class. This is where auxiliary classes come in.

NOTE

The base schema defines the following non-effective classes:

• ndsLoginProperties

• Partition

• Resource

• Server

Although Top is flagged as an effective class, no object can be created by using the Top class.

NOTE

Starting with NetWare 5, the schema class Tree Root ( T= ) is used to indicate the top of the tree. Previously, this was referred to as [Root] . Therefore, you will find documentation and utilities still making references to [Root] , especially when discussing NDS partitioning and related concepts.

An auxiliary class is a class whose set of attributes can be added to particular eDirectory object instances rather than to an entire class of objects. For example, a network monitoring application could extend the schema of your eDirectory tree to include an On-Call Pager auxiliary class. You could then extend individual User objects with the attributes of the On-Call Pager class as needed by adding the auxiliary class to the Object Class attribute of the User object. When the auxiliary class is added, the object inherits all the attributes of the auxiliary class while retaining all its own attributes. When the auxiliary class is removed from the object, the auxiliary class attributes are removed from the object, and the object no longer has access to those attributes.

The following are some rules for using auxiliary classes:

• The Object class flag should only set the Auxiliary class flag.

• Auxiliary classes cannot have the Container flag set.

• Auxiliary classes cannot have the Effective class flag set.

• Creation fails if rules are not followed.

• Auxiliary classes can have mandatory attributes, optional attributes, or both. (DS will not add an auxiliary class to an object without values for all mandatory attributes.)

• Auxiliary classes are not required to have superclasses but may contain superclasses.

• Auxiliary classes should not contain Top as a superclass or define containment.

• Auxiliary classes and superclasses are combined.

• Attributes of an auxiliary class and a superclass are deleted if the auxiliary class is removed.

• Auxiliary classes can define naming attributes. (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.)

WARNING

When additional attributes are added to class definitions shipped with eDirectory (which are known as base classes), these extensions cannot be removed. On the other hand, you can remove an auxiliary class definition from the schema when you no longer need it. For instance, if you added an On-Call Pager attribute directly to the User class, you cannot remove this attribute at a later time. If you have defined an auxiliary class that contains this On-Call Pager attribute and associated this auxiliary class to existing User objects, however, you can later delete the auxiliary class when no more User objects are using it.

NOTE

Auxiliary classes are supported only by NDS 8 and higher. That is to say, NetWare 4.x (which runs NDS 6) and NetWare 5.x servers running NDS 7 do not support auxiliary classes. Objects containing auxiliary classes will be displayed as Unknown objects (but they are still known on the servers running NDS 8 or higher).

TIP

If you have a mixed- NDS -version environment that includes NDS 6 and 7, you need to ensure that you are using the latest DS.NLM updates. You can also refer to TID #10083622 for more information.

Every class in eDirectory has at least one superclass (as illustrated in Figure 2.2), with the exception of the Top class. Top is where all classes start their inheritance. This means all classes in eDirectory contain some attributes that are common to all ”those defined in the Top class. Some of these common attributes are ACL , Back Link , CA Private Key , CA Public Key , Equivalent to Me , GUID , and Revision .

NOTE

Appendix C, "eDirectory Classes, Objects, and Attributes," lists some of the most commonly encountered object class and base attribute definitions found in an NDS /eDirectory tree.

The following are some of the schema changes made since NDS/eDirectory 8:

• ndsLoginProperties is a new non-effective class. It contains all the attributes required for an object to authenticate to the DS tree.

• The Person and Organizational Person classes are now effective classes, and because they now inherit the required login attributes, Person and Organizational Person objects can log in to the DS tree.

• The ability for Country , Locality , Organization , and Organizational Unit class objects to contain domain objects comes with the installation of NDS 8 and higher. The domain (not to be confused with Windows NT or Active Directory domain) and dcObject classes and the dc attribute were introduced to support RFC 2247, "Using Domains in LDAP/X.500 Distinguished Names ."

domain objects can contain all the leaf objects in the operational schema. The ability for domain objects to contain container objects such as Country , Locality , Organization , or Organizational Unit , however, does not come automatically. This functionality must be added to the schema by running the Optional Schema Enhancement option (see Figure 2.4) in DSRepair, which is for eDirectory 8.5 or higher.

Figure 2.4. Extending schema containment functionality.

Attributes

Attributes are used to define the various aspects of an object. Examples of attributes associated with a User class object are be Surname , Full Name , and Network Address . Each of these holds a piece of information relevant to the User class object in question.

NOTE

Novell documentation and utilities use the terms property and attribute interchangeably to mean the same thing.

It is important to understand other aspects of attributes. The first of these aspects is the idea of a mandatory attribute. A mandatory attribute is an attribute that is required in order for the object to be created; if a mandatory attribute is missing, the object cannot be created. The Surname attribute, for example, is required when creating a user. That is to say, if you do not provide the user's surname, you will be unable to create the User object.

TIP

With many of the DS -aware utilities, when one or more of the mandatory attribute values have not been supplied, the Create or OK button is grayed out, preventing you from creating the object.

Loss of a mandatory attribute after creation of the object causes the object's class attribute to be changed to Unknown . Figure 2.5 shows ConsoleOne with several Unknown objects in the tree. The circles with the question marks in the figure are yellow, making the Unknown class objects easy to spot.

Figure 2.5. An example of Unknown class objects in ConsoleOne.

There is a second type of object seen in NetWare Administrator, ConsoleOne, and other management utilities that many people mistake for an Unknown class object. This type of object appears either as a white square with a black question mark inside it in NetWare Administrator (see Figure 2.6), a cube with a black question mark beside it (see Figure 2.7), or a white dog-eared rectangle with a black question mark inside it in NDS iMonitor (see Figure 2.8). This particular type of object is not of the Unknown class but means that the necessary snap-in component for NetWare Administrator, ConsoleOne, or NDS iMonitor/iManager is not available, and consequently the object cannot be administered with the tools. Such objects are referred to as unmanaged or unmanageable objects.

Figure 2.6. An example of unmanageable objects in NetWare Administrator.

Figure 2.7. An example of unmanageable objects in ConsoleOne.

Figure 2.8. An example of unmanageable objects in NDS iMonitor.

The opposite of a mandatory attribute is an optional attribute . As the name implies, this is an attribute that is not necessary to create the object in question. The Full Name attribute of the User class is an example of an optional attribute. It can be present in the object that has been created, or it can be omitted.

Attributes can also be single valued or multivalued. A single-valued attribute, such as the Surname attribute, can contain only one value. If you change that value, the old value is replaced with the new one.

A multivalued attribute is an attribute that can contain a number of entries. The Network Address attribute is such an attribute. It can contain one entry for every workstation a user has logged in to, and when you look at the list in management tools such as NetWare Administrator or ConsoleOne, you may see multiple values listed, one for each station the user is logged in to.

REAL WORLD: Operational Attributes

In NDS /eDirectory, not all information about an object is kept in attributes. For example, an object's base class name, last modified time, and creation time are not stored as standard attributes but are stored in operational attributes . These attributes are related with the operational status of an object. The following is a list of operational attributes:

• createTimeStamp ” Shows when the object was created. (This is also a standard LDAP attribute.)

• creatorsName ” Shows the distinguished name ( DN ) of the user that created the object. (This is also a standard LDAP attribute.)

• entryFlags ” Indicates the object's state, such as whether the object is an alias, a container, or a partition. (This is a DS -specific attribute.)

• federationBoundary ” Shows where the federation boundary begins for a Domain Name Service ( DNS )-root tree. (This is a DS -specific attribute.)

• localEntryID ” Shows the object ID or record number for the object in the server's local database. (This is a DS -specific attribute.)

• modifiersName ” Shows the DN of the last user that modified the object. (This is also a standard LDAP attribute.)

• modifyTimeStamp ” Shows when the object was last modified. (This is also a standard LDAP attribute.)

• structuralObjectClass ” Shows the base class of the object. (This is also a standard LDAP attribute.)

• subordinateCount ” Shows the number of objects immediately subordinate to this object. (This is a DS -specific attribute.)

• subschemaSubentry ” Shows the LDAP name for the schema location. For eDirectory, it is cn=schema . (This is also a standard LDAP attribute.)

An object's information is read-only by the clients and maintained by DS . Figure 2.9 shows some of these operational attributes, as they appear in the DSBrowse NetWare Loadable Module ( NLM ).

Figure 2.9. Examining operational attributes by using DSBrowse.

Each class has one or more attributes designated as naming attributes (referred to with Named By in the schema definition) used to name the actual objects. These attributes can be either mandatory or optional, but you must give at least one of them a value when creating an object of that class. If the only naming attribute is declared as optional, it is, in effect, considered to be mandatory.

Naming attributes can be multivalued; in other words, more than one name (value) can be added to the naming attribute. For example, a User object can have both Tasha and Chelsea as values for the CN attribute. (Additional CN entries are associated with the Other Name field found in tools such as ConsoleOne and NetWare Administrator.)

Some object class definitions specify multiple naming attributes. For example, the NetWare server license container object is of the NLS:Product Container object class and is named by three attributes NLS:Publisher , NLS:Product , and NLS:Version . An example of a typeless relative distinguish name (RDN) for such an object is

 Novell+NetWare 6 Server+600 

where plus signs ( + ) are used to indicate where the additional attributes' values begin.

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 ) attribute. In such names, the naming attribute itself does not indicate which class the object belongs to, but the value of the naming attribute might suggest the nature of the object. For instance, the Security container found in eDirectory trees uses CN as its naming attribute. However, some naming attributes are closely tied to specific classes. For example, the C ( Country Name ) attribute is used to name only Country objects.

It is a common misconception that all leaf objects in a DS tree have CN in their typeful partial name (for example, CN= objectname ). Because there is no (schema) rule stating that one must use CN as the naming attribute for a leaf object, not all leaf objects have CN in their typeful partial names. The License Certificate object is an example of such an object (see Figure 2.10). It uses NLS:License ID as the naming attribute.

Figure 2.10. License Certificate objects do not use CN for their naming attribute.

Attribute data can be represented in many different forms in the eDirectory database. In defining an attribute, you also need to define the format used to store the data. This format is called the syntax .

Syntaxes

Another important piece of the database structure to be aware of is syntax ”a definition for what format an attribute's data is in, such as "this is a text string" or "this is to be interpreted as a network address." Table 2.2 lists all 28 syntaxes employed in every NDS/eDirectory tree. The syntax names are given in standard C-code format. Also listed in the table is the minimum DS version needed for accessing those syntaxes via LDAP.

Table 2.2. eDirectory Attribute Syntaxes

SYNTAX ID	SYNTAX ID VALUE (DECIMAL)	LDAP NAME	DESCRIPTION	MATCHING RULES	ATTRIBUTE EXAMPLE	MINIMUM DS VERSION FOR LDAP
SYN_BACK_LINK	23	taggedName	Used by DS for the Back Link attribute.	Equality Approximate (not supported through LDAP)	Back Link	eDirectory 8.5
SYN_BOOLEAN	7	boolean	Represents a true/yes (1) or false/no (0) value	Equality	Password Required	NDS 7
SYN_CE_STRING	2	IA5String	A text string for which the case (upper- or lowercase) is significant when performing comparisons. ( CE stands for "case exact.")	Equality Substring (that is, may use * as a wildcard match pattern)	NDSCat:Attributes	NDS 7
SYN_CI_LIST	6	caseIgnorelist	An ordered sequence of text strings for which the case (upper or lowercase) is not significant when performing comparisons.( CI stands for "case insensitive.")	Equality Approximate	Language	NDS 7
SYN_CI_STRING	3	directory String	A text string for which the case (upper- or lowercase) is not significant when performing comparisons.	Equality Substring	Full Name	NDS 7
SYN_CLASS_NAME	20	oid	A text string representing object class names	Equality	Object Class	NDS 7
SYN_COUNTER	22	counter	A signed (32-bit) integer value. (The value range of a signed integer is ±2147483648.)	Equality Ordering (such as less than, equal to, and greater than)	Grace Login Remaining	eDirectory 8.5
SYN_DIST_NAME	1	dn	A text string that denotes the DN of an NDS object. (The value is not case sensitive.)	Equality	Dn	NDS 7
SYN_EMAIL_ ADDRESS	14	taggedString	A value that represents an email address and its type (such as GroupWise or Internet)	Equality	Email Address	eDirectory 8.5
SYN_FAX_NUMBER	11	faxNumber	A text string that complies with the inter nationally agreed format for showing international telephone numbers , E.123, and an optional bit string formatted according to Recommendation T.30.	Equality	Facsimile Telephone Number	NDS 7
SYN_HOLD	26	N/A	A value that is composed of a server name and a signed integer number. (NetWare Accounting uses this. Each time a server is about to perform an action that will be charged against a user's account, the server makes sure the account has a sufficient balance. To do this, the server places a hold (via the Server Holds attribute) against an object's balance, which is an estimate of what the final charge will be. If the hold is successful, sufficient balance remains and the action is performed. When the action is completed, the hold is cancelled, and a true charge for the actual amount is made against the object's balance. When a hold is pending, this attribute contains the name of the server requesting the hold and the total hold amount. LDAP does not currently support the Hold syntax; therefore, LDAP clients cannot access this attribute.)	Equality Approximate (not supported through LDAP)	Server Holds	Unsupported
SYN_INTEGER	8	integer	A signed integer value.	Equality Ordering	Login Maximum Simultaneous	NDS 7
SYN_INTERVAL	27	integer	A signed integer value that presents the amount of time in seconds.	Equality Ordering	Intruder Lockout Reset Interval	NDS 7
SYN_NETWORK_ADDRESS	12	taggedData	A value that represents a network address. It consists of the address and its type (such as Internet Protocol [IP] or Internetwork Packet Exchange [IPX])	Equality	Network Address	eDirectory 8
SYN_NU_STRING	5	numericString	A numeric value that is a text string format,as defined in CCITT X.208.	Equality Substring	International iSDNNumber	NDS 7
SYN_OBJECT_ACL	17	ndsAcl	A value representing the access control list (ACL) entries of an object.	Equality Approximate	Inherited ACL	eDirectory 8
SYN_OCTET_LIST	13	octectList	An ordered sequence of octet strings.	Equality (must match on the size of the list and for each string in the list)Approximate (only one string in the list needs to match)	WANMAN:WAN Policy	eDirectory 8.5
SYN_OCTET_STRING	9	octetString	A list of byte strings used to represent information in a proprietary format. (DS does not interpret the information.)	Equality Ordering	CA Public Key	NDS 7
SYN_PATH	15	taggedName AndString	A value representing a file system path. (The information includes namespace, volume, and path .)	Equality Substrings Approximate (not supported through LDAP)	Home Directory	eDirectory 8
SYN_PO_ADDRESS	18	postalAddress	A text string containing postal address information. The case (upper- or lowercase) is not significant when comparing strings.	Equality	Postal Address	NDS 7
SYN_PR_STRING	4	printable String	A string of characters that represents a printable string, as defined in CCITT X.208. The case (upper- or lowercase) is significant when performing comparisons.	Equality Substrings	Serial Number	NDS 7
SYN_REPLICA _POINTER	16	ndsReplica Pointer	A value composing of five parts : complete name of the server holding the replica, replica type (for example, Master ), replica state (for example, On), replica ID, and referral information. (Matching is based on server name only and is case insensitive.)	Equality Approximate (not supported through LDAP)	Replica	eDirectory 8.5
SYN_STREAM	21	binary	Used for login script, print job configuration information, and other stream-based data.	None (Streams are files of information. The data stored in a stream file has no syntax enforcement of any kind. It is purely arbitrary data, defined by the application that created and uses it. Therefore, no matching is possible.)	Login Script	NDS 7
SYN_TEL_NUMBER	10	telephone Number	A text string that complies with the internationally agreed format for showing international telephone numbers, E.123, and an optional bit string formatted according to Recommendation T.30.	Equality Substrings	Telephone Number	NDS 7
SYN_TIME	24	generalized Time	A signed integer number representing the number of seconds since midnight, January 1, 1970, UTC. The LDAP server converts the DS time to the LDAP format specified by X.208, which includes the year, month, day, hour , minute, optionally seconds, and time zone (GMT is recommended by X.208 for the time zone and uses Z as its symbol). An attribute with an LDAP time syntax would have a value similar to the following: 200412241032Z or 20041224103200Z .	Equality Ordering	Login Expiration Time	NDS 7
SYN_TIMESTAMP	19	ndsTimestamp	A value that marks the time when a particular event occurred or will occur. It has three components: the number of seconds since midnight, January 1, 1970, UTC; the replica number identifying the server that created the timestamp; and an event ID that orders events occurring within the same whole-second interval (the event number restarts at one for each new second).	Equality Ordering	Synchronized Up To	eDirectory 8.5
SYN_TYPED_NAME	25	typedName	A value representing a level (indicating the priority) and an interval (indicating the frequency of reference) associated with an object.	Equality Approximate (not supported through LDAP)	Notify	eDirectory 8.5
SYN_UNKNOWN		unknown	Used for attributes whose attribute definition was deleted from the schema.	Equality Ordering	Auxiliary Class Flag	NDS 7

NOTE

Attribute type definitions are built on attribute syntaxes. For example, the On-Call Pager attribute is of the type SYN_TEL_NUMBER . Software developers extending the schema can create new attribute types by using these predefined syntaxes, but they cannot create any new syntax definitions.

NOTE

The nwdsdefs.h C header file of the Novell Developer Kit ( NDK ) also shows a SYNTAX_COUNT (decimal value 28) definition. It is not a syntax type, but it shows the number of syntaxes defined.

Matching rules indicate the characteristics that are significant when comparing two values of the same syntax. The approximate comparison rule is used in searches and comparisons on syntaxes with lists of strings, and it can also be used with syntaxes that have multiple fields and an ID field:

• Strings ” The approximate rule determines whether a string is present in a syntax with a string list.

• IDs ” The approximate rule determines whether an ID matches the ID in a corresponding field while ignoring the other fields in the syntax. Although most of the application programming interface (API) structures for syntaxes require an object name, NDS replaces these names with IDs in the comparison and search operations.

Bear in mind that this NDS approximate matching rule is quite different from the LDAP approximate matching rule. In LDAP, approximate matching (known as soundAlikeMatch ) means that the names sound similar. NDS does not support this type of matching; implementation of approximate matching rules is not a must for LDAP servers, as per RFC 2252.

Default ACL Templates

Every object in the DS tree has an (optional) ACL attribute so you can control and protect the object and its attribute values from being modified. The ACL 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 that contain the following:

• The trustee name (full DN [FDN])

• The attribute in question: [Entry Rights] , [All Attributes Rights] , or a specific attribute

• The privileges (such as Browse or Write)

Default ACL templates are defined for specific classes in the base schema and provide a minimum amount of access security for newly created objects. This permits ACL values to be assigned automatically when the object is created, without manual intervention. The Top class defines a default ACL template:

Object Name	Default Rights	Affected Attributes
[Creator]	Supervisor	[Entry Rights]

This allows the object that creates another object to have full control (Supervisor rights) over the created object. Because of class inheritance, all object classes get this default ACL template. As a result, all objects created have at least one ACL assignment made upon their creation. The purpose of this ACL is to ensure that every object added to the DS tree is manageable, unless manually changed later.

NOTE

At some companies, the DS administrator sets up some help desk users that have Create (but not Delete) rights in certain containers in the tree so the help desk can, for instance, create users and groups when necessary but not allow them to delete anything. Because of this default ACL template from the Top class, however, these help desk users will be able to delete the objects they created, thus defeating the intention , unless extra steps are taken. See Chapter 15, "Effectively Setting Up eDirectory Security," for details on how to best set up help desk rights.

Because an object inherits the default ACL templates that are defined for the object class and its superclasses, the overall ACL template is the sum total of all default ACL templates of its superclasses plus any defined for that object class. For example, the NCP Server object inherits default ACL templates from Top and Server and then defines one for itself, as follows :

Object Name	Default Rights	Affected Attributes	Class Defined For
[Creator]	Supervisor	[Entry Rights]	Top
[Self]	Supervisor	[Entry Rights]	Server
[Public]	Read	Network Address	Server
[Public]	Read	Messaging Server	NCP Server

The net effect is that the user who creates an NCP Server object in the tree and the server itself are granted Supervisor rights to this NCP Server object, and the other objects in the tree (through [Public] ) have Read access to the server's Network Address and Messaging Server attributes.

There are two situations in which the default ACL template values are not applied:

• The code that creates the object 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.

NOTE

Only base schema objects can have default ACL templates. Software developers extending the schema cannot create any default ACL templates for new objects. When an object is created in the tree, however, 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.

Naming Rules and Restrictions

If you are considering extending your schema, using either standard classes or auxiliary classes, you should be aware of the naming rules and restrictions of class and attribute names. For a new class name or attribute name to be a valid NDS name, it must fit two criteria:

• The name cannot exceed 32 characters. Spaces are allowed but are counted as part of the 32-character limit. Spaces are not recommended because they are not allowed in LDAP schema names.

• The name must be unique in its level of hierarchy in the NDS tree. Names are case-insensitive, although case can be used for easier visual discrimination.

For example, NDS considers Accounting and accounting to be the same and will not allow two class names or two attribute names different only in capitalization to be created. However, NDS does allow the same name to be used for a class name and an attribute name. Thus Accounting could be the name of a class and accounting the name of an attribute. For example, NDS has defined a number of classes and attributes with the same name: User (class) and User (attribute), Queue (class) and Queue (attribute), and Resource (class) and Resource (attribute).

If you want an application to also work with LDAP applications, your schema extensions should conform to the LDAP naming conventions, which are more restrictive than NDS schema naming conventions. When creating an LDAP schema name, you must conform to the following rules:

• Use alphanumeric characters. LDAP allows one hyphen in a name. The hyphen is the only non-alpha-numeric character allowed, and it cannot start the name. It is recommended that a name contain only alphanumeric characters, without a hyphen.

• Start with an alphabetic character. Numeric characters cannot start a name, nor can a hyphen.

• Do not include spaces.

• Create a unique name for the type (class or attribute). Note that like NDS, LDAP names are not case-sensitive.

• Do not create a name with more than 32 characters. This is actually an NDS restriction. LDAP allows longer names, but NDS does not currently support names longer than 32 characters. (At the time of this writing, there is no RFC that specifies any size limits for the various LDAP entities, such as class names or DNs.)

NOTE

The restriction on alphanumeric characters and one hyphen in the name applies only when dealing with the LDAP schema. Objects in an LDAP -compliant directory may contain multiple hyphens as well as metacharacters such as + and ; . If one of the following characters appears in the name, it must be escaped using the backslash character ( \ ):

• A space or # character occurring at the beginning of the string

• A space character occurring at the end of the string

• One of these characters: , + " \ < > ;

A typical LDAP convention is to lowercase the first word in the name and then capitalize the initial letter of other words that make up the attribute's or class's descriptive name. If the name is composed of a single word, it is generally used as all lowercase. Here are some examples:

chair

leatherChair

importedSofaBed

NOTE

For more information about LDAP and NDS integration, refer to the section "The LDAP Server for NDS," later in this chapter.

The following is a brief review of some of the NDS object naming rules and conventions:

• NDS treats underscores the same as spaces. Therefore, name has spaces is the same as name_has_spaces . Consequently, if a DS object is called name_has_spaces , Novell's LDAP server would return that object as the result for a search query for name has spaces .

• The RDN or partial name is the name of the object itself and does not include names of its parent objects (for example, CN=Tasha ).

• The DN or FDN is the full name of an object, which includes the names of its parent objects. It is referred to as the complete name in some cases. An example is CN=Tasha.OU=Customer_Service.O=Company .

• The NDS context identifies an object's location within the NDS tree. It is a list of all the container objects leading from the object toward the top of the tree, called [Root] . Each NDS client (which may be a workstation, a workstation-based utility, or a server-based application) maintains a name context. When an RDN is used, the name is expanded with the addition of the name context to the name, thus forming an FDN, before being passed to DS.

  NOTE

  An object is exactly, and uniquely, identified by its DN . No two objects can have the same FDN . Furthermore, no two objects can have the same RDN if they both exist in the same context, even if they are of different object classes. For example, NDS will not allow you to create a user called Tasha Golden and a group called Tasha_golden in the same container because names are case-insensitive and underscores are the same as spaces.

  
  

• A typeful object name uses attribute type abbreviations (based on the naming attributes) to distinguish between the different container types and leaf objects in an object's DN or RDN.

  If you do not provide a typeful object name, NDS uses the following guidelines, known as the default typing rule, for the attribute types for each object:

  • The leftmost object is assumed to be CN= .

  • The rightmost object is assumed to be O= .

  • All intermediate objects are assumed to be OU= .

  NDS, however, is smart enough to automatically determine whether the leftmost object is a leaf or container object and derive a proper type for it.

  NOTE

  A typeful FDN is also known as a canonical name : a name that includes a full naming path with a type specification for each naming component. DS operates on canonical names only.

  
  

  TIP

  The default typing rule is only applied to untyped portions of a name; typed objects are not touched. For example, the default naming rule will expand the typeless name Kim.Webservices.L=Novell.Company to CN=Kim.OU=Webservices.L=Novell.O=Company .

  
  

  WARNING

  The fact that the default typing rule always assumes that the rightmost object is an Organization object ( O= ) and the leftmost object is an object named by CN= poses a problem to applications if the object's topmost container is not an Organization object or if its naming attribute is not CN (as is the case for the License Certificate object). For example, if you have a Country object at the top of your tree and try to use a typeless name similar to Kim.Webservices.L=Novell.Company.C=US , you might expect the converted name to be CN=Kim.OU=Webservices.L=Novell.O=Company.C=US . Unfortunately, what you get is CN=Kim.OU=Webservices.L=Novell.OU=Company.C=US . This is because the rightmost object is already typed, and the default typing rule says that all intermediate objects are assumed to be OU= (unless they're already typed.

  
  

• A typeless name does not include any of the object attribute types. For example, the typeless FDN for CN=Tasha.OU=Customer_Service.O=Company is Tasha.Customer_Service.Company .

NOTE

There is no published guideline that a DS -aware application needs to support typeful or typeless naming. Therefore, it is all up to the developer. A " well-written " utility will accept an object name in either format. However, some accept only typeful names. In most cases, unless specified, you should try the typeless name first ”it is easier to type. But if the object is located in a tree branch that contains Country , Locality , or domain objects, you need to use the typeful name.

You should also be familiar with the significance of periods in DS object names. NDS uses periods as delimiters between object names in the context. This means you should not use periods when naming objects. If there is a need, however, you can use periods; ConsoleOne allows you to create an object that has embedded periods. With other tools, however, you must escape the period by using a backslash (for example, enter the name as firstname \.lastname ). Note that ConsoleOne permits the creation of such an object without having to escape the period and shows the object as firstname.lastname (see Figure 2.11), but other tools do not (see Figure 2.12).

Figure 2.11. ConsoleOne, showing a User object containing a period in its name.

Figure 2.12. NetWare Administrator, showing a backslash in an object name.

An LDAP query of an NDS object that has embedded periods in its name will result in the name without the periods being escaped. That is, the object will appear as firstname.lastname and not firstname\.lastname , as shown in Figure 2.13.

Figure 2.13. LDAP, not showing escaped periods in object names.

NOTE

To log in as a user that has embedded periods in the name, you must escape each period when entering the name, unless the application you use takes care of that for you.

We have all become familiar with using a leading period in an object name to mean that the name is to be treated as an FDN and that the name context information should not be added to it. However, there is also a trailing period rule that not everyone is aware of. Each trailing period in a name tells DS to remove one object name from the left side of the name context before appending the remaining names to the RDN. For example, say your current name context is OU=Department1.O=Company and you specified the following RDN:

 CN=Admin. 

DS will remove one name ( OU=Department1 ) from the left side of the name context and append the remaining name to the RDN ( CN=Admin ), producing the following FDN:

 CN=Admin.O=Company 

Multiple trailing periods can be used to move up multiple levels in the tree; some utilities (such as CX.EXE ) will return an error if you specify too many trailing periods, taking you past the [Root] level in the tree.

NOTE

You cannot use the leading period rule in conjunction with the trailing period rule. An entry such as .CN=admin. would result in an error.

TIP

The trailing period rule can come in handy when your current name context is set to Container A (for example, containerA.department.company ) but you need to specify an object name from Container B (whose context is containerB.department.company ). Instead of changing your current context or having to enter a long FDN such as objectname.containerB.department.company , you can simply type objectname.containerB. .

The RDN of a DS object is limited to 128 characters, and the FDN can be a maximum of 256 characters. However, the total number of intermediate containers you can specify in a typeful FDN is less than in its typeless variant, due to the overheads in typeful naming. Table 2.3 summarizes the maximum number of characters allowed in the various categories of names.

Table 2.3. NDS Object Naming Restrictions

NAME CATEGORY	MAXIMUM NUMBER OF CHARACTERS
NDS RDN	128
NDS DN	256
NDS schema class name	32
NDS schema attribute name	32
Tree name	32
SAP service name	47

NOTE

Bear in mind that although the maximum number of characters allowed for an RDN is 128, most of the DS objects' RDNs are actually restricted to 64 characters. This is because they use CN as the naming attribute, and CN is defined to be a 64-byte case-ignored string. This limitation is causing some headaches in situations where long Internet domain names are used and NetWare 6.5's certificate service (Novell Modular Authentication Service [ NMAS ]) is unable to create key material objects (KMOs) ”digital certificates ”because a KMO object name includes the server name plus domain name. As a result, you cannot use secure Web services on these servers. Novell is aware of this shortcoming, and a longer CN limit may be introduced in a future release of eDirectory.