To manage user connectivity within NetWare 6, you must first understand the two types of connections that NetWare 6 servers use: bindery services connections and eDirectory connections.

Bindery services connections are server-based, meaning that as users attempt to connect to multiple servers, they must enter a user ID and password at each server. This primitive connection type is required for access to NetWare 3.x servers and older client versions that require a bindery connection.

Setting the Bindery context in the Novell Client allows NetWare 6 to emulate a bindery so that older versions of the client can be used to connect to the server. The Bindery context is the location in the eDirectory tree where the user account exists.

eDirectory connections enable users to log in once and automatically connect to additional servers through login script drive mappings. The benefit is that you need to manage only a single user account for all eDirectory resources throughout the network. The trick is that eDirectory connections require the new 32-bit Novell Client provided in NetWare 6.

The single sign-on capability of eDirectory works because RSA encryption is established between NetWare 6 servers and 32-bit workstations. RSA is an Internet encryption and authentication system that uses sophisticated algorithms for network security. All servers must be running NetWare 6 for the background authentication process to run and establish connections to multiple NetWare 6 servers.

Three types of eDirectory connections are provided by the Novell Client:

Among other things, login scripts in NetWare 6 can be used to establish environment variables for users’ access to eDirectory resources. Some of the resources that users might need access to include mappings to network drives, mappings to applications, and captures to printers and print queues.

In eDirectory, a login script is a property of an eDirectory object and is accessible only through an eDirectory connection. Only Container objects, Profile objects, and User objects have a login script property. Users needing the same network resources are typically grouped together in the same eDirectory container. This management strategy creates a natural group in which all resources can be deployed through the use of a single Container script.

Here’s how it works. After a user has entered a valid ID and password, the Novell Client checks the Container login script for the container where the user object resides. If there is a Container login script, the client executes the script to establish the appropriate network environment variables. You can establish Profile login scripts and/or specific User login scripts to provide further additional customization. Creating and maintaining Container login scripts is the most common and efficient method for supplying access to network resources.

When managing client connectivity, you must identify the needs of the following three user types:

You should identify the populations of these users in your organization and document their needs. Let’s take a closer look.

Novell offers client software for various workstation operating systems, including Windows 95/98/Me, Windows NT/2000/XP, Windows 3.x, DOS, Macintosh, Unix, and OS/2. In this lesson, we’ll concentrate on Novell Client architecture for Windows 95/98/Me and Windows NT/2000/XP.

Novell Client architecture consists of four client technologies organized into two functional categories: hardware (network interface card, or NIC) and software (workstation operating system, or WOS). See Figure 4.1.

FIGURE 4.1 The detailed Novell Client architecture.

Workstation hardware encompasses the first two client technologies: LAN drivers and communications protocols. It is responsible for physically connecting the workstation to the network and providing a communications path to the server. It is not responsible for the content of the data, how the data is used on the workstation, or guaranteeing network privileges for access to any program or resource on the LAN (these are the responsibilities of the workstation software).

Workstation software encompasses the final two client technologies: the Novell Client Requester and WOS interface. The primary responsibilities of the workstation software are to create the content sent to and from the network, format the data so that network resources can understand it, help ensure that only authorized users access the network, and control the flow of data within the workstation.

See Table 4.1 for an overview of Windows 95/98 and Windows NT/2000/XP Novell Client architecture.

TABLE 4.1 Windows 95/98 and Windows NT/2000/XP Novell Client Architecture Overview

In this lesson, we’ll review the four client technologies that make up both the Novell Client for Windows 95/98 and the Novell Client for Windows NT/2000/XP. The following is a preview of the four components presented in Figure 4.1:

Let’s start at the bottom with LAN drivers.

LAN Drivers

As you saw in Figure 4.1, the LAN driver sits near the bottom of the Novell Client architecture. Each physical NIC has its own specific LAN driver. The LAN driver accepts any type of packet, and then either sends the packet up to the communications protocol or down to the network cabling. The LAN driver is supported by a secondary interface called the Link Support Layer (LSL), which acts as a switchboard for routing packets between the LAN driver and the appropriate communications protocol. The LSL identifies the packet and then passes it to the appropriate protocol. Together, the LAN driver and LSL handle all physical workstation communications.

Both the Novell Client for Windows 95/98 and the Novell Client for Windows NT/2000/XP support two different types of LAN drivers (see Figure 4.2):

   Network Driver Interface Specification (NDIS)—This is an internal interface, found in Windows 95/98, that consists of a native Windows 95/98 driver and the VMLID.NLM support file.

   Open Data Link Interface (ODI)—This is Novell’s own LAN driver standard. Both the Novell Client for Windows 95/98 and the Novell Client for Windows NT/2000/XP support the use of 32-bit ODI LAN drivers through the ODI NDIS support module (called ODINSUP). This enables you to access Microsoft networks using native Novell LAN drivers.

FIGURE 4.2 Novell Client LAN driver architecture.

Table 4.2 shows the components that are installed during a typical installation and the choices you have during a custom installation.

TABLE 4.2 Components to Install

Communication protocols are the common language of the network. The Novell Client for Windows 95/98 and the Novell Client for Windows NT/2000/XP support both TCP/IP and IPX protocols. TCP/IP is the protocol of the Internet, whereas IPX supports previous versions of NetWare. For the most part, IPX support is provided solely by the Novell Client, whereas Windows itself helps establish TCP/IP communications.

As a network administrator, you must decide which protocol to use on each workstation. Many organizations enable both the TCP/IP and IPX protocols on workstations to ensure network compatibility. This allows each workstation to connect to previous versions of NetWare, the Internet, and/or NetWare 6 networks utilizing IP only.

As you can see in Figure 4.3, the following four options are available in the Protocol Preference configuration screen: IP Only, IP with IPX Compatibility, IP and IPX, and IPX. The default for a new installation is IP and IPX.

FIGURE 4.3 Selecting protocol(s) during a custom Novell Client installation.

Authentication is the process of identifying an individual when he requests access to the network. This is accomplished when a user enters his username and password in the NetWare 6 GUI Login screen.

The Login Authenticator configuration screen shown in Figure 4.4 provides two authentication options: NDS (NetWare 4.x or later) and Bindery (NetWare 3.x). If you want to log in to eDirectory to access services such as printers and servers that are available on that tree, select NDS. The bindery is a nonhierarchical network database that contains definitions of network objects and is used by NetWare versions older than NetWare 4.0. To log in to one of these versions (NetWare 3.x), select Bindery.

FIGURE 4.4 Specifying an NDS connection during a custom Novell Client installation.

During a typical installation, or if you selected Novell Workstation Manager during a custom installation, you’ll be prompted to enter the tree name in the Tree field of the Workstation Manager window.

Near the end of the custom Novell Client installation procedure, the Optional Components screen provides a myriad of optional client components. The specific components available depend on which NetWare 6 client is being installed. For example, Figure 4.5 illustrates the optional components that are supported by the Novell Client for Windows 95/98.

FIGURE 4.5 Selecting optional components during a custom Novell Client installation.

After you select Finish, all the necessary files are copied and the components are installed. You must reboot the workstation for the changes to take effect.

You must make sure that the Novell Client is configured correctly for your network. This involves ensuring that you have selected the correct network protocols. Configuring protocols incorrectly results in the workstation not being able to correctly connect to the network, so this is important.

For Windows 95/98 and Windows NT, right-click Network Neighborhood and select Properties. After you’ve selected the protocol you want to configure, select Properties.

For Windows 2000/XP and XP, right-click My Network Places and select Properties. Right-click Local Area Connection and then, after you’ve selected the protocol you want to configure, select Properties.

In some scenarios, your network will use DHCP to assign IP addresses automatically. If this fits your bill, select the IP Address tab and check the Obtain IP Address Automatically option.

If your network uses static IP addresses, select Specify an Address and then enter a valid IP address.

To make these changes take effect, select OK.

After you’ve installed the Novell Client, there’s only one task left: logging in. But not so fast. Before we tackle client connectivity management, let’s explore another client installation procedure: Automatic Client Upgrade (ACU). That has a nice ring to it.

For ACU to work properly, the newest Novell Client files must be stored on a centrally available file server. Select a directory on a server that all network users can access, such as SYS:/PUBLIC. Make sure that you select a location on a server to which you have Supervisor rights so that you can copy files to the directory.

