Feature Request: 802.1x supplicant capability for Omada EAPs & Switches
This is a copy of an extremely long running feature request I had from UniFi, before I switched most clients and sites to Omada. There are many situations (particularly in schools, kids get up to all kinds of stuff, but also camp grounds, B&Bs etc) where physical security of remote ethernet ports/APs cannot be assured and simultaneously it's desirable to make sure that unauthorized devices can't just be plugged in and go cruising through the network by tagging their own traffic. MACs are utterly trivial to spoof. The right way to do that is typically multi-host 802.1x for a wired port. As far as I can tell, Omada of course supports acting as an Authenticator for its own clients, but the actual switches and EAPs do not have any ability to act as a supplicant themselves (same as UniFi). So their ports have to be set force authorized, and in turn if someone unplugs one they can then just plug in something else.
And while technically this is true of lots of devices that don't support 802.1x, I think it's worse in the case of network infrastructure. If some networked screen or printer or whatever client appliance didn't support it, the port still needs to only offer just a single VLAN of traffic along with features like port isolation, so it can be trivially restricted and monitored. But switches and access points that are themselves serving further downstream clients must be able to pass traffic for everything those clients might use, including further network devices and the management VLAN itself.
Having the switches & APs themselves support RADIUS under network options and cooperate such that the port won't pass any traffic at all without an authorized device attached could be used to fix this. It's also possible to envision various proprietary approaches, allowing admins to explicitly designate a given port as a "downstream network intermediary" or whatever label, and make it so that Omada hardware has a way to handshake and perhaps setup a transparent to operator tunnel. I think something standard is likely best, but whatever the approach it'd be a real boon to have some extra layers available.
Ideally Omada would leverage this into the adoption process, so new kit can have credentials added so everything automagically can provision on adoption or deployment. Apologies if this has already been addressed somewhere, but I did a search and couldn't find it. Thanks for your consideration.
