Sponsor Portal guest account suspend/delete and CoA PoD

[Arne Bier]

Hello again

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

1. Deleting the account
2. Removing the Endpoint Identities from the respective Endpoint Identity Groups linked to that account - guest must login again with all his devices (key word is ALL!!!)
3. Sending a CoA PoD (packet of disconnect) to the NAS to kill all the sessions (key word is ALL!!!)

Suspending a Guest account should achieve

1. Suspending the account until re-instated
2. Removing the Endpoint Identities from the respective Endpoint Identity Groups linked to that account- guest must login again with all his devices (key word is ALL!!!)
3. Sending a CoA PoD (packet of disconnect) to the NAS to kill all the sessions (key word is ALL!!!)

Points 2 and 3 are the good stuff.  But sadly in my experience I either

• don't always see the CoA arriving at the WLC - still tracing and debugging why
• don't see multiple CoA's if there is more than one device linked to an account - e.g. WLC aaa debug shows only 1 CoA PoD even when three devices were used
• or, much worse, the Endpoint Identity(ies) are not removed in ISE - which nullifies the CoA PoD, because the user's WLC session is just temporarily upset, and then user is back in business without an account.  Once the account is deleted in this way, there is no way to kick a user off via ISE (have to hunt them down in WLC and also manually remove MAC addresses in ISE)

I hope my expectations of how the Delete and Suspend account process works, are correct.

[Jason Kunst]

I agree what you're saying, please let us know the defects, internally i am discussing this with our team to get more clarity

[Arne Bier]

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.

[Jason Kunst]

Thanks for keeping us updated. Please continue

[Arne Bier]

Hi Jason - I am happy to update here but I have not had a status update in two weeks on the case.

[Jason Kunst]

Please ask for escalation BEMs case if its not getting anywhere as well.

[Jason Kunst]

any news on this i can't look at the case

[Arne Bier]

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.

[Jason Kunst]

great info, keep it coming!

[Arne Bier]

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.

[Jason Kunst]

Thanks, even though you’re not using profiling per say, still endpoints are moved into different groups using the profiling mechanisms I believe

[Jason Kunst]

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?

[Arne Bier]

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.

[Jason Kunst]

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