Security

 View Only
last person joined: yesterday 

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

Failed to classify request to service - from a newbie!

This thread has been viewed 36 times

  • 1.  Failed to classify request to service - from a newbie!

    Posted Jul 07, 2021 10:35 AM
    I've recently started using Clearpass, and trying to get a grasp on why some of our external users cannot connect to eduroam, when others can. Other than the obvious "Authentication failure", the rest are "Failed to classify request to service", but I'm unsure where to start; given they're attempting to auth externally, isn't the issue that the SSID doesn't match down to the other institute? But then I'm at a loss as to how the requests make it back to us at all.

    ------------------------------
    Peter Gaughran
    ------------------------------


  • 2.  RE: Failed to classify request to service - from a newbie!

    Posted Jul 07, 2021 10:44 AM
    You mention "some" are working.  Have you been able to identify what's different between those users? 

    3 types of services are used with eduroam: local auth for local clients, local auth for remote clients (i.e. your users are visiting somewhere else) and auth for visitors.

    Is it one of the three or some users when they are visiting are not working?


    --
    °(((=((===°°°(((================================================



    Original Message


  • 3.  RE: Failed to classify request to service - from a newbie!

    EMPLOYEE
    Posted Jul 07, 2021 11:28 AM
    If you see a 'Failed to classify request to service', check the attributes from Access Tracker once they come in versus the Service's Rule conditions.

    This Service classification is 'ClearPass basics', so it may be good to check with your Aruba partner, or Aruba Support to get you going.

    eduroam is using the same SSID ('eduroam') everywhere... So also check that you are broadcasting the SSID with that name, and all lower-case.

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

    Original Message


  • 4.  RE: Failed to classify request to service - from a newbie!

    Posted Jul 07, 2021 11:47 AM
    Yes, some are working and have services against them; the ones that aren't don't specify an Essid-Name. So, for the ones that aren't working, I'm getting the below (specific details removed.)

    Radius:IETF:Calling-Station-Id
    Radius:IETF:NAS-Identifier
    Radius:IETF:NAS-IP-Address
    Radius:IETF:Operator-Name
    Radius:IETF:Proxy-State
    Radius:IETF:User-Name



    And for the ones that are, for example, the internal ones, it looks like this.

    Radius:Aruba:Aruba-AP-Group
    Radius:Aruba:Aruba-Essid-Name eduroam
    Radius:Aruba:Aruba-Location-Id
    Radius:IETF:Called-Station-Id
    Radius:IETF:Calling-Station-Id
    Radius:IETF:Framed-MTU
    Radius:IETF:NAS-Identifier
    Radius:IETF:NAS-IP-Address
    Radius:IETF:NAS-Port
    Radius:IETF:NAS-Port-Type
    Radius:IETF:Service-Type
    Radius:IETF:User-Name

    So, internally, eduroam is indeed the SSID being broadcast. My reading of it is when our users are attempting to connect in other institutes - that's the issuem as best as I can tell.



    ------------------------------
    Peter Gaughran
    ------------------------------

    Original Message


  • 5.  RE: Failed to classify request to service - from a newbie!

    Posted Jul 08, 2021 08:16 AM

    I've had instances where other institutions don't send the full list of attributes. So I have this as the service categorization for our inbound eduroam service

    connection: src-ip-address belongs to group: National eduroam proxies
    authentication: full-username-equals: *regex to match our domain*

    When setting eduroam up using Clearpass I followed this guide by Geant: https://archive.geant.org/projects/gn3/geant/services/cbp/Documents/cbp-79_guide_to_configuring_eduroam_using_the_aruba_wireless_controller_and_clearpass.pdf

    It was extremely helpful



    ------------------------------
    Christopher Wickline
    ------------------------------

    Original Message


  • 6.  RE: Failed to classify request to service - from a newbie!

    MVP EXPERT
    Posted Jul 09, 2021 05:05 AM
    I used to have the problems that the remote sites used to pass everything to our service ad didn’t filter anything.

    I front ended our ClearPass service with a FreeRadius cluster where you can make sure what goes out and what comes in gets filtered down to the required attributes .. also stops your centralised auth service (Clearpass ) from being hit by external DoS attacks

    A


    Original Message