Implementing NDS-Enabled Solutions at Clemson University, Part 2
Articles and Tips: article
LAN Systems Manager
Clemson University
PAMELA J. BOWEN
Consultant and Trainer, Computer Training
Clemson University
SCOTT HAMMEL
Systems Programmer I
Clemson University
01 Aug 1998
Find out more about how Clemson University is using NDS to create a campus-wide collaborative learning environment for students, faculty, and visitors.
Introduction
The purpose of this two-part series is to show how Clemson University in Clemson, South Carolina, has provided an effective set of solutions by leveraging the power of Novell Directory Services (NDS) and making NDS the centerpiece of security, fault tolerance, and authentication. Part 1 of the series covered hardware configuration, NDS tree design, and the Collaborative Learning Environment (CLE). (See "Implementing NDS-Enabled Solutions at Clemson University" in the July 1998 issue of Novell AppNotes.)
As explained in Part 1, the Clemson network provides computing support to students, faculty, and staff in a comprehensive manner, including single login and authentication for all services and work spaces. Each student, faculty member, or employee is automatically assigned a user ID and work space on a server for storage of personal documents. Using a "virtual laptop" concept, the network allows users to log in from any campus workstation and immediately be presented with the look and feel of their own desktop. A series of Clemson-developed NetWare Loadable Modules (NLMs) are used throughout the login and authentication process.
A central server authenticates all logins, and a single login provides access to a wide range of servers and applications. Access to network resources is controlled by NDS. Once authenticated, users have access to all network resources defined for them and to their personal work spaces.
This second AppNote offers details on Clemson's virtual laptaps, NLM development, authentication, and printing and e-mail strategies.
Virtual Laptops
Over the past three years, the Division of Computing and Information Technology (DCIT) at Clemson has developed and deployed the "virtual laptop" computing environment. Thirty-three university computer laboratories, providing about 700 workstations, now run what is known as the "standard image," which allows students to go to any workstation, in any lab, at any time, and through a single login have the workstation in front of them transformed into their own personally configured workstation. Upon logging in to the network at another workstation at some later time, the student's workstation appears exactly as it was left earlier. This includes settings and preferences used in applications such as Microsoft Office, Netscape Navigator, and Eudora e-mail.
Clemson started by examining the underlying reasons students need their own personal computers. In essence, students need applications, documents and data to be delivered wherever and whenever they may require them. This includes in classrooms, computer labs, dormitory rooms and off-campus locations. Furthermore, such services are best delivered in a secure and reliable environment with dependable backups. Finally, the support should be delivered at a low cost. This was the basis for the Clemson virtual laptop.
A network login also gives students access to the Internet via the Netscape Web browser or through other common Internet access utilities such as Telnet or FTP. Eudora e-mail is available in all labs.
Internet access isn't all that a login in the public computer labs offers. Students are given a veritable Internet presence with the ability to create and store their own Web pages in their personal user space. Novice Web users could type simple documents in Microsoft Word, save them (as HTML) to their PUBLIC.WWW folders in their user space, and the documents would immediately be visible to others on the Web. No complex file transfers or knowledge of UNIX is required.
Students can check the current usage in 33 DCIT and departmental computer labs using the Lab Status application. It shows the number of desktop computers in use and available in these labs, and the information is updated every 30 seconds. Students can also update personal address information from the Web using Student Information Services (SIS). A full range of student services was placed in SIS last fall. All users can now set an e-mail forwarding address from the Web.
The virtual laptop program is highly efficient. Whereas student-owned machines are used only when the owner turns them on, the lab machines stay busy a large proportion of each day. Students do not need to search around for a suitable machine, either appropriately configured with hardware, or, more likely, with the appropriate software. All machines appear identical in function, but with the desktop being tailored to the individual who has just logged on.
The fact that the virtual laptop approach satisfies the large majority of student users means that the transition to a true laptop ownership model can be undertaken in a more planned and orderly fashion. Pilot laptop programs can be undertaken and properly analyzed before proceeding to the next step; modifications to the information technology support structure are more easily made and funded; and the administrative and logical details related to managing a campus-wide laptop ownership program can be fully worked out in advance.
At Clemson, the virtual laptop environment has proven to be so successful that, within two years, it has all but eliminated the independent college and departmental student computer labs. All but the most specialized labs now run the standard environment, resulting in an approximate doubling of the number of workstations in the general student pool.
All lab PCs run Windows 95. There are items under the "Start | Programs | Dept.Apps Menu" for each college in which several other programs are available. These programs were purchased by individual departments and professors and are available in certain labs for use by particular individuals and classes. The pieces of software in this group are not supported by DCIT.
Programs Executed by Virtual Laptops
Virtual laptops execute a combination of off-the-shelf and custom programs. Some of these are available on login, while others are available on logout. The programs in both categories are listed after Figure 1, which shows the interaction among the workstation, root server, and application server at login.
Figure 1: SFLogin uses NDS to find the correct User object and to set the context. Client 32 then checks the ID/password, requests the profile script, and processes it.
On Login. Programs executed on login include the following:
SFLogin by Netoria. This is a NetWare client extension that provides contextless login. After the correct user ID and password are entered, the login script is processed, and several processes are spawned in response to the script:
IsItCool. This is a Clemson-developed NLM and workstation client that decides which lab application server to use for the current session. A list of servers is kept in the registry on each lab machine. The IsItCool client on the workstation queries the IsItCool NLM on the server to determine the status and availability of the server. (Figure 1 illustrates the details of SFLogin and IsItCool in relationship to the workstation, the root server, and the application server.)
CUMAP. This is a Clemson-developed application which maps drives to servers based on the registry key set by IsItCool.
DataCool. This is workstation client code that provides IsItCool functionality for the data servers (where home directories live). DataCool provides fail-over in case a user's home directory is not available. If ISITCOOL.NLM on the server does not answer the workstation query or returns a "don't connect" message, the workstation displays a message to the computer user and sets up a default configuration on the hard drive, with the e-mail client configured to "leave mail on server." This allows people to work even when their home directories are not available.
PCRDIST by Pyzzo Software. This program is used to load the profile for the user ID, set the Windows 95 Start menu to a standard, and to set location-specific things such as print queue mappings. PCRDIST does the bulk of its work at this point by invoking other programs:
REGDUMP (Pyzzo software) is used to export registry hives to registry export files.
REGEDIT (which comes with Windows 95) is used to import the registry keys specific to the current user from drive U (a standard mapping in the Clemson environment).
EDITREG(developed at Clemson) is used to change specific registry
PATCH95 (developed at Clemson) reads configuration files from application servers and from home directories and invokes EDITREG for one-time applications of changes to various pieces of a user ID's registry keys.
EDITINI (developed at Clemson) is the same as EDITREG, but for Windows .INI files.
Novell Application Launcher (NAL) is used to deliver disk space and some applications to users. This is the lab link to the Collaborative Learning Environment.
On Logout. Programs executed on logout include the following:
TRAPSD (from Pyzzo Software). This utility is placed in the Windows 95 system tray and intercepts any Windows shutdown message. It invokes PCRDIST.
PCRDIST (via REGDUMP) exports the user ID's registry keys to drive U. This saves things like settings for wallpaper, various application preferences, and so on.
If the user has chosen to simply log out, that's all that happens. If the user has chosen to shut down or restart the workstation, the following events also happen:
PCRDIST returns the registry to a default state.
PCRDIST makes the directory/file structure on the computer's hard disk look like the image on the application server.
PCRDIST ensures any .INI files settings and other configuration settings are as they should be.
PCRDIST reboots the computer.
Clemson's Systems Integration Group (SIG) uses MS Visual C++ Professional to develop such utilities as CUMAP and EDITREG.
The Role of Lab Support
The Lab Support Group has always had a small staff in relation to the work they do. Therefore, their second goal behind customer service has always been easy, flexible maintenance. They will often take non-traditional routes to obtain their objectives. For example, they maintain much of each user ID's Windows 95 profile themselves rather than allowing Windows 95 to do it because it turns out to be more work to mesh Windows 95's mechanisms for profile management than to implement their own.
Unlike other departments around campus that might own general-use computer labs, Lab Support's view is very general. They implement for the campus as a whole, not for the needs of particular departments or colleges. In response to new service requests, they will often take a specific request and generalize it to a type of request and implement an infrastructure to support it. By implementing the infrastructure rather than each individual request, they provide solutions now for issues that arise later and can often leverage the manpower and expertise of local departments to implement specific instances of their general infrastructure.
For example, currently Lab Support must perform all software installations since the hard disk image on the servers is just a copy of a workstation hard disk. Now that many departments have labs that run DCIT's "standard lab image," the number of software requests has increased and the required turnaround time on installs has decreased. Therefore, Labb Support is restructuring the image and replacing tools such as PCRDIST to support an image that will allow departments to perform their own installations to augment the standard image rather than modifying the image itself for every install. They are moving toward providing an image infrastructure rather than providing the complete image themselves.
NLM Development at Clemson
DCIT has been a strong development shop for several years. Members of the Server Support group use the NetWare SDK and BorlandC/C++ to write such NLMs as the following (which are linked by way of Novell's NLM linker):
|
AUTHSERV |
Locates user objects, checks passwords, checks security equivalences, and performs a variety of other administrative functions; uses different hooks to communicate with different operating systems |
|
CUSCRCH |
Reviews file system and deletes dated material |
|
GROUPMGR |
Automatically updates groups as students add or drop classes |
|
ISITCOOL |
Uses IP to query for an accessible application server; if the nearest app server is unavailable, ISITCOOL checks for the next one. |
|
LOGNTIME |
Looks at who is logging in to network and gives variety of statistics on each node |
|
MACUSERS |
Gives information on all Macintosh users on the network |
|
SCRATCHW |
Warns users that certain files are scheduled for deletion |
|
SMTPCLNT |
Formats and sends E-mail messages for applications |
|
USERMNT |
Creates, modifies, and deletes user accounts |
Authentication
In the past, the MVS mainframe has been the center of the computing backbone for security and availability at Clemson. However, if they were to try to use MVS as the authentication server, it would be required to be available on a 24 x 7 schedule. Despite its stellar reliability record, it could not meet this need. They have had some experience with DCE, but widespread multi-vendor support has yet to be evidenced. Since implementing NDS, they have achieved 100 percent availability despite individual server failures, thanks to the design of their replica rings. It was decided that instead of trying to synchronize the passwords with other systems, these other systems would simply use NDS to authenticate in real time.
In November of 1995, Clemson sent two Systems Programmers to developer school at Novell in Provo. They would develop a set of NLMS to accept requests from other systems as well as hooks on these other systems to redirect both local user authentication and password change requests to the NLM. They spent the next two months prototyping and the next four months developing and testing the production version of the code. The system was put into production on July 1, 1996.
The NLM runs on multiple servers for fault tolerance in case of a server or network outage. The authentication NLM is multithreaded to be able to simultaneously handle multiple requests from many systems. It makes full use of NDS constructs concerning the user account and password. Examples are password expiration, password rules from the user object, and intruder detection, as defined in the user object's container.
Figure 2: The base client code is the same for all platforms.
As illustrated, the base client code authC is the same for all platforms. The communication with AUTHSERV.NLM is carried out using BSD-based TCP sockets over IP. The hooks for the various clients are dependent on the OS. With the OS/390 system, they have made use of RAC-F user exits to redirect password check and password change requests to the NLM. This means that all software systems on OS/390, including the IDMS database online systems, ultimately use NDS for authentication, as shown in Figure 3.
Figure 3: All systems use NDS for authentication.
For software systems that run on top of the OS, calls may be made directly to exported functions that make use of the base client code. For example, a Web server application running on NT makes calls to a 32-bit DLL that is provided to use built-in Web authentication tools against NDS. The developer needs to know nothing about socket programming, as debugged base code is provided in the form most viable for each platform. Client code now runs on the OS/390, Windows NT, Solaris, BSD UNIX, Linux and Windows 95 platforms, either as an integral part of the OS or as a tool available to software developers on those platforms. Any platform that supports TCP/IP is a candidate to be added as a client. The base client code has a built-in fault tolerance mechanism to contact the secondary and tertiary servers in case of a network or server outage.
Additional Functionality
Soon after putting this new software into use, the Clemson team began to receive requests from application programmers for additional client functions. They wanted to leverage NDS into these other platforms. The authentication server has basically grown into a gateway for other systems to NDS. This has made NDS become the centerpiece of connectivity and security at Clemson, particularly with respect to Web development.
For example, a Web developer wants to not only authenticate a user, but restrict access to data over the Web after the user is authenticated. When the user connects to the secured URL, the built-in authentication mechanism in Netscape or Internet Explorer can be driven to prompt for user ID and password. As you may know, this information is encrypted at the workstation before being transmitted to the Web server, which then makes the authentication call to the NLM via a DLL.
After the user is authenticated with NDS, the Web developer can then decide what access this particular user has to the data or page he is requesting by making a call to the security equivalence routine in the authentication client. This will check for this user's security equivalence to a fully distinguished group, or for that matter, to any NDS object in the tree such as an Organizational Role. This particularly useful since security constructs are often already defined in NDS for users and groups to function in the NetWare environment.
Results
Between March 20 and May 8 of this year, the primary authentication NLM processed 2.2 million requests. There was some concern about the turnaround time required for a client system to create a TCP socket to the server, have the server process the request, and return the result. Based on statistics gathered from MVS, more than 90% of successful password check requests are sent, processed, and returned in less than 1/10 of a second.
The authentication server has been successful from developers all the way down to end users. There seems to be a general increase in knowledge concerning one's password. Our help desk performs fewer password resets. Previously, as students only used the mainframe once or twice a semester for pre-registration, we usually ended up doing about 16,000 password resets around that time. Now, since users have been using the password along all semester, this is no longer a problem. Developers like using the client as part of their applications since it brings some uniformity to the multivendor client/server development world. Users like it because they don't have to remember multiple passwords.
Security
There are several aspects of security that warrant mention. With a single user ID/password across all systems, there is some concern that when a password is compromised, it is compromised across all systems. However, the Clemson team has found that with only one password to remember, users are more likely to choose a strong password to begin with. Also, they are less likely to compromise the password by sharing it or writing it down since it is so important (permitting access to grades or salary information).
Since the client systems are using NDS for authentication instead of the local security system, this leaves the local security system less vulnerable to hack attempts. Who cares if someone steals the /etc/passwd file from a Unix system and runs crack against it if the Unix system does not use the password file for authentication? The authentication NLM only accepts requests from authorized clients as defined in a configuration file that is read at startup. The data is secured with a key. As mentioned previously, the Web interface makes use of built-in browser encryption so that the user ID and password do not go across the wire in clear text.
Clemson only allows trusted machines with trusted administrators to run the authentication client code. This is a philosophical hurdle that their seasoned systems programmers had to overcome. In the past, they controlled all authentication dialogs and access to systems. In today's computing environment, this is no longer the case as application programmers must now write and process the authentication information. What's to keep a web developer from filing valid user ID/password combinations as he makes calls to the authentication server? Today, we must trust application programmers not to do this.
A Look into the Future
In the future, the Clemson team will continue to add functionality to the server to better leverage NDS in other environments. There are remaining items on the wish list from developers. They hope to add OS interfaces to additional systems. They will also be adding clients as new operating environments emerge. In the near future, they hope to integrate with Oracle as it is becoming a mainstay in database development in Clemson's data warehouse system. Clemson still has an eye on DCE; if it matures, they will make it a player, possibly adding the NDS-based authentication server as an element of the DCE security server. A related goal is to provide for single signon, so that once a user is authenticated to one system, the user no longer has to supply a password to others, much like NetWare 4.x works for multiple server access.
Printing
Clemson's printing strategy can be summarized as follows:
All shared printers are network attached, supporting only IPX.
All printer access is controlled through NDS.
UNIX print services make any print queue available to any TCP/IP host using standard LPR/LPD protocols.
UNIX print services also make high-speed institutional printers on mainframe available to both NetWare and UNIX users and applications.
Figure 4 shows how NDS manages printer access.
Figure 4: NDS design for printing.
Clemson's e-mail server is based on Sun Solaris and incorporates server software developed at Clemson. No user accounts are required on Solaris. The messaging system employs a Eudora site license purchased by DCIT and is centered on the Post Office Protocol/Multipurpose Internet Mail Extensions (POP/MIME) Internet standard protcols.
NDS runs in the background and allows for automated distribution lists and automated NDS group membership. The NDS interface to the list server accomplishes the following:
Enables collaborative work between faculty and students.
Uses data from the employee system on MVS to keep department NDS groups correct.
Lets users use NWAdmin to manage e-mail lists.
Eliminates the need to make changes to NDS and the list server.
Ensures that data is correct everywhere.
Figure 5 illustrates the role of NDS in managing distribution lists.
Figure 5: Managing distribution lists with NDS.
Conclusion
The mission of Clemson's Division of Computing and Information Technology (DCIT) can be summarized as follows:
Provide a computing infrastructure for faculty, staff, and students.
Empower users and departments.
Provide guidance in selecting solutions based on industry standards.
Deploy solutions to meet the needs of institutional computing.
Provide user support and training.
In meeting these objectives, DCIT has leveraged the power of NDS. For example:
NDS allows single login and authentication across a diverse network that includes NetWare, OS/390, Windows NT, Macintosh, and a variety of versions of UNIX.
NDS replication provides system-wide fault tolerance.
The LAN infrastructure is built on NDS, and NDS enables the network to appear as a single cohesive entity to the user.
NDS controls access to network resources.
NDS provides information about printers and manages printer access.
NDS manages e-mail distribution lists and allows for automated lists and automated group membership.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.