NDS Technical Overview

Articles and Tips: article

JUDY WILSON
Technical Writer
Novell Products Group

JOHN WILLIAMS
Technical Writer
Novell Products Group

01 Apr 1998

This description of Novell Directory Services includes the following: advantages of NDS, features overview, object management, authorization, and authentication. Such topics as access control lists, access control rights, and NetWare 4 authentication are covered in detail.

Introduction
Advantages of NDS
NDS Feature Overview
NDS Object Management
Authorization
Authentication

Introduction

Novell Directory Services (NDS) is a distributed, hierarchical database of network information that is used to create a relationship between users and resources. It simplifies network management because network administrators can administer global networks from one location (or many) and manage all network resources as part of the NDS tree. User administration is simplified because the users dynamically inherit access to network resources from their placement in the NDS tree. For example, NDS enables users to dynamically inherit access to departmental resources such as applications, printers, and modems when users are placed in the department's NDS container.

NDS runs on the NetWare operating system and can be ported to run on other operating systems such as NT and UNIX, bringing its global administrative capabilities to the NT and UNIX servers. In addition, NDS allows you to administer intranet- and internet-based networks.

Advantages of NDS

NDS offers network administrators a number of advantages:

Global database and administration. NDS uses a single naming system that encompasses all servers, services, and users in an internetwork. In the past, names were administered separately in each server. Now, NDS allows information entered once to be accessible everywhere, and lets a user log in once to access diverse, geographically separated resources.
Hierarchical naming. Names are organized in a top-down hierarchy or tree structure. This helps users find resources in a structured manner. It also enables an administrator to administer a large network by delegating portions of the tree to local administrators.
Access control through inheritance, assignments, and filters. Rights flow down the tree until blocked by a filter or another assignment. When a department adds a new user account to its container in the NDS tree, the user inherits the department's rights and gains access to the department's network resources.
Distributed database. NDS information is typically stored not on one network server, but on several servers which are often at different locations. This allows information to be stored near users and provides efficient operation even if the users are geographically dispersed.
Replicated database. NDS is highly reliable because it stores multiple copies of Directory information on different servers. When one server is inaccessible for any reason, another server can fill its role.
Partitioned database. A large NDS tree can be divided into partitions of manageable size. For each partition, an administrator assigns one or more NDS servers to hold a replica of that partition's information.
Extensible schema. NDS keeps a schema which describes the classes of data objects, the relationships between them, and the kinds of attributes associated with each class. There are built-in classes for typical network entities and for users. Developers can add new classes to support new applications.
Authentication services. The NDS authentication process allows users to authenticate once and then uses background authentication to give the user access to network services. NDS uses encryption keys on the server and client so that passwords do not need to be sent across the wire for verification.
Multiple protocols. NDS supports such protocols as Light Directory Access Protocol (LDAP), Novell Directory Access Protocol (NDAP), and ADSI (the Microsoft interface to directory services).
X.500 compatible. The NDS database is based on the X.500 directory services standard.

NDS Feature Overview

NDS is designed so that a company can configure NDS to match the company's needs. A company can install:

A single corporate NDS tree which contains all network resources
Multiple NDS trees which contain each department's or location's network resources
An NDS tree on each network server which contains the users and the network resources that these users access

Company management decisions, not NDS, determine the configuration.

NDS features can be divided into the following categories:

Object management
Database management
Protocol
Schema
Core supporting services
Management utilities
NDS-enabled applications and services

The object management features deal with all operations that manipulate the entries in the NDS database. These features are described in this article.

NDS Object Management

The object management features include the following services:

Storage
Naming
Entry management
Authorization
Authentication

Storage

NDS uses the Record Manager to store NDS object information. The Record Manager provides access to the Directory Information Base (DIB), which stores the information contained in the Directory. The DIB is composed of Directory entries, each of which is made up of attributes that contain information about that entry.

For example, a User object is an entry in the DIB, and the attributes contain information about such characteristics as the user's name, password, address (network and mail), phone number, and fax number.

The DIB entries are arranged in the form of a logical tree structure. The container entries in the DIB usually represent countries, organizations, and departments. Leaf entries in the DIB usually represent people, services, applications, and physical objects such as printers or plotters.

Figure 1 illustrates a simple NDS tree.

Figure 1: Simple NDS Tree.

This NDS tree has four container objects: Novell, Engineering, Utils, and Marketing. The DIB uses container entries (entries that can contain other entries) and leaf entries (entries that cannot contain other entries). It has four leaf objects: Admin, Sam, Joe, and Sue.

Naming

The NDS naming service is object-oriented and global because it 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 if they have the appropriate rights.

NDS Objects and Attributes. NDS consists of objects and attributes, and these objects are represented on each server by a physical entry. The schema contains the rules for forming these objects and attributes and establishing the hierarchy.

The NDS schema defines two types of objects:

Container objects. These are the objects that can contain other objects. NDS uses the following: Tree Root, Country, Locality, Organization, and Organizational Unit.
Leaf objects. These are the objects that cannot contain other objects and usually represent network resources. For example, NDS uses the following: Users, Printers, Volumes, and NCP Servers.

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 "root-most," or most superior object. For example, User Joe from Figure 1 has the following name:

.CN=joe.OU=marketing.O=novell

In this name, CN=joe is the name of the most subordinate object, while O=novell is the name of the most superior, or root, object. This name in the above example is also known as a typeful name, because it gives the type of each object in the name.

When an object name uses the "." between the object names and drops the object types, it is called a typeless name. The following is an example of a typeless name:

joe.marketing.novell

Besides typeful and typeless names, NDS uses distinguished names (DN) and relative distinguished names (RDN). Both name examples above are distinguished names because they give the path from the leaf object (joe) to the root object (novell). Distinguished names are also sometimes called fully distinguished names (FDN).

Relative distinguished names are each of the individual object names without the path information. In the example name above, marketing and Joe are relative distinguished names. RDNs must be unique in relation to the parent object. For example, a printer and a user cannot have the same RDN if they both reside in the same parent container.

Name Resolution. Resolving a name involves walking the NDS tree to locate a particular object. One of the main functions of NDS is to translate network or resource names to network addresses. This means that any modification to the network address of a resource or object is invisible to the user; the user is still able to access the resource by the resource's name. Figure 2 illustrates this basic concept.

Figure 2: Name-to-Address Resolution.

Name resolution functions return an entry ID for the object, which the client can use to find the object's network address or ask for other information about the object. An entry ID is a numeric value that references an entry in the NDS database. The entry ID is not global; it is local to the server and specific to the server's NDS database files.

Name resolution can be done through three operations:

List
Search
Resolve Name

List Operation. The 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 database. 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.

Multivalued Distinguished Names. Multivalued distinguished names allow a single object to have an RDN that contains more than one name component. 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 name of 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 a Texas or Idaho container. (S is an attribute that can be used as a component of a Directory name to specify a geographical location such as a state or province.)

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.

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 describe operations that manage Directory objects.

Directory objects can be either entries or aliases. An alias is an object that points to another object in the NDS tree. Each alias points to one object in the tree, which can be either a leaf or container object. The most common use of an alias is to place one in a container so that users in that container have rights to the resource referenced by the alias. For example, if a printer is defined in one container, users in another container can gain access to that printer by placing an alias in their container.

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 and specify the following:

Mandatory attributes for an entry
The attributes that must 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. The Modify Entry operation allows a client to modify, add, or delete an entry's attributes except for the 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. An alias has only a few attributes, and changing these attributes does not change the attributes of the real object.

Modifying an Entry's Name. The Modify RDN operation allows a client to change an entry's relative distinguished name (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. Only 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. These routines 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 object class determines which attributes the entry has.

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 reply 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. The Remove Entry operation 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.

Authorization

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

NDS access control can be used to grant access to a particular application. However, the application must use the NDS operations as NDS enforces them. The application cannot modify how NDS access control works or have NDS apply application-specific access control operations.

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 the following components to control access:

Access control lists
Security equivalency
Inheritance

Access Control Lists

An access control list (ACL) is an optional attribute of every object in the database. This attribute determines which operations a trustee 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 ACL is an attribute on the object that is being accessed. Each assignment in an ACL lists which entry has been granted rights to the object, what type of rights the entry has been granted, and what rights are being granted. When an entry has been granted rights to another object, the entry is called a trustee of that object.

The ACL attribute uses three fields to contain the information about a trustee assignment:

Trustee ID
Protected Attribute ID
Privilege Set

Trustee ID. This field specifies the object that is being granted rights and contains the Entry ID of the object. It can also contain one of the following special entry references:

Reference	Description
[Inherited Rights Filter]	NDS uses this reference to mask or filter privileges rather than granting rights. (This filter is described in more detail below.)
[Public]	NDS uses this reference to grant rights to all entries in the NDS tree, even if the entry hasn't authenticated to the tree.
[Root]	NDS uses this reference to all grant rights to all authenticated entries.
[Creator]	NDS uses this reference to grant all rights to the client that created the object.
[Self]	NDS uses this reference to allow objects to add or delete themselves as values of attributes and to grantthe object rights to its own attributes.

Protected Attribute ID. This field specifies the type of right that is being granted. It can contain one of the following:

Name of one of the object's attributes. This indicates that the rights apply just to this attribute. For a User, possible attributes would be such items as phone number, address, or login script.
[All Attributes Rights]. This indicates the access rights apply to all the object's attributes.
[Entry Rights]. This indicates that the access rights apply to the object that owns this ACL attribute. Entry rights grant rights that affect the object as a whole.

Privilege Set. This field lists the rights that have been granted to the subject. If the trustee ID is [Inherited Rights Filter], the Privilege Set field lists the rights that can be inherited on that entry, although they might not have been granted. (See the Rights section below for a list of rights that can be granted in this field.)

Sample ACL. If the object Joe has Browse [Entry Rights] to the container, OU=engineering, the ACL attribute on object OU=engineering would look like this:

Field	Value
Trustee ID	CN=joe.OU=marketing.O=novell
Protected Attribute ID	[Entry Rights]
Privilege Set	Browse

Rights. NDS uses two types of access control rights:

Entry rights
Attribute rights

Entry rights give a trustee rights that affect an object as a whole, not just its attributes. NDS uses the following:

Browse. 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).
Delete. Allows a trustee to delete an entry. This right does not allow a trustee to delete a container entry that has subordinate entries.
Rename. Allows a trustee to rename an entry.
Supervisor. Gives a trustee all rights to an entry and its attributes.

Attribute rights give a trustee rights to all attributes or to a specific attribute of that entry. For example, User entries can 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 allows that user to modify all writeable attributes.

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

Compare. Allows a trustee to compare, or see if an attribute contains a given value.
Read. Allows a trustee to read an attribute value. This right confers the Compare right.
Write. 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. Allows a trustee to add or delete its name as an attribute value on those attributes that take entry names as their values.
Supervisor. The Supervisor right gives a trustee all of the attribute rights.

Note: The schema defines some Directory attributes as "hidden." Trustees cannot read such an attribute's value even if they have the Read right. The schema also defines some attributes as read-only and public-read which trustees cannot modify.

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 NDS Schema Specification.

Security Equivalency

Security equivalence simply means that one entry has the same rights as another entry in the Directory tree. 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 container in its distinguished name. When a container is granted rights, every object in the container inherits those rights.
Every entry listed in its Security Equals attribute. When a user is security equivalent to another user, the user inherits all the trustee assignments granted to the equivalent user.

For example, the object joe.marketing.novell has the same rights as

OU=marketing and O=novell, because they are in Joe's distinguished name (the possible effects of an Inherited Rights Filter are described below)
[Root] and [Public]
Sue, if Joe is security equivalent to Sue

Inheritance

Some 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 3, Joe has Browse [Entry Rights] to [Root]. Through inheritance, Joe also has Browse [Entry Rights] to OU=engineering, OU=marketing, and all of their subordinate entries.

Figure 3: Inheritance.

Inheritance is controlled by ACLs. A user's rights flow down the tree until one or both of the following occur:

The user is granted another ACL. The closest ACL to the object in question takes precedence over an ACL granted higher in the tree.
An Inherited Rights Filter (IRF) is modified. (See the next section.)

Inherited Rights Filters. IRFs allow administrators to control how rights are inherited. A special kind of ACL attribute value called an Inherited Rights Filter 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.

The following figure uses the same tree structure as shown in Figure 3 but has different ACLs.

Figure 4: Inherited Rights Filter.

This time the following Access attributes apply:

