Security

 View Only

  • 1.  TEAP and CoA and DUR

    Posted 8 days ago

    Hello,

    I am having a problem with a conductor/controller setup I am supporting that uses TEAP authentication (outer-method EAP-TLS, inner-method MSCHAPv2)

    The SSID uses the following settings:

    • Enterprise SSID
    • Machine Authentication disabled
    • no deny listing

    Server-derived roles, value returned from ClearPass

    An CoA server is configured in the Authentication profile and added in the AAA profile, DUR is also activated in the AAA profile, the setup also uses clustering and we added the additional VRRP IP address for CoA.

    On the ClearPass server we made use that CoA was added to our NAD devices we configured under Network > Devices

    Our ClearPass policy was configured to use Downloadable User Roles, and additionally we also update a Palo Alto Firewall and add an additional profile (CP-36629) to send TEAP-Method1-Username to the Controllers. The controllers accepts the User Role but we can't seem to get CoA to work.

    I hope I provided enough information for someone to say "Did you check....?"  or can help us figure out what we should check? Our access-tracker input shows the IP address of the configured CoA IP (cluster VRRP)

    Our setup uses the following software versions:

    • ClearPass 6.11.8 with hotfix for DUR
    • Controller/Conductor: 8.10.16 LSR
    • Windows 10: 10.0.19.0.45.5487

    Thanks in advance,



    ------------------------------
    Martijn van Overbeek
    Architect, Netcraftsmen a BlueAlly Company
    ------------------------------


  • 2.  RE: TEAP and CoA and DUR

    Posted 7 days ago

    TEAP doesn't have an outer-method, think only PEAP has inner and outer methods (configurable). MSCHAPv2 is strongly deprecated because it's security has been broken for many years and should not be used anymore; move to EAP-TLS instead.

    But question was around the CoA. On the 'did you check', do you have accounting enabled? Can you do a manual 'Change Status' from Access Tracker? How does the CoA fail, do you see an error message (not authorized, attributes missing, timeout, other)? Do you see something on your controller in the logs or in 'show aaa rfc-3576-server statistics'? Does the CoA even reach the controllers? Does CoA work on this ClearPass and Controller for other purposes? Note that with a ClearPass virtual IP, the CoA originates from the ClearPass virtual IP, so that needs to be listed as RFC3576/CoA server in your controllers.

    Enough questions?



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

    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.
    ------------------------------

    Original Message


  • 3.  RE: TEAP and CoA and DUR

    Posted 7 days ago
    Edited by mvanoverbeek 7 days ago

    Thanks/Dankjewel Herman, great questions!


    And you are correct, my apologies for my mistakes, the customer is actually transitioning to EAP-TLS for the client-auth as well, machine was already EAP-TLS. Loads of questions to follow up on. One thing I do remember and need to double check is the "RADIUS key". Of course we have configured the RADIUS key for RADIUS itself but I am reading this article https://arubanetworking.hpe.com/techdocs/ClearPass/6.11/PolicyManager/Content/Deploy/Aruba%20Controller%20Configuration/RFC_server_configure.htm 

    that states I have to configure a password under "Server Options". I will verify this setting and also the other insightful questions you posed.



    ------------------------------
    Martijn van Overbeek
    Architect, Netcraftsmen a BlueAlly Company
    ------------------------------

    Original Message


  • 4.  RE: TEAP and CoA and DUR

    Posted 7 days ago

    So we made some progress, found a few issues, indeed some of it related to the CoA server not having the correct password. We also find discrepancies between the role-mapping and policy so we recreated and simplified both. Although CoA works now, and roles are pushed and appear correct we still experience unexpected behavior. 

    We are now able to use CoA, unfortunately both DUR roles and roles locally defined on the controller giving us strange behavior, this is what happens:

    • When we log in to the PC when it is not connected to our WLAN everything works out it seems, we can ping the gateway and connect to the internet
    • When we only use machine authentication, meaning before logging into the PC we connect to the WLAN, we are receiving the correct role from Clearpass and it is visible in the controller
    • When logging in the user authentication is triggered and we are receiving the correct role from ClearPass, it is visible in the controller, but the behavior is strange. We were able to ping some other users in the subnet but not the gateway which is a switch upstream from the controller.

    A packet capture shows the Client trying to ARP for the Gateway, but it never receives this information back.

    The switch connected to our ESXi host has an ARP entry for the client (this might be an old entry though)

    Probably not enough to go by but thought I share it.



    ------------------------------
    Martijn van Overbeek
    Architect, Netcraftsmen a BlueAlly Company
    ------------------------------

    Original Message


Related Content