Purge guest enpoints based on guest user expiration

[Dominic Stalder (old profile)]

Hi guys

I think there is no native Cisco ISE way to check, if the guest user or portal user for a specific endpoint is expired and if so, purge this endpoint the next time purging is running, correct?

- At the moment, we create a guest user with a lifetime of 30 days and save the mac address into the endpoint group Guest_Endpoints

- After 30 days the guest user will expire, but we will not purge any guest users at all (we want to have them all in the database "forever", because we use an index which will be incremented while self registration, some thing like guest-0001)

- Under Endpoint Purge settings we purge everyday and configured the endpoint group Guest_Endpoints to be purged, if ENDPOINTPURGE ElapsedDays GREATERTHAN 30 Days

1. First of all, is our configuration correct, so that after the endpoint gets saved into the endpoint group Guest_Endpoints it will be purged during the night and the next day, it will be redirecte to the guest portal again?

2. I know there is a way to check if an endpoint has an portal user (saw something like this in a presentation by @Jason Kunst: guest-restrict1hrday.pptx) inside the policy sets (authorization). But is there also a way to check if the sponsor user is expired or not, so we can decide if the endpoint needs to be redirected to the guest portal again or if it has access straight away?

It would also be great, if you can specify this check under Endpoint Purge settings, let's say "purge all endpoints in endpoint Group Guest_Endpoints if their sponsor user is expired"!

Thanks in advance and best regards

Dominic

[Jason Kunst · Accepted solution]

1. 1. First of all, is our configuration correct, so that after the endpoint gets saved into the endpoint group Guest_Endpoints it will be purged during the night and the next day, it will be redirecte to the guest portal again?
   • Yes this is common config. 2 basic rules
   • If Mab and Guest_endpoints then permit access
   • If MAB then send to redirect authz profile

1. 2. I know there is a way to check if an endpoint has an portal user (saw something like this in a presentation by @Jason Kunst: guest-restrict1hrday.pptx) inside the policy sets (authorization). But is there also a way to check if the sponsor user is expired or not, so we can decide if the endpoint needs to be redirected to the guest portal again or if it has access straight away?

Wouldn’t this do it for you?

•   If Mab and Guest_endpoints AND portal user ID is NOT NULL (per the presentation) then permit access
• If MAB then send to redirect authz profile

It would also be great, if you can specify this check under Endpoint Purge settings, let's say "purge all endpoints in endpoint Group Guest_Endpoints if their sponsor user is expired"!

I don't see that as an option either, open an enhancement with the TAC, also get me your product feature request offline so I can get to the PM

[Dominic Stalder (old profile)]

Hi Jason

1. Thanks for confirmation, I have the authorization policy configured like this:

By the way, I use the condition Network Access:ISE Host Name EQUALS ise01 and Network Access:ISE Host Name EQUALS ise02 to have a fallback to the portal on ise02 in case of a failure on ise01, is that a good way to accomplish that if you don't have a load balancer?

Redirect public1 redirects the user to the URL public1.customer.ch pointing to the portal on ise01

Redirect public2 redirects the user to the URL public2.customer.ch pointing to the portal on ise02

2. It would, IF we would purge the guest users as soon as they expire, but because we don't purge any guest users, we will always have a portal user attribute. Here it would be necessary to have the possibility to check the expired status of this portal user, or am I wrong?

Concerning the product feature request, can you send me your email address offline, mine is dstalder@itris.ch.

Thanks and best regards

Dominic

[Jason Kunst]

JAK - the authz policy is fine but i like to have Wireless_MAB in every line

By the way, I use the condition Network Access:ISE Host Name EQUALS ise01 and Network Access:ISE Host Name EQUALS ise02 to have a fallback to the portal on ise02 in case of a failure on ise01, is that a good way to accomplish that if you don't have a load balancer?

Redirect public1 redirects the user to the URL public1.customer.ch pointing to the portal on ise01

Redirect public2 redirects the user to the URL public2.customer.ch pointing to the portal on ise02

JAK - ISE will redirect to the correct portal on its own depending on which the PSN RADIUS Request comes in on. Static redirection is only used in specific use case needs. Do you have a special need?

2. It would, IF we would purge the guest users as soon as they expire, but because we don't purge any guest users, we will always have a portal user attribute. Here it would be necessary to have the possibility to check the expired status of this portal user, or am I wrong?

JAK - the portal user id is attached to the endpoint, when the account expires its removed from the endpoint and won't be matched this is explained in that powerpoint you found. let me know if future questions

Concerning the product feature request, can you send me your email address offline, mine is dstalder@itris.ch.

JAK - can you please send your use case through your account team to get to our Product Managers

[Dominic Stalder (old profile)]

JAK - the authz policy is fine but i like to have Wireless_MAB in every line

Thanks, already changed the first line to Guest_Endpoints and Wireless_MAB.

JAK - ISE will redirect to the correct portal on its own depending on which the PSN RADIUS Request comes in on. Static redirection is only used in specific use case needs. Do you have a special need?

Our authorization policies are based on a Static IP / Hostname / FQDN CWA redirect:

If I would like to have a redundancy behind public1.xxx.ch, I would need to configure two A-Records for this FQDN (A-Record for ise01 and A-Record for ise02). Correct? But then the client would take ise01 and ise02 by coincidence, or am I wrong? Or how do you setup this kind of redundancy?

JAK - the portal user id is attached to the endpoint, when the account expires its removed from the endpoint and won't be matched this is explained in that powerpoint you found. let me know if future questions

OK, sorry, didn't see this fact. Will try it!

[Jason Kunst]

Does this help

http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/117620-configure-ISE-00.html

if not

Can you bring up the redundancy on another thread? Its not relevant to the purging

[Dominic Stalder (old profile)]

Hey Jason

thanks, never saw this document before, but it describes exactly the way I configured the static redundancy too:

So I was just "lucky" with my configuration :-)

Have a nice weekend

[alex.fritzsche]

Does this:

If Mab and Guest_endpoints AND portal user ID is NOT NULL then permit access

still work?

We have this Problem too and we only see the dictionary condition "Endpoints:PortalUser" and then can not match for an ID.

Anyway after a guest account expires, and is not deleted, the associated Endpoints are not purged until the Guest-Account is deleted, plus the Endpoint still has the Guest-Username associated as "PortalUser" under Attributes, and not NULL or similar.

Thanks in advance for any reply.

Alex

[Jason Kunst]

Please open a case with the technical assistance center and get associated to a defect

If the behavior has changed then it’s a defect and we need to come up with a new approach if possible

Please also state the associated flow and behavior you would like to see happen

[Jason Kunst]

please let me know the defect as well so i can escalate

[marco.merlo]

Hi Alex,

your hint about using PortalUserID endpoint attribute in the MAB authorization policy worked for ME

Regards

MM