Captive portal behavior with Ipads/Iphones

[BobW]

I am using the CP quite successfully.  However, I am running into some strange behavior with the Iphones and ipads.

If I connect a (non AD Bound) computer to the wireless, it connects fine and I get prompted for the captive portal only when I try to get to the internet.  Perfect behavior.

When I attach on Ipad or Ipod to the wireless, as soon as it connects the captive portal immediately pops up.  If the user chooses to not authenticate, the wireless immediately gets dropped.  Strange since the wireless is a Ruckus device and the DHCP is from our internal windows servers.  Seems to me it shodl keep the connection and get an IP even without logging in through the CP.

The reason this is bad is the client is then mapped as a CP authenticated user before I can attach the client to the Exchange server.  If the user was attached to the exchange server is should be an AD/agent based IP mapping and the user should not be prompted for credentials.

Any thoughts on how/why this occurring would be appreciated,

Bob

Note it seems I can get around this by authenticating via CP, attaching to Exchange, going to the CLI and clearing the ip mapping method, which then picks the authent method from the Exchange event log.

[Lucky7]

My experience is the new IOS wants to connect to apple.com immeidately to verify if it has internet access.

[essnet]

I have same opinion than Randall : if you don't provide login, IOS device will cycle Wifi and retry later

[BobW]

So after digging a bit deeper, this IOS thing has become messier.

A new Ipad "activates" by hitting the internet with web browsing, OCSP, facetime, itunes etc.  With captive portal turned on, the unit can not activate as the CP never shows up.

After the unit is activated (via a non CP network) and the IOS device is attached to the SSID, it immediately calls home as shown here http://erratasec.blogspot.com/2010/09/apples-secret-wispr-request.html .  That then forces the user to authenticate via CP.  Problem is if the unit is on a network with exchange, the preferred method is to map the ip-user via the Exchange logs which can't happen until it is on the wireless.

So it looks like:

A non CP zone must be propped up just for activation of the units.

A rule must be set to allow the unit to "call home" in order to avoid the captive portal.

I have attempted to create a rule to just allow web-browsing to the special URL with no luck.  For some reason, the rule allows web traffic to different URLs as well.

I hope the above helps, if anyone has an idea as for a rule to allow all users to get to www.apple.com/library/test/success.html via the following I would appreciate it.

GET /library/test/success.html HTTP/1.0

Host: www.apple.com

User-Agent: CaptiveNetworkSupport/1.0 wispr

Connection: close

Bob

[BobW · Accepted solution]

I have an update on this issue which I hope will help someone.  After working with tech support this afternoon, they helped create the necessary rules to work around the issue.  While its sounds fairly simple in practice, the tech (who was excellent), agreed that this is a funky issue and will be researching it further.

The solution is to create a "no captive portal" rule to be applied when going to a custom url category containing www.apple.com/library/test/success.html.

Then we created an allow rule for unknown users to allow web-browsing with a destination address (FQDN) for www.apple.com and a custom URL profile blocing all except  *.apple.com, www.apple.com etc.

This allows the Idevices to hit apple.com and avoid the  captive portal during the startup process thus allowing the ipad to be on the SSID long enough to be connected to the Exchange server.

Bob