Azure Auth and Meraki WiFi with Trusted Access

#cisco #meraki #merakiminute #moreaboutmeraki #systemsmanager #trustedaccess #eaptls #emm #mdm #azure #microsoftazure
Paul Fidler takes us through what is needed to do Azure Authentication with Meraki WiFi. We use a capability called Trusted Access, which allows end users to self provision certificates and network configurations onto their device, certificates that can have varying lengths according to your policies. Certs can be revoked at any time, and users can go back and update them if the certificate is close to expiry. Every time the user goes to the self service portal, they have to reauthenticate against Azure again
We truly appreciate your views, feedback and subscriptions.
Check out and subscribe to the MerakiMinute KZbin channel: / merakiminute
Learn more about the products from Meraki and the Meraki platform:
Cisco: www.cisco.com
Cisco Meraki: meraki.cisco.com
Cisco Meraki documentation: documentation.meraki.com/
Disclaimer: All opinions are our own. All information provided is of general nature.

[@SamJonsson-uk9zz]

How do I assign group policies to the users ?

[@basec0m]

So, you need to pay for Systems Manager to get this to work?

[@MerakiMinute]

That's correct. More details here: documentation.meraki.com/General_Administration/Cross-Platform_Content/Trusted_Access_for_Secure_Wireless_Connectivity

[@ivanmuccini6415]

Is the authorization vs Azure verified at each network connection or does this only rely on the expiration date to potentially terminate the access of a user? Is this using EAP-TLS?

[@MerakiMinute]

Authentication is done against Azure just prior to the cerificate / passkey installation. Any authentication for wifi after that is done using the certificate against Meraki dashboard radius

[@webbxpert]

I'm trying to understand the upside. So Meraki, with the assist of additional licensing ($$$), is registering trusted devices (eh erm... 'Conditional Access' which we already pay for via MS's licensing). Why can't Meraki support just support SAML SSO for wifi connections (via captive portal prior to authenticating to the IDP and whitelisting the required IDP urls), and let the AAD admin configure conditional access? This just seems like another system to manage that does effectively the same thing as AAD. Am I missing something?

[@MerakiMinute]

Thanks for the comment! A few things: 1. Azure isn't the only IDP: This will also work with any OpenID Connect / SAML IDP, as well as natively with Google Enterprise 2. Not everyone is on an E3 license. 3. Conditional access doesn't allow you to do network segmentation using MX Sentry policies, allowing you to change the network experience based on WHO logged in 4. What wasn't shown in the video is that different groups of users can get differing lengths of certs: from 1 day to 1 year. Users can renew their certs at any time and, most importantly, can provision their device with a cert *without* having the need to be connected to the network. This allows, for example, new starters to provision their phone whilst working from home, connecting automatically to when they get into the office 5. And most importantly, captive portal is NOT 802.1x, whereas Trusted Access is. A certificate can be revoked at any time without revoking ALL network access

[@stefansijswerda5667]

not only here but I always read on integration issues with MS AAD ever thought of the fact that this is an MS issue as all network vendors have standarized protocols for already a long time for access control and only MS insn't supporting that. Therefore there is always a middelware required. So maybe stop paying MS for licenses which introduce complexity in the full environment.

[@webbxpert]

@@stefansijswerda5667 -- "Therefore there is always a middelware required" this is not true. SAML 2.0 is a standard, I can use via Okta, Google, MS, Salesforce, etc. to manage an IDP. What you cannot do, is use the SAML or OAuth endpoints supported by the IDP (ubiquitous support by all major vendors), to authenticate clients to the WIFI. Mind you, that all other applications in most B2B are now OAuth or SAML, but Meraki? No, they require that you do a whole bunch of extra work, licensing fees, certificate deployment, etc., for something that could be available by Meraki out of the box. Moreover (if my reasoning above wasn't already compelling enough), Meraki DOES support logging into the admin interface via SAML: so they know HOW to do this, they just don't because they want to fleece customers for something that is, again, ubiquitous among IT groups.

[@Totelrecall]

@@stefansijswerda5667 No offence but this is nonsense, SAML is a standard protocol that Azure can leverage with enterprise applications, which is exactly whats going on here, its supported by all IDP vendors. Ive yet to see one that does not support it.