Context and Names

In NetWare Directory Services (NDS), context refers to the location of an object in the Directory tree. Context is important because NDS objects are identified by their relative location in the Directory tree.

The complete context, or path, from an object to the [Root] of the Directory tree in addition to the object's common name forms an object's Distinguished Name (also called the complete name). The context, or path, from an object to another object in the Directory tree forms that object's Relative Distinguished Name ( RDN).

For example, in Figure 2-5, the following is true:

The context for the User object ESAYERS is OU=DESIGN.OU=LONDON.OU=MFG.O=ACME.C=US
The Distinguished Name for User object ESAYERS is CN=ESAYERS.OU=DESIGN.OU=LONDON.OU=MFG.O=ACME.C=US.
The context for the User object RJONES is OU=HR.OU=HQ.O=ACME.C=US
The Distinguished Name for the User object RJONES is CN=RJONES.OU=HR.OU=HQ.O=ACME.C=US.
The Relative Distinguished Name for the User object RJONES in relation to the Organizational Unit SALES is CN=RJONES.OU=HR.OU=HQ.OU=SALES.
Figure 2-5 Context in a Directory Tree

Because names and contexts can be confusing for users, consider the following guidelines:

Limit the levels of container objects you have in your Directory tree.
Because it is difficult for some users to remember long Distinguished Names with multiple layers of Organizational Units, you might choose to have no more than two or three levels in your Directory tree.
Use short object names.
Because each object is identified by its location within the Directory tree, use a naming scheme that is both practical and functional for your organization.
For example, name servers for their function within a specific organization, and name printers for their type and location.
Use Alias objects for accessing objects not in current contexts. Alias objects point to objects that exist elsewhere in the tree.
For example, if RJONES wants to use Accounting's printer, you can create an Alias object for that printer and put it in RJONES' context.
This way, RJONES can find the printer in his own context, and he doesn't have to remember the longer "real" name of that printer.
Avoid using spaces in names.
Spaces in object names appear as underscores in some utilities.
In other utilities, you might have to enclose the name in quotation marks to avoid having the utilities treat the two-word name as two separate commands or objects.

Common Names

All leaf objects in the Directory tree have a common name. For User objects, the common name is the login name displayed in the Directory tree. For example, the common name for Edwin Sayer's User object is ESAYERS.

Other leaf objects also have common names displayed in the Directory tree.

See "Common Name" in Concepts for more information.

Name Types

Names in the Directory tree have two name types: typeful and typeless. A typeful name includes the name type (OU, O, etc.) of each object in the Distinguished Name of an object. A typeless name excludes the name type for each object.

A name type distinguishes the specific object you are referring to, such as a User object or an Organizational Unit container object. For example, the following typeless name

ESAYERS.DESIGN.LONDON.MFG.ACME.US

is expressed with name types as

CN=ESAYERS.OU=DESIGN.OU=LONDON.OU=MFG.O=ACME.C=US

where CN is the common name of the leaf object, OU is the Organizational Unit name, O is the Organization name, and C is the Country.

In most cases, you do not need to use name types.

Any time you move from one container object to another, you change context. Whenever you change contexts, you might need to indicate the Distinguished Name of the object you are changing context to.

If you are referring to an object in the same container as your User object, you need only refer to the object by its common name.




	NOTE: All Distinguished Names should be unique within a Directory tree. In addition, all object names should be unique within a container. The NDS database recognizes only one occurrence of the same name within each container.

Logging In and Authentication

The location of an object within the Directory tree, or name context, is also important when logging in. When a user logs in to the network, an available server begins a process called authentication.

Based on the current context and the login name provided, authentication identifies the User object to other servers in the tree and verifies that the object has rights to use network resources.

Authentication allows a user who has logged in to the network to access any servers, volumes, printers, etc., in the network that the user has rights to. Conversely, if the users lacks rights, access is denied.

Authentication checks a user's rights to both NDS and file-system resources. This is one way you, as a network supervisor, can regulate security.

Authentication works in combination with the Access Control List to provide network security. See "Property Rights" in this chapter for more information.

Also see "Name Context" and "Authentication" in Concepts for more information.

Object Naming Rules

Apply the following rules when naming NDS objects:

The name should be unique in the branch (container) of the Directory tree where the object is located.
The name can be up to 64 characters in length.
You can use special characters. But, if the object needs to be accessed from a workstation running the NetWare Client shell (NETX), you should avoid using special characters.
For a list of these special characters, see "Naming Restrictions for Bindery Services" in this chapter.
Object names are displayed with uppercase and lowercase letters as they are first entered, but they are not case-sensitive. Therefore, "ManagerProfile" and "MANAGERPROFILE" are considered identical names.
Spaces and underscores can be used and are displayed as spaces. Therefore, "Manager_Profile" and "Manager Profile" are considered identical names.
If you use a space in a name, you must place quotation marks around that text string whenever you use a command line utility that includes that text string. For this reason, spaces are not recommended.
Country objects can have only two-character names. For example, the United States is US.




	CAUTION: If you anticipate managing objects created from different code pages, you must limit object names and properties to those characters common to all the applicable code tables. Nondisplayable Unicode* characters for your code page are represented by an ASCII 3 character (a "heart" symbol). For more information, see "Unicode" in Concepts.

Naming Restrictions for NetWare Server Objects

The following restrictions apply when naming Server objects:

When you install NetWare 4, an NDS NetWare Server object is created for the server in the container object you specify.
If you create a Server object for a server other than a NetWare 4 server, you must use the server name for the object, because NDS searches for the server to verify its existence.

For more information on NetWare Server objects, see "Object" in Concepts.

Naming Restrictions for Bindery Services

When you create objects to be accessed from workstations running the NetWare Client shell (NETX), the names of the objects must follow bindery naming rules or these clients cannot recognize them. Object names in bindery services are interpreted as follows:

Spaces in object names are replaced by underscores
Object names are cut off after the 47th character

You cannot use the following characters in an object name that must be accessed from a workstation running the NETX client:

/ slash

\ backslash

: colon

, comma

* asterisk

? question mark




	NOTE: The object naming rules apply to most objects. Additional rules applying to NetWare Server objects and objects viewed through bindery services are described in a separate chapter. See chapter 4 for more information.

Naming Restrictions for International Support

Unicode is a wide character encoding scheme that provides the basis for internationalization of the information in an NDS database. All character strings exchanged between an NDS server and a client workstation are in Unicode. The NetWare Client software handles the translation of Unicode strings.

Occasionally, however, you might use characters that Unicode cannot translate. When this happens, the character is substituted in your display as a "heart" symbol in DOS and as a box (q) in Windows.

Substituted characters can prevent NDS from recognizing an object. See "Unicode" in Concepts for more information.

Context and Names

Technical documentation

» Table of Contents

» Glossary

» Index