Radius Client

  1. Radius Client For Windows
  2. Radius Client Test
  3. Radius Client For Windows
  4. Radius Client Server

The Cisco Meraki MR Access Points and MX Security Appliance allow a Splash Page to be configured, requiring users to interact with this captive portal before being granted network access. One configuration option for this Splash Page is to allow authentication with an existing RADIUS server on the network, so users must enter their domain credentials to get through the Splash Page.

Oct 10, 2020 Remote Authentication Dial-In User Service (RADIUS) is a network protocol that secures a network by enabling centralized authentication and authorization of dial-in users. Many applications still rely on the RADIUS protocol to authenticate users. RADIUS test client is an easy to use tool to simulate, debug and monitor RADIUS and Network Access Servers (NAS). Simulate RADIUS Authentication, Accounting and CoA/Disconnect requests for multiple devices and usage scenarios.

This article outlines the Dashboard and RADIUS configuration steps to use a RADIUS server with a sign-on Splash Page.

Supported RADIUS Attributes

When a sign-on Splash Page is configured with RADIUS server, authentication is performed using PAP. The following attributes are present in the Access-Request messages sent from Dashboard to the RADIUS server.

Note:Please refer to RFC 2865 for details on these attributes, additional notes for certain attributes are included below.

  • User-Name
  • User-Password
  • Called-Station-ID: Contains (1) the MAC address of the Meraki access point (all caps, octets separated by hyphens) and (2) the SSID on which the wireless device is connecting. These 2 fields are separated by a colon. Example: 'AA-BB-CC-DD-EE-FF:SSID_NAME'.
  • Calling-Station-ID: Contains the MAC address of the wireless device (all caps, octets separated by hyphens). Example: 'AA-BB-CC-DD-EE-FF'.
  • Acct-Session-ID
  • Framed-IP-Address
  • NAS-Identifier
  • NAS-IP-Address
  • NAS-Port-Id
  • NAS-Port-Type
  • Service-Type

The following attributes are honored by Cisco Meraki when received in an Access-Accept or Access-Reject message from the RADIUS server to Dashboard:

  • Session-Timeout: This is the maximum time in seconds that the given user's session will last. After that time, the user will need to log in (authenticate) again using their username and password. Only used in Access-Accept packets.
  • Idle-Timeout: This is the idle timeout in seconds. If the user does not transfer any data on the network for this amount of time, the user's session will end and they will need to log in (authenticate) again using their username and password. Only used in Access-Accept packets. This attribute is ignored if RADIUS accounting is not enabled on the network.
  • Maximum-Data-Rate-Upstream / Maximum-Data-Rate-Downstream: These are used to impose bandwidth limits, only used in Access-Accept packets. The values are the maximum rate in bits/second. See RFC 4679: vendor-specific (set Vendor-Id 3561). If these values are not present, Dashboard will use the Bandwidth limits that the user set on the Dashboard traffic shaping page as a default. If these values are set to '0', Dashboard will set the Bandwidth limit to unlimited.

Note: Maxiumum-Data-Rate-Upstream and Downstream must be specified in separate RADIUS vendor-specific attributes - if both values are specified in a single attribute, Dashboard will not honor them.

  • Filter-Id: This attribute can be used to convey a group policy that should be applied to a wireless user or device. The attribute type should match that which is configured under the Configure tab > Group policies page in the Cisco Meraki Cloud Controller. The attribute value should match the name of a policy group configured on that page.
  • Reply-Message: This is a message for the user that will be displayed inline on the splash page. It is allowed in Access-Accept and Access-Reject messages, but will only be shown to the user in the case of Access-Reject messages.

Note: Matching the Filter-Id RADIUS attribute with a Group Policy for sign-on splash is currently only for the MR and is in beta - please contact support to have it enabled for your networks.

Dashboard Configuration

The following instructions explain how to configure an SSID with a Splash Page using a local RADIUS server:

  1. In Dashboard, navigate to Wireless > Configure > Access Control.
  2. Select the desired SSID from the SSID drop-down menu.
  3. Set the Association requirement to Open (no encryption).
  4. Under Splash page, select Sign-on with and choose my RADIUS server from the drop-down menu:
  5. (optional) For Captive portal strength, choose Block all access until sign-on is complete.
  6. (optional) For Walled garden, choose Walled garden is disabled.
  7. Under RADIUS for splash page, click Add a server.
  8. Enter the following information:
    • Host - Public IP address of the RADIUS server.
    • Port - UDP port that the RADIUS server listens on for access requests, typically 1812.
    • Secret - RADIUS client shared secret (if a RADIUS server has not been configured yet, select a shared secret here and make note for later).

