Troubleshooting

To troubleshoot the RADIUS server service, enable message-level debug logging.

With message-level debug logging enabled, AM writes messages to the Radius debug log file when notable events occur, including the following:

RADIUS server startup
Changes to the RADIUS server configuration
Successful and unsuccessful client connections
Various error events

You can configure the RADIUS server service to log the packets sent between RADIUS clients and AM. To enable packet logging, use the Log Packet Contents for this Client property when configuring RADIUS clients in the RADIUS server service.

Solutions to common RADIUS server service issues

Use this information to help you troubleshoot if you encounter the following issues when configuring communication between RADIUS clients and the RADIUS server service. Make sure you’ve enabled message-level debugging for the RADIUS server service and have access to the debug logs.

Client can’t connect

When a RADIUS client connects to AM’s RADIUS server and hangs without receiving a response, the problem could be one of four possible issues:

The AM RADIUS server service isn’t enabled.

An entry similar to the following in the Radius debug log indicates that AM’s RADIUS server was started:
```
RADIUS Listener is Active.
Port              : 1812
Threads Core      : 2
Threads Max       : 10
Thread Keep-alive : 10 sec
Request Queue     : 10
```
If no such entry exists in the debug log, re-examine the configuration for the RADIUS server service and correct the problem.
The client isn’t defined.

An entry similar to the following in the Radius debug log indicates that the client can’t connect:
```
WARNING: No Defined RADIUS Client matches IP address /192.168.10.10. Dropping request.
```
To fix the problem, correct the client configuration in the RADIUS server service.
The handler class for the client is incorrect.

An entry similar to the following in the Radius debug log indicates an incorrect handler class:
```
ERROR: Unable to load Handler Class _handler class_
for RADIUS client testClient. Requests from this client will be ignored.
```
To fix the problem, correct the client configuration in the RADIUS server service.
Traffic isn’t arriving at the AM server.

No specific debug log entries appear for this problem.

This is likely a network communication problem. Investigate the route for traffic between the RADIUS client and the RADIUS server to see where communication is lost.

Authentication always fails

When authentication always fails, the probable cause is one of the following issues:

The journey configured for the client in the RADIUS server service isn’t compatible with the RADIUS protocol.

If the configured authentication journey succeeds in a browser but always fails when used by the RADIUS server, it’s likely it’s incompatible with the RADIUS protocol.

To fix this problem, review the guidance in Create an authentication journey and make sure your journey is compatible.
The client secret configured for the client in the RADIUS server service is incorrect.

If the shared secret on the client and the server don’t match, the server can’t decrypt the user’s password correctly, causing authentication to fail.

From the server’s perspective, this is indistinguishable from the user entering the wrong password. In both cases, the log file records a rejected request:
```
Rejected access request.
```
Since the shared secret is specific to each client, such messages might appear for one RADIUS client, while other clients can authenticate successfully.

To fix this problem, correct the configuration for your client in the RADIUS server service.
The realm configured for the client in the RADIUS server service is incorrect.

An entry similar to the following in the Radius debug log indicates the realm isn’t specified in the RADIUS server service configuration:
```
ERROR: AuthenticationStrategyFactory: Missing realm configuration.
```
To fix this problem, correct the client configuration in the RADIUS server service.
The authentication tree configured for the client in the RADIUS server service is incorrect.

An entry similar to the following in the Radius debug log indicates the authentication tree and realm combination specified in the RADIUS server service configuration doesn’t exist:
```
ERROR: AuthenticationStrategyFactory: Unable to find tree: RADIUS-ClientA-Journey in realm: alpha
```
To fix this problem, correct the client configuration in the RADIUS server service.

Configuration is correct but authentication fails

If you believe your configuration is correct but authentication still fails, you might have a client-specific problem. You can use a test handler to isolate the issue and confirm that AM is receiving requests and sending responses as expected.

AM provides two test handlers for this purpose:

org.forgerock.openam.radius.server.spi.handlers.AcceptAllHandler: Always returns an Access-Accept packet, indicating success. Use this to verify that the client correctly handles a successful authentication response from AM.
org.forgerock.openam.radius.server.spi.handlers.RejectAllHandler: Always returns an Access-Reject packet, indicating failure. Use this to verify that the client correctly handles a failed authentication response.

To test the client’s handling of successful authentication responses from AM:

Temporarily change the client’s handler class to org.forgerock.openam.radius.server.spi.handlers.AcceptAllHandler .
Make sure packet logging is enabled for the client, and send an authentication request.

You should see an ACCESS_REQUEST packet from the client in the Radius debug log:
```
WARNING:
Packet from TestClient:
  ACCESS_REQUEST [1]
    - USER_NAME : bjensen
    - USER_PASSWORD : *******
    - NAS_IP_ADDRESS : /127.0.0.1
    - NAS_PORT : 0
    - MESSAGE_AUTHENTICATOR : 0x00
```
Followed by an ACCESS_ACCEPT packet from AM to the client:
```
WARNING:
Packet to TestClient:
  ACCESS_ACCEPT [1]
```
If you see both packets in the log but the client still reports an authentication failure, the issue is likely on the client side. The client may be rejecting the Access-Accept response because it expects specific attributes that AM isn’t providing. Check the client’s documentation for its requirements.

If you don’t see the packets, it indicates a network communication problem preventing the request from reaching AM.
When you’ve finished testing, change the handler class back to the correct one for your client, for example, org.forgerock.openam.radius.server.spi.handlers.OpenAMAuthHandler.

Authentication always succeeds, even with a bad password

This would be a very unusual situation, possibly because the org.forgerock.openam.radius.server.spi.handlers.AcceptAllHandler handler is left in place after troubleshooting an error scenario in which authentication always succeeds.

To resolve the problem, verify that the correct handler class is specified in the RADIUS server service configuration for the client.

PingAM

Troubleshooting

Solutions to common RADIUS server service issues