Selecting a RADIUS Server Host

  Primary RADIUS Authentication Server. Select or create a host with the following characteristics to use as a RADIUS authentication server:
    Secondary RADIUS Authentication Server.   Use  a secondary RADIUS server with the same security and performance characteristics as the primary server. Network Access Server queries secondary RADIUS Secondary Server if Primary does not respond. For example,  PortMaster always queries the primary RADIUS server first; if the server does not respond, it is queried a second time. Then both the primary and secondary servers are queried up to eight more times at 3-second intervals until one responds or until 3 seconds after the tenth query without a response. At this point, the login attempt fails.

  RADIUS Accounting Server.  If you implement RADIUS accounting, you must also select one or more RADIUS accounting servers. The RADIUS accounting server can be located on the same host as the RADIUS server used for authentication, or on a separate host.

  Secondary RADIUS Accounting Server.  You can define a secondary accounting server to serve as a backup if the primary server cannot be contacted. For example,  PortMaster always sends accounting packets to the primary RADIUS accounting server first, and retries it once every 45 seconds. If the primary server does not respond within 10 minutes, or if more than 50 accounting packets are waiting to be sent, the PortMaster sends the accounting packets to the secondary RADIUS accounting server.

How to install Radius

Get the radiusd distribution
untar the archive
compile the source
install binaries and configuration files

Adding a RADIUS Client

.
There are two steps to adding a RADIUS client:

  1. Modify the clients file to add the NAS and shared secret.

 2. Configure the following on the NAS and save the configuration changes.

 - Security enabled on all ports

  - IP addresses of the primary and optional alternate RADIUS authentication servers; optionally configure an authentication port number different from the default

  - IP addresses of the primary and optional alternate RADIUS accounting servers, if accounting is to be performed; optionally configure an accounting port number different from the default

 - RADIUS shared secret

       Modifying the clients File

  The clients  file is a flat text file installed on the RADIUS server. The clients  file stores information about RADIUS clients, including each client's name or IP address and its shared secret. Use any text editor to edit the /etc/raddb/clients  file.
 
  1. Verify that only root users have read and write access to the clients file.

 The clients  file contains the shared secrets for the RADIUS clients, and this information must be protected from unauthorized access.

 The permissions on a UNIX host look like this:

 -rw------- 1 root daemon 802 Jul 15 00:21 clients

  2. To add a client, enter the client's name or IP address and the shared secret. To add a comment line, start the line with the number sign (#).

 Shared secrets must consist of 15 or fewer printable, nonspace, ASCII characters. There is no limit to the number of clients that you can add to this file.

  Here are some examples of client names and shared secrets:

  #Client Name Shared Secret

  #------------------------------

  t1.dialup.afnog.org  wP40cQ0

  t2.dialup.afnog.org A3X445A

  192.168.1.2 wer369st

Use IP addresses to avoid the DNS lookup time entailed by using client names and possible incorrect name translation.

Client configuration lines on a cisco 2511 (t1.dialup.afnog.org)

aaa new-model

radius-server host 192.0.2.1

radius-server key wP40cQ0

Configuring User Information

  The RADIUS users  file is a flat text file on the RADIUS server. The users  file stores authentication and authorization information for all users authenticated with RADIUS. Each user must be represented by a profile  that consists of three parts: the username , a list of check items , and a list of reply items . The Figure 0 displays an example.
 

Figure 0 

       User Profile Format

  User profiles must be separated from each other by an empty line. The first line of a user profile consists of the username followed by the check items. The username is separated from the check items by spaces or tabs. This first line must not exceed 255 characters. All subsequent lines of the profile are individual reply items. Each reply item line must begin with a space or tab. Each reply item, except for the final line in the profile, must end with a comma.
  You can add comments to the users  file by beginning comment lines with a number sign (# ).

  Do not place comments within a user profile. Comments in a user profile prevent any reply item following the comment from being processed and sent to the client. Place comments either before or after the user profile. The contents of each user profile are case-sensitive. Definitions for all attributes and values are in the dictionary file and can be viewed with any text editor.  Modifying the contents of the dictionary file incorrectly can cause RADIUS to fail to authenticate users correctly or cause other problems.
  Username.  The username is the first part of each user profile and must start in the first column. Usernames consist of up to 63 printable, nonspace, ASCII characters. If ActivCard, SecurID, or a system password file is used for authentication, the username must conform to any limitations imposed on the username by the host.

  Do not use white space within a username. In RADIUS 2.1, access-requests are rejected if the username contains a space or tab. If a user enters a username with trailing spaces or tabs, the access-request is rejected.
  Check Items.  Check items are listed on the first line of a user profile, following the username and separated from it by white space. The line in the user profile that contains the username and check items must not exceed 255 characters. Check items must be separated by commas. Do not place a comma after the final check item. For an access-request  to succeed, all check items in the user profile must be satisfied by information from the access-request or by related information from the local system, such as group membership in the access-request.
 
   If no check items are included in the user profile, the user is rejected.
  Reply Items.  Reply items are placed one per line. Each line begins with white space. Each line ends with a comma, except for the final reply item. Reply items give the NAS authorization information about the user's connection--for example, whether PPP or SLIP is used or whether the user's IP address is negotiated. In Figure 0, Framed-Protocol is a reply item. The value of Framed-Protocol is PPP, indicating that bob uses PPP for his connection.

       Matching User Profiles

  When a user logs in, the RADIUS server searches the users  file for a matching profile. The following components of a profile must match the access-request for authentication to occur:
  The username matches if any  of the following conditions are met :
 The password matches if it is identical to that entered by the user. The password can be stored locally in the profile or remotely in a separate file. If you use an additional level of password security, you can specify the additional password authentication step in the profile.
 All check items specified in a profile also must be present in the access-request packet or satisfied by local system information, for a match to occur.

       Editing User Profiles

  User profiles are maintained in the users  file. On a UNIX host, use any text editor to edit the /etc/raddb/users  file.

       Default User Profiles

  When the RADIUS server receives a login name from a NAS, the server scans the users  file for a matching username, starting from the top of the file. If a match is located, RADIUS attempts to authenticate the user with the information in that user profile. If a matching user profile is not found during the scan, but a DEFAULT profile is located, RADIUS attempts to use the DEFAULT profile for authentication.

  You must place DEFAULT profiles at the end of the users  file. RADIUS stops scanning profiles when a matching DEFAULT profile is found and ignores any user profiles located after a DEFAULT user profile.

  In the following example, user bob's password is stored in a system password file. When he attempts to connect to the network, RADIUS scans the users  file to determine if it contains a matching user profile. If a matching profile is not found before the DEFAULT profile is found, the DEFAULT profile is used. Because the DEFAULT profile includes Framed-Protocol = PPP  as a reply item, PPP is used for bob's connection

  DEFAULT Auth-Type = System

  Service-Type = Framed-User,

  Framed-Routing = None,

  Framed-Protocol = PPP,

  Framed-IP-Address = 255.255.255.254,

  Framed-MTU = 1500
 

  RADIUS for UNIX 2.0 and later versions permit multiple DEFAULT user profiles. In place of a username, the first line of DEFAULT profiles start as follows:
 

       Check Items

  Check items are used to authenticate the user. Table 2 describes all check items that can be used in RADIUS user profiles. Called-Station-Id, Calling-Station-Id, and Connect-Rate can be used as check items only if the RADIUS client is capable of sending them in an access-request.
  Although it is not considered a check item, be sure that the username appears as the first item on the first, or check item, line of the user profile.
 

 
  Table 2 User Profile Check Items 
Item  Options  Explanation 
Auth-Type Local User's password is stored in the RADIUS users file. Default.

System User's password is stored in a system password file.

ActivCard User is authenticated via ActivEngine software

SecurID User is authenticated via ACE/Server software.

Reject User always fails authentication. 
Called-Station-Id String of numerals Telephone number called by user. 
Calling-Station-Id String of numerals Telephone number user is calling from. 
Connect-Rate String of numerals Maximum connection rate permitted, in bps. 
Crypt-Password User's password User's password is stored in UNIX crypt format. CHAP authentication attempts fail if Crypt-Password is used, even if the password is correct.
Expiration Must be specified in "Mmm dd yyyy" format Date that user's password expires.
Framed-Protocol PPP PPP is used for the connection. Can also be used as a reply item.
Group String of characters in double quotation marks (" ")  Groups that user belongs to. 
NAS-IP-Address IP address  NAS IP address.
NAS-Port Number The NAS port number that the user is dialed in to (for example, NAS-Port = S2).
NAS-Port-Type ISDN ISDN port.

Async Asynchronous port.

Sync Synchronous port.

ISDN-V120 ISDN in V.120 mode.

ISDN-V110 ISDN in V.110 mode.
Password String of characters in double quotation marks (" ") User's password.
Prefix String of characters in double quotation marks (" ") Removed from beginning of username before checking password.
Service-Type Call-Check Authenticates the user at the point of entry on a NAS before answering the call. The NAS must support an ISDN Primary Rate Interface (PRI). You must also configure the call-check feature on the NAS.

Framed-User User uses PPP or SLIP for the connection. Can also be used as a reply item.

Outbound-User User makes outbound connections via Telnet. Can also be used as a reply item.
Suffix String of characters in double quotation marks (" ") Removed from end of username before checking password

       Reply Items

  Reply items can authorize or apply any of the following: type of service provided, callback information, routing information, connection protocol, timeouts, port limits, menus, maximum MTU, filters, remote login information, and termination menus. Table 3 summarizes the reply items you can include in user profiles.

 
  Table 3 User Profile Reply Items 
Item  Options  Explanation 
Callback-Id Location name in double quotation marks (" ") Specify only for 
Service-Type = Callback-Framed-User. Location must be in NAS location table.
Callback-Number Phone number in double quotation marks (" ") Specify only for 
Service-Type = Callback-Login-User.
Filter-Id Filter name Filter name to be used for packet or access filtering on the interface.
Framed-Compression None If this reply item is omitted, Van Jacobson TCP/IP header compression is used.

Van-Jacobson-TCP-IP Van Jacobson TCP/IP header compression is used for the connection. Default.
Framed-IP-Address IP Address The user's IP address.
Framed-IP-Netmask Netmask The user's netmask.
Framed-IPX-Network Dotted decimal IPX network number IPX network number.
Framed-MTU Number  Number of bytes in maximum transmission unit (MTU).
Framed-Protocol PPP PPP is used for the connection. Can also be used as a check item.

SLIP SLIP is used for the connection.
Framed-Route Destination IP address The IP address of the destination network.

Gateway IP address The IP address of the gateway to the destination network.

Metric The number of routing hops to the destination network. Also known as the hop count.
Framed-Routing None Disables RIP on the interface.

Broadcast The interface sends RIP updates.

Listen The interface listens for RIP updates.

Broadcast-Listen The interface sends and listens for RIP updates.
Idle-Timeout In seconds Specifies the idle time limit for a session.
Login-IP-Host IP address Address of the remote host.
Login-Service Telnet Establishes a Telnet connection to the remote host.

Rlogin Establishes an rlogin connection to the remote host.

TCP-Clear Establishes a TCP clear connection to the remote host.

PortMaster Establishes a connection to the remote host using the PortMaster login service.
Login-TCP-Port TCP port number TCP port number of the Login-Service.
Menu Menu name in double quotation marks (" ") Defines a menu in a user record. 
Port-Limit Number of B channels for ISDN Multilink PPP or Multilink V.120 Specifies the maximum number of B channels a user can use.
Session-Timeout In seconds Specifies the time limit for a session.
Service-Type Administrative-User Grants user full access to all configuration commands.

Callback-Login-User Calls user back and connects via Telnet, rlogin , PortMaster, or TCP-Clear login service.

Callback-Framed-User Calls user back and establishes a framed connection (PPP or SLIP). Location must be specified in NAS location table.

Framed-User User uses PPP or SLIP for the connection. Can also be used as a check item.

Login-User User connects via Telnet, rlogin , PortMaster, or TCP-Clear login service.

NAS-Prompt-User Grants user limited access to commands (nonconfiguration only).

Outbound-User User makes outbound connections via Telnet. Can also be used as a check item.
Termination-Menu Menu name in double quotation marks (" ") Menu to display after service is terminated.

 

 

       Using RADIUS with PAP and CHAP

  You can use RADIUS with Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP).

 

       PAP

  The NAS sends the PAP ID and password to the RADIUS server in an access-request packet as the User-Name and User-Password. The NAS includes the Service-Type = Framed-User and Framed-Protocol = PPP attributes in the request as a hint to the RADIUS server that PPP service is expected.

  To authenticate a user with PAP, user profiles can include Auth-Type = Local, Auth-Type = System, or Auth-Type = SecurID.
 

       CHAP

  For CHAP, the NAS generates a random challenge and sends it to the user. The user returns a CHAP response, CHAP ID, and CHAP username. The NAS then sends an access-request packet to the RADIUS server with the CHAP username as the User-Name and with the CHAP ID and CHAP response as the CHAP-Password. The random challenge can either be included in the CHAP-Challenge attribute or, if it is 16 octets long, it can be placed in the Request Authenticator field of the access-request packet. The NAS includes the attributes Service-Type = Framed-User and Framed-Protocol = PPP as a hint to the RADIUS server that PPP service is expected.
  The RADIUS server does the following:
  CHAP requires that the user's password be available on the RADIUS host in unencrypted (clear text) format so that the server can encrypt the CHAP challenge and compare the result to the CHAP response. If the password is not available in clear text, the server sends an access-reject to the client.