Search code examples
radiusfreeradiusradius-protocol

Test RADIUS configuration method

I'm developing a product that need to integrate with RADIUS server as an authentication method. When configuring the RADIUS server (IP Address, Port, Shared Secret) I would like to do a "test" in order to check that the configuration is valid - The server is available and it is indeed a RADIUS server, Shared secret is OK.

I did some research on how to do it, My options are:

  1. Send Access-Request message with fictional user name and password to the RADIUS server
  2. Send Status-Server message to the RADIUS server

RFC 5997 introduces the use of Status-Server Packets in the RADIUS protocol. This packet extension enabling clients to query the status of a RADIUS server. The Status-Server is marked as experimental and as Informational RFC rather than as a Standards-Track RFC

My questions are:

  1. Which are the most common \ in use RADIUS server vendors ? MS NPS, FreeRADIUS, Other?
  2. Are these vendors supporting Status-Server request - Do they implementing this packet type ?
  3. If i will use Access-Request, I will receive "Access-Reject" with a failure message in "Reply-Message" attribute. Can i understand the reason for the refusal from that text message? Is there any list of error codes\messages that are part of the Standard ?

Thanks a lot,

Yossi Zrahia

Solution

  • Ad 1) Exact (or even estimate) numbers are hard to come by, but you should expect to encounter FreeRADIUS, Microsoft NPS, Radiator and maybe Cisco ACS/ISE.

    Ad 2) FreeRADIUS, Radiator support it. Microsoft NPS and Cisco ACS/ISE do not. If your "test" is used once (upon configuring) I would use option 1 with the Access-Request. If you wish to periodically check the availability and configuration of a RADIUS server, I would suggest implementing both options and allow for configuration of the check as part of the RADIUS configuration:

        IP: 1.2.3.4
    Port: 1812
    Shared Secret: U7tr453cur3
    Servercheck: [x] Status-Server
                 [ ] Access-Request

    Ad 3) From RFC2865, section 5.18 (Reply-Message):

    "[...] This Attribute indicates text which MAY be displayed to the user. [...] When used in an Access-Reject, it is the failure message. It MAY indicate a dialog message to prompt the user before another Access-Request attempt. [...] The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters."

    There apparently are no standard messages specified; however if IP, Port or Shared Secret are configured incorrectly you should not get a response at all, because RFC 2865 specifies:

    "A request from a client for which the RADIUS server does not have a shared secret MUST be silently discarded."