Hi guys,
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
https://documentation.meraki.com/MX/Installation_Guides/vMX100_Setup_Guide_for_Microsoft_Azure
Hello @RohitRaj I hope you're doing well. Is there any positive updates regarding the Azure AD authentication on Meraki WiFi?
@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.
https://docs.microsoft.com/en-us/mem/intune/protect/network-access-control-integrate
and leverage an oauth token to connect to intune
We too are looking for this since we are moving our devices to Azure AD only.
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.
Hello,
Can you please tell if you came up with any solution ?
We too have Azure AD and planning NPS Radius in Azure
Hi Kushan,
So - Following the three data center outages which manage Meraki Radius, ( I know, different topic)
I stepped back from waiting for (1) Azure Auth and for (2) Meraki Radius to be (1) implemented, and (2) fixed.
And set up instead ID-PSKs with group policies and am still using the local Merak user base.
Yes it is still a pain, but it at least lets me kind of manage the users in groups as i can see the groups based on the group policies enforced via ID Psk. its not a solution but it is keeping me floating for the moment while we continue to wait.
That said, the latest Microsoft outtage has highlighted an issue and has raised concerns over "should we federate with Azure" if Microsoft has another outtage like this, not only will users have a depreciated experiance with MS tools. but it could knock them off from having an internet connection.
We more or less survived this outtage and ops were not disrupted too much. But man, If they got kicked from using the network, it would have been a really busy day.
If it is that critical for you why not create an additional SSID with complex WPA key that is distributed to your managed clients by policy. This can be used as a backup in case the AAD fails. The additional SSID is disabled in Meraki and when AAD fails you simply activate it.
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.
You can use FreeRADIUS to do PEAP auth of users against Azure AD.
@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
Now that the Azure AD DS is out, has someone ventured to setup this with Azure AD DS?
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.
Hello, did you have a chance to look into the config ? thanks
Hi @SoUnCool
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?
i've been waiting for integration that leverages intune device compliance checks
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?
Currently using Meraki System Manager on its company owned tablets and computers. No MDM for staff phones (all BYOD)
@jrhopYes, I reached out to SecureW2 and received a quote. The price is quite a lot.
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
Hey "UnCool",
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
Daniel.Kritikos@obs.school
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,
what os's we have a heavy ios dependency.
Windows, Android and iOS
sweet. do you have any clips or docs on your installation?
something for me to follow.
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
Can one push a portnox agent onto IOS?
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.
alright, ill look into it, Cheers Uncool
@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
2022 Meraki has any update on this for us? People are moving away from on-prem stuff. They need to allow Azure AD via API for wifi auth.
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)
https://apicli.com/2021/12/13/meraki-mr-802-1x-with-azure-active-directory/
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.
I meant that Aruba central supports a very simple Azure AD integration.
Has anyone managed to get any further with this setup?
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 ?
Does Meraki have any plans to support this basic feature that other cloud networking gear supports?
Let me share one recent Meraki tech support conversation with you:
Me: We are using System Manager sentry on Windows for Meraki cloud authentication and Windows asks for username & password. All Windows endpoints have System Manager installed properly, showing up on back-end. No issue with iOS devices.
Meraki support: Sorry to hear that. It is a known issue that Windows asks for username & password in this use case. Please create users on Meraki dashboard for the time being.
Me: No. The entire purpose to pay for System Manager is to get rid of manual user creation for cloud authentication. When the issue can be fixed.
Meraki: We are working on fixing the issue.
Me: Any ETA?
Meraki: No ETA
Me: How long this issue has been?
Meraki: a little over two years.
Me: !!!! ????...
Guys dont mix up Systems Centry Manger, Cloud Auth, and Wireless Auth, they are all seperated in the Meraki ecosystem.
Your community is feeling pain here, come on, you need to get this done.
Others have achieved SAML based WPA2 Ent Auth, why can you not catch up.
A. Consoladate the user pages into one.
Org / Admins and Network Users should all be on the same page.
B. add logic and enrich the new users page. ie + New User = (selection of user types incl Admins) where the logic can tell the difference, provide wireless and network access as well as "user wireless access", have the 2FA options built in to this area. and like on your Org Admins section, incorporate the SSO section.
C. upon sso setup, have a cron or something that is securly connected to "i.e" an AAD to check for the list of users.
So when I get my request to set up a new user, I click that +, I check the sso box, I start to type the name and the text box auto recommends the new user pulled from AAD, and atuo enters their name, and their email.
I click save, and they get an email saying to sign into the "org" network simply enter in your email address and your password. a simple session cookie can do the rest.
and AND; treat the info as 802.11x. win win win.
You already have all of these options scattered around your dashboard. you just need to push them all together on one page, and do a little logic coding to make them all talk to each other and behave seamlessly.
I told you guys this like 6 years ago, and have pushed this upon you frequently, your "make a wish" response is bs,
We pay you guys enough, I am starting to wonder if the cost is worth it, granted the ammount of problems I am having with your Cloud Radius, and lack of response.
You are in a perfect position, we the community are literally handing the work to you.
I don't know if this helps anyone, but we had this issue - wanting to secure our WiFi for Azure AD joined machines, but not having a password etc. We achieved this by *loosely* following this guide : Intune: 802.1x Wi-Fi, NPS and user PKCS certificates | Katy's Tech Blog (katystech.blog) this helped us to set up the Intune Certificate Connector to issue internal CA certs to Intune/AAD devices. We then set our Meraki authentication to "Enterprise with Local Auth", allowing certificate authentication, uploaded our root CA cert... And it worked!
@NovaNinja Hey good idea, where did you "upload your root CA" in Meraki? When "Enterprise with Local Auth" is enabled all I see is a preset that points to Meraki's RADIUS; how did you configure your Meraki end? I totally get how the CA would work with InTune - pretty clear process but I'm missing few pieces of the end-to-end solution that you implemented. Also just to be clear - in your solution the chicken-and-egg issue of having to have cached credentials (first login done other than 802.1x) isn't a thing because this is pure device based auth, yes?
...
Why has Meraki not stepped up on this? Can we get a response with a roadmap or an ETA on this feature? Completly unacceptable that we are being told to use work arounds to acheive enterprise secuirty on a product that we have fully paid and subscriped to. I could understand if this was a bunch of guys hacking firmware to get this to work, but this is the offical support from Cisco/Meraki? Get your priorities figured out and get this working very soon!
...
Your input is unproductive and is off point. Please stay on topic.
Your mentioned social media does not provide cloud based sd wan to hardware services.
@NovaNinja Good point but sidetracked, my recommendation searves as a base for all environments, such as those that do not use a device managment platform.
@Robert_H Agreed, some form of acknologment that this is even on their radar, with a roadmap would be good.
I am quite frustrated with their own cloud based 802.11x radius soultion. on paper its brilliant, no need for an on prem ISE. But we have experianced three times where their Radus services at their datacenter have failed, preventing our entire org from authenticating into the configured ssid. We have had to downgrade to a psk to counter this issue.
I also have alot of struggle managing users, ie who i can remove and who is current.
with these two major issues on my hands, having an user authenticate via SSO off a cloud AD "like azure in our case" would be epic.
@MerakiHell back to your point on MS vs Meraki, also not accurate, I can SSO from AAD to the dashboard for admin control, just not to the wireless network as they are seperated systems.
I managed hundreds of iPad that use System Manager based sentry and Meraki cloud authentication. One big lesson is you have to have a backup SSID (using PSK). So, when Meraki cloud authentication fails (it will fail), you immediately broadcast the backup SSID.
Make the backup SSID part of your MDM profile; make it tag the same VLAN as your primary SSID,
😔So true, a lesson I learned the hard way.
...
Honestly you are likely not going to get an answer or acknowledgement from meraki here. These types of conversations are best had in the boardroom, so to speak, with your actual account reps and customer success champions in attendance face to face and where you hold their feet to the fire.
I had these conversations during Cisco Live last year with the product managers and Meraki leadership team. I was very vocal about the lack of such a basic feature. To this date, we are no closer to achieving the outcome. We have a cloud-first strategy, but Meraki is really slowing us down.
Unless it was in a whisper suite, I would suggest that you need to reengage and commit something to paper. Even if it was in whisper suite you have some onus to follow up with them.
The latest CVD for WiFi integration is available here - Meraki WiFi in a Box Design Guide (CVD) - Cisco Meraki
Solution Use Cases - (1) Secure Corporate Wireless LAN Access with AD authentication - is what we need. Guess what it's also required ? Cisco ISE 3.1 (so you can deploy it in the cloud)
When I asked our Cisco Meraki rep 1yr ago when ISE will be available in the cloud and which cloud they said AWS.
Why?! Because most of their customers prefer AWS. But in most of the cases ISE will be integrated with Azure AD. ETA for ISE in Azure cloud ? N/A
A 61 pages documentation. It is REALLY a VERY easy to adopt solution.
ISE 3.2 open beta is out for testing since mid June. You can deploy it in Azure , Oracle cloud as well.
Hi Adimizil, thank you for your message.
Would you deply a beta into a live environment? seems risky, especially givin this topic is about authenticating users.
If anything goes wrong, you will be dealing with a very large number of unhappy employees.
Then, should you contact support to explain something is not working as expected with the open beta. I doubt you would get support on a Beta.
To be honest I've deployed ISE 3.1 in a VMware test lab for testing purposes nd also in AWS as AMI for the same reason. Configuring an Azure test account , Intune, SCEP etc takes more time than the actual ISE MDM integration.
ISE 3.2 is just a open beta and it was provided just for testing purposes. I haven't had time to test it yet.
Hi SAtech, thanks for pointing this out. In my case this will not work as it is dependent upon having
Since Meraki can be SSO connected directly to Azure for Admin portal access.
I am waiting and hoping that they will adopt this configuration and extend it to users to allow for access into the network with out the use of an ISE.
Meraki installations already cost a fair ammount, These PreReqs are an added cost for a functionality that Meraki could implement into their existing environment.
R
Dan
Reading all this. There could also be another solution. Microsoft could just provide a RADIUS service in their Azure AD solution. Problem done.
Because the real issue here is of course, network equipment speaks, good old fashioned, has always worked, RADIUS, and Azure AD speaks SAML . And in case you didn't know SAML != RADIUS. 🙂
So who "gives in" first ? The network provider, that now have to invent a new integration to potentially all cloud solutions, that can be completely different from each other, or , the AD cloud provider who should just provide a well defined service in their solution , that would then work with every network vendor. - So should the pressure not be on the cloud AD provider instead of the network vendor ? - I dunno. This is why we get these fun solutions with a "translator" in between from RADIUS to SAML 🙂
Just my thoughts. - Not here to fight 🙂
SAML2 is a growing, modern authentication method requiring little setup and knowledge and next to no maintenance to keep running. And, it's cloud-focused.
RADIUS is an old, inflexible method that generally relies on either maintaining your own on-prem system or going to an expensive third-party "cloud" solution.
Given Meraki is better suited not towards large enterprises but towards smaller, cloud-focused businesses, it would be in Meraki's best interest and follow their business model to move to support SAML authentication for 802.x. It would not make sense for Microsoft to implement an outdated authentication model in their cloud-focused Azure platform. Meraki/Cisco is also small-beans compared to Microsoft, so if anyone is going to follow suit it'll be Cisco.
I mean, technically it's already possible by standing up an on-prem or cloud NPS server with RADIUS, but the goal of this post is to get Meraki to support modern technologies, so I find your comment out of place.
But what EAP method would work with SAML ? I'm guessing only one of the servers side certificate methods like TTLS and PEAP ? Or is this the real problem, that you cannot do EAP "on top" of SAML ? Then it becomes a whole new Hornets nest of development hell. Clients need to support it, the network devices needs to support it, and between the network and the AD SAML provider . So I'm guessing that because RADIUS ( you call it inflexible , I call it very flexible 🙂 ) is the standard for dot1x authentication, it will remain, until someone sets a standard for SAML network authentication from client device and out.....
The way I imagine it would work is RADIUS would still technically be used in order to remain compatible with 802.x, just that Meraki would be the RADIUS server and would primarily serve to translate the SAML authentication response.
In the meantime, I'm thinking of trying to use FreeRADIUS and an LDAPS module with AADDS to accomplish this. It should allow me to perform authentication without running a FreeRADIUS vm in Azure Cloud, or setting up Azure VPN. It'd be great if I could find some documentation of connecting FreeRADIUS with SAML... then I wouldn't even need AADDS or LDAPS.
This is exactly what Meraki has. when you Ent in a network’s settings, you can select where the auth happens in a drop down, this list has Meraki Radius as a selection.
When selected, the auth occurs off site in the DC where your installation is hosted. in my case Frankfurt serving Switzerland.
Two problems with this, 1. which i have experienced three times now, when their DC goes down, your entire org cannot get on to the network.
2. managing users. just an all-round nightmare, due to their lack of functionality in the user’s section.
As mentioned, a few times, they already have SAML functionality setup. When I want to access the dashboard, I need to use my Azure Credentials and Azure MFA to log in. works a charm.
What I want is the already present functionality to be extended to the "Meraki Radius" so that we do not have to manage users in Meraki, they simply sign into the network using their "SSO" in my case Microsoft Email address and Password.
I just don’t understand why they do not do this as they seem to already have the system in place.
We are an independent school completely updating our entire network infrastructure with Meraki gear based on the recommendation by an independent school technology consultant. We also would like to move to cloud based authentication and remove our on-prem AD. Has there been any progress on this technologically? This is of great interest to us.
Hi there LakesideLion, Maybe reach out to me, Daniel.Kritikos@obs.school
We are also a fully cloud operational school using Meraki.
I have tested the waters with Meraki's own cloud based radius auth, Back then it was not reliable, I switched to identity psk and baked the wifi connection and psk into a jamf mdm config which is pushed out to our devices. this seems to be working well for us.
R.Dan
Depends on the size of your infrastructure, budgets, etc. but I'd start with a conversation with Tim at Splash Access. https://www.splashaccess.com/ We're pretty confident this will be a good answer to this issue.
I will definitely look into that. We're a 5th through 12th grade school with about 900 students and 250 faculty, staff and administrators so about 1150 users with about 2300 endpoints ( laptops, desktops, tablets, phones ) spread over 11 buildings on 2 campuses. Thanks very much for the recommendation.
Sounds like the right fit for SplashAccess. Heavily used in Education environments. We haven't implemented yet, but demos and test environment all look good, so am confident it will be a fit for you.
When will Meraki have a native Azure integration for this?
Is it on the roadmap?
All,
Have you seen this YouTube video from Paul Fidler on how to use System Manager along with Trusted Access to integrate into Azure AD for user self provisioning on Wi-Fi? It uses certs from Azure that can be configured with different expiry times based on AD groups.
@Kit_Johnston Thank you for the YouTube link; it's very clear on the features, etc. My only issue with SM is.. well the licensing. Trusted Access is very attractive in every other way so not a dis at all!
@Boyan1 I IM'ed with the guy that made the video, and he said it will work with other MDM solutions, but that you still needed "just a handful of systems manager licenses".
Any idea if the "handful of licenses" is just like for the registration phase? I am wondering if you really need the systems manager licenses for each device that's online or just for like when the devices are actually connecting. If its for every device then we're just doubling up on other licensing to get one connection completed but if it's just for the registration phase that seems doable because I would assume you could get like 5% of the user base and be covered for reconnects depending on your expiration settings.
@WilliamBHunt, If you have WebEx, you can ping Paul Fidler directly and ask him what "handful of licenses" actually means.
Posted to the video too, but I also want this communities input...
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?
Yes, you’re missing Meraki/Cisco’s greediness and unwillingness to provide us with features we ask for. Anyone who says there’s technological reasons why it won’t work is lying to themselves. It can be done on other platforms.
Do tell - what platform can do that and I will gladly dump Meraki - it's budget season now so it's the best time to have this discussion. I'm already furious about Meraki's "co-term" licensing scam and how they forbid your legacy SM free license to exist if you want to escape the scam of co-term; it's phenomenal "sales marketing" if you ask me to force a custom to pick the lesser of 2 evils
It is frustrating that even after meeting the Merak product managers and senior leadership at Cisco Live and candidly discussing the absence of a basic feature, there has been no progress made in almost a year.
I am not an expert but I think the certificates are actually generated by Meraki after the user successfully authenticated via SAMl on the portal.
My doubt is whether the authentication is performed on Azure via SAML at every network authentication attempt, or if it terminates on the SM and it is valid until expire date. What would happen if you "remove" a user from Azure AD?
SLO would be expected to be initiated by the IDP, instantly revoking access via the Meraki. It's up to the implementation to correctly support it, which Meraki seems disinterested (as evidenced by this very long, very old, and very ignored forum thread)
I'm using AWS cloud for active directory and NPS using 802.1x, however, using cloud server got high latency as compare on-prem.
After years of waiting on this feature hoping there will be a fix before moving off local AD I think I will move to JumpCloud for Radius service. I hate paying for it, but it seems simple and reliable. Has anybody else utilized it? Configure Cisco Meraki WAP to Use Cloud RADIUS - JumpCloud
This doesn't connect to AAD. Does it?
I would say "yes" based on their docs : https://jumpcloud.com/support/authenticate-to-radius-with-azure-ad
I've confirmed that if you want your users to type in their AAD user/pass when they connect to wifi - JumpCloud will work. I've spent all week trying their Passwordless option and can't get it to go - even with support. In theory, Jumpcloud syncs AAD users to its interface, a cert is loaded on the workstation, wifi should connect without intervention. When a user is terminated - you have to delete the user from Jumpcloud (and AAD) to stop wifi access.
I'm still working with support, but their documentation is confusing. It's good documentation, but it needs to be accessible with steps. Step 1 website, Step 2 website, etc. I end up with 20 tabs open every time I try and troubleshoot.
i have been having issue with jumpcloud before, attributes filter ID is not that flexible unlike policy on NPS.
Jumping in here after reading this entire thread to give a few comments about JumpCloud and our experience with it for their RaaS. I know it's 5+ months late for your question, but maybe it will help others scavenging this thread for morsels of information.
It's important to understand that we have a few different platforms to cover our needs. While there is a fair amount of overlap in our platform choices, they were picked for specific reasons and because of the pricing we received as a non-profit.
Our imperfect solution combines:
I will also apologize for not being nearly as well educated in networking as other members who have posted here already.
Okta is our SSO and IdP. We fully left Microsoft AD behind in the great Covid work from home flight. Okta and JumpCloud were the two platforms selected to replace our on-prem AD.
Utilizing SCIM, we push our users from Okta to JumpCloud. This also syncs their local logon password from Okta to JumpCloud.
For the RaaS, now that they have dynamic groups, users are added automatically to an access group to allow them to use the RaaS.
The setup of the JumpCloud RaaS in Meraki was fairly straightforward and didn't present any critical problems that I can recall. Or at least nothing that a little bit of troubleshooting couldn't resolve.
So now users could log into the wifi with their SSO creds. Next to make it seamless.
Up to this point, you could fully achieve that without using a JumpCloud agent. It could be a very expensive investment to only buy the RaaS feature from JumpCloud considering everything else they can offer now.
Since we are using JumpCloud for our MDM, we installed agents and can leverage their remote commands feature. I prepped a wifi profile XML and in that XML I substituted the wifi credentials with $Variables that would pull from the creds they used to log into their laptop, which again are their SSO creds thanks to Okta/JumpCloud SCIM provisioning.
That XML file is delivered to their laptop via command and then the actual powershell command will create the wifi profile utilizing that XML. The wifi is set to auto connect, so nearly flawless seamless wifi access via their SSO creds. This worked for 99% of our windows users. Very rarely would we encounter someone that had issues. We would just forget the wifi, delete the XML, and rerun the command in JumpCloud to fix it.
The same behavior was achieved for ChromeOS users using Google Admin's policies and setting it up to use variables for the user name and password.
I was working on getting a command setup for MacOS / iOS devices, but they are much harder to work with for me and we just lost time and traction. Given the relatively small number of those users, we just connect them manually to the wifi.
NOW... The reason I came to this thread...
Many months after that aforementioned setup, we came into a position where we needed to save some extra money where possible. We had been inadvertently provisioning ALL our users from Okta to JumpCloud, including those that don't use a Windows laptop. JumpCloud cannot manage, at least to a level we are comfortable with, ChromeOS devices. It is on their radar for better options, but they are being tight lipped about it whenever I ask. So, we decided to remove the ChromeOS users from our JumpCloud. Since JumpCloud charges by user, not device, it made sense.
Well, as we discovered, that of course removes their ability to use the RaaS and thusly use the office wifi...
As an temporary solution, we have those users connect to a more traditional PSK wifi. The Chromebook users do not visit the office regularly at all since we have maintained a hybrid work model. So this has been an acceptable workaround for the moment.
Since Okta offers a cloud LDAP, we thought we might be able to use that with Meraki local auth, but Okta's EAP-TLS cert is not viable for Meraki's certification chain.
So now we are stuck in a position of trying to find a solution among the resources we currently have to give all our users seamless and secure access to the office wifi.
I was kinda hoping that maybe Azure AD or Microsoft Entra ID could possibly be leveraged since that still exists, but as you might have surmised by this point in this thread, that is a lost cause still.
Has anyone seen or tried this. I stumbled across this in YouTube.
https://www.youtube.com/watch?v=5PDpnsWtmlE
Yes we’ve seen that, it’s a non-solution.
The premise is to buy their expensive device management solution on top of AzureAd/Intune (which is itself a device management solution) so that we can then authenticate WiFi.
No thanks. Just implement this basic feature.
Whole heartedly agree.
Meraki, seriously...
We are 4 years after the creation of this post, companies are migrating more and more to Hybrid cloud or even full cloud, Meraki is supposed to be an actor of this transition, and yet! Still no simple integration with AzureAD to make a simple SSID login page.
It's crazy that in 4 years of discussion and suggestions, the only workaround is to use google oauth with workplace connected to azuread, which is clearly far from optimized and practical for users.
You're supposed to be a dynamic cloud actor who keeps up with the latest developments / techs and that's just one of the many points showing that you're having trouble following this status.
It would be very helpful if Meraki would let us know what types of Wi-Fi integration with AAD/Entra/SAML and Intune are in the pipeline so we can better make decision on whether to (1) continue to configure Wi-Fi auth manually/non-granularly, (2) develop custom tooling (open sourced, if possible), or (3) seriously explore marketplace solutions that might be overkill or misaligned with basic use cases.
I come back every few months to see if we have a new update or solution that does not require more cost to setup. It does not seem to be the case just yet.
I am also Waiting on integration with Azure AD as well.
Come on, Cisco, based on the statistics, you are the best, but you have not been able to cover this need that we all have and it makes you look bad.
This could work : https://documentation.meraki.com/MR/Encryption_and_Authentication/Meraki_Local_Authentication_-_MR_8...
As long as you can speak "LDAP" with your Azure AD.
Has anyone gotten a reply from Meraki on this, need to know if this is even being worked on.
Come back in 10 years time and we will still be talking about it. What a joke!
Radius as a service is a good solution if it needs to be basic.
It is then completely dependent what you put in the certificates.
And you can use your cloud MDM to push those certs to the clients.
And there is a solution from Cisco that integrates with Azure AD in the form of ISE. I know that is an expensive solution if you only have a single office with less than 50 users but in that case you should look more at the EAP-TLS way with a radius service.
If Meraki does go out of their way to support a certain protocol with Microsoft and then Microsoft decides to change something or stop supporting something on a whim that investment could be lost.
Hello Meraki Community!
Great news as we have begun testing for Entra ID authentication with Splash Access 🎉
All you need to do is scan the attached QR code or follow the link. This will direct you to Stomio project where you can create a tester account, and voilà, you'll find yourself a part of the beta project.
The platform will communicate announcements on Entra ID with Splash Authentication. Once you're part of the project, please share your network link and verify that it has network support access. Once we have the requested network information, Entra ID with Splash Access will be enabled. Thank you for your patience on this!
While many of us have been waiting for this for a LONG time, and it is exciting, The security guy in me is suspect. Can we get a bit better from Meraki then a random post on the online forum? Like maybe a genuine meraki portal sign up option? Not super happy about having to share our network ID'S etc. Anyways I am guessing legit but is there a way to make this a bit more certified by Meraki looking?
I agree, this is very strange. I’d expect this to be an option in the Early Access section of the dashboard not a random forum post with a link…
I’m also not sure what “Splash Access” means, I have a feeling it’s the webpage splash screen which is NOT what this thread is even about. We want RADIUS auth, not auth through a webpage.
I have the same thoughts, is it official or some random third-party option?
Agreed. The «The Office» meme and the QR code (why?) were my triggers.
ATTENTION, THIS IS A MALICIOUS MESSAGE, DON'T SCAN THE IMAGE OR FOLLOW THE URL:
I created a Stormio account, then clicked the link, but it just takes me straight to my Stormio account. I see nothing that indicates I joined a project. If I log out and click the link again, the page I land on tells me that I have been invited to join the Microsoft Entra ID Splash Project. I log in on that page, and the same thing happens. Straight to the Stormio account page and no indication of being added to a project. Any advice?
Hi Dylan, when trying to onboard your email it states that you are a manager to a project. Is there an alternate email address that you can use to create a tester account? Also if you could unicast me your network link and I can go ahead and enable the feature.
I sent you a direct message, but I cannot for the life of me see how to sign up for an account as a tester. Whether I follow the link or the QR code, it asks me to create an account, then I do so, and upon verifying my email it asks me to associate with a workspace, which I assume tags my account as a project manager.
Can you send me a direct message with what you need me to send you to enable this for our network(s)?
Thanks in advance!
Reaching out!👍
Hi Chris - Sorry to bother again but I did not see your direct message after you said you had reached out yesterday. We are in the middle of rolling out a 3rd party solution for this now, but I would much rather use this if possible, so I am trying to get it enabled soon so I can know which direction to head with the project.
Thanks for your help!
Chrisgw,
The opt-in Stomio project link does not work anymore. Have you withdrawn this?
Hi @stu84773, Yes, the beta concluded last week. We are currently working on productizing the feature and scoping an official public release.
I just tried to opt in and I get an error saying "Invalid Opt In link"
edit: i just saw a post here that the beta concluded. i look forward to the public release
Hi all,
The news is very real. Cisco Wireless is starting the private beta for Entra ID authentication with Splash Access before it is released for public access. This is to get initial customer feedback on configuration and testing. We have made the announcement to internal account teams that may reach out to you for participation. While this is only for Splash Access, there is planned support for further user and policy-based authentication coming soon.
This time around, the project is being hosted in a Stomio beta testing platform rather than a Meraki community forum, so the Cisco Wireless product team can manually enable the feature on your network of choice. Please note your network links will not be shared outside of the beta program.
Will both Open networks and Enhanced open networks be able to take advantage of this? Else we won't be able to use it for 6 GHz networks.
How about WPA3 support for local auth using certs?
Splash Access sign-on with Entra ID is configurable for Open networks and Enhanced open network Security. Additionally, support for 802.1X is planned, which will go into beta before early access.
@Chrisgw Very interesting - any ETA on when 802.1X will be available via Entra ID? This will be a game changer, no disrespect to splash access but pushing corp users to do it every time will generate pushback, guests - sure, everyone is used to this but entitled users? Obstacle galore ... Thank you!
Agreed. Funny thing is that's what this entire post is about - RADIUS/802.1x, not splash. Looks like he did reply above that 802.1x is planned: https://community.meraki.com/t5/Wireless/Azure-AD-authentication-on-Meraki-WiFi/m-p/244716/highlight...
@Boyan1 I believe you can change the auth timeout of the splash page under Wireless -->Splash page. I'm not 100% sure how effective this is just yet as I'm in early stages of testing. We set ours to 30 days with the hope that the Wi-Fi won't make them re-auth until this time elapses.
Its hard to believe somebody finally decided to get this going. I am happy to report very easy installation. Super easy authentication - especially if already logged into browser with credentials. Everything i always wanted.. (see my post from 2019)
Thank you and please let us know when additional security features get added and most importantly gets moved to production.
Signed up for the BETA and stepped through the instructions. A couple minor bugs / errors during setup process but nothing show stopping. Its up and running on one of our test SSIDs, our techs are trying it out, so far so good!
I have configured it as per the instructions but I am getting this error after the authentication.
"This network's administrator has prevented you from using the network."
This looks to be an issue with the wireless client being blocked by a policy in place. By navigating to Network->Clients and then to the device, you can see if it is blocked or if a group policy has been assigned to block its access.
https://community.meraki.com/t5/Switching/Meraki-blocking-WiFi-connection/m-p/56119
Thats what I thought, but I have tested with Normal and Whitelisted Device Policy and still get the same error.
Hello Chris,
Opened a ticket, 12255521.
TAC claims that the beta is not available anymore and he does not know/does not have any information.
Are you able to share with us some information on it and guide it to some documents ?
- If beta is not available anymore, is there ETA dates or some release notes/technical guides for us to read and understand and plan ahead ?
Very much a break fix response from TAC. I am trying to request for a manager to review the case so he can help forward to the right team which knows it better. I hope he escalates it as per request
Regards
Gan
This issue was resolved by adding my Organizational Azure domain to the Allowed Domains list for the SSID.
Hi Gan,
The beta for Entra ID with Splash page has concluded. Once support for Entra ID with TLS and EAP-TTLS is available, we will release this feature as part of MR-ADV licensing. Once GA'd, all technical documentation will be published within the Meraki documentation portal.
Any general timeframe for availability?
Hi Puck,
We are targeting support for Entra ID within the first half of the 2025 calendar year.
Hello Chris,
Thanks for the update. Any docs/whitepapers you are able to share with us so we can understand, plan and prepare ?
I feel this very much requires a splash page and it is not as seamless compared to Radius auths.
Also I noticed when users roams, wireless users need to re-auth at times, I am wondering if this will prompt more splash pages as users roam ?.