Security

 View Only
last person joined: 11 hours ago 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Architecting ClearPass to know which VLAN names are on which switches

This thread has been viewed 35 times
  • 1.  Architecting ClearPass to know which VLAN names are on which switches

    Posted Jan 14, 2021 06:42 PM

    Hi Friends, 

    We are in the process of setting up a large Aruba-CX deployment with Central + ClearPass.   We are aiming to get ClearPass to colorless port functionality.   We are a government "service provider" to many departments/agencies that have distinct networks but that frequently are co-located and share network infrastructure.  So, we have 55+ distinct VLAN use cases/security zones and 1000s of sites but we have essentially 1 AD domain.   

    I want the logic of my 802.1X auth to be: 
    1. Authenticate user machine using 802.1X
    2. Then do a series of checks: 
    #1    Check if user machine is in AD group departmentA, if yes, then
                  check if VL-groupA exists on local switch,  then apply DUR (downloadable user role) with local VLAN name VL-groupA.  
                   else apply DUR-tunnel to controller to core VLAN named VL-groupA. 
    #2    Check if user machine is in AD group departmentB, if yes, then
                  check if VL-groupB exists on local switch,  then apply DUR (downloadable user role) with local VLAN name VL-groupB.  
                   else apply DUR-tunnel to controller to core VL-groupB. 
    etc. etc. ....
    Then when we get through ~50 of those, 
    #51  Default rule/profile is a DUR that is applied for a remediation VLAN because the user machine did not match any of the sub-group conditions. 

    A similar logic would be run for MAC Auth use cases with some extra ACL security as part of the DUR for printers, etc. 

    A lot of this is working in my mock up, but the part that has been tricky is figuring out a 'painless' way to get ClearPass to have a database of which local VLAN names (from our approved list of ~55) are on a given local switch.  

    One way we have gotten it to work is by creating a unique "tag" that designates the presence of each local VLAN and place a list of the tags in each switch's attributes.   For instance, Device>Attributes>Location = "#VLgroupA, #VLANgroupB, #VLANgroupX". . Then, in addition to checking AD group membership, I can also check for to see if the switch attribute contains the tag designating the needed local vlan.  This does work. but it also feels like a hack to some extent.    I suppose something similar could be done with the sysLocation SNMP field on the switch and we could have that set on the CLI/by central and then ingest it through SNMP.   

    Beyond that, I might experiment with Ansible or something to login to the switches and pull the vlan list and put it in a DB that is made available to ClearPass, but that is a lot of work and another dependency for the system. 

    I have tried using Device groups (one group for every VLAN name), but it doesn't quite work because if it gets as far as matching the rule (based on AD group membership), and then there is no local VLAN DUR profile available, ClearPass never backs out of the rule and goes looking for another rule... .it just returns "authenticated" and the switch ends up putting the user in the default access vlan set on the port.. We need it to "fall through" when the local vlan name is not available.

    So... short ask is... has anyone else encountered a large environment like this and found a good way to record which local vlans exist on which switches and use that in ClearPass Policy DUR selection criteria?   Automated, low touch is better, of course.  I am desperately trying to avoid having 100s or 1000s of services to correlate with all the different permutations of vlans that are present at different sites.  I'm trying to keep the keep the logic straightforward/understandable and flexible for the many different combinations we have to support. 
     
    Thanks!
    Matt

    ​​​​​​


  • 2.  RE: Architecting ClearPass to know which VLAN names are on which switches

    Posted Jan 22, 2021 10:14 AM
    Hi Matt,

    For me, a pre-requisite of using DUR is some form of standard vlan naming.

    If not, you may be better of defining your role locally and assign the vlan needed locally. Like that, you can have a same user role name but with a per switch vlan assigned to it. ClearPass will then send the role name for the user authentication.


    ------------------------------
    Julien B
    ACEX #90
    ------------------------------



  • 3.  RE: Architecting ClearPass to know which VLAN names are on which switches

    Posted Feb 01, 2021 12:52 PM
    Hi Julien,

    Thanks for the response.   We are going to use standardized VLAN NAMES across our enterprise.  The problem is I have about 50 different security designations (for compliance and segmentation) that equate to 50 separate VLAN Names (and in most cases separate VRFs, etc. )  However, not all 50 VLANs are on all switches (in fact, they never are), so I need ClearPass to be programmed to always know which vlans are on a given switch so it makes sure it doesn't send a DUR to a switch with a VLAN NAME that is unknown to the switch.  

    The way we have chosen to try to solve this is:  for each switch's device record in ClearPass, add a custom attribute called "Local VLANs"... this attribute will list the VLAN names that are available on the local switch.   The enforcement logic in the CPPM policy will then look in that attribute before pushing a DUR to the switch.   [if the needed local VLAN NAME is not in the attribute, CPPM will use an alternate DUR or UBT policy].   To automate the process we will try to build automated API calls to pull this information from Aruba Central Variables and write/update it to ClearPass Device Records.  The automation is worth it when there are many 1000s of switches and scores of engineers in the mix and sites coming online all the time.

    If anyone has tried something like this, please let me know. :-o

    Regards, Matt