RADIUS/NPS Server configurations

  • 1
  • Question
  • Updated 4 months ago
  • Answered
When you follow the AH directions for configuring an external RADIUS Server and it's an NPS server, everything seems to work except that I seem to have a high level of intermittent assignations of the default user profile, which is set to disassociate users, as Crowdie suggests here

Another option is to create a user profile that has a schedule availability that cannot be matched (say 00:00 to 00:01 on the 1st of January 2012) so that if a wireless client is authenticated but not matched into a User Profile they will be de-authenticated. 
Now, in another thread, Nick Kanaef says that he got his configuration working by adding the various Tunnel attributes. I've confirmed that without the tunnel attributes configured the way he he has them, the RADIUS Server test does not seem to indicate the proper attribute being returned from the RADIUS server, but authentication does seem to work in general. On a test profile with the tunnel attributes being set the RADIUS Server test does indicate the designated UPID being returned, i.e.
RADIUS server is reachable. Get attributes from RADIUS server: User-Attribute-ID:0=2006;
where 2006 is the Tunnel-Pvt-Group-ID attribute and is also the user profile id set in the user profile that the Filter-Id attribute matches.

So what's going on here? Would modifying my production NPS settings to include the Tunnel-Medium-Type, Tunnel-Pvt-Group-ID, and Tunnel-Type attributes solve the mysterious default-profile issue? Or is there some other issue? 
Photo of J. Goodnough

J. Goodnough, Champ

  • 265 Posts
  • 32 Reply Likes

Posted 4 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I suggest using a RADIUS standards based configuration and just use the Filter-Id to set the user profile. Why are you using some sort of hybrid configuration?

From the Aerohive perspective in a VLANed environment, you are either meant to:

  • Set the Tunnel-Type to GRE with the Tunnel-Medium-Type set to IP if you intend to use the Tunnel-Private-Group-ID as the user profile attribute, setting the VLAN via the profile.
OR
  • Set the the Tunnel-Type to VLAN with the Tunnel-Medium-Type set to 802 and use the Filter-Id attribute to set the profile.
For 802.1X, RFC3580 states that the following basic attributes should be present:

"Tunnel-Type=VLAN (13)
Tunnel-Medium-Type=802
Tunnel-Private-Group-ID=VLANID"

The Filter-ID is documented in the RFC as follows:

"3.9. Filter-ID

This attribute indicates the name of the filter list to be applied to
the Supplicant's session. For use with an IEEE 802.1X Authenticator,
it may be used to indicate either layer 2 or layer 3 filters. Layer
3 filters are typically only supported on IEEE 802.1X Authenticators
that act as layer 3 devices."
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Aha - in my configuration I was missing the tunnel-medium-type attribute. Adding that in seems to cause the proper RADIUS Test results. I'll see if it solves the issue with the default profile being selected as well.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Are you using the older Aerohive vendor specific Tunnel-Type of GRE or using the standards based Tunnel-Type of VLAN?

Ideally, return the VLAN for the client in the Tunnel-Private-Group-ID attribute, decoupling the VLAN from the user profile.
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
That is all correct! :)
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Originally, I had this set up to just return Filter-Id, Framed-Protocol, and Service-Type. The RADIUS Server test tool would return no attributes, but auth would actually work correctly - faculty would get into the faculty vlan, students would get into the student vlan, because the Filter-Id mapping did seem to be working properly.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
It should, in theory and abstractly, be possible to set just the Filter-Id, Framed-Protocol and Service-Type attributes, omitting all of the Tunnel attributes and relying on the VLAN configuration in the user profile. I am not sure how well tested and supported this will be though and, from what you are observing, it might not be particularly reliable.
(Edited)
Photo of pstejskal

pstejskal

  • 2 Posts
  • 0 Reply Likes
