Novell is now a part of Micro Focus

Developing NDS-Enabled Solutions at Clemson University, Part I

Articles and Tips: article

DAVID CONDREY
LAN Systems Manager
Clemson University

PAMELA J. BOWEN
Publications Editor, Consultant
Clemson University

SCOTT HAMMEL
Systems Programmer
Clemson University

01 Jun 1998


The Clemson University Network supports more than 36,000 students, faculty and staff, offering them such services as single login and access to personal work space from any location on campus. This article shows how Clemson's Division of Computing and Information Technology has developed sound, directory-enabled solutions by leveraging the power of NDS with customized NLMs and utilities. Future articles in this series will discuss specific NLMs and utilities and show sample code.

Introduction

Clemson University's Division of Computing and Information Technology (DCIT) has implemented a campus network that is both technically strong and functionally rich. This cross-platform network incorporates several different operating systems--including NetWare, OS/390, Windows NT, Macintosh, and a variety of versions of UNIX--and offers computing support to more than 36,000 students, faculty, and staff. The features of this network, which include single login and authentication for all services and work spaces, are available automatically to all members of the campus community and now make possible the move to a campus-wide collaborative learning environment later in 1998.

The purpose of this article is to show how Clemson's DCIT has developed sound, directory-enabled solutions by leveraging the power of Novell Directory Services (NDS) with customized NetWare Loadable Modules (NLMs) and utilities. Future articles in this series will discuss specific NLMs and utilities and show sample code.

For example, each individual entering Clemson as a student, faculty member, or employee is automatically assigned a computer user identifier (userid) and work space on a server for storage of personal documents and data. An NLM is used to automatically create the user account and home directory. Employing a "virtual laptop" concept, the network allows students to log in from any of the campus computer centers--which are called "labs"--and immediately be presented with the look and feel of their own desktop. This includes settings and preferences used in software, such as Microsoft Office, Netscape Navigator, and Eudora E-mail.

A central server authenticates all student, faculty, and staff logins, and a single login provides access to a wide range of servers and applications. Once authenticated, users have access to all network resources defined for them and to their personal work spaces. NDS provides information about printers, application servers, and the groups to which users belong. Access to network resources is controlled by NDS, and a series of NLMs and utilities communicate with NDS to enhance and facilitate the entire login and authentication process. As a result, NDS has become the centerpiece of security, fault tolerance, and authentication--for NetWare servers as well as OS/390, UNIX, and Windows NT systems.

Background on Clemson Information Systems

A major goal of the Clemson network is to provide a "virtual" computing environment in which students, merely by identifying themselves to the network, gain access to a personalized array of services no matter where in the network they happen to be. A second goal is to provide faculty members with the comprehensive tools needed to introduce and use technology in their teaching, service and research. Finally, the network must enable Clemson to fulfill its role as a major public service provider to South Carolinians.

Most universities can claim to have networked computers. Clemson takes the definition of "networked" several steps further. Networks are frequently a conglomeration of semi-independent networks. Users connected to one of these sub-networks are typically known only to that sub-net and are not provided a view of, nor are they known to, the network as a whole. At Clemson there is an umbrella network to which users connect. Under this umbrella they are allowed access to a range of services across the entire network tailored to the individual.

Hardware Configuration

The Clemson network includes a mainframe, minicomputers, more than one hundred servers, and UNIX, Windows, and Macintosh workstations. Ethernet and Fast Ethernet are both used, with twisted-pair cable generally providing local connections to the backbone and FDDI connecting backbone components.

Technical Architecture

The following figure shows the basic topology for the Clemson University Network.

Figure 1: The Clemson FDDI backbone.

As shown in the above figure, the campus backbone uses 100 MBPS fiber optic, FDDI (Fiber Distributed Data Interface) technology. The backbone is composed of a central ring and two smaller rings. One small ring serves the College of Engineering and Science buildings and the other is essentially a point-to-point connection to Clemson Research Park. The Information Technology Center, the largest campus data center, is located in the Clemson Research Park. Building networks connect to the backbone at one of eight locations. Each of the locations is a fiber hub site, with a large Cisco router, serving all the buildings in that area of campus. Only TCP/IP and IPX protocols are allowed to transverse the backbone. A parallel OC-12, ATM backbone is being constructed to support Internet 2 networking requirements.

