Guest Hot Spot and LastAUPAcceptanceHours - how does this work?

[Arne Bier]

Hi

I have a requirement to provide a Hot Spot AUP page and allow guests to browse internet for 1 hour.  After 1 hour they need to see the AUP again.

I don't know where this is defined, but I have to assume that

LastAUPAcceptanceHours = ROUND(CurrentTime - LastAUPAccepted)

I devised the following Policy Set in ISE 2.4/2.6 but, the same logic doesn't work in ISE 2.2

I think the issue is that new MAB connections (Endpoints never seen in ISE before) reach this point of the Policy Set processing, and will fail the first Condition, since the Variable LastAUPAcceptanceHours is undefined - and therefore client fail through to the bottom rule which results in HOTSPOT_PORTAL_INTERNET (i.e. they are allowed onto the internet without seeing the URL redirection)

In ISE 2.4 I take an unknown endpoint, click on the Wi-Fi SSID and I observe the iPhone spinning its wheels while ISE finally decides to redirect to the URL (in that whole time, the endpoint's LastAUPAcceptanceHours goes from undefined (i.e. cannot find it in the properties) to 1500 suddenly) - and at that point the AUP pops up.

I have seen this happen and it made me wonder whether I am using this incorrectly.  Now that I look at the above Conditions it doesn't look right - >=1 means 2 hours, not 1.  But the matter of the principle is that how do I tell ISE to send a customer to an AUP if

LastAUPAcceptanceHours = <UNDEFINED>  (i.e. new client)

or

LastAUPAcceptanceHours >1

Even if ISE were to initialise the variable to 0 on new Endpoint creation, what would that look like?  LastAUPAcceptanceHours =0   - well then my logic would not work either

LastAUPAcceptanceHours >= 1    is not equal to   LastAUPAcceptanceHours = 0

When ISE creates a new Endpoint in its database, I have seen it set it to 1500 hours!  Yes.  62 days.  is that a bug or normal?

Has anyone got this working in ISE 2.2 (customer on patch 8) ? - don't get me started on patching ... yet. I just want to see if I am configuring this correctly.

[Surendra · Accepted solution]

Ideally the rules should be like this :

If LastAUPAcceptance >= 24: Hotspot Redirect
If LastAUPacceptance < 24: PermitAccess
If Wireless_MAB: Hotspot Redirect

This will ensure that no endpoint gets access to the internet if AUP is not accepted in the last 24 hours.

[Surendra]

Also, could be CSCvg46899 which is fixed in patch 9.

[Arne Bier]

Thank you @Surendra 

I didn’t think of using that three stage logic. Seems obvious now. I will give it a try. 

[absuizo14]

what does this look like on ISE 3.0?

[Arne Bier]

@absuizo14 - not sure what you mean. The same compound condition can be built in ISE 3.0 using the same three components - the same logic still applies in ISE 3.0

[absuizo14]

Im sorry @Arne Bier . not to much experience on ISE i tried to use the rule but what happened was when i accepted the AUP and got redirected to the success page i was stuck there with no internet. what we are trying to achieve is that hotel guests that are staying in the hotel for more that 48 hours should go through the aup again. this is what the policy look like.

[Arne Bier]

It appears that you didn't send the correct Authorization Results to the wireless controller. Permit-Access is not enough. Depending on what the controller is, you need to return an ACL that blocks internal network access, and allows internet access. These ACLs are discussed quite often in the Community and elsewhere on the web.

[absuizo14]

Hi @Arne Bier actually without the LastAUPAcceptanceHours it works fine. when  guests connects to the ssid they are redirected to the AUP and once accepted they go to a landing page and can connect to the internet. the only thing we need is that hotel guests that are staying in the hotel for more that 48 hours should go through the aup again.

[Arne Bier]

Ah ok - the GuestFlow condition is the issue. In order for GuestFlow to be TRUE, the user must have just logged in, and the RADIUS Accounting Start received from the WLC. But when a user disconnects from the WLC (due to expiry) then the WLC will send an Accounting Stop to ISE. And then GuestFlow is FALSE.

Instead of GuestFlow, use the "Remember Me" feature (as Cisco calls it). Every authenticated user's MAC address should land in an Endpoint Identity Group. And you authorize Internet Access if (and only if) that MAC address is still in that Group.

48 hours lifetime is achieved by purging that Endpoint Identity Group. It's not an exact science and there have been discussions for many years how to do this. I would simple run a purge job at 3AM if the ElapsedDays attribute of an endpoint is greater than 2 days. That will give you at least 2 full days and a bit extra.

[absuizo14]

Hi @Arne Bier thank you for this advice. we look into purging Guest accounts and found 2 settings. may we ask what is the difference between these 2?

and 

[Arne Bier]

Ok so there are two things at play

- Guest account (usually a username/password - this has a start and end date that ISE validates when a user tries to authenticate on a Guest portal. These accounts can be deleted, suspended etc.) - When you delete a guest account manually, it will send a CoA Disconnect to the WLC/Switch to kick the user off (if there is a live session) and it will delete the user account

- Guest endpoint (this is the MAC address that ISE records against the user who logs in via a guest portal. - if you delete the MAC address (manually or via purge) then the authorization policy for Remember Me will force the guest back to the portal. As long as the MAC address is still active in ISE, the Remember Me feature will not display the portal - the guest will be on the internet.

The best thing to do is to read this great guide - I put the link in that takes you directly to the Remember Me,