Implementing Naming Standards for NetWare Directory Services

Articles and Tips: article

J. ORLAND SEAVER
Senior Consultant
Novell Consulting Services

01 Feb 1994

This AppNote gives some guidelines for setting up naming standards for objects in NetWare Directory Services (NDS). A consistent naming standard is crucial in implementing NDS efficiently. By carefully defining naming standards, administrators can simplify growth of enterprise networks. A naming standard makes Directory objects more uniform and more useful to the organization. An effective naming standard document includes a list of objects to be implemented, the format of each property value, and the intended use of each property.

Related AppNotes Apr 93 "An Introduction to NetWare Directory Services" Apr 93 "Planning a NetWare 4.0 Directory Tree"

Introduction
General Naming Standard Guidelines
International Considerations
Example Naming Standard

Introduction

As network computing moves from a local to a global environment, using common symbols to communicate the nature of the network resources grows increasingly important. These common symbols are defined through the use of a naming standard. When a network is small the idea of a naming standard seems almost trivial. However, when the network grows to thousands of resources in many different locations, a naming standard is obviously required. Unfortunately, if a naming standard was not adopted when the network was small, it is difficult and expensive to change to a new standard after a large network is in place.

This AppNote discusses the purpose of a naming standard, offers guidelines for creating an appropriate naming standard for your organization, and presents a specific naming standard based on Novell Consulting Services (NCS) experience. This naming standard can be used as is or can become the basis for a customized standard. This AppNote assumes that readers are familiar with NetWare Directory Services (NDS) and the principles behind an X.500-compliant directory service. For background information on NDS, see the April 1993 issue of NetWare Application Notes. The AppNote "Planning a NetWare 4.0 Directory Tree" (p. 55) contains general information on naming standards.

General Naming Standard Guidelines

To allow an organization to build for the future, the first consideration in implementing NetWare 4 should be establishing a set of specific, defined naming standards. Implementing a consistent naming standard throughout the enterprise, regardless of the number of trees, will allow the greatest flexibility to merge or rearrange the Directory structure in the future.

Names should be consistent to allow users from one Organizational Unit (OU) to recognize resources from another OU as they browse the Directory tree. Consistent names reduce the time required to train users as they move from one OU to another. Consistent names also reduce the cost of administering network services, and allow different trees to be merged to create a larger, consistent tree.

Names of all objects within the enterprise should be implemented with future growth in mind. For example, we recommend that the username should follow a defined E-mail name, which is normally unique within the organization, rather than simply be the first name of the user. With NetWare 3, servers set up to use the first name as the username worked well because most systems were confined within a single department or office area. With the implementation of a global Directory, however, using an E-mail name makes more sense.

Be careful not to create names that become dated. For example, when Bill installed a NetWare 3 server several years ago in the accounting department he called it BILLSERV. Now Bill is gone, and the server is still named after him. Many people like to use "cute" names for resources, like CALVIN, HOBBES, SNOOPY, ELVIS, and so on. The problem with cute names is that they usually have no meaning to users at other locations trying to access the resource. Another pitfall is labeling resources with a software version number or with the word new in the ID. Names like SERV311 or NEWSERV can quickly become outdated.

We recommend using names that associate the resource with its location or use. For example, BILLSERV would have been more appropriately named ACCTG. Two good tests to use in judging a name are:

Can new employees remember it?
Will the name will still be applicable in three years?

When administrators learn the reasons behind a naming standard, they usually follow it more strictly than if they are told, "That is the way it is." When administrators are convinced that a naming standard has value to them, they are more conscientious about collecting and formatting property values for each object. The objects they set up are more uniform and more useful to the organization. A good naming standard can thus become a powerful asset to the organization as NetWare 4 is deployed within the department and throughout the enterprise.

Features of a Good Naming Standard

A good naming standard document includes the following:

