Wireless Access

There are new business requirements for the Aruba WLAN environment I am adminitrating that require me to let users access "smart" screens via WLAN. My problem with this setup is is that technically all users from anywhere on the campus would be able to access those screens, unless I use individual WLANs (which would be counterproductive).

 

A possible solution I can think of is that I know that the controllers (a) know through which AP a user tries to access the screen and (b) the Aruba controller have firewall capabilities. Therefore, I should be able to restrict the access to the screen per AP - if Aruba provides such capabilities.

 

Is it possible to override the global ACLs for a Campus-WLAN on individual APs to provide per-AP access to specific ressources?

 

(EDIT) I should note that we use AOS6.4 on two 3600 controllers.

You can configure a user-derived role and apply it to the existing aaa profile and this will override the default user-role

https://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Content/ArubaFrameStyles/Firewall_Roles/User_Role_Assignments.htm


Thank you

Victor Fabian

Pardon typos sent from Mobile

Ah, perfect. I knew there should be a solution. User Roles just didn't occur to me. I'll check if I get the results I am after and report back.

I was trying to implement this solution and was able to create a differing ACL-set by creating a new User Role. I created a new User Rule that queries which AP a user is connecting to (attribute Location) and assigns the new User Role I created. In the corresponding AAA-profile of the WLAN I am configuring I selected that Rule as the "User derivation rules".

 

But sadly when I search for my client I can see that the default User Role is applied, despite that in the User Rule I can see the Hit-count increasing everytime I reconnect.

 

Am I missing something here?

 

We authenticate against an external RADIUS-server, could that be the reason? I thought the user derivation rules are applied AFTER the authentication?

 

Config:

aaa derivation-rules user access-media-appliances
  set role condition location equals "AP-139-1" set-value authenticated-access-media-hs4
!
user-role authenticated-access-media-hs4
 max-sessions 65535                               
 access-list session global-sacl
 access-list session apprf-authenticated-access-media-hs4-sacl
 access-list session ra-guard
 access-list session logon-control
 access-list session no_manage-access
 access-list session allowall
 access-list session v6-allowall
!
aaa profile "eduroam"
   authentication-dot1x "default"
   dot1x-default-role "authenticated"
   dot1x-server-group "hs-radius-v2"
   user-idle-timeout 30
   max-ip ipv4 wireless 3
   radius-accounting "hs-radius-v2"
   radius-interim-accounting
   user-derivation-rules "access-media-appliances"
   no wired-to-wireless-roam
   enforce-dhcp
!

Perhaps your radius is returning a role as a VSA which overrides the derivation rule, you can check it using the steps below.

 

The captures below are from a a derivation rule that applies role=derived-role due to an ap-name match (same as you have). But the radius is also returning Aruba-User-Role VSA with role=authenticated

 

 

(7005) #show aaa debug role user ip 192.168.1.20
Role Derivation History
=======================
    0: l2 role->logon, mac user created
    1: l2 role->derived-role,  handle_sta_up_dn: setting l2 role for user attributes
    2: l2 role->authenticated, station Authenticated with auth type:  802.1x

(7005) #

The UDR can be seen to be applied early from the security debug, this happens before the dot1x auth starts

 

 

Dec 6 11:21:34 :124086:  <4414> <DBUG> |authmgr|  Create macuser 0x0xf8c3c4 and user 0x0x14ec8bc.
Dec 6 11:21:34 :124093:  <4414> <DBUG> |authmgr|  Called mac_station_new() for mac 84:38:38:00:00:00.
Dec 6 11:21:34 :124103:  <4414> <DBUG> |authmgr|  Setting user 84:38:38:00:00:00 aaa profile to radcp, reason: ncfg_set_aaa_profile_defaults.
Dec 6 11:21:34 :124209:  <4414> <DBUG> |authmgr|  handle_sta_up_dn:2828 Updating vlan usage for MAC=84:38:38:00:00:00 with vlan 1 apname ap325
Dec 6 11:21:34 :124004:  <4414> <DBUG> |authmgr|  Matching `user' rules to derive role ...
Dec 6 11:21:34 :124004:  <4414> <DBUG> |authmgr|   location 'equals' ap325
Dec 6 11:21:34 :124004:  <4414> <DBUG> |authmgr|  rule:   set role condition location equals "ap325" set-value derived 
Dec 6 11:21:34 :124004:  <4414> <DBUG> |authmgr|  match_rule Value Pair to match bssid : 80:8d:b7:22:22:22
Dec 6 11:21:34 :124004:  <4414> <DBUG> |authmgr|  match_rule Value Pair to match location : ap325
Dec 6 11:21:34 :124004:  <4414> <DBUG> |authmgr|  Matching `user' rules to derive vlan ...
Dec 6 11:21:34 :124004:  <4414> <DBUG> |authmgr|   location 'equals' ap325
Dec 6 11:21:34 :124105:  <4414> <DBUG> |authmgr|  MM: mac=84:38:38:00:00:00, state=4, name=, role=derived-role, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=1.  <<<<<<<

