Security

 View Only
last person joined: yesterday 

Enterprise security using ClearPass Policy Management, ClearPass Security Exchange, IntroSpect, VIA, 360 Security Exchange, Extensions and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

This thread has been viewed 32 times
  • 1.  Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 13, 2022 07:20 AM
      |   view attached

    Hi All,

    I got a use-case, where a device roams from one floor to another, within same SSID, but different so-called Policy Tag in Cisco 9800 WLC. Different floor different policy tag.
    This Policy Tag appends at RADIUS:NAS-Identifier and I put a Role Mapping rule like below:
    - If policy tag = L1 -> assign WLAN VLAN L1 clearpass role
    - If policy tag = L2 -> assign WLAN VLAN L2 clearpass role
    Role mapping evaluation algorithm is the evaluate-all.
    I ask my network team, for some reason they cannot name L1 and L2 with same vlan name with different vlan id at their backend.

    So the issue with this, is when a user connects to L1, and then moving to L2 within 5 minutes policy cache result, this endpoint will have both L1 and L2 clearpass roles at the same time , whereby at the enforcement policy, first-applicable rule is applied: L2 rule is below L1, and this 'use cached Roles and Posture attributes from previous session' is checked, because I have posture attribute that needs to take into account as well.

    If I change the role mapping evaluation algorithm to first-applicable, it is still possible for the user to hold two clearpass roles at the same time in this scenario.

    So, at the end, could I request please, to have multiple options to tick the 'use cached Roles' separately from the 'use cached Posture' ?
    Definitely in this case I do not want to tick the 'use cached Roles' because if ticked, it will make the same enforcement mistakes. At the same time Posture cache is a must so if you separate it, I will tick the Posture ONLY.

    PS: actually we can create multiple Service with multiple policy tag as the service rule, but imagine we have so many floors with the SSID broadcasted everywhere... it will be so many Service lines seen at the Services page, and the enforcement policy should become a lot as well.



  • 2.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    EMPLOYEE
    Posted Sep 13, 2022 09:22 AM
    Feature requests can be submitted in the Aruba Innovation Zone, which is open for partners and Aruba employees.

    Please contact your Aruba partner or local Aruba SE to get this processed, if you can't submit it yourself.

    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------



  • 3.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 14, 2022 02:09 AM
    Hi Herman,

    I am able to submit myself at the Innovation Zone.

    Thanks.


  • 4.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 13, 2022 11:19 AM
    Why have multiple policy tags for this at all on the 9800?  Why should the client be forced to a "hard" layer3 roam just because they moved floors?  Why not use the same VLAN?


  • 5.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 14, 2022 12:44 PM
    My network team said it is because , one vlan can only have limited number of hosts , and we cannot predict where the endpoint will be roaming , and according to the design, this one vlan cannot be configured everywhere.

    Personally, I also find that design has weaknesses, but either way this ability to choose use cached Roles or Posture should be there.


  • 6.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 15, 2022 11:16 AM
    Did you try to assign attribute to APs in Clearpass?  If you assign for example attribute Location=L1 to endpoint database records of APs in one floor, you could use it in role mapping/enforcement to assign correct vlan.

    Best, Gorazd

    ------------------------------
    Gorazd Kikelj
    ------------------------------



  • 7.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    EMPLOYEE
    Posted Sep 15, 2022 06:48 PM


    ------------------------------
    Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba.
    ------------------------------



  • 8.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 15, 2022 10:11 PM

    @GorazdKikelj @ariyap

    Do I have to register all the APs under Network > Devices ?
    My APs are not fat APs/controllerless, it's with controller so the NAS-IP-Address at the incoming RADIUS is never the AP IP.

    I actually have been trying to add post-enforcement update to Endpoint Repository, updating the particular MAC's location with %NAS-Identifier, then upon update I use this location to map to a certain vlan. But, it changes my authentication workflow and after trying this, I still feel it could be better if I can separate the cached roles and posture​, because in the end it is just what I want (I dont want to use the cached role in my enforcement policy).




  • 9.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    EMPLOYEE
    Posted Sep 16, 2022 01:47 AM
    if they are controller-based APs, then you can use  Radius:Aruba:Aruba-AP-Group
    you can put the APs in different ap-group and then based on that you can use the above attribute to differentiate.

    ------------------------------
    Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba.
    ------------------------------



  • 10.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 20, 2022 05:00 AM
    In this deployment particularly the AP brand is Cisco.

    The thing is, I couldn't use RADIUS:IETF at enforcement policy, so I must have configured a role mapping for each floor/location in which I will be assigning different vlan to each.
    Or another way is to use the RADIUS:IETF attribute at the Service rule at the front, but this makes me create multiple Services for each of the locations which I found it too 'untidy' and in some way ridiculous.


  • 11.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 16, 2022 02:27 AM
    In RADIUS request you'll find  attributes like Aruba:Aruba-Location-Id and IETF_Called-Station-Id where the name of the AP is provided. The same info you can get from Connection:AP-Name.

    If you have some unified way to include location info in the AP name, you can use this data to find out the micro location of the client.

    You do not need to define APs in Device database.

    Best, Gorazd

    ------------------------------
    Gorazd Kikelj
    ------------------------------



  • 12.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 20, 2022 05:09 AM
    My "Connection:AP-Name" has the AP MAC address as its value, and "RADIUS:IETF:Called-Station-Id" is basically the same as RADIUS:IETF:NAS-Identifier in which I got the AP-Name & Policy Tag appended there already. I don't know how to populate the called-station-id in 9800 WLC Cisco controller with SSID&&AP-Group, last time in 5500 series I could do that.

    Example of my attributes' values:
    - Radius:IETF:Called-Station-Id f0-1d-11-22-33-44:<SSID-Name>
    - Radius:IETF:NAS-Identifier ushospwl:<CustName>-L01-AP11:<CustName>_POLICY_TAG_<TagName>
    - Connection:AP-Name f01d11223344

    I tried adding an added attribute under Network >> Devices, but it does not help as I can only add the attribute at the WLC device itself, not the AP.


  • 13.  RE: Feature Request: SEPARATE 'Use Cached Roles and Posture Attributes From Previous Sessions'

    Posted Sep 20, 2022 05:53 AM
    Hi.

    It looks like you don't have set the AP names on the controller so you get the default name.
    You can use CLI command to set AP name and AP location on the WLC.

    ap name XXXXXXX location "XXXXXXXXXX XXXXXXXXXXX"

    I have very limited knowledge on Cisco WLC. You can check/try setting AP and location on the AP and see, what you will get in IETF parameters.

    When you determine the correct parameter, then you can use it to dynamically set vlan like in the following example. In this example, I use AP-Name as the name of the vlan. You can put vlan number to the location parameter in ap name xx location xx command and use it to assign the correct vlan by number.

    Enforcement profile example

    The result in my example is


    This is just a demonstration how you can use values gathered from different sources to dynamically create appropriate enforcement profiles. It require some discipline eg. you need to maintain correct information for all APs for this to work reliably.

    Best, Gorazd






    ------------------------------
    Gorazd Kikelj
    ------------------------------