Novell is now a part of Micro Focus

Increasing Global Control with "Virtual" Login Scripts

Articles and Tips: tip

Paul Oppenheim
Open Networks Inc.
Portland, Maine USA

01 Jul 1996

NDS simplifies network administration through the hierarchical nesting of containers, and NDS and file system rights flow down the tree. If used, this flow-down method permits administrators to make global trustee assignments -- and modifications -- at higher NDS levels, and a reduced number of assignments at lower levels.

Unfortunately, the same is not true for login scripts. Users execute the login script for their immediate container; they don't inherit scripts from successive containers up the tree. As container objects increase both in their numbers and in the depth of their hierarchical nesting, global control over the login process becomes more difficult. Making a system-wide modification can potentially mean editing as many login scripts as there are NDS containers.

This NetNote presents a way to coax the NDS hierarchy into helping overcome this problem by creating what might be called virtual system-wide login scripts.

First, though, it's worth reminding ourselves that in the bindery-based world of pre-NDS NetWare, the system login script is the administrator's main point of global control. But since each 3x server has its own bindery, the server level is about as global as it gets.

By contrast, NetWare Directory Services container login scripts take on the role of initializing the environment for all immediately subordinate user objects. The set of user accounts initialized by a given container login script isn't drawn along server lines for the simple reason that NetWare 4x user accounts don't reside in server-based binderies, but in the distributed, replicated NDS database.

Using the NDS Hierarchy for Login Scripts

Now, suppose your NDS structure is a hybrid, combining geographical and organizational functions. Suppose also that user objects reside not only in the lowest NDS level (that is, the level furthest from the root), but are scattered through different levels of the NDS hierarchy. For example, branch or location administrative users may reside in the container that holds all other containers for the given location.

Let's say there are three tiers to the NDS structure; we'll call them 1, 2, and 3 (1 being the highest and 3 being the lowest, or furthest from the root). Most users reside at tier 3, a fewer number at tier 2, and still fewer at tier 1. The trick to our method is to systematically add INCLUDE statements to the login script of every container in the tree.

All tier 3 container login scripts would start with:


All tier 2 container login scripts would start with:


And all tier 1 container login scripts would start with:


Place tiern shared initialization elements in the tiern.log file. Place shared elements for successive NDS levels up the tree in their respective files. Those are the basic rules to follow.

Such a scheme enables you to alter the login process for all users residing at a given tier by modifying the tiern.log file. If you're thinking of doing this on a really large network, pay attention to bandwidth and WAN issues. For example, since WAN bandwidth should not be consumed every time a user logs in, you may want to replicate your tiern.log files to a few geographically strategic locations. This replication can be easily done with a simple batch file.

You should also consider using directory map objects rather than hard-coding the location of tiern.log files. By experimenting, you'll undoubtedly come up with better solutions than the one presented here. Above all keep an open mind: NDS is a tool for you to control, rather than the other way around.

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

© Micro Focus