NPS and Session Timeout Settings

  • 1
  • Question
  • Updated 1 year ago
Looking for some verification that I am setting this up correctly...  

I have NPS running on a Win2012 server in our domain.  I have a network policy set up and have a Network Policy in Aerohive pointing to this RADIUS server.

It works perfectly.  User chooses the SSID, gets prompted for a login immediately, logs in with AD credentials, accepts the certificate and off they go.

Because of the variety of use cases in our environment we would like to enforce a session timeout in which users are forced to re-authenticate after a designated period of time... lets say 600 minutes.

In NPS I chose my network policy, and on the Constraints tab set the Session Timeout to 15 minutes (just to see if it would work).   On the Settings tab I added the Termination-Action attribute with the value RADIUS-Request.

So I cleared settings on a device here and re-authenticated on the associated SSID.  After 15 minutes I am still surfing away... no forced re-authentication.

What am I missing?
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes

Posted 1 year ago

  • 1
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
Have you enabled "Permit Dynamic Change of Authorization Messages (RFC 3576)" under Configuration -> Advanced Configuration -> Authentication -> AAA Client Settings?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Tony,

What authentication means is this for? 802.1X, CWP or MAC auth...

Which version of HiveOS are you using?

It is expected that you should observe periodic RADIUS re-authentication where a Session-Timeout and Termination-Action AVP are sent, as per the expected behaviour of RFC 3580.

We did have a bug in previous versions of HiveOS where the time accrued against the Session-Timeout would be lost for 802.1X when a roam from one BSS to another BSS took place. This is no longer the case with up-to-date HiveOS versions.

I suggest testing with a shorter Session-Timeout for testing purposes with HiveOS 6.5r7 or HiveOS 8.0r1

Thanks,

Nick
(Edited)
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
Thanks Nick...

We are still in the process of updating the APs.  All but the APs in the heavy use buildings are done and we need to schedule these after hours.

Getting back to your last comment....

For the most part basic 802.1x will be fine.  However, we have a few cases where multiple students share a single device.  Because the credentials used in the 802.1x authentication process are passed to our content filter, the teacher often wants the device to be tied to a specific student so that any issues can be traced to that student.  Without the ability to force a re-authentication this is going to be difficult.  It isn't a common situation, but it does exist.

Tony
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi,

There is no conceptual reason to require 802.1X re-authentication as the content filter should be able to consume on-going RADIUS accounting information as well as auth information.

Where re-authentication takes place, you will observe this taking place between the client's supplicant, the AP and the RADIUS server but a user will nearly always not be prompted to re-enter their credentials again where a username/password inner-authentication method has been used as these are normally remembered by the supplicant where they are needed again.

Thanks,

Nick
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
As I said... it is a rare instance.  But an example:

Johnny Smith is using an Android tablet to test an App he wrote in class.  He grabs the tablet, connects to the wireless network with his AD credentials and off he goes.

Next hour Jane Doe wants to do the same thing.  She grabs the same Android tablet and gets right in.  Everything she does is associated with Johnny Smith as far as the content filter is concerned since she was not required to re-authenticate.

What we may have to do in these cases is force the Android devices to a captive portal page right on the content filter.  It will require more granular management of the devices, but might be the most effective route.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi John,

If the device has multiple users, you would need to somehow get the device to forget the existing credentials and would also want to force the client to de-authenticate via a Termination-Action of Default, terminating the session and not re-authenticating.

Typically these type of devices aren't designed for multiple users in this way and, yes, you would I suspect sadly need some form of separate authentication to take place.

Nick
Photo of Tony Andrews

Tony Andrews

  • 52 Posts
  • 5 Reply Likes
Thanks Nick,

Understood.   What we have typically done in the case of shared devices (Chromebooks, etc) is force them to our "DistrictDevices" SSID which leverages NPS and MAC Authentication.  The assumption here is that the devices are being used in supervised conditions where anonymous access is not a big concern.   This may ultimately be how this rare use case is handled.

Regardless, I appreciate your assistance.  I know far more now than I did when I started this thread.

Tony