Troubleshooting RADIUS   A

  This appendix provides hints and tips for troubleshooting the RADIUS authentication server and the RADIUS accounting server.

       Troubleshooting RADIUS Authentication

  Most RADIUS authentication problems occur because the server or client was not configured correctly, or because a step was omitted during installation. Carefully check the instructions in Chapter 2, "Configuring a RADIUS Server," and Chapter 3, "Adding a RADIUS Client," to ensure that the authentication server was properly installed and configured.

  If you have not solved the problem after reviewing the instructions in Chapter 2 and Chapter 3, read the troubleshooting suggestions in this section. Refer to Appendix B, "RADIUS for UNIX Error Messages," for information on specific error messages.

       Checking the radiusd Daemon

  1. Use radiusd -v command to display the version number.

  2. Verify that the /etc/raddb directory (or the directory you specify with the -d flag) contains the following files: dictionary, users, and clients.

  If you are using RADIUS menus, check the menus  subdirectory.

  3. Make sure /etc/radiusd is running.

  4. Use radiusd -x to view incoming and outgoing packets from RADIUS.

       Checking the PortMaster

  1. Make sure that security is on  for each port:

  Command>  set all security on

  Command>  save all

  Command>  reset all

  When security is on, the show  S0 command displays (Security)  in the Port Type field of its output.

  Note ¯ When you issue the reset all  command, all connections on serial and asynchronous ports are dropped. On the PortMaster 4, the reset all  command is issued to a slot; only active connections on that slot are dropped. For all PortMaster products, the console port is not affected by the reset all  command

  2. Use the show global command to verify the following:

  ¯ RADIUS server IP address is set on the PortMaster

  ¯ Secondary RADIUS server does not have the same IP address as the primary server

  3. Make sure that the PortMaster can contact the RADIUS server:

  Command>  ping Ipaddress

  4. Make sure the secret set on the PortMaster with the set secret  password command matches the secret in the  /etc/raddb/clients file on the RADIUS server.

  The PortMaster will not display the shared secret; however, you can set the secret again if you are not sure that it is set properly. If you update the shared secret, make sure to use the save all  command to save the shared secret in the PortMaster nonvolatile memory.

       Checking /etc/raddb/users

  1. Items in the user entries are case-sensitive. You must do the following:

  a. Verify the spelling and capitalization of each line of the users  file.

  b. Compare keywords against the /etc/raddb/dictionary  file to ensure that they are the same.

  2. Verify that the user can authenticate with a clear text password before authenticating with Auth-Type = System or Auth-Type = SecurID.

       Host Unavailable

  If a "Host Unavailable" message is displayed before a username is entered at the login prompt, then both  of the following conditions exist:

•  Autolog username was set on the port
•  Default host is not responding to the login service. The default host is either defined for the port or defined in the PortMaster user table for the user. The login service--rlogin  or telnet  or in.pmd --is either defined for the port or defined in the PortMaster user table for the user.

  If a "Host Unavailable" message is displayed after a username is entered at the login prompt, but before a password is entered, all  of the following conditions exist:

•  Username exists in the local user table
•  No password is associated with the username
•  Default host is not responding to the login service--rlogin , telnet , or in.pmd 

  If a "Host Unavailable" message is displayed after a username and password are entered at the login prompt, either  of the following conditions might exist:

•  Security for the port is disabled and the default host is not responding to the login service--rlogin , telnet , or in.pmd 
•  Security for the port is enabled and the default host is not responding to the login service--rlogin , telnet , or in.pmd 

  To verify that security is not enabled, enter the following command. If necessary, replace S1 with the port that you are using.

  Command> show s1 

  If (Security)  is not displayed in the Port-Type field, enter the following commands to enable security for the port:

  Command> set s1 security on 

  Command> reset s1 

  Command> save all 

       Invalid Login after 30-Second Wait

  If the PortMaster sends 10 access-requests at 3-second intervals and then displays an "Invalid Login" message, this message can indicate one of the following problems:

•  RADIUS is not running on the server.

    Verify that /etc/radiusd  is running.

