Chapter 7

Through Novell Directory Services, NetWare 5 offers a single login to the network. That single login enables authentication for access to any NetWare 5 server, printers, and other network resources. In environments with multiple resources, or with end users that require transparent access to resources, the administrator needs to be able to automate how users attach to resources.

Login scripts can be used to:

• Attach to resources such as network drives and printers
• Set workstation environment variables
• Display messages
• Execute applications

Several types of login scripts can execute when logging in to Novell Directory Services. There is an order to the execution, which makes the login scripts a scalable tool that can be used in global enterprise networks. The login script order is:

1. Container script that contains the User object (if it exists)
2. Profile script (if it exists)
3. User script (if it exists) OR default script (if user script does not exist)

Login scripts are generally located within Novell Directory Services as properties of objects. The only exception to this rule is the default login script, which has historically been compiled within the login executable of the workstation client.

The container script is a property of the container object. Both the Organization and the Organizational Unit objects have a login script property. These are all container scripts.

A container script executes for a user who is a child object of that container object. For example, in the NDS tree in Figure 7-1, the user TMeyer is a child of the ACCT container. As such, TMeyer executes the login script property of the ACCT container. In contrast, user Jsansoterra is a child of the ENG container and executes the login script property of the ENG container.

In order to access the Container Script property, in NetWare Administrator, browse through the NDS tree until the target container is located. Right-click the container and select Details from the pop-up menu. In the resulting dialog box (see Figure 7-2), click the Login Script button. If the container does not have a login script, this window will be blank.

Administrators typically use the Profile object for special-purpose login scripts, such as location-specific scripts or even a global script. The profile script can be used to set environment variables, map drives, and execute commands for multiple end users. The profile script is a property of the Profile object.

A location-specific script is useful for grouping users based on their physical location in the enterprise. When designing printing services and access to printer resources, the profile script enables users to run the printer captures through a login script that is based on the printers closest to them (see Figure 7-3). This is preferable to a script that is run based on a business unit affiliation, or organizational unit membership.

The profile script also allows an administrator to create a script that can be used by several users in any context of the tree. Whenever a change is needed, the profile script needs to be changed only once. In contrast, if an administrator has created identical user scripts instead of a profile script, each user script must be edited if change is required.

A profile script is assigned to a user through the User object’s login script property page.

1. If drive F: is not mapped to volume SYS, then right-click the Network Neighborhood icon, select Novell Map Network Drive, select drive F: under Device, and type \\SERVERNAME\SYS in the Path area; then click Map.
2. Choose Start | Run, type F:\PUBLIC\WIN32\NWADMN32, and press ENTER.
3. Navigate through the tree until the User object is located.
4. Double-click the User object.
5. Click the Login Script property page button.
6. Click the button to the right of the Profile Script box.
7. Navigate through the NDS tree until the Profile object is selected.
8. Click OK.
9. Click OK to close the User object details and save the changes made (see Figure 7-4).

A user login script is a property of the User object in Novell Directory Services (see Figure 7-5). It executes for the individual User object, and never for any other user.

When designing an enterprise network login system, most network designers choose not to include user login scripts because they are difficult to maintain for a growing network. Network resources can be added, moved, or changed. Changes in network resources directly affect how a script is designed. For example, if a database application is added to the network that requires an environment variable to be set for each user accessing the application, a line would have to be added to each individual’s login script. The larger the number of users that access the application, the more scripts to be changed. In contrast, if using a container or profile script, the line would have to be added only once, to a single script.

Each user is given access to his or her own user login script property, as shown in Figure 7-6. The default property rights for the user's own login script property in Novell Directory Services are Read and Write. This enables the user to write his or her own login script.

The default login script is compiled as part of the login executable. It provides the minimal resource access a user might need when connecting and logging in to the network. Because the default login script is compiled, there is no way to change the script commands. The following is the list of commands that are in the default login script:

