What attributes are need to CoA to change a user-profile

  • 1
  • Question
  • Updated 3 years ago
What attributes specifically are needed to dynamically change a user's user-profile via CoA.

I understand what is required if during auth we want to give them a particular user-profile, but what what about changing 'on the fly', without doing something disruptive like terminating the session?
Photo of wombat

wombat

  • 62 Posts
  • 3 Reply Likes

Posted 3 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi wombat,

Taking a step back, for auth, to set a user profile you are either meant to:

  • 1) Set the Tunnel-Type to GRE with the Tunnel-Medium-Type set to IP if you intend to use the Tunnel-Private-Group-Id value as the user profile attribute, setting the VLAN where desired via the one defined in the user profile. This VLAN is then coupled to the user profile therefore. There should be a Service-Type set to Framed and a Framed-Protocol set to PPP.
OR
  • 2) Set the the Tunnel-Type to VLAN with the Tunnel-Medium-Type set to 802 and use the Filter-Id attribute to set the value that references the user profile (or another attribute of choice, although I have no idea why anybody might do this?). The VLAN is decoupled to one defined in the user profile as it is overridden. This is really useful in complex, rich network environments. There should be a Service-Type set to Framed and a Framed-Protocol set to PPP.
From comments passed back to me from the development team, although I have not tested this first hand, I understand that with CoA once a session exists, you can at present only use the first method along with a session identifying attribute, such as the Acct-Multi-Session-Id or Acct-Session-Id.

The second method, that allows the VLAN to be decoupled as it overrides any set in the user profile, is apparently not supported via CoA. (I have raised this previously during a beta process many months back but think it got misunderstood by engineering and I honestly did not push or chase hard to get full clarification.)

I will therefore chase this again to get clarification and do some first hand testing.

For reasons explained in my other post, to which you are no doubt referring, you should identify the session desired via the Acct-Multi-Session-Id and not the Acct-Session-Id due to the interaction between BSS transition and RADIUS accounting - there's a race condition. This requires HiveOS 6.6r1, it was not supported in HiveOS 6.4r1.

To change a user profile via CoA, you need HiveOS 6.6r1. It is not supported in HiveOS 6.4r1, 6.5r1 or 6.5r2.

Cheers,

Nick
(Edited)
Photo of wombat

wombat

  • 62 Posts
  • 3 Reply Likes
Nick, thanks for the detailed response.  I am not sure what your original post was anyway.

I can easily change the user-profile during the next mac-auth, but as you know the time before the next mac-auth can vary wildly depending on the client. 

I am sure I can easily force this by sending a disconnect as a CoA, but would rather switch the user-profile silently in the background without the device having to go through a disconnect, then reconnect.

The help guide says "you can enable the dynamic authorization extension provided in RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS). "Disconnect" messages terminate a user's session immediately, and CoA messages modify session authorization attributes such as VLANs and user profile IDs."

That's great, but please please tell me how to do it in the guide.  Right now I am left with working it out for myself using trial and error.

Anyhow, hopefully I will crack this and be able to report back tomorrow.  Using 6.6 anyway, so that should be fine.

:-)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Yes, the documentation is non-existent here. For MAC authentication, the Calling-Station-Id would be the session identifying attribute. (No RADIUS accounting presently occurs for anything but 802.1X.)

The Service-Type is Call-Check for MAC authentication and not Framed.

An open question for example is... What's the order or precedence applied for session identifying attributes by HiveOS? Which exact session identifying attributes can we use?

I should have mentioned that there's Disconnect-Request and CoA-Request packets that have different semantic meaning depending on whether you want to disconnect a session or change the nature of of it. I assumed you would already knew this so didn't mention this initially.

The other thread to which I was referring was: https://community.aerohive.com/aerohive/topics/radius-server-out-of-the-box
(Edited)
Photo of wombat

wombat

  • 62 Posts
  • 3 Reply Likes
I've stumbled at the first hurdle.

Set the Tunnel-Type to GRE with the Tunnel-Medium-Type set to IP if you intend to use the Tunnel-Private-Group-Id value as the user profile attribute.

This doesn't even work at the moment.  The device just ends up in the default profile.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Wombat,

Firstly, looking back at my notes from December 2014, CoA reassignment was actually added in 6.4r1 and not 6.6r1.

It is 6.6r1 that allows CoA to reference a session via the Acct-Multi-Session-Id.

The comment that I had passed back to me from engineering at the time that I was querying this was:

 The feature:
1.      RADIUS server can return user’s profile to AP by using Attribute #11 “Filter-Id” and carry the attribute # matching what’s in the User Profile.
2.      The VLAN will change if needed based on the User Profile.
3.      Check the Accept CoA, then RADIUS can send CoA back to AP anytime and carries the new attribute # (which matches the new User Profile) – and AP will change user to the new user profile.

So I made a mistake, it was intended when it was introduced to use the Filter-Id attribute and not the Tunnel-Private-GroupId. It may not therefore work via the Tunnel-Private-Group-Id method. (Oops, sorry, I probably sent you down a blind alley.)

My response back at the time was:

The problem with that is that the VLAN is then coupled to the user profile and cannot be set independently by the RADIUS server.

It doesn't match the implemented behaviour for initial authorization with an Access-Accept and should, I think, therefore be deemed a bug.

When an Access-Accept is sent, the VLAN can be be set independently to the user profile by using a Tunnel-Type of VLAN rather than GRE.

There, with the Tunnel-Type set to VLAN, the Tunnel-Private-Group-Id is authoritative and overrides any VLAN set in the user profile. (The user profile itself specified by the Filter-ID AVP.)

I do think that we need to get clarification on how this feature has actually been implemented. In my opinion, it does not look like it has been thought through completely. It may have been added to interop with something specific.

Comment was also passed back to me that:

We will not need to change Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id. 

This also does not make sense as it means that there would be different semantics between initial auth and CoA. It probably needs revising by engineering therefore.

Cheers,

Nick
Photo of wombat

wombat

  • 62 Posts
  • 3 Reply Likes
So I tried a standard dot1x and am able to put the user into a particular user-profile based on those attributes.  At least that works as per the documentation.

Tunnel-Type = GRE
Tunnel-Medium-Type = IPv4
Tunnel-Private-Group-Id = <attribute no>

But unfortunately, this does not work when the method is using mac-auth.

So, onto the CoA.  Interestingly I can do a CoA disconnect when using the dot1x.  I can also do a CoA to switch the user-profile, which works nicely as well.



Now if only it would behave the same way if the auth method was mac-auth.  I am still returning the same attributes, so can't understand how this is different.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi,

Indeed, as no RADIUS accounting occurs for MAC address authentication, we have no Acct-Session-Id or Acct-Multi-Session-Id attributes to work with for CoA.

Only things like the Calling-Station-Id and User-Name attributes could be session identifying attributes therefore.

I suspect that this simply fell outside of the scope of the feature.
(Incidentally, I never use MAC address authentication with 802.11 NASes.)

It would be great to see RADIUS accounting occurring for other authentication types.
The Service-Type attribute would differentiate the type of authentication that accounting is occurring for, be it 802.1X, MAC address authentication or CWP.

There is complexity in the case that more than once authentication type takes place. Take for example 802.1X where subsequent MAC address authentication takes place.

Should accounting occur independently and simultaneously for each authentication type for the same client? If not, which authentication type should take precedence as the one that ends up being accounting for? Should it be configurable?

Cheers,

Nick
(Edited)
Photo of wombat

wombat

  • 62 Posts
  • 3 Reply Likes
Attributes sent back to the Aerohive as part of mac-auth are simply ignored.  If the exact same attributes are sent back as part of a dot1x, it works fine.
This is disappointing, especially since it is possible on other vendors.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Yup, it would be great to see this improved as the primitives just are not there at the moment.

The RADIUS accounting side has been asked for before by a few people:

https://community.aerohive.com/aerohive/topics/perform_radius_accounting_for_ppsk_and_psk_access

https://community.aerohive.com/aerohive/topics/ppsk_radius_accounting
(Edited)