I use CWP with an external Radius Server. Is it possible to reject a login if the Filter id of the user doesn't match the filter of the User group/user profile? At the moment the user receives the default User Profile if the filter id doesn't match.
I have multiple user groups all linked with his specific user profile. If the filter id matches the user is assigned to the right User Profile. So this part is working fine.
Where it is wanted to reject a login, RADIUS servers should be returning an Access-Reject.
That said, I can see definite merit in making HiveOS explicitly reject to give the explicit feedback that something needs fixing rather than falling back to the default user profile.
It is in the position where it could treat the Access-Accept as being an Access-Reject.
There can easily be security implications if the configured default profile is permissive.
What is your use case/rationale for wanting this behaviour?
One SSID for Students and Faculty, but Students are not supposed to connect on certain APs. I would have loved to do this all on one Network Policy and use device tags as additional decision point for user profile selection with the possibility to reject connections in a condition like "if filter-id = student and device-tag1 = dormitory then reject" - but that's not possible.
So I created 2 network policies with 2 SSID profiles, same SSID. The NP for the "dormitory APs", where students are not allowed to connect to, are still authorizing them - cannot reject them - but I overwrite the VLAN and put them into one that doesn't work. Not the most elegant, but it has the desired effect...
Now, if we would be able to use more conditions for authorization, as by above example, that would make it much cleaner and more versatile.
Ultimately, I feel that auth should entirely be up to the RADIUS server and it should pass back the right attributes in the Access-Accept, giving a proper separation of concerns and avoiding, where possible, modifying things post facto after authorization has completed. But heck, I'm a bit of a architectural layering purist...
My view is that where NPS wasn't/isn't flexible and rich enough from a configuration perspective to play nicely for a particular use case, I'd use FreeRADIUS or Radiator.
I'm sorry radius server and radius attributes are pretty new for me. So maybe I'm trying something that can be solved very easily with some other configuration.
Here is the situation:
There is only one Radius server for the guest part of multiple locations. Guest from one location may not login on another location. Also all locations have their own hivemanager. I thought I could solve this with the filter id. For example for every in Location A i make a filter-id: Guest-locationA (for location B filter id Guest-locationB,....). So in hivemanager for location A I have made a user group "Guest-locationA" and if someone from location B is tried to login I thought it would be rejected.
Another solution or workaround (example: use of other radius attributes) is more than welcome :-D
Anyway - Jonas: In your case your are using the NAS IP (Aerohive AP) to identify the location of the connecting station, right? So as Nick said, ideally you configure the Radius server to check for requesting location (NAS IP) and account location group - if they don't match, you return a noauth.
The user profile assignment on the Aerohive system assumes that authorization has been granted, and now it's purely about putting the user into the right bucket, so to speak.
Just make sure that all approved connections get to a different user profile, one that has access to the network.