In large networks, security information can be scattered throughout the network on different devices. RADIUS allows user information to be stored on one host, minimizing the risk of security loopholes. All authentication and access to network services is managed by the host functioning as the RADIUS server.
RADIUS software from Lucent InterNetworking Systems--version 2.0 and higher--can be used with any communications server that supports the RADIUS protocol as long as you own at least one Lucent InterNetworking Systems PortMaster. For more information see the Software License Agreement at http://www.livingston.com/license.html .
RADIUS server software for UNIX platforms is distributed in source code format to Lucent InterNetworking Systems PortMaster customers. Using modifiable "stubs," RADIUS can be adapted to work with existing security systems and protocols. You adapt the RADIUS server to your network, rather than adjusting your network to work with RADIUS.
Note ¯ Lucent InterNetworking Systems does not support modified RADIUS code.
The RADIUS server stores security information in text files at a central location; you add new users to the database or modify existing user information by editing these text files.
RADIUS provides extensive accounting trail capabilities, referred to as RADIUS accounting . Information collected in a log file can be analyzed for security purposes or used for billing.
RADIUS determines whether users are eligible to receive requested services. Authentication information is stored in either a local users file or database cache, or accessed from external authentication mechanisms such as a UNIX password file, ActivCard ActivEngine database, or SecurID ACE/Server database.
Figure 1-1 RADIUS Authentication and Authorization
For example, when user bob attempts to log in to a PortMaster, the following authentication sequence takes place:
1. The PortMaster prompts bob for his username and password, and then compares the username-password pair to the PortMaster user table.
2. The PortMaster sends an access-request message to the RADIUS server if the following conditions are met:
¯ Username is not found in the user table
¯ Security for the port is set to on
¯ RADIUS settings are configured on the PortMaster
The access-request message contains the information necessary for the RADIUS server to authenticate the user.
3. The RADIUS server checks its users file to determine if an entry for user bob is present. For bob's login to be successful, a matching username or DEFAULT entry must be found.
4. User bob is either accepted or rejected:
¯ If a matching entry is found in the RADIUS users file, if the password requirement is met, and if all check items in the users file are matched by additional attributes in the access-request message, the RADIUS server sends an access-accept message to the PortMaster indicating that bob has been successfully authenticated. It also sends authorization information--reply items--about the services bob can access and configuration information about bob`s connection.
¯ If the password request is not satisfied or if other check items--specified in the RADIUS users file--fail, the RADIUS server sends an access-reject message to the PortMaster indicating that the authentication attempt has failed. The PortMaster terminates bob's connection attempt.
If third-party software--such as ActivCard or SecurID--is used, the user might be prompted for more information before being accepted or rejected.
Authorization controls access to specific services on the network by configuring the user's session. Once a user is authenticated, RADIUS reports to the PortMaster what a user is authorized (permitted) to access. For example, user bob might be authorized to use the Point-to-Point Protocol (PPP) for his connection, be assigned IP address 192.168.200.4, and have to filter his traffic using packet filters std.ppp.in and std.pp.out .
RADIUS accounting stores usage information for dial-in users. This information is often used for billing purposes. When the user is authenticated and the session has been configured according to the authorization information, an accounting start record is created. When the user's session is terminated, an accounting stop record is created. See Chapter 8, "Implementing RADIUS Accounting," for more information.
Proxy RADIUS enables your RADIUS server to forward authentication requests from a PortMaster or other network access server (NAS) to a remote RADIUS server and to pass the reply back to the NAS. This feature enables cooperating Internet service providers (ISPs) to handle dial-in service requests from each other's users. Corporate users can easily forward packets from local to remote networks.
You create a proxy file in the /etc/raddb directory on the forwarding server and, if necessary, on the remote server. Each line in the proxy file contains the hostname or IP address of a remote server, the secret shared between the forwarding server and the remote server, and the realm of the remote server in the proxy chain. Each entry can specify the ports the remote server uses for RADIUS authentication and accounting as well as certain keywords to affect server behavior.
Note ¯ Usernames with an embedded at sign (@ ) are treated as proxy realms.
The iPass protocol enables you to provide global roaming Internet access. To use iPass with RADIUS 2.1, you must do the following:
a. Register at the iPass, Inc. website, http://www.ipass.com/ .
b. Add the keyword ipass to the entries of the appropriate remote servers in your /etc/raddb/proxy file.
c. Run iradiusd instead of radiusd .
Note ¯ If you run iPass and ActivCard or Securid, for configuration information send email to firstname.lastname@example.org .
RADIUS now supports ActivCard authentication on the following platforms supported by ActivCard 2.1: AIX, HP-UX, Solaris, and Sun-OS. ActivCard authenticates users by means of dynamic passwords generated by a handheld token using the public Digital Encryption Standard (DES) algorithm. The RADIUS server can forward all requests specified by the user profiles to the ActivCard server. Perform the following steps to enable user authentication via ActivCard:
a. Install the ActivCard server on either the same host as the RADIUS server or on a different host.
b. Create the file /etc/raddb/config.aeg on the host where the RADIUS server resides.
c. Specify Auth-Type = ActivCard as a check item in the user profiles of all ActivCard users.
RADIUS 2.1 strictly complies with RFC 2139. The server discards unsigned accounting packets--packets with invalid request authenticator attributes--and logs an error message. If you want to use RADIUS accounting, you must run RADIUS 2.1 with ComOS 3.3.1 or later. You can use radiusd -o to run RADIUS 2.1 if you have noncompliant RADIUS clients. In this case, RADIUS logs unsigned accounting records and flags them with Request-Authenticator = None.
You can restrict the number of logins permitted to specified telephone numbers.
a. Install the RADIUS accounting and authentication servers on the same host.
b. Create the file /etc/raddb/vports with the format shown in the following sample file:
# Called-Station-ID Number of logins permitted
c. Issue the command radiusd -s to run the server in single-thread mode.
Note ¯ The virtual ports feature does not provide an exact control. Logins that occur before radiusd starts running are not considered in the count. Accounting records that are sent to the backup accounting server are not considered in the count. This feature cannot provide simultaneous login limits for individual users because it is based on Called-Station-Id rather than Calling-Station-Id.
RADIUS 2.1 supports RFC-compliant vendor-specific attributes, including the two new Lucent InterNetworking Systems attributes introduced in ComOS 3.8: LE-Advice-of-Charge and LE-Terminate-Detail.
The LE-Advice-of-Charge value is a string included in RADIUS accounting stop records generated by ComOS 3.8 or later. This string provides any advice-of-charge information passed along by the telephone company on the ISDN D channel.
The LE-Terminate-Detail value is a string included in RADIUS accounting stop records generated by ComOS 3.8 or later. This string provides a detailed description of the reason the session terminated.
The RADIUS 2.1 dictionary file uses the following syntax to define vendor-specific attributes that conform to RFC 2138:
# Vendor-Specific attributes use the SMI Network Management Private
# Enterprise Code from the "Assigned Numbers" RFC
# Livingston Vendor-Specific Attributes (requires ComOS 3.8 and RADIUS
ATTRIBUTE LE-Terminate-Detail 2 string Livingston
You can run radiusd -f Filepath to specify a password file other than /etc/passwd .
You can force the RADIUS server to bind to a specific IP address to listen for requests by running radiusd -i Ipaddress. You might find this useful if you are running RADIUS on a multihomed host or a host with a virtual IP address.
Note ¯ When using hosts that are multihomed or that have virtual IP addresses, remember RADIUS clients ignore replies that do not originate from the primary or secondary RADIUS server specified on the client.
The syslog message for many kinds of rejected access-requests now includes the Calling-Station-Id--if known--enabling you to track down where the failed login attempts are dialing from. Here is an example syslog message:
Jul 10 21:10:50 ra radius:unix_pass: password for "bob" at 5551234 failed
Failures are currently logged for unknown users and for failed logins where the user profile included Auth-Type = System.
Other syslog messages are more detailed, including the UDP port and RADIUS message ID for easier tracking. The following example syslog message shows a RADIUS packet being forwarded from UDP port 1093 and ID #139 for the source IP address to UDP port 1645 and ID #17 for the destination IP address:
Jul 10 21:10:50 ra radius:forwarding request from 192.168.96.6/1093.139 to 172.16.3.24/1645.17 for edu.com
You can turn on RADIUS debugging by sending a SIGUSR1 signal to radiusd . Sending a SIGUSR2 signal to radiusd turns debugging off. The RADIUS server logs a short summary message of radiusd activity when either signal is sent and when radiusd is exited. See "Turning on the Debug Function" on page A-5 for instructions.
Figure 1-2 RADIUS Directory Structure
Note ¯ PortMaster products use ports 1645, 1646, 1650, and 1651 by default; this is specified by ComOS and cannot be modified in ComOS versions prior to 3.8. If you change the port number as stated above, RADIUS might work with other network access servers (NASs) but cannot authenticate users or gather accounting data for accesses to PortMaster products unless they are running ComOS version 3.8 or later.
|1. Select a host to use as the RADIUS server.||See "Getting Started" on page 2-1.|
|2. Install the RADIUS server software on the host.|
|3. Configure client information on the RADIUS server.||See "Modifying the clients File" on page 3-1.|
|4. Configure the PortMaster as a RADIUS client.|| See one of the following:
· "Configuring the PortMaster Using the Command Line Interface" on page 3-2."
|5. Configure user profiles.||See Chapter 4, "Configuring User Information."|
|6. You can optionally define menus to enable authenticated users to select different login options.||See Chapter 5, "Configuring RADIUS Menus."|
|8. You can optionally install and configure ActivCard.1||See Chapter 6, "Installing and Configuring ActivCard."|
|7. You can optionally install and configure SecurID.2||See Chapter 7, "Installing and Configuring SecurID."|
|9. You can optionally install and configure RADIUS accounting.||See Chapter 8, "Implementing RADIUS Accounting."|
|10. You can optionally configure RADIUS proxy service.||See Chapter 9, "Configuring RADIUS Proxy Service."|