Aruba 7210 controller and Bradford Networks Campus Manager

[mharing]

I have an Aruba 7210 controller and Bradford Networks Campus Manager to do SNMP and RADIUS. I have a Server Group configured on the controller with server derevation rules that read "If Aruba-User-Role equals Registration set vlan 6". After connecting to the SSID, the user is Mac authenticated, but is given the default mac auth role in the 802.1x authentication profile instead of the role that Bradford is sending back. We checked on the Campus Manager and it is sending the Role back to the Aruba, but their it is using the default one. Not sure what needs to be configured or if something is missing to get this to work? Any helps is much appreciated.

[cappalli]

Does your server-group for the MAC authentication contain the Bradford servers?

[mharing]

Users are getting that default machine role instead of the role of "Registration" which is being passed back from the Campus Manager.

[cjoseph]

mharing,

Are you sure the Bradford is not sending back and Aruba VSA?  That overrides any Server derivation rule.  Turn on debugging:

config t
logging level debugging security process authmgr
logging level debugging security subcat aaa

 Do your authentication, then type "show log security 50" to see what attributes are sent back and forth and the derivation involved.

[mharing]

Ok, I have debugging enabled, but we just noticed another problem. We cannot authenticate to the campus manager, but they have an IS (microsoft radius) that campus manager uses also. We can authenticate to that, but when we try to campus manager we fail and get a server timeout. Campus manager is what is sending the aruba-user-role attribute so could this be a cause of our problem? is there a reason communication is failing on that? I have campus manager setup as a radius server.

[cjoseph]

So Campus Manager is supposed to be setup as the radius server, as a proxy to the REAL radius server.  It sorts out the mac auth and the 802.1x auth and processes for forwards based on which is which.  One thing Campus Manager should NOT do is time out and this probably should be checked into.  Take a look at your overall radius statistics with:

show aaa authentication-server radius statistics

[mharing]

Jun 10 13:35:03 :124004:  <DBUG> |authmgr|  AUTH GSM: USER DELETE uuid(0xf)
Jun 10 13:35:03 :124004:  <DBUG> |authmgr|  amon_send_payload: Sending msg to mgmt srvr - 10.10.20.220 0
Jun 10 13:35:03 :124004:  <DBUG> |authmgr|  add_USER_INFO_records: Adding AUTH User Info records, total updates 1, hash idx count 1, record_num 0, num_records_added 0 max_records 109 record_idx 0
Jun 10 13:35:03 :124004:  <DBUG> |authmgr|  add_USER_INFO_records: Sent a total of 1584 USER records
Jun 10 13:35:04 :121004:  <WARN> |authmgr| |aaa| RADIUS server CM3000--10.10.21.10-1812 timeout for client=88:53:2e:16:d5:cd auth method 802.1x
Jun 10 13:35:04 :121031:  <DBUG> |authmgr| |aaa| [rc_server.c:787] Sending radius request to CM3000-10.10.21.10-1812 (retry 2)
Jun 10 13:35:07 :121031:  <DBUG> |authmgr| |aaa| [rc_sequence.c:111] seq_num_timeout_handler: Freed 0 entries
Jun 10 13:35:08 :127037:  <WARN> |AP 24:de:c6:cc:60:f8@10.10.52.42 sapd| |ids-ap| AP(24:de:c6:46:0f:80): Station Associated to Rogue AP: An AP detected a client f0:cb:a1:79:b4:3b associated to a rogue access point (BSSID 44:ad:d9:e4:99:c0 and SSID Academic on CHANNEL 1).
Jun 10 13:35:10 :121031:  <DBUG> |authmgr| |aaa| [rc_sequence.c:111] seq_num_timeout_handler: Freed 0 entries
Jun 10 13:35:14 :121004:  <WARN> |authmgr| |aaa| RADIUS server CM3000--10.10.21.10-1812 timeout for client=88:53:2e:16:d5:cd auth method 802.1x
Jun 10 13:35:14 :121031:  <DBUG> |authmgr| |aaa| [rc_server.c:787] Sending radius request to CM3000-10.10.21.10-1812 (retry 3)
Jun 10 13:35:17 :121031:  <DBUG> |authmgr| |aaa| [rc_sequence.c:111] seq_num_timeout_handler: Freed 1 entries
Jun 10 13:35:18 :127037:  <WARN> |AP 24:de:c6:cc:60:f8@10.10.52.42 sapd| |ids-ap| AP(24:de:c6:46:0f:80): Station Associated to Rogue AP: An AP detected a client 6c:88:14:b0:e2:fc associated to a rogue access point (BSSID 58:35:d9:77:15:70 and SSID Academic on CHANNEL 6).
Jun 10 13:35:20 :124230:  <DBUG> |authmgr|  Rx message 10006/67108864, length 114 from 127.0.0.1:8476
Jun 10 13:35:20 :124004:  <DBUG> |authmgr|  mdns_message_handler : msg_type 10006
Jun 10 13:35:21 :121031:  <DBUG> |authmgr| |aaa| [rc_sequence.c:111] seq_num_timeout_handler: Freed 0 entries
Jun 10 13:35:24 :121004:  <WARN> |authmgr| |aaa| RADIUS server CM3000--10.10.21.10-1812 timeout for client=88:53:2e:16:d5:cd auth method 802.1x
Jun 10 13:35:24 :121031:  <DBUG> |authmgr| |aaa| [rc_request.c:37] Del Request: id=126, srv=10.10.21.10, fd=64
Jun 10 13:35:24 :121031:  <DBUG> |authmgr| |aaa| [rc_api.c:1029] AAA server timeout
Jun 10 13:35:24 :124004:  <DBUG> |authmgr|  Auth server 'CM3000' response=2
Jun 10 13:35:24 :124014:  <NOTI> |authmgr|  Taking Server CM3000 out of service for 10 mins
Jun 10 13:35:24 :124004:  <DBUG> |authmgr|  Select server for method=802.1x, user=host/x.lan.x.org, essid=Academic-Secure, server-group=Campus Manager, last_srv CM3000
Jun 10 13:35:24 :124038:  <INFO> |authmgr|  Selected server <> for method=802.1x; user=host/x.lan.x.org,  essid=Academic-Secure, domain=<>, server-group=Campus Manager
Jun 10 13:35:24 :124544:  <DBUG> |authmgr|  Timed Out to N/A.
Jun 10 13:35:24 :124541:  <DBUG> |authmgr|  Bring all servers in server group Campus Manager back in service.
Jun 10 13:35:24 :124015:  <NOTI> |authmgr|  Bringing Server CM3000 back in service.
Jun 10 13:35:24 :132053:  <ERRS> |authmgr|  Dropping the radius packet for Station 88:53:2e:16:d5:cd 24:de:c6:46:0f:88 doing 802.1x
Jun 10 13:35:27 :121031:  <DBUG> |authmgr| |aaa| [rc_sequence.c:111] seq_num_timeout_handler: Freed 0 entries
Jun 10 13:35:33 :127037:  <WARN> |AP 24:de:c6:cc:60:f8@10.10.52.42 sapd| |ids-ap| AP(24:de:c6:46:0f:80): Station Associated to Rogue AP: An AP detected a client 04:db:56:2b:d4:7e associated to a rogue access point (BSSID 44:ad:d9:e4:99:c0 and SSID Academic on CHANNEL 1).
Jun 10 13:35:37 :121031:  <DBUG> |authmgr| |aaa| [rc_sequence.c:111] seq_num_timeout_handler: Freed 0 entries
Jun 10 13:35:54 :124230:  <DBUG> |authmgr|  Rx message 10006/67108864, length 114 from 127.0.0.1:8476
Jun 10 13:35:54 :124004:  <DBUG> |authmgr|  mdns_message_handler : msg_type 10006
Jun 10 13:35:57 :121031:  <DBUG> |authmgr| |aaa| [rc_sequence.c:111] seq_num_timeout_handler: Freed 1 entries
Jun 10 13:36:01 :121031:  <DBUG> |authmgr| |aaa| [rc_sequence.c:111] seq_num_timeout_handler: Freed 0 entries
Jun 10 13:36:10 :124230:  <DBUG> |authmgr|  Rx message 10006/67108864, length 114 from 127.0.0.1:8476
Jun 10 13:36:10 :124004:  <DBUG> |authmgr|  mdns_message_handler : msg_type 10006

[mharing]

Checked with Bradford Support, the Campus Manager is sending the RADIUS request to the NPS server and the accept packet back to the controller, but the controller is not accepting the "accept" packet.

[cjoseph]

What is "not accepting" ?  Is there  a flat-out rejection?  Does the radius shared key match on the controller, CM and the NPS server? 

The most definitive thing you can do is a port mirror to capture the radius traffic or even better, do a pcap for whatever udp port on the controller you are using for radius using the guide here:  https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-712

[cjoseph]

If you are using ArubaOS 6.3 and above, you should do a packet capture like this:

config t
packet-capture controlpath udp 1812 <assuming that is your radius server port>
packet-capture destination local-filesystem

 Then you should be able to see the radius traffic back and forth:

(192.168.1.3) #show packet-capture controlpath-pcap

13:09:37.747800 IP 192.168.1.3.32847 > 192.168.1.32.1812: RADIUS, Access Request (1), id: 0x1b length: 204
13:09:37.790675 IP 192.168.1.32.1812 > 192.168.1.3.32847: RADIUS, Access Challenge (11), id: 0x1b length: 76
13:09:37.797032 IP 192.168.1.3.32847 > 192.168.1.32.1812: RADIUS, Access Request (1), id: 0x1c length: 223
13:09:37.800312 IP 192.168.1.32.1812 > 192.168.1.3.32847: RADIUS, Access Challenge (11), id: 0x1c length: 76
13:09:37.807616 IP 192.168.1.3.32847 > 192.168.1.32.1812: RADIUS, Access Request (1), id: 0x1d length: 322
13:09:37.814378 IP 192.168.1.32.1812 > 192.168.1.3.32847: RADIUS, Access Challenge (11), id: 0x1d length: 939
13:09:37.837885 IP 192.168.1.3.32847 > 192.168.1.32.1812: RADIUS, Access Request (1), id: 0x1e length: 361

 After that, if you collect the logs.tar, you should be able to see the filter-pcap file that will detail the captured traffic in .pcap format.