Issues with onboarding/authenticating mainly BYOD devices - How are you all doing this?

  • 1
  • Question
  • Updated 2 months ago
  • Answered
I am working to deploy a new Ruckus system to replace our aging Cisco.  We have two SmartZone 100 controllers and hosted Cloudpath setup.  Our test users have had a terrible time getting their BYOD devices connected to the system.  The first hurdle was that users on Android were attempting to use the Android CNA browser which wouldn't allow them to click the button and get to the playstore to download the Cloudpath app.  After adding the Google connectivity checks in the walled garden and having them use a different browser we have issues with the redirect failing due to HSTS.  The process has been even worse on ChromeOS.  I am experimenting with the idea of using local NPS for Radius login but was wondering what everyone else is doing.  Maybe a redirect to a login portal that will take their AD credentials?  Throw me some ideas.

Thanks!
Photo of John Westlund

John Westlund

  • 10 Posts
  • 2 Reply Likes

Posted 2 months ago

  • 1
Photo of Alex Shalima

Alex Shalima

  • 45 Posts
  • 18 Reply Likes
John,

We have done it with Active Directory, Guest Portal and RADIUS. 

AD:
If you have AD already, then it would be a legit way to save yourself time of not creating a new authentication method for your customers. All you have to do is to add AD server under AAA Servers, allow your Firewall to talk to Ruckus SmartZones and change your Authentication type for your WLAN (configure the WLAN).

PROs: Secure Access to your network
CONs: Users without AD cannot connect, when AD is down - Wi-Fi is down


Guest Portal:
Another way could be a guest WLAN that points to the Ruckus Web Server with a preset Portal Page. Credentials can be created inside the Smartzone to be used with the WLAN.

PROs: Anyone can connect
CONs: potentially devices not getting a portal page (old devices)


RADIUS
RADIUS server can be used as well. You have to define a criteria against which you will authenticate. It can be MAC addresses of the customer devices (have to be known in advance), SSID to which they can connect (here you would turn on full wireless client isolation to the gateway).

PROs: Anyone can connect (depending on config). Flexible way to authenticate. No portal needed.
CONs: when RADIUS Server is down - Wi-Fi is down 


P.S. Also, a good old WPA2 AES is always an option. Just turn on full wireless client isolation all the way to your Gateway, put guests on separate VLAN and tunnel your traffic on encrypted tunnel to the Smartzone (WRG Tunnel under your SSID). Change your password once in a while. Profit.


Cheers,
Alex
(Edited)
Photo of Abhi Maras

Abhi Maras, Employee

  • 19 Posts
  • 10 Reply Likes

Hi,

Unfortunately both iOS and Android are restricting the capabilities of the pop up browsers effectively letting them do a simple mac authentication only including avoiding ability to download or even redirect thanks to HSTS. To circumvent this, we have identified one of the methods to avoid this. This method is not a clean-cut solution but still worthwhile IMO and we are evaluating to add this as a config option in Cloudpath itself.

 Below are the high level steps

  1. Create 2 workflows; workflow1 for simple mac auth and workflow2 for standard TLS onboarding
  2. Use workflow1 as the redirection URL in the controller for the onboarding SSID
  3. Enter the workflow2 URL in the controller for final redirection instead of the URL user intends to visit (or typically Google.com) and/or have a link/continue button on final page to redirect to workflow2 (A link or continue button that hyper links to workflow2 is especially needing for Android)
  4. Have a session timeout for <5 mins for workflow 1 when the initial mac auth is done

 

The benefit of above is since we are doing only mac auth initially, the CNA browser will work fine. Once the mac is registered AP/controller will drop the firewall and redirect the user to workflow2 for TLS onboarding. Since the device is allowed access (with a session timeout for about 5 mins), device should auto redirect to a full browser and user can complete the TLS onboarding. For Andorid users they will have a continue button that redirects it to workflow 2 automatically on a full browser.

 

All this is transparent to end user and their experience will be like a single workflow and this will avoid whitelist, HSTS redirection and CNA browser issues – this solves all 3 issues. It is a bit cumbersome to setup and could have some timing issues with mac auth to complete and TLS onboarding completion in that window but the benefits far outweigh the cons.


Stay tuned for CP 5.4 to have a more cleaner solution for the iOS and Android behavior changes.


Photo of John Westlund

John Westlund

  • 10 Posts
  • 2 Reply Likes
This seems like what I need.  I already have our workflow configured which would be what you referenced as workflow2.  Any steps on creating the first workflow?