How to enable Wireless Captive Portal controller to remember wireless devices

Pkafkas
Pkafkas used Ask the Experts™
on
How are Wireless devices remembered when they try to reconnect to a wireless Network?

I am trying to setup a new enterprise Wireless system and our Corporate Wireless Network uses Widows RADIUS Servers (Network Policy Server).  When the corporate devices connect to our Employee Network  the employee's username/password credentials are remembered the next time they login.

I have also setup a Guest WLan for employees to logon with their personal devices (BYOD) and that WLan uses WIndows RADIUS servers taht are registered to our Active Directory Domain.  The BYOD WLan is actually using the same Windows RADIUS servers as the Employee network is using and authenticatin is working for the BYOD captive portal.

The problem I am running into is that e mobile devices are not able to reconnect to the BYOD WLAN without entering a username/password every time.  Unless they are windows devices (Surface Pro. tablets)  that are not part members of the active directory domain by the way.  So our Android, Apple, linux laptops and phones need to sign in every time because their devices are not remembered.  

The current production system (HP) using different Windows RADIUS servers does remember all mobile devices the next time they try to connect; but, the new system does not.  I am wondering if I need to set a specific configuration on the Network Policy Servers to remember non-windows devices?  It should be possible because the older system can do this.  But the new Wireless Vendor has informed me that to do this I need to allow MAC address caching and that is only allowed if we purchase another appliance.

I am curious about that response.  My questions are:

1.  How do Wireless Systems remember devices when the logon from a web page/captive portal, when using RADIUS servers

2.  Do I need to configure something to enable Windows RADIUS Servers to remember non-windows devices when trying to re-connect to the SSID?

3.  What is funny is that the Windows device reconnect or are remembered easily with this specific captive portal, as long as their MAC address is still in the user table (as long as the session idle time out has not expired).

so how can I enable non-windows device to get remembered?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Adam BrownSenior Systems Admin
Top Expert 2010

Commented:
Windows Clients that connect to Wireless via RADIUS are actually passing the users' logged in credentials automatically after the first login. This is a function of Windows RRAS policies and the fact that most Windows RADIUS implementations also utilize Certificate Based authentication.

