Workshops

Plugging Holes With Remote Authentication

More users are accessing their workstations from home. Users might install Symantec Corp.'s pcANYWHERE on their workstations and dial in through an office phone line. But if the software was improperly configured, they have just created a major security hole that you may not be aware of--until it's too late. To make matters worse, dial-up connections usually add accounts for which users must remember passwords. The next thing you know, they're attaching Post-it Notes with passwords onto their monitors--once again compromising security.

Forcing users to keep track of multiple accounts obviously is undesirable, and managing these additional accounts is even more so. In an environment that supports thousands of users, dial-up authentication theoretically can duplicate LAN accounts. In reality, most organizations have separate LAN, Unix, mainframe and dial-up user databases. Multiply the number of accounts by at least four. Now, add the cons tant turnover of accounts. You cannot adequately maintain a secure network if user accounts aren't accurate, or if disgruntled former employees have access to your network.

While you must keep carefu l track of user accounts, you shouldn't have to maintain multiple copies of each one. In a dial-up situation, the remote-access servers answering your calls should seek higher ground to verify a user's identity from an existing account database. These servers should provide centralized authentication, some sort of configurable access control and a robust accounting facility to provide an audit trail.

We investigated several remote-node authentication technologies at our Syracuse University lab in Syracuse, N.Y., including remote-access servers from Ascend Communications, Bay Networks, Shiva Corp. and 3Com Corp., as well as host-based servers such as Microsoft Corp.'s Remote Access Server (RAS) under Windows NT 4.0 and Novell's NetWare Connect 2.0. We found that although there are options available that provide authentication for LAN services, these solutions lack across-the-board support from remote-access vendors and aren't flexible enough for an enterprisewide setting.

Seeking Higher Ground T he remote-access servers we tested offer some support for local user lists as the lowest common denominator for user authentication. But these solutions don't scale to enterprise environments. The lack of central authentication and control makes it difficult to maintain more than a handful of dial-up accounts. The solution is to create a central authentication system and implement a protocol that will let the remote-access server talk to this system.

Of the remote-access devices we tested, we found four authentication protocols: Novell authentication against a NetWare Bindery (or Novell Directory Services through Bindery Emulation); Microsoft authentication against an NT Domain; Extended Terminal Access Control Access System (XTACACS) against Unix accounts or an independent database; and Remote Authentication Dia l-In User Service (RADIUS) against Unix accounts or an independent database.

Ideally, dial-up authentication should use existing user accounts, be they NetWare, Windows NT or Unix-based. Althou gh support for each network operating system does exist, we found serious shortcomings in Novell and NT authentication systems. It's tempting to look to Novell and NT as authentication solutions, however, we found that support is far from standard on all remote-access servers, and their functionality is limited when compared with full-fledged authentication systems like RADIUS and XTACACS.

Novell and NT Authentication The easiest way to integrate dial-up authentication into your network is to place an authentication system on existing servers. This is the solution offered by both Novell and Microsoft to satisfy small-to-medium-scale remote-access needs. Microsoft's RAS ships as part of NT Server 4.0 and runs as an NT service. Novell's NetWare Connect is a server-based NetWare Loadable Module (NLM) that is sold as an add-on to NetWare 3.12 and 4.1. Both authenticate users against user accounts through the network operating system, making configuration a snap. Setting up authentication on these two systems was as easy as installing the software, plugging in a modem and dialing in.

Two of the remote-access servers we tested also support NetWare and/or NT authentication. Shiva's LANRover/E Plus and 3Com's AccessBuilder 4000 can query a NetWare bindery. The 3Com unit also supports NT Domain authentication (using a simple gateway service installed on the NT server). We found that the two provided seamless access to existing LAN accounts on our test network, but they lacked meaningful access control. Shiva's bindery lookup requires users to be in a specific dial-in or dial-out user group; we couldn't find any access-control functions on 3Com's NT authentication service.

These four services may provide the answer for dial-up authentication in an NT- or NetWare-based network, but they don't adequately scale to an ent erprisewide implementation. None, for instance, will provide you with any sort of advanced session configuration, such as connection type--shell, Serial Line IP (SLIP) or Point-to-Point Prot ocol (PPP)--nor will they let you build in extra intelligence, such as limiting logins to a certain time of day or class of users.

The Third Tier When supporting dial-up infrastructures on a large scale, it is worth stepping up to XTACACS, TACACS+ or RADIUS. These protocols are designed to provide the authentication, access control and accounting functions necessary in a large enterprise environment.

By default, all the products we tested support local account databases; however, each can be configured to act as a gateway to an external authentication system. Such a gateway creates a three-tier architecture: The user authenticates against the remote-access server and the server queries the authentication server, which in turn queries an external service, such as Network Information Service (NIS), NIS+ or Kerberos (see "A Robust Implementation With TACACS or RADIUS" on page 120).