cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1673
Views
0
Helpful
11
Replies

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

kshah2589
Level 1
Level 1

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

11 Replies 11

kshah2589
Level 1
Level 1

Just waiting to see if anyone has any suggestions.

Greg Gibbs
Cisco Employee
Cisco Employee

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.

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

@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.

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

@kshah2589 Just as Greg already suggested,

> ... with the CNA bypass feature enabled.

Screenshot 2023-12-26 at 18.32.39.pngScreenshot 2023-12-26 at 18.35.29.png

 

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.

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.

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

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.

kshah2589
Level 1
Level 1

So we were unable to continue to implement the solution.

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.