Setting this up to work with BYOD devices is much more difficult, since the Windows Client Certificates used for Active Directory RADIUS connections aren't deployed to those devices automatically, and they don't support Windows Native Authentication through Kerberos (BYOD devices are not part of the domain, so they can't use that type of authentication).

If you have an MDM suite that supports certificate enrollment and deployment, you could probably automate this type of thing, but I wouldn't do that with anything other than corporate owned mobile devices.

So, you will need to work with your Wireless controller's settings to "remember" clients that have logged in to the Wireless Captive Portal already. This would likely involve extending out the session timeout interval to something like 30 days or mucking with the RADIUS policies. It probably varies based on the WLAN controller manufacturer, so let us know who makes your devices so we can more easily provide instructions.
PkafkasNetwork Engineer

Author

Commented:
I am wondering how a 10 year old device can remember different mobile devices and automatically re-connect them while not prompting the user to sign in from the portal every time....

When the new replacement device (different company name) forces the same device to re-authenticate.  How does the older controller do this?  Too bad it is end of life and I cannot ask the company's support about it.  But a lot of wireless controllers remember user credentials and auto-reconnect.
PkafkasNetwork Engineer

Author

Commented:
Another problem I am running into is that since these non-windows devices get initially connected but eventually get disconnected, the post authentication user role is still configured at connected until there is an idle time out.  By default the idle time out is set for 10 minutes.

During this 10 minute window after the mobile device (non-windows) got disconnected the same non windows device cannot get to the sign on page until their logon expires from the idle time out.  So if an android device is connected and then restarts their phone they cannot logon again until 10 minutes later.  Unless I manually remove the MAC address from the Wireless controller.

So what i have done is decrease the idle time out to 4 minutes instead of 10 minutes.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Adam BrownSenior Systems Admin
Top Expert 2010

Commented:
I am wondering how a 10 year old device can remember different mobile devices and automatically re-connect them while not prompting the user to sign in from the portal every time....

Put simply, the newer device is implementing more modern security standards or has significant changes to how it implements security.
PkafkasNetwork Engineer

Author

Commented:
Ok, sounds good to me.

I wanted to 'speculate' because of IoT that modern wireless security practices are forcing re-authentication to be less common.  The Wireless Vendor  (ARUBA) is suggesting we purchase an appliance that can be used for MAC Address caching.  I will need to research other alternatives and provide an explanation to my superiors why we will need to purchase another licensed virtual appliance to work with our new Wireless System.

I like the explanation that the new Wireless system is designed to use modern security practices vs the other Wireless system that is used in production.  I just need to put in my time researching ways to have the same result without purchasing any additional options.  Because if I say we need need to purchase something else in addition to what we already have and someone else finds a way to accomplish our goals without purchasing that appliance, then I will look bad and that I gave up on finding a solution to quickly.

So far the best justification that I have come up with is that:

1.  The new Wireless system is using new modern security practices vs the old system.

2.  The vendor technical support staff officially recommends that we purchase the additional virtual appliance.
     a.  I am trying to get the same recommendation from the vendor's sales staff, for MAC address caching.

3.  Perhaps the RADIUS Server authentication for mobile devices (captive portal) authenticates the usernames but
     does not take the devices into account.
     a.  However that is not true because windows devices can re-authenticate with captive portal and RADIUS just
          not non-windows devices.
     b.  Perhaps this is where more modern security practices are coming into place?
PkafkasNetwork Engineer

Author

Commented:
A better explanation was provided by teh vemdor:

• Initially regarding your query “Does RADIUS server authentication validate the username for authentication and not take into account the devices?”
◦ Yes the authentication servers will validate the username and password for authentication and the devices are not taken into account.


• And you would also like to have an understanding about how captive portal authentication with internal database works, as the clients are able to re-authenticate without any issues.
◦ When the internal database is made the authentication server, once the users credentials are verified it assigns a user role to the device and stores the username and MAC address of that device in its user-table.
 
◦ So basically in this way it remembers the Mac address of the device. Thus in this case where the controller is the authenticator the next time when the device tries to connect to the SSID, the controller will push the post authentication role if the device tries to connect within the idle timeout. This is the reason why the authentication type shows as MAC on user-table for captive portal based SSIDs, when the user re-connects within the idle time.


• This is the reason why MAC address caching is not needed when we use internal captive portal. However the advantage of having Mac address caching is you can set a timer for few days, whereas the user idle timeout on the controller can be set up to only few hours.
PkafkasNetwork Engineer

Author

Commented:
Is there a way to force Windows RADIUS Servers to to authenticate with remember non-windows devices like it does with Windows devices?

I know it was done with the older system; but, is that a security flaw with the older system?  Is it better design to use a system with MAC address caching for mobile devices?  

Perhaps the Windows RADIUS servers work better to recognize windows devices but not so well on non-windows devices.  The fact it successfully recognized the non-windows devices before may be a security flaw.  Or is there a setting on the RADIUS server that is required to make this work?  

Basically does the older device authenticate non-windows devices because it is using older non-standard security protocols?
Network Engineer
Commented:
I ended up allowing a rule to allow DHCP from any device after the user/device was authenticated.  After the device was authenticated and is still in the Wireless LAN's idle time out threshold it will automatically re-authenticate.  

Before it would try to re-authenticate but I say on my phone "... Obtaining IP address....." and it eventually timed out.  The same problem or error did not happen on windows devices.  After adding the rule to use DHCP from any device in the post authentication settings the non-windows devices re-authenticated.

That is as long as the wireless connection was within the idle time out threshold before the wireless controller disconnected the session from idle time out.
PkafkasNetwork Engineer

Author

Commented:
Now the vendor stated in order to re-authenticate automatically we needed to purchase an additional service/product.  But that was not the case.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial