Novell Home

Renaming Containers

Novell Cool Solutions: Feature
By Jim Henderson

Digg This - Slashdot This

Posted: 17 Aug 2005

In this article, we will examine a quick and easy way to rename containers and update the relevant information on Windows workstation clients using a login script.


The reorganization of an eDirectory tree can become necessary in situations as varied as unanticipated growth, site relocation or consolidation, or a merger or acquisition.

When dealing with a small number of users - where the impact is usually the most obvious - such reorganizations can be handled fairly easily; when hundreds or thousands of users are affected, tree restructuring can become a major operation.


Guidelines have been provided in many places concerning the use of aliases. Aliases are objects that point from one location in a tree to another; they are structural elements of an eDirectory tree, but the objects themselves are very simple. Apart from the inherited attribute definitions from the Top class, aliases contain only two attributes: the name of the alias object itself, and the object at which the alias is pointing.

Some customers use aliases rather excessively in their environments. Some create hierarchical trees and then create a single container in which to place aliases to all user objects in order to provide a sort of "poor-man's" contextless login functionality. This is not the intended purpose of the object class; such use can be demonstrated to require more administrative effort to maintain.

An appropriate use for aliases is in the management of tree restructuring. This is a temporary use, in which the alias is retained long enough to ensure that the default context setting in Client32 has been reset on all workstations affected by the restructuring of the tree.

When logging in with a user DN containing an alias, the login script variable %LOGIN_ALIAS_CONTEXT is set to a value of "Y". Any logic such as updating registry entries or logging the authentication to a text file using an external program (for purposes of determining when the alias can be deleted) can be performed by including the following test in the login script:

   REM Add your commands here

This block will execute when the user uses the alias object as part of their login name.

For example, if the tree structure looks like this:

then you can rename the FlightOps container to Operations, rename the FlightOps container and create an alias so the tree looks like this:

The user appears in both places, but the FlightOps container is actually a leaf object (i.e., it has no subordinates) that points to the Operations container. Deleting the JHenderson user from within either containers deletes it from both containers, because there is only one object.

If the user logs in as JHenderson.FlightOps.SLC.DA, the value returned by
is set to Y, because part of this distinguished name is an object with an object class of Alias.

If the user logs in as JHenderson.Operations.SLC.DA, the value returned by
is set to N, because the real container is used.

In testing with Client32 version 4.90 SP1a, an interesting behavior can be observed when logging in through an aliased container - the client will automatically populate the context associated with the tree with the new container name. This particular behavior means that the client should only hit the alias test in the login script once. If a means to write the user name to a file during the login process is available, a log of all users who have logged in and had their client reconfigured can be easily obtained. When all of the affected users have been moved, it is safe to remove the alias object from the tree.

WARNING: It is very important to delete only the alias object; do not delete anything that appears to be subordinate to the alias object. Those are real objects, and if deleted from under the alias, the real objects themselves will be deleted!

Bear in mind that the change made automatically in the client configuration does not change settings in the location profile or other places in the registry. It will be necessary to verify where in the environment the login context is stored, and import registry updates using the IF block in the login script. It may also be necessary to change attribute values such as license object owners. Most object references are handled using the entry ID (EID) of the object rather than the object's distinguished name; the change in tree structure will not affect those references.

Also keep in mind that eDirectory's use of entry IDs - rather than object names - for referencing objects means that the actual distinguished name of the object is irrelevant for object relationships such as group memberships or host server attributes. The change in DN does affect things such as Apache configuration files, in which a DN might be specified for a search base. Always test in the lab before implementing restructuring changes in the tree. Verify all configuration files and applications that might be affected by such a change before removing the alias object. For LDAP-based applications, change the "Dereference Aliases" setting on the LDAP server object to "Default" to have aliases dereferenced so that LDAP applications are unaffected by the use of the alias.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© 2014 Novell