MAP DISPLAY OFF
MAP ERRORS OFF
REM Set 1st drive to most appropriate directory
MAP *1:=SYS
MAP *1:=SYS:%LOGIN_NAME
IF "%1"="SUPERVISOR" THEN MAP *1:=SYS:SYSTEM
MAP S1:=SYS:PUBLIC
MAP S2:=S1:%MACHINE\%OS\%OS_VERSION
MAP DISPLAY ON
MAP

If there is no user login script, the default login script runs. Because a network designer might not want the default login script to run, there is a way to stop it. This is accomplished by placing the statement NO_DEFAULT in either the container login script or the profile login script that the users run prior to the default script.

NetWare includes many login identifier variables for customizing a login script. Administrators use the login identifier variables in order to use a standard login script for multiple users. This system is both a flexible and efficient. Table 7-1 defines the login identifier variables and their uses.

Note that many of the login variables are actually NDS properties of the User object. Property values of NDS objects can be used as variables in login scripts. However, not all properties are supported. They can be used the same as any login identifier variable. When the schema is extended to include additional properties, this capability makes NetWare scripting flexible. If a network administrator wants to use an NDS property as a login variable but it contains a space in the property name, the administrator simply encloses the property name in quotation marks or replaces the spaces with underscores.

NetWare login scripting supports commands that can be used on a command line. One of the most common is MAP, which is used to connect network drives. The login script actually uses an internal version of MAP. When used in a login script, the MAP command is used the same way as it is on the command line.

In a login script, the command for mapping a root drive is:

MAP R G:=SERVER\VOLUME:DIR\SUBDIR

In a login script, the command for mapping a search drive is:

MAP INS S16:=SERVER\VOLUME:DIR

In a login script, the command for mapping a standard drive is:

MAP J:=SERVER\VOLUME:DIR

There are two MAP commands that work in a login script that do not work on the command line. These are:

MAP DISPLAY OFF or MAP DISPLAY ON
MAP ERRORS OFF or MAP ERRORS ON

The MAP DISPLAY ON/OFF toggles whether the user will see drive mapping during the login script execution. The MAP ERRORS ON/OFF toggles whether the user will see the drive map errors during the login script execution. Neither of these script commands works on the command line.

The FIRE PHASERS command works only in a login script. When using this command, the computer will issue a beeping sound. Up to nine sounds can be executed by adding a number between 1 and 9 after the FIRE PHASERS command. So, for a login script to promote seven beeps, the command would be FIRE PHASERS 7.

