Perhaps one of the most useful features that Novell has added to the venerable but excellent NetWare operating system is the Native File Access Pack, which gives you the ability to access the NetWare file store using client operating system native protocols such as CIFS (Common Internet File System), AFS (Apple File System), and NFS (Network File System). The Native File Access protocols allow for a true “out-of-the-box” installation of NetWare, without the need for any additional software, such as Client32, for access to files on a NetWare server. In this Daily Drill Down, I’ll show you how Native File Access works and how to set it up.

Author’s Note

For this Daily Drill Down, I’ll be using a NetWare 6 server for the server component and a Windows XP Professional workstation running version 4.83 SP1 of the Novell Client. I’ll offer only minimal coverage of native Macintosh access to a NetWare server.

First things first
As with any software component, there are certain prerequisites for Native File Access under NetWare.

On the server side, if you’re running AFP.NLM and APPLETALK.NLM, you must unload them in favor of the MAC.NLM namespace and add the newer namespace to any volumes that you wish to access natively with Macintosh systems. To do so, go to the server prompt on your NetWare 6 server and type:
UNLOAD AFP
UNLOAD APPLETALK
LOAD MAC.NLM
ADD NAME SPACE MACINTOSH TO VOLUME {volume}

Even though the key benefit of running Native File Access is that if frees you from relying on the Novell Client, the workstation that you’re going to use to install and configure Native File Access must be running a recent version of the Novell Client. Make sure that your workstation is running at least version 3.21 for Windows 9x systems and version 4.80 for Windows NT/2000/XP systems.

In addition, if you want the ability to change passwords from a client workstation, you must install a strong version of Novell International Cryptographic Infrastructure (NICI)—at least version 1.5.7. For my example, I’ll be using Client 4.83 SP1 and NICI 2.4.2.

The systems that will connect to the NetWare server using native protocols must also meet certain criteria. Fortunately, these criteria are very simple and easy to deal with:

  • Macintosh clients must be running at least Mac OS 8.1 or Mac OS X.
  • Windows clients have the Client for Microsoft Networks installed.
  • UNIX/Linux systems can use either NFS 2 or NFS 3.

Installing the software
At the server, insert the NetWare 6 Operating System CD. From the server’s graphical console, choose Novell | Install. Browse to the Product.ni file on the NetWare 6 Operating System CD, as shown in Figure A.

Figure A
Browse to the Product.ni file on the NetWare 6 CD.

Click OK to begin the installation of a new component. From the list of components that comes up, choose Novell Native File Access Pack, and click Next to continue. You’ll be prompted to provide the logon credentials for a user with access to the root of your NDS tree. During the installation, you may also be prompted for information regarding other selected components. Leave them at their defaults. Eventually, you’ll be prompted to select which client operating systems you’d like to support with Native File Access. For this example, I’ve chosen Windows and UNIX/Linux (CIFS/SMB and NFS) support, as shown in Figure B. I’ll only be covering CIFS/SMB in the rest of this Daily Drill Down, however. Make your choices, and then click Next.

Figure B
Client OS support selection

The next screen of the installation wizard is the Server Properties screen shown in Figure C. It asks you to provide information regarding the way that the server will appear on the Windows network, such as the server name and a comment. The comment will appear next to the server name when browsing the network. By default, Native File Access uses the server name appended with _W. Click Next to go on.

Figure C
CIFS sample configuration

You’ll then see the Authentication screen. Here you’ll need to provide information on how users will authenticate to these services. Your two choices are local and domain. Choosing local will authenticate users via NDS, while choosing domain will authenticate users via a Windows domain controller. If you choose domain, the wizard will ask you for information regarding the domain controller that you wish to use for this purpose. For this example, I’ll choose the Local option, as shown in Figure D. Click Next to continue.

Figure D
Choose an authentication method.

A nice feature of the Native File Access pack is the ability to limit the IP addresses that can accept requests for CIFS. The IP Address screen allows you to set up this limitation by entering the allowed IP addresses. For my example, I’ve chosen to allow CIFS on all IP addresses, as shown in Figure E. Click Next to go on.

Figure E
Limiting access by server IP address

You’ll then see the Share Point Setup screen shown in Figure F. In the Windows world, a user who browses to a server is only allowed to see the share points that have been set up by the system administrator. You can replicate this functionality on the next screen of the wizard by creating specific share points. If you’d rather just share all of your volumes, you can do so by checking the Share All Mounted Volumes box at the bottom of the window. For this example, I’m only going to share my server.

