Reject user when Filter-id is wrong

  • 1
  • Question
  • Updated 3 years ago
Hi,

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.

Regards,
Jonas Dekkers
Photo of Jonas Dekkers

Jonas Dekkers

  • 152 Posts
  • 29 Reply Likes

Posted 3 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I am curious why/where one would ever legitimately / knowingly be in the position of returning a Filter-Id that cannot be mapped to a user profile?

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?
(Edited)
Photo of Carsten Buchenau

Carsten Buchenau, Champ

  • 356 Posts
  • 117 Reply Likes
Nick, I recently had a similar use case.

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.

carsten
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hmm... Respectfully disagree, I think it's too much complexity and in the wrong place.

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.
(Edited)
Photo of Jonas Dekkers

Jonas Dekkers

  • 152 Posts
  • 29 Reply Likes

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

Photo of Carsten Buchenau

Carsten Buchenau, Champ

  • 356 Posts
  • 117 Reply Likes
Nick: You are right, I fully agree on the architecture point. In my case I was working with a legacy Radius installation on the customer site (Periodik Labs’ Elektron), and I could not persuade it to not authorize a user when the request came from certain APs. Maybe a configuration issue on the Radius server. But roaming seemed to be an issue as well, as students could authenticate on another AP and then walk over.

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.

carsten
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I would probably use the NAS-Identifier in preference to the NAS-IP-Address, but both are completely acceptable choices to discriminate on.

Yes, roaming would be the other issue for many reasons...

Actually, because of that alone, this sounds like a bad idea, I would not try to do this as it is likely to cause service availability issues for clients.

For example, one could hack up a scheme to check the RADIUS accounting information and use CoA to terminate a client's connection if it roams where it is not meant to be. Ugly though as it does not stop the client roaming in the first place...

Personally, I would be minded to not bother or to use different SSIDs to solve this, assuming too many of them wouldn't be needed!

A conceptual AP availability and roaming restriction policy could only be properly enforced by the APs themselves. I am not convinced though that it would be worth the time and effort for this to be engineered though.
(Edited)
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
Leaving aside the architectural design debate, Nick hit on the key point above.  If those without a filter ID are falling into the default user profile and you don't want them to have access, make the default user profile a black hole.  Set the default user profile for a vlan that does not exist, or a firewall policy that Denies everything, or a user profile availability schedule that is never available.

Just make sure that all approved connections get to a different user profile, one that has access to the network.
 
Photo of Jonas Dekkers

Jonas Dekkers

  • 152 Posts
  • 29 Reply Likes
Okay I will try to work with the nas id. Sending a gues to vlan that not exist wil be confusing I thinks. First he gets login succeeded and than he can't surf. Thanks for the help you all!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Would it not be better to use a different SSID?