Wireless Access

last person joined: 18 hours ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

User Derived Role not applied - was: AP-specific ACL

Jump to Best Answer
  • 1.  User Derived Role not applied - was: AP-specific ACL

    Posted Nov 29, 2018 05:12 AM

    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.



  • 2.  RE: User Derived Role not applied - was: AP-specific ACL
    Best Answer

    Posted Nov 29, 2018 07:28 AM
    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


  • 3.  RE: User Derived Role not applied - was: AP-specific ACL

    Posted Nov 30, 2018 06:21 AM

    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.



  • 4.  RE: User Derived Role not applied - was: AP-specific ACL

    Posted Dec 05, 2018 11:08 AM

    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
    !


  • 5.  RE: User Derived Role not applied - was: AP-specific ACL

    Posted Dec 05, 2018 10:45 PM

    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

     

     



  • 6.  RE: User Derived Role not applied - was: AP-specific ACL

    Posted Dec 07, 2018 06:58 AM

    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. ¯\_(ツ)_/¯



  • 7.  RE: User Derived Role not applied - was: AP-specific ACL

    Posted Dec 07, 2018 07:16 AM

    @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?