In your central directory, create a subdirectory structure to organize Client files by version and operating system. For example, you should start with SYS:/PUBLIC/CLIENT483 for the Novell Client Version 4.83. Then create a series of subdirectories underneath named
SYS:/PUBLIC/CLIENT483/WIN2K (for Windows 2000),
SYS:/PUBLIC/CLIENT483/WINNT (for Windows NT), and
SYS:/PUBLIC/CLIENT483/WINXP (for Windows XP).

After you’ve created a central client directory structure, you must make sure to copy the correct files into their appropriate subdirectories. To do so, you can either download client files from Novell’s Web site or copy files from the Novell Client CD. Also periodically check http://support.novell.com for any patch files for the client version you’re upgrading.

In each operating system subdirectory, copy the following files:

ACU.INI determines how the client installation utility should run. If the default settings in ACU.INI satisfy your needs, you don’t need to modify this configuration file. Unfortunately, this is rarely the case. See Table 4.3 for a description of the default ACU.INI configuration options.

TABLE 4.3 ACU.INI Configuration Options

You can use the Novell Client Install Manager (NCIMAN.EXE) to modify ACU.INI. This utility is included on Novell Client CD.

If you want to use ACU.EXE to customize the Client installation based on workstation platform, you can use a platform–specific configuration file. This file can be created using NCIMAN.EXE and placed in the platform–specific subdirectory.

If you intend to use platform–specific configuration files, you must change the UNATTENDFILE option in the main ACU.INI file to Yes. On the other hand, if you prefer to install the client with the ACU.INI default settings for all platforms, you can use a central configuration file.

After you’ve prepared the central server directory and ACU configuration files, it’s time for the main event. In step 5, you’ll create a custom set of instructions within the Container login script for each platform–specific ACU file. For example, if Windows 2000, Windows 98, and Windows XP workstations need an upgrade, you add two instances of the ACU.EXE command to the central Container login script.

Although you might have three different windows workstation platforms on the network, you have to include only two upgrade instructions because each Novell Client provides the files needed for multiple, similar Windows platforms. Also, you should always add the ACU instructions at the end of the Container login script. This allows other login script commands to execute before the ACU, ensuring that processes started at the beginning of the script aren’t interrupted and possibly cause some network traffic problems.

The following script provides an example of the ACU instructions you’ll need to add to the end of ACME’s Container login script:

I highly recommend that you use ACU on your network. Not only does it save valuable time, but ACU ensures that all your distributed workstations are running the latest Novell Client software. Now let’s shift gears a bit and explore some other Novell Client management tricks.

As a network administrator, you’ve already accomplished the hard part: automating the workstation connection. Now it’s the user’s turn. The good news is that both the Novell Client for Windows 95/98 and the Novell Client for Windows NT/2000/XP provide a friendly GUI login utility for users. As you can see in Figure 4.7, the Novell Login window provides simple Username and Password input boxes within the native Windows environment. The good news is that NetWare 6 supports a single login for access to all authorized network resources. In other words, after the user has logged in, she is granted automatic access to all authorized resources in the eDirectory tree.

FIGURE 4.7 Novell Login window.

To log in to a NetWare 6 tree, the user must have either the Novell Client or NFAP software installed. The user must also have a live connection to the network, including a functioning NIC and a correctly configured protocol stack. Finally, the user must have a valid username and password. The username (also known as a login ID) is the same as the user’s User object name. eDirectory also requires a valid eDirectory context so that it can differentiate between users with similar names.

So, how do you get access to the NetWare 6 GUI Novell Login window on a Windows 95/98 or Windows NT/2000/XP workstation? Good question. NetWare 6 offers numerous choices:

Here are a few important things to remember about the NetWare login process: Login is mandatory; login is primarily a security issue; eDirectory provides a single point of login to all authorized network services in an eDirectory tree (that is, after a user has been authenticated, he should not have to enter a login name or password again).

Here are a few other things to remember:

As you can see in Figure 4.7, the Novell Login window contains an Advanced button for login script and eDirectory configuration. This enables you to configure two important types of login information:

