Novell is now a part of Micro Focus

Understanding and Using NDS Objects

Articles and Tips: article

JEFFREY F. HUGHES
Senior Consultant
Novell Consulting Services

01 Jan 1995


This AppNote explores the structure of NDS and the specialized objects used to create a tree. NDS objects represent the physical and logical entities of the network. Objects are defined as either container objects or noncontainer objects. Container objects can contain other objects. Noncontainer objects, also known as leaf objects, do not have subordinate objects. The main types of container objects used in tree creation are the Organization (O) and Organizational Unit (OU) objects. Understanding these objects allows administrators greater flexibility and choice in tree design, which in turn simplifies network management.

This AppNote is adapted from Chapter 2 of Novell's Quick Path to NetWare 4, by Jeffrey F. Hughes and Blair Thomas, by permission of SYBEX Inc. ISBN number 0-7821-1634-5, Copyright 1995, SYBEX Inc. All rights reserved. The book will be available from Novell Press in February 1995. See the Research Index for Novell Press ordering information.

Introduction

Before you begin the design of your NDS tree, you should have a clear understanding of NDS objects and their use in the tree. Understanding the objects will allow you greater flexibility and choices in your tree design. This AppNote explores the structure of NDS and the specialized objects that you will use to create your tree.

NDS objects represent the physical and logical entities of your network. The objects represent resources found on your network such as users, servers, printers, print queues, groups, and so on.

NetWare Directory Services defines a base set of object types that can exist in the NDS Directory. These objects types and their rules form what is called the NDS base schema. The NDS schema structure is automatically stored on every NetWare 4 server you install, even if you don't have actual objects defined and stored on that server. The NetWare 4 installation procedure places the schema on that server so that the database rules are in existence before you add objects.

Objects are defined as either container objects or noncontainer objects. Container objects can contain other objects. Noncontainer objects, which are also known as leaf objects, do not have subordinate objects. For example, users, printers, and NCP servers are leaf objects.

Each object type is defined by a set of rules known as the object class definition. Each class definition includes a set of attributes (also referred to as properties). For example, a user object describes an actual user on your network. The user object contains a list of attributes (or properties) associated with it. Information contained in the attributes is referred to as values. When you create a user you are adding values to the properties of the user object.

The attributes are defined in terms of data types. The object's attributes contain object information, access control information, and management data to maintain and control the actual network entity that the object represents.

One type of object is a user. The user object represents a particular network user and has particular properties associated with it. For example, users can be granted access rights to manage their own object and properties or a combination of the two. Among the rights granted by default to a user are the read and write rights to their Login Script property. This allows the user to modify or create a personal login script if they wish. You can revoke these rights if you don't want the user to add or modify a user login script.

In most cases, the default rights assigned to objects provide the access and flexibility required by users. Administrators will need to add file access for specific applications and create the necessary groups and subadministrators.

Structuring Container Objects

The main types of container objects you will use are the Organization (O) and Organizational Unit (OU) objects. The O object represents the company name and is generally the first object underneath the [Root]. (Use of the optional Country object is discussed later). Your tree can consist of more than one O to represent multiple organizations. You must define at least one O.

Below the O object are the OU objects used to represent geographic locations and organization departments. For example, an OU could represent your Atlanta office (OU=ATL), or your engineering department (OU=ENG). Generally, OU objects are nested to offer a further breakdown of a company's locations and departments. For example, you may have ten regions in your company and create ten OU container objects to represent those regions. You may further divide the locations under these regions by creating OUs to represent specific cities or departments.

Each OU object may contain leaf objects that provide a one-to-one representation of network resources. You may place resources and users in the lowest level of OU objects. However, you may also consider using a structure based on the "superserver" concept, which places servers at a regional OU level followed by OU objects that designate cities within the region (see Figure 1).

Figure 1: An NDS tree structure with regional, city, and department container objects, and leaf objects.

The Country Object

Novell's 4.1 utilities also allow you to create a Country (C=) object. The Country object provides another layer of identification for your company's tree and may be needed for participation in a global NDS network. The Country object is directly below the [Root] object in your NetWare 4.1 tree.

As Novell works with other third-party providers to introduce NDS as a global operating system, the use of the Country object may become necessary for some corporations. Worldwide corporations may use the Country Object as their entry point into a global NDS provider. Other companies may only need to use their O= as their entry point. These issues are still being defined.

There is no problem in designing the tree with the Country object if you anticipate connecting to one of these NDS service providers.

Special Purpose Objects

Most of the questions regarding NetWare 4 objects are about using ADMIN and other specialized objects. The following sections explain how, why, and when to use ADMIN, Alias, Organizational Role, Group, Profile, and Directory Map objects.

The ADMIN user object is created automatically when you first install NetWare 4. Initially, this special user has rights to the entire tree and includes Supervisor rights of every server added to the tree. The ADMIN user is the first administrator of the tree. This user not only has complete access to the file system (just as the Supervisor does in NetWare 3) but he or she also has full access to NDS as well.

NDS grants the ADMIN such power in order to initially install the tree and establish rights for the file system on your first NetWare 4 server. As time goes on you may want to distribute administration of NDS and the file systems to other administrators.

Note: ADMIN is not a reserved user name as is Supervisor. You can always rename this object to something less conspicuous.

The importance of maintaining the ADMIN user cannot be overemphasized. When you first install NetWare 4 the ADMIN user is created at the O=Organization level. The ADMIN user has all rights (NDS and file system) at the [Root] object and, at this point in your installation, is the only user with such complete and extensive access to your network.

If you should accidentally delete the ADMIN user, your access to the tree is effectively removed from the tree. Restoring access to the tree is a tedious process and can only be accomplished with the assistance of Novell Technical Support.

After you have installed the first couple of NetWare 4 servers ensure that the ADMIN password is protected.

Follow the steps below to diminish the likelihood of losing access to your tree.

  1. While creating your first NetWare 4 server, you are prompted for a password. Choose a password that is easy to remember and yet not common to people in your environment. For example, don't use your friends' or children's names, spouse's name, or local football team.

  2. Create a second ADMIN user as a backup using the NWAdmin utility. Do not make this object security equivalent to the original ADMIN user. If the original ADMIN were to be deleted, your second ADMIN would have no access to the tree because the security equivalency would be lost. Instead, assign explicit Supervisor rights for this second ADMIN at object [Root]. After you create this second ADMIN with its password, you will have a backup ADMINin case of emergency.

  3. Consider changing the password periodically so that fewer people will know it and distribute it. Initially, a group of people may need to know the password. Eventually you should be able to reduce the number of people who have access to the ADMIN account.

Note: If you're installing a new NetWare 4 system, rather than upgrading from NetWare 3, the ADMIN user password is also assigned to the bindery Supervisor.

Using the Alias

An alias is a special object that points to another object you specify in the directory tree. An alias can point to either a container object or a noncontainer object. The object being "aliased" is known as the primary object or aliased object.

For example, you may want users to access a particular resource contained in another OU such as a printer. You can create an alias that references a printer in a particular OU as shown in Figure 2. The alias is a pointer to the other object. It can be considered a relay to another object in a different part of the tree

Figure 2: An Alias is used here for access to a particular printer that resides in another OU.

You can also alias one Organizational Unit to another OU, thereby giving one OU rights to the aliased OU's resources. For example, you may have created a Workgroups OU object that contains a series of workgroup servers.

However, users in other OU objects also need access to those servers in the Workgroups OU. You can set up an alias from the several OU's to the Workgroups OU. This example is demonstrated in Figure 3.

Figure 3: Aliasing two OUs to the Workgroups OU to provide access to its servers.

This is a very powerful feature and should be used carefully. A situation where you would consider using this alias would be if you have created a workgroup OU which contains a series of workgroup servers. You have users in other OU's which need access to those servers in the Workgroup OU. You can alias the users from several OU's to the workgroup OU and obtain access(based on security assignments) to those servers.

Naming Alias Objects

You may want to give an Alias object a name that indicates that it is a pointer to another object. For example, the name might include the word Alias such as Alias_Bob.

On the other hand, you may not want to give the Alias object any distinction from the original object. Your users may not need to know the difference, and adding the alias label could just confuse them when they are logging in to the network.

Granting and Administering Alias Rights

It is important to understanding how rights are granted and administered to an alias. The alias has two states: Dereferenced and Non-dereferenced.

Dereferenced means that the alias points to the properties of the primary object. If your alias object is dereferenced, it means that when you change the alias object you are actually changing the primary object.

Non-dereferenced means that you are pointing to the properties of the alias itself. If you change a non-dereferenced alias you are changing the alias object itself. Some operations using the alias automatically are non-dereferenced. These activities include moving, renaming, or deleting the alias object. If you delete the primary object, you will automatically delete the alias object.

Using Organizational Role Objects

The Organizational Role (OR) is extremely versatile and similar to a Group object. The basic difference between using an OR object and a Group object is that a Group object is generally used in a login script (as in "IF MEMBER OF GROUP") and is activity oriented (such as for accessing a word processing application on your server). OR objects are not used in login scripts and are more suited to creating sub administrators containing a small number of occupants. The OR object has an attribute known as "role occupant."

An occupant can be moved in and out of the OR quickly to facilitate short term assignments. If the regular Administrator is absent for any length or time, another user can be moved into the Administrative OR temporarily to manage the network.

You create the OR object and assign specific rights depending on the characteristics needed for the role. You then assign users to the OR as occupants through the NWAdmin utility.

For example, if you wanted to assign a user to be an Organizational Unit OU_ADMIN, you would create an organizational role called OU_ADMIN and give that role some explicit object rights assignments based upon the needs of that role.

The next step is to make a user an occupant of that organizational role. Through security equivalency to the OU_ADMIN object the occupant gains the rights that the OR has been assigned. These can be Supervisor rights or less powerful rights as appropriate.

As shown in Figure 4, we have created an organizational role for OU=Eng. This role is to be used as a subadministrator in the engineering department. After creating this OR, we grant Supervisor object rights to role on the object OU=ENG. This means that we are granting rights contained in OU=Eng to the OR ENG_ADMIN. Next, we specify Bob and Sally as occupants to the Organizational Role.

Figure 4: An organization role is created for the engineering department. Bob and Sally are made occupants of this role and can function as subadministrators. department. Bob and Sally are made occupants of this role and can function

Through the mechanism of security equivalency Bob and Sally receive all rights granted to the OR ENG_ADMIN and have the necessary rights to be subadministrators for the engineering department.

Using Profile Objects

The profile object is used as a special-purpose scripting object that executes a login script after your OU login script. The profile script can contain special drive mappings or environment settings you want a select group of people to receive. The profile will execute for those users whose profile attribute has specified a profile object for execution.

When you first set up a user using the NWAdmin utility, you can specify that the user execute a particular profile. You can also add a user to a profile anytime after.

There are three main uses for a profile script:

  1. Creating a global login script.

  2. Creating a location login script.

  3. Creating a special function login script.

Creating Global Login Scripts

Netware 4 does not use a global, system login script. Each OU object you create has its own login script referred to as the container login script. The order of execution of login scripts is as follows:

  1. Container login script, if present

  2. Profile login script, if used

  3. User login script or the default login script if no other script is available

Therefore, if you want to create a more global login script and include users from multiple OUs, you could employ the Profile object to set up a specific environment for a group of users. A Profile is used to provide an additional set of drive mappings to what is specified in a container login script.

Creating Location Login Scripts

A profile can also be used for determining resource allocation based on location. For example, suppose each floor of your company has three printers and three print queues, and you want to be able to assign a particular group of users to a specific print queue. You can use a profile login script to capture to a particular print queue. The users whose profile attribute has been specified will automatically capture to that print queue.

Creating Special-Function Scripts

You can create a Profile object for a special function script, such as one to assign access for applications. For example, you can create a Profile script that will be used by administrators only. This script may give these users a specific drive assignment to the NWAdmin Utility.

In this scenario, you would move the NWAdmin utility from the SYS:Public directory into a new subdirectory you create called ADMIN. When an administrative user logs into the network, the Administrator Profile executes and assigns that user a drive mapping to the ADMIN directory. Only the users executing the profile script will be mapped a drive to the NWAdmin utility. You can then grant Read and File Scan rights only to the administrative users.

Using Group Objects

You may wonder what the difference is between using Group objects and using OU objects. It is true that users as members of both objects receive rights by security equivalence. However, the filtering of these rights is handled differently.

Note: Group objects in NetWare 4 serve the same function as they do in NetWare 3.

Because of security equivalency, any member of a container will receive whatever rights the container possesses. An Inherited Rights Filter(IRF) will not mask these rights. Users inside Group objects also receive whatever rights the group possesses.

You can use Group objects to give users within an OU or multiple OUs specialized rights assignments. This allows you to provide specialized assignments to a smaller subset of users within your tree.

Figure 5 shows an OU object called OU=MKTG, populated with users and resources. Within this OU are two marketing staffs working on different projects, Staff1 and Staff2.

Figure 5: This is an example of using groups within an OU for differentiating rights assignments.

Each group is accessing different software on the server and needs different rights assignments. We create two groups called Staff1 and Staff2 and grant specific rights to each. Within the OU login script (known as the system login script in NetWare 3) the "IF MEMBER OF GROUP" statements are used to determine which users are part of Staff1 and Staff2. When each user logs into the network, the login script determines which group the user belongs to and then the appropriate drive mappings are assigned for file system access.

Another less desirable way to accomplish this same procedure is to create two more OUs under OU_MKTG called Staff1 and Staff2. This method adds more layers of complexity to your tree and causes you to create and administer two more container login scripts (one for each marketing group). In the first example the groups' assignments would be executed in the OU_MKTG login script.

Note: Keep in mind that each OU created has its own OU (system) login script. The user's login procedure looks to its own OU for a login script and does not search any higher in the tree for an OU script.

As explained in the previous section, the order of script execution is as follows:

  1. The container login script

  2. The Profile script (in addition to the container login script if available)

  3. The user script (in addition to the container and profile scripts if they are available)

If no user script is available, the default login script is executed. This means, at a minimum, one login script - the default script - will be executed. At a maximum, three scripts - a container script, Profile script, and user script - will be executed.

Using the Directory Map Object

The Directory Map object is a special-purpose object used for pointing to a specific volume and directory path on a NetWare server. Using the object name then allows you to map a drive letter to the Directory Map object name in your container login script. For example, you have just installed a new WordPerfect application on your server and five containers in your tree need access to a particular application. Each container has its own login script with a reference to the WordPerfect application by mapping a drive assignment such as:

MAP S16:=WordPerfect.ESP.O=NOVELL

If, later on, the WordPerfect version was updated, the drive assignment within the Directory Map object "WordPerfect" would be changed to reflect the path of the new version of WordPerfect. In one step all the users in five containers are automatically redirected to the new version of WordPerfect. This can be a real time saver in large network environments. The only change is to the Directory Map object.

Assign the Directory Map object a path to the file(s) that you are referencing. You also must perform a second step of assigning each user Read and File Scan rights to the file(s). Another method is to grant Read and File Scan rights to the Directory Map object, and then make each user security equivalent to the Directory Map object.

Because this is a cumbersome step, you may also consider assigning the file rights to each OU. Users are security equivalent to their OU.

Extending the NDS Schema

The number of objects and properties currently in NDS is quite comprehensive. However, eventually you may want to create new objects. You can extend the NDS base schema by using Novell's Directory Application Programming Interfaces (APIs) to create new objects, class definitions, and attributes as well as by adding existing attributes to existing class definitions. For example, you may need a special object to represent a group of CDs that could be controlled through NDS.

Any changes to the schema will be reflected on all NDS servers in the tree. However, the Novell 4.1 utilities will not allow you to add or modify objects in your new object classification. You will need to create utilities that can manage these new objects along with the currently defined NDS objects.

In the future, Novell or third party applications will allow you to modify the schema and your own utilities in one process. This way, your utilities will be able to display any changes to the NDS schema immediately.

Conclusion

Once you understand the use of NDS objects you will have greater flexibility in managing and designing your NetWare 4 tree. This is only the beginning. Novell and third party developers will produce many more new and exciting objects in the months and years ahead.

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

© Copyright Micro Focus or one of its affiliates