Network Computingwww.networkcomputing.com

However, this model breaks down when authenticating against a back-end user directory such as an NDS tree or NT domain. CHAP must use a plain-text copy of the user's stored password to validate the authenticating user's response to the server's "challenge. " Unfortunately, most NOSes and directories store users' passwords in a one-way hash, which stops the RADIUS or TACACS+ server from extracting the original password to validate the response. A standard network access server login prompt or PAP (Password Access Protocol) obtains the user's password in clear text, where it can be verified against the back-end directory.

Let's See Some ID (Authentication) Depending on your network, simple user name and password authentication might be sufficient, or one-time passwords and handheld security tokens might be the norm. Either way, the dial-in authentication protocol ties scores of network-access servers to a single, secure authentication system. Both RADIUS and TACACS+ can act as an authentication system (using a central user database) or serve as a proxy to external authentication systems. Through these protocols, a network access server can authenticate against an enterprise system--such as NDS trees, Windows NT Domains or Unix-based NIS maps--or third- party token-based security systems like AXENT Technologies' Defender or Security Dynamics' ACE/Server.

Dial-in authentication systems can implement several layers of abstraction to the ultimate user authentication service. Even the smallest remote-access environments served by a single network access server can benefit from a centralized authentication system. Why maintain a first-tier authentication system of internal user lists when the network access server can directly query an IntranetWare or Windows NT server for second-tier user authentication? Likewise, small-to-medium-sized remote-access centers maintaining multiple access servers can use RADIUS or TACACS+ to access back-end authentication third-tier systems. Finally, fourth-tier, or proxy authentication systems, offer incredible levels of flexibility for the largest remote-access providers, primarily in terms of access control.

This has the advantage of simplifying the authentication process on the network access server side--servers simply po int to a common authentication server for all authentication requests and most session-configuration information. Using the RADIUS or TACACS+ server as a central point of administration means that back-end authentication services are effectively modular and independent of vendor support.

Hey You, Over There (Proxy) Larger enterprise remote-access centers and dial-up service providers face a dilemma. What happens in a NOS migration when some of your users are in an NDS tree others call an NT domain home, and the rest are stored in an NIS map? What if your dial-in environment is a service bureau that needs to authenticate against various clients' own user directories? Although these environments support a RADIUS or TACACS+ service, remote-access servers can't choose different authentication servers on a per-user basis. Network access servers can be configured to query multiple authentication servers, but they will fail over to another server only when the first doesn't respond. To solve this dilemma, proxy authentication lets the user specify a logical authentication server.

Preserving the centralized model of RADIUS authentication, servers like Funk's Steel-Belted Radius and Shiva's Access Manager can act as proxies to external RADIUS (target) servers (see "RADIUS Proxy Authentication," left). By default, RADIUS proxy separates a user's name from a logical realm with the "@" character. A login to a network access server with a user name of "chuck@nds" is redirected to the RADIUS server responsible for the "nds" realm where "chuck" is authenticated against the NDS tree. Upon successful target authentication, the proxy RADIUS server delivers a valid authentication response to the network access server. In addition, the central RADIUS server preserves its right to impose session parameters and other authorization policies. Those in the "nds" realm are PPP users with a three-hour time limit; users in a realm called "Unix" are configured for text-only terminal mode and are automatically connected to a Unix host via telnet from the network access server.