I'm trying to determine if there's a way to achieve the following:
An 802.1x client authenticates onto the network.
By virtue of the credentials we leverage the WLC's AAA override feature and redirect that client to a specified interface on the WLC. That interface effectively generates a splash page (provided by the WLC) that says something along the lines of "Your credentials work" but dead ends the client at that point - not giving it network access.
Is there such a methodology?
Are you using ISE as your RADIUS server?
You probably could do it using ISE.
So your really trying to setup a SSID so users can check if their credentials work? Wouldn't access to the network confirm that and a splash page if they fail be a better idea?
ISE is yet to be integrated into our environment.
I'm not looking to provide an SSID so users can confirm that credentials work. The situation we're trying to address is as follows - our institution is a member of the Eduroam consortium. Subsequently, we support the 'eduroam' SSID/service across our network. The idea is to prevent users affiliated with our institution from using the service. Reason being their associations to the eduroam network will not allow access internal network resources (this is a guest network) and we want to eliminate its use since eduroam is a dual band network and any number of clients will gravitate to 2.4 GHz - not the place to be in our high volume, high AP density environment. I was hoping there was a way we could identify clients using our realm on that SSID as part of their username and subsequently deny them access directly on the WLC - presenting sort of a Webauth splash page.
> if from @ourUNI.XXX then drop onto staff or student segment, if from visiting institute then to drop to guest.
Definitely a viable solution to redirect clients onto our internal 802.1x network - which addresses access to internal resources. But we'd still have the 2.4 GHz client issue.
We run eduroam as dual band so as to be as inclusive as possible. (I'd love to make it a 5 GHz only service)
Rather than deny access to 2.4GHz, perhaps consider the RF component and using technology like band select or limiting the amount of associations per-radio on 2.4GHz to keep it cleaner. We prefer to keep 2.4GHz on for backwards compatibility, but the reality is that with 2.4GHz enabled, you will likely have more customers with a poor experience than if you turned it off altogether (where *only* 2.4GHz-only devices will be unable to connect).
You can always set the Radio Policy on the SSID to be 5GHz only.