Figure F
Create share points for your users.

When you click Next, you’ll see the Context Setup screen shown in Figure G. In order to allow for a true “out-of–the-box” installation, you’ll need to avoid NDS nomenclature for your users. You can do this by indicating which NDS containers the Native File Access wizard should search when a user makes a request for a CIFS mount point. Because I’m running a very small lab server, I only have the initial NDS context named Myhome. If you use NDS based on department, you can easily limit which departments are allowed to use these services by choosing them and clicking the Add button.

Figure G
Select which user contexts are allowed to use Native File Access.

At the end of the wizard, a summary screen will indicate all of the products that you’ve added to the server. In that list should be the Native File Access option I’ve described.

Once you’ve finished installing everything, you must restart your server. You can do so by typing restart server at the server console prompt. When the server restarts, you should reapply the latest Support Pack to your server. When the Support Pack has installed, you can start using Native File Access.

Controlling the CIFS Native File Access service
Probably the easiest part of this whole process is starting the CIFS services on the NetWare server. When you restart your server, CIFS will load automatically because the installation program adds the appropriate commands to the server’s Autoexec.ncf file.

If for some reason you need to start or stop the service manually, it’s as simple as typing cifsstrt to start the service and cifsstop to stop the service at the server’s console prompt. You might need to do this is if you make a change to the CIFS configuration.

Administering the service and related users
Because I chose the local authentication method, every user that makes use of the CIFS protocol needs both a user name and a simple password assigned in NDS. The simple password is separate from the NDS user object password and can be different from the user’s NDS password. If the password is different, the user will use the simple password when authenticating with native protocols and the NDS user object password when authenticating with the Novell client.

You can create a simple password for a user via ConsoleOne, which you run from SYS:public/mgmt/ConsoleOne/1.2/bin/ConsoleOne.exe. You must do this from a Windows workstation running a minimum version of the Novell client, as described earlier.

For example, I’ll assign a simple password to a user named slowe in NDS. To do this in ConsoleOne, I’ll click on the Login Methods tab, choose Simple Password from the list, and enter the appropriate information, as shown in Figure H.

Figure H
Assign a simple password to a user.

Testing the service
You can test the service with any workstation that doesn’t have the Novell client loaded. For this example, I have a Windows XP Professional workstation configured without the Novell client. In order to test whether everything works as it should, log into the workstation with the same user name and password that you assigned on the Simple Password tab in ConsoleOne.

To find your NetWare server, click Start | My Network Places | Entire Network. When the Entire Network screen appears, double-click the domain or workgroup that you entered back in Figure D. You’ll then see your NetWare 6 server listed with your Windows servers, as shown in Figure I.

Figure I
Network neighborhood shows the NetWare CIFS server.

You can be certain that this is the CIFS version of your NetWare server because it has the same name as your NetWare server. Also, you’ll notice the comment next to the server and the fact that the server name ends with the _W, or another extension that you provided during the installation.

Allowing users to change their passwords
Native File Access lets users change their own passwords. To do this, press [Ctrl][Alt][Del] on a Windows NT/2000/XP machine, and click Change Password. In the Log On to box, type in the name of the NetWare CIFS server, and then enter the old password plus the new password. From a command prompt in a Windows 9x machine, type NET PASSWORD {Netware CIFS server name} and press [Enter].

When prompted, enter the name of the user, the old password, and the new password. You’ll also need to go to the Passwords control panel and change the local system password for the user in order to keep them synchronized.

Password synchronization
One major problem with this method of handling access to a NetWare server is that each user requires two separate passwords—and in the same profile no less. This can create some confusion for the administrator, but it’s not that difficult to work around it.

If you initially set up the NDS user object password and the simple password to be the same, the NDS user object password is changed when a user changes his simple password so that the two stay synchronized. However, the reverse is not true: If the user changes her NDS password (i.e., from a system while logged in via the Novell Client), her simple password won’t change, and you’ll have to synchronize them manually. If the two passwords aren’t the same, neither will be synchronized when the other one is changed.

Of course, this is only a problem if you’ve chosen to use local authentication. If you’ve opted instead for domain-level authentication, passwords are handled at the Windows domain controller and not in NDS at all.

Free at last!
The CIFS Native File Access protocols allow an administrator a great deal of flexibility in a mixed environment. It can be a great way to reduce the hassle of running Novell’s Client to provide access to your NetWare servers. Password synchronization between the NDS and CIFS sides is not perfect, but being able to provide native access to files can far outweigh this problem.