ACL Attribute	Trustee	Protected Attribute	Privilege Set
Novell	Marketing	[Entry Rights]	B rowse, D elete
Engineering	Joe	[Entry Rights]	C reate
Engineering	[IRF]	[Entry Rights]	Filter D elete
Utils	Sue	[Entry Rights]	D elete

Joe has the following effective rights:

The Browse right to the entire tree because Marketing is part of Joe's distinguished name (this makes Joe security equivalent to Marketing) and because no IRF filters out this right.
The Delete right to Utils because Joe is security equivalent to Sue.
The Delete right to Novell and Marketing because Marketing is part of Joe's distinguished name (this makes Joe security equivalent to Marketing). Joe does not have the Delete right to Engineering because the Engineering IRF masks this right.
The Create right to Engineering and Utils because the Engineering ACL grants this right to Joe and Utils does not have an IRF masking this right.

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 5, Engineering and Marketing have Inherited ACL attributes because they are partition root entries.

Figure 5: Inherited ACL.

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.

Authenticated users receive rights from the following sources:

A trustee assignment to a entry's ACL attribute
The trustee's security equivalences
Access privileges the trustee can inherit from the entry's parents
Access privileges of the objects, [Public] and [Root]

NDS calculates a user's effective rights by checking the ACL attribute of the entry in question and then moving up the tree until it finds an Inherited ACL 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 calculates the inherited rights of joe.marketing.novell by walking up the tree to marketing.novell, which as a partition root entry, has an Inherited ACL. NDS checks the Inherited ACL attribute for rights Joe receives by inheritance.

Management Rights. Management rights 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 NDS schema, a trustee must have management rights to the Directory's root partition.
To perform partition operations, a trustee must have management rights on the target partition.
To back up an entry, a trustee must have management rights on the entry being backed up.
To add an entry to a write-managed attribute on another entry, a trustee must have management rights to the entry being added and write rights to the attribute.

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 and write rights to the attribute.

Write-managed attributes include the following:

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

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 4 authentication
NetWare 3 authentication
LDAP

NetWare 4 Authentication

Novell Directory Access Protocol (NDAP) is the standard protocol allowing NetWare access to NDS. This is the protocol supported by the Novell client requesters that have been written for NetWare 4.

Authenticating in a NetWare 4 environment consists of two processes:

User login. The client logs in to 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, the login process is extremely straightforward: it merely asks the user to enter a password. The server then returns the user's context, and the user is ready to work on the network.

From the perspective of NDS, the login process uses the user's password to encrypt the private key. After the login process has completed, the client is ready to authenticate to other network services. NDS handles this process in the background, in cooperation with Novell client software. Services external to NDS can also use NDS authentication to authenticate themselves to NDS.

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.

Although NetWare 4 servers need to authenticate to other NetWare 4 servers, 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. Security-conscious installations can also restrict the amount of time a client can hold essential data and can require a user to re-enter a password for background authentication.

NetWare 3 Authentication

To authenticate a user without transmitting the password on the wire, NetWare 3 uses a challenge key and password encryption. 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.

NDS treats the bindery as an emulated database stored in a flat name space specific to one server. NDS bindery services provide 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 converting double-byte enabled bindery names into something that is network readable, specifically dynamic SAPping 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. Once the bindery is closed, the dynamic objects are deleted. If these objects are needed, they are added again 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.

The following bindery 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 7to 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 (which defines the object type).

LDAP Authentication

LDAP Services for NDS allow applications that use the Lightweight Directory Access Protocol (LDAP) to access data in the NDS database. When an LDAP client sends a request from an LDAP application, NDS completes the request for only the attributes which the LDAP client has the appropriate access rights.

Currently, LDAP Services for NDS supports three types of authentication:

Anonymous bind. This type of authentication does not require a username or password. The LDAP user has the equivalent rights of the NDS [Public] user. Default rights assignments allow [Public] to browse the names of all objects in the NDS tree, but without additional rights assignments, [Public] cannot view any attribute information.
Proxy user anonymous bind. This type allows authentication with an NDS username, but no password can be required. For LDAP, this is an anonymous bind which enforces the password restriction. For NDS, the user is an NDS object that can be assigned additional rights just as any other NDS object.
NDS user bind. This type allows LDAP clients to authenticate to NDS using their NDS usernames and passwords. Since passwords are sent as clear text on the wire, they can be captured and used to access the NDS tree unless you use security features which filter IP addresses.

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