We are working on moving away from our on-premises AD to Azure AD. Part of our current infrastructure is using RADIUS authentication on our WiFi network, linked to our AD.
Seeing as using Azure AD directly isn't an option yet for Meraki, have you guys come up with any solutions for this?
I've been reading some posts about using a splash page to authenticate against Azure AD, but nothing specific or with a detailed configuration guide.
We don't want to spin up a VM in Azure just for this. I'm guessing we are not only ones facing this issue?
Hello @KevinI ,
At the moment, Meraki does not have a direct integration with Azure AD. However, since Azure AD is cloud-based, you would need to set up some kind of VPN set up anyway (until a direct VPN with Azure can be established).
I would recommend checking up on the vMX feature of Meraki. Following KB gives you some details on the setup
I would not recommend using a splash portal (open ssid) for corporate users. We are looking into a solution with ipsk and Azure. I'll keep you up to date.
following, we have the same question. We do not want separate vm's or servers, just Azure AD authentication on our Meraki equipment.
This question gets asked a lot on the Cisco ISE Community pages too. The challenge is that Azure AD is not the same as Active Directory (obviously) and the interfaces into Azure AD don't lend themselves to every use case. ISE for example, offers SAML interface to *some* parts of ISE (like Sponsor Portal Login page, or MyDevices Portal page) - but you cannot use Azure AD for things like EAP-PEAP authentication. Why? Because ISE has no native integration for such an external identity source. The closest you can get to that (with ISE) is to use Secure LDAP. But that breaks the password challenge algorithms (MS-CHAPv2) that is commonly used in EAP-PEAP - it cannot work. But the sLDAP integration could be used for non Authentication purposes - e.g. checking for AD Group membership during an EAP-TLS (cert based) authentication.
This is a challenge for every vendor and I have yet to come across a AAA vendor who has solved this problem. Be careful when reading that a product "integrates with Azure AD" - it's often very specific use cases only.
The solution to all this is probably a new protocol that runs over TLS (https) directly into public cloud providers. You might want to look at JumpCloud.com to see what they are currently up to.
@m841 - that's good to know. Do you have actual experience with this? I'd like to learn how this is done. Please post some more information - I have some identities in Azure and a small lab to test with. I am not too familiar with Free Radius - if you have some kind of base config, that would be handy. 🤔
Have it running in production, though it was a while ago that I set it up, and I stupidly didn't even document it for future self. When I get some time I'll see if I can cobble together some steps
Azure AD DS has been available for some time. The issue that everyone is having is how to tell our glorious RADIUS servers how to use Azure AD DS. Whether FreeRADIUS, Cisco ISE or Clearpass - they all have the same issue.
I was on an ISE update session the other day and it was mentioned that ISE has support for SAML integration with Azure AD DS. Of course this only helps us for https (portal based) services, but not at all for EAP-PEAP, etc. - without divulging too much on the ISE roadmap, I believe there may be some work under way to utilise this SAML mechanism for other authentication means.
@RohitRaj azure offers the idea of conditional access based on a compliant device. i'm hoping that Meraki will build in a compliant device check via intune nac.
and leverage an oauth token to connect to intune
Most of the Cloud Identity providers are just providing simple Username/Password and maybe MFA and masquerading that as full identity management solution. With ZeroTrust, those solutions are missing key components like End-Point posture assessment. O365 offers Intune, but it’s very limited with Macs and has limited end-point capabilities. There are a number of 3rd party offers as well, but now you are operating multiple security policies.
We also have lots of clients moving to cloud, but most realize that moving AD is the last thing they want moved. It’s the security ‘Crown Jewels’ and loosing control of that to a cloud provider should be considered as a major potential issue.
Providing 802.1x for NAC from the cloud has many other issues, mostly manifesting with users not getting basic local lan access. 1x can be very chatty in a dynamic environment and any delay above 100ms will cause timeouts resulting with either default guest access for privileged users at best, or no access at all at worst. Both options are sub-optimal.
This is a classic ‘Just because you can, doesn’t mean you should’
Buyer beware. Just saving $$ should not be the primary driver when it comes to moving identity completely to the cloud.
Okta, ping, and the rest of the cloud IAM are nothing more than just a unified SSO middleman, with a pretty front end. Execs love it, cause it looks good, but many IT organizations are realizing that they are losing all control of the end-point, and with ZeroTrust, the endpoint is just as important in deciding the correct access policy.
Some interesting points of view
We dont have any networking setup in azure.
ideally would like to use something that doesn't involve doing adding more complexity
Meraki has implemented WPA2-Enterprise auth with GSuite/Google, why not implement the exact same integration for AzureAD?
Meraki has SSO SAML integration with Azure for dashboard access. Its has splash page sign in with 'out of the box' support for google and facebook. But somehow, even with a UI that supports potentially endless idp's, MS is not there. There are no legitimate support docs to build your own splash page.
There is no logical reason to exclude MS as an idp for wifi sign in. The question has been posted since 2017. There is no technical reason. The conspiracist in me thinks meraki hates MS ?, google is paying meraki to exclude it? the original developer of the meraki authentication lost the source code? There has to be hundreds of thousands of potential meraki customers that would benefit from this. It make no sense.