Remote Access Management with RADIUS

Simplify user authentication

Mobile users, virtual offices, and telecommuting aren't futurist fantasies in 1999. Many Windows NT network managers have installed RAS servers with modem pools in their networks to provide dial-in service to remote users for accessing corporate network resources. As the number of remote users grows, network managers need to add more modems and RAS servers to their networks, and companies spend more money on long distance and toll-free telephone service. At the same time, remote access media technologies continue to evolve. For example, asymmetric digital subscriber line (ADSL), wireless, and cable modems are replacing slower traditional modems. In the face of these changes, network managers need to create long-term RAS solutions. One viable solution is to outsource RAS to an ISP so that the ISP provides and hosts RAS for the outsourcing company. Outsourcing RAS has several advantages. First, remote users can dial up their ISP's local Point of Presence (POP) to reach their corporate network, which reduces long-distance charges. (In general, ISPs charge connection fees that are much less expensive than long-distance charges.) Second, network managers needn't worry about RAS server hardware upgrades. Third, with a good service level agreement (SLA), ISPs guarantee high service availability.

However, network managers face two areas of concern when outsourcing RAS: security and user account management. If RAS security isn't adequate, intruders can steal sensitive business data as it traverses the Internet. Without centralized user account management, users need an extra account, in addition to their corporate network account, to dial up an ISP. Network managers have no control over the way an ISP manages its user accounts. However, ISPs that have many POPs and RAS servers need centralized user account databases for user authentication; the alternative is to maintain user accounts on every RAS server.

Fortunately, two Internet technologies—network tunneling and Remote Authentication Dial-in User Service (RADIUS)—greatly reduce problems with security and user account management in RAS. Network tunneling—which PPTP, Layer 2 Tunneling Protocol (L2TP), and IP Security (IPSec) implement—protects network traffic by forming a secure channel between a remote machine on the Internet and a tunnel server in the corporate network. Many people refer to this technology as VPN. RADIUS lets an ISP's RAS servers forward user authentication requests to a corporate network through the Internet. The corporate network can use its existing user directory, such as an NT directory service, to authenticate users for both ISP and corporate network access. RADIUS thus removes the requirement of maintaining a separate user database for the ISP and buying individual user accounts from the ISP.

Windows 2000 (Win2K) and NT 4.0 support network tunneling and RADIUS. Tunneling technologies are well known in today's NT world. RADIUS, however, is relatively new in NT. In this article, I explore RADIUS and its functionality. I discuss Microsoft's RADIUS server software, which the company calls Internet Authentication Service (IAS). I don't discuss PPTP and other tunneling technologies in detail, but I look at how you can integrate RADIUS and VPN.