Clemson's data network is designed to minimize data leaving a building, so there is often a server located in the building to store commonly used applications and departmental data and to handle local printing.

There are over fifty of these servers in the network. Large computer labs usually have their own server because of the high traffic levels. Because everyone in the building shares this server and because many of the applications are fairly large, the server is usually connected to the Ethernet switch by a Fast Ethernet of 100 MBPS bandwidth. There is also a 10 MBPS or 100 MBPS switched Ethernet link leaving the building to connect to a backbone router.

The Ethernet switch also connects many 10BaseT hubs to the building network. In some locations, powerful workstations have their own switched Ethernet segment rather than sharing a segment within a 10BaseT hub. Hubs are set to transmit network traffic only for the Medium Access Control address of the workstation attached to each port in order to prevent snooping.

Workstations

Workstations are connected to the backbone by way of twisted-pair, 10BaseT, Ethernet cabling. The minimum configuration recommended for an Intel-based workstation is the following:

  • 100 MHz processor

  • 16 MB RAM

  • 1.0 GB hard-disk storage

  • 3.5" diskette drive

  • 3Com Ethernet network interface card (NIC)

Servers

Clemson's server hardware is constantly changing. Except for the personal data servers, which are Hewlett Packard NetServers, we build our own servers from the same components used by server manufacturers.

Personal Data Servers. These hold the home directories for all users on the LAN. They are currently the biggest and fastest server that HP builds. They are each capable of 2 GB of RAM and virtually unlimited disk space.

EMPLOYEDx are the servers that holds the home directories for all employees and miscellaneous users of the LAN at Clemson. They are running Novell's IntranetWare in an SMP configuration with dual Pentium-Pro 166 MHz processors. They have 512 MB of RAM and serves up approximately 50 GB of RAID-5 storage to a little over 10,000 defined users.

STUDENTDx are the servers that holds all student home directories. They are also running IntranetWare from Novell, but on dual Pentium-Pro 200 MHz processors. They have 768 MB of RAM and about 95 GB of RAID-5 storage for about 25,000 defined users.

Root Servers. These servers are dedicated to running NDS at Clemson. All workstations as well as other Novell Servers depend on these servers to be operational. Multiple root servers are placed strategically on the network to enhance performance and to offer fault tolerance.

The base configuration of these root servers is as follows: 200MHz Pentium Pro, 256 MB RAM, two 2-GB mirrored hard disks.

Group and Student Lab Application Servers

These servers are configured to hold collaborative data and applications for departments and workgroups at Clemson. They are secured through NDS and run Novell's IntranetWare. Their base configuration is as follows: 166 MHz Pentium, 128 MB RAM, multiple 4-GB mirrored hard disks.

NT Application Servers

These servers are configured to run turn-key application under Microsoft Windows NT. The only direct users of these systems are the people that administer the software systems on them. End-users access these applications through Web browsers.

Their base configuration is as follows: 166 MHz Pentium, 128 MB RAM, two 4-GB mirrored hard disks.

Large Computing Systems

OS/390 Mainframe. The OS/390 Mainframe is an Hitachi Data Systems Pilot 25 Enterprise Server running the OS/390 operating system. Clemson's mainframe has always allowed users to connect directly, whether to TSO or an application like the Student Information Services (SIS) or CU Explorer, a system of catalogs and indexes that provides information for Clemson University students, faculty, and staff; however, it also provides some common server functions like FTP, NFS, and ODBC. In the future, more server-style functions will be available: improved database access, a Web server, and perhaps some network-related services.

hubcap. DCIT's general purpose UNIX computer--called hubcap--is a SUN Microsystems HPC 3000 with 1.5 GB of main memory, six 275 MHz processors, and a refrigerator-sized RAID disk subsystem containing more than 135 GB of disk storage. It runs the Solaris 2.6 (SunOS 5.6) operating system. Userids are available for staff and students who apply.

The substantial resources of hubcap will also be used by people who are developing and configuring jobs and simulations that they will eventually run on Clemson's new "super computer"--a SUN 6000 with 4 GB of main memory, sixteen 275 MHz processors and a RAID subsystem similar to

NDS Tree Design

