Overview of Novell Directory Services

Articles and Tips: article

NANCY CROSSEN
Technical Writer
Internet/Intranet Division

JOHN WILLIAMS
Technical Writer
Internet/Intranet Division

SELBY HERRIN
Software Engineer
Internet/Intranet Division

01 Mar 1997

Discusses the following features of NDS: schema, naming, entry management, relationship management, NDS personalities, local event services, authentication, and authorization.

Introduction
Schema
Naming
Entry Management
Relationship Management
NDS Personalities
Local Event Services
Authorization
Tracing and Logging

Introduction

Novell Directory Services provides the following features that make it an advanced global, distributed, replicated, and partitioned directory service:

Schema
Naming
Entry management
Relationship management
NDS personalities
Local event services
Authentication
Authorization

Schema

The NDS schema consists of the set of rules governing the structure of the Directory tree. It defines the objects that can exist in the tree, including how entries may be constructed, which attribute values are permitted, how Distinguished Names may be built, and other characteristics of use to the Directory itself. These object and attribute rules are specified through a data dictionary that provides a standard set of data types from which objects can be created.

Every object in the Directory belongs to an object class that specifies the attributes that can be associated with the object. All attributes are based on a set of standard attribute types, which in turn are based on standard attribute syntaxes.

The Directory schema controls the structure of individual objects and the relationship among objects in the tree. In controlling this relationship the schema specifies subordination among object classes.

The set of rules that controls the creation of a particular object type is called an Object Class. Each object class is defined in terms of attributes or properties. An attribute is a specific piece of information that can exist for an object. Attributes, in turn, are defined in terms of a base set of data types called Attribute Syntaxes. The attribute syntaxes define the primary data types for values stored in the Directory. The schema thus dictates the requirements, limits, and relationships of objects and attributes of objects that can be created and used in the Directory tree.

Dynamic Schema

The schema is extensible and dynamic in that administrators can define new objects classes and attributes of objects in addition to those provided by the base schema. Extending the schema is accomplished through modifying or creating new object definitions (attribute or object class) and then adding these new definitions to the base schema.

Because the schema has been moved into the regular hierarchical object space in the Directory Information Tree (DIT), schema objects generally are named and behave as normal NDS objects in instantiation, synchronization, and modification. Additionally, the normal NDS functions in the DSAPIs can be used to manipulate schema definitions (create, browse, modify, etc.).

A schema maintenance utility, Schema Manager, allows administrators to easily modify the NDS operational schema. The Schema Manager allows administrators to view, extend, modify, print, compare, and diagnose their NDS schema. It also provides support for developers and ISVs who need to extend the schema for their applications.

Global Schema

The basic NDS release is restricted to a single partition in the NDS tree, thus the schema is global to that tree by default.

Naming

The NDS name service maps network names to addresses. It is an object-oriented, global information database that uses a hierarchical name space rather than a flat name space. This hierarchy allows the database to be mapped as a tree that can be partitioned by its subtrees. Because object names contain the hierarchy information, users can access network resources globally, and administrators can administer the entire tree and its objects from a single point.

NDS Objects and Attributes

NDS consists of objects and attributes based on an extensible schema. Objects are represented on each server by a physical entry. The schema contains the rules for forming these objects and attributes and the hierarchy. The NDS schema defines two types of objects:

Container objects are simply those objects that can contain other objects. The Tree Name, Country, Locality, Organization, and Organizational Unit objects are container objects.
Leaf objects are those that cannot contain other objects. These objects usually represent network resources. Users, Printers, and NCP Servers are examples of leaf objects.

Object Names

Every object must have a unique name. This name and its location in the hierarchy form the object's name context. Names lead from the leaf-most, or most subordinate, object to the most superior object. For example, let's use the following name:

.CN=RobF.OU=HQ.O=Novell.T=Novell_Inc

In this name, CN=RobF is the name of the most subordinate object, while T=Novell_Inc is the name of the most superior object.

Name Resolution

