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?
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
aaa server radius dynamic-author
client 192.168.1.1 server-key 7 xxxxxxxxxxxxxxx
switchport access vlan 111
switchport mode access
authentication port-control auto
dot1x pae authenticator
dot1x timeout quiet-period 2
dot1x timeout tx-period 2
spanning-tree bpduguard enable
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:
– Tunnel-Type = VLAN
– Tunnel-Medium-Type = 802
– Tunnel-Private-Group-ID = VLAN name or VLAN ID
Attribute  must contain the value VLAN (type 13). Attribute  must contain the value 802 (type 6). Attribute  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.
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.