The LAN infrastructure is built upon Novell NetWare 4.1 and NDS. NetWare supports connectivity from DOS/Windows, Windows 95, Mac OS, Windows NT, OS/2, and UNIX. NDS is a distributed and replicated database that holds the object and security definitions about the network. NDS provides the users and the network administration staff with a logical view of the network that conceals the sometimes bewildering complexity of the actual physical topology and configuration.

NDS enables the network to appear as a single cohesive entity to the user. No longer is the view centered on file servers; as file servers and their volumes are just another type of resource on the network that the user may or may not want to access. With NDS, a user performs a single login to the network and is authenticated as necessary with respect to resources on the network.

Figure 2: The Clemson NDS tree.

NDS is structured and represented using the tree model. As shown in the above figure, the root of the tree is the organization name, CLEMSONU. Under the organization name are a number of organizational units. This is usually reflective of structure of the organization. Organizational units can themselves contains organizational units. For example, the organizational unit STUDENTS contains the organizational units A, B, C, and so on.

An example of this is shown with DCIT having org units of ISD, CSO, CTS, CSG, and APS. Org units are sometimes called "containers" since they may contain many types of objects such as users, servers, server volumes, groups, organizational roles, aliases, computers, printers, print queues, and user profiles. The NDS database is collectively referred to as "the tree."

The process of naming objects in the tree follows a "dot" naming convention that conforms to the X.500 standard. For example, the A container in Figure 2 can be referred to as ".a.students.clemsonu."

Designing the NDS tree is a subjective process. You can use the organizational model as shown above, or a geographic model if your organization is dispersed. The underlying objective in designing the tree is making the resources in it easy to manage. There are over 30,000 user objects alone in our tree, which makes Clemson one of the largest users of NDS in the world.

Given that we want the maintenance of userids to be handled by the Automatic Userid System (AUS), we have taken a hybrid approach to tree design. The clemsonu tree has two distinct flavors that complement each other very well: the first being the traditional organizational model discussed previously and the second being a categorical model based on user type.

Three organizational units are used at the organizational level to basically hold user objects. They are "students," "employee," and "misc." The students container holds all userids for students. Similarly, the employee container holds all userids for employees. The misc container was created to hold special userids that are not owned by a student or employee. Examples of these might be friends of the University, outside customers of DCIT, or miscellaneous system or test userids that are not expressly owned by a student or employee.

The students, employee, and misc containers each contain 28 org units; one for each letter of the alphabet and one for groups and printers, respectively. The containers for each letter of the alphabet hold users whose userid starts with that letter. For example, the userid "amie" belongs to an employee so that user would be in the ".a.employee.clemsonu" org unit. This is also referred to as that user's "context." The complete, or fully distinguished, name of the user is ".amie.a.employee.clemsonu." Userids that do not begin with an alphabetic character are placed in the "Z" container.

Because groups of users may have common management and/or security attributes, NDS provides the "group" object. The "groups" container holds them. These groups are maintained by Computer Resources. Users that need to make use of a group may either contact Computer Resources to have a group created and maintained for them, or the user may create and maintain the group himself in the organizational part of the tree. Users that choose to create and maintain groups themselves may obtain assistance from Computer Resources over the telephone or from Client Support. Groups may be requested by anyone, consisting of any set of users.

For example, a professor could request a group consisting of a set of student users that she wants to permit to access particular data on one of her group servers.

The "printers" container holds print queues designated to be serviced by printers located throughout the organization. Most print queues are available to all users. The print queues are serviced by print servers and printers that are located throughout the NDS tree. The printers group is centralized for easy access by users.

Also, all printers defined to NDS may be made accessible from other systems across campus such as OS/390, or any UNIX host. Similarly, there are print queues available for printing to printers connected to other systems.

The data servers discussed earlier, EMPLOYED and STUDENTD, are under the Employee and Students containers, respectively. These servers hold the home directories for all employees and students. This is a departure from the traditional approach of users having home directories on the departmental (group) server.

This is necessary since at this point a number of users do not have access to a group server. Other benefits of this departure are increased manageability, increased per user storage space, high-speed backup/restore capability, and the Hierarchical Storage Management (HSM) capabilities of these two servers, as well as increased assistance from Computer Resources. Also, as users move between departments and buildings, there is no data movement required. Students have a home directory disk quota of 20 MB per user. Employee and misc users receive a 100 MB quota by default. These limits may be increased on a per user basis by contacting Computer Resources.