Dec 6 11:21:34 :124004:  <3806> <DBUG> |authmgr|  Select server for method=802.1x, user=test1, essid=dot1x-vlan, server-group=cppm, last_srv <>
Dec 6 11:21:34 :124038:  <3806> <INFO> |authmgr|  Selected server cppm for method=802.1x; user=test1,  essid=dot1x, domain=<>, server-group=cppm
Dec 6 11:21:34 :121031:  <3806> <DBUG> |authmgr| |aaa| [rc_server.c:2326] Sending radius request to cppm:192.168.1.220:1812 id:58,len:188
Dec 6 11:21:34 :121031:  <3806> <DBUG> |authmgr| |aaa| [rc_server.c:2342]  User-Name: test1 

but then later the radius sends back a Aruba-User-Role VSA, which overrides the UDR

 

 

Dec 6 11:21:34 :121031:  <3806> <DBUG> |authmgr| |aaa| [rc_request.c:40] Del Request: id=66, srv=192.168.1.220, fd=84
Dec 6 11:21:34 :121031:  <3806> <DBUG> |authmgr| |aaa| [rc_api.c:1211] Authentication Successful
Dec 6 11:21:34 :121031:  <3806> <DBUG> |authmgr| |aaa| [rc_api.c:1213] RADIUS RESPONSE ATTRIBUTES:
Dec 6 11:21:34 :121031:  <3806> <DBUG> |authmgr| |aaa| [rc_api.c:1228]  {Aruba} Aruba-User-Role: authenticated  <<<<<<

Dec 6 11:21:34 :121031:  <3806> <DBUG> |authmgr| |aaa| [rc_api.c:1228]  {Microsoft} MS-MPPE-Recv-Key: \242\246o-\256\2724,\261\227\025\340h\020\365&\365`\030\026\033\206#\351a\004\3501\234\355\225&P\004\021LP\030\254\324t\274\240Mf_\365\011\014Z

Dec 6 11:21:34 :124004:  <3806> <DBUG> |authmgr|  user_download: User N/A  Router Acl(0)
Dec 6 11:21:34 :124105:  <3806> <DBUG> |authmgr|  MM: mac=84:38:38:00:00:00, state=6, name=test1, role=authenticated, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=1.
Dec 6 11:21:38 :124148:  <3806> <DBUG> |authmgr|  Create ipuser 192.168.1.20 for user 84:38:38:00:00:00.
Dec 6 11:21:38 :124156:  <3806> <DBUG> |authmgr|  Called ip_user_new() for ip 192.168.1.20.
Dec 6 11:21:38 :124004:  <3806> <DBUG> |authmgr|  sta_add_l3: mac 84:38:38:00:00:00 ip 192.168.1.20

 

 

That was it. I've managed to permit access to certain services from specific APs, as described above.

 

All I needed to do was to make my radius-server reply the configured user role in the "Aruba User Role" attribute. While this forces me to update my radius server as well as my aruba controllers, this is fine for my environment. Although I still do not know why radius is sending all those Aruba attributes, as none of it is manually configured anywhere. ¯\_(ツ)_/¯

---

@alex_dot wrote:

All I needed to do was to make my radius-server reply the configured user role in the "Aruba User Role" attribute. While this forces me to update my radius server as well as my aruba controllers, this is fine for my environment.

---

This is the way it's meant to work - it's part of a bigger story around having something like Clearpass decide what role the user is ultimately going to be in after some policy is applied.

 

It's quite common for the centralised radius to be the arbiter (and therefore the point of configuration) rather than doing things down on the controller. A more traditional way of solving your issue perhaps would be to have the radius return the desired user role for specific dot1x users (or mac addresses if needs be) that are (for example) members of some AD group or other means of grouping - no matter the AP they are on, rather than having it open for anyone that authenitcates on specific APs (maybe that's how you solved it in the end).

---

Although I still do not know why radius is sending all those Aruba attributes, as none of it is manually configured anywhere. ¯\_(ツ)_/¯

---

What other attributes are you seeing?