I've been campaigning for a working solution to how users Authenticate for wired port security, and it's sort deflating that the industry standard methods are simply not working for me me.
My goal: In my org, I have the desire to use Okta for a user-base, and to have all networks around the globe (all Meraki MS switches) to Auth users with Okta.
My workaround: Since I need this global network to exist, and for my teams to onboard/offboard users as needed, meanwhile allow users to easily travel to our offices without hindrance, I'm having to provide:
Outlook: What are the chances Meraki will extend Authentication at wired ports to use EAP-TTLS, or to work with Okta on a real integration? Thanks!
>Meraki MS switches don't support EAP-TTLS or PAP RADIUS.
EAP encapsulates the authentication method inside itself - so the switch doesn't have to specifically support EAP-anything as the encapsulation means it will support EAP-everything. So EAP-TTLS will be supported - because the switch doesn't see it - the TTLS bit is encapsulated inside of EAP.
To use EAP-TTLS you will need to explicitly configure your clients to use this specific type of authentication, and for your RADIUS server to support this. Note that in the Microsoft desktop family - only Windows 10 supports EAP-TTLS.
A simpler approach - have you considered using certificate-based authentication (specifically EAP-TLS)? Much simpler, it is widely supported by devices (including printers), and you can use simple Microsoft NPS.
>Okta doesn't support RADIUS MSCHAPv2 (Microsoft refuses to work with them, I'm told).
They don't need Microsoft to work with them. They could copy they MSCHAPv2 code out of the very popular open-source SAMBA package.
To be clear, RADIUS with MSCHAPv2 works fine for AD, which is the method we're using. The goal, ultimately is to remove AD altogether and use a single cloud-based solution. Okta is almost there, but without MSCHAPv2, it's simply not possible.
As for using MSCHAPv2 in SAMBA, I suspect there's a licensing challenge there since SAMBA is free (GNU), and Okta Authentication isn't. Perhaps they could build it into the package as value-add, but I suspect they would be naive to assume Microsoft wouldn't try to stop that if Okta is a competitor. I don't personally know the mechanics of that challenge they have, but their engineering team said they've not been allowed to employ it for whatever reason.
If that's the case, I'm not fully understanding if/why Okta cannot or will not use it. I've worked on them for over a year in the hopes to get them to implement, but they've said it was not going to happen. We're researching other workarounds, which centralize AUTH, but allow Meraki wired 802.1x to work with it.
+1 would love to see this sort of functionality - exciting that its coming to the wireless side of things - but really need it for our switches/wired access as well.