The students container is also home to the student application servers, which are named student2-student6. They are all exact mirrors of one another and are, for all intents and purposes, read-only. They are placed strategically on the network, basically one per lab, and perform the task of serving up application software and data as well as Microsoft Windows to the lab workstations.

The lab workstations locate the nearest application server as the user logs in to the network. The workstation attaches to it for the purpose of obtaining applications and also attaches to the appropriate data server to give the user connectivity to his/her personal data. The data server is STUDENTD if the user is a student or EMPLOYED if the user is an employee or misc user. While the application server does serve Windows to the workstation, the user's home directory contains the configuration files for Windows and other application software available in the lab. This allows the user to control his/her own Windows and other software setup. The following figure shows the environment as seen by a lab workstation.

Figure 3: The environment as seen by the workstation.

In the case where an employee or misc user is using the lab, these configuration files are automatically placed in a subdirectory under the user's home directory. The name of this subdirectory is "win95.lab." It ensures that lab configuration files will not conflict with any other setup information that may be there for running software from some other location or configuration, such as the user's office.

As the employee or misc user performs the login and the profile login script executes, there are certain resources that the user is automatically connected to by way of drive mappings. Additional resources may be added, but these are the base standards that should remain a constant:

  • Drive U: maps to the user's home directory. Drive U is "you." Individual users control this space and have the authority to permit any user or group to access it. DCIT regularly backs up these home directories.

  • Drive Z: is a search drive that maps to general network utilities provided by Novell. Although necessary, since this is a drive in the search path, users usually don't need to be concerned with it.

  • Drive P: maps to a set of ready-to-run programs. Drive P is for "programs." These are applications that have been configured on users' behalf by DCIT to run from the server, requiring no installation. They are appropriately licensed, whether freeware or site license acquired.

  • Drive S: maps to a general shared space. Drive S is for "share." Each directory under drive S has a unique purpose, as shown below:

    • EVERYONE--this subdirectory is wide open. All users have all rights. This is really intended as a big scratch pad for users and administrators. Files or directories may be put here and optionally protected as desired. The caveat concerning EVERYONE is that the data is susceptible to automatic scratch after 48 hours, or sooner if a substantial percentage of the total available space is used within the period.

    • SOFTWARE--this subdirectory is a set of ready to install software maintained by Client Support. For example, if a user wants to install the latest 32-bit version of Eudora, this is where he or she can find the latest tested and supported copy of all free or site licensed software supported by DCIT. There are versions for each operating system where appropriate as well as 16- and 32-bit versions of most Windows applications.

    • SUPERUSR--this subdirectory is available only to users defined to the Technology Support Provider (TSP) group within NDS. It consists of information and tools provided by DCIT and others in the group to make the TSP's job easier.

    • ????????--there are a number of directories created at this level to hold shared data and applications for a group or set of groups. These are located here when there is no suitable group server available or one is not justified. Also, applications which are not site licensed, but used on a wide scale are installed here; an example being Microsoft Office.

Server and Network Resource Access

Of more than 100 servers on the network, there are five basic types:

Personal Data Servers

There are currently two of these--STUDENTD and EMPLOYED, as discussed above. On both servers, users can create personal Web pages. STUDENTD1, STUDENTD2, etc., are the NetWare servers that hold private data space for all enrolled Clemson University students. When a student logs in to the Clemson Novell network, the U: drive is automatically mapped to the appropriate server.

EMPLOYED is the Novell server that holds private data space for all Clemson University faculty and staff. When a Clemson employee logs into the Clemson Novell network, the U: drive is automatically mapped to this server.

Faculty/Staff Group Servers

There are many of these. They hold collaborative data and applications for faculty and staff in colleges, departments, and/or workgroups. A group can also make use of this collaborative storage space to serve Web pages to the Internet without having to run a Web server locally. A faculty member may use these servers to do collaborative work with students in a class as well as accept secure file submissions from students.

Individual departments throughout the University often have their own applications servers from which department employees may run software purchased by that specific department.

Lab Application Servers

There are also many of these. They support the public and departmental labs by serving up general purpose and teaching applications to workstations in the labs. The STUDENTx servers are the application servers from which all labs conforming to the campus standard lab configuration run their desktop software.

NDS Root Servers

