topic RE: WiNG captive portal re-authentication timeout in ExtremeWireless (WiNG)

WiNG captive portal re-authentication timeout

gluo — Wed, 15 Feb 2017 19:37:00 GMT

Hi, I have setup a captive portal on a VX9000 and I noticed that every day the user has to re-enter the username and password. Is there a way to remain authenticated for as long as the user is valid? Also is there a way to un-authorize a certain user from the captive portal?

RE: WiNG captive portal re-authentication timeout

Ondrej_Lepa — Wed, 15 Feb 2017 20:22:00 GMT

Hello Konstantinos,

based on your Captive Portal design you may either use access time value / timeout

Or if it is driven by RADIUS (internal) you may change RADIUS group attributes

If you want to de-authenticated Captive Portal users you may do it through Statistics - Captive Portal.

Please find Captive Portal How to Guide under this link for more details.

Regards,
Ondrej

RE: WiNG captive portal re-authentication timeout

gluo — Wed, 15 Feb 2017 20:34:00 GMT

Thank you for the swift reply!

RE: WiNG captive portal re-authentication timeout

gluo — Mon, 20 Feb 2017 18:01:00 GMT

Hi again,

I have one more question.
It seems that the maximum amount of time a captive portal guest can be inactive (meaning not connected to the wireless network) without the session to timeout and have to re-authenticate can be 24 hours . Is there any way to set it to more than 24 hours?
This would allow clients to remain connected over the weekend and not have to re-authenticate each Monday for example. Or maybe there is another way?

thank you in advance.

RE: WiNG captive portal re-authentication timeout

Ondrej_Lepa — Mon, 20 Feb 2017 18:01:00 GMT

Hello Konstantinos,

correct - Captive Portal service can maintain authenticated users for 24 hours top.

In theory you might workaround it using CP as fallback and mapping AAA-policy as primary authentication method for a WLAN.
I.e. using authentication based on MAC and AAA you might be able to drive first attempt towards RADIUS server and if this fails, Captive Portal based authentication as fallback.
However, once user gets authenticated and its MAC is withing authenticated, second connection should be first tested against RADIUS server who already know this MAC and there is no need to use CP fallback.

Regards,
Ondrej

RE: WiNG captive portal re-authentication timeout

gluo — Mon, 20 Feb 2017 18:01:00 GMT

Hi,

Does the mac address need to be manually added or it could be added automatically once the user first authenticates via CP?

RE: WiNG captive portal re-authentication timeout

Ondrej_Lepa — Mon, 20 Feb 2017 18:01:00 GMT

Theoretically speaking it shall pass automatically with first CP authentication - then it relies on RADIUS authentication timeout.

Let me test it to get it confirmed.

EDIT: In WiNG 5.8.5 I see the access time is extended to max 10080 minutes / 7 days.

RE: WiNG captive portal re-authentication timeout

gluo — Mon, 20 Feb 2017 18:01:00 GMT

It is the inactivity timeout the value in question that is limited to 1 Day (1440minutes). The above numbers are both the same in 5.8.4. (inactivity timeout & Client Access time)

RE: WiNG captive portal re-authentication timeout

gluo — Mon, 20 Feb 2017 18:01:00 GMT

Hi Ondrej, Did you have a chance to test this?

RE: WiNG captive portal re-authentication timeout

Ondrej_Lepa — Mon, 20 Feb 2017 18:01:00 GMT

Hi Konstantinos,

I setup scenario with AP adopted to a controller when AP had Captive Portal service and controller ran RADIUS service.

Captive Portal configuration as follows:

captive-portal RADIUS
access-time 10
inactivity-timeout 60
simultaneous-users 1

use aaa-policy RADIUS
bypass captive-portal-detection

WLAN configuration as follows:

wlan RADIUS
bridging-mode local
encryption-type none
authentication-type mac
use aaa-policy RADIUS
use captive-portal RADIUS
captive-portal-enforcement fall-back

Then connecting to SSID I see in logs that system first tries to authenticate client against AAA / RADIUS and then failover to Captive Portal

Then successful authentication via Captive Portal pages against same RADIUS server

So in theory this will work fine as you see first attempt goes to RADIUS.
You might noticed a problem though - AAA policy asks to authenticate user 38-F2-3E-18-5B-04

This is result of having authentication method MAC.

So here we go with a fork:

either you have to create a user database based on clients' MAC addresses instead of username and password

or you will use Captive portal guest registration based on your VX-9000

Problem here is that using authentication we need to send a username to question database. With MAC based authentication we use MAC as one and do not actually link it with a RADIUS user account provided through Captive Portal credentials fields. However it works as correctly, it is not designed to be used with anything else than Guest registration.

Regards,
Ondrej

EDIT: Just checked RADIUS group policy for timeout options and I have some bad news - it is also limited to 86400 seconds

However RFC2865 does specify its maximum as 32-bit integer, we have limitation for a day in WiNG

RE: WiNG captive portal re-authentication timeout

gluo — Mon, 20 Feb 2017 18:01:00 GMT

Hi Ondrej, Thank you for your detailed answer and testing. Really helpful information, good job! My use case is site visitors that are being handed out pre-printed vouchers with username/passwords in order to authenticate and being able to access the WLAN, so there is no previous knowledge of the MAC address, hence the first fork does not fit, please correct me if i am wrong. About the second fork, I can not download the document because it takes my to your sharepoint cloud server. So I need your aid with the following: 1. Does self registration allow anyone to access the WLAN? (That would be a problem in this case) 2. Is it possible to provide a username/password (CP) and then the user enter his own mac (AAA)? If the second is possible then the inactivity timeout of the RADIUS holding MAC addresses, would not be a problem since it happens automatically.

RE: WiNG captive portal re-authentication timeout

Ondrej_Lepa — Mon, 20 Feb 2017 18:01:00 GMT

Hi Konstantinos,

here is new link - I probably checked wrong access rights.

Anyway, you are right about the self-registration. This allows everyone to access under condition client finishes registration. Might be OAUTH, Click&Tell etc...

If you provide the username / password you will capture MAC automatically as it is being recorded by Captive Portal. However, here we are hitting the limit of 86400 seconds.

Then, yet another issue - if you select AAA policy to be used here, it does not receive any EAP ID from client - remember this is not set on client!

Any authentication method (other than MAC) requires client to be induced in identification. But with open network client does not provide any.
So in the end authentication request will failover back to Captive Portal.

I am afraid there is only solution for this use case - externally hosted custom pages capturing the MAC used with an CP voucher and creating a fake RADIUS guest user account based on the MAC address - quite demanding one.

Regards,
Ondrej

RE: WiNG captive portal re-authentication timeout

gluo — Mon, 20 Feb 2017 18:01:00 GMT

Thank you Ondrej. Your help was enlightening!

RE: WiNG captive portal re-authentication timeout

Ondrej_Lepa — Mon, 20 Feb 2017 18:01:00 GMT

Glad to help 🙂

Regards,
Ondrej