Note: RADIUS access request messages for a Splash Page will be sourced from Dashboard, not from the local Meraki devices. As such, the RADIUS server's private LAN IP address cannot be specified here.

  1. Read the instructions outlined in the IP addresses section and make adjustments to network firewalls if necessary. Make sure to take note of the RADIUS client IPs listed under Help > Firewall Info.

Testing RADIUS from Dashboard

Dashboard has a built-in RADIUS test utility, to ensure that all access points (at least those broadcasting the SSID using RADIUS) can contact the RADIUS server:

  1. Navigate to Wireless > Configure >Access control.
  2. Under RADIUS servers, click the Test button for the desired server.
  3. Enter the credentials of a user account in the Username and Password fields.
  4. Click Begin test.
  5. The window will show progress of testing from each access point (AP) in the network, and then present a summary of the results at the end.
    APs passed: Access points that were online and able to successfully authenticate using the credentials provided.
    APs failed : Access points that were online but unable to authenticate using the credentials provided. Ensure the server is reachable from the APs, the APs are added as clients on the RADIUS server.
    APs unreachable: Access points that were not online and thus could not be tested with.

The Test button does not exist for MX or Z-series networks.

RADIUS Configuration

While any RADIUS server can be used, the following configuration requirements are necessary for use with a sign-on Splash Page:

  • RADIUS must be configured to allow PAP (unencrypted authentication) as the authentication method when you are using the Sign-on Splash page feature with a customer hosted RADIUS server.
  • With PAP, user credentials are sent in plain text. However, in a Meraki network, user credentials are encrypted in an SSL tunnel when sent from the clients web browser to the Meraki Cloud.

  • The Meraki Cloud acting as the RADIUS client sends the username and password along with other connection specific data in a RADIUS Access-request to the RADIUS server you specified in Dashboard. For security, the Meraki Cloud encrypts the password using the RADIUS shared secret and an XOR function. This ensures the users password is never transmitted in plain text.

Note: Communication between the client and Dashboard is done through the Splash Page, which is encrypted using SSL.

  • Dashboard's IP addresses must be configured on the server as RADIUS clients/authenticators, with a shared secret. These IP addresses can be gathered in Dashboard from Help > Firewall Info.

Please refer to your RADIUS server vendor's documentation for configuration specifics.

Example RADIUS Server Configuration (Windows NPS + AD)

The following example configuration outlines how to configure an existing Windows 2008 server, running Network Policy Server (NPS) alongside Active Directory:

  1. Add Dashboard as a RADIUS Client.
  2. Configure a RADIUS Network Policy.

Adding Dashboard as a RADIUS Client in NPS

Since access request messages for a sign-on Splash Page are sourced from Dashboard, NPS must be configured to allow incoming requests from Dashboard's IP addresses:

  1. From the desktop of your Windows 2008 server, click Start > Administrative Tools.
  2. Click on Network Policy Server when it appears in the list.
  3. In the Network Policy Server console, navigate to NPS ->RADIUS clients and Servers -> RADIUS clients.
  4. Right click RADIUS clients and select New RADIUS client.
  5. Fill out the fields in the New RADIUS Client window.
    • Friendly name: Unique identifier for this client.
    • IP address: The IP ranges used by Dashboard (gathered in step 9 of Dashboard configuration)
    • Shared Secret: Secret configured in the RADIUS server value in Dashboard (used in step 8 of Dashboard configuration). This needs to be the same for each RADIUS client you add.
  6. Click OK.
  7. Repeat these steps for each of Dashboard's IP addresses, as specified on the Access control page in Dashboard:

Configure a RADIUS Network Policy in NPS

