06-12-2024 10:18 AM
**Please point me in the right direction if there is a better place to post this**
We have a single SSID in use for any non-corporate devices. This includes Guests/Visitors and Employees BYOD (cell phones).
1) The Visitors connect to the SSID and are redirectred to the Captive Portal. They sign in using sponsored credentials that we provide them for the day. ...These users have zero issues, everything works as expected.
...
2) Our Employees connect to the same SSID/Portal and sign in using their Active Directory domain credentials. They can sign in and authenticate without issue, then can surf the web, listen to music...whatever. No problem here.
The problem comes down to our employees that connect when their devices have Random Mac Address enabled. They can connect just as i stated #2 above. But after 5-10 minutes they are forcibly disconnected and re-directed (again) to the Captive Portal.
I can not narrow down the issue. Why would they keep dropping connection? Repeatedly. Also whats even more confusing is im SURE a good portion of visitors have Random Mac enabled as well, yet they are just fine.
So what would be cause only our Emplyoees (with Random Mac Address) to constantly get de-authenticated over and over?
(Will upload some screenshots momentarily)
TY!
06-12-2024 04:26 PM
Hi @MikeMoss
A few observations. I used to think that allowing employees to log into the company guest Wi-Fi was a clever/neat idea, until someone pointed out to me that this is a serious security risk, since you're allowing a user to type in their company username and password into an untrusted device. By untrusted, I mean that the personal device could potentially contain malware that harvests your employee's credentials. In security, we always think of the worst case and chances are it may never happen - but I would take this seriously and not accept company credentials on personal devices.
Secondly, MAC addresses on wireless devices are already a pain to deal with (local/random MAC addresses) - it's going to get worse. Apple just announced on their WDC that iOS 18 will have rotating MAC addresses - this means the MAC address will change even after you have associated to the WLAN. Makes guest portals and AuthZ policies using MAC addresses a complete nonsense.
We have to get away from using MAC addresses for any kind of authentication. The industry seems to favour privacy over convenience.
The forcible reconnection is due to their devices roaming (whether intentionally by moving around, or because of the wireless network conditions changing to cause a device to select another AP). When this happens, the WLC/AP kills the existing session and requests a new MAB from the RADIUS server. In the case of ISE, if you are using the "Guest_Flow" Authorization, then this means that the guest has a new session (because the previous one is now dead, due to RADIUS Accounting Stop) and then the portal must appear.
if you want the "Remember Me" feature, then you should be putting employees into an ISE Endpoint Group after they have authenticated on the portal, and use that as an AuthZ Rule, instead of the "Guest_Flow" condition. - then, they will never see the portal again, until their MAC address is purged from that Endpoint Group.
But, in the case of iOS devices, once they get iOS 18.x and later, this will break everything - and users will be finding themselves in the portal constantly. And ISE will be filled with MAC addresses that you will have to purge.
Random/Rotating MAC addresses are a nice feature for the consumer to protect their privacy - but an absolute PITA in the corporate environment. Perhaps we should stop using portals (YAY!) and move to WPA3 with OWE instead.
06-13-2024 04:25 AM
To add more into that feature from Apple for iOS 18 and Sequoia, and due to the lack of information about it, this is likely to impact the quality of experience of users, as the MAC rotation could make the device to abruptly disconnect from the wireless network to restart a new full authentication, which may introduce drops in real-time communications.
If the feature will be enabled by default or not like the private MAC is something unknown, and we would need to check with the RADIUS vendors about a potential license over-consumption under this situation, when devices are not expiring the previous sessions if they don't send a disassociation/deauthentication packet before rotating the MAC.
There are some options as workaround for this new paradigm:
06-13-2024 02:09 PM
@JPavonM - nice summary of options. One other thing I would add for guest access is Open Roaming, which in theory sounds like the ultimate user experience for a visiting user (e.g. conference) - I had this experience at Cisco Live and it was great. However it seems that setting this up has quite some cost involved for the venue organiser - I looked at this as an option for my customers and was confused about how it worked and the costs involved. I wish there was a way that we could implement Open Roaming without the massive cost.
Eduroam is a great example of something that also just works and to my knowledge, doesn't require a subscription fee to keep running - IIRC it relies on partnerships and federations with other RADIUS servers. But the users must of course be known and onboarded somehow.
Many years ago I was involved in Service Provider EAP-SIM/EAP-AKA to allow mobile subscribers to transparently access the wifi hotspots of their service provider - users didn't even know it was there and the "Wi-Fi just worked" - that's the dream. But boy oh boy, the effort and infrastructure to make that happen was quite massive.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide