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.

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.

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.

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:

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.

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

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

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.

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.

FIGURE 2.9 Examining operational attributes by using DSBrowse.

The Master replica is the first copy of a new partition. When you install a new server into a new tree, that server automatically receives a Master replica of the [Root] partition. If you then create a new partition by using NDS Manager or ConsoleOne, the already-installed server receives the Master copy of that partition as well because it has the Master replica of the parent partition.

As discussed in Chapter 6, the Master replica must be available for certain partition operations, such as a partition join, a partition split, or an object/partition move. The Master replica can also be used to perform NDS operations such as object authentication, object addition, deletion, and modification.

A Master replica may be used to provide bindery emulation services because it is a writable replica type.

Similar to Master replicas, a Read/Write (R/W) replica is a writable replica type that can be used to effect object changes. Unlike Master replicas, however, Read/Write replicas are not directly involved in replica operations. The NDS server installation process will ensure that there exists one Master replica and two “full” replicas. (Filtered replicas do not count, as discussed later in this chapter.) When you install an NDS server into a partition that has only two replicas (one Master and one Read/Write replica, for instance), a third replica (Read/Write) will automatically be added to the new server. You normally create additional Read/Write replicas of a given partition to provide fault tolerance and to provide faster access to eDirectory data across WAN links.

A Read/Write replica may be used to provide bindery emulation services because it is a writable replica type.

The Read-Only (R/O) replica type is seldom—if ever—used. It was added because Novell built NDS based on the X.500 directory standard, which specified Read-Only replicas.

Use of R/O replicas is strongly discouraged. They do not provide any advantages with regard to traffic management because they can actually generate more traffic than a Read/Write replica due to referral and redirection.

Any change directed at a server that holds an R/O replica of a partition would end up being redirected by the server to a server with a Read/Write or Master replica. The change would then be synchronized back to the server holding the R/O replica, through the normal synchronization process.

R/O replicas have been used to provide NDS data lookup, as in the case of an address book application. However, Filtered replicas (discussed later in this chapter) are better suited for these types of applications.

Read-Only replicas cannot be used to provide bindery emulation services because they are not writable.

The Subordinate Reference (SubRef) replica type is the only user-defined replica type that is not actually placed manually. Rather, its creation and deletion are managed automatically by NDS. SubRef replicas are used primarily to provide tree connectivity. In simplest terms, a subordinate reference (subref) is a (downward) pointer to the child partitions. It links a parent partition to a child partition. A SubRef replica contains a complete copy of the partition root object of the child partition. It does not, however, contain any other data for the child partition. A SubRef replica has a complete copy of the partition root object, and it has a Replica attribute that contains the following information:

In essence, a SubRef replica can be considered the glue that binds parts of the NDS tree together.

SubRef replicas cannot be used to provide bindery emulation services because they are not writable. Also, they cannot be used for fault tolerance purposes because they do not contain all the objects of a partition.

eDirectory 8.5 introduced two new replica types: Filtered Read/Write and Filtered Read-Only replicas. A Filtered replica is essentially a Read/Write or Read-Only replica that holds only a subset of the objects or attributes found in a normal Read/Write or Read-Only replica. Filter replicas are used to specify which schema classes and attributes will be allowed to pass during synchronization. A Filtered replica ignores changes made to objects outside the filter.

Filtered replicas can be sparse or fractional replicas. A sparse filtered replica contains only objects of selected object classes. All other objects are filtered and not placed in the local database. A fractional Filtered replica contains only attributes of selected attribute types. All other attributes are filtered and not placed in the local database. A typical Filtered replica is both sparse and fractional because it filters both object classes and attribute types.

Filtered replicas are useful in the following situations:

To create a Filtered replica, you must first create a replication filter on the server that will host the Filtered replica. This replication filter determines which objects and attributes are allowed in the Filtered replicas that reside on the server. You create the replication filter via ConsoleOne.

In addition to the desired classes and attributes stored in a Filtered replica, eDirectory must always synchronize attributes that are critical to the operation of eDirectory. The following schema flags cause the affected object classes and attributes to be included in a Filtered replica:

   SF_SPARSE_REQUIRED—Object classes and attributes designated with this flag will always pass through the replication filter, regardless of the filter settings. The ACL attribute is an example (see Figure 2.15).

FIGURE 2.15 The SF_SPARSE_REQUIRED schema flag, which causes the ACL attribute to pass through a Filtered replica filter.

   SF_SPARSE_DESIRED—This flag allows desired classes and their required attributes to pass through the replication filter.

   SF_SPARSE_OPERATIONAL—This flag identifies classes and attributes that must be cached on Filtered replicas (because they are part of the operational schema). Setting this flag on an object class or attribute type definition guarantees that the class or attribute is created as a reference object if it is not in the replication filter. The DS Revision attribute is an example of this.

eDirectory will also allow any objects referenced by an allowed attribute to pass through the filter in a reference state. For example, say a replication filter allows the object class User and attribute Group Membership but filters the object class Group. The Filtered replica will create the Group object and flag it as a reference object. The Group object is required to ensure database consistency, and the reference tag is used to ensure that the incomplete Group object does not synchronize to other servers.

Container objects in an eDirectory database are also allowed to pass through to any filtered replica. This ensures that all objects beneath the container can be created, if the filter allows them through. Container objects created in this manner are also flagged as reference objects. The Unknown object class is flagged as a container. This causes all objects with an object class type Unknown to also be created as reference objects in a Filtered replica.

Filtered Read/Write replicas can make modifications to objects and attributes that pass through the replication filter. These changes will be passed to all other servers in the replica ring. However, a Filtered Read/Write replica is not allowed to fully participate in the transitive synchronization process (see the section “The Synchronization Process” in Chapter 6) and will not send changes that did not originate in the local database. This is necessary to ensure database consistency for all changes.

Like their Read-Only replica cousins, Filtered R/O replicas cannot make modifications to objects and attributes that pass through the replication filter. Filtered Read-Only replicas can be used for data lookup only.

Each server that contains a replica of the parent partition also contains a Subordinate Reference replica of every child partition that is not physically located on that server. Consider the sample NDS tree shown in Figure 2.16. This tree contains four partitions: Root, A, B, and C. Three file servers—FS1, FS2, and FS3—are installed in this tree, one server in each of the O= containers. Each server holds the only copy of the partition (Master replica) in which the server is contained; the [Root] partition is stored on FS1.

FIGURE 2.16 A sample NDS tree with four partitions.

Table 2.5 shows the replica structure in this tree.

TABLE 2.5 Replica Structure of a Sample NDS Tree

FS1 contains Subordinate Reference replicas because the parent of Partitions B and C, Partition [Root], resides on the server, but Partitions B and C do not. Neither FS2 nor FS3 needs a SubRef replica because neither Partition B nor Partition C has a child partition. If the Master partition of [Root] were placed on FS2 rather than FS1, FS2 would contain Subordinate Reference replicas for Partitions A and C.

The standard LDAP protocol specification does not yet support access to replication, partition, and synchronization services. However, these services are available through (Novell-specific) LDAP extensions that are available for eDirectory 8.5 and higher.

Tables 2.9, 2.10, and 2.11 show controls and extensions supported by eDirectory 8.5 and higher that allow LDAP clients to perform the following request:

TABLE 2.9 LDAP Extensions Supported by eDirectory

Table 2.10 lists the extensions used by the Novell Import Convert Export (ICE) utility. They are not general extensions designed for developer use but are designed to support the LDAP Bulk Update Replication Protocol (LBURP).

TABLE 2.10 ICE-Specific LDAP Extensions for eDirectory 8.5 and Higher

TABLE 2.11 LDAP Controls Supported by eDirectory

Persistent search is an LDAP v3 extension that enables applications to maintain a connection to an LDAP-compliant directory even after that directory has returned the results of a search request. For example, say that an LDAP application searches for all entries in the tree for which the CN attribute has a value beginning with the letter A, and 500 hits are expected. However, this application supports increments of only 10 search results. Using persistent search, this application could receive search results for this request in increments of 10 CN attributes without having to establish a new connection to the directory for each increment. Otherwise, this application would have to establish a new connection and issue a new search request for each increment.

If you are unsure what extensions and controls are supported by the version of the LDAP server for eDirectory that you have, you can query its root DSE by using an LDAP search tool. For example, this is the syntax for using ldapsearch:

The following is an example of some of the output from this command, showing just the supported extensions and controls, from a Windows 2000 server running eDirectory 8.7.3:

The LDAP Server object has a multivalued attribute called extensionInfo, which contains the list of supported controls and extensions supported by that server, as shown in Figure 2.21. To access this screen, you select the LDAP Server object in ConsoleOne and then right-click and select the Properties option from the context menu. Next, you select the Other tab, open the extensionInfo listing, and click the Extended Editor button, which is denoted by an ellipsis (…).

FIGURE 2.21 The extensionInfo attribute of the LDAP Server object.

You can deselect an extension from being supported by the server by deleting the attribute value that corresponds to the extension in question. However, because the attribute value is an octet string (SYN_OCTET_STRING), it could be cumbersome to put it back at a later time. (Note that this is not supported by Novell.) Alternatively, you can edit the value and change the starting E to a D (or basically anything other than E). This deselects the extension. Then you restart the LDAP server for the change to take effect. To reselect the extension at a later time, you change the D back to an E and restart the LDAP server.

LDAP requires a client to employ a two-step process to connect with and authenticate to its back-end directory service. You first need to establish a connection to the LDAP server. This can be either an insecure, clear-text connection (with the default port 389) or a secured, encrypted connection (with the default port 636). Then the client has to perform a bind, the LDAP term for sending user information and password for the purpose of authentication, with the LDAP server. In the case of eDirectory, the supplied user credential is used for authentication against eDirectory, and the level of access is subject to eDirectory security (this includes user-level restrictions such as login time restriction and account lockout due to intrusion detection).

LDAP supports a number of bind methods involving just the use of usernames and passwords. The bind methods defined in RFC 2829, “Authentication Methods for LDAP,” are as follows:

Every LDAP operation requires the client to be bound before the operation is attempted. After the completion of the operation (be it successful or failed), the connection is automatically terminated. Therefore, to perform an add entry operation and then a modify entry operation, you must bind twice. The exception to this rule is if you are using persistent search, where you need to bind only once to retrieve all the search results.

Another feature introduced in LDAP v3 is the ability to apply access control. Access control determines who has rights to entry information in a directory. In an NDS tree, every entry has an ACL attribute, which contains the explicit trustee assignments that have been made to the entry and its attributes. In addition, NDS allows rights to be inherited, so that an assignment in a parent container can allow additional trustees to have access to an entry. Functions that calculate effective rights gather information from these parent containers as well as from the ACL attribute. When an LDAP client queries for effective rights, the result returned by an eDirectory LDAP server is based on the explicit assignments as well as the inherited rights. Directories that do not allow the inheritance of rights implement the functions to return only explicit trustee assignments.

The LDAP server for eDirectory 8.7 also implements support for extensible match search filtering, as defined in RFC 2251. An extensible match allows an LDAP client to specify multiple match rules for the same type of data and to include dn attribute elements in the search criteria. For example, the following extensible match filter searches for all User objects in containers that have OU=Grade5 as part of their DNs:

As you can imagine, this feature allows applications to perform complex searches much more easily. Without it, the client itself has to provide more processing in order to filter out the desired data.

Perhaps the most useful feature of the LDAP Server is LDAP Event Services, which was added to the Novell LDAP server for eDirectory 8.7. LDAP Event Services provides a way, via the standard LDAP extension mechanism, for applications to monitor the activity of eDirectory on an individual server.

LDAP Event Services supports more than 200 events that are divided into the following event types or categories:

The event system extension allows a client to specify the events for which it wants to receive notification. This information is sent in the extension request. If the extension request specifies valid events, the LDAP server keeps the connection open (through the use of the persistent search feature) and uses the intermediate extended response to notify the client when events occur. Any data associated with an event is also sent in the response. This feature provides an easy mechanism for network management applications to include eDirectory in their list of managed services.

The LDAP server for eDirectory automatically maps the DS attributes and classes that are defined in RFC 2256 to their LDAP-equivalent names. Alas, not all DS names can be mapped to LDAP names due to naming convention incompatibility, as discussed earlier in this chapter, in the section “Naming Rules and Restrictions.” If LDAP clients need access to DS classes and attributes that have incompatible names, you need to manually map them to LDAP-compatible names by using ConsoleOne. Even if a name is compatible with LDAP conventions, an LDAP client may still not be able to access a certain attribute because the LDAP server does not support that attribute’s syntax.

eDirectory 8.5 and higher map inetOrgPerson to the DS object class User by default. LDAP clients can access this class by using the LDAP names inetOrgPerson or user. In NDS 7 and NDS 8, by default, the User class definition does not contain all the standard attributes for inetOrgPerson. To add these attributes to the User class definition, you must update the schema by using a schema file (nov_inet.sch), available from Novell. With eDirectory 8.5 and later, however, this is all done automatically for you.

The LDAP server allows LDAP access to DS attributes if the DS attribute uses LDAP-compatible syntax. For example, any DS attribute that uses the case ignore string syntax (SYN_CI_STRING) is available through LDAP because LDAP supports this syntax (which is called directoryString in LDAP). DS attributes that use a compound syntax (such as the timestamp syntax, SYN_TIMESTAMP, with its fields for time, replica number, and event identifier) are not automatically accessible through LDAP. Instead, the LDAP server converts such a syntax to case ignore strings, using dollar ($) signs to separate fields of the same data type and (#) signs to separate fields of different data types. For example, the ACL is represented as follows:

where the first field is the trustee rights value (2 = Read), the next field indicates that it applies to the whole object (subtree), the next field is the object that has been granted the rights (cn=admin,o=testing), and the last field is the attribute name ([All Attributes Rights]). Postal Address is an example of an attribute that uses $ as data field delimiters (because all its data fields are of the type CI string):

The LDAP server converts the DS time information (which uses the SYN_TIME syntax) 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). The Login Time attribute would have a value similar to the following:

If you need to look up the attribute and class mapping between LDAP and NDS, from ConsoleOne you open the LDAP Group object, and from its Properties page, you check the Attribute Mappings (see Figure 2.22) and Class Mappings (see Figure 2.23) tabs, respectively. You can also use these tabs to add, delete, or modify the mapping assignments.

FIGURE 2.22 The Attributes Mappings tab of the LDAP Group object.

FIGURE 2.23 The Class Mappings tab of the LDAP Group object.

Sometimes when an LDAP client issues a request to an LDAP server, the server may not contain the target entry of the operation in its local database. However, the server can use the NDS knowledge references that it has about partitions and other servers in the eDirectory tree to contact another LDAP server that knows more about the DN. This process is called chaining, and it is a server-based form of name resolution. If necessary, the chaining process continues until the first server contacts a server that holds a replica of the entry. eDirectory then handles all the details to complete the operation. The LDAP server performs all this on behalf of the client. Therefore, unaware of the server-to-server operations, the client assumes that the first server completed the request.

Through chaining, an LDAP server provides the following advantages:

Chaining has disadvantages as well as advantages. For instance, the client might have to wait for some time without any feedback from the server while the server chains to resolve the name. If the operation requires the LDAP server to send many entries across a WAN link, the operation might be very time-consuming. If several servers are equally capable of processing the operation, different servers might process two requests to operate on the same entry. In 99% of the cases, this is not an issue. However, depending on the type of operation, the client may receive an erroneous indication that the requested operation—say, deletion of an entry—failed (due to duplicate processing).

Chaining can be bandwidth-intensive for large LDAP search operations. This is because in the chaining mode, the first LDAP server acts as the proxy to the client, where it receives the search results from another LDAP server and then passes the results back to the client; the data is transmitted on the network twice.

In a way, LDAP chaining is similar to NDS’s tree-walking mechanism. However, there is a difference between the two in terms of performance. LDAP chaining requires a bind every time a server is chained to. If the chained-to server does not have the required entry, the overhead spent on the bind operation is wasted, and another bind has to be made to the next server. (The way around this is for the client to first do an anonymous bind to search for the target entry before binding to perform the operation. This does not always work, however, because the anonymous user may not have the necessary browse rights to the target entry, and the client application will have to be smart.) NDS tree-walking, on the other hand, does not require authentication. Only when the target object is located is an authenticated connection made to that server.

Referrals are a client-based name resolution method in which the client decides what to do if the target LDAP server does not have a local copy of the target entry. In this model, whenever a server cannot find the requested DN within its local database, it uses the knowledge reference it has to generate a referral to another server that does have the desired information or knows more about the target DN. The client then makes a new request to the referred server and retries the operation. If the second LDAP server has the target DN for the operation, it performs the request; otherwise, it also sends a referral back to the client. This continues until the client contacts a server that has the entry and can perform the desired operation or until an LDAP server returns an error that the entry cannot be found. The client can also decide to not connect to the next referred server and return an error instead or prompt the user before contacting the referred server.

The main advantage of the referrals-based method is that the client has total control. When the server returns a referral to the client, the referral contains information for each of these other servers. To continue the operations, the client can be smart about which server it picks from the list, or it can prompt the user for a selection. Another advantage is that when the client knows where an entry is located, it can go directly to the server that has the entry for additional operation requests, thus increasing efficiency and reducing network traffic.

The main downside of the referral method is that the client has to be smart and know how to handle and then follow referrals. The other drawback is that an LDAP server must service every partition in the NDS tree. Otherwise, some entries will not be accessible by LDAP clients because no referrals can be generated for data in the partitions that are not serviced by an LDAP server.

LDAP v3 introduced a new type of referral call superior referrals. Superior referrals enable an eDirectory tree to refer directory requests to other directories (such as a separate eDirectory tree or one hosted on a Netscape directory server). This capability enables eDirectory to function as part of a larger directory tree that comprises two or more separate directory trees. In other words, this feature can help companies federate two or more directory trees to function as a single directory tree. For example, suppose your company acquired a subsidiary that is using eDirectory. Your company is not using eDirectory but is using an LDAP v3–compliant directory. Your company wants to add the subsidiary’s directory tree as a branch of its corporate tree. By using superior referrals, you can configure eDirectory to consult your company’s corporate directory to fulfill requests for information that resides in that directory. Superior referrals are supported by eDirectory 8.7 and higher.