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.
Introduction
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: lpIII.marketing.VerySmallCompany. 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 lpIII.marketing.VerySmallCompany, 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: lpIII.marketing.VerySmallCompany.
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: .lpIII.marketing.VerySmallCompany.
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 |
Type |
Abbreviation |
|
Leaf objects (typically) |
Common Name |
CN |
|
Organization |
Organization |
O |
|
Organizational Unit |
Organizational Unit |
OU |
|
Country |
Country |
C |
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:
CN=JJones.OU=development.OU=engineering.O=VerySmallCompany
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 jjones.development.engineering.VerySmallCompany.
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 jsmith.marketing, 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: "jsmith.marketing.". 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: "jjones.marketing.London.LargerCompany".
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: "KJones.engineering.London..". The NDS client detects the two trailing periods and removes two name components from the default context, "marketing.berlin.VerySmallCompany" and changes the context to: "kjones.engineering.London.VerySmallCompany".
About NDS Replication
This discussion covers the following areas:
Replication
Paritions
Replicas
Replica list
Replica ring
Synchronization
Replication
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.
Partitions
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.
Replicas
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 |
Description |
|
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.
Synchronization
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.
Conclusion
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 http://www.developer.novell.com/ education/dirconcepts_assess.htm.
* 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.