Hello, I am trying to implement: if a user is member of AD group Staff they are put on VLAN 4 and if a member of AD group Students they are put on VLAN5.  I am really lost! Aerohive phone support can't figure out the RADIUS group ID part so I am stuck.  Also I am a novice at RADIUS so a lot of the terminology is over my head.  Do you have steps or instructions on how to set this up from start to end?  peter at maclay dot org
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
What RADIUS server are you using?
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
I am planning to implement sectorized VLANs on campus soon, as seen here. So at that point I'd need to modify these attributes to the AH-specific GRE style?

Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
You would not use the Filter-Id to map to a user profile as you are instead setting it via the Tunnel-Private-Group-Id so are in undefined behavior territory doing it twice, especially if they differ!

I actually think all of this could do with being documented a little better...
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
100% agree this could be documented better. In any case, this current setup works in limited testing, but the test profile only has a single VLAN, so there is no conflict. I did just remove the Filter-Id attribute from the above testing configuration, and auth continues to work - as expected. Thanks.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Sorry, I did not actually answer your question directly. Yes, you would probably want to use the Aerohive vendor specific GRE style at that point.

This does not have any negative implications at all as you want to do something vendor feature specific when you leave the VLAN assignment up to HiveOS and its configuration in that way rather than using what the RADIUS server returns in the Tunnel-Private-Group-Id.

It should, in theory and abstractly, be possible to set just the Filter-Id, Framed-Protocol and Service-Type attributes, omitting all of the Tunnel attributes and relying on the VLAN configuration in the user profile. I am not sure how well tested or supported this will be though and, from what you are observing, it might not be particularly reliable.
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Well, I can confirm that using just the Filter-Id, Framed-Protocol and Service-Type attributes "works", inasmuch as that's what I've been doing up to this point. I do have this issue where I have about 16% as many messages indicating that the default profile has been issued because a station has been disassociated e.g. <182>amrp2: receive event STA leave: 1234:5678:e90ab de-associate wifi0.1 upid 666 vlan 0 flag 0x00000000 as I do RADIUS auth/reauth messages e.g. <182>radiusd[1308]: RADIUS: The RADIUS server accepted user 'user_name@school.org' through the NAS at 172.24.4.52.

This definitely means people are getting de-associated for user profile reasons a decent percentage of the time when trying to auth/reauth, but it seems to be rather randomly distributed. I wonder if an Aerohive employee could weigh in? There doesn't seem to be any reason that this should be happening. As I understand it, Aerohive should assign the default profile in the event it is returned a Filter-Id (and/or?) a Tunnel-Private-Group-ID attribute it cannot match against a user profile in the SSID configuration. I know that all four Filter-Id attributes that could be returned do match user profiles, and I've seen this behavior on devices that then do immediately successfully get assigned a non-default user profile -- as seen here, chronologically from bottom to top:


Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
The major use case for using a Filter-Id to map to a user profile is that, as the Tunnel-Private-Group-Id can then specify the VLAN id, it does allow the VLAN used for a client's session to be decoupled from the user profile applied and be controlled by the RADIUS server.

There is also the concern of the Filter-Id being vendor agnostic, but I do not suspect that such agnosticism and being standards based was a major driving force for adding the feature.
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Also, for the start of today I used the Filter-ID, Framed-Protocol, Service-Type, Tunnel-Medium-Type (802), Tunnel-Pvt-Group-ID (VLAN #), Tunnel-Type (VLAN) configuration.

This does not appear to have cut down on the default profile assignments, but it does make the RADIUS Test tool return the VLAN-ID attribute.
Photo of sam lujan

sam lujan

  • 10 Posts
  • 0 Reply Likes
I am new to Aerohive and we have a virtual radius setup on our Windows 2012 R2 box. This is my first time and could use some direction as far as the settings on the windows side. Much appreciated... 
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Windows NPS is a full-fledged RADIUS server. You'll need to make some Network Policies, where the returned Filter-Id matches the name of the Aerohive Local User Group -> User Group Name, which will need to have the same User Profile Attribute as the matching User Profile.