There are three of these servers. They operate in the background, keeping the network running smoothly by synchronizing among themselves information about users and resources on the network and the security associated with them. Holding replicas is the exclusive role of these root servers.

NT Application Servers

There are a good number of these. These servers run turn-key applications that are mostly Web-based. For the most part, they operate in the background.

Printers

A number of Novell network printers are in the Students container. Each lab-specific printer is automatically mapped for students who are working in one of the DCIT-owned labs. Each of these printers shows up in the printer setup of each specific application as "Local Lab Printer" from a PC and as a printer icon on the desktop of a Mac. The printers can all handle either straight ASCII text or postscript.

Virtual Laptops

Over the past three years, DCIT 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 standard lab, at any time, and, through a single login have the workstation in front of them transformed into their own personally configured workstation.

On logging on 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 software such as Microsoft Office, Netscape Navigator, and Eudora electronic 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 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."

Each individual entering Clemson as a student, faculty member or employee is automatically assigned a computer user identifier (userid) and workspace on a server for storage of personal documents and data. A central server authenticates all student, faculty, and staff 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 workspaces. NDS provides information about printers that they can use, building servers where application software resides and the class and departmental groups to which they may belong. Users also have access to a campus-wide Post Office Protocol (POP) mail server for their mail.

To support a single userid and password combination across all software systems, Clemson has developed authentication software to run on Novell servers and a variety of clients. These clients include the OS/390 enterprise server, the central mail server and many Web servers. Clemson has developed a set of NLMs to accept requests from clients, and has also built hooks on various clients to redirect local user authentication and password changes to the NLM. The NLM runs on the three Novell root servers for fault tolerance and is multithreaded to handle simultaneous requests from many client systems.

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 email 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 on their personal user space. A novice Web user could type a simple document in Microsoft Word, save it (as HTML) to their PUBLIC.WWW folder in their user space, and it 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 Stats 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 email 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. The student does 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 today 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 it has, within two years, 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.

Software Available to Virtual Laptop Users

As this list shows, the Clemson network supports a wide variety of software.

DCIT-supported PC Lab Software

The following are supplied and supported by DCIT and are available in all of the DCIT PC labs on campus:

  • Microsoft Office 97 Professional

    • MS Word

    • MS Excel

    • MS Access

    • MS PowerPoint

    • MB Binder

    • MS Photo Editor

  • Netscape

  • Eudora E-mail

  • McGill TN3270 (SIS and OS/390 Mainframe and telnet)

  • WS_FTP

  • PC/SAS

  • CodeWarrior

  • VET95 Anti-virus

  • Novell NWAdmin

All 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.

On login:

  • SFLogin: by Netoria, a NetWare client extension, that provides contextless login. After the correct userid and password are entered, the login script is processed, and several processes are spawned in response to the script:

    • ISITCOOL: a Clemson-developed NLM and workstation client used by a workstation to decide which lab application server to use for the current session. A list of servers is 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 availabiliy of the server.

    • CUMAP: a Clemson-developed application, maps drives to servers based on the registry key set by ISITCOOL.

    • DATACOOL: provides fault tolerance in case a user's home directory is not available. If the server NLM does not answer the workstation query or returns a don't connect message, the workstation displays a message to the 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 is used to load the profile for the userid, set the Windows 95 start menu to a standard, and to set location-specific things, like print queue mappings. PCRDIST does a 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 U:

    • EDITREG (developed at Clemson) is used to change specific registry keys.

    • 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 userid's registry keys.

    • EDITINI (developed at Clemson) is the same as EDITREG, but for Windows .INI files.

    • NetWare 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:

  • TRAPSD, a utility in the Windows 95 system tray (from Pyzzo Software) intercepts any Windows shutdown message. It invokes PCRDIST.

  • PCRDIST (via REGDUMP) exports the userid's registry keys to 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 also happens:

  • PCRDIST returns the registry to a default state.

  • PCRDIST makes the directory/file structure on the computers HDD look like the image on the application server.

  • PCRDIST ensures any .INI settings, etc., 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 Lab Support group has always had a small staff in relation to the work we do. Therefore, our goal, second only to customer service, has always been "easy, flexible maintenance." We will often, therefore, take non-traditional routes to obtain our objectives. For example, we maintain much of each userid's Windows 95 profile ourselves rather than allowing Windows 95 to do it because it turns out to be more work for us to mesh Windows 95's mechanisms for profile management than to implement our own.