A list of objects to be implemented and supported in the Directory.This includes the standard name format to be used for each object type.
Required objects (and the reasons they are required)
Required properties
Format of each property value (uniform formats make data more useful)
Intended use of each property (to help administrators understand why they enter all of the data)
Optional properties
Optional objects (and when they can be used)
Objects not implemented (and why)

Objects To Be Implemented. The list of objects to be implemented helps administrators understand what building blocks are available to them as they organize their Directories. For each object, include a short paragraph explaining the use of the object within the organization. You can also use this section to discuss relationships among objects.

Confusion and errors are reduced when administrative personnel understand the use of each object and which tasks require which objects. Examples of the implementation of required and optional objects clarify the use and relationships of Directory objects.

Property Information. A list of required properties is associated with each object. These subsections should provide detailed information for each of the supported object properties. Each property should be explained. Defining the property value format allows property values to be more useful to applications accessing NDS. Explaining the use of each property allows administrators to understand why the property is being entered into the Directory.

Required Objects. Use this section to define required objects and relationships among objects. Explain the use of each object and include task-oriented examples. Administrators should be able to use this section as a simple reference in understanding the relationships among the objects they manage.

Optional Objects. These objects simplify administrative tasks, but they may not always be applicable. Use this section to define optional objects and their relationship to required objects.

Objects Not Implemented. This section explains why certain objects have not been used within an organization. For example, many organizations do not wish to use the Country container object in their Directory structure. In this case, the naming standard should explain that the Country object type will not be used in the Directory because Directory lines are structured around business functions, not international boundaries.

International Considerations

Organizations that have locations in different countries and use different languages have some interesting problems when naming resources. We recommend using names that can be recognized simply as character strings. Because most users recognize English computer terms, use simple English names as your base for international object names. Short, concise names often include initials such as LJ to represent a laser printer in all countries. Even if the user doesn't know what the initials stand for, short initials can be easily memorized and understood in all languages.

In the long term, it is more important to have a uniform naming standard across all countries than to have country-specific names. (At the same time, you need to be aware of cultural sensitivities and use country-specific names when necessary.) As organizations continue to implement business functions across international boundaries, the uniform names in the Directory result in significant savings in the costs of user training, network access, and administration.

Example Naming Standard

There is no "correct" naming standard. Different organizations may adopt different naming standards based on both their requirements and their existing configurations. This naming standard is offered as an example that will work well for an organization, regardless of size, but can be modified and adjusted as desired to better meet the requirements of the organization.

In our examples, we have tried to create relatively short names. This helps keep the context short and reduces data traffic as NDS searches for specific objects. You may have already chosen a different format to name users or servers in NetWare 3, and you may want to use those names as a starting point as you implement NetWare 4.

Organization and Organizational Unit Names

Our Organization and Organizational Unit names are based on our company's abbreviations of our unit names. For example, our organization is NOVELL, our business unit is ASG, and our division is NCS. Thus our context in the corporate tree is OU=NCS.OU=ASG.O=NOVELL.

Server Names

Our naming standard uses a server name made up of three-character codes for the location, division, and server. We use the airline city code as the three-character location code. This code is widely recognized because all commercial airports in the world have one. Therefore, a server located in Provo and used by NCS is named PRV-NCS-001. Server names must be unique. So if you have one server named ACCTG, you cannot have another server with that same name anywhere on the enterprise network. (This is a restriction of SAP rather than NDS.)

Printer Names

The printer name includes the three-character location code (again the airline city code) followed by the mail stop and the printer type. For example, our LaserJet 4 SI would be named PRV-E232-LJ4SI. Our duplex LaserJet 4 SI in the same location will be named PRV-E232-LJ4SID.

Print Server and Print Queue Names

Our print server and print queue names start with the characters PS and PQ. The rest of the name contains the department server name and a number for each print server or print queue. For example, our print server is named PS-NCS001-1 and it services print queues named PQ-NCS001-1 and PQ-NCS001-2.

Usernames

We restrict usernames to eight characters to match our E-mail name length. The E-mail name consists of the first letter of the first name, followed by the last name. For example, Bill Smith becomes BSMITH. If we have more than one person with the same first initial and last name, we add the middle initial as the second character of the name. For example, Bill Smith might be BSMITH and Beverly Lynn Smith would be BLSMITH.

Group Names

Group names are based on the function performed by the group. For example, our word processing group is named GP-WP.

Organizational Role Names

For security purposes, we always use the Organizational Role object to grant administrative rights. The Organizational Role object can be used in any situation where changes in personnel may be frequent or when an error in controlling rights would pose a grave security risk to the organization. For example, our container administrative organizational role is named OR-NCSADMIN.

Profile Names

Profile names are based on the function supplied by the profile. For example, the profile in our container providing all the required mappings for the departmental users is named PF-NCSMAP.

Directory Map Names

We name our Directory Maps after the application or process being mapped. For example, our WordPerfect application files are mapped with a Directory Map named DM-WP.

Property Value Formats

Property value formats are as follows:

Postal Address The postal address consists of the following fields:

Street
P.O. box (if applicable)
City
State or province
Postal/zip code
Nation

Telephone Number The telephone number consists of the following information separated by hyphens:

Country code (1 for the USA)
Area code
Prefix
Number
Extension (if applicable)

If an extension is required, insert a space between the main number and the extension number, as in this example:

1-800-453-1267 7633

Recommended and Optional Objects

The following table offers detailed information on objects and their associated properties. Objects are listed in alphabetical order. After each object, we indicate in the Mandatory/Optional column if it is a required or optional object inside our tree. The Description/Format column describes the object. The codes used in the Mandatory/Optional column are:

M Mandatory R Recommended O Optional U Unused (recommended that the property not be used) A Automatic (maintained automatically by NetWare) MV Multivalued (several values of this property can be stored) T Template (will be entered as a default by a template) * Implementation issue (decision to be made during implementation planning)

Figure 1: Objects and associated properties.

Object	Property	Mandatory/Optional	Description/Format
Alias		O	Use this objectto create an alternate name for an object.This allows "easy to use" names to be createdwithin an Organizational Unit that referenceresources in another OU.
	(All properties)	See Note	Based on theobject aliased. When accessing the alias,you actually access and see the informationfrom the actual object being aliased. Allnaming standards and rules that apply tothe object also apply to the alias.
Computer		O	Use this objecttype to record information about computersthat are not NetWare servers, such as Unixcomputers. To avoid a maintenance nightmare,do not include desktop PCs.
CN (Object name)	M	Name of computer,such as Unix host name
Other names (MV)	R	Asset number Optionally,any previous host name
Owner	R	Division anddepartment owning the computer
Description	R	Short descriptionof the computer, explaining its make, model, and use
Serial Number	O	Serial number
Location	R	Location, building,floor, room number
Department	O	Department/divisionowning the computer
Organization	O	Organizationowning the computer
Server	O	Server to whichthis computer will attach. Blank (this canonly be a NetWare server) unless this computeracts as a client to a NetWare server
Operator (MV)	O	Login nameof operator(s)/system manager
Network Address (MV)	R	Address ofthis computer in each of the protocols thatare supported by the computer.
See Also (MV)	O	Related NDSobjects, such as print queues
Directory Map		O	May be usedto protect individual users from possiblefuture change of the directory structureof an application. Note that even if a DirectoryMap is used, rights to the directory mustbe granted. (Rights are usually best grantedby membership within a group.)
	Other Name (MV)	O	Other names for this map
	Volume	M	Name of volumefor the directory being mapped
	Path	M	Path of thedirectory being mapped
	Description	R	Descriptionexplaining the purpose of the Directory Map
	Location	O	Location thatrequires the map
	Department	O	Departmentrequesting/using the Directory Map
	Organization	O	Organizationrequesting/using the Directory Map
	Rights to Files and Directories	O	Rights to accessfiles and directories accessed by the mapcan be granted here. However, the simpleuse of the map does not give the rights grantedhere to the user. A user or group must begranted security equivalence to the map toobtain these rights. By using security equivalenceyou can protect the user from any changeof directory at both the object name andfile/directory rights levels.
	See Also (MV)	O	Related NDSobjects, such as other maps, groups using the map, and so on.
Group		M	A list of userswith a common access requirement, such asLotus users or printer operators. Using groupseases the administrative load of controllingrights to resources within the network.
	CN (Object name)	M	Name of group
	Other names (MV)	O	Alternativenames for the group that might aid searches
	Owner	M	Login nameof user responsible for defining and maintainingthe list of members of the group
	Description	M	Purpose/membership criteria
	Location	O	Location, building,room number
	Department	O	Department/division name
	Organization	O	(Give property value)
	Member	M	Login names of members
	See Also (MV)	O	Related objects

Table 1 (continued):

Object	Property	Mandatory/Optional	Description/Format
NetWare Server		M	The objectrepresenting a NetWare file server computer
	CN (Object name)	A	The uniquename of the file server. This should be ameaningful and unique name. This object isnormally created through the installationprocess.
	Other name	M	Asset number
	Description	R	Make and model,CPU, RAM, and disk capacity
	Location	R	Location, building,floor, room number
	Department	O	Department/divisionowning the server
	Organization	O	(Give value)
	Network Address	A	IPX internal network number
	Status	A	Up/down
	Version	A	OS version,such as NetWare 4.01
	Operators (MV)	R	Login namesof the operators
	Supported Services	R	As many ofthe following services as apply:- File-Print- NFS- FLeX/IP- SAA Gateway-E-mail Server
	Resources	O	Server's resources,such as printers, volumes
	See Also (MV)	O	Related objects
	Users	O	Users specificto this server (we suggest you leave this blank)
Organization		M	The objectrepresenting the company or other organization
	CN (Object name)	M	Organizationname (short format)
	Other name	M	Full legaltitle of organization (for example, Novell, Inc.)
	Description	O	Any commentsabout scope of O object, such as subsidiaries excluded and so on.
	Location	O	Head office location (brief)
	Telephone Number	R	Head office telephone number
	Fax Number	R	Head office main fax number
	E-mail address	O	*
	Postal Address	R	Head office postal address
Organizational Role		M	We recommendthat all administrators be granted authorityto administer their part of NDS through theuse of Organizational Roles. We recommendthat you never grant administrative authoritydirectly to a user. Always use an OrganizationalRole to grant authority to perform administrativeresponsibilities. A job role that may beswitched between staff members may also becontrolled by use of the Organizational Roleobject.
	CN (Object name)	M	Short descriptionof the role (max 16 characters), such as NDS Administrator
	Other names (MV)	O	Another namethat assists searches
	Occupant (MV)	M	NDS name ofuser(s) currently performing this role
	Description	R	Full description of the job role
	Location	O	Location where role is fulfilled
	Department	O	Department/divisionwhere role exists
	Telephone Number	O	Role telephone number, if applicable
	Fax Number	O	Role fax number, if applicable
	E-mail address	O	Probably not used
	Postal Address	O	Role address, if applicable
	See Also (MV)	O	Related objects, such as aliases
OrganizationalUnit		M	A divisionor department within the organization
	CN (Object name)	M	The OU namedefined in the corporate NDS tree, such as NCS
	Other names (MV)	O	Alternativename for division (such as CONSULTING) to aid searches
	Description	R	Official nameof the organizational entity, such as Novell Consulting Services
	Location	O	Divisional head office location
	Telephone Number	R	Division's telephone number
	Fax Number	R	Division's fax number
	E-mail address	O	Probably not used
	Postal Address	R	Divisionalhead office postal address
	See Also (MV)	O	Related objects (probably blank)
