cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
642
Views
0
Helpful
9
Replies

Posture assessment stuck in pending state - must force reauth

julienphz
Level 1
Level 1

Hello,

We had a perfectly functional ISE 2.7 posture deployment, but we had to upgrade to ISE 3.2.

We set up another deployment & imported our 2.7 conf into the 3.2. Since then, our computers never go through the full posture process.

We're using Anyconnect for posture. When we boot the computer & log into it, the posture is shown as "compliant" on the endpoint, and the report is actually sent to ISE (we can see it in the reports), but our ISE never sends back a CoA to modify the authorization profile.

So our computer is stuck with the authorization profile that it gets while the posture status is "unknown", because on ISE, posture status remains as "pending" forever in the live logs.

We can fix this with one of the following methods:

  1. by doing a shut/no shut of the switchport the endpoint is connected to
  2. directly from ISE with a "CoA action: send reauthentication with port ..".
  3. By ticking/unticking the "block untrusted server" checkbox on Anyconnect on the endpoint.

When we do any of these actions, the posture is re-evaluated, the status sent to ISE, and it works correctly because ISE will now really get the "compliant" status of the posture, and send a CoA. The authorization profile is then updated on the switchport.

I've opened a TAC case but I'm hoping somebody has faced the same issue and managed to solve it.

9 Replies 9

Do you see the CoA packet leaving ISE?  Do you have a log for CoA on ISE?  Does the NAD have a dynamic author entry for the new 3.2 ISE nodes?  What patch on ISE 3.2?

https://www.cisco.com/c/en/us/products/collateral/security/anyconnect-secure-mobility-client/anyconnect-secure-mobility-client-v4x-eol.html

Hello,

It's Patch 4. Yes, we have the dynamic author configured. It used to work in 2.7, not in 3.2 anymore.

One of the logs I've seen is that we get a line in live logs for the affected computers that states "Compliant". If I open that log, it states that it's going to send a CoA to update the authorization profile.

But it never does, and I can't see those CoA in the firewall logs either... I'll check for some other machines again tomorrow.

Another issue I've been facing since 3.2 is that periodic re-assessment completely fails ("reassessment failed") when it's triggered automatically by the reassessment period (configured at 1 hour for us). But if we initiate the process manually by ticking/unticking the "block untrusted servers" checkbox, it works perfectly fine.

It's been a real headache to figure out if our Anyconnect version is the issue, or the ISEPostureConfig.xml file that is not correct for 3.2, or something else I'm not thinking of.

 

Reload the PSN and see if the problem is resolved.  I had a customer with a very similar issue recently.  A reload corrects the issue.  They are working with Cisco TAC on a long-term resolution.

... that's right, we never tried to reload any PSN. Will do that tomorrow and let you know. Thanks for the idea.

Unfortunately, the PSN reboot did not solve the issue and TAC couldn't figure it out either. We'll see how it goes.

Give TAC CSCwi38377

 

mtar
Level 1
Level 1

Hello!

Any update regarding this problem?  I'm affraid we are also affected by this issue.

BR

Hi,

Unfortunately my Cisco TAC ticket is still opened and they have not managed to solve it yet.

The bug mentioned that suggested we should reboot our ISE nodes does not seem to work for us. I've tried rebooting all of them (PAN/SAN/PSN), no difference.

We do see the CoA being sent on ISE, and I saw it on my firewalls as well, but somehow the wrong profile/authorization policy seems to be selected.

Our workaround is to grant the same dACL regardless of what profile is chosen (UNKNOWN posture or COMPLIANT).

I'll update this post once we finally solve this.

Hello!

Thank you for your update!

Meanwhile we have opened a TAC case also and referenced the bugID mentioned above. 

If we manage to figure out a permanent workaround or solution I will update you as well.

BR