Troubleshooting Radius problems on PAM
Article ID: 125413
Updated On:
Products
Issue/Introduction
Troubleshooting Radius problems on PAM. TCPDUMP
Environment
Release:
Component: CAPAMX
Resolution
The starting point in understanding how to troubleshoot Radius authentication with PAM is to understand the configuration.
The connection to the Radius server must be configured on the 3rd Party page. Before you can do this, you must configure a device for the Radius Server, a Target Application of Type "Radius/Tacacs+ Secret" and a Target Account to hold the Shared Secret.
The application will have to be set with type Radius and with the desired port. The default port is 1812.
The account name may have to match an account on the radius server, but with freeradius it is possible to name it anything.
Once the account is created, the account is configured into the Config --> 3rd Party --> Radius or Tacacs+ page. The Server, Application and Account fields must all be populated.
You can doubleclick the magnifying lens next to the account field and select the desired account. This will populate all 3 fields.
Next you will need to configure the user or users that will use Radius Authentication. If the users are LDAP users you will have to import the LDAP group and specify Radius Authentication be used.
You will also have to populate the Unique Attribute field with the LDAP field that holds the string that will match the user in the Radius server. This is commonly samaccountname=. If LDAP is not used, configure each user and set the Authentication Type to Radius. It may be possible to configure a User Group with Authentication Type set to Radius, and have the user entries dynamically created when the user logs in. That would require that the user be assigned to that group on the Radius Server.
The starting point for troubleshooting is to confirm that the configuration on PAM is correct. Make sure that the Shared Secret is correct and the Radius Server is reachable. Ping the server and make sure the port is open. The ping can be done from the Tools page, but Radius typically uses udp and PAM's Port Scan tool only does TCP.
It is possible for PAM Support to establish an SSH Debug session to your PAM instance, via a webex with you, and to execute nmap from the command line, as follows:
nmap -sU -p <your port> <your PAM address>.
Check that the Radius server is up and running and matches the configuration on PAM. This includes making sure that the radius server has PAM configured as a valid authentication agent, and that the user(s) are valid on the Radius Server, and still active in PAM. This includes checking that the user is still active in PAM and in LDAP. If using a Radius group, make sure that the user is a member of the group.
You should check the Session Log, but that will not likely have anything more than the message seen when the login fails.
If the steps above don't help it will be necessary to perform some additional steps, which may require that Support be engaged to connect with SSH Debug. First, change the Web Services Log Level to Debug and reproduce the problem. After duplicating the problem, download the system logfiles, logs.bin. Attach this to your support ticket, so that Support may check the php_error.log file that is included. The file may also be examined via SSH Debug. You can also obtain the Debug tcpdump patch, which will enable a tcpdump to be performed on PAM. Support can execute tcpdump from the command line, while duplicating the problem. If you want to analyze the trace in WireShark execute the command as follows:
tcpdump -s 0 -w /var/log/output.pcap
Once this is done, support can help you retrieve it from your system. One method is for Support to provide a control file that can be used to specify which files are to be included in the system logs archive. A second method is to use WinSCP to download the file, after making a private key connection to PAM, which also has to be done by Support.
Feedback