Unlike other departments around campus that might own general-use computer labs, Lab Support's view is very general. We implement for the campus as a whole, not the needs of particular departments or colleges. In response to new service requests, we 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, we provide solutions now for issues that arise later and can often leverage the manpower an expertise of local departments to implement specific instances of our general infrastructure.

For example, at present Lab Support must perform all software installations since the HDD image on the servers is just a copy of a workstation HDD. Now that many departments have labs that run DCIT's "standard lab image" the number of software requests has increased and the required turn-around time on installs has decreased.

Therefore, we are 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. We are moving toward providing an image infrastructure rather than providing the complete image ourselves.

Authentication

The Clemson network employs NetWare Directory Services (NDS) to provide authentication and access services across the 36,000-user network. NDS controls the resource access of each userid, including printers, data files, building server used for application software and departmental groups. Novell Print Services control most network printers, and uniform print services are available across all servers, including Solaris and OS/390. There are dedicated network servers to provide name services and backup of user work spaces.

To support a single userid and password combination across all software systems, Clemson staff members have developed authentication software to run on three Novell servers and a variety of clients. These clients include the OS/390 enterprise server, the central mail server and many Web servers. Clemson developed a set of Network Loadable Modules (NLMs) to accept requests from clients, and also built hooks on various clients to redirect local user authentication and password changes to the NLM. The NLM runs on three servers for fault tolerance and is multithreaded to handle simultaneous requests from many client systems.

Design and Development

In the past, the OS/390 mainframe has been the center of the computing backbone for security and availability at Clemson. However, if we were to try to use OS/390 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.

We have some experience with DCE, but widespread multi-vendor support has yet to be evidenced. Then we turned to NDS. While individual server failures had occurred, we had achieved 100 percent availability in the preceding months with NDS given the design of our 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, we sent two Systems Programmers to developer school at Novell in Provo. We 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.

We 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. The NLM 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 4: The base client code is the same for all platforms.

Authentication Using Three NetWare Servers

As illustrated, the base client code--authC--is the same for all platforms. The communication with the NLM--AUTHSERV.NLM--is carried out using BSD-based TCP sockets over IP. The hooks for the various clients are of course dependent on the OS. With the OS/390 system, we 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 the Figure 5.

Figure 5: 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 we provide debugged base code in the form most viable for each platform.

Client code now runs on a OS/390, Windows NT, Solaris, BSD UNIX, Linux and Windows 95 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 going production, we 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. This is particularly true 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 userid 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, any NDS object in the tree such as an Organizational Role. This is 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 OS/390 gathered statistics, 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 they have been using the password all semester, this problem is no longer with us. 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. Some users argue that when a password is compromised in a single userid/password system, it is compromised across all platforms. This is true. However, we have 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 /etc/passwd off of a UNIX system and runs crack against it if the UNIX system does not use the password file for authentication?

The 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 userid and password do not go across the wire in clear text.

We only allow trusted machines with trusted administrators to run the authentication client code. This is a philosophical hurdle that we as seasoned systems programmers had to overcome. In the past, we 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 userid/password combinations as he makes calls to the authentication server? Today, we must trust application programmers not to do this.

Future

In the future, we will be continuing to add functionality to the server to better leverage NDS in other environments. There are remaining items on the wish list from developers. We hope to add OS interfaces to additional systems. We will also be adding clients as new operating environments emerge. In the near future, we hope to integrate with Oracle as it is becoming a mainstay in database development in our data warehouse system. We still have an eye on DCE; if it matures we will make it a player, possibly adding the NDS based authentication server as a element of the DCE security server. A related goal is to provide for single login, so that once a user is authenticated to one system, he or she no longer has to supply a password to others, much like Netware 4.x works for multiple server access.

NLM Development at Clemson

DCIT has been a strong development shop for several years. Members of the Network Services 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):


NLM Name
Description

AUTHSERV

Locates user objects, checks passwords, checks security equivalences, andperforms a variety of other administrative functions; uses different hooks tocommunicate 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 isunavailable, 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

Future articles will offer in-depth discussions of some of these NLMs.

* 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.

© Copyright Micro Focus or one of its affiliates