Resolving a name involves walking the NDS tree to locate a particular object. An Entry ID for that object is returned, which the client can use to find out information about the object.

Name resolution can be done through three operations:

List
Search
Resolve Name

List Operation. This List operation lists the immediate subordinate objects to a specified container object and any information specified about those objects. The List operation does not "walk the tree" because the information it returns is local to the current name server.

The client can specify three filters by which to select information about each object:

The Name Filter allows the client to request only objects that have a certain Relative Distinguished Name.
The Class Filter allows the client to request only objects that belong to a certain object class.
The Time Filter allows the client to request only objects modified after a certain time.

A client's rights on the subordinate object determine the information the operation returns.

Search Operation. The Search operation searches a region of the Directory tree for objects whose attributes satisfy specified criteria. Unwanted entries are weeded out by placing assertions on attribute values, or by a Boolean combination of these assertions. The assertions must conform to the matching rules defined for the syntax of an attribute in the NDS schema. The search is applied not only to containers directly subordinate to the specified object, but to all objects subordinate to that object.

The same filters used in the List operation apply to the Search operation.

Resolve Name Operation. The Resolve Name operation takes an object's Distinguished Name and uses it to obtain an Entry ID, which can then be used to access a corresponding NDS entry record in the ENTRY.NDS file. The client can specify request parameters and flags to determine acceptable responses.

Three types of requests are used:

Connection-based requests, which are used to find an Entry ID on a specific server.
Referral requests, which are made by a client as it walks the distributed tree to locate a specific object. This operation gives the client referrals that help it walk the tree and find the object.
Chained requests, which are used by clients whose limited resources require that the server handle the referral process.

Entry Management

Few businesses and organizations are static, so NDS allows administrators to modify Directory objects to reflect changes. In addition, administrators can obtain information about Directory objects and their attributes. The following sections described operations that manage Directory objects.

Adding an Entry

NDS allows administrators to add an entry or an alias to the NDS Directory. The schema dictates where entries are created and what their attributes can be. To be valid in the Directory, the new entry must hold the attribute Object Class, which has as its value a valid NDS base class. The object classes are defined in the schema. These object classes specify:

Mandatory attributes for an entry
The attributes that can appear in its Relative Distinguished Name
Optional attributes, if any

Comparing Values

The Compare operation compares a given value to an existing attribute and its value. For example, the client might use Compare to find out if the group Everyone.Novell has a Member attribute that has a value of Admin.Novell. The operation returns true if the values match or false if they do not. This operation verifies the existence of a value without having to read the value.

Comparisons are based on the matching rules of the attribute syntax assigned to the attribute (for information about matching rules, see NDS Schema Specification). Therefore, the matching rules must provide for this operation.

Modifying an Entry

Modify Entry allows a client to modify, add, or delete an entry's attributes in the same operation, except naming attributes. For example, the client might use Modify Entry to modify a user's telephone number.

All modifications must obey the rules defined by the class of the entry. For example, read-only attributes and "hidden" attributes cannot be changed. Because the entry's object class is read only, the class cannot be changed. This operation can also be used to modify an alias.

Modifying an Entry's Name

To change an entry's Relative Distinguished Name (RDN), the client uses Modify RDN. Using this operation, a client can specify a new naming attribute and value that will serve as the entry's RDN, or the operation can specify a new value for the existing naming attribute. In either case, the new name must obey the rules for the object classes of the entry being modified. A few object classes currently define more than one naming attribute.

If the operation changes a multivalued attribute or substitutes a new naming attribute, the old value can remain in the entry if the client requests it. In that case, the former attribute value will not remain part of the entry's RDN, but will remain as an attribute value or values of the entry.

Moving an Entry

The Move Entry operation comprises two routines, Begin Move Entry and Finish Move Entry, that place an entry in a different location in the Directory tree, which changes the entry's Distinguished Name.

Reading an Entry

The Read operation returns information about an entry stored in the Directory. It reads attribute information associated with the entry. The attributes the entry has depend on the object class.

The client can choose to return information about:

Specific attributes or a complete list of an entry's attributes.
Attribute names only or attributes names and values.
Effective access control privileges of the current user or of another user.

The granularity of the Read reply is the attribute value. An attribute value cannot be split across NDS iterations, but an attribute's list of values can be split. When split, each NDS reply message contains the Syntax ID, Attribute Name, and Number of Values fields. The Number of Values field indicates how many values are in the current reply.

Removing an Entry

Remove Entry removes an entry from the Directory tree. The entry being removed must be a leaf or a container having no subordinates. If the entry has subordinates, the operation fails.

A client or server can use Remove Entry to remove an alias from the Directory. If the entry ID indicates an alias entry, the operation removes the alias, not the entry the alias refers to.

Relationship Management

In the basic NDS, relationships between servers and objects are managed by multivalued Distinguished Names. In the SCALE product, server-object relationships are also handled by distributed relationship management.

Multivalued Distinguished Names

Multivalued Distinguished Names use a plus (+) delimiter to allow users to distinguish between two similar names in a Directory subtree. For example, two localities might have the same Paris, but one might refer to Paris, Idaho, and the other to Paris, Texas. In this case the administrator might assign the name L=Paris+S=Texas.OU=Mktg.O=Novell to the Texas locality and L=Paris+S=Idaho.OU=Mktg.O=Novell to the Idaho locality. This allows the administrator to distinguish between the two localities without creating an S=Texas or S=Idaho container.

The most common use of multivalued Distinguished Names is in those objects created through the bindery that do not map to well-known NDS objects. These objects have the RDN of the object plus the number of the bindery type: CN=ArcServer+Bindery Type=680.

NDS Personalities

NDS provides a set of multi-personality APIs that allow the following name services to access an NDS database:

NDAP
Bindery

NDAP

Novell Directory Access Protocol (NDAP) is the standard protocol allowing NetWare access to NDS.

Bindery

NDS treats the bindery as an emulated database stored in a flat name space specific to one server. The NDS bindery services code provides an alternate view of the same data stored in the NDS Directory Information Base (DIB). However, bindery services are limited; they allow backward compatibility but cannot express all of the information stored in the Directory.

NDS accomplishes backward compatibility with the NetWare bindery by setting aside fields in one of the primitives' shared memory blocks. These fields are set aside to convert double-byte enabled bindery names into something that is network readable, specifically dynamic SAPing tree names, which contain the network/node/socket address of the advertising tree.

Generally, the Bindery Services module makes only local calls to the Name Base, with occasional calls to the Directory Client, such as when it needs to read a console operator.

Bindery Objects. NDS bindery services uses the dynamic and static bindery objects as follows:

Dynamic bindery objects are not stored in normal NDS containers. They do not have a specific bindery parent container, but are stored in a dedicated "bindery partition." They can be accessed by a bindery client or server, but are not available from NDS APIs. Dynamic bindery information times out and must be refreshed on a regular basis by either an application or by SAPping.
Static bindery objects are stored in normal NDS containers specified in the bindery context path. They are normal NDS objects and are stored persistently in the NDS database, whether or not the bindery is open. When the bindery is open, they are visible to bindery calls. The bindery context can contain up to 16 containers.

Because the bindery is not hierarchical and does not need to distinguish objects by class, it has no formal schema definitions. However, the old NetWare bindery allowed object types, designated by 16-bit values that grouped similar objects. Some of the well-known object types have direct counterparts in the NDS schema and can be converted, or mutated, from the Bindery object class to the appropriate NDS object class.

Currently, the following object types can be mutated:

Bindery object type 1 to NDS object class User
Bindery object type 2 to NDS object class Class
Bindery object type 3 to NDS object class Queue
Bindery object type 7 to NDS object class Print Server
Bindery object type 309 to NDS object class Profile

These object classes, along with the Bindery Object class are all of the objects visible through bindery calls. No other NDS object classes are visible through bindery calls.

