Splash page authentication problem with macos and ios

[AaronKennedy]

I am encountering a weird problem with =some= Mac laptops and iPhones. One of my SSIDs uses Active Directory authentication on a splash page. These devices CAN get the splash page to show up, and they CAN enter their credentials on the splash page. After doing so, the page tells the user that the device is now authenticated.

BUT... the splash page does not show the "Done" button. Instead, it continues to show a "Cancel" button. The user can wait forever, but the "Done" button never appears. If the user clicks on cancel or closes the splash page, then the device does not gain access to the network [Captive portal is set to block access until authentication is complete]

When I navigate to "Splash Logins" on the dashboard, I see that the user has successfully authenticated the device, but if I go to the client page on the dashboard, I am told the device is 'not authorized.'

Can anyone tell me what is going on and why is it only happening on a few Apple devices?

[PhilipDAth]

Try comparing the Macs that do work versus those that don't.  I'll take a put the ones not working are missing some software update.

[AaronKennedy]

I had time to play around with one user's Macbook Pro (2018) and another's iPhone (4s). The Mac is running Mojave (10.14.6) and the iPhone is running iOS (9.3.5). I can understand if the iPhone 4s has issues due to an outdated OS, but I have had other Macs successfully authenticate today with different macOS all the way back to 10.10.

When I examine the affected Mac in more detail, the client is being tagged with a VLAN by the SSID and issued an IP address in the VLAN's subnet with the appropriate router and DNS server addresses. Then the splash page pops up.  Credentials are provided, and the splash page returns that the authentication was successful.  But the splash page seems to hang at that point without providing the user an option to click "done" or close otherwise the splash page.

On the Mac, I tried the built-in splash page dialog window (uses Safari), but I also tried by bringing up the splash page in Chrome after going to http://captive.apple.com. The same behavior happened using both browsers.

When I do a packet capture with Wireshark, I see a never ending stream of broadcast and probe response entries that only cease when the user presses "cancel" on the splash page.

I'm stumped.  I had 102 different BYOD Macs connect to this particular SSID today and this happened with 9 of them.

[AaronKennedy · Accepted solution]

It turns out I had 27 devices that this happened to yesterday (90% Apple devices). They would...

     a) connect to the SSID

     b) be served the splash page

     c) enter their credentials

     d) be told that they were connected and could now close the splash page

But if they closed the splash page, their connection was dropped and they had to repeat the process all over again.

Things I tried that did NOT work:

1. I rebooted the affected devices
2. I whitelisted the 'check for internet' URLs in the walled garden [captive.apple.com, msfttestconnect.net, *.gstatic.com] to prevent the splash page from being served automatically and forced the splash page to appear manually by doing an http GET request from a web browser. 
3. I revoked device authorization in the Dashboard and de-authorized the user on the 'splash login' page, waited 10 minutes and had the user try to sign in again
4. I Changed the policy on each affected device to "blocked", waited 10 minutes for that change to propagate to all of the MRs, and then changed the device policy to "normal", waited another 10 minutes and had the user try again
5. I had the user connect to an SSID that used a "click-through" splash page instead of Active Directory authentication
6. I turned off "mandatory DHCP" on the SSID access control page, and set a static IP on the device using the appropriate gateway and DNS addresses.

Things I neglected to try that might have worked:

• Clear any stale session cookies from the browser cache of affected devices
• Spoof the MAC address on an affected device so the MR believes it to be a 'new' device 

What ended up working for me...

I created a new open SSID with no splash page (direct access). I had the affected devices connect to that SSID and browse to a couple of different websites. Then I told those devices to 'forget' the open SSID and connect once again to the SSID with the Active Directory splash page. This time, the sign-in process completed and users could click "done" or close the splash page without losing their connection.

I have no idea why just under 10% of the devices on my wireless network suddenly had problems with the splash page, nor do I know why the 'solution' I discovered actually works. I just thought I would document my process just in case anyone ever discovers this thread while searching for solutions to a similar problem.

[ajcamacho]

this solution does not help much, any other ideas?. Tried devices with different versions, all of them failed. keeps blinking on the success page with CANCEL option on the top right side.