Troubleshooting the RADIUS Server Service

If you need to troubleshoot the RADIUS Server service, enable message-level debugging. For information about enabling debug logging, see 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 also 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

This section offers solutions to issues that you might encounter when configuring communication between RADIUS clients and the RADIUS Server service. The solutions assume that you have enabled message-level debugging for the RADIUS Server service in AM and have access to the debug logs.

Client Cannot 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 is not enabled.

    An entry similar to the following in the Radius debug log indicates that AM's RADIUS Server was started: 

    amRadiusServer:10/12/2015 12:00:14:814 PM PDT: Thread[RADIUS-1812-Listener,5,main]:
TransactionId[27350419-8c21-429e-b580-35abf64604cf]
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 is not defined.

    An entry similar to the following in the Radius debug log indicates the inability of a client to connect: 

    amRadiusServer:10/12/2015 04:05:53:681 PM PDT: Thread[RADIUS-1812-Listener,5,main]:
TransactionId[270084d5-b7d0-42e4-8709-eeaeaf435aff]
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: Configuration setting handlerClass in RADIUS Client configuration named
'TestClient' is invalid. Requests from this client will be ignored.

    To fix the problem, correct the client configuration in the RADIUS Server service.

  • Traffic is not 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 AM RADIUS server to see where communication is lost.

Authentication Always Fails

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

  • The client secret configured for the client in the RADIUS Server service is incorrect.

    In an Access-Request packet, the shared secret is used along with the random value sent in the request authenticator field to encrypt the password field value that is passed across the wire. If the client and server's shared secrets are not identical, the password expected by the server will not match the password sent by the client, resulting in authentication always failing. The user's password is always incorrect in such a scenario and there is no way for the server to differentiate between the client secret being incorrect and the password sent from the client being incorrect. The log file indicates that AM has sent an Access-Reject packet to the client, similar to the action that would be taken if the shared secret matched on the client and server and the user entered an invalid password: 

    amRadiusServer:10/12/2015 04:27:55:785 PM PDT: Thread[RADIUS-1812-Listener,5,main]:
TransactionId[270084d5-b7d0-42e4-8709-eeaeaf435aff]
finalPacketType sent in response to auth request: 'ACCESS_REJECT'

    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 an invalid realm in the RADIUS Server service configuration: 

    ERROR: Unable to start login process. Denying Access.
com.sun.identity.authentication.spi.AuthLoginException: Domain is invalid|
invalid_domain.jsp

    If the realm is missing from the configuration, an error similar to the following appears: 

    ERROR: Unable to initialize declared handler class
'org.forgerock.openam.radius.server.spi.handlers.OpenAMAuthHandler' for RADIUS
client ''. Rejecting access.
java.lang.IllegalStateException: Configuration property 'realm' not found in
handler configuration. It must be added to the Configuration Properties for this
class in the Radius Client's configuration.

    To fix this problem, correct the client configuration in the RADIUS Server service.

  • The authentication chain configured for the client in the RADIUS Server service is incorrect.

    An entry similar to the following in the Radius debug log indicates an invalid authentication chain in the RADIUS Server service configuration: 

    amRadiusServer:10/12/2015 05:32:21:771 PM PDT: Thread[pool-5-thread-2,5,main]:
TransactionId[378a41cf-0581-4b62-a92f-be2b008ab4d3] ERROR: Unable to start login
process. Denying Access.

    If the chain is missing from the configuration, an error similar to the following appears: 

    ERROR: Unable to initialize declared handler class
'org.forgerock.openam.radius.server.spi.handlers.OpenAMAuthHandler' for RADIUS
client ''. Rejecting access.
java.lang.IllegalStateException: Configuration property 'chain' not found in
handler configuration. It must be added to the Configuration Properties for this
class in the Radius Client's configuration.

    To fix this problem, correct the client configuration in the RADIUS Server service.

Configuration Is Correct but Authentication Fails

In this case, you might have a client-specific problem. AM provides a tool that you can use to eliminate AM and its configuration as the cause of the problem. You can declare an alternate handler class implementation in the RADIUS Server service configuration. Two test handlers are available for troubleshooting purposes:

  • The org.forgerock.openam.radius.server.spi.handlers.AcceptAllHandler handler always returns an Access-Accept packet, indicating successful authentication for all requests.

  • The org.forgerock.openam.radius.server.spi.handlers.RejectAllHandler handler always returns an Access-Reject packet, indicating failed authentication for all requests.

In a case where you believe that configuration is correct but authentication always fails, you could specify the org.forgerock.openam.radius.server.spi.handlers.AcceptAllHandler handler class in the RADIUS Server service configuration for your client. With packet logging enabled, all requests received from the client should log packet contents traffic similar to the following even if the password is incorrect: 

WARNING:
Packet from TestClient:
  ACCESS_REQUEST [1]
    - USER_NAME : demo
    - USER_PASSWORD : *******
    - NAS_IP_ADDRESS : /127.0.0.1
    - NAS_PORT : 0

This is followed by: 

WARNING:
Packet to TestClient:
  ACCESS_ACCEPT [1]

If the client still indicates that authentication has failed, refer to the documentation for the client to determine why the Access-Accept response is rejected. Most likely, the client expects specific fields in the Access-Accept response that are not provided by AM. There is currently no facility in AM to return fields in Access-Accept responses.

Authentication Always Succeeds, Even With a Bad Password

This would be a very unusual situation, probably due to the org.forgerock.openam.radius.server.spi.handlers.AcceptAllHandler handler being left in place after troubleshooting an error scenario in which authentication always suceeds.

To resolve the problem, verify that the correct handler class is specified in the RADIUS Server service configuration for the client. If it is not specified, review the authentication modules in the chain that authenticates users and determine whether one of the modules might be accepting all authentication requests. This situation could also occur because of incorrectly-specified module criteria in the chain's definition.

Read a different version of :