Bindery Object Properties. The NDS schema allows any object class to have a Bindery Property attribute type through a special case check. This allows for backwards compatibility with bindery-based applications that define their own properties. NDS names of bindery objects are a combination of the object name and the Bindery Type attribute. The Bindery Type attribute defines what type of object this is.

LDAP

Novell's LDAP server agent is based on University of Michigan's SLAPD version 3.3 implementation and provides LDAP version 2 access as specified in RFC 1777 to NDS including extensions for referrals. This means Novell's LDAP supports simple bind (unauthenticated access and access where the LDAP client provides name and password), search, modify, add, delete, modify RDN, compare, abandon and unbind requests. In addition, Novell's LDAP does not support clients if they are not also running LDAP version 2. Because Novell's LDAP is an NDS personality, Novell's LDAP must run on a server where NDS also is running.

Connectionless LDAP (CLDAP) will be supported for unauthenticated access over UDP. CLDAP supports CLDAP v 2 as specified in RFC 1798. Initially, Novell's LDAP supports at least 100 clients.

NDS/LDAP Schemas. The LDAP schema (based on X.500) and the NDS schema (X.500-compatible) are mapped to correspond to each other, allowing an LDAP client to browse the NDS directory. In the initial release, Novell's LDAP supports a static mapping between these two schemas. In later releases, Novell's LDAP administrators will be able to configure this mapping.

Novell's LDAP can browse an NDS container if the LDAP agent has browse rights to that container.

Authentication. Currently, the only form of authentication that Novell's LDAP will support is the user's name and password. We assume that LDAP clients will use SSL for their LDAP sessions and will be able to encrypt this information. Novell's LDAP uses SSL version 3 to create an encrypted channel for LDAP clients to provide their name and password to Novell's LDAP.

Configuring Novell's LDAP. Novell's LDAP is configured with the NWAdmin tool. Initially, configuration will reside in a file on the local file system. In subsequent releases, Novell's LDAP's configuration will reside in NDS. Novell's LDAP is dynamically configured so that the parameters can reset without having to restart it.

Protocol Compatibility. Novell's LDAP relies on the TCP/IP sockets interface. Novell's LDAP will also run on the WinSock interface to Windows NT.

Searching. To provide fast and efficient searches, Novell's LDAP uses a local data store as a catalog and a dredger to maintain that data store. Novell's LDAP supports approximate matching.

Local Event Services

NDS Event Services provides a way to monitor the activity of NDS on an individual server. Event Services can track local events and global events. When specified NDS events occur, a monitoring NLM can view them and determine what action to take. Event Services can notify the NLM during or after the event. Using Event Services, an NLM application can register one or more functions to be called when specific events occur. These events stay registered until the NLM application specifically unregisters them.

All event-driven subsystems within NDS prior to the current release were deeply embedded in the main NDS source code. These subsystems include:

Auditing
Accounting
Network Management
Tracing (information to a debug screen)
Logging (information to a file)

The current NDS event system tracks only one kind of information in the DS.NLM: the event reporting feature. The other subsystems are implemented as separate NLMS. Previously, there were 19 possible events, relating primarily to managing objects and connections. Currently, there will be more than 150 possible events.

The event-reporting mechanism consists of two kinds of routines:

Event reporter routines allow event information to be reported back to an entity needing that information. These routines report events and optionally the information and results associated with those events, including the event type, size of data, and the actual data.
Event consumer routines allow network entities to register and unregister events to be reported. An NLM can use these routines to register a function that will be called when a specific event occurs.

Filtering Event Data

Event Services must determine if data it is reporting contains information that the NLM application wants to use. For example, if the NLM application cares only about changes to telephone numbers, Event Services would use its data only if it contained information for a Telephone Number attribute. If the data does not contain Telephone Number attribute information, Event Services may return either no information or an error code, depending on what the NLM application requests.

Filtering by Local ID. While the object names in the Directory are global, the local IDs for entries on individual servers are not. Each object on a server is identified by a local ID that is relevant only on that server. The object's local ID on another server may or may not be the same. Local IDs are also used to identify attributes and object classes. These local IDs are also improve reporting speed. Comparing two 32-bit IDs is faster than comparing two strings.