•  The RADIUS server is not defined correctly on the PortMaster.

    Check the RADIUS server information using the following commands:

    Command> show global 

    Command> show netcon 

    Look for remote ports of 1645 or 1646 in the netcon  output.

•  No entry exists for the PortMaster in the /etc/raddb/clients  file. Verify this condition by editing /etc/raddb/clients  to verify the PortMaster hostname or IP address is correctly defined in the file.
•  radiusd  responses are not getting back to the PortMaster. Do the following:

    ¯ Examine the routing table on the RADIUS server host.

    ¯ Ping the PortMaster from the RADIUS server host.

    ¯ Run traceroute  on the PortMaster address from the RADIUS server host.

    ¯ Run traceroute  on the RADIUS server host from the PortMaster.

•  The PortMaster is ignoring radiusd  responses. This occurs when the access-accept or access-reject source address does not match the destination of the access-request packet--the IP address of either the primary or secondary RADIUS server. This is usually caused by one of the following:

    ¯ Multiple IP addresses are assigned to a single Ethernet interface on the RADIUS server host.

    ¯ Multiple Ethernet interfaces are enabled, and the RADIUS server is replying to a request from the PortMaster on an interface different from the interface that received the request.

    You can use the PortMaster packet tracing command ptrace  to determine where packets are being routed. See the PortMaster Troubleshooting Guide for more information.

       Turning on the Debug Function

  You can run radiusd -x  to display debugging output. RADIUS version 2.1 or later also enables you to use SIGUSR signals. You can turn on RADIUS debugging by sending a SIGUSR1 signal to radiusd . Sending a SIGUSR2 signal to radiusd  turns debugging off.

  1. Issue one of the following commands, depending on your version of UNIX, to determine the process ID for radiusd:

  %  ps ax | grep radiusd

  or

  %  ps -ef | grep radiusd

  If you are running RADIUS in single-threaded mode--radiusd -s --this returns a single process ID. If you are not running in single-threaded mode, this returns a process ID for the parent radiusd  authentication process and a process ID for the child radiusd  accounting process. You can signal the authentication and accounting processes separately.

  2. Send the desired signal to the process.

  To turn debugging on:

  Command> kill -USR1  processid

  To turn debugging off:

  Command> kill -USR2  processid

  The RADIUS server logs a short summary message of radiusd  activity when either message is sent and when radiusd  is exited.

  An example syslog  message might appear as follows (shown on two lines instead of one for legibility):

  Mar 19 23:10:50 ra radius[14870]: counters 5 8 / 2 4 / accept 4 reject 1 challenge 0 response 8

  This messages shows that the RADIUS server received the following:

•  5 packets on port 1645--unless the RADIUS port was specified differently by running radiusd -p  Portnumber
•  8 packets on the RADIUS accounting port
•  2 RADIUS proxy replies
•  4 RADIUS accounting proxy replies

  This message also shows that the RADIUS server sent the following:

•  4 access-accept packets
•  1 access-reject
•  0 access-challenges
•  8 accounting responses

  The following example syslog  message is a summary (shown on two lines instead of one for legibility) of memory allocation for each of the four major data structures that radiusd  uses:

  Jul 28 09:56:01 ra radius[19340]: memory usage=pair 8/35/4784 peer 0/0/0 req 1/4/570 buf 1/4/570

  The memory allocation is in the format x/ y/ z, where x is the number allocated but not yet freed, y is the high-water mark--the most ever allocated but not freed at one time--and z is the total number allocated.

       Result of Debug Output

  If debug output shows more than one access-reject packet sent for the same ID, check the following:

  1. Check the route back to the PortMaster; ensure that replies are getting to the PortMaster.

  2. Check to see if the RADIUS server host has more than one Ethernet port or multiple IP addresses are assigned to the same Ethernet interface.

  3. Check for packet filters between the RADIUS server host and the PortMaster filtering out the RADIUS return packets.

  4. On the PortMaster, use ptrace as follows to show packets returning from the host running radiusd.

  For ComOS versions below 3.7:

  Command> add filter r  

  Command> set filter r 1 permit udp src eq 1645 

  Command> set filter r 2 permit icmp 

  Command> ptrace r 

  Note ¯ ptrace  on a PortMaster only shows UDP or ICMP packets generated on the PortMaster itself if the PortMaster is running ComOS version 3.7 or later. Outgoing RADIUS access requests are not shown; however, returning packets are displayed. To turn off tracing, use the ptrace  command with no values. See the PortMaster Command Line Reference for more information.

  For ComOS version 3.7 or higher:

  Command> add filter r  

  Command> set filter r 1 permit udp src eq 1645 

  Command> set filter r 2 permit udp dst eq 1645 

  Command> set filter r 3 permit udp src eq 1646 

  Command> set filter r 4 permit udp dst eq 1646 

  Command> set filter r 5 permit icmp 

  Command> ptrace r ext 

  5. Check the source address of a packet during tracing.

  A multihomed RADIUS host might be using the wrong source address when replying to access-request packets.

  If debugging output shows an access-reject packet right away, check the following:

  1. Check the spelling of the username and password.

  The capitalization must match exactly.

  2. Check the log file.

  Check syslog  for errors from radiusd .

  3. Use the show table user command to verify that the user is not in the PortMaster user table.

  The local user table is always checked first during authentication attempts.

  4. If Auth-Type = System is not working, attempt to use a clear text password in the user profile.

  5. If Auth-Type = System is specified on a UNIX system that has shadow passwords, ensure that radiusd is run as root to access the shadow passwords.

  6. Verify the spelling, capitalization, and syntax of the /etc/raddb/users file.

  If radiusd  finds any errors in the user profile, it sends an access-reject message and logs an error to syslog .

  7. Check that the shared secret in  /etc/raddb/clients matches the one set on the PortMaster with the set secret command

  8. If you are using PMconsole 3.5 or earlier, ensure that the secret was not inadvertently erased.

  Pressing the Return  key with the cursor in the RADIUS Secret field of the RADIUS window erases the secret when the Save  button is clicked.Lucent InterNetworking Systems recommends using PMVision.

       Performance Degradation

  If you experience a degradation in RADIUS performance, consider the following two possibilities:

•  Non-RADIUS processes on the host machine might be using host resources. Review the recommendations in "Selecting a RADIUS Server Host" on page 2-1. Removing non-RADIUS services can free-up host resources.
•  User lookups take more time as the number of user profiles on the RADIUS server increases. Lucent InterNetworking Systems recommends caching user profiles when the users  file contains more than 500 users to increase the speed and efficiency of user lookups.

       Troubleshooting RADIUS Accounting

  Most RADIUS accounting problems occur because a step was skipped during installation. Carefully check the instructions in Chapter 3, "Adding a RADIUS Client," and Chapter 8, "Implementing RADIUS Accounting," to ensure that the accounting server was properly installed and configured.

  If you have not solved the problem after reviewing the instructions in Chapter 3 and Chapter 8, do the following:

  1. Verify the RADIUS accounting service directory, /usr/adm/radacct,  exists.

  2. Verify that the account used to execute radiusd has write permission to the RADIUS accounting service directory.

  3. Check the RADIUS version number.

  Run radiusd -v .

  4. Make sure that you do not have any other process bound to UDP ports 1645 or 1646.

  Kill radiusd  and use the netstat -a  command. Start radiusd  and use the netstat -a  command again.

  Note ¯ Note that some UNIX operating systems display the sockets symbolically as .radius  and .radacct  rather than .1645 and .1646.

  5. Use the show global command to verify that the IP address of the accounting host has been configured on the PortMaster.

  If it has not been configured, set it using the set accounting  Ipaddress command on the PortMaster, where Ipaddress is the IP address of the host running radiusd .

  6. Check syslog (auth.warning) for error messages from radiusd.

  During normal use, very few error messages should appear.

  7. Ping the PortMaster from the RADIUS server to check connectivity.

  8. If the previous suggestions do not solve the problem, run radiusd -x on the RADIUS server host and check to determine if accounting records are displayed.