Confused about RADIUS return Attributes for user profiles

  • 1
  • Question
  • Updated 4 months ago
Hi:
I'm confused about how to return attributes from a RADIUS server to assign user profiles to users. In my research I've discovered two methods:

Method 1:
Authenticate via RADIUS to AD, and based on the user’s AD groups, 
return a filter-id attribute that contains the name of an Aerohive user group.
That Aerohive user group has an Aerohive user profile attribute that matches the Aerohive user profile we want for that user.

Method 2:
Authenticate via RADIUS to AD, and based on the user’s AD groups, 
Return 3 values:
Return: Tunnel-Type set to GRE
Return: Tunnel-Pvt-Group-ID set to user profile attribute number that matches the Aerohive user profile we want for that user.
Return: Tunnel-Medium-Type set to IPv4

Do both of these work? Does one work better? Is one being depricated?

Thanks for the info!
Photo of Aeroboy

Aeroboy

  • 4 Posts
  • 0 Reply Likes

Posted 7 months ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes

Hi Aeroboy,

For the RADIUS attributes used in the Access-Accept, originally, Aerohive used the GRE Tunnel-Type in a non-standard based way in HiveOS to signify that the Tunnel-Private-Group-Id contains a UPID (User Profile id) and not a VLAN id, along with setting the Tunnel-Medium-Type to IP.

We now have two different methods of user profile assignment via RADIUS, the legacy, non-standard method and a newer, standards based method. The benefit of the newer method is being able to override the VLAN defined in a user profile, being standards compliant means it often can be used with other standards-compliant vendors reducing the need for more complex RADIUS server configuration, thus it is more compatible. There is no impact on performance or security using either method, and we are not deprecating the original method.

If you intend to use the Tunnel-Private-Group-Id as the user profile attribute, using the VLAN defined in the user profile (legacy method, not standards based):

Framed-Protocol set to PPP
Service-Type set to match that in the Access-Request (differs based on 802.1X, MAC auth etc)
Tunnel-Type set to GRE
Tunnel-Medium-Type set to IP
Tunnel-Private-Group-Id set to the UPID

If you intend to use the Filter-Id to map a user profile, using the VLAN defined in the user profile (newer, standards based method):

Framed-Protocol set to PPP
Service-Type set to match that in the Access-Request (differs based on 802.1X, MAC auth etc)
Filter-Id set to the value configured to map to a user profile

If you intend to use the Filter-Id to map a user profile, overriding the VLAN defined in the user profile (newer, standards based method):

Framed-Protocol set to PPP
Service-Type set to match that in the Access-Request (differs based on 802.1X, MAC auth etc)
Filter-Id set to the value configured to map to a user profile
Tunnel-Type set to VLAN
Tunnel-Medium-Type set to 802
Tunnel-Private-Group-Id set to the VLAN ID

If you intend to use the user profile that the client gets by other means, just overriding the VLAN defined in that:

Framed-Protocol set to PPP
Service-Type set to match that in the Access-Request (differs based on 802.1X, MAC auth etc)
Tunnel-Type set to VLAN
Tunnel-Medium-Type set to 802
Tunnel-Private-Group-Id set to the VLAN ID

Hopefully this answers your question, please ask if you need more detail.

Regards,

Nick

(Edited)
Photo of Will Rhodes

Will Rhodes

  • 45 Posts
  • 9 Reply Likes
Hi Nick,
  Great breakdown of the different methods. I was testing the second method listed but can not get the profile to assign correctly. All I get is the default profile. I took a look at the response in wireshark and verified the filter-id is being passed correctly but the default user profile is assigned. Any ideas? 
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Are you using HM Classic or HMNG?
Photo of Will Rhodes

Will Rhodes

  • 45 Posts
  • 9 Reply Likes
Classic
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Will,

We usually find that https://d2r1vs3d9006ap.cloudfront.net/s3_images/966765/filter-id.png?1380845703 hasn't been completely followed and/or the User Profile Application sequence has not been configured or correct where MAC auth or CWP auth is being used as the default is to give the SSID the highest priority.

(For 802.1X, the User Profile Application sequence does not come in to play.)

Cheers,

Nick
Photo of Aeroboy

Aeroboy

  • 4 Posts
  • 0 Reply Likes
Hi Will:
I'm curious if you ever got the filter-id method working?
Thanks
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Aeroboy,

