Hi Guam,  I am using both, I have two ssids, one ssid is using 802.1x with user/pass and local authentication with AP embeded radius. The other ssid is using 802.1x with Client TLS certificates and local authentication. The first ssid has to reach AD within a day to renew the kerberos tokens in order to authenticate, while the second ssid relies only on TLS cerificate validity and MDM devices enroled. So I do this to accomodate the loss of AD DCs in case of WAN remains down for more than 1 day. I had encountered the WAN to be down and I am provisioning a failover method for wifi. Internet was ok but the WAN to the AD DCs was down, so when tokens expired, nobody could associate anymore, even the internet was available.  ... View more

Hi Guac,  On Wireless Access control for the particular SSID, below on the Splash page, there is a setting called "System Manager Sentry enrolment" and this adds the MDM settings to your SSID access control. In my case I choose to allow only MDM enrolled devices to join this ssid even the TLS certificate is valid. So, yes, the Meraki MDM called Systems Manager manages my devices and therefore are valid to associate with ssid.  ... View more

Hi Boyan,  The short answer is no to the question of "using same SSID for enrolment and production";  The long answer is related to Wireless medium, for each SSID we have to configure an association and authentication method at creation, methods that are transmitted once a client wishes to associate. This limits the SSID to a single authentication method: in my case described, WPA2-PSK for enrolment or WPA2-Enterprise aka 802.1x with TLS certificates as means of authentication. So I can't create an SSID with two authentication options the client has to choose. The wired ports have the luxury of cascading authentication methods, 802.1x first, then MAB, then CWA (portal auth), if 802.1x fails to authenticate, then MAB can pickup, and so on, we can't do that on same SSID.    The authorisation part can be done as you described, so we can have different authorisation policies per device type after the authentication has completed, we can associate a certain VLAN, we can use external radius to override the VLAN association, apply dACL and so on, but only after the authentication has passed.  ... View more

Hi Boyan again,  Reading your post once more I think the question is oriented on enrolment, "how to onboard a device and connect it to this certificate based auth SSID for the first time". Well I think I will give it a try with an onboarding policy in MDM, where I will create the SSID from MDM and push a generic machine certificate from that MDM to the enrolling machine, just to see if it works. If it does, then we can have 2 steps, one SSID (preshared key) only for enrolment, then once it is enrolled, the cert is positioned and the user can switch to production SSID.  ... View more

Hi Boyan,  I just tested now on Windows10, I tried to login to the SSID before user login and I am being asked to choose a certificate but there is none available since I use a client certificate that is in user space. So in my case, the pre login connection to this SSID does not work.  Same goes in OSX, with client certificates.  But I think I can make it work with Windows Machine certificate in Local Machine certificate store. Since the settings I have will only check the validity of the certificate in respects to its Root, it should work fine.  Security wise this is a little bit too loose but in my scenario, in meraki I have a secondary check after association, if the machine is enrolled in MDM, so the certificate is used just to connect to the wireless eth, get an IP address then the MDM check kicks in.  ... View more

Ah that problem, yes,  The settings I use are :  ... View more

  Hey, I tried with the below settings and works like a charm. As long as the client certificates are in User Certificate store -> Personal, all is good.    ... View more

Hmm, interesting scenario, so this means any device enrolled in AD and with machine cert or user cert can join to the SSID ? is this the desired outcome ? I can give this a try with a windows machine that has client cert and try this out. ... View more

Yes, I am currently using one SSID with 802.1x Enterprise with username / password towards AD DC 2019; The users are stored in DCs, APs query the authentication directly to DCs, then store tokens. I red there is an option to use client certificate authentication and this can enforce user certificate and user/pass, or can leave only client certificate authentication. I personally haven't distributed the client certificates to all devices and most particularly Mac OSX or iphone/ipads. That is why I remained to user/pass scenario.  ... View more

My opinion is the following, with regards to ISE and radius server:  For established infrastructures, there is AD DCs, there is radius and the full control suite of a NAC. But for distributed branches, that connect over internet, internet outages can occur, so radius and LDAP/Kerberos will be missing, hence lack of authentication on the remote site.    With local authentication the branch can survive the downtime up to 24h, because it no longer relies on radius to be reachable between the Authenticator and the Authentication server (beaconing is around 30min to one hour). With this feature the AP stores the authenticated credential token for 24h and even the radius isn't available it can reuse that authentication token for that specific client. Ofcourse new clients cannot join if the wan is down.    In my case in particular I wanted to eliminate the Radius server completely, (ISE) and only rely on the direct connection of APs to the AD DCs, to store cached tokens. If AD is down, is also fine, 24h for authenticated clients. I you are right, we no longer need radius.    ... View more

Hi RLNG,  Radius is needed due to 802.1x protocol stack, EAPOL on the wireless side, then from the Authenticator (Wireless AP) to the Authentication server the protocol is radius/diameter; https://en.wikipedia.org/wiki/IEEE_802.1X  What MRs are doing with Local Authentication is internalising the radius part and become Authenticator AND Autentication server at the same time, so it can query the AD DCs directly over LDAP. So shortens the eap chain. Instead of client <-wireless EAPOL->  Authenticator <-Radius-> Authentication Server <-LDAP/Kerberos-> AD DCs it shortens to : client <- wireless EAPOL - - Authenticator - internal radius server - credential cache - LDAP -> AD DCs Or this is how I understood it and how it works for some time for me.  ... View more

Hy Philip, I am having a go on this feature since I have to move ISE local radius server and AD Domain controllers from the local LAN. It is the perfect usecase described by the Local Authentication. I red several times the documentation presenting this feature here : https://documentation.meraki.com/MR/Encryption_and_Authentication/Meraki_Local_Authentication_-_MR_802.1X   But the messages are confusing. I understand that Radius server should exist and Local Auth will only cache that authentication hash, but, I have running now an SSID_name with MyRadius (ISE) and AD DCs in backend. For Local Auth I need another SSID_name2, that I configured and have succesfully connected to AD DCs in backend, but there is no reference in this SSID config about Radius, only Radius accounting. So, I presumed, the secondary SSID_name2 will query ISE Radius as well, as long ISE radius is allready configured in the dashboard. It doesn't, I don't see radius requests coming from APs to ISE when I try to authenticate to SSID_name2 over Local Auth.   So, what I am doing wrong ? ... View more