In most cases, you can filter using local IDs because data structures in the callback's data parameter use IDs rather than names.

Authentication

Authentication is the process by which users establish their identities when accessing a network application service. NDS supports the following types of authentication:

NetWare 3 Authentication
NetWare 4 Authentication
Graded Authentication

NetWare 3 Authentication

NetWare 3 uses a challenge key and password encryption to authenticate a user without transmitting the password on the wire. A NetWare 3 user uses this process to log in to an NDS server where the bindery context has been set. The authentication exchange begins after an NCP connection has been established and buffer sizes have been negotiated.

NetWare 4 Authentication

Authenticating in a NetWare 4 environment consists of two processes:

User login. The client logs into an NDS server to establish the user's identity. No matter where the user is logging in, NDS walks the tree until it finds a writeable copy of the user's object. NDS then retrieves the client's private key.
Background authentication. After logging in, the user still needs to authenticate, or establish its identity, to a server holding a network service. This is done through background authentication.

Essentially, user login and authentication are the same process, but they are handled differently.

From the user's perspective, login asks him or her to enter a password and then locks the server. The server returns the user's context, and the user is ready to work on the network.

From NDS's perspective, login requires the user to enter the password, which NDS uses to encrypt the private key. After the login process has completed, the client has its private key and is ready to authenticate to other network services. NDS handles this process in the background.

Authentication data is valid only during the current login session. The critical data used to create authenticated messages for a user is never transmitted across the network in plain text.

NetWare 4 servers do not need to log in to the network because they store their own private keys. Because the servers can calculate the credential and signature from their local information, they use only background authentication.

Background authentication happens without the user's involvement. As previously mentioned, enough information is available from the login exchange for the client and server to mutually authenticate to each other.

Authorization

Novell Directory Services uses a process called access control to authorize users to perform Directory operations on other entries and their attributes. Access control restricts many different operations, including creating objects, reading and modifying entry attributes, and comparing attribute values. An access-restricted entry is referred to as a protected entry. An entry granted a particular set of access privileges to the protected entry is called the subject, or trustee, of those privileges.

As a service, access control protects only the entry information stored in the Directory. An application can use the Directory to store access control information specific to the application, but the Directory does not store this information as attributes. In addition, the Directory does not manage, evaluate, or apply this data on the application's behalf.

Because NDS defines and enforces Directory access, a Directory client application cannot access the Directory without using NDS access control. If a Directory client application must use access control in its session with clients, NDS can centrally store and retrieve access control information.

NDS uses special entry names that can be used on Access attributes in place of Distinguished Names and Relative Distinguished Names. The following are special entry names used:

DS_ROOT_NAME
DS_PUBLIC_NAME
DS_MASK_NAME
DS_CREATOR_NAME
DS_SELF_NAME

By default, an entry has the access privileges of:

Every entry in its Distinguished Name, unless one of these objects has an inherited rights filter.
Every special entry name that applies ([Public], [Root], [Creator], and [Self], and [Nobody]).
Every entry in its Security Equals attribute, if its object class definition has that attribute.

For example, in the following illustration, the object Joe.Marketing. Novell would have the same rights as:

OU=Marketing and O=Novell, because they are in Joe's Distinguished Name (unless an Inherited Rights Filter applies).
[Root] and [Public].
Sue, if Joe is security equivalent to Sue.

Access Control List Attribute

The Access Control List (ACL) attribute is the key component in determining Directory access control. This attribute determines which operations a trustee entry can do on another entry and its attributes. In the Directory schema, an ACL is a multivalued attribute type assigned as an optional attribute to the object class Top. Because all object classes inherit the characteristics of Top, all entries could have an ACL.

The Access Control List attribute contains the following values:

Protected Attribute ID. This field contains a reference to the attribute that the Privilege Set field (see below) applies to. It could also contain an identifier such as [Entry Rights] or [All Attributes Rights]. If this field contains [Entry Rights], the access privileges apply to the entry that holds this ACL.
Trustee ID. This field contains an Entry ID for a specific entry in the Directory. However, it could also contain a special entry reference such as [Inherited Rights Filter], [Public], [Root], [Creator], or [Self]. An ACL with [Inherited Rights Filter] as the trustee masks or filters privileges granted to an entry.
Class ID. This can contain a specific object class or [Anything], which includes all object classes.
Privilege Set. This field lists the privileges that have been granted to the subject. If the subject name is [Inherited Rights Filter], the Privilege Set field lists the rights that can be granted on that entry, although they might not have been granted.
Controls. Currently the only possible value is Inheritable. If this bit is set, the privilege set being granted is inherited at subordinate objects.

The ACL is an attribute on the object that is being accessed. The ACL lists the trustees and the rights they have to the object. For example, if object Joe had Browse [Entry Rights] over OU=Engineering, the ACL attribute on object OU=Engineering would look like this:

Field	Value
Attribute ID	[Anything]
Trustee ID	CN=Joe.OU=Marketing.O=Novell
Protected Attribute ID	[Entry Rights]
Privilege Set	Browse
Controls	DS_ENTRY_CTL

ACL fields have the following order of precedence:

[Entry Rights], [Anything], Supervisor
Uninheritable
Inheritable
[Entry Rights] a. A specific class b. [Anything]
Attributes a. A specific attribute b. [All Attributes Rights]

Default ACL Templates. In the NDS schema, most object classes specify a default Access template that is used to create an ACL attribute for a new entry. This default template provides basic access control for the new entry, allowing it to function in the Directory. Different object classes have different default ACL templates to reflect their different needs. For example, the User object class's default ACL attribute grants that User entry the Write right to its Login Script attribute. This allows users to change their login scripts as necessary. For information about default ACL templates, see the specific object classes in Novell Directory Services Schema Specification.

Rights. The Protected Attribute ID field can identify four types of access control rights:

[Entry Rights]
[All Attributes Rights]
Specific attribute rights
[Partition Rights]

These rights are granted to the entry's trustee. [Entry Rights] give a trustee rights that affect an entry as a whole, not just its attributes.

The following are [Entry Rights]:

Browse. The Browse right allows a trustee to discover Directory entries.
Create. The Create right allows a trustee to create child entries (new entries that are subordinate to the entry in the tree). The Create [Entry Right] is referred to as Add in the NDS code but as Create in the user interface and utilities. This document refers to it as Create.
Delete. The Delete right allows a trustee to delete an entry. This right does not allow a trustee to delete a container entry that has subordinate entries.
Rename. The Rename right allows a trustee to rename an entry.
Supervisor. The Supervisor right gives a trustee all rights to an entry and its attributes.
Backup. The Backup allows a trustee to backup an entry.
Restore. The Restore right allows a trustee to restore an entry from a backup.
Resolve. The Resolve Name right allows an entry to resolve the object's name. This right can be used to protect an entry from being seen across federated partitions.

Attribute rights give a trustee rights to all an entry's attributes or to a specific attribute on that entry. For example, User entries may have the Write attribute right to their Telephone Number attribute. This allows a user to change his or her Telephone Number attribute as necessary. Granting that same User Write [All Attributes Rights] on its attributes would allow that user to modify all writeable attributes.

The following rights can be granted to all an entry's attributes or to specific attributes of an entry:

Compare. The Compare right allows a trustee to compare, or see if an attribute contains a given value.
Read. The Read right allows a trustee to read an attribute value. This right confers the Compare right.

The schema defines some Directory attributes as "hidden." Trustees cannot read such an attribute's value even if they have the Read right.

Write. The Write right allows a trustee to add, delete, or modify an attribute value. This right also gives the trustee the Add or Delete Self right to the attribute.
Add or Delete Self. Some attributes take entry names as their values. The Add or Delete Self right allows a trustee to add or delete its name as an attribute value.
Supervisor. The Supervisor right gives a trustee all of the attribute rights.

The schema defines some read-only and public-read attributes, such as a Back Link, that trustees cannot modify.