NetWare 6 supports a drive pointer system called drive mapping. Drive mapping is a built-in file system management scheme that enables you and users to assign drive letters to network directories. Physical local devices are typically referenced using characters at the beginning of the alphabet (such as A: through E:). In NetWare, logical network directories are typically referenced using characters in the remainder of the alphabet (such as F: through Z:).

Network drive mappings can be managed from the Novell Client using the Novell Map Network Drive option within the N menu. You can also use the Mapped Drive window to map additional drives, disconnect mapped drives, and establish search drives for users. This can be helpful in supplying a temporary solution to connectivity problems until you can correct them through the user’s Container login script. Remember that it’s much more efficient to establish drive mappings in login scripts than to visit each individual workstation.

In Windows NT/2000/XP, all drive mappings created by the Novell Client are root-mapped. Because of this, programs cannot access directories above the root drive. If necessary, you can turn this off by adding the following statement to the top of the Container login script:

The Novell Client also includes a primitive broadcast messaging system. Using the N menu, you can broadcast messages to specific users or the system console. Keep in mind that you can send a message to the system console only if you’ve authenticated directly to its host server with Supervisor rights.

Using the Send Message feature enables you to make contact with users when the phone system or email is down. This facility also helps you broadcast server maintenance or status messages to everyone on the network.

The Novell Client Send Message feature resembles an instant messaging system. When users reply to your message, you see the reply header in the upper portion of your Send Message window. The full text of the reply appears in the lower portion. All messages exchanged in the session remain listed in the window. This enables you to view the text of any message until you close the session.

To use the Novell Client to send instant messages, select NetWare Utilities and Send Message from the N menu. Next, select Users or System Console. To send messages to a single user or multiple users, highlight the user and/or group in the subsequent object list. To send messages to the system console, double-click the server from the list of connected servers. After you’ve entered your message in the text field, click Send to begin instant messaging.

Recall that the main purpose of the network is to provide users with access to network resources. The most popular network resource served by NetWare is the file system. In fact, the file system is the glue that holds your network data together. File services run on the network server and allow users to store, share, and use application and data files through the network file system.

Managing Novell Client connectivity often requires troubleshooting user file access and file recovery. To help you manage files and directories on the network, you must first authenticate to the servers where the files are stored. Next, you must ensure that you have the necessary file system rights to obtain the files. To quickly check a user’s rights to a file or directory on the network, use the Windows Explorer or Network Neighborhood utilities to navigate to a given file. Then right-click the file and select the Properties option. Finally, click the NetWare Rights tab (see Figure 4.8). If explicit trustee assignments have been made to the selected file, the trustees’ distinguished name appears in the Trustees field.

FIGURE 4.8 NetWare Rights dialog box in the Novell Client.

To change a user’s file system rights, you can do one of three things:

In addition to restricting rights, you can use the Novell Client to purge or salvage network directories and files. The Salvage option underneath Network Utilities within the N menu enables you to restore files without having to restore them from tape backup. However, this feature works only before you purge the files to free disk space. Both the Purge and Salvage management options require appropriate file system rights.

The Novell Client also includes a GUI file management program called the NetWare File Copy Utility. The NetWare File Copy Utility can be found within Network Utilities from the N menu. With this program, you can copy multiple files, search by extension types, and/or modify file attributes. I’m sure you’ll agree that this is a huge improvement over the primitive COPY command.

One of the most important elements of client connectivity management is identifying the installed version of the Novell Client. You can view the installed client version, preferred server, and preferred tree for a specific user by selecting Novell Client Properties from the N menu. All of these options are found within the Client tab.

This completes our discussion of Novell Client architecture, installation, and client connectivity management. By now you should appreciate that there’s much more to the NetWare workstation than meets the eye. It’s a complex collection of user components and connectivity hardware. This makes your job as a CNE an incredible challenge. As you’ve learned so far in this chapter, you must have complete control of your faculties to pull it off.

So, where do we go from here? Good question. Now I think you’re ready to extend beyond the typical boundaries of the NetWare Client into the realm of cross-platform connectivity. Hold on tight, this is going to be a wild ride!

NFAP behaves slightly differently in each of the five operating system environments it supports. The cool thing is that it morphs automatically to use the native protocol of the client it’s communicating with. For example, NFAP communicates with Macintosh clients using the AFP protocol, and it transforms the NetWare server into a virtual AppleShare server.

