ISE Guest Captive Portal - Generic Guest user (unlimited devices, each device having a timeout)

[Ralphy006]

I'm trying to get the ISE Guest Captive Portal working with a generic guest user. The username is "guest". We will be having many users using this generic user, so the number of devices needs to be unlimited.

We are hoping to create a timeout for each device that's logged in (24 hour).

So if phone1 connects on Monday, 11am, we would want phone1 to have to reauth on Tuesday, 11am.

If phone2 connects on Monday, 12pm, we would want phone2 to have to reauth on Tuesday 12pm.

Can this be done? What is best practice?

My initial thought was to set it up like this:

-Create a network access user called "guest"

-I'm not sure if I should set it as a "GuestType"

Thanks!

[Jason Kunst]

Please explain what you mean by reauth. Is it a new set of credentials? Or simply to be shown the login page?

[Ralphy006]

Sorry for the confusion. reauth = forcing to logon again via the captive portal with the SAME username and credential.

Would this be accomplished with an Endpoint purge rule? Where I can create a rule stating "GuestEndpoints" get purged when greater than 1 day?

My concern is that the "rules" (ie account duration) associated with the generic guest user found in the Guest Type follows the user, as opposed to the device. So I'm concerned if I set the account duration to 1 day in the Guest Type, ALL devices using the guest user will stop working a day after the first guest user logged in.

Sorry if this is confusing.

[Jason Kunst]

Please see the guest deployment guide (remember me section) and let me know if something is not clear
https://community.cisco.com/t5/security-documents/ise-guest-access-deployment-guide/ta-p/3640475

[Ralphy006]

Jason,

Awesome document. The "Remember me" is exactly what I was a looking for.

I still have a couple of questions though.

QUESTION 1:

If I have an Endpoint Purge rule:

GuestEndponts AND ENDPOINTPURGE: ElapsedDays GREATERTHAN 10 Days

Does this mean, a GuestEndpoint has been in the database for greater than 10 days, it will get purged during the scheduled purge time? But if less than 10 days, it will remain?

QUESTION 2:

The "Guest Account Purge Policy". There is a setting that says "Expire portal-user information after: x days. Unused guest accounts (where access period starts from the first login).

Does that mean the guest account will be purged ONLY if the guest account is NOT used for x days?

QUESTION 3:

Your document seems to suggest "generic" and "shared" logins should be done via the Hotspot portal. And the username/password is more for Registered and sponsored access. However, I hope to do something in between. Where we have shared username/passwords. If so, would best practice be to add the users as manually created Network Access Users?

Thanks in advance!

[Jason Kunst · Accepted solution]

If I have an Endpoint Purge rule:

GuestEndponts AND ENDPOINTPURGE: ElapsedDays GREATERTHAN 10 Days

Does this mean, a GuestEndpoint has been in the database for greater than 10 days, it will get purged during the scheduled purge time? But if less than 10 days, it will remain?
JAK - CORRECT

QUESTION 2:

The "Guest Account Purge Policy". There is a setting that says "Expire portal-user information after: x days. Unused guest accounts (where access period starts from the first login).

Does that mean the guest account will be purged ONLY if the guest account is NOT used for x days?

JAK - guest accounts are purged if they are expired or if they go unused (never activated)


QUESTION 3:

Your document seems to suggest "generic" and "shared" logins should be done via the Hotspot portal. And the username/password is more for Registered and sponsored access. However, I hope to do something in between. Where we have shared username/passwords. If so, would best practice be to add the users as manually created Network Access Users?
JAK - hotspot is for no logins. its just a mac address accepting an AUP
credentialed flows - self-registration and sponsored are used for creating and tracking specific information to a user. You can certainly use internal users if you like. These are treated as employees. 1 account however can have no more than 999 endpoints registered to it. This is used for the remember me flow.

What exactly are you trying to accomplish? Why do you need accounts if you are going to share them? why not just use a hotspot portal with an access code and an AUP instead?

[Ralphy006]

Thanks, all great comments.

The use case?

-We want some sort of credentialed access with an AUP (this can be done with the hotspot with access code, or with username/password

-We were leaning towards the username and password, so we could have the flexibility of spinning of a different user if we ever had a unique event. For example, or day-to-day guest users would be "guest". If we had a one-night event, we could create a user called "event1" and have a unique password. And then we could remove the user when the event is over. The Hotspot with access code seems inflexible since it can only have ONE access code. But it might be the better solution due to the 999 device limitation associated with a user.

With the Hostpot/access code... once they acknowledge the AUP and enter in the code, the device's mac address becomes a part of the Endpoint Database as a "GuestEndpoint"? (just double-checking to make sure I can leave my AuthZ policy the same where it permits access to (Wireless_MAB AND GuestEndpoints) to accomplish the "remember me")

[Jason Kunst]

OK i understand your use case, please do get this to our product manager through the sales team so they can add you to the list requiring this, you're looking for an event ID tracking type of code. Another way would be to have multiple guest portals. Have a hotspot portal linked to other hotspot portals that could be temporary. This is a little more complicated as well.

https://community.cisco.com/t5/security-documents/ise-hotspot-portal-with-links-to-employee-or-vendor-portals/ta-p/3643513

Yes with hotspot it gets registered to the same endpoint group. You can see this under the portal settings.