This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
I have a TAC case regarding my bad experiences so far with ISE 2.2 Sponsor Portal and the results of deleting and suspending accounts. Not getting great tracking on that yet, so I thought I would share my thoughts here.
The official Cisco documentation about the ISE 2.2 Sponsor Portal Delete operation is not helpful and trivialises this with statements like "When you click on delete, then it deletes the account". It doesn't help much ...
What REALLY happens when you suspend and delete an account is a bit more involved than that, especially when you use it in the context of MAB (RememberMe) authentications.
Deleting a Guest account should achieve
Suspending a Guest account should achieve
Points 2 and 3 are the good stuff. But sadly in my experience I either
I hope my expectations of how the Delete and Suspend account process works, are correct.
I agree what you're saying, please let us know the defects, internally i am discussing this with our team to get more clarity
Thanks Jason. I only have a TAC SR 682978363 so far. Engineer has captured some info but no feedback so far.
My own testing reveals that I can always send a CoA Reauth or CoA Disconnect from the PAN GUI (and I always see it on the Cisco WLC aaa debug). But I don't always see the CoA Disconnect when I delete an account. It's quite easy to recreate this. I suspected that my F5's were consuming the CoA - but I ran TCPdump on my PSN's and I never saw the CoA go out.
Any help would be greatly appreciated to solve the mystery.
I had a WebEx with TAC yesterday and the engineer was able to reproduce one of the scenarios (i.e. one account logged in with three devices - then delete account, and one Endpoint remains in the Endpoint Identity Group). But in her case she was able to always send the CoA to the WLC for all endpoints. Her lab consisted of one PSN only (I have two, and they are in a Node Group). I will ask my customer if we can take the second PSN out of the F5 pool and then see if the CoA problem changes. No new bug raised yet but the TAC will liase with BU about the non-deleting Endpoint issue.
TAC concluded that they have managed to reproduce the case where not all Endpoints get deleted from the Endpoint Identity Group. They had 3 endpoints and when account was deleted there was always a one that was not deleted. The TAC filed a new bug CSCvg23565.
Then the TAC mentioned that we may be hitting CSCvd10486 which is apparently fixed in 2.3 but the bug ID mentions profiling again. We don't use profiling. So I am sceptical whether this issue has been resolved. Remains to be seen.
In my prod deployment I have cases where the CoA is never sent to disconnect the session after account deletion, but I can manually trigger CoA from the PAN GUI, therefore I know the PSN *can* perform CoA and it's able to talk to the NAS. Drives me nuts.
My 2.2 to 2.3 upgrade is in planning stage.
Thanks, even though you’re not using profiling per say, still endpoints are moved into different groups using the profiling mechanisms I believe
i checked CSCvd10486 and it says possibly fix in 2.2 patch 5 as well, since patch 4 just came out Did tac try 2.3?
That's a good point about TAC trying 2.3 - why didn't I insist on them proving that ?
Well, we want to move to 2.3 anyway - big organisations take some time to get all the approvals and testing before that will happen. I don't have enough time to figure out why my TACACS Policy sets doubled in size and whether I can simply clean up all the extra stuff that it created.
I wish there was an option to do an upgrade from 2.2 to 2.3 where it just leaves my Policies alone. If they're inefficient or messy, that's nobody's business. At least I understand them.
That’s a totally unrelated item about TACACS. Would recommend if you have some feedback, please write it up send over to get to our PMs