Web Authentication with Android

[Oscar Falcon Ortiz]

Hello guys,

Does anybody know a solution for the issue with web authentication when using Android devices. I've been testing it and it seems to be caused by certificates (as it has been said in others discussions). With https disabled in the WLC (Wism 6.0.196.0), the portal authentications loads, but no with https.

In addition, another issue I've detected is the DNS resolution of my controller by 1.1.1.1 when redirection takes place. With https enabled, DNS resolution and redirection works fine, so I don't think DNS server misconfiguration is the cause of the problem.

I've only been able to see the portal with https disabled and entering manually 1.1.1.1/login.html

Any suggestions? Thanks in advance.

[George Stefanick]

Actually https is not supported for web redirect ..

Sent from Cisco Technical Support iPhone App

[George Stefanick]

Chew on this

http://www.my80211.com/home/2012/7/23/web-auth-redirect-doesnt-work-when-client-uses-a-https-url-c.html

Sent from Cisco Technical Support iPhone App

[Oscar Falcon Ortiz]

Thanks George, but my question wasn't about https redirection, but web authentication and redirection when trying it with android devices.

With "https" I refer to management mode int the wlc, not trying to reach and https web, and get redirected. 

It's with https management mode in the controller when issues appears, maybe because android devices don't validate the selfsigned certificate of the wlc, refusing it silently.

Is there any solution to this apart from disabling https mode in the WLC?

In addition as I mentioned in my first post, I've detected DNS resolution issues with http management mode enabled, when I'm redirected to mycontroller/login.html not being resolved to 1.1.1.1/login.html. But if I enter the URL manually, I get my portal authentication. Maybe is this another issue whit web authentication and android devices??

From PC or laptops, and Iphones, web authentication works perfect regardless of the management mode in the WLC (http or https).

Thanks.

[Scott Fella]

Well the only way around that is to install a 3rd party certificate.

http://www.cisco.com/en/US/products/ps6366/products_configuration_example09186a0080a77592.shtml

If you don't want to install a 3rd party certificate, then you will need to disable https for the management. Is there an issue with disabling https... well it depends on your security policy as you know, http isn't secure:)

With the WiSM2 and newer WLC's running 7.2 or newer, there is a command to disable secure web-auth but still keeping management using https...

Sent from Cisco Technical Support iPad App

[Oscar Falcon Ortiz]

Thanks Scott, I'll study this possibility. I think that getting a signed certificate has costs associated but I'll take it into account if need be.

[Saravanan Lakshmanan]

Did you try different browser?

Did you accept the cert once?

Does Android tries https://google.com for redirection?

Just curious, if its an cert issue then how the page is pulled when trying https://1.1.1.1 manually.

[Oscar Falcon Ortiz]

Did you try different browser?--> Yes, but I get the same.

Did you accept the cert once?-->I don't remember if I did, but I think no...

Does Android tries https://google.com for redirection?-->No, as we know this is not going to work because https redirection doesn't work with web auth. And this isn't the matter of my question....

Just curious, if its an cert issue then how the page is pulled when trying https://1.1.1.1 manually.---> No, I have to enter manually http://1.1.1.1/login.html in order to get web auth portal, but this semms to be caused by a DNS issue with Android devices too, maybe related with the certificate issue...I don't know.

[Oscar Falcon Ortiz]

With only http mode management enabled in the WLC, does anybody notice the same problem with DNS resolution with Android devices once the WLC redirects to the login authentication portal? The only way I can get the portal is entering manually http://1.1.1.1/login.html. I know my device is reaching DNS servers but there is something that blocks http://mycontroller/login.html resolution to http://1.1.1.1/login.html... Has anybody tested this?

Regards.

[David Fitzgerald]

I have a similar situation, but the way I see it, it's an issue with Android that behaves as follows.  This may be my ignorance filter skewing my view, however.  On a droid, I can locate and associate to a guest SSID.  I get an IP, and I become associated, but not Authorized.  If I crank up the browser, it takes me to 1.1.1.1/login.html, and I enter credentials.  So far so good.  I have a long time out (6-8 hours) so I should be set.  Let's say that I walk to a local restaurant for lunch, leaving the reach of my SSID, and hitting the free open SSID at the Starbucks or whereever.  The android associates there no problem.  Back to the office...  I automatically reassociate with my guest SSID, but until I actually use a browser, I don't authenticate.  Thus, any mail client, such as Good, Airwatch, etc, doesn't receive mail until I explicitly use a browser.

Iphones don't seem to behave in this manner.  Does the third party certificate solve this behavior?  The android sw I know of that behaves in this way is 2.3.

[George Stefanick]

David

I believe you are referencing is the browser pop up. Whereby your device connects to the ssid and your browser launches to indicate there is a aup (acceptable use page). This is a vendor thing. Apple does this as part of their browser. Has nothing to do with cents. I gather you are using some type of accept button ? Is that right ?

Sent from Cisco Technical Support iPad App

[Scott Fella]

So what you need is to have your session timeout at around 8 hours and your idle timeout at around 2-3 hours. This idle timeout will keep the device in the run state for that value. 1 hours is too low as some take a long lunch. I find 2 hours good.

Sent from Cisco Technical Support iPhone App

[David Fitzgerald]

Scott, on the WLAN, I see the session timer, but I don't see an idle timer.  The session timer is currently set to 4 hours.  I'm also of the opinion that the power management on the various handsets is an issue.  A phone will shutdown WiFi to conserve power if the device is not actively being poked and prodded.  At a previous employer we'd tell users to just shutdown the phone's WiFi, as the previous mail client (AirWatch) would authenticate over the carrier's network if it coudn't find a valid WiFi path. This seems to work with Good on the Android.

[Scott Fella]

Depending on the code version in the WLC. The general tab in the GUI has the idle timer. On the v74, idle timer can be override in the WLAN advanced tab.

Sent from Cisco Technical Support iPhone App