RADIUS User Management
RADIUS is an Internet protocol that Livingston Enterprises (currently Lucent Technologies Remote Access Business Unit) proposed in 1996 in the Internet Engineering Task Force (IETF—http://www.ietf.org) Request for Comments (RFC) 2058 and RFC 2059. Livingston redefined RADIUS in 1997 in RFC 2138 and RFC 2139. RADIUS contains three user management pieces—authentication, authorization, and accounting—which Livingston referred to as AAA.

RADIUS authentication identifies a remote user by checking the user's identity against a user account database. RADIUS supports such authentication methods as Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Microsoft's RADIUS also supports Microsoft CHAP (MSCHAP). Depending on the vendor implementation, RADIUS can authenticate a user with user account information in NT domains, Novell Directory Services (NDS), Lightweight Directory Access Protocol (LDAP) directories, Microsoft SQL Server databases, ODBC databases, and UNIX password files. For example, IAS Commercial Edition (IAS/C) supports NT domains, ODBC databases, Microsoft Commercial Internet System (MCIS) membership in SQL Server, and flat user file-based authentication.

RADIUS authorization restricts authenticated users' access to certain network services to ensure high network security. For example, you can set up a user authorization profile in RADIUS that lets only remote users access a specified server and service, such as a Telnet server and service.

RADIUS accounting records the amount of network resources (e.g., connection time, number of transferred packets) that a remote user uses during a specific session. ISPs can use the accounting information for billing needs and network traffic analysis. Corporate network managers can use the accounting information to verify ISP charges and allocate expenses to individual departments.

RFC 2138 (and the obsolete RFC 2058) define RADIUS authentication and authorization. RFC 2139 (and the obsolete RFC 2059) describe RADIUS accounting. RADIUS accounting is independent of RADIUS authentication and authorization, and you can use RADIUS without accounting.

RADIUS Client and Server
RADIUS is a client/server protocol. The RADIUS client passes remote user information (e.g., username, password) to a specific RADIUS server. The RADIUS server checks the user against a user account database (e.g., SAM) and sends either an accept or reject response to the RADIUS client. The client accepts or rejects the remote user according to the response the server sends.

The RADIUS client is often a RAS server (or network access server—NAS—in ISP terminology). The RADIUS server is often a dedicated computer at the edge or in the demilitarized zone (DMZ) of a corporate network. The user account database can reside in the RADIUS server or in a different machine. For example, you can install IAS as a RADIUS server on an NT domain controller that contains the domain account database locally, or on a member server that doesn't contain a domain user account database locally but authenticates users from its domain controller. A RADIUS server can also work as a store-and-forward machine to exchange messages between a RADIUS client and another RADIUS server. In this case, the forwarding RADIUS server is a RADIUS proxy server.

Figure 1 illustrates how the RADIUS client and server work together to process a user authentication. When remote user John of the ACME company wants to access ACME's network, he first dials the ACME ISP's local POP or NAS and tries to establish a Point-to-Point Protocol (PPP) link between his computer and the NAS. Before John can access the ISP, he needs to send the NAS his username and password for authentication. His username can be either a regular username such as John or a username with a realm. A realm is an identifier that represents a company or organization and attaches to a username as a prefix or suffix. For example, ACME's prefix realm is ACME/, and its suffix realm is @acme.com. If ACME and its ISP prefer suffix realms, John's username with a realm will be [email protected], which might be identical to his Internet email address and thus easy to remember. The NAS, which is a RADIUS client, sends an access request message containing John's user information to the RADIUS proxy server. The RADIUS proxy server checks the realm in John's user information and forwards the user information to ACME's RADIUS server. ACME's RADIUS server verifies John's account by checking the user account database through an appropriate access protocol—for example, using ODBC to access a legacy database, or LDAP to access an LDAP directory. ACME's RADIUS server responds to the RADIUS proxy server with an access-accept message or access-reject message. The RADIUS proxy server forwards the packet to the NAS, and the NAS either allows or denies John access to the ISP.

RADIUS proxy servers provide users with several advantages. First, an ISP need configure its customers' RADIUS server name and IP address only in its RADIUS proxy server, rather than in every NAS in its network. Second, a company that outsources RAS need configure only the ISP's RADIUS proxy server name and IP address, rather than every NAS name and address in its RADIUS server. Third, including realms in user accounts lets the ISP use one RADIUS proxy server to serve more than one company, thus saving hardware resources. Using realms, an ISP RADIUS proxy server can forward access requests to corresponding companies' RADIUS servers.

RADIUS uses a shared secret to authenticate a RADIUS client and server. You must specify an identical shared password when you configure a communicating RADIUS client and server pair. For example, if ACME configures the password abc for the ISP's RADIUS proxy server in the ACME RADIUS server, the ISP must also use abc as the password for ACME's RADIUS server in the RADIUS proxy server. Otherwise, the ACME RADIUS server and the ISP RADIUS proxy server can't authenticate each other.

RADIUS Attributes
The access-accept and access-reject messages that RADIUS servers return to their clients after verifying user accounts contain user authentication and authorization information and configuration details. RADIUS uses attributes in accept and reject messages to describe authorization and configuration. For example, the RADIUS attribute Framed-Protocol identifies which framed protocol a remote user can use to access the corporate network. You can often define or select a value for an attribute. For example, if you select PPP as Framed-Protocol's value, the NAS that receives this attribute will let the remote user use only PPP to connect to the corporate network.

RFC 2138 defined 43 RADIUS attributes. The IETF Internet-Draft "RADIUS Attributes for Tunnel Protocol Support" (draft-ietf-radius-tunnel-auth-06.txt) added nine attributes, which come into effect when RADIUS supports a tunnel protocol such as PPTP. Also, RADIUS lets vendors add proprietary attributes in RADIUS implementations. For example, Cisco defined the cisco-avpair attribute in the Cisco 6510 NAS, which the company uses to establish Layer 2 Forwarding (L2F) tunneling, Cisco's proprietary VPN connection. Microsoft predefined about 170 RADIUS attributes in IAS, which include basic attributes that RFC 2138 defined and Ascend Communications' RADIUS attributes. (Many ISPs use Ascend's NAS equipment.)

RADIUS server software such as Microsoft's IAS/C lets you define RADIUS profiles to contain various attributes and values to authorize remote users' access to a corporate network. For example, if you let only ACME's research department telnet a UNIX host 192.100.254.9 from the Internet, you can create a profile for the research department and add the following three attributes to the profile: Login-Service=Telnet, Service-Type=Login, and Login-IP-Host=192.100.254.9. Screen 1 shows this profile configured in the IAS/C server bigserver1.

If the research department users' ISP login names contain the realm @research.acme.com, ACME's RADIUS administrator can create the realm @research.acme.com and link the created realm to the ACME Research profile in ACME's IAS/C RADIUS server, a configuration that Screen 2, page 98, shows. When ACME's RADIUS server sees the realm @research.acme.com in a username that an NAS or RADIUS client sends for access authentication, ACME's RADIUS server inserts the realm's authorization attributes into the returning access-accept message after authenticating the user. The NAS or RADIUS client receiving the access-accept message will let only research users telnet the specified host from the Internet.

RFC 2059, the Internet document for RADIUS accounting protocol, defined 12 RADIUS accounting attributes. These attributes are straightforward. For example, attribute Acct-Session-Time specifies how many seconds a remote user is connected through the ISP in a specific session. RADIUS uses accounting attributes in RADIUS accounting messages instead of in access authentication messages; therefore, RADIUS accounting is separate from RADIUS authentication and authorization. In general, a RADIUS server can be an optional accounting server. An NAS or RADIUS client configured to use RADIUS accounting sends an accounting message to the RADIUS accounting server when a user session starts and completes. An accounting message can include the services that the user uses and statistical information related to the packets delivered between the user and the corporate network. The RADIUS accounting server writes received accounting information into an accounting database or log file. Depending on how RADIUS clients use accounting, log formats in accounting databases can differ from server to server. For example, a log might read: At 15:30:45 on 06/01/1999, NAS130.50.254.9 reports user [email protected] used its service to ftp host 192.100.2.3 for 500 seconds and transferred 1MB data to the host in session number 40.

RADIUS in VPN
An important VPN application is end-to-end network tunneling, which provides a secure remote access channel between a remote user and a corporate network over an ISP network or the Internet. Tunneling protocols include PPTP, L2TP, L2F, and IPSec. PPTP is well known in NT 4.0. Two types of PPTP tunneling exist: voluntary and compulsory. Voluntary tunneling is nonmandatory tunneling that depends on a remote user initiating and creating a tunnel. For example, a remote user can use PPTP in Windows OSs to establish a voluntary tunnel from a remote computer to a PPTP server in the corporate network after successfully logging on to the company ISP's NAS and corporate network. Voluntary tunneling is transparent to ISPs. In contrast, compulsory, or mandatory, tunneling requires an ISP to establish a tunnel between its NAS and the PPTP server in the corporate network every time a remote user connects to the corporate network. ISPs that provide PPTP compulsory tunneling must use PPTP in their NAS or RAS. Currently, several NAS or RAS server vendors, including 3Com, Ascend, and ECI Telematics, have delivered or are ready to deliver NAS or RAS server versions that support PPTP.

You can integrate RADIUS with PPTP to dynamically and automatically set up a compulsory tunnel from an NAS in your ISP to a PPTP server. On the RADIUS server, you need to configure authorization profiles using tunnel attributes and assign the profiles to corresponding realms and users. For example, if you want all remote users of the realm @acme.com to tunnel to PPTP server 192.100.254.2, you need to create a profile that contains at least these three attributes: Tunnel-Type=PPTP, Tunnel-Medium-Type=IP, and Tunnel-Server-Endpoint=192.100.254.2. Because PPTP runs only on IP, you have to set the attribute Tunnel-Medium-Type to IP. The new L2TP supports other transport media in addition to IP: for example, asynchronous transfer mode (ATM), Frame Relay, IPX, and X.25. The attribute Tunnel-Server-Endpoint is the desired PPTP server's IP address. You can include other tunnel attributes in the profile. For example, you can include a tunnel password to authenticate the tunnel server. After creating the profile, you assign it to the realm @acme.com.

Figure 2 demonstrates the process RADIUS uses to establish a compulsory tunnel between the ISP and ACME. For example, after John dials a local POP server to connect to his corporate network, his company ISP's NAS sends an access request to the RADIUS server in the corporate network through the RADIUS proxy server. When ACME's RADIUS server authenticates John, it sends the tunnel profile of the realm @acme.com with an access-accept message to the NAS through the RADIUS proxy server. The NAS establishes a PPTP tunnel to the PPTP server based on the received tunnel configuration information. The NAS also sends John's user information to the PPTP server. The PPTP server (which also works as a RADIUS client) will send ACME's RADIUS server an access-request message to authenticate John again. When the PPTP server receives an access-accept message from ACME's RADIUS server, the PPTP server establishes a PPTP tunnel to the NAS and lets John access ACME's corporate network through the tunnel. If you lack the second authentication of PPTP users, system intruders can establish a PPTP session with the PPTP server and use the tunnel to reach the corporate network.

Implementation of compulsory tunneling via RADIUS is still an Internet-Draft (draft-ietf-radius-tunnel-imp-04.txt). Microsoft led the draft's development. Also, on its TechNet CD-ROM, Microsoft published the white paper "Dynamic Compulsory Tunneling with RADIUS and PPTP (Windows NT Server 4.0)," which describes the company's vision of RADIUS in VPN.

Microsoft RADIUS
Microsoft supports RADIUS in NT Server 4.0 and has released both a commercial version (IAS/C) and a simple version (IAS) of its RADIUS server software. IAS/C is available in MCIS 2.0, and IAS is a component of Internet Connection Services for RAS in the NT 4.0 Option Pack. IAS/C is a full version of RADIUS and includes all RADIUS AAA and proxy server functions. IAS/C can authenticate remote users against NT domain controllers; the MCIS 2.0 Membership Security Database, which is based on SQL Server; any ODBC-compliant databases such as Oracle and Sybase; and flat user files. Microsoft refers to these constituents as authentication providers. In contrast, IAS has limited features, although it supports AAA. In IAS, you can use only NT authentication for user authentication. You can't add more authorization profiles, although you can edit the default profile. You can't create realms and link profiles to realms. If you want comprehensive RADIUS functions, therefore, you should use IAS/C; ISPs using IAS/C can take advantage of RADIUS proxy, profile, and realm capability. However, IAS can be suitable for your enterprise if you use only NT domain authentication and one profile for all your remote users.

Microsoft provides a RADIUS client in RRAS for NT Server 4.0. If you install the RADIUS client in RRAS, you can opt to authenticate users with the RRAS server or forward user authentication requests from the RRAS server to a RADIUS server. Win2K Server includes IAS and can function as both a RADIUS client and server.

Using Microsoft RADIUS
Installing Microsoft's RADIUS server software is easy. You can install IAS/C from the IAS directory on the MCIS 2.0 CD-ROM, and IAS from the Option Pack. Both IAS/C and IAS require Internet Information Server (IIS) 4.0. You can install IAS/C or IAS on a different server from the authentication provider. For example, if you install IAS/C or IAS on an NT member server and use NT domain authentication, the authentication provider will be the domain controller of the domain that the member server belongs to.

To configure RADIUS successfully, you must work with your ISP. First, make sure you define the correct port numbers for RADIUS communication: You and your ISP must use the same RADIUS port numbers in RADIUS servers and clients. The old RADIUS standards (RFC 2058 and RFC 2059) defined UDP port numbers 1645 for authentication and 1646 for accounting. However, the new standards (RFC 1812 and RFC 1813) define UDP port numbers 1812 for authentication and 1823 for accounting, because the old numbers conflict with the datametrics and sa-msg-port services. IAS/C and IAS use the older port numbers by default, but you can change the port numbers to follow the new standard if your ISP uses the new port numbers.

You can set up multiple RADIUS servers in your network for fault tolerance. Your ISP can define a RADIUS server group that contains your RADIUS server names or IP addresses in its RADIUS proxy server, then forward authentication and accounting information to the group. If the ISP's RADIUS proxy server can't reach the first RADIUS server in the group, it will try the next server in order. Be sure you and your ISP use the same password for RADIUS server and proxy server communication. Screen 3 shows that ACME's ISP created the ACME Radius Servers server group. This group contains two of ACME's RADIUS servers, which use the same password that ACME uses for its ISP's IAS/C RADIUS proxy server.

IAS/C lets you create realms and authorization profiles. When you create a realm in your RADIUS server, you can link the realm to an authentication provider as well as to an authorization profile. Screen 2 shows that ACME's RADIUS server authenticates its research users within the realm @research.acme.com by NT authentication and authorizes the users with the profile ACME Research. Screen 2 also shows that the RADIUS server will strip the realm name from the user account before asking the NT domain controller for user authentication. Your ISP needs to create the same realms you created in your RADIUS server in its proxy server, and must map the realms to your RADIUS server group. If you use realms and profiles in IAS/C, your ISP should forward user authentication with realms. If you use IAS, which uses only the default profile and NT authentication, your ISP needs to strip realms from user authentication before forwarding the user authentication.

IAS/C lets you use authentication providers other than NT when you have a large number of users. According to Microsoft, you can use NT authentication for fewer than 30,000 users, MCIS membership for a million or more users, and ODBC databases if the number of users is between 30,000 and 1 million. IAS/C provides preconfigured NT authentication and configurable ODBC database and MCIS membership authentication. You can also create a local user file (a flat file) in IAS/C, which can include individual users who don't belong to defined realms on the local server. When IAS/C can't match a user to a realm, it will try to authenticate the user from the local user file. You can link a user to a specific profile within the local user file. If IAS/C can't match a user in the local user file, it will try to authenticate the user via a default authentication provider. IAS/C uses NT authentication as the default authentication provider, but you can either change the default in IAS/C to another provider or disable the default authentication provider capability.

Both IAS/C and IAS fully support RADIUS accounting. You can use IAS/C or IAS as a RADIUS accounting server by enabling the accounting log, as Screen 4 shows. Both IAS/C and IAS can automatically create a new log file daily, weekly, monthly, or when a log file reaches a maximum size limit that you define.

Additional RADIUS Server Software
Microsoft's RADIUS server software is easy to use and implement and can scale from a small company to a large ISP, and IAS/C's flexible and robust features will help push NT to ISPs. Microsoft's Internet Connection Services for RAS can also help ISPs and enterprises better manage their POP phone books, automatically distribute the phone books to clients, create dial-up client installation files, and ease client software installation. However, I hope Microsoft will replace IAS in the Option Pack with the full version of IAS/C, or make IAS/C available for free download. Doing so will make Microsoft RADIUS more attractive and competitive.

Microsoft is not the only vendor in town with RADIUS server software for NT. At least seven other vendors have released RADIUS server software for NT. Some of these vendors offer multiplatform RADIUS server software and even open their source codes. Table 1 lists some of these RADIUS vendors, products, and Web links for your further evaluation.