ISE ElapsedDays and RememberMe Guest feature

[Arne Bier]

Hello,

I ran into an issue with ISE Guest functionality. ISE 3.2 patch 2

I wanted to implement a Self-Registered Wi-Fi Guest solution, where users would only see the Guest Portal once, login, and then never see again, until X number of days have elapsed. Cisco calls this the RememberMe feature, and the portal-bypass relies on the existence of the endpoint MAC address in a specific Endpoint Identity Group. When that endpoint is not present in the Endpoint Identity Group, then the URL redirection happens, and the user sees the Guest Portal. That's standard stuff and well documented.

Now my issue:

We know that the ISE Endpoint ElapsedDays attribute is set to 0 when an endpoint is first discovered by ISE.

Example of when purge will produce the undesired result:

Imagine I wanted to use the RememberMe feature and I had a purge policy as follows:

If GuestEndpoints and ElapsedDays GREATER THAN 3

If an endpoint is first seen by ISE on Monday because user connected the Guest SSID, then ElapsedDays is 0. User is redirected to Guest Portal. User has not registered and has not logged in. User leaves the office and returns to the office on Thursday. By then, ElapsedDays is 3 or 4 days. Now the user decides to register, and after successful registration, endpoint lands in GuestEndpoints Identity Group.

On Friday 3AM the purge job runs, and the endpoint is removed prematurely - the user will see the portal again. But we told them they had 4 days of access before they see the Guest Portal again, right? 

There should be another attribute called "DaysSinceGuestLogin" or … the ElapsedDays should be reset to 0 when a user logs into a Guest Account for the first time.

Is the RememberMe feature doomed to fail because of how ISE handles the ElapsedDays attribute?

[hslai]

@Arne Bier This might not be perfect but our internal team suggests to condition on ENDPointPurge:InactiveDays, beside ElapsedDays.

[Arne Bier]

Thanks @hslai - how do they propose such a rule might look?

[hslai]

@Arne Bier DE suggested

> ... we can purge if we set inactive days to less period when compared to elapsed days. when you say that endpoints no longer on network means we are not supposed to updates from that endpoint. so inactive days will increment and endpoint will be deleted.

[Arne Bier]

I think they don't understand the scenario I am painting. I am describing the potential of a mismatch between what the user expects (e.g. 5 days not seeing the portal after login) and what could happen in reality (user logs in on Wednesday and sees the portal the following day) - there is no way that you can use Elapsed or Inactive in that scenario to achieve the outcome that the customer/user expects.

Yes of course we can purge endpoints if they have been inactive for some time - but what if the user is NOT inactive? Then that counter stays at 0. And the user doesn't have to login to the portal to stay active - all they need to do is to be in range of the Guest wifi and leave their device on - the device will keep getting redirected to the portal all day long, which means the endpoint Inactive never increments.

It doesn't matter. Perhaps I should raise an enhancement request to have another attribute added that calculates the absolute number of days since the last successful Guest Portal login. That's essentially what I want.