I should further add that you do not have to user the Filter-Id attribute to map to a user profile and can pick another attribute of your choice from the drop down menu, but doing so is strongly discouraged.

At the HiveOS CLI behind the scenes, the Filter-Id is used by default as this is the standards-based attribute to use. This is not currently made clear in the HM Classic and HMNG UI which currently offers a dropdown of many possible attributes. (I hope to get that changed!)

Regards,

Nick
Photo of Aeroboy

Aeroboy

  • 4 Posts
  • 0 Reply Likes
Hi Nick:
Thank you! for your very detailed and articulate response!
It's also good to know the history behind it. I'd never heard of setting a Tunnel-Type to GRE, so I suspected it was an older method.

It's also good to know I can change the VLAN along with sending the filter-id. But my preference would probably be create separate profiles, like employee_100, employee_200, etc., and assign each profile a different VLAN. That seems cleaner to me.

So otherwise, the graphic in this post is correct?
https://community.aerohive.com/aerohive/topics/what_radius_attributes_can_i_configure_in_hivemanager...

Another follow up question: 
With any RADIUS server I've worked with, I've never had to return the Framed-Protocol set to PPP, nor the Service-Type set to match that in the Access-Request. Are these usually set automagically and the proper value is returned? With most equipment I've just returned the proper filter-id, and it worked.

Thanks!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Aeroboy,

It is a question of correctness for the Service-Type. For this attribute, RFC 2865 states of it for an Access-Accept:

"A NAS is not required to implement all of these service types, and MUST treat an unknown or unsupported Service-Types as though an Access-Reject had been received instead."

HiveOS uses a different Service-Type based on whether 802.1X, MAC auth, CWP auth or the RADIUS test tool is being used.

If there is a mismatch, technically it should be handled as an Access-Reject.

(If you omit the Service-Type attribute or send one that mismatches, HiveOS will currently ignore this but this could change.)

Setting the Framed-Protocol to PPP, this attribute is currently ignored by HiveOS but there is a convention of returning it. Things like NPS I think will do this by default for 802.1X.

Thanks,

Nick
(Edited)
Photo of Aeroboy

Aeroboy

  • 4 Posts
  • 0 Reply Likes
Hi Nick:
Great info, once again.

So it sounds you're saying that I can ignore those two attributes for now, but I do so at my own peril? :-)

But if I want to be standards compliant:

1) I would set Framed-Protocol to PPP.

2) I'm not clear about a different setting for Service-Type based on 802.1X, MAC Auth, etc.?

What would I set Service-Type to? (1) Login? That's the only setting from this list that makes sense to me.

................................................................................
From RFC 2865

The Value field is four octets.

       1      Login
       2      Framed
       3      Callback Login
       4      Callback Framed
       5      Outbound
       6      Administrative
       7      NAS Prompt
       8      Authenticate Only
       9      Callback NAS Prompt
      10      Call Check
      11      Callback Administrative
................................................................................


Is there a different setting to use for each AuthN type?

Thanks for helping me dig into the RADIUS weeds. This is awesome info!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes

Hi Aeroboy,

The following Service-Types are used by HiveOS:

1) 802.1X - Framed
2) MAC address auth - Call-Check
3) CWP auth - Login
4) RADIUS test - Authorize-Only

Sorry for the delay in my response to this.

We noticed a regression in 8.2r1 from 6.5r8b where the Service-Type attribute is currently missing for CWP auth. We are getting that corrected with a subsequent release.

Thanks,

Nick
(Edited)
Photo of Marco Scano

Marco Scano

  • 5 Posts
  • 0 Reply Likes
Hi Nick, I have a question: Now we have 802.1x authentication with NPS that push different vlans to different group-user. Is it possible to avoid vlan override from NPS,if Aerohive fingerprint match a particular OS and then use the user profile pushed by hivemanager?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Marco,

The operating system match takes place after 802.1X authentication and association via DHCP snooping or HTTP header user agent snooping. Therefore, it is not conceptually possible for the VLAN override in the Access-Accept to be avoided.

Regards,

Nick
Photo of Marco Scano

Marco Scano

  • 5 Posts
  • 0 Reply Likes
I'm sorry, but I don't understand your answer, because in my enterprise seems that the rules that assign the VLAN 14 (see attached image below), is bypassed and I take the VLAN pushed by NPS...