Chapter 2
Enabling Network Access
Certification Objectives
*Multiple Link Interface Driver (MLID)
*Link Support Layer
*IPX Protocol or IP Compatibility Protocol
*NetWare Client Software
*Restrictions in NDS
*From the Classroom
*Backing up Wisely
*Intruder Detection
*One of the first things end users do when they arrive at the enterprise network, is log in. Logging in gives them access to files, printers, e-mail, databases, and other network resources. Some enterprises require that no data be kept anywhere but on the servers, and in those enterprises, the only way that an end user can get to work is by logging in. There are several things that an administrator has to provide in order to enable login authentication:
Enabling Network Communication (IPX/IP)
In order for workstations to access network resources, they need a method of communication with the server. This method of communication is a protocol. Older versions of NetWare used only the IPX/SPX (Internet Packet Exchange/Sequenced Packet Exchange) protocol. Administrators have added TCP/IP (Transmission Control Protocol/Internet Protocol), the protocol used on the Internet, to satisfy the growing need for businesses to communicate with the Internet. The result is that NetWare networks must run multiple protocols. There is a perception that TCP/IP is easier to maintain since routers are optimized for Internet traffic. So, with NetWare version 5, Novell has stepped up to the challenge and begun to provide TCP/IP as a base communications protocol for NetWare networks. IP compatibility mode can run on a NetWare 5 server, and all IPX dependencies are no longer present. The IP compatibility mode can run on a NetWare client using an IP compatibility mode driver allowing the client to access any NetWare server running IP compatibility mode.
Workstations access the network through client software. NetWare 5 comes with client access software for many different workstation operating systems, including DOS, OS/2, Microsoft Windows 95/98, and Microsoft Windows NT v4.0.
Client 32 Overview
When Microsoft introduced Windows 95, Novell immediately followed with the NetWare Client 32. The 32 stands for 32-bit, which means that the client software is not a standard DOS or Windows 3.x 16-bit application. Microsoft Windows 95 already included a 32-bit client for NetWare, but Novell’s version came with additional access components. For example, Microsoft’s initial version did not allow the end user to browse the NDS tree; it was only a bindery-compatible client. Novell’s version was immediately compatible with NDS.
The Client 32 was popular due to the graphical utilities and speed. Novell then created a Client 32 for DOS and Windows 3.1x. And after Microsoft released Windows NT v4.0, Novell released a 32-bit client for that operating system.
Client 32 requires the following workstation components:
Client 32 includes several software components called NetWare Loadable Modules (NLMs). The Client 32 supports the NetWare ODI specification, or Open Data-link Interface. ODI is a modular client specification, allowing multiple protocols to be used with a single NIC. It requires four components for network connectivity:
Multiple Link Interface Driver (MLID)
The MLID is the software that transmits data onto the network through the Network Interface Card. It communicates directly with the NIC hardware. This software component is different for each NIC used. For example, an Ethernet card will not use the same NIC driver software as a Token-Ring card, and the driver for various Ethernet cards may be different between vendors, or even types of cards from the same manufacturer. Even though the MLID is an NLM, the file does not use the .NLM extension. Instead it uses a .LAN extension. This represents the Physical Layer of the OSI (Open Systems Interconnection) protocol stack model.
The Link Support Layer (LSL) communicates at the Data Link Layer of the OSI model. This connection between the IPX or IP protocol and the MLID is handled by LSLC32.NLM.
IPX Protocol or IP Compatibility Protocol
IPX.NLM and IPHLPR.NLM provide the IPX and IP protocols. These protocols work at the Network Layer of the OSI model. They transmit data between the NetWare client software and the Link Support Layer.
Network applications interface directly with the NetWare client software (see Figure 2-1), which can work at the upper layers of the OSI protocol stack reference model. These layers are all above the Network Layer — Transport, Session, Presentation, and Application. This software enables the mapping of drives, capturing network printers, and access to other network resources. The Client 32 is NDS-compliant, and allows NDS applications such as the NetWare administrator or NDS Manager to run on the workstation. Bindery-based client software will not allow the workstation to browse the NDS tree, or run any other NDS utilities.
Figure 1: Modular software communication for Client 32
Exam Watch: The four components needed to supply client access to NetWare’s ODI specification are, in this order, MLID, LSLC32.NLM, IPX.NLM/IPHLPR.NLM, and CLIENT32.NLM.
All Client 32 software can install automatically using existing configuration or newly edited configuration files. The command is SETUP /ACU. The /ACU switch stands for Automatic Client Update and is also used for upgrading an existing Client 32 installation.
Client 32 Installation Procedure for Windows 95
There are a few different ways of installing the Client 32 on a workstation:
The most common installation is run over the network and attending the setup. This usually involves the administrator copying the installation files to a network server volume. Table 2-1 depicts the optional components available with the Windows 95 version client.
|
Component |
Description |
| Novell Workstation Manager | A single administrative utility for managing user and desktop information. |
| Novell Distributed Print Services (NDPS) | A new printing service enabling bi-directional, real-time communication with network printers. |
| Novell NetWare/IP Protocol | Support for NetWare/IP requester networks. |
| Novell SNMP Agent | SNMP agent that works on both IPX and IP networks. |
| Host Resources MIB | Enables a management console to poll SNMP clients for inventory information. |
| Network Management Responder (NMR) | Supplies operating system, BIOS, and other information to the management console. |
| Novell Target Service Agent (TSA) | Used for backing up workstations. |
| Novell NDS Provider –for Active Directory Service Interfaces (ADSI) | Enables ADSI client applications to access NDS information. |
| Novell Remote Control Agent | Allows other workstations to take control remotely of this workstation. |
Table 2-1: Optional Windows 95 Client Components
Exercise 2-1 outlines the process for installing the Client 32 on a Windows 95 workstation.
Exercise 2-1 Windows 95 Client 32 Installation
Figure 2: Client 32 license screen
Figure 3: Protocol options
Figure 4: Optional components
Client 32 Installation Procedure for Windows NT
Exercise 2-2 outlines the installation procedure for the Client 32 software on Microsoft Windows NT v4.0. The client can be loaded over the network, if the Microsoft Client Service for NetWare is loaded, in both an attended or unattended mode. The client can be integrated with a network installation of Windows NT, or manually installed from diskettes or CD.
Client 32 for NT uses the IPX/SPX compatible protocol that comes as part of the Windows NT operating system. It is recommended, but not necessary for diskette or CD installs, that the Microsoft Client Service for NetWare be set up prior to installing Client 32. To verify that it is installed, right-click on the Network Neighborhood and select Properties. Click the Services tab to view which clients are installed (see Figure 2-5).
Figure 5: Client Service for NetWare
Exercise 2-2: Microsoft Windows NT v4.0 Client 32 Installation
Figure 6: Removing Client Service for NetWare
Login Concepts
There are several different security controls in NetWare:
The authentication process manages login security. Authentication is configured through the restrictions and rules set within NDS, with properties of objects such as users who log in and container objects that contain user objects somewhere beneath them.
Several NDS restrictions establish network security. The Login Restrictions properties in the User object (see Figure 2-7) enable the administrator to restrict whether a user may log in at all. The administrator may disable the ID, force it to expire on a given date, or limit how many concurrent logins the user may have.
Figure 7: Login Restrictions properties for User objects
The Password Restrictions properties allow the administrator to establish password policies on a per-user basis. The administrator may set whether a user can change their password, how often the password will be required to change, or how many grace logins the user is allowed with the old password before they must change it.
Deciding whether or not to back up the file system is not hard. What is usually a less obvious, yet critical, decision is what to do with the NDS database. Don’t forget to back it up. True, it is a distributed, replicated database, but waiting for the synchronization to happen between replicas can be time-consuming and crowd the bandwidth while critical information is being updated, especially if done over WAN links. Including NDS as part of the backup is prudent and saves time in the long run, particularly if you've ever experienced a catastrophic disk failure on a server containing several partitions' worth of Master Replicas and have to restore everything.
— By Dan Cheung, CNI, MCNE, MCT
Login Time Restrictions properties offers the administrator a method of restricting logins on a time basis. The benefit of a login time restriction is for handling daily backups or weekly scheduled maintenance of the servers. It effectively avoids some data loss by making sure that no files are open when other processes need to access them, or when the server is suddenly taken offline. In Figure 2-8 the shaded area shows that logins are restricted between 12:00 a.m. and 3:30 a.m. each weekday.
Figure 8: Example of Login Time Restrictions
Network address restrictions uses the network node address of a workstation, and limits the network access for a user to only the workstations having those addresses listed. For high security networks, using a network address restriction can make sure that a user does not login at an unauthorized.
An intruder is anyone who attempts to log in to the network using an invalid password. NetWare can lock an account when an invalid password is used too many times for a user ID. This is to protect the network from hackers trying to figure out a password.
Figure 9: Establishing intruder detection in an organizational unit
Intruder Detection is established in a container object, through the Intruder Detection property, as demonstrated in Figure 2-9. The default settings are not to detect intruders. There are two reset intervals. The Intruder attempt reset interval is the length of time to wait before starting to count the number of incorrect password attempts again. For example, if Joe is allowed seven incorrect login attempts, and the intruder attempt reset interval is 30 minutes, then the 30 minute period starts from the first bad login attempt. Joe can try six times in a 30 minute period to log in with the wrong password and not lock out the user account.
The Intruder lockout reset interval kicks in after the user account has been locked out. If Joe has been locked out of his account, and the intruder lockout reset interval is 15 minutes, then he can wait 15 minutes. At that point in time, the user account will no longer be locked out, and provided he knows the correct password, Joe may log in.
Login Process
Novell Directory Services enable users to have a single login to gain access to any enterprise-wide network resource. Authentication is the process that enables the single login capability.
When a user logs in to the network, it may appear that the password is sent to the server and that the server clears the user for access. However, for security reasons, the password is not sent across the network. Instead, an encrypted user code of the user’s information — including user name, password, workstation, and other details—is created from the login process. The authenticating server performs the same process to create a user code. The server compares its user code to the workstation version and if it matches, the user is granted access.
As illustrated in Figure 2-10, when a user logs in there are several scripts that will be run in a specific order.
Figure 2-10: Logical cascade of Login Scripts
The following is a list of commands found in the default login script:
MAP DISPLAY OFF
MAP ERRORS OFF
REM (Set first 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
| Justine is the administrator of a NetWare 5 network. She has created a Profile script that runs a CAPTURE command for the Graphics Department’s color laser printer. Justine then assigns the Profile script to the users within the Graphics Department. There is no Container script or User script being run. When Justine tests the script, she gets an error that the external command CAPTURE cannot be executed. CAPTURE is in the Public directory, and when Justine checks, there is a mapping to SYS:PUBLIC. Why does she get this error and how can she fix it? | Justine was depending on the default login script to provide the mapping to the Public directory. However, because the Profile script executes before the default login script, it did not have a mapping to SYS:PUBLIC when it was trying to find the CAPTURE command. In order to fix this, Justine can add the Search drive mapping to the Profile script. Or, to prevent errors like this from happening in the future, she can place the commands she wants to have in the Container script for all users and add the NO DEFAULT line so that the default script will not run for users in that container. |
Browser Client Installation
A web browser, Netscape Navigator v4.04 , is part of the client installation options on the NetWare 5 CD. The steps for installing the browser client are outlined in exercise 2-3:
Exercise 2-3: Netscape Navigator v4.04 Installation
Previous versions of NetWare did not include a web browser. The need simply was not prevalent in an IPX-based network. With Internet and intranet access needs becoming more accepted in networks, including a web browser on a client workstation has become necessary. This completes the client software needed to access a NetWare 5 server configured as a web server. New to NetWare 5 is the publishing of Help files and server documentation in HTML (HyperText Markup Language) format. To view the documentation, a web browser is required.
Certification Summary
The communication between the workstation and the server is through a protocol. NetWare 5 can use both the IPX protocol and the IP protocol from the client to access a server running the same protocol. The IP protocol is new to NetWare 5 in the sense that the server and the workstation do not need to have IPX running for network access.
Client 32 is a 32-bit software application that is available for DOS, Windows 3.1x, Windows 95/98, and Windows NT 4.0 workstations.
Client 32 has four components for network communication that translate to a layer of the OSI reference model for protocol stacks. The specification for the four components is called ODI, or Open Data-link Interchange. These four components are:
The applications that provide the components are called NLMs, NetWare Loadable Modules. The files that provide each layer are a .LAN file for the MLID that is specific to the card being loaded. This file is still an NLM even though the file has a .LAN extension. LSLC32.NLM provides Link Support Layer communication. IPX.NLM and IPHLPR.NLM provide network layer services. CLIENT32.NLM supplies the client access software interface and upper layers.
The Windows 95 Client 32 installation can be installed from CD or diskette, over the network, and can be integrated with an installation of Windows 95/98. The installation can be run in an unattended mode using a switch after the setup program. The command is SETUP /ACU. The /ACU switch stands for Automatic Client Update and is used for upgrading an existing Client 32 installation.
Windows 95 setup files for Client 32 are located on the NetWare 5 CD-ROM. It is typical for an administrator to copy them to a network server for installation.
Windows NT setup files for Client 32 are located in a different directory on the CD. The setup executable for the NT version of Client 32 is SETUPNW.EXE.
Login security within NetWare is above and beyond file security and NDS security. Properties of user objects and container objects will configure how login security works. These things include password restrictions, login time restrictions, Intruder Detection, and network address restrictions.
The login process begins with authentication. The user’s password is never sent over the network wire. Instead a complex process at the workstation creates an encrypted package of the user’s information and typed-in password. The server is notified of the login attempt and creates the same encrypted package and compares it to the one from the workstation. A match allows the login to occur. Once the user logs in, the authenticating server will check for a Container Login script and run it if there is one. Then it will look for a Profile script and run it if there is one. Then it will look for a User Login script and run it if there is one. If there is no User script, the login process will run a default login script.
To provide the network an access method to HTML documents, NetWare 5 comes with Netscape Navigator, version 4.04.
Two-Minute Drill