The following instructions explain how to configure a network policy in NPS, that will allow

  1. From the Network Policy Server console navigate to NPS > Policies > Network Policies.
  2. Right click Network Policies and select New.
  3. On the Specify Network Policy Name and Connection Type create a Policy name and verify Unspecified is selected in the 'Type of network access server:' drop down.
  4. Click Next.
  5. On Specify Conditions click Add and append Windows Group > Domain Users group from the Windows Active Directory domain, then click OK.
  6. Click OK, Review the conditions, then click Next.
  7. On Specify Access Permission select Access granted and click Next.
  8. On Configure Authentication Methods make sure Unencrypted authentication (PAP,SPAP) is the only method checked and click Next.
  9. Click No when presented when the Connection Request Policy help pop-up appears.
  10. Click Next on Configure Constraints.
  11. On Configure Settings find the section Network Access Protection, select NAP Enforcement.
  12. For Auto Remediation un-check the box Enable auto remediation on client computers and click Next.
  13. On Completing New Network Policy click Finish.
  14. Prioritize the policy by Right-clicking the policy you created and selecting Move up, placing the policy above any existing deny policies.
  15. Review the policy values in the right side of the console:

Error: The Meraki Cloud is having difficulty connecting to your RADIUS server

When Sign-on Splash-page is used with a RADIUS server, Dashboard must be able to communicate with the RADIUS server. Dashboard, which acts as the RADIUS client, sends authentication requests (RADIUS Access Requests) to the public IP address of the configured RADIUS server.

The source IP addresses used by Dashboard may change over time. As a precaution, Dashboard periodically tests the configured RADIUS server to verify accessibility. Specifically, Dashboard sends an Access-Request message with 'meraki-ping' as the username and 'ping-test' as the password. If the RADIUS server replies with an Access-Accept or Access-Reject, Dashboard knows the server is reachable.

In the event that Dashboard does not receive a response after 6 attempts (one every 20 seconds), it will assume the RADIUS server is unreachable and an email will be sent to the Dashboard administrator.

If you received this email, please verify the following:

  1. If the RADIUS server is protected by a firewall, ensure that Dashboard is able to access the server through the firewall using the IP addresses and port number specified in the email. A current list of IP addresses and the port number can be found in Dashboard on the Help > Firewall Info page.
  2. Dashboard's IPs must be configured as RADIUS clients on the RADIUS server using the same shared secret configured in Dashboard.
  3. Ensure there are no additional restrictions on the RADIUS server that would prevent it from responding to Dashboard ss the test Access-Request will not contain all attributes (such as Calling-Station-ID), see below for an example message.

RADIUS Accounting with a Sign-on Splash Page

RADIUS accounting can be used with RADIUS authenticated splash pages to provide information regarding when a client was authorized through the splash page, and later had that authorization cleared/expired. These messages are sent from Dashboard to the customer's configured RADIUS server.

Note: RADIUS accounting is only available by default with 802.1X authentication. To enable RADIUS accounting for splash page as well, please contact Cisco Meraki support. RADIUS accounting is not currently available on Splash Pages for Security Appliances nor Teleworker Gateways.

Accounting Overview

When RADIUS accounting is enabled, RADIUS 'start' accounting messages will be sent whenever a client is authorized through the splash page. These start messages are sent from Dashboard, typically from the same IP address as used for the authentication Access-request message. A ‘stop’ accounting message is generated when the client's splash authorization is manually cleared or expires based on the splash frequency.

The screenshot below shows a Wireshark packet capture of an example RADIUS ‘start’ message sent by Dashboard (using an IP address of 74.50.53.101) to a RADIUS server. When the RADIUS message is expanded, there are many parameters that show the information contained within the ‘start’ message. Some data has been obfuscated for security reasons.

The screenshot below shows a wireshark packet capture of a RADIUS accounting ‘stop’ message sent by Dashboard because the Splash frequency time of 30 minutes was reached. This means the client has to log in again through the Splash Page to continue using the network.

Configuration

The following instructions outline how to enable RADIUS accounting for a sign-on Splash Page:

  1. In Dashboard, navigate to Wireless > Configure > Access Control.
  2. Select the SSID currently configured to use RADIUS with a sign-on Splash Page.
  3. Further down the page, set RADIUS accounting to RADIUS accounting is enabled.

Note: If this option is not available, please contact Cisco Meraki Support to have accounting enabled.

  1. In the RADIUS accounting servers section, click Add a server and provide the following details:
    • Host - Public IP address of the RADIUS accounting server.
    • Port - UDP port that the RADIUS server listens on for accounting messages, typically 1813.
    • Secret - RADIUS client shared secret.

Note: RADIUS accounting messages for a Splash Page will be sourced from Dashboard, not from the local Meraki devices. As such, the RADIUS server's private LAN IP address cannot be specified here.

