CSCvg88945 CoA on Reprofile Still Not Fixed

[paul]

<vent mode>

This bug has gone on for so long and it is key concept that has to work in ISE.  If there is a profile change and I have CoA set globally to Reauth or specifically set on the profile to Reauth ISE has to send out a CoA.  

I am testing this with 2.4 and it still doesn't work.  If things go from unknown to anything that works, but when there is a profile change say from Cisco-Device to Cisco-IP-Phone it doesn't work.

In particular, I have IND integrated with ISE setting custom endpoint attribute tags that allow be to switch SGT tags based on these  attributes.  Profiling with these attributes is working perfectly.  As soon as I change the security tag in IND the profile changes in ISE, but no CoA is sent.  If I manually CoA life it good.

You might say well what about the silly exception action work around.  That does work for the first flip, but then the profile is statically set and no more profiling can occur for that MAC.  So when I switch it back in IND it doesn't reprofile.

Can I get an accurate status of this bug or get it reclassified as not fixed?  If the devs need someone to truly test out a fix for them I am willing to do that.

</vent mode>

[thomas]

2.3.0.903 means 2.3 Patch 3.

2.4.0.357 is the FCS of ISE 2.4.

Please call TAC if you want to troubleshoot with ISE 2.4 and re-open the bug.

[paul]

It wasn’t working in 2.3 patch 3 either. I will open a TAC case. I would love to know how the devs tested this.

[umahar]

Will this bug also affect if we change static identity group ?

I tried to showcase quarantine behaviour of ISE by moving and endpoint to blacklist but I did not see any CoA issued.

However it was working on 2.2 just fine.

[Damien Miller]

I've noticed something similar in 2.4. If I change the static identity group for an endpoint, I have to go clear the auth manually or do a reauth from the endpoint db page. COA is definitely working. Haven't had time to look deeper.

[paul]

It might affect that as well. I usually show case ANC Policy assignment for doing things like blacklisting. ANC policy was working last time I tested and doing the CoA, but haven't tested in 2.4. I can do that this weekend as well.

[hslai]

This issue has been escalated and Krishnan is engaging our engineering team.

[paul]

I will test on 2.4 patch 2 this weekend. My IND customer has a TAC case open on it, 685006752. If I see the issue still on patch 2 with my large customer I can open a TAC case as well. Or because you have been able to recreate the issue Hsing is there a need to open a TAC case?

[paul]

Hsing,

I have upgraded to patch 2, but need to do some testing after I resolve my live session issue.  I have a TAC case open on why I don't see live sessions.  That could be affecting my CoAs as well.  I am still seeing inconsistent results.

[Justin Walker]

I'm seeing the same thing on a 2.4 patch 1 deployment today.   I thought I was going crazy for a bit until I saw this thread. 

I was trying to use IP address in one of my profiling policies, which was correctly changing the profile for the device after it got an IP address from DHCP but the device was stuck on my Monitor-Mode-MAB authz rule. 

What I've seen today:

1. Workstation connects > Profiled as Microsoft-Workstation > Static Set Corp-Printer Policy > No CoA

2. Printer connects > Profiled as Cannon-Device > Re-Profiled as Corp-Cannon-Device > No CoA

3. Security Device Connects > Unknown Device > Profiled as Corp-Security-Device > CoA reauthorizes session

Anytime it matches an existing Cisco profile first, the re-profiling works but it doesn't respect the global profiling CoA Reauth settings.   I even tried to set the CoA Reauth in the profile itself without any success. 

[paul]

Actually I think the only time CoA works is if it goes from Unknown to something else. If it goes from another to another profile I am not CoAs not matter if I do global or profile based CoAs.

[Justin Walker]

Oh your right,  I agree with your statement above.

It's pretty frustrating when you're expecting it to just work when doing a bunch of profiling rule build out. :) 

I opened a case with TAC as the accepted answer recommends.  Thankfully for troubleshooting purposes its pretty easy to replicate the issue. 

[bart.raat]

We see the exact same behavior. Running 2.4 patch 2 at the moment.

It's working when going from unknown to another profile policy, however when we manually import the MAC address to an endpoint group it doesn't work.

When I configure an Exception Action to force a CoA for a specific profile policy it's also working but that's not a solution you want :)

I see the bug still has the status fixed, have you heard anything from TAC about this?

[paul]

I am going to get a TAC case open today. It is definitely broken and has cause a major customer of mine an issue. So there will be some pressure to get this fixed.

[hslai]

Yes, please do open a TAC case. And, focus on the new issue that ISE profiling CoA requests with this Cisco AVP subscriber:reauthenticate-type=last

If ISE 2.3 not including such option in the same requests, then ask TAC to file a new bug.