[Partition Rights] allow a trustee to perform operations on a given partition. [Partition Rights] are always assigned at the partition root object. The following are [Partition Rights]:

Partition Add. The Partition Add right allows a trustee to create a partition boundary.
Partition Delete. The Partition Delete right allows a trustee to remove a partition boundary.
Partition Manage Replicas. The Partition Manage Replicas right allows a trustee to add or delete a replica from a server, repair time stamps, or run a DSRepair local database repair.
Partition Move Subtree. The Partition Move Subtree right allows a trustee to move the partition.
Partition Supervisor. The Partition Supervisor right allows a trustee all the partition rights listed above.

Inheritance. NDS rights "inherit," or flow down the tree the same way NetWare file system rights do: rights granted at a container apply to all subordinate entries within the container and subsequent subordinate containers.

For example, in Figure 1, Sue and Joe have Browse [Entry Rights] to [Root] by default. Through inheritance, Sue and Joe also have Browse [Entry Rights] to OU=Engineering and to all of its subordinate entries.

Figure 1:Inheritance.

An ACL attribute can grant rights to an attribute that is not present on the entry. This allows administrators to grant rights, through inheritance, on all the entries under a container, even if that container does not hold the same attributes as the container.

For example, a container may not have a Telephone Number attribute, but granting the container the Read [All Attributes Rights] on its entry allows all the users in the container to read all their attributes, including the Telephone Number attribute.

NDS calculates an entry's inherited rights by checking the entry's ACL attribute and then moving up the tree until it finds an Inherited Access attribute (on the partition root entry). On each ACL attribute it finds, it checks for [Inherited Rights Filters]. All rights not masked by an [Inherited Rights Filter] flow down the tree.

In the example tree above, NDS would calculate Joe.Marketing. Novell's inherited rights by walking up the tree to Marketing. Novell, which as a partition root entry, has an Inherited ACL. NDS would check the Inherited Access attribute for rights Joe receives by inheritance.

Security Equivalence. Security equivalence simply means that one entry has the same rights as another entry in the Directory tree. Before the system can calculate an entry's rights, it must determine its security equivalences.

Every entry in the Directory tree is security equivalent to the following entries:

[Public], even if the entry is not authenticated
The [Root] entry of the tree, if authenticated
Every entry contained in its Distinguished Name
Every entry listed in its Security Equals attribute

As an example of how rights are computed, assume that in Figure 1 Joe has Browse [Entry Rights] to Sam. If Sue is security equivalent to Joe, Sue also has Browse [Entry Rights] to Sam.

Now suppose that Sam's ACL attribute does not grant Sue any [Entry Rights] to Sam. To compute Sue's rights, NDS starts at O=Novell and walks down the tree. As it walks down the tree, NDS looks for ACL attributes on the entries it finds. It finds that Sam's Access attribute does not give Sue any [Entry Rights] to Sam; however, it also finds that Sue is security equivalent to Joe, which has Browse [Entry rights] to Sam. So, Sue gets Browse [Entry Rights] to Sam through security equivalence, not through inheritance.

Effective Rights. Effective rights are the sum of all the rights a user has received to Directory entries. The Get Effective Privileges operation allows a client to list the effective rights a given user, or trustee, has over NDS entries. These rights are received from the following sources:

Each entry's ACL attribute
The trustee's security equivalences
Access privileges inherited from the entry's parents
Access privileges of the designated subject, [Public]

Inherited Rights Filters. NDS allows administrators to control how rights are inherited. A special kind of Access attribute value called an Inherited Rights Filter (IRF) specifies which rights can be inherited from an object to entries below it in the Directory. The IRF (sometimes called an inheritance mask) takes the place of the trustee name in the ACL attribute ("[Inherited Rights Filter]" appears in the Trustee ID field). It can be applied to [Entry Rights], [All Attributes Rights], or specific attribute rights. Figure 2 shows the same tree as Figure 1.

Figure 2: Access Attributes and Inheritance.