Data-Carrier Detect (DCD)

When enabling RADIUS accounting on a sing-on splash page with my RADIUS server, the option Enable data-carrier detect becomes available. If data-carrier detect is enabled, sessions will be revoked and accounted for whenever a client disassociates from a network. To allow clients to re-associate to the network without re-authorization, do not enable data-carrier detect. See also RFC 2866 Section 5.10.

Additional Resources

For more information on RADIUS and Splash Pages, please refer to the following documentation:

Contents

Introduction

Radius

The Remote Authentication Dial-In User Service (RADIUS) protocol was developed by Livingston Enterprises, Inc., as an access server authentication and accounting protocol. The RADIUS specification RFC 2865 obsoletes RFC 2138. The RADIUS accounting standard RFC 2866 obsoletes RFC 2139.

Prerequisites

Requirements

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Radius Client For Windows

For more information on document conventions, see the Cisco Technical Tips Conventions.

Background Information

Communication between a network access server (NAS) and a RADIUS server is based on the User Datagram Protocol (UDP). Generally, the RADIUS protocol is considered a connectionless service. Issues related to server availability, retransmission, and timeouts are handled by the RADIUS-enabled devices rather than the transmission protocol.

RADIUS is a client/server protocol. The RADIUS client is typically a NAS and the RADIUS server is usually a daemon process running on a UNIX or Windows NT machine. The client passes user information to designated RADIUS servers and acts on the response that is returned. RADIUS servers receive user connection requests, authenticate the user, and then return the configuration information necessary for the client to deliver service to the user. A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers.

This figure shows the interaction between a dial-in user and the RADIUS client and server.

  1. User initiates PPP authentication to the NAS.

  2. NAS prompts for username and password (if Password Authentication Protocol [PAP]) or challenge (if Challenge Handshake Authentication Protocol [CHAP]).

  3. User replies.

  4. RADIUS client sends username and encrypted password to the RADIUS server.

  5. RADIUS server responds with Accept, Reject, or Challenge.

  6. The RADIUS client acts upon services and services parameters bundled with Accept or Reject.

Authentication and Authorization

Radius Client Test

The RADIUS server can support a variety of methods to authenticate a user. When it is provided with the username and original password given by the user, it can support PPP, PAP or CHAP, UNIX login, and other authentication mechanisms.

Typically, a user login consists of a query (Access-Request) from the NAS to the RADIUS server and a corresponding response (Access-Accept or Access-Reject) from the server. The Access-Request packet contains the username, encrypted password, NAS IP address, and port. The early deployment of RADIUS was done using UDP port number 1645, which conflicts with the 'datametrics' service. Because of this conflict, RFC 2865 officially assigned port number 1812 for RADIUS. Most Cisco devices and applications offer support for either set of port numbers. The format of the request also provides information about the type of session that the user wants to initiate. For example, if the query is presented in character mode, the inference is 'Service-Type = Exec-User,' but if the request is presented in PPP packet mode, the inference is 'Service Type = Framed User' and 'Framed Type = PPP.'

When the RADIUS server receives the Access-Request from the NAS, it searches a database for the username listed. If the username does not exist in the database, either a default profile is loaded or the RADIUS server immediately sends an Access-Reject message. This Access-Reject message can be accompanied by a text message indicating the reason for the refusal.

In RADIUS, authentication and authorization are coupled together. If the username is found and the password is correct, the RADIUS server returns an Access-Accept response, including a list of attribute-value pairs that describe the parameters to be used for this session. Typical parameters include service type (shell or framed), protocol type, IP address to assign the user (static or dynamic), access list to apply, or a static route to install in the NAS routing table. The configuration information in the RADIUS server defines what will be installed on the NAS. The figure below illustrates the RADIUS authentication and authorization sequence.

Radius Client For Windows

Accounting

The accounting features of the RADIUS protocol can be used independently of RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of sessions, indicating the amount of resources (such as time, packets, bytes, and so on) used during the session. An Internet service provider (ISP) might use RADIUS access control and accounting software to meet special security and billing needs. The accounting port for RADIUS for most Cisco devices is 1646, but it can also be 1813 (because of the change in ports as specified in RFC 2139 ).

Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, user passwords are sent encrypted between the client and RADIUS server to eliminate the possibility that someone snooping on an insecure network could determine a user's password.

Radius Client Server

Related Information