Print Server		M	An object representinga NetWare print server
	CN (Object name)	M	The uniquename of the print server. This should bea meaningful and unique name.
	Advertising Name	M	Name used whenloading PSERVER.NLM (should be same as CN)
	Other name	O	Alternativename to assist searches
	Network Address	M	IPX addressof server running PSERVER.NLM
	Description	R	Short description,such as HP Ethernet print server in Consulting Services
	Location	R	Location, buildingand floor (include the name of the host serverif it's an NLM print server)
	Department	O	Division/departmentowning the print server
	Organization	O	(Give value)
	Version	A	Version of PSERVER.NLM
	Status	A	Up/down
	Operators (MV)	M	Login nameof users responsible for managing the printserver, and able to down it and control attachedprinters
	Users (MV)	O	Login nameof users allowed to see the server status
Printer		M	An object representinga printer
	CN (Object name)	M	Printer name
	Other names (MV)	R	Asset number
	Description	R	Make and modelnumber in Asset Database format, such as HP4A
	Network Address	O	IPX address,if attached to server (probably blank)
	Location	R	Town, building,floor, room, position if not in room
	Department	O	Division/departmentowning the printer
	Organization	O	(Give value)
	Print Server	M	Print serverthat services the printer
	Default Print Queue	M	The objectname of the default print queue
	Page Description Language	O	PDLs available,such as PostScript
	Memory	O	Memory in printer, such as 2MB
	Supported typefaces	O	Fonts available
	Supported cartridges	O	Type of cartridges in printer
	See Also	O	Related objects

Table 1 (continued)

Object	Property	Mandatory/Optional	Description/Format
Print Queue		M	A print queue(temporary storage of print jobs betweenuser requesting print and output to physical printer)
	CN (Object name)	M	Printer nameas defined above
	Volume	M	Volume namestoring queued files (recommend that it not be a SYS volume)
	Other names (MV)	O	Alternativenames to aid searches
	Description	R	Identify asthe queue for which printer(s)
	Location	O	Location ofserver hosting the queue
	Department	O	Division/departmentowning the printer
	Organization	O	(Give value)
	Operators (MV)	M	Login namesof operators responsible for managing print jobs on the queue
Profile		O	A login scriptapplicable to a subset of users in a container,or subsets of users in several containers
	CN (Object name)	M	Short classification,such as Consultants
	Other name	O	Alternativename to aid searches
	Description	M	Purpose and usage criteria
	Location	O	Location, building
	Department	O	Division/department
	Organization	O	(Give value)
	See Also (MV)	O	Related objects, such as Groups
	Login Script	M	Script commandsas required by the users of the profile
User		M	A user of the network
	CN (Login Name)	M	User's loginname in format noted above.
	Last name	M	Surname, such as Jones
	Other names (MV)	R	First names, such as William
	Title (MV)	R	Job title
	Description	R	Descriptionof user's position, related details (freeformat) If user has a secretary, give secretary'sname and telephone extension also.
	Location	R	Location, suchas town, building, room number
	Department	R	Departmentname (use standards list to give dept name conventions)
	Telephone	R	Telephone number
	Fax number	R	Fax number (T)
	E-mail address	O	Address ofuser in E-mail system
	Language	M	English (T)
	Network Address	O	IPX node addressof user's PC (normally left blank)
	Default Server	M	The serverwhere the user's information will be stored by default
	Home Directory-Volume- Path	M	User's homedirectory for storage of personal files,given as a Volume object and a subdirectorypath to the specific subdirectory
	Postal Address	O	(T)
	See Also (MV)	O	Could be usedfor the user's secretary's user object (loginname), if user has a secretary. Other relatedNDS objects, such as Alias objects
Volume		M	A volume ona NetWare server (a volume is the root of the file system)
	CN (Object name)	M	Name of volume,such as SERVERNAME_SYS
	Host Server	A	Server hosting this volume
	Host Volume	A	Physical nameof volume, as defined when volume was createdduring installation (can only be changedthrough INSTALL program)
	Other name	O	Alternativenames for NDS searches to the volume
	Location	O	Floor, building,town (will be the same as server location,so it's not required)
	Department	R	Division/departmentwhose data is stored in this volume
	Organization	O	(Give value)
	See Also (MV)	O	Related NDSobjects, such as Alias objects

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