Introducing RADIUS   1

       Introduction to RADIUS

  The Remote Authentication Dial-In User Service (RADIUS) is a client/server security protocol created by Lucent InterNetworking Systems. RADIUS is an Internet draft standard protocol. See RFCs 2138 and 2139 for more information on RADIUS.

  User profiles are stored in a central location, known as the RADIUS server. RADIUS clients (such as a PortMaster communications server) communicate with the RADIUS server to authenticate users. The server specifies back to the client what the authenticated user is authorized to do. Although the term RADIUS  refers to the network protocol that the client and server use to communicate, it is often used to refer to the entire client/server system.

       Overview of RADIUS Features

  RADIUS offers the following features:

•  Security

    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.

•  Flexibility

    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.

•  Simplified management

    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.

•  Extensive auditing capabilities

    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.

  The RADIUS for UNIX server version 2.1 is available in ready-to-run binary form for the following operating systems:

•  Alpha Digital UNIX 4.0
•  BSD/OS 2.0 and 3.0
•  HP-UX 10.20
•  IBM RS6000 AIX 4.2
•  Redhat Linux 5.0
•  SGI IRIX 6.3
•  Slackware Linux 2.0.30
•  Solaris 2.5.1
•  Solaris x86 2.5.1
•  SunOS 4.1.4

       How RADIUS Works

  RADIUS performs three primary functions. The RADIUS for UNIX server version 2.1 adds enhancements for ease of use.

       Basic RADIUS Functions

  The primary functions of RADIUS are authentication, authorization, and accounting. Figure 1-1shows the authentication and authorization process.

•  Authentication

    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

    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 .

•  Accounting

    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.

       Ease-of-Use Enhancements

  RADIUS 2.1 for UNIX provides the following enhancements to improve RADIUS functionality:

•  Proxy RADIUS

    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.

•  iPass protocol support

    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 support@livingston.com .

•  ActivCard support

    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.

    d. Run the daemon sradiusd  instead of radiusd .

•  Accounting signatures required

    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.

•  Virtual ports

    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

    9255550020 20

    9255550021 30

    9255550022 25

    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.

•  Vendor-specific attributes

    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

    #

   

    VENDOR Livingston 307

   

    # Livingston Vendor-Specific Attributes (requires ComOS 3.8 and RADIUS
  s# 2.1)

   

    ATTRIBUTE LE-Terminate-Detail 2 string Livingston

    ATTRIBUTE LE-Advice-of-Charge 3 string Livingston

•  Alternate password file

    You can run radiusd -f  Filepath to specify a password file other than /etc/passwd .

•  Address binding

    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.

•  Improved messages

    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[14870]: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[14870]:forwarding request from 192.168.96.6/1093.139 to 172.16.3.24/1645.17 for edu.com

•  Enhanced debugging

    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.

       Feature No Longer Supported

  The obsolete RADPASS feature is no longer available.

       RADIUS Directory Structure

  RADIUS server files are stored in the raddb  (RADIUS database) directory. The raddb  directory is typically placed within the /etc  directory. Lucent InterNetworking Systems recommends that you use this default.

  The raddb  directory contains files and subdirectories organized as shown in Figure 1-2 and explained in the list that follows. A dotted line indicates an optional file.

  Figure 1-2 RADIUS Directory Structure

•  The users  file stores user profiles, which consist of authentication and authorization information for all users authenticated with RADIUS.
•  The dictionary  file contains information used to parse user access requests and generate responses. It lists attribute numbers, names, and the data type expected for attribute values. Attributes appear in client-server communications and accounting records and are used to create user profiles. After you modify this file, you must restart RADIUS to apply your changes.
•  The clients  file contains the IP addresses of all RADIUS clients and the secrets shared between the clients and the RADIUS server(s).
•  The builddbm  utility enables you to convert the users  file into DBM format for faster look-ups.
•  The menus  subdirectory contains individual menu text files. You can optionally use menus to provide users with different login options once the users have been authenticated.
•  The proxy  file stores information about the remote servers to which the local server can forward authentication requests. This information includes the hostname or IP address, shared secret, and the remote realm.
•  The vports  file contains Called-Station-IDs and the number of logins permitted via each telephone number.
•  The config.aeg  file contains the configuration settings that specify how RADIUS connects to an ActivCard server. This optional file is needed only if you are using ActivEngine with RADIUS. See Chapter 6, "Installing and Configuring ActivCard," for more information.

  The RADIUS server uses the User Datagram Protocol (UDP) and the following UDP ports:

•  Port 1645 for authentication
•  Port 1646 for accounting
•  Ports 1650 and 1651 for proxy

  If different ports are assigned to these services in the /etc/services  file, RADIUS uses those ports in preference to the default ports listed above. You can also specify different UDP ports by using the radiusd -p  portnumber  command on UNIX hosts. Port 1812 is reserved for RADIUS authentication and port 1813 is reserved for RADIUS accounting. See Appendix C, "RADIUS Options," for more information.

  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.

       RADIUS Installation and Configuration

  Table 1-1 provides a quick overview of the tasks required to install and configure RADIUS.

  Table 1-1 Overview of RADIUS Installation and Configuration Tasks  

 

Task	Instructions
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.	· See "Installing RADIUS on a UNIX Host" on page 2-3
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."   · "Configuring the PortMaster Using PMVision" on page 3-4."
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."