About NDS Naming
Articles and Tips: article
Senior Editor
DeveloperNet University
nmclain@novell.com
01 Oct 2000
Presents a definitive treatise on NDS naming, covering such concepts as name context, how NDS resolves names, current context, the different types of NDS names, and how periods work in NDS names. This information will help you understand and apply effective NDS naming in your network.
NDS tree design includes not only partitioning and replication strategies, but also naming standards. NDS naming follows X.500 naming conventions. As in X.500, the complete NDS name of an object describes its place in the directory tree.
To understand NDS naming, you need to understand the following concepts:
Name Context
Resolving NDS Names
Current Context
Types of NDS Names
Periods In NDS Names
Name Context
NDS locates an object by its path from the [Root] of the tree. An object's name context represents its position in the NDS tree. The context is a list of containers represented in hierarchical order and separated by periods. This list of containers traces the object's path back to [Root] in the NDS tree.
For example, Figure 1 shows a User object and a Printer object in a simple NDS tree. The name of the User object is Brenda.Benefits.HR.VerySmallCompany. You would interpret this name as: Brenda is in Benefits, which is in HR, which is in VerySmallCompany, which is just under [Root].
Figure 1: A small NDS tree with a User object and a Printer object
The context of Brenda's User object is Benefits.HR.VerySmallCompany. This means that her User object is located in the Benefits container, which is contained by the HR container that is located in the VerySmallCompany container.
Resolving NDS Names
The context helps a client agent to locate a network resource without knowing its network address. NDS looks up the resource's name or context and resolves it to a network address. Figure 2 illustrates the process of resolving the name of the printer shown in Figure 1--Printer.HR.VerySmallCompany.
Figure 2: The process of resolving an NDS name
Current Context
The current context is the context of the user's workstation. It can be thought of as your (not your User object's) current position in the NDS tree. For example, in the sample tree shown in Figure 1, if Brenda logs in to her usual context (Benefits.HR.VerySmallCompany), her current context would be Benefits.HR.VerySmallCompany. If Brenda changes her view of the tree by going up one container, her current context changes to HR.VerySmallCompany.
If you're a developer, your applications have current contexts also. If your application is currently working with the HR.VerySmallCompany portion of the tree, then its current context is HR.VerySmallCompany. If your application is working with the Engineering portion of the tree, then its current context is Engineering.VerySmallCompany. If your application can only see the Testing portion of the tree, then its current context is Testing.Engineering.VerySmallCompany. You must keep track of your application's current context. If your application is seeing a different portion of the tree than you expect, it may not work properly.
Types of NDS Names
As stated earlier, NDS names are made up of the containers in an object's path back to [Root]. There are three main types of NDS names:
Complete names, or fully distinguished names
Relative Distinguished Names
Common Names
Each of these name types can be either typeful or typeless.
Complete Names, or Fully Distinguished Names. The terms complete name, distinguished name, and fully distinguished name all describe the same type of name. An object's complete or distinguished name is its common name combined with its context. The common name is an attribute on the object that usually holds the object's name.
Combining a User object's common name with its context provides its distinguished name. For example, the distinguished name of the User object shown in Figure 1 would be ".Brenda.Benefits.HR.VerySmallCompany." In this example, the common name of Brenda's User object is Brenda. The object's context is .Benefits.HR.VerySmallCompany.
Distinguished names explicitly identify an NDS object. Although two NDS objects can have the same common name, they can't have the same distinguished name. For example, the tree in Figure 1 could have a User object in the Training container with the common name of Brenda. But the distinguished names of these objects would be different and would explicitly identify each User object: .Brenda.Benefits.HR.VerySmallCompany and .Brenda.Training.HR.VerySmallCompany.
Distinguished names always start with a leading period. The leading period tells NDS that the name is distinguished and, thus, has its current context already appended to it. Never end a distinguished name with a period. (See the "Periods in NDS Names" heading for more information about the role of the period in NDS names.)
Relative Distinguished Names. NDS resolves relative distinguished names (sometimes abbreviated as RDN) from the current context, not from [Root]. For example, if Brenda's current context were HR.VerySmallCompany, Brenda's relative distinguished name would be Brenda.Benefits. When NDS is told that Brenda.Benefits is a relative distinguished name, it appends the current context onto it. So, NDS would read her relative distinguished name as Brenda in the Benefits container that is in the current context (HR.VerySmallCompany).
Never use a leading period with a relative distinguished name. The lack of the leading period tells NDS that the name is a relative distinguished name and, thus, needs to have its current context appended to it (which is appended to the left-hand side of the name). However, you can end a relative distinguished name with a period. (See the "Periods in NDS Names" heading for more information about the role of the period in NDS names.)
Common Names. An object's common name is held by its Common Name (CN) attribute. This is usually the name shown next to the leaf object in the NDS tree. We have already seen that the common name for Brenda's User object is "Brenda". The Printer object's common name is Printer. Common names are relative distinguished names. In order to locate the object, NDS must append the current context to it.
Typeful and Typeless Names. NDS names can be either typeful or typeless. Typeful names include the type of containers in the name. For example, in the tree shown in Figure 1, Brenda's typeful name would be: CN=Brenda.OU=Benefits.OU=HR. O=VerySmallCompany. Typeless names omit the container type in the name. The name Brenda.Benefits.HR.VerySmallCompany is typeless. If you don't provide a typeful object name, NDS calculates the object type of each container in the name.
The object types in the typeful name use the following abbreviations:
|
Object Class
|
Object Type
|
Abbreviation
|
|
Leaf object |
Common Name |
CN |
|
Container object |
Organization |
O |
|
Container object |
Organizational Unit |
OU |
|
Container object |
Country |
C |
Periods in NDS Names
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 HR.VerySmallCompany, it will locate the HR container by walking (searching) 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]. In other words, for each trailing period, NDS removes one object name from the left side of the current context.
For example, in Figure 1, suppose Brenda's current context is Benefts.HR.VerySmallCompany. If you enter "Brenda." as the relative distinguished name, NDS would remove one container from the left side of the context, append the relative distinguished name to the current context (without the left-most container), and would produce the distinguished name Brenda.HR.VerySmallCompany.
Practical Application of NDS Naming
Naming is a part of designing an NDS tree. Consistent naming standards and resource placement help users locate the resources they need more easily. In most cases, it's a good idea to create a naming standards document that defines what container and leaf object names should look like. For example, in this article, the name assigned to Brenda's User object was simply "Brenda". In many companies, the name of her User object would be formed by combining her first initial and last name; for example: BSmith. You can define what resource names should look like as well. For example, the printer in our sample tree was named simply "Printer". Perhaps you would want to identify the printer by its model name (lp3), or by its model name and floor (F22-lp3).
Conclusion
NDS utilities and documents continually refer to terms like distinguished name or typeful name. Understanding these terms and how the names work is essential to understanding how to operate or develop to NDS. NDS naming and terminologies follow the X.500 directory service standard.
* 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.