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.
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.
¯ 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.
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.
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:
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.
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.
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.
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:
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:
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:|
|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."|