topic Re: Issue with SAML SSO based Password less BYOD flow for Apple device in Network Access Control

Issue with SAML SSO based Password less BYOD flow for Apple devices

kshah2589 — Mon, 04 Dec 2023 22:34:53 GMT

Hello Community,

The SAML SSO based Password less flow(from Meraki >> Cisco ISE >> Microsoft Azure ) with windows and Android devices working properly. We are having challenges with Apple devices. when we connect Apple devices to SSID, the apple CNA(mini browser) pop up automatically and get redirected to Microsoft login page where we are putting username and then getting 2-digit code in authenticator app to confirm. After that, looks like the flow breaks and as a result we couldn’t complete a successful authentication and redirected back to ISE to complete next page in flow(ex: AUP).

However, Disabling CNA allowing us to manually go to browser and type in http website for automatic redirection and we can be able to complete successful authentication and access the internet.

Let me know what could be the reason and how can we remediate the issue?

Regards,

Kunal

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

kshah2589 — Mon, 11 Dec 2023 17:33:49 GMT

Just waiting to see if anyone has any suggestions.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

Greg Gibbs — Mon, 11 Dec 2023 21:53:55 GMT

The Apple CNA is not a full-feature browser and is know to cause issues with some portal-based flows. There have also been multiple past instances in which Apple made changes to the CNA without notification which broke previously working flows.

If the flow works consistently with the CNA bypass feature enabled, the recommendation would be to keep it enabled and communicate the expected behaviour to your users.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

kshah2589 — Wed, 13 Dec 2023 14:58:36 GMT

Hello Greg,

Please find the additional below observations from testing of different Apple devices with password less SSID. Apple CNA(mini browser) is enabled.

1). iPad/MacBook laptop

Connects to SSID >>> Apples Captive Network Assistant brings up the Captive Portal >>> user redirected to Microsoft login page >>> enters credentials and user prompted for 2-digit code in authenticator app to confirm identity >>> user redirected back to ISE for next steps(ex: AUP) >>> the flow works, and user can browse internet.

2).iPhone with two different scenarios.

A).iPhone connects to SSID with Microsoft authenticator app is in different device : the process is same as above mentioned >>>> the flow works, and user can browse internet.

B). iPhone connects to SSID with Microsoft authenticator app is also in same device : connects to SSID >>> Apples Captive Network Assistant brings up the Captive Portal >>> user redirected to Microsoft login page >>> enters credentials and user prompted for 2-digit code in authenticator app >>> User switches to Authenticator app to confirm identity, this action closes the Apple Captive Network Assistant(mini-browser) >>> which breaks the flow and user cannot proceed as Apple CNA starts again and repeats the above loop without success.

Let me know your thoughts and next steps we can take to fix the issue.

Regards,

Kunal Shah

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

hslai — Fri, 22 Dec 2023 23:54:10 GMT

@kshah2589 : I am with @Greg Gibbs that the issue is due to the wall-garden by the Apple CNA. Whenever we switch to another app, it terminates the wall-garden process.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

kshah2589 — Sat, 23 Dec 2023 00:20:49 GMT

Hello hslai,

Thanks for reference. I am not sure what you mean by that, if you can rephrase for me. what's the solution to fix the issue because Android doesn't have the same issue?

Regards,

Kunal Shah

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

hslai — Wed, 27 Dec 2023 02:38:39 GMT

@kshah2589 Just as Greg already suggested,

> ... with the CNA bypass feature enabled.

By comparison (at least on my Android test devices), the mini browsers on Android devices seem more capable in handling JavaScript, and multi-webpage on-boarding, and more flexible because it does not terminate the Internet connections when switched to Cisco Network Setup Assistant to complete the cert provisioning, etc.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

joshhunter — Wed, 30 Jul 2025 22:07:40 GMT

I’m resurrecting this old thread to check whether there have been any improvements or viable workarounds for Apple devices in recent years.

As previously discussed, the Captive Web Portal flow using SAML login (Microsoft Entra ID) still appears to break on Apple devices. Specifically, the issue occurs when users authenticate via the Microsoft Authenticator app—the Apple Captive Network Assistant (CNA) mini-browser closes once the app is launched, and users are not returned to the portal, breaking the login process.

Have there been any updates, best practices, or configuration changes from Cisco or Microsoft to mitigate this behaviour?

Appreciate any guidance or recommendations.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

joshhunter — Wed, 30 Jul 2025 22:08:11 GMT

I’m resurrecting this old thread to check whether there have been any improvements or viable workarounds for Apple devices in recent years.

Have there been any updates, best practices, or configuration changes from Cisco or Microsoft to mitigate this behaviour?

Appreciate any guidance or recommendations.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

kshah2589 — Wed, 30 Jul 2025 22:56:53 GMT

Our team has tried everything to fix the issue but no updates have been provided from microsoft/apple.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

kshah2589 — Wed, 30 Jul 2025 22:59:05 GMT

So we were unable to continue to implement the solution.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

joshhunter — Fri, 01 Aug 2025 18:39:31 GMT

Thank you so much for your reply!

It’s unfortunate — we tested the flow without the Apple Captive Network Assistant (CNA), but despite using publicly signed certificates, the device still displayed certificate warnings. Disabling the CNA entirely doesn’t seem like a practical solution, especially for non-technical users.

It’s also disappointing that DHCP Option 114, which is Apple’s recommended method for launching the portal in Safari (instead of the limited mini-browser), isn’t currently supported by Cisco WLC or ISE.

I am aware that Apple iOS 18 introduces some improvements around captive portals but unfortunately I cannot see any enhancements specifically for thie issue: switching to the Microsoft Authenticator app still causes the CNA browser to close and break the login flow. DHCP Option 114 support on the network side would be the most effective route forward, but it’s currently not implemented by Cisco.

As it stands, Android devices work well, but for iOS, the limitations with CNA + SAML + Authenticator remain unresolved.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

irfsalam — Wed, 12 Nov 2025 10:14:32 GMT

I’ve spent a couple of days setting up DHCP Option 114 and an API server to return the user portal URL for Apple devices. But even after all that, macOS and iOS still open the captive portal URL inside their mini-browser, which messes up the number matching in the Microsoft Authenticator app.

So, from my experience, even with DHCP Option 114 in place, Apple devices still break the MFA flow by launching the portal in that mini-browser instead of Safari or the default browser.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

joshhunter — Wed, 12 Nov 2025 18:18:07 GMT

iOS 26 is the same also. Still only working on Android.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

joshhunter — Wed, 19 Nov 2025 15:18:12 GMT

The only other thing I can think of trying is 'turning off' the Mini-Captive Browser i.e. disabling Captive Portal detection.

So, from the Cisco 9800 Wireless Controller enabling captive portal bypass.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

joshhunter — Fri, 21 Nov 2025 14:21:06 GMT

I have now re-tested using the 'Captive Bypass Portal' feature on Cisco 9800. This allowed the Apple iPad/iPhone with the Microsoft Authenticator App on the same device to login via the Captive Portal Page using Cisco ISE - Azure SAML.

Disabling Apple Captive Portal detection seems to be the only way to get this to work. By preventing the Mini-browser from opening it stops the session from being closed when the Microsoft Authenticator App is opened.

Re: Issue with SAML SSO based Password less BYOD flow for Apple device

joshhunter — Fri, 06 Mar 2026 11:43:56 GMT

Hi All,

We have this workaround implemented now, it requires the user to open Safari and trigger the re-direction via HTTP webpage....

In summary,

Apple iOS opens captive portals in a mini-browser (CNA). When Microsoft Entra authentication requires the Microsoft Authenticator app to open on the same device, the mini-browser session closes and the login process fails.

To resolve this, Apple captive portal detection was effectively bypassed by allowing access to captive.apple.com / Apple connectivity check domains in the pre-auth ACL on Wireless Controller. This prevents the Apple mini-browser from launching and allows authentication to occur in the full Safari browser instead, enabling the Microsoft Authenticator app to open and complete the login.

As a result, of 'disabling' Apple CNA, the login page will not automatically appear when connecting to Wi-Fi. Users must open a browser and visit a non-HTTPS website (e.g. http://neverssl.com) to trigger the redirect to the Cisco ISE login portal.

As we have a single portal with Employee Login for Guest and Visitor Self Registration for Guest, these instructions are provided to the Employees and Visitors and a link to the HTTP webpage via QR code. The customer has set up an HTTP webpage, i.e. http://wifi.[thecustomer].com as part of this process.