08-09-2018 11:18 AM - edited 08-09-2018 11:20 AM
<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>
Solved! Go to Solution.
08-27-2018 07:04 AM
08-31-2018 12:16 PM
We run ise 2.3 patch 3 (2.3(0.903)) and we still get the issues.
08-31-2018 07:39 PM
09-17-2018 06:17 AM
My open TAC case was also linked to CSCvm22838. TAC said 2.4 patch 4 for targeted release for a fix and tentative early October time frame for release.
10-11-2018 07:09 AM
Well, 2.4 patch 4 has been released and no fix was included. Not only that, a couple of the TAC cases i have involving the issue have been asked to provide additional evidence of issues with the CoA after reprofile.
The easiest way I've been able to reproduce it (maybe its the only method doing it), is to set an IP Address condition in a new profile. The delay in the IP Address information being sent to ISE is just enough that a CoA action has to take place for the device to be authorized. The profile will match correctly, but the CoA is never sent.
Between the cases i have opened, the following bugs have been referenced... all terminated:
CSCvg88945
CSCvm22838
CSCvk25516
Anyone else having these issues, or made any progress with TAC?
10-11-2018 07:20 AM
10-11-2018 07:30 AM
I've had a couple of clients now that have upgraded to 2.4 from 2.1/2.2 installs. Each of them has hit this issue in some varying degree.
Thank you for confirming that this is still relevant and that you have a case open as well. TAC said it was going to be fixed, but then came back and said the Devs cannot replicate the issue. I was starting to second guess myself, because I found it extremely easy to replicate in a lab with the IP address condition.
Thank you Paul for your reply.
10-11-2018 07:40 AM
10-11-2018 08:19 AM
Hi,
You should follow the bug CSCvm22838. We could confirm this is not patch but worst at 2.3 patch 5. We actually use a rehauthentication as workaround like suggested in the bug. So we have an open case open with TAC.
10-11-2018 08:27 AM
10-12-2018 07:30 AM
Hi Paul,
We didn't do it manually , we know it's not clean and could create side issues. And we hopfully wait the return of COA. But during this time network must operate !
What we do as workaround:
1.NAD configured to accept timer of rehautentication by av-pair.
2.An autorisation Policy of profilling for all unknow device or transitive profilling categorie (ex: Cisco-device). With this Policy we send the av-pair for rehautentication with an agressive timer and a Vlan were we could profile and the device didn't get ip address.
3.At the rehautenttication the device must be profiled, so the autorisation policy should be the good one. In this policy we send av-pair for rehautentication with a much longuer time and good network access.
configuration in switch port:
authentication periodic !active rehaute periodicaly
authentication timer reauthenticate server !use the radius av-pair value in the radius response to set periodic rehaut time.
In Policy authorization result:
Session-Timeout = {time in second} !will rehaut with the asked time
Termination-Action = RADIUS-Request !will maintain connectivity during the rehaut process
I hope this could help,
11-04-2018 10:36 PM
Thanks all for the information about this ongoing bug.
I can also confirm that this is not working on ISE 2.3-Patch4. TAC case opened 685425611
Really hope that this will get fixed permanently with Patch5.
Can't believe Cisco let this drag for so long without providing a proper fix - Such key functionality within ISE.
11-13-2018 06:41 AM
11-15-2018 08:20 PM
Thanks for the update Paul.
03-01-2019 11:42 AM
Seems like this bug is still not fixed in 2.4 p6 according to release nots.
Any recent updates ?
https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/release_notes/b_ise_24_rn.html#id_98767
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide