Meraki Local Authentication - MR 802.1X

Last updated
Save as PDF

Overview

In large-scale deployments RADIUS servers are typically located in remote data centers (DCs) or otherwise off-site, requiring a working WAN uplink in order to reach these servers for authentication purposes and connect to 802.1X-protected SSID. This is especially true for retail environments where wireless point-of-sale (POS) devices require both the high security of the data transferred over the air provided by 802.1X authentication and high availability in the case of inability to reach RADIUS server(s).

The Meraki Local Auth feature provides an alternative authentication method to allow connection to 802.1X-protected SSIDs that does not rely on the reachability of the RADIUS server(s). This is done by running a built-in RADIUS server on MR access points and allowing MRs to act not only as Authenticator but also an Authentication Server – the role typically played by a RADIUS server.

When relevant servers are reachable, MR access points cache wireless clients’ authentication information. If wireless clients try to connect when servers are unreachable, the MR access point consults its cache to accept or reject the authentication.

Note: Alternative Management Interface can be used to communicate with the LDAP server only. It cannot be used to communicate with the OCSP server.

Username/Password Caching (Password Auth)

When enabled, the MR access point connects to the configured LDAP server to ensure the user exists and is authorized for WiFi access. It will then check the credentials presented by the user either against a password attribute received from the LDAP server or through an LDAP bind using the user credentials provided. It then caches a hash of the credentials used if the authentication is successful. This cache is referenced whenever a user tries to connect via 802.1X and the LDAP server is unreachable.

Certificate Caching (Certificate Auth)

The MR and client mutually authenticate each other using SSL certificates. MR uses the certificate signed by QuoVadis CA and the client uses the certificate signed by their own CA.

On March 31st, 2021 Meraki access points configured for Meraki Local Authentication transitioned to certificates signed by IdenTrust Commercial Root CA 1, instead of the QuoVadis Root CA 2.

To check the revocation status of the client certificate, you can (optionally) add a URL for the OCSP responder that will indicate if the certificate is revoked or not. To (optionally) check if the certificate belongs to a user or device that can use WiFi, you can add an LDAP server.

Instead of caching a password, MR will cache a hash of the client certificate if all configured checks pass, and the authentication is successful. When a wireless client tries to authenticate again but either the OCSP or LDAP servers are unreachable, the client certificate will again be verified against the configured CA certificate (in case it has changed), then the hash of the certificate will be compared against the "known good" certificate hash for that user in the cache. If the hashes match, the user will be authenticated. If neither OCSP nor LDAP verification is enabled, the MR never needs to consult any external servers, so no information is cached in this scenario.

Note: An external RADIUS server is not involved in this process and is not needed. The RADIUS server on the MR will handle 802.1X authentication instead.

local auth.PNG

Note: For password-based authentication, and for certificate authentication (if enabled), the MR will perform an ldapsearch using the username provided by the wireless client (supplicant) in the inner EAP tunnel, limiting the search to the base DN provided in the dashboard configuration. The search will look for accounts that have one of the following attributes equal to the username: sAMAccountName, uid, cn, or userPrincipalName.

If certificate-based authentication is used, the MR will additionally check that the provided username matches either the CN or userPrincipalName in the certificate, since the username would otherwise be unauthenticated.

Requirements

All MR access points in the Network must be running MR 27.1+ firmware*
An admin account credential for the LDAP server with read-only permissions has to be input as part of dashboard configuration
If an Active Directory-based LDAP server is used, it must support an LDAP bind operation
The LDAP server must support STARTTLS
CA certificate used to sign the LDAP server's private key must be uploaded to the dashboard. This certificate is used by an MR to verify the authenticity of the LDAP server.
The LDAP server’s certificate must have a subjectAltName field that matches the Host address configured on the dashboard (either IP address or FQDN)
Wireless clients must trust the certificate presented by the MR which is signed by a well-known Certification Authority QuoVadis for the purposes of validation of the MR for certificate-based authentication.

* MR 27+ firmware is not supported on all MR models. Please refer to the Product Firmware Version Restrictions.

Supported Authentication Types

Password-based

EAP-TTLS/PAP
PEAP-GTC

In both cases, communication between the MR and the wireless clients is protected by TLS. The default method is EAP-TTLS/PAP, as this is the most widely supported authentication method. Windows 10 and iOS require special configuration to use PEAP-GTC.

Note: EAP-MSCHAPv2 is not supported with Meraki Local Auth.

Certificate-based

EAP-TLS

Note: Currently we cannot check if a user’s account is locked or disabled in the Active Directory. In addition, it’s not possible to “pre-cache” specific clients only. By default, all clients will be cached.

Configuration

Please complete your LDAP server configuration first. Refer to your vendor documentation for detailed configuration steps.

At a minimum, the following tasks need to be completed and the following information should be gathered on your LDAP server:

LDAP server IP or FQDN and port number the server is listening to for LDAP queries
Create an Admin account with read-only permissions
Note the LDAP search base DN. In the example below Microsoft Active Directory is shown. In this example, “dc=ballena,dc=local” is the LDAP search base DN.

Create users accounts
Export the CA certificate used to sign the LDAP server's private key. PEM and DER formats are supported.

Password Authentication

Step 1. Navigate to Wireless > Configure > Access control and select the desired SSID from the drop-down at the top of the page.

Step 2. Under Security, select Enterprise with Local Auth.

Step 3. Set Password Authentication to Enabled.

Step 4. Enter the Cache timeout in seconds. By default, the timeout is set to 86400 seconds (24 hours). Please note that 24 hours is the maximum timeout that can be set.

Step 5. Add the LDAP server IP or FQDN and the port number the server is listening to for LDAP queries.

Note: A maximum of one LDAP server is currently supported. However, you can have different LDAP servers for different SSIDs. Secure LDAP (LDAPS) is not currently supported.

Next, provide the admin credentials for your LDAP server. This admin account only requires read access to your LDAP server.

Enter the LDAP search base DN that will be used as a point in the LDAP directory, below which the user accounts will be searched.

Note: The MR access point uses the configured LDAP server to authenticate supplicants (wireless clients), either using the password attribute read from the LDAP server, or by using the provided credentials to do an LDAP bind for the user and checking that it is successful.

When a wireless client successfully authenticates, the MR access stores a hash of the password used to authenticate, so if the connection to the LDAP server is lost, the MR can still authenticate wireless clients based on their last known good password. This hash is also accessible by other APs in the network because the client may connect to a different AP than where its last known password is stored.

Step 6. Upload the CA certificate used to sign the LDAP server's private key in the LDAP Server CA section so the AP can verify the LDAP server before sending the admin credentials to it. This is also important if we have to bind against the LDAP server to verify user credentials.

local auth2.PNG

Certificate authentication

Step 1. Navigate to Wireless > Configure > Access control and select the desired SSID from the drop-down at the top of the page.

Step 2. Under Security, select Enterprise with Local Auth.

Step 3. Set Certificate Authentication to Enabled.

Step 4. Enter the Cache timeout in seconds. By default, the timeout is set to 86400 seconds (24 hours). Please note that 24 hours is the maximum timeout that can be set.

Step 5. Ensure that the wireless devices are set to trust the certificate presented by the MR which is signed by a well-known IdenTrust Root Certification Authority. Note that users might get prompted to trust the IdenTrust CA when connecting to the SSID.

Step 6. If you wish to check if the certificate presented to the MR belongs to a user or device that is authorized to use Wi-Fi, set LDAP to Verify Certificate with LDAP and use the same settings noted in the previous section.

Note: If the Verify Certificate with LDAP option is set, only clients that previously successfully authenticated and verified with the LDAP server to be authorized for wireless access will be able to connect to the SSID. Any clients that have not been successfully authenticated and therefore not cached will be denied access to the SSID if the LDAP server is down. Secure LDAP (LDAPS) and the use of port 636 is not currently supported.

If the common name field of the certificate is configured with the FQDN of the LDAP server, then this should be configured on the dashboard instead of the IP address (The DNS server needs to be able to resolve the FQDN name of the LDAP server for this to work)

Otherwise, leave the LDAP option set to Do not verify certificate with LDAP. Note that in this case, any wireless device that presents a valid certificate will be able to connect to the SSID regardless of the permissions set for that device/user.

If you wish to check if the certificate presented to the MR is revoked, set OCSP to Verify Certificate with OCSP and set the OCSP Responder URL the MR can use to check the certificate against.

Step 7. Upload the Client Certificate CA certificate used to sign the client certificate in a form of a PEM or DER file.

Meraki Local Authentication CA Replacement - March 31 2021

In July of 2020, there was an industry-wide issue affecting the revocation abilities of certain CAs. Cisco has identified that the QuoVadis Root CA 2 used to issue trusted TLS certificates has been impacted and has been decommissioned. It is important to note that there is no security impact to this chain and its certificates: the root CA is being decommissioned as a result of rule changes stemming from the problem, and not due to any compromise of trust in the CA.

For additional explanation around this decision, refer to the section below - Background for CA Replacement

How Clients Can Handle a Certificate Signed by Previously Unknown Root CAs

When using 802.1X - Local auth, each AP uses it's own RADIUS server certificate to authenticate client. Every time a client connects to an AP, it receives the AP's RADIUS server certificate and if the client trusts it, it sends its credentials or its own certificate to be authenticated. The client must trust each AP's RADIUS server certificate on the network or its signing root CA (IdenTrust Commercial Root CA 1) in order to complete the authentication.

There are different ways your clients can handle a new certificate signed by a previously unknown root CA and presented by MR access point during mutual certificate authentication:

“Blindly” trust the certificate. Some devices, can be configured not to validate the server certificate at all.
Prompt user to trust a previously unknown certificate. Some devices (e.g. Windows and iOS) will alert the user any time they connect to a wireless network and see a certificate for the first time (either first time connecting, or a new certificate), and allow the user to proceed or not. Note that this is for the server certificate itself (e.i, the certificate presented by the MR acting as a RADIUS server), regardless of which root CA signed it.
Expect a certificate assigned by a specific CA only. Some devices allow specifying a CA that is authorized to issue certificates for a network, any certificate from this CA is accepted.
Expect certificates to be in the system store and have a specific domain. e.g Android devices have a UI option to trust any certificate with a specific domain from any CA in the root store. Use the domain radius.meraki.direct to do so.
This behavior is defined by an MDM solution, such as Systems Manager. Mobile device management can configure more complex settings for trusting certificates, including checking for a specific DNS name, specifying one or more root CAs that are allowed to issue certs for the network, etc.

Please note that the list above is not exhaustive and may not cover all scenarios and device types behaviors.

Actions Taken by Cisco Meraki

In order to prevent an undesirable behavior when wireless clients that are configured to trust on the old QuoVadis CA will not be able to connect certain MRs using the new certificates signed by IdenTrust Commercial Root CA 1 and prevent the creation of networks where MR access points have “mixed” TLS certificates (some signed by the new IdenTrust Commercial Root CA 1 and some still signed by the old QuoVadis Root CA 2), all MR access points connected to the Meraki cloud have been forced to update their certificates to the one signed by the new CA - IdenTrust Commercial Root CA 1 - as of March 31, 2021.

Meraki dashboard administrators of the networks affected by this change will be notified by the banners in the Meraki dashboard as well as by email.

After March 31, 2021, devices that are not configured trust certificates signed by the IdenTrust Commercial Root CA 1 are no longer be able to connect to Meraki local authentication-enabled SSID that’s configured for certificate authentication.

Actions Required by Meraki Dashboard Administrators

Please ensure that your wireless devices that connect to a Meraki local authentication-enabled SSID set to trust certificates signed by the IdenTrust CA.

Please ensure that that your clients that use certificate authentication have both certificates signed by IdenTrust Commercial Root CA 1 and by QuoVadis Root CA 2 in the certificate stores. The old certificate signed by QuoVadis Root CA 2 can be removed after March 31, 2021, if desired.

The majority of modern devices will have IdenTrust Commercial Root CA 1 in their certificate stores by default.

Note: Please consult vendor-specific documentation to determine the exact path to a device's certificate store or IdenTrust Commercial Root CA 1.

*Below is an example of the keychain store on OS X 10.15.

The new certificate can be obtained in the text format from IdenTrust's Commercial Root CA 1 page.

Please refer to our documentation to add a certificate via Meraki System Manager MDM solution.

Background for CA Replacement

When using the certificate caching (Certificate Authentication) option of Meraki local authentication MR access points and clients mutually authenticate each other using SSL certificates. Originally, 2021 MR access points used the certificate obtained from the Cisco PKI and signed by QuoVadis Root CA 2, and the client used the certificate signed by their own root CA.

Cisco PKI began issuing certificates signed by IdenTrust Commercial Root CA 1, instead of the QuoVadis Root CA 2, after March 31, 2021. Because MR access points rely on Cisco PKI to receive their certificates, it means that any MRs added to your Meraki dashboard network on or after March 31, 2021, with an SSID enabled for Meraki Local Authentication will receive a new certificate signed by IdenTrust Commercial Root CA 1, instead of the QuoVadis Root CA 2.

Certificates used by MR access points for certificate authentication are valid for one year since the MR access point is added to the network. It means that these certificates could be valid on MR access points currently present in your network after March 31, 2021 (assuming that MRs have been added to the network after March 31, 2020). However, any new MRs added to the same network will receive a new certificate from the Cisco PKI signed by IdenTrust which might result in some MRs having certificates signed by old QuoVadis CA and some having certificates signed by the new IdenTrust CA. This could lead to undesirable behavior when wireless clients that are configured to trust on the old QuoVadis CA will not be able to connect certain MRs using the new certificates signed by IdenTrust Commercial Root CA 1 and vice versa. Therefore, all MRs currently using a certificate signed by QuoVadis CA will get a new certificate signed by IdenTrust CA after March 31, 2021.