Disconnect a guest session after allowed working hours.

[tertang@cisco.com]

Can ISE send or support  a RADIUS CoA Disconnect using admin-reset workflow to kickoff  a current guest session after the allowed working hours is up?

i've thought about using the endpoint purge policy to kick off the guest user but this will not disconnect the existing session and also requires the guest to re-register again the next day.

-terence 

[Jason Kunst · Accepted solution]

The recommended way to set login times is via the guest type. This will require the user to login to the guest portal every time there is a new wireless session ID. Not the best experience but the only way to enforce times is with portal login.

You will also need to make sure you have locations (time zones) setup for all sites that require this support. A self-reg or sponsored guest will need to choose the corresponding location of the guest, otherwise the times won’t match.

If the guest is not logged out automatically at the stop time (don’t think it works like that) then you could try forcing a session terminate every 60 min in the RADIUS session timeout. This will require them to hit the portal to login and enforce login times.

Other than this you would have to script it to kick users out after a certain time and force to login to the portal again.

[tertang@cisco.com]

Hi Jason,

The use case isn't so much of admitting new guest users into the network/enforce network login timings- but to make sure no guest users remain on the corporate network after working hours.

i've discussed with the wireless CSE and talked about the possibility of using a global session timeout on the WLC to limit time on each wireless connection. but foresees other issues on using this option.

Also not sure if enforcing a session timeout attribute and forcing a re-auth on ISE will work out and kick that wireless guest session off the network.

appreciate your thoughts on this.

-terence

[Jason Kunst]

I think the radius session timeout terminate will work for you, try it out

[gbekmezi-DD]

I think Jason’s idea may work. If you don’t want to force guests to authenticate every hour, you could create 8 (or whatever the working hours you are looking for are) time and date conditions as well as 8 authz profiles. Time and Date condition 1 may be match 8:00AM - 8:59AM. Time and Date condition 2 may match 9:00AM - 9:59AM. 3 - 8 would follow that pattern as well. Then each T&D condition would be paired with a unique AuthZ profile where the first one allows for an 8 hour session timeout. The second 7. The third 6 and so forth. It’s a little bit of work up front, but it won’t be too bad if you have your guest ssid in a separate policy set or at-least a wireless policy set. Good luck!

George

[Jason Kunst]

Good point if you have a general rule then they would get kicked out every so often which doesn’t work well. Your way is better butnot sure how the time zones play in that scenario

[tertang@cisco.com]

So i've tested and session-timeout was working as intended, the WLC de-auths the wireless client once the timer expires on that session in WLC.

Some behaviours i've observed:

1. I've configured the session-timeout to be 32400sec/ 9hrs working hour but upon authz, i see in the logs ISE can only send *a maximum value of 3660secs.

2. cosmetic issue: ise logs shows the session-timeout metric in milliseconds instead of seconds

Point 1 issue is preventing me from testing out George's idea!!!

[vibobrov]

You can also do device registration to record the mac address of the users and unconditionally kick the sessions out once an hour or even more frequently. This will force the guests to continually re-authenticate through the AuthZ policy. You can configure the AuthZ rule that allows the guest MAC addresses on only when the attempt is within business hours.

[Jason Kunst]

vibobrov assuming this would be using API

[Jason Kunst]

To clarify. If I wanted to make sure the time was associated with Boston for example then my Boston Network Device Group would need to be called out in the authz rule. I would need to assign the correct time based off my PSN time, if I used UTC for all my deployment or another timezone then I would need to make sure the time I entered in the rule was the correct time with timezone correction

another option

You could create a new device group called time zone where you can populate the timezone for each device, rather than keying on the location.

Yes, the time conditions would have to be offset based on the timezone configured on the PSNs.

For example, if the PSNs are in UTC, the condition would be like this

If DEVICE:TimeZone==EST and Time between 4am and 2pm then allow guest.

Due to summer time, we would probably have to extend the range by an hour.

[Jason Kunst]

please let us know how it works out