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
@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
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.
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.
We dont have any networking setup in azure.
ideally would like to use something that doesn't involve doing adding more complexity
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
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.
Two Years on, I am still waiting for this.
Has there been any progress on this yet?
I need my users to be able to connect to the wireless network using their office 365 credentials.
I have Meraki SSO set up for admins to access the dashboard, but I really need to see better user managment options.
and the golden nugget here would be users using AAD creds to authenticate.
Did a Google search and this page is the 1st.
I am looking for the same solution. Two companies, one is cloud only, one is hybrid, both prefer to use Azure AD for certificate based corp wifi.
Can Azure AD DS work as a RADIUS server?
It sounds to me like Meraki is using the same methods for Google Auth that are being used on Cisco ISE for leveraging 802.1x with Azure AD:
- Authentication is handled by EAP-TTLS / PAP
- It then is "proxied" to Azure AD using ROPC, Meraki is acting like a "man in the middle" here.
In theory, this could be used for Azure AD too.
I have setup certificate authentication using SCEPman (www.scepman.com) and InTune, SCEPman is a Azure Web App that can generate SCEP certificates but only if the device is registered into InTune. You can then either setup EAP-TLS on NPS or another RADIUS server, or use www.radius-as-a-service.com (same company as SCEPman) and point your Meraki SSID to them. With SCEPman there is a free trial, free version and a paid supported version. With radius-as-a-service you can get a trial, but it is something you need to pay for.
If you do use your own NPS/Radius you need to use SCEPman user certificates as it does a lookup to local AD and cannot resolve Azure AD device ID.
Hope this helps.
This company has about 900 employees, at least 100+ of the management staff will need a corp Wifi. So Intune based option will be a sizable costs (well, technically can buy the much cheaper Intune for device license).
OK, radius-as-a-service might still be able to work, or JumpCloud as someone else mentioned. I think Meraki System Manager can also generate and deploy certificates. Are they using any type of MDM currently?
The costs and complexities involved for “proper” wifi authentication in a cloud only environment has made us rethink our whole approach. As long as we can restrict lateral movement (and printers etc are on isolated subnets and only accessible via their cloud gateways), our risk assessment may potentially lead to the conclusion that WPA2-PSK on the corporate WLAN is “good enough”. Lord knows that the pandemic has had our users do their business on networks way outside our control the last 18 months anyways.
we had the same problem, complex solution, lack of support, cost etc
we went with Portnox cloud radius and certificate service, worked like a charm
Lets talk, I am looking for an alt solution to Meraki radius to auth users of meraki on to the network.
Id love to hear how you managed it with Portnox.
Please drop me a mail
No any PSK on an ent network is a bad idea.
Of course it depends on how much a malitious vector can inflict on your network.
but these days cracking a key is a walk in the park.
at least with 802.11x their shot is limited to one user.
if you have a psk with attempt rules, if i fail multiple handshakes with one user, i can just move onto the next.
at this point in the hands of somone like me, your fairly screwed at this point.
the problem i am faced with is where to balance the level of security over the level of convenience.
we had a temporary situation where i needed to psk out to the org, but we also had an mdm.
so i created the most rediculas password somehting like 256 chars long mixing all dictionaries,
saved it to a wifi mdm profie and pushed it out to all devices.
but in any other circumstances, i would never use a psk in an ent or corp.
the risks are too high.
I'm also subscribing to this post.
- Alot of customers are moving to full cloud using nothing but direct internet access to access their o365 applications.
- I believe Microsoft is at fault here for not providing enough with their Azure AD solution and I'm curious to see how this will get solved.
for what is is worth, we did a pilot for portnox, it worked so easily that I was suspicious, all we needed to do was deploy their agent to end points, (our scenario and choice, not a hard limit of solution) and within 2 hrs we were up and running, Everyone now authenticate with azure AD , no more local domains,
by the way did anyone else experiance the Meraki Radius server DataCenter going down. has happened to us twice now. they still have not issued a report
The keyword here is "agent", and that is the main concern.
If I have to cast trust in one company, I will have to choose Microsoft.
portnox, jumpcloud, secure2w, you name it, are all agent based solutions. They are convenient (and not inexpensive) but by installing their agents, the entire IAM is at their mercy.
@SAtech it works without agent as well as a cloud radius service, depending how you want to do implementation you can bypass agent altogether
we looked at https://www.glueckkanja-gab.com/en/products/radius-as-a-service as well, they do not support on-prem or hybrid devices that was deal breaker
Has anyone tried either of these workarounds?
1. Use LDAPS from Meraki local auth to Azure AD (needs azure connectivity) - https://apicli.com/2021/12/13/meraki-mr-802-1x-with-azure-active-directory/
2. Use an Azure-hosted captive portal that uses OAuth to Azure AD - https://developer.cisco.com/codeexchange/github/repo/rafael-carvalho/meraki-azure-ad/
Check out this blog that was written by one of our brilliant engineers (Yuji)
This is a super well done documentation for the ldap workaround. great job to the author. However, if you see that it is about 20 pages long, and the doc for saml configuration for other meraki settings is 1 page. Google and Facebook auth require no documentation.
I did notice that they added AnyConnect VPN support with SAML auth and we have started testing. looks good so far. Packaging anyconnect client is problematic but that's cisco's issue not meraki....
@shauno- #2 is a solution I tried 3 years ago and was not able to reliably support.
I still wish and engineer could explain why this is so hard. Maybe there is something about wifi that makes a 3rd party idp not work, except for google....
I agree with Fady - this is a super complicated setup. Is there a simpler option available yet or is that even planned? I would also like to know why Meraki doesn't support a simpler integration while other providers like Aruba central do?
Hi @rsweet , just wondering what type of integration with Aruba central and Meraki will be beneficial? If you are referring to Aruba ClearPass, then we already have integration with it.
I agree that native integration with Azure will be ideal and I will have this as a feature request but till we have the native integration the detailed document I shared can be used as a workaround.
We need real integration support, not community workarounds.
Meraki is expecting customers to pay a large amount of money but provide only what they think is necessary.
Azure AD Integration for WiFi .1x is a must these days!
Meraki .1x WPA2-Enterprise with Google Auth it's possible, dashboard integration with Azure AD is possible, why is this not extended to .1x WiFi as well ?