Aerohive RADIUS Server and non-Aerohive RADIUS NAS Clients

  • 1
  • Question
  • Updated 4 years ago
  • Answered
Can an Aerohive AP RADIUS Server authenticate on behalf of non-Aerohive NAS authenticators?

We're trying to add wired 802.1X authentication via AD on a Cisco switch after wireless 802.1X auth has already been implemented. I'm seeing documentation that the AAA server can only authenticate other Aerohive devices, and no real options in HiveManager for interoperability with non-Aerohive authenticators.

Are we stuck with moving AAA services to NPS instead?

Photo of Steven Bateman

Steven Bateman

  • 65 Posts
  • 12 Reply Likes

Posted 4 years ago

  • 1
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
The help file only mentions  Aerohive RADIUS authenticators

but there are no restrictions from creating aaa clients/nas that I can see

I am interested in your results. are your supplicants failing?

I've gotten this working with clearpass and acs, but have not tried with Aerohive AP due to eDirectory issues

aaa authentication dot1x default group radius
aaa accounting dot1x default start-stop group radius

dot1x system-auth-control

aaa server radius dynamic-author
 client server-key 7 xxxxxxxxxxxxxxx
 port 3799
 auth-type all

interface GigabitEthernet1/0/2
 switchport access vlan 111
 switchport mode access
 switchport nonegotiate
 authentication port-control auto
 dot1x pae authenticator
 dot1x timeout quiet-period 2
 dot1x timeout tx-period 2
 spanning-tree portfast
 spanning-tree bpduguard enable

Photo of Steven Bateman

Steven Bateman

  • 65 Posts
  • 12 Reply Likes
I added the Cisco switch to the NAS clients and once the switch was configured supplicants did authenticate, but were not dynamically assigned VLANs based on identity/user profile. Once I researched the documentation and also checked via the RADIUS access test tool, I found that the Aerohive AP is returning the user profile attribute instead of a VLAN assignment. This completely makes sense if the authenticator is an Aerohive device, as the VLAN assignment is part of the user profile.

But returning a user profile attribute number obviously means nothing to a Cisco switch. What I couldn't figure out is if there are methods of returning custom attributes FROM an Aerohive AAA server TO an a non-Aerohive authenticator upon successful authentication. From an example configuration guide the Cisco switch needs the following vendor-specific attributes returned:

Assign vendor-specific tunnel attributes in the RADIUS server. The RADIUS server must return these attributes to the switch:
[64] Tunnel-Type = VLAN
[65] Tunnel-Medium-Type = 802
[81] Tunnel-Private-Group-ID = VLAN name or VLAN ID

Attribute [64] must contain the value VLAN (type 13). Attribute [65] must contain the value 802 (type 6). Attribute [81] specifies the VLAN name or VLAN IDassigned to the IEEE 802.1x-authenticated user.

Since the Aerohive AAA server presumably is returning only the user profile attribute number, the Cisco switch considers the VLAN assignment not valid. Authentication succeeds though, and the user is placed on the VLAN for which the port was previously configured.

If 802.1x authentication is enabled but the VLAN information from the RADIUS server is not valid, authorization fails and configured VLAN remains in use. This prevents ports from appearing unexpectedly in an inappropriate VLAN because of a configuration error.

There's also the problem of Aerohive AAA servers using different tunneling methods than Cisco, but I'm not sure how big of a problem that is yet.

Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2487 Posts
  • 449 Reply Likes
Yup, this doesn't appear to be supported. I think you'll end up having to kick up that instance of Network Policy Server or FreeRADIUS for your use case.
Photo of Steven Bateman

Steven Bateman

  • 65 Posts
  • 12 Reply Likes
Sounds good, I figured as much.

Maybe this could be a feature request? Returning custom attribute values doesn't seem too difficult. Again, not sure about whether the tunneling differences between vendors would be a sticky problem.