Thanks Bibin, I have played with this configuration some in the past. With this config if your users have https://www.google.com for their homepage do they get prompted for an invalid security certificate? I think that's where I left that option last. Also, it looks like you're enabling WISPr so that probably means that clients using the Captive Network Assistant for example can't download anything? That is my second problem.
The ideal solution for this in my mind would use WISPr initially but re-direct when it comes time to download a WPA2-Enterprise mobileconfig or get an app from the Google playstore, etc. Maybe a better option does not exist yet... Thanks, Curtis On Wed, June 29, 2016 11:48 am, Bibin George wrote: > For https redirect you need this command on the wlc > config network web-auth https-redirect enable > > I have these three enable in controller > Web Auth Captive-Bypass .................. Enable > Web Auth Secure Web ....................... Enable > Web Auth Secure Redirection ............... Enable > > -----Original Message----- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K. Larsen > Sent: Wednesday, June 29, 2016 12:39 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: [WIRELESS-LAN] Captive Portals, WISPr, and https Re-directs > > Hello, > > I am curious about what people are doing for their Guest captive portals. In > my case, It's been a > bit of a battle to combine usability and security. For example, if I try to > keep a session > completely captive before guiding the user through the onboarding process > that means disabling > WISPr or "web-auth captive-bypass" in Cisco WLC terms so that a user can get > to the play store > during onboarding. > > Of course, disabling this makes it so that the client browser does not > automatically pop-up to > notify the user to accept an AUP or complete the onboarding process, etc. > Since the browser does > not pop-up and auto-re-direct that means a user must 1) open a browser, and > 2) type on non-https > address in order for the web-redirect to work. I think too many users have > an https website for > their homepage ie. https://www.google.com so this means they never get to the > re-driect page > unless they understand to type a non-https URL. > > So, I am playing with a scenario right now that uses WISPr first, then > re-directs to the > onboarding process. This works rather nicely for iOS, OSX, and Windows, but > Android and ChromeOS > want to shut down the WISPr browser after my re-direct. :( > > Just curious: > > Does your captive portal offer WISPr? If so, how are you allowing devices to > the Play Store? > > If no WISPr, have you found some other way to make https re-directs work for > users? > > Let me know. > > Thanks, > > Curtis > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can > be found at http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
