Often, administrators will attach a machine that’s running Windows 98 to a Novell NetWare network without giving the arrangement a second thought. However, you should take into account many important issues when making such a connection, especially related to security. In this Daily Drill Down, I’ll discuss some of the issues that you should consider when running Windows 98 with NetWare. I’ll also discuss remedies to some of the problems you may encounter.
Working with Gateway Services for NetWare
Before you can really discuss the issues involved in connecting Windows 98 to a NetWare server, you must take a look at the connection method. One common method is to use a Windows NT Server that’s running Gateway Services for NetWare. Gateway Services for NetWare is a Windows NT service designed to allow non-NetWare clients to access a NetWare server. This is accomplished by attaching a Windows NT Server to the NetWare server. The clients then log directly into the Windows NT environment and access all NetWare files by using the Windows NT Server as a proxy agent. However, you’ll encounter some serious security issues with such an arrangement.
Gateway Services for NetWare works by using a pre-selected Windows NT account to access the NetWare server from the Windows NT Server. Usually, this is an account that has unlimited permissions to the NetWare server. Once the gateway service has been set up, a client accesses NetWare resources by passing through a share point on the Windows NT Server. The Windows NT Server then uses the account with permissions to the NetWare Server to retrieve the requested resources and pass them back to the client.
The problem with such an arrangement is the fact that all client/server communications work through share points. Even though the clients are accessing the NetWare resources through a Windows NT Server, you can’t assign NTFS (file-level) permissions to the resources, because NetWare doesn’t support NTFS. Furthermore, you can’t really restrict the account that’s doing the actual NetWare access because it usually requires full access to the NetWare server. This means that all security must reside at the share points you set up.
It is possible to properly configure your security at the share level. However, you must exercise extreme caution when doing so. The reason is that it’s very easy to create overlapping or contradictory permissions. For example, imagine you have a folder on the NetWare Server called DATA. The DATA folder contains a subdirectory called FINANCE. Now suppose a given user needs full access to DATA but should have only read access to FINANCE. In such a situation, you’d have to create a share point on the DATA folder (or on a folder above it) and grant the user full access. You’d also have to create a share point on the FINANCE folder and give the user read-only access. Although this arrangement sounds simple enough, consider that when you give access to a share, the access trickles down to everything below the share. This means that if the user in question tried to access the FINANCE directory through the FINANCE share, the user would receive the appropriate read-only permissions. However, if the user went in through the DATA share and navigated through the directory structure to the FINANCE directory, the share permissions the user had at the original point of entry would still apply, thus giving the user full access to the FINANCE directory rather than the read-only access the user was supposed to have. Unfortunately, there’s really no easy way around this little dilemma. The best thing that I can tell you is to be careful about how you arrange your directory structure and be careful about how you create your shares.
Microsoft Client for NetWare vs. Client32
As I mentioned earlier, the security issues you’ll encounter will depend heavily on how your clients attach to the NetWare server. Suppose you’re not using Gateway Services for NetWare. If you’re not using a gateway, then your Windows 98 clients will have to use some type of client access driver to connect to the NetWare server. Usually this means using either the Microsoft Client for NetWare Networks that’s supplied with Windows 98 or the Client32 NetWare requester that you can download from Novell.
The client that you use brings up a lot of issues. There are pros and cons to using each client. Let’s begin exploring these issues by looking at the client supplied with Windows 98.
The Microsoft Client for NetWare Networks is simple to configure and usually works very well. The big problem with this client is that it’s limited to logging on to the NetWare environment in bindery emulation mode. This means that Windows 98 workstations that are running such a client can’t run administration programs such as NWAdmin. Often, this doesn’t present a big problem—it’s just a pain from a help desk standpoint to go out to a machine and discover a potential problem, and then have to go back to your desk to fix the problem. However, if security is your main goal, there are certainly advantages to making it impossible to run administrative programs from your workstations.
If you want to use Microsoft’s client and still want access to NDS services, Microsoft provides an additional component to its client called the Microsoft Service for NetWare Directory Services. You can add the service by clicking Add in the Network Properties sheet and selecting Service.
One big problem with using the Microsoft requester, though, is that you can’t connect a workstation’s printer to a NetWare print queue via NPRINTER. This is because hosting a NetWare printer through Windows 98 involves running the NPTR95 program. Unfortunately, this program won’t run in bindery emulation mode. It will run only in directory services mode. However, even if you run the Microsoft Service for NetWare Directory Services, you can’t use NPRINTER because it relies on certain DLLs included with Novell’s client.
If you want to make a workstation’s printer accessible to other workstations, you’ll have to load the Client for Microsoft Networks on each client (in addition to the Microsoft Client for NetWare Networks). Once both clients are loaded, you can share the printer using the usual Microsoft method.
With all the difficulties associated with using the Microsoft Client for NetWare Networks, you may be wondering why you’d ever want to use it. However, there are some problems associated with Novell’s Client32 as well. A very serious bug exists in many of the newer versions of Client32 that causes DOS-based FoxPro databases to be corrupted after they’ve been accessed. If you’re using FoxPro on your network, you may want to upgrade to the newest version of the client. You should turn Use Extended File Handles on in the client’s properties. Also, you should check to make sure that Opportunistic File Locking is turned off.
The main problem with the Novell client appears in low-resource situations. The Novell client consumes more resources than the Microsoft client. If your workstations run applications whose minimum requirements are near the workstations’ current configuration, the Novell client may cause the workstations to perform unacceptably slowly.
NetWare and long filenames
Although not really security related, another common issue that you may encounter when connecting Windows 98 to NetWare is that by default, versions of NetWare prior to NetWare 5 aren’t configured to accept long filenames. Therefore, if one of your users tries to save a file with a long filename to a NetWare 3.x or 4.x server, the user will receive an error message, the file will save under an unexpected name, or both. As you can imagine, this can be quite troubling to an unsuspecting user.
You can get around this issue by simply enabling long filenames. You can do this by enabling the OS/2 name space. How you do this depends on the version of NetWare you’re running. If you’re using NetWare 4.10 or earlier, type the following commands at the NetWare server’s command prompt:
ADD NAME SPACE OS2 TO VOLUME SYS
Next, add the following command to the STARTUP.NCF file:
Finally, down the server and exit the NetWare environment. When DOS loads, copy the OS2.NAM file from your distribution CD (or disks) to the directory that contains the SERVER.EXE file. You may now reboot the server and begin using long filenames.
If you’re running a NetWare 4.11, the process is much simpler. All you have to do is type the following commands at the server’s command prompt (within NetWare):
ADD NAME SPACE LONG TO SYS
Once you’ve done so, you can test the long filenames by either creating a file with a long filename or by using the VOLUME command to check the status of the volume’s long filename support.
Sharing resources among peers
If you’re using Microsoft Client for NetWare networks, you’ll have to jump through a couple of hoops before you’ll be able to share local resources with other PCs. This is because NetWare was never designed to function as a peer-to-peer environment.
To share resources off your local machine with other users, open Control Panel and double-click the Network icon. If you’re already attached to a NetWare server, you’ll already have either the Microsoft Client for NetWare Networks or the NetWare Client32 loaded. You’ll also have IPX/SPX or NWLINK IPX/SPX loaded. These components, along with a network card driver, represent the minimum requirements for attaching to a NetWare network. However, sharing local resources across that network requires a couple more components.
To install the required components, click the Add button. When you do, you’ll see the Select Network Component Type dialog box. Select the Client option and click Add. Next, you’ll see the Select Network Client dialog box. This dialog box contains all the available network clients. Select Microsoft from the list on the left and Client For Microsoft Networks from the list on the right. Click OK to return to the main Network properties sheet.
At this point, click the File And Print Sharing button. Select both check boxes in the resulting File And Print Sharing dialog box and click OK. Click OK again to close the Network properties sheet. Windows 98 will now copy a few files from your installation media and ask you to reboot the system.
When the system reboots, log in as you normally would and return to the Network properties sheet within Control Panel. At this point, navigate to the Access Control tab. This tab contains two radio buttons. Normally, the tab is set to use share-level access.
You can use share-level access if you want to, but doing so requires that you create passwords on each workstation to allow access to that workstation. Instead, you can use User Level Access Control to enable all access rights to be determined by your NDS tree.
Therefore, select the User Level Access Control radio button. Once you’ve done so, you’ll have to specify the NetWare server that contains your security accounts. This will be the server that Windows 98 pulls its list of usernames from. Now, click OK twice and you’ll see a warning message stating that existing share points will be destroyed. Click OK to acknowledge the message. Windows 98 will now ask you to reboot the system. When the system reboots, you can begin sharing resources.
When you create a share point, it will look a little different than what you may be used to. Instead of just specifying a share name, you’ll be asked for a list of users who should have access to a share. You can specify one list for users who should have full access and another list of users who should have read-only access. The names that you can use in the list are pulled directly from the NetWare server you specified earlier. When a user tries to access the share that you’ve set up, Windows 98 checks the username against the list to see what level of, if any, access the user should have to the share point.
There are many more issues involved in connecting Windows 98 to a NetWare network than most people realize. In this Daily Drill Down, I’ve addressed some of the security-related issues you may encounter in such an environment. I also discussed the workaround for these issues.
Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it’s impossible for him to respond to every message. However, he does read them all.)
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.