Novell is now a part of Micro Focus

White Pages Application NDS Programming Tutorial: Directory Concepts

Articles and Tips: article

Senior Technical Writer
Developer Information

01 Aug 1999

Explains various aspects of NDS and includes information on directory naming and NDS replication. This is the first section of a two-part DeveloperNet University tutorial. To proceed with the tutorial, you will need a basic understanding of what a directory is and how it is used.


This Developer Note explains basic NDS concepts. Familiarity with NDS concepts will help you understand the issues involved in your code. This article explains various aspects of NDS and includes the following sections:

  • About NDS

  • About Directory Naming

  • About NDS Replication

About NDS

This discussion covers the following areas:

  • Introduction to NDS

  • The NDS Tree

  • Objects in the NDS tree

Introduction to NDS

NDS is a Directory Service. Directory Services have been around for several years, mainly in the enterprise environment. A Directory Service allows you to easily manage your network resources. Simply put, NDS is a globally accessible, distributed database of objects that represent network resources; such as network users, servers, printers, print queues, and applications. NDS can be described as a hierarchal tree.

NDS is stored as a set of database files on a server. A NetWare server stores these files on volume SYS. Other server environments, such as NDS for Solaris and NDS for NT, don't use file system volumes. In these environments, the server stores the NDS database files in an NDS installation subdirectory. The NDS Directory can be replicated on multiple servers.

The NDS Tree

The NDS tree can be thought of as a distributed database that contains directory information about objects. That is, the database contains objects and the attributes, or properties, that describe those objects. Each NDS tree maintains its own database of objects. Because it is a distributed database, the database is usually contained on more than one server. Figure 1 shows an example NDS tree.

Figure 1: Example NDS Tree.

The information in an NDS tree does not describe the physical layout of the network. It usually describes the logical organization of the business. The NDS tree is usually organized into subtrees that reflect the different departments and units in the company. In turn, those subtrees contain the resources within the different departments.

NDS Objects

The NDS tree is made up of objects. These objects represent network entities and are of two basic types: Leaf objects and container objects. In the tree representation, container objects can hold leaf objects and other container objects. Container objects are Country objects, Locality objects, Organization objects, and Organizational Unit objects. NDS 8 includes an additional container object called domain. Leaf objects represent a network resource that can't hold another object. For example, a leaf object could be a user or a printer. Figure 2 shows an example of an NDS tree with the appropriate objects.

Figure 2: Example NDS Tree with Appropriate Objects.

All leaf objects such as printers and users are indicated by the CN (Common Name) object type.

If VerySmallCompany used the Country object to organize its tree by country, the Country object would be located between the [Root] and the Organization objects, as shown in Figure 3.

Figure 3: An Example NDS Tree with a Country Object

You can also place a Locality object in a tree. Locality objects would be placed between the Country and the Organization object. You can use Locality objects to further divide your tree between states, provinces, cities, counties, and so on. You can also use a Locality object to divide your tree between such locality types as headquarters and branch offices. Most companies choose to not use the Country and Locality objects. Instead, they divide the tree below the Organization object and use Organizational Unit objects to organize by countries and localities. Figure 4 illustrates this method.

Figure 4: Common Organization of International Tree.

An object's name context is a list of the containers between the object and [Root]. This context, or name, describes its position in the NDS tree.

About Directory Naming

This discussion covers the following areas:

  • Name Context

  • Current Context

  • NDS Name Types

  • Periods in NDS Names

Name Context

An object's name context represents its position in the NDS tree. The name context is a list of containers separated by periods. This list of containers traces the object's path back to [Root]. An example of a user's name context might be: Read this name as the lpIII printer which is in marketing which is in VerySmallCompany.

Name contexts mean that you don't have to know an object's network address in order to locate it on the network. NDS looks up the resource's network name, or name context, and resolves it to a network address for you. Network addresses function much like street addresses for a house. For example, an IP address has four fields. The first two fields represent the network segment, the last two fields represent the resource. So, the address is resolved by locating the network segment, then locating the resource along that segment. A directory service allows you to locate a resource by its name, or location in the directory tree, rather than having to know its address.

Figure 5 illustrates resolving a context to a network address. This figure shows how a client would locate a printer in the network.

Figure 5: Resolving a context to a network address.

Current Context

An object's context is the portion of the path that defines the object's location in the tree. For example, in the network name, The printer's common name is lp; its current context is marketing.VerySmallCompany.

NDS Name Types

NDS names can be presented as:

  • Distinguished or Complete Name

  • Fully Distinguished Name

  • Relative Name

Distinguished and Fully Distinguished Names can be presented as either Typeful or Typeless Names.

Please note that this sections describes NDS naming conventions. Non-NetWare environments, such as an ActiveX environment, use these naming conventions differently.

Distinguished or Complete Names. Distinguished Names are also sometimes called Complete Names. An object's Distinguished Name is its object name combined with its context. For example, suppose a printer's object name is lpIII, and its context is marketing.VerySmallCompany. The printer's Distinguished Name would be:

The Distinguished Name doesn't use a leading period.

Fully Distinguished Name. A Fully Distinguished Name is a Distinguished Name that includes the leading period. The leading period means that NDS will resolve the name from the Root, regardless of the object's current context. The printer's Fully Distinguished Name would be:

Typeful Name. Typeful names are either Full Distinguished Names or Distinguished names that include the type of each object in the context. They are also called Typed Names. The object types use the definitions in the list below:

Object Class



Leaf objects (typically)

Common Name





Organizational Unit

Organizational Unit





The typeful name uses the type abbreviation, an equals sign, and the object's name. For example, if JJones were a user located in the VerySmallCompany's development department, her typeful name would be:


Typeless Name. Typeless name is the same as the either Full Distinguished Name or the Distinguished Name without object types. JJones's Typeless Name is

Relative Name. NDS resolves relative names from the workstation's current context, not from [Root]. For example, if the workstation's current context is marketing.VerySmallCompany, and the user's relative name is, NDS reads the name as jsmith in marketing in the current context (marketing.VerySmallCompany.). Never use a leading period with a relative name.

Periods in NDS Names

Generally, periods in NDS names separate the objects. They perform much the same function as a slash does in a file system directory name. However, if the period is leading or trailing, it means something different.

Leading and trailing periods relate to the current context. Use a leading period when you want to resolve the name from [Root], regardless of the current context. For example, when NDS sees the context .marketing.VerySmallCompany, it will locate the PR container by walking the tree from [Root]. This is also called the absolute path.

You can only use trailing periods in relative naming. For each trailing period in a relative name, NDS resolves the name from one container closer to [Root]. For example, if the workstation's current context is marketing.London.LargerCompany, and you wanted to access jjones' object in the context "marketing.London.LargerCompany". You could use the following string: "". NDS detects the trailing dot and removes the "marketing" component from the default context before it appends the new context. So, the context will correctly read as: "".

Each trailing dot removes one naming component from the default context. For example, to access KJones in engineering in London, you can use the context: "". The NDS client detects the two trailing periods and removes two name components from the default context, "" and changes the context to: "".

About NDS Replication

This discussion covers the following areas:

  • Replication

  • Paritions

  • Replicas

  • Replica list

  • Replica ring

  • Synchronization


If your network has more than one NDS server, you can replicate the NDS Directory. Replication simply means that your network has more than one copy of the Directory, and NDS automatically keeps all the copies up-to-date, or synchronized. Keeping multiple copies of the Directory lets users continue to log into the network and use the remaining network resources if servers or network links fail. One server can hold replicas of multiple partitions.

Keep in mind that NDS replication is not a back-up solution. The replication and synchronization processes only replicate information about NDS objects. NDS does not replicate any information, except that which is stored in the directory. You still need to back-up your system to keep information that is not associated with NDS objects, such as files and documents.


A partition is simply a subtree of the NDS tree. At installation, NDS creates one partition by default; this means that the entire tree is a partition. You can create multiple partitions by creating partitions for different subtrees. Figure 6 shows a partitioned NDS tree.

Figure 6: A partitioned NDS Tree.

Partitions are named by the container that is closest to the root. Figure 6 has three partitions: [Root], Engineering, and Marketing.


An instance of a partition is called a replica. Partitions can have multiple replicas; but only one replica of a particular partition can exist on a server. Servers can hold more than one replica, as long as each replica is of a different partition.

The following table describes the four NDS replica types:

Replica Type


Master Replica

The first NDS server installed on the network holds the master replica by default. Partitions have only one master replica. Other replicas are created as read/write replicas by default. The "creating a new partition" and "creating a new replica" operations require that a master replica is available. If the master replica is on a server that is down, NDS cannot create new partitions or replicas until the server is up again.

Read/write Replica

NDS can access and change information in a read/write replica and then propagate those changes to the other replicas. If users cross slow WAN links or busy routers, you can place a read/write replica locally to them to speed their access of network resources. Keep in mind that the more read/write replicas you create, the more network traffic necessary to keep the replicas synchronized.

Read-only Replica

Network clients can read network information from read-only replicas, but they cannot change them. NDS synchronizes read-only replicas with the changes from read/write and master replicas.

Subordinate Reference

Subordinate references are system-generated and contain only enough information to allow NDS to resolve names across partition boundaries. The system creates subordinate references on servers that hold a replica of a parent partition, but not of its child partitions. This allows NDS to walk the tree to replicas of the parent partition's child partitions on other servers. The system automatically deletes the subordinate reference, if a replica of the child partition is copied to the server holding a replica of the parent partition.

Each replica contains a replica list that contains all the other replicas of its partition. All the servers that hold copies of a particular replica is called a replica ring.

Replica List

Each replica stores a list of all the partition's replicas. Replicas store this list as an attribute of the partition's root-most container object. This list contains the following elements for each replica:

Server Name

The name of the server holding the replica.

Replica Type

The type of the replica stored in the server named in the Server Name field.

Replica State

The status of the replica.

Replica Number

The number the master replica assigned to this replica.

Network Address

The server's last known address.

Remote ID

The entry ID of the replica's partition root object.

Replica Ring

Multiple servers that hold replicas of the same partition compose a replica ring. NDS automatically synchronizes the servers in a replica ring.


The NDS database is loosely consistent, which means that replicas are not guaranteed to hold the latest changes to the database at any specific moment in time. To ensure database integrity, NDS automatically synchronizes all replicas. So, the database is guaranteed to completely synchronize. If there is any period of time during which no database changes occur, the database will completely synchronize and all replicas will hold the most recent information.

A good example of this occurs whenever users change their passwords. If they attempt to login with their new password immediately after they change it, the authentication often fails. But, if they wait a few minutes and then login with the new password, the system allows them in. This is because NDS had time to synchronize the password with all the replicas.

Fast synchronization, which is synchronization of all object modifications, occurs every 10 seconds. Slow synchronization, which is synchronization of the attributes dealing with login time and network addresses, occurs every 5 minutes.

Instead of synchronizing all information for every object, NDS only synchronizes the updated (delta) information. Each attribute has a time stamp associated with it. NDS updates this time stamp whenever the attribute is updated.


This article has offered basic concept for the following areas:

  • NDS

  • Directory naming

  • NDS replication

After studying this article, you can test your knowledge by going to the Directory Concepts Assessment at education/dirconcepts_assess.htm.

* Originally published in Novell AppNotes


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.

© Copyright Micro Focus or one of its affiliates