Enterprise with Local Auth - how to generate Client Certificate CA

[LG]

Hello everyone! 

I was thinking of testing the Enterprise with Local Auth authentication method here at home, but I wonder what would be the correct way to generate/upload the Client Certificate CA and generate client certificates...

Mac user here..

Thanks in advance,

LG

[PhilipDAth]

Are you going to use a RADIUS server to authenticate the user certificates?

The "Local Auth" system is only for caching responses so the system can continue to allow people on who have previously been on.

https://documentation.meraki.com/MR/Encryption_and_Authentication/Meraki_Local_Authentication_-_MR_8... 

[LG]

Thanks for replying Philip!

I was not going to use Radius.. What if you don't configure the certificate verification? It isn't mandatory in the config and as such, there isn't a field to enter any radius server (well, only accounting, but not mandatory as well)

With that said, in the end, with this config below in mind, the AP does not know what are the users or certificates that it needs to validate? 

[PhilipDAth]

This config only works when you use a RADIUS server.  It caches the RADIUS server saying to allow (or deny) access.  There there is no RADIUS server to give the response, there is nothing to cache.  Only the cache is used to say weather access is to be granted or not.

[LG]

What about this? 

"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."

It just seems that, if I upload the Client Certificate CA and the client certificate matches the one uploaded, the MR will accept the client, not having to previously cache anything from an external radius..

Doesn't make sense? At least it is a way to interpret the documentation about Certificate Caching/Auth. Even the 

[adiaron]

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_8...

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 ?

[RLNG]

Did you figure it out?

[RLNG]

Hi Philip, 

I was looking into this option as well & it clearly says on the article 

"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."

So why do we need the RADIUS server?

[adiaron]

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. 

[RLNG]

Thank you for the response. But from what I read LDAP is an optional setting. Are you using this option currently? We don't have ISE but were NOT planning to use the MS RADIUS Server either. I was hoping this option allows EAP-TLS auth to take place locally without being dependent on anything else on the backend. Any thoughts? 

[adiaron]

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. 

[RLNG]

Thank you. We are planing to move away from the user/pass model and strictly use EAP-TLS(Certificate) only. That's why I was thinking Meraki can handle this locally without depending on LDAP or RADIUS server. Do you know if that is the case?

[adiaron]

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.

[adiaron]

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. 

[RLNG]

I tried uploading the cert into a new ssid but it's giving an error "WPA Encryption is incompatible with association type". WPA is selected as WPA2 only

Update:

Actually, it turned out to be a new dashboard version issue. Once I changed it back to the old version it worked. 

[adiaron]

Ah that problem, yes, 

The settings I use are : 

[Boyan1]

@adiaron One quick question if you don't mind: does the windows device connect BEFORE any user is logged in; or does a user need to login do Windows first, and then SSID association takes place? I'm asking the classic question of chicken-and-egg; does a user need to login ONCE by Ethernet first, so credentials are cached and then 802.1x  works consecutively or does your solution permit first-time-ever login to Windows?

[adiaron]

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. 

[Guac55]

"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. "

--> How are you doing this secondary check? Does Meraki has the capability to do this check natively with MDM or are you using something like ISE to do it on behalf of Meraki? We use Intune as our MDM so not sure if Meraki can do this directly. 

[adiaron]

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. 

[adiaron]

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. 

[Boyan1]

@adiaron Thank you; very helpful. I wonder if the 2 step process you described could be handled by the same SSID; much like classic switch port based 801.1x auth where if certain enterprise auth method fails, the port (or SSID in our case) gets dropped into a certain less secure VLAN and if it succeeds - then the production VLAN. So our bootstrap scenario associates with the same SSID, only that "pipe" delivers different degree of connectivity at different times based on auth. I'm new to MRs so this is a question I would love clarify. Thank you

[adiaron]

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. 

[Taezius]

Hi Adiaron... related to that conf (that I want to reply) just one info 🙂

If I click on (i) icon on the left on Root Ca I read : "Configure wireless supplicants to expect RADIUS server certificates with the following properties. Use the 'Current organization' certificate name to trust all APs in this organization. Use the 'Current network' certificate name to only trust APs in this network." Of course that value are dedicated to your network / environment but you configured into supplicants, right ? 

[adiaron]

Hi Taezius, 

I can't really say I "configured" it into my suplicants, because the first time I tried to connect (osx or windows) the supplicant asked "Do you trust this certificate with *.org_id.radius.meraki.direct" and I clicked Yes, that was about it. If I would like to do it more nicely and at a scale I would export that cert and push it through MDM as a valid trusted certificate for supplicants, but I need to figure it out where that cert has to be pushed in what store in osx, then in Windows etc and by doing so I remove one "click" from the user and possibly the risk of SSID impersonation. 

[Taezius]

Ok

thanks a lot, I will try to do that step in test lab!

[JoseM]

Hello @adiaron ,

any digital certificate is valid?

Does the connecting customer have any special settings on their network card?

greetings

[lilZ]

Hi Adiaron,

am trying to test this without a radius server. i have generated my own RSA (public and private keys) then i have trusted this certs using online root ca (online website) for 3 month.

after that i have installed Meraki root CA on my devise then i have uploaded the trusted client into Meraki portal.

i have also installed the client and Meraki certs in >personal.

unfortunately i still cant authenticate "Client failed 802.1X authentication to the RADIUS server."

any thoughts?

[adiaron]

Hi IilZ, 

I don't understand from the description the relation of trust between your RSA public cert and the Meraki root CA. Who is the root for the client certificates ? 

https://documentation.meraki.com/MR/Encryption_and_Authentication/Meraki_Local_Authentication_-_MR_8... 

I suspect there is a lack of trust between the certificates used for the user to authenticate and the certificate presented to Meraki as root of those. 

[jaymon123]

Thank you for posting this.  I have a few questions if you have a second:

1. Is there a way to generate a Client Certificate CA without Active Directory Certificate Services?  We no longer have on-prem AD.
2. If I install the certificate on the device in the Local Computer store, will the network function pre-user authentication (i.e., before the user logs on to Windows)?
3. Has it been your experience that if you use Local Auth that WPA3 is unavailable?

[PhilipDAth]

Do you use Intune?  if so, you can use CloudPKI to issue certificates.

https://techcommunity.microsoft.com/t5/microsoft-intune-blog/microsoft-cloud-pki-launches-as-a-new-a... 

[DTown-AI]

Hello Adiaron,

With regards to this, what client cert are you using?

DId putting it in machine context address all issues?

Thanks

[adiaron]

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. 

[Guac55]

Are you using credential based auth (MSCHAPV2) or cert based? (EAP-TLS)

I assume If you are using EAP-TLS local auth, you will never need to communicate with the Radius server as authentication occurs locally rather than creating any cache. 

[adiaron]

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.