In order to run an external, or DOS, command from a login script, the command must be preceded by a pound sign (#).To change the current context from within the login script, use the CONTEXT command. To set the user to the NY Organizational Unit in the MA Organization, the command is CONTEXT .NY.MA. The WRITE command is used to display a single text line during the login script execution. To display the word Hello, the command is WRITE "Hello". The DISPLAY and FDISPLAY commands will show a text file during login script execution. The difference between DISPLAY and FDISPLAY is:

• DISPLAY shows a text file in raw format.
• FDISPLAY filters out codes such as unprintable characters and printer codes and displays the remaining text of the file.

To show a tip of the day text file, the administrator can add the command DISPLAY SERVER\SYS:PUBLIC\TIP.TXT to the login script. A REM, REMARK, a semi-colon (;), or an asterisk (*) can all be used as comment indicators. The text following these will be ignored. This is helpful if an administrator wants to temporarily stop using a login script command, but enable it later.

The logic that a login script uses is embodied in the IF, THEN, ELSE command set. This set will execute a command based on a condition. The syntax is:

IF <condition> THEN <command> [ELSE] <command> END

The ELSE is optional. For example, if the admin user wants a MAP command to run for the SVC group or a different MAP command for everyone else, the condition is MEMBER OF SVC; the command is MAP drive letter = SERVER\VOLUME:GROUP\SVC; and the ELSE command is MAP drive letter = SERVER\VOLUME:GROUP\ALL, which creates the following:

IF MEMBER OF SVC THEN
MAP G:=SERVER\VOLUME:GROUP\SVC
ELSE
MAP G:=SERVER\VOLUME:GROUP\ALL
END

One way to scale a login script process across an enterprise is to design login scripts to include the scripts within other containers (see Figure 7-7). This is done with an INCLUDE command. The idea is to create a series of login scripts that start at the user’s container and lead up the tree to the organization container script. This way, any commands that must be run for every user in the network can be placed in the organization container script. The INCLUDE command can extend to text files that are written with the standard login script structure. For example, adding the line INCLUDE SYS:PUBLIC\SCRIPTS\SAMPLE.TXT to a container script will run those script commands before moving to the next script, which would be a profile script if it exists.

Container objects provide the most common and manageable venue for login scripts. If the NDS tree is designed according to Novell’s recommended method, User objects will be naturally grouped according to resource proximity and usage. Also, there are typically fewer containers than User objects; therefore, login script management and administration are simpler than managing a multitude of user login scripts.

However, don’t forget that container login scripts aren’t inherited by users in subordinate organizational objects. In order to use a container login script, the User object must have that container as its immediate parent object, and cannot use the container login script of the container that the user’s parent container is in. The Read Selected Property Right to the container object’s Login Script Property is not inherited by a subordinate container object’s users.

Example: If O=Chicago has a cContainer login sScript and one of the commands is NO_DEFAULT,

And if OU=Downtown.O=Chicago has a container login script with NO_DEFAULT as one of its commands,

But OU=Naperville.O=Chicago does not have a container login script and there are no user login scripts and no profile login scripts assigned to any user,

Then, when CN=Mark.OU=Naperville.O=Chicago logs in, Mark does not run any container login scripts. Instead, Mark uses the default login script.

—By Dan Cheung, CNI, MCNE, MCT

All login scripts use the same scripting language, which makes it easy to transfer the contents of a profile script to a container script, for example. This is important to remember. When testing a login script, it is in the administrator’s best interest not to create a new login script, nor to add new login script commands, to the login script property of an organizational unit. This avoids two things:

• Users accidentally running the unproven login script
• Bad logic causing the login script to lock users out of the network

The best practice to use when creating and debugging a login script is to create the script in a Profile object, and assign that object to a test User object. If the administrator wants to skip the container object script, the administrator can do either of the following:

• Place the test User object in a test container object that does not have a login script, or
• Add the statements:

Even though you are skipping the container script in order to test the profile script, the new script should always be tested with any other scripts that will be executed. If the new script will be a user script, a good practice is to copy it to the user login script property of a test user in the same context as the user that will eventually use it. If the new script will be a profile script, it should be tested with the container script and user or default login scripts, if any are used. If the new script will be a container script, it should be tested with the profile, user, or default login scripts, if any of them are used.

GUI login utility script variables are available to use with a login script. Older versions of NetWare assumed that a DOS client would be used, with a text-based login script. This enabled the user to execute the login command from a prompt and follow it with variables, such as LOGIN BLDG1 FLOOR3. The login script would interpret the BLDG1 and FLOOR3 expressions as the %2 and %3 variables, respectively, in the script. Then, assuming that the script was set up to capture printers and map drives based on the building and floor, these variables would set that user’s location environment accordingly.

DOS clients are becoming more rare. Most network clients, such as Microsoft Windows 95/98 or Microsoft Windows NT 4, utilize a GUI login The difficulty with the GUI login utility is that the login command is not invoked at the command line. In order to use variables, the login script utility requires a place to put them. It is prompted from the Variables button on the Script tab of the login utility, shown in Figure 7-10.

As seen in Exercise 7-2, the execution of an external DOS command from a GUI login utility will bring up a DOS window. If multiple external DOS commands must be executed, they will each bring up their own DOS window. In order to execute multiple external DOS commands in a single window, the administrator must create a batch file and execute the batch file from the login script.

When the FIRE PHASERS command executes for the GUI login utility, it does not execute the machine beep. Instead, it executes a PHASERS.WAV file. If another sound file is desired, the PHASERS.WAV file should be replaced on the network client workstation.

There are four types of login scripts: container scripts, profile scripts, user scripts, and the default login script. The container script of the user’s parent container executes first if it exists; the profile script executes next, if it exists; the user login script executes next if it exists,; and, finally, if there is no user script, the default login script executes. The administrator can disable the default login script by using the NO_DEFAULT statement in a container or profile script that executes before the default login script normally would execute.

The container script is written within the login script property of a container, either an organization or an organizational unit. The profile script is written within the login script property of a Profile object. A profile script is assigned to a user in the Profile Script property of the Login Script property page of a User object. The user login script is on that same property page. The default login script is compiled within the login executable.

Login scripts use several variables, and can even utilize some NDS properties in order to make the scripts flexible and efficient. The login scripting language uses a few commands, and can execute external DOS commands by using the pound sign (#) in front of the command within the script.

Using the INCLUDE statement, a login script system can be designed for an enterprise network. The INCLUDE statement will run another container object’s login script, effectively cascading from one to another.

It is best to take care in creating new login scripts. If possible, use a test user and a profile script so that other users are not affected by the new commands. The PAUSE command is useful for stopping the login script between new commands in order to view the errors that may be occurring.

The GUI login utility executes login scripts within a window, which is very different from the way a text-based DOS client might execute a login script. Aside from DOS commands executing external DOS windows, the GUI login utility uses a different way of executing login script variables.

• NetWare 5 offers a single login to the network through Novell Directory Services. This single login enables authentication for access to any NetWare 5 server, printers, and other network resources. In environments with multiple resources, or with end users that require transparent access to resources, the administrator needs to be able to automate how users attach to resources.
• Login scripts can be used to attach to network resources, set workstation environment variables, display messages, and execute applications
• Several types of login scripts can execute when logging in to Novell Directory Services. The login script order of execution is: 1. Container script that contains the User object (if it exists), 2. Profile script (if it exists), and 3. User script (if it exists) OR default script (if user script does not exist).
• The container script is a property of the container object. Both the Organization and the Organizational Unit objects have a login script property. These are all container scripts. A container script executes for a user who is a child object of that container object.
• The profile script can be used to set environment variables, map drives, and execute commands for multiple end users. The profile script is a property of the Profile object. A location-specific script is useful for grouping users based on their physical location in the enterprise.
• The profile script also allows an administrator to create a script that can be used by several users in any context of the tree. Whenever a change is needed, the profile script needs to be changed only once.
• A user login script is a property of the User object in Novell Directory Services. It executes for the individual User object, and never for any other user.
• When designing an enterprise network login system, most network designers choose not to include user login scripts because they are difficult to maintain for a growing network Each user is given access to his or her own user login script property. The default property rights for the user's own login script property in Novell Directory Services are Read and Write.
• NetWare includes many login identifier variables for customizing a login script. Administrators use the login identifier variables in order to use a standard login script for multiple users. Property values of NDS objects can be used as variables in login scripts. However, not all properties are supported.
• NetWare login scripting supports commands that can be used on a command line. One of the most common is MAP, which is used to connect network drives. The login script actually uses an internal version of MAP.
• One way to scale a login script process across an enterprise is to design login scripts to include the scripts within other containers. This is done with an INCLUDE command. The idea is to create a series of login scripts that start at the user’s container and lead up the tree to the organization container script. This way, any commands that must be run for every user in the network can be placed in the organization container script.
• All login scripts use the same scripting language, which makes it easy to transfer the contents of a profile script to a container script, for example. This is important to remember. When testing a login script, it is in the administrator’s best interest not to create a new login script, nor to add new login script commands, to the login script property of an organizational unit. The best practice to use when creating and debugging a login script is to create the script in a Profile object, and assign that object to a test User object.
• GUI login utility script variables are available to use with a login script. Older versions of NetWare assumed that a DOS client would be used, with a text-based login script. This enabled the user to execute the login command from a prompt and follow it with variables.
• Most network clients, such as Microsoft Windows 95/98 or Microsoft Windows NT 4, utilize a GUI login The difficulty with the GUI login utility is that the login command is not invoked at the command line. In order to use variables, the login script utility requires a place to put them. It is prompted from the Variables button on the Script tab of the login utility.