Security

 View Only
last person joined: 14 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

CPPM -> PaloAlto XMLAPI UserID data resend?

This thread has been viewed 57 times
  • 1.  CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Sep 11, 2018 04:05 PM

    I have configured an enforcement profile to send my Palo Alto the user's UserID and HIP data. We notice that the CPPM server resends records well after a user has left the premises. 

    To test I disabled the profile match statement so no new data would be sent and I see that CPPM continues to resend records, now several days later.

    Is this a feature or a bug? No sessions are still active, and no event has matched the enforcemnt profile in 6 days, yet I'm still getting new XMLapi connections on the PA firewall.

    How do I make ClearPass stop sending?



  • 2.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    EMPLOYEE
    Posted Sep 11, 2018 04:09 PM
    It should only be sent on accounting changes. Please open a TAC case.


  • 3.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Sep 11, 2018 05:13 PM

    Calling now.



  • 4.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Sep 21, 2018 12:18 PM

    TAC reports that this is a "known bug" and I'm now (im)patiently waiting for word on a fix.



  • 5.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Jul 17, 2019 10:15 AM

    Any updates on this? We noticed this behaviour in our environment as well. I could not find any hints on a known bug in the release notes. IMHO the Palo Alto context server option is not usable like that. ClearPass also keeps sending the API request if the context server is deleted. That must be a bug. Timeout settings also do not seem to work.



  • 6.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Jul 17, 2019 06:21 PM

    I'm sorry I let this thread go without updating.

    The next patch fixed the issue and we haven't seen it again.

     

    I can't tell you exactly which version it was that fixed it, but we patch within a few days of each release.



  • 7.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Jul 18, 2019 03:38 AM

    That's strange because we are on 6.8.0, update to latest 6.8.1 is pending. I think I will give the latest version a try and contact TAC otherwise. For now we disabled the API access on PAN site because ClearPass doesn't stop sending requests.



  • 8.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?
    Best Answer

    Posted Aug 15, 2019 04:38 AM

    Recently had a TAC case, turned out that it is a known bug again. But there exists a workaround:

    • Under Cluster-Wide Parameters General Tab set Post-Auth v2 to ENABLED
    • then restart Async network service on all machines

    That fixed it for me.



  • 9.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Dec 23, 2020 01:20 PM

    Thanks, we recently turned this feature back on and I was seeing the returned bug (CPPM version 6.9.3.x) and am now trying the work-around.



    ------------------------------
    --Matthew

    If I have in some way helped, please click the KUDOS button
    ------------------------------



  • 10.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Dec 23, 2020 02:30 PM

    Nope - still continuing to update stale records. Heading to TAC.



    ------------------------------
    --Matthew

    If I have in some way helped, please click the KUDOS button
    ------------------------------



  • 11.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Jan 20, 2021 03:55 AM
    ​Hi Matthew,

    did you get any further with that? We noticed this behaviour as well after upgrading to CPPM 6.9.3. Stale entries are resend irregularly and generate wrong user-ids which really is a security issue.

    Post-Auth v2 should be the default now. Seems there is currently no workaround available.

    Regards

    Edit: Maybe it is related to CP‑31417:
    ClearPass leaves stale entries when a client roams from one ClearPass server to another.
    
    In a cluster environment where the user first authenticated on one ClearPass server and later authenticated on a different ClearPass server, ClearPass might leave a stale entry in a Palo Alto Networks (PANW) server.
    
    Workaround: If you use a load balancer to load-balance ClearPass RADIUS traffic, configure a load balancing algorithm that maintains connection persistence based on a RADIUS username.


    ------------------------------
    Daniel
    ------------------------------



  • 12.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Jan 27, 2021 07:22 PM
    I made it worse by upgrading versions mid-troubleshoot. All UserID updates stopped after the upgrade.
    We got the postauth service restarted and the updates started again including the stale entries continuing to update as well.

    Troubleshooting tomorrow.

    I'll keep the updates trickling in.

    ------------------------------
    --Matthew

    If I have in some way helped, please click the KUDOS button
    ------------------------------



  • 13.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    MVP
    Posted Jan 27, 2021 07:42 PM
    Do you actually have a TAC case open?

    ------------------------------
    Danny Jump
    "Passionate about CPPM"
    ------------------------------



  • 14.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Jan 27, 2021 08:26 PM
    I'm never sure when I do or not. I Email a gentleman in TAC who handles my reqeust and finds me the appropriate resource [in this case Mathew George (Aruba-ERT)] then my handler or whoever he finds to help me opens a ticket when tracking is needed. I think my case is 5353130348 at this time.

    ------------------------------
    --Matthew

    If I have in some way helped, please click the KUDOS button
    ------------------------------



  • 15.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    MVP
    Posted Jan 27, 2021 11:29 PM
    Thats cool, Mathew George is "THE TAC ENGINEER, GLOBALLY", and knows the PANW/CPPM integration very well, your in the best of hands with him.

    ------------------------------
    Danny Jump
    "Passionate about CPPM"
    ------------------------------



  • 16.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Jan 28, 2021 07:24 AM
    Thanks for keeping us up to date! Really looking forward to your results




  • 17.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Feb 04, 2021 07:30 PM
    After some fiddling and database querying, we agreed that there were stale entries in the redis queue, and I observed that most of the MAC addresses were for devices which I had been using to test my enforcement policy, and which hadn't logged out, so much as been removed from the role-matching when I completed testing. Effectively I'd added them to the role-match to make something happen, and removed them from the match when I was ready to go live - with no way to tell CPPM that I was done with them.
    I had hoped that when they logged off, they'd get flushed - but they don't log off, they were iPads and all out users ever did was lock the screen and leave them on the charger over night. 
    We flushed the redis queue and let new authentication events repopulate.
    No stale entires have reappeared. (so far)

    ------------------------------
    --Matthew

    If I have in some way helped, please click the KUDOS button
    ------------------------------



  • 18.  RE: CPPM -> PaloAlto XMLAPI UserID data resend?

    Posted Feb 05, 2021 02:23 AM
    Great job, sounds exactly like my issue. I was also testing a lot and now that you mention it: the affected User-IDs are all from the testing time. I also noticed that CPPM sends a lot of wrong logout events to the PAN FW for these IDs, forcing them to reauthenticate every now and then. I will head to TAC and ask them to clear the redis queue as well.

    ------------------------------
    Thanks
    Daniel
    ------------------------------