The following is a list of the platforms supported by the NetWare 6 NFAP chameleon:

In this section, you’ll learn how the NFAP chameleon performs its magic for the three most popular native clients—Windows, Macintosh, and Linux/Unix.

Just a hint: It’s all smoke and mirrors.

Now it’s time for action. Enabling Novell NFAP is a relatively straightforward process. First you must make sure that the host server and distributed workstations meet the minimum system requirements. Then you can install NFAP by using the NetWare 6 installation GUI. This involves selecting the Macintosh, Windows, and/or Linux/Unix components to install and configuring certain protocol parameters.

After Novell NFAP installation has been completed, you must select or create User objects and assign them simple passwords before they can access the network natively. This is all part of NFAP configuration. When users access a network resource by using their native protocols, they enter their NetWare username and simple password that are verified by NetWare. This is all part of the high-security methodology maintained by NetWare 6.

Now let’s take a closer look at Novell NFAP configuration, starting with the minimum system requirements.

Configuring NFAP

Novell NFAP incorporates the security of NetWare by using simple passwords. The simple password is required because it provides access to NetWare servers from workstations not running Novell Client software. Just like any NetWare password, the simple password is stored in eDirectory and all users must have one before they can access NetWare resources using native protocols.

When users access a network resource by using their native protocol, they enter their NetWare username and a simple password that is verified by NetWare. The User object then reads eDirectory and controls the network resources that the user can access.

To create User objects and assign simple passwords for NFAP access, perform these steps:

1.   From the administrative workstation, log in as a user with administrative privileges. Then run the ConsoleOne utility by using the CONSOLEONE.EXE file, which is found in the PUBLICMGMTCONSOLEONE1.2in directory.

2.   Create a new User object for NFAP access by right-clicking the appropriate host container and selecting New, User. You can also configure an existing user for NFAP access by double-clicking it.

3.   You must assign a simple password to your new or existing user object. To do so, simply right-click the User object and select Properties. Then choose Simple Password from the Login Methods tab. You should see a configuration screen similar to Figure 4.9. Finally, mark the Set Password radio button and enter the user’s simple password in the fields provided.

FIGURE 4.9 Configuring simple passwords for NFAP user access.

You can create simple passwords for users one at a time by using ConsoleOne or you can automate the process for many users with the help of NORM (Novell Remote Manager).

To create simple passwords for many users, select Manage eDirectory from the left frame of NetWare Remote Manager, and then click on the NFAP Security link. The NFAP Simple Password Management screen should appear (as shown in Figure 4.10). This Web-based form includes these configuration fields:

   NDS Context—Enables you to create a simple password for each user object found in the specified context.

   Traverse Context Tree for User Objects—Enables you to search the tree for User objects and to create passwords for each one that is found. This is very similar to the inheritance flow of eDirectory rights.

   User Supplied Password—This field defines the simple password that you’ll pass to all users in the context described earlier.

   Generate Script File—Enables you to create a text file that contains the scripting commands necessary to create simple passwords based on the NFAP security preferences you selected.

   Process Script File—Enter the script name in this field if you want the system to automate the process of assigning simple passwords to User objects scattered through the eDirectory tree.

FIGURE 4.10 Configuring simple passwords in NORM.

TIP

If the simple password you configure is different from the user’s NetWare password, the user must enter the simple password when accessing the network-native protocols. However, users must also remember that their NetWare password is required when logging in from Novell Client–equipped workstations.

Finally, select Start to begin the automatic simple password assignment process.

All finished! If you have learned anything in this section, I hope it’s that NFAP is your friend. This powerful NetWare 6 chameleon enables you to open the doors of NetWare filing to users of many different workstations, operating systems, and protocols. This is network diversification at its finest.

In this section, you learned that Novell NFAP is a server-based solution that enables Windows, Macintosh, or Linux/Unix clients to securely access NetWare storage natively. Furthermore, NFAP enables these users to be managed through the central eDirectory tree.

Now that we’re armed with a truly diverse population of NetWare users, let’s tackle the most challenging environment of all: eDirectory!

Ready, set, go!