This time, however, the following Access attributes apply:

Object Holding

ACL Attribute	Trustee	Protected Attribute	Privilege Set
Novell	Marketing	[Entry Rights]	Browse, Delete
Engineering	Joe	[Entry Rights]	Create
Sam	Sue	[Entry Rights]	Delete

If no object in the Directory has an Inherited Rights Filter, Sue would have the following effective rights:

The Delete right to Sam because Sam's ACL grants this right to Sue
The Delete right to Novell and Engineering.Novell because Marketing is part of Sue's Distinguished Name (this makes Sue security equivalent to Marketing)
The Create right to Engineering and Sam because Sue is Security equivalent to Joe
The Browse right to Sam, Engineering, and Novell because Sue is security equivalent to Marketing

Figure 3:Inherited Rights Filter.

Suppose, however, that Engineering.Novell has an Inherited Rights Filter that masks the Delete right. As Figure 3 shows, Sue no longer has the Delete right to Engineering but retains that right on Sam.

Inherited ACL. An Inherited ACL is an attribute of each partition root entry. This attribute summarizes the effective rights that trustees inherit in order to perform operations on entries. The Inherited ACL attribute is valid only on a partition root entry. Unless an Inherited Rights Filter is in use, these effective rights are granted to all entries in the partition. Having this attribute at the partition root level allows NDS to calculate effective rights for each entry in the partition without walking that entire portion of the Directory tree. Inherited ACLs are not visible to users or clients.

When a client creates a new partition, NDS creates an Inherited ACL as a multivalued attribute attached to the partition's root entry. NDS updates these ACLs when the Directory tree changes. In Figure 4, Engineering, Marketing, and Provo have Inherited ACL attributes because they are partition root entries.

Figure 4:Inherited ACL.

Management Rights. Management rights are the rights that allow a trustee to grant rights to other entries. A trustee has management rights when it has the Write attribute right to the entry's ACL attribute. The following rights can grant management rights to a trustee:

Write or Supervisor right on the ACL attribute
Write or Supervisor[All Attributes Rights]
Supervisor [Entry Rights]

Management rights are important because a trustee that can modify an entry's ACL can control what other entries can do to that entry. The following NDS operations require management rights to complete:

To modify the schema, a trustee must have management rights to the Directory's root partition.
Partition operations require the trustee to have management rights on the target partition.
Backup requires the trustee to have managed rights on the entry being backed up.
Adding an entry to a write-managed attribute on another entry requires management rights to the entry being added.

Write-Managed Attributes. Write-managed attributes are those attributes whose values are the Distinguished Names of entries in the Directory tree. To add or delete an entry name to a write-managed attribute, a trustee must have management rights to the entry being added; however, the trustee does not need rights to the object being modified.

The schema defines write-managed attributes, which include:

Security Equals
Group Membership
Higher Privileges (not used)
Profile Membership

Tracing and Logging

NDS provides tracing and logging features driven by certain NDS events. Tracing and logging can be configured to provide information or to trigger management utilities based on user-defined events.

The DSTrace NLM allows administrators to set groups of events that can be traced on the server console, logged to a file, or both. DSTrace uses the NDS Event System to register for the events specified by the user and display the data on the trace screen (or log file) as requested.DSTrace displays or logs text associated with the events; however, some internal events contain text and cannot be localized, since the text is embedded within DS.NLM itself. These events are used only for internal debug purposes.

Several data files are associated with DSTrace. The first is SYS:SYSTEM\DSTRACE.CFG. This file contains the list of event groups known on this server, the groups that are currently active (events in the active groups will be registered for, and text displayed for those events only), and log file control information, such as log file name, old log file name, log file size, and whether or not the log file should be enabled at all. Several default groups are included in a DSTRACE.CFG file to emulate all the existing "groups" defined by the "Set DSTRACE=" console command. There are currently 26 different valid possibilities to be given to this set command, all of which can be given in any combination. Unlimited user defined groups are possible.

There is no programming interface to the DSTrace NLM. It provides no accessible APIs.

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