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.
Okta doesn't support RADIUS MSCHAPv2 (Microsoft refuses to work with them, I'm told).
Meraki MS switches don't support EAP-TTLS or PAP RADIUS.
Okta supports a cloud-based RADIUS solution, but again, doesn't support MSCHAPv2, the only protocol Meraki does support.
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:
Active Directory running NPS (RADIUS) at each location, or in AWS.
Authenticate wired port security users directly with each location's AD/NPS.
Use Okta agent and push-groups to push users and group assignments to each integrated AD.
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.
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.