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.
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.
All MR access points in the Network must be running MR27.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.
* MR27+ firmware is not supported on all MR models. Please refer to the to Product Firmware Version Restrictions
Supported Authentication Types
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.
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.
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.
Navigate to Wireless > Access Control and select the desired SSID from the dropdown on the top of the page.
Under Association Requirements select Enterprise with Local Auth
Under Authentication Configuration set Password Auth to Allow password authentication
Select the “Caching 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.
Add LDAP server IP or FQDN and port number the server is listening to for LDAP queries.
Note: The maximum of one LDAP server is currently supported. 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 for.
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.
Please 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.
Under Authentication Configuration set Certificate Auth to Allow certificate authentication
Select the Caching 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.
Ensure that the wireless devices are set to trust the certificate presented by the MR which is signed by a well-known QuoVadis Certification Authority. Note that users might get prompted to trust the QuoVadis CA when connecting to the SSID.
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 CN with LDAP and set the same settings noted in the previous section.
Note: If the Verify Certificate CN 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) is not currently supported.
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.
Please upload the Client Certificate CA certificate used to sign the client certificate in a form of 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
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, e.g. Android, 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.
This behavior is defined by an MDM solution. 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. 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.
Validating that your Clients Trust the New Root CA
Cisco established a test URL that you can use to check your device compatibility with the new certificate - https://cs-ident-test.cisco.com/
If you see the message below after following this link the verification was successful:
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.