Understanding and Using NDS Alias Objects
Articles and Tips: article
NetWare Text Utilities
01 Sep 1993
In NetWare 4.x, Alias objects are NetWare Directory Service objects that provide a quick way of accessing objects in another context. Aliases are a very powerful feature of NetWare. For many users, aliases are new and therefore intimidating. The purpose of this AppNote is to show how simple aliases are and yet how they can help you as you optimize your network.
With the introduction of NetWare 4.x, there are numerous new concepts that NetWare users need to learn. While learning anything new is looked upon as being a "task," there are also advantages. This is the case with the NetWare Directory Services (NDS) Alias object. By understanding and using the alias object properly, Directory use can be simplified for users.
This AppNote provides a basis for understanding and using the NDS Alias object to simplify different Directory tasks.
Before I begin, I want to define a couple terms:
In this AppNote, when I refer to the Primary object, I am referring to the object that is being pointed to by the alias. For example, a primary object is user object "John".
When I refer to the Alias object, I am referring to the object that points to a primary object. For example, alias object "John Alias" points to primary user object "John".
Although I refer to NetAdmin in this AppNote, NWAdmin (the GUI counterpart of NetAdmin) can also be used to create Alias objects.
Purpose of Alias Objects
Aliases are very powerful tools, if you remember that an alias is simply a method of giving an object more than one name. Usually, unless not dereferencing (explained later), all properties, property values, and access privileges of an alias object are the same as those of the primary object.
Aliases can point to container or leaf objects. They can be in the same container as the primary object, or in any container in which the primary object could legally reside. Primary objects in the directory may have multiple aliases. Alias objects cannot have aliases.
Aliases allow you to create one object in the tree and then allow others to easily access this object by creating alias references to the object. For example, if you have a volume that users in other contexts need to access, you can create an alias of the volume in the other contexts that point to the original volume object.
Example of Using an Alias Object
Let me give an example of the use of an Alias object. Suppose that I usually log in as user Bcutler in the context TextUtil.NPD.Novell. Sometimes, however, I need to log in as the administrator user called Admin. The Admin user is found in the SMS.Backup.NPD.Novell context. Since I don't want to change my context to SMS each time I log in as Admin, I create an Alias object called Admin_Bruce in the TextUtil context that points to the Admin object in the SMS context. Now, without having to change my context, I can log in as both Bcutler and Admin.
Another usage for an alias would be to create an alias of a volume object in all of the contexts where there are users that will be using that specific volume. For example, assume that you have a volume object called System in the TextUtil context that the users in the SMS context also use. Rather than having all of the users in the SMS context map to the System volume in the TextUtil context, we could create an alias object called System Alias in the SMS context that points to the System volume in the TextUtil context. This way all of the users in the SMS context would only have to map to System Alias instead of having to map to .System.TextUtil.NPD.Novell. (See Figure 1).
Figure 1: NDS tree structure including our examples.
Dereferencing vs. Non-dereferencing
Earlier I used the term dereferencing. Let me explain what this term means. The IEEE X.500 specification refers to dereferencing of alias object. Dereferencing simply means to view the properties of the primary object. Non-dereferencing (a double negative, meaning referencing) of alias objects means "to access the properties of the alias object itself."
For NetWare Directory Services (NDS) to know about an alias, it creates an alias object. The whole purpose of this object is to point to another object. Both the primary and alias objects have properties including Access Control Lists (ACLs). When you dereference an alias, you are telling NDS that you want to access the properties of the primary object. When you are not dereferencing, you are telling NDS that you want to access the properties of the Alias object.
In the example above, if we dereference alias Admin_Bruce, we see user Admin's properties. If we don't dereference, we see the properties of the alias Admin_Bruce.
The NetAdmin utility doesn't use the terms dereferencing and non-dereferencing. Instead it has an option called "Show alias class (Y/N)" on the Manage According to Search Pattern screen. If you set this option to "Yes," you have selected non-dereferencing. If you set this option to "No" you have selected dereferencing. (See Figure 2).
Figure 2: Example of dereferencing.
Properties of Alias Objects
Alias objects have their own properties. In addition to the name of the alias object, it has one mandatory property: the primary object name, and one optional property, Access Control List (ACL). The ACL has the Inherited Rights Filter (IRF) and trustee assignments to the object.
Alias objects can be located in the same type of container (Organization, Organizational Unit, Country) as the primary object. For example, an alias of an Organization can only be contained in a Country or Top object. An alias of a Country can only be contained in an object of class Top. An alias of a user object can be contained in an Organization or an Organizational Unit but can't be contained in a Country or Top object.
An alias has the same naming rules as the object to which it points. For example, if the primary object is of type Country the naming attribute is C= and the name can only be 1-2 characters in length. If the primary object is an Organization, the naming attribute is O=. If the primary object is an Organizational Unit, the naming attribute is OU=. If the primary object is a User, the naming attribute is CN=.
Object Rights Associated with Alias Objects
All NDS objects inherit access control privileges (ACL) from their parent container. Since an Alias is simply another name for a primary object, dereferenced alias objects also inherit privileges from the primary object's container. For example, if the container TextUtil has been given rights to volume System, user Bcutler would inherit those rights. Since the alias Admin_Bruce refers to Admin in another context, Admin_Bruce will not inherit rights from the container TextUtil. Just keep in mind that aliases act as though they are the primary object. You get exactly the same rights by logging in as an alias as you would logging in as the primary object.
A metaphor may be useful here. Let's say that I decide that I want to create an alias for myself. I decide that I want to have an alias name of Bill Clinton. By so doing, I am known as both Bruce Cutler and Bill Clinton. Does this change who I am? No. I still can't command the Armed Forces of the United States and I am not married to Hillary. (Good thing, my wife would be just a little upset!) I have just given myself another name. I am still just plain old me. I have no more or less rights even though I have an assumed name. You don't get more or less rights by being an alias than you have by using your original name.
There are occasions when you want to assign trustees of the alias object. The only way you can assign rights to an alias object is to not dereference. If not dereferencing, you can give another object, such as a user, rights to the alias object via an ACL entry. In order to control who has rights to move, rename, or delete an alias, the user must have rights to the alias object itself.
For example, in order to rename, move, or delete Admin_Bruce, I must have rights to the alias Admin_Bruce. I must turn off dereferencing so that I can access the properties of the alias object. Then I can assign trustees of the alias object Admin_Bruce. I can also give Admin_Bruce an IRF as well.
Let's assume that we give Paul the following rights to Admin_Bruce:
Object: Alias object Admin_Bruce (not dereferenced) [Object Rights] [B R ] Browse, Delete Rename,Supervisor
With these rights, Paul can do the following things to the Alias object:
View the name of the alias
Rename the alias to something else, like Admin_Paul
Other General Behaviors
Generally, when viewing alias objects you will see the name of the Alias object (Admin_Bruce) but will be viewing and modifying the properties of the Primary object (Admin). If you modify the object, you are modifying the Primary object. If you add the object as a trustee of a file, directory, or another object, you are adding the Primary object as a trustee. On the other hand, if you move, rename, or delete the object, you are moving, renaming, or deleting the Alias object, not the primary object.
We are currently looking at methods of displaying dereferenced objects so that you will know that you are looking at an object via an Alias. In the meantime, be sure and name your aliases so that you will know that you are accessing an object through an alias. For instance, add the word Alias after the name of the object.
It doesn't make sense to create an alias of an object in the same context. For example, it doesn't make sense to create an alias of user Admin in the same context where Admin resides. It's easier to just select Admin than to create an alias that points to Admin. (See Figure 3).
Figure 3: Example of an alias in the same context.
With the 4.0 release, NDS would allow you to alias a parent container object. With a future release, this will not be permitted. It is therefore recommended that you not alias a container which is a parent of the alias object. For example, if our current context is OU=NPD.OU=Provo.O=Novell, we would not want to create an alias object that points to object OU=Provo. If we do so, we would get a loop of containers. (For an example of this, see Figure 4.)
Figure 4: Example of aliasing a parent container.
Be careful of looping aliases. If you were to point a container alias to a container in another portion of the tree, the possibility exists that you may end up with a loop (see Figure 5).
Figure 5: Another example of "looping" containers.
You may want to avoid aliasing containers for this reason. While Aliases can be used for container objects, they are most useful for leaf objects.
If you rename, move, or delete an alias object it renames, moves, or deletes only the alias object. The primary object is unaffected. The dereferencing option does not affect these functions.
Alias and the Login Utility
Alias objects are affected by the NetWare Login utility in a slightly different manner than regular NDS objects are. This section explains how the Login utility works with Alias objects.
If Login has to search for the user object, it will change the VLM context to the context of the user it finds. If you enter the full name of the objectCwhich means login does not have to search - the VLM context will not be changed. A full name is defined as a name with a dot preceding the name. For example, the following is a full name:
Here is what Login does with alias objects:
Login searches for the object associated with the login name.
a. If the full name is specified, the object will be read without searching. If it is not found, Login will stop with an error message.
b. If a partial name is specified, Login will search the current VLM context for the object.
c. If the object is not found in the current VLM context, Login will search the context of the server specified on the command line. For example, if you enter Login S1/John_Alias, the context of server S1 will be searched for John_Alias.
d. If a server is not specified on the command line, e.g. Login John_Alias, the context of the default server will be searched. The default server is the server associated with the current drive letter. For example if F: was the current drive letter and F: is mapped to S2, server S2's context will be searched.
The login script ofthe alias' container is executed. (This is going to change. The login script of the user's container will be executed.)
Login then proceeds as though you had logged-in as the user.
Be aware of the following:
When logging in as an alias, all object names in the Login Script must be relative to the context of the alias. For example, if you have a map statement of the form
where WP is a directory map, the WP object must be in the alias' context.
The user must have sufficient rights to the alias' container in order to execute the system login script. By default, all containers are given the Read right to their own Login Script. Thus, all subordinate objects inherit the same rights, unless revoked. Sincethe alias points to a user object in a different context, the user will not automatically inherit these Read rights.
This procedure is being simplified for a future release of NetWare 4.x. In this future release, Step 2 will change to the following:
The Alias will be dereferenced to locate the primary object. Login will then proceed to log you in as though you had manually changed your context, using CX, and then logged in as the user.
When this process changes, the things you need to be aware of above will no longer apply.
NDS Object Specifics
Here are some things to consider when creating aliases of the following types of objects:
Since an alias ofa country can only exist in the root, itdoesn't make sense to have an alias of a Countrybecause it would be in the same context.
It is recommended that you create aliases for NetWare servers ratherthan creating duplicate NetWare server objects.Plus, you can't create another 4.x NetWareserver object if the server is already inthe tree. Creating an alias is the only wayto place a NetWare 4.x NCP server in anothercontext.
An alias of anOrganization can only be located in the rootor in a Country container.
Do not create analias that points to an Organizational Unitin the same or parent context. This createsa loop when browsing the tree that could causethe NetAdmin utility to run out of memory.Likewise, be careful that you do not get ina loop of aliases that point to containersthat eventually point back to aliases.
Print Queueand Printer
The containerof a Print Queue is given rights to the PrintQueue object by being added as a Queue User.This allows all users in the context to accessthe queue. If there is an alias object inthat context, the primary object to whichthe alias refers does not inherit rights tothe queue. This also applies to Printers.
Since thereis only one object of type Top allowed, youcannot create an alias that points to an objectof type Top.
If you haveusers who periodically visit other officesand need access to the resources at theseother offices, such as print queues and printers,you should consider setting up OrganizationalRole objects and making the users Role Occupants.
In each remote office,you could have an OrganizationalRole object which has those users that needaccess to local resources as Role Occupants.When a user travels to the remote office,he would log in with his regular user name.Since he has logged in as he usually does,he has rights to resources in the main office.Because he is a Role Occupant of the OrganizationalRole object at the remote site, he also hasrights to the remote resources.
For example, assume user Bill normally works in marketing in the Provo office but frequently travelsto the San Jose office. Bill has a user object inthe Marketing.Provo context. He isalso a Role Occupant object of theSan Jose role occupant. The San Jose Organizational Role has rights to the local printers, print queues,etc. Therefore, Bill has rights to accessthe remote resources as well.
One additional thing you might want to do for Bill: create an Alias in the San Jose context that pointsto Bill's user in the Marketing.Provo context.
Do not createmultiple volume objects for the same physicalvolume. Always use aliases to refer to volumesalready in the tree.
Now that you have an understanding of NDS Alias objects you should be able to more effectively use your Directory. Remember that Alias objects allow quick access to the primary object. Whenever you access an object through an alias, it is as though you had typed the full name of the primary object. Aliases are simple, but effective typing shortcuts.
* Originally published in Novell AppNotes
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.