cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1018
Views
0
Helpful
1
Replies

Issue with MacOS and Anyconnect and Azure SSO

kf4ape-epik
Level 1
Level 1

got a Meraki setup where users connect via Anyconnect (5.1.5.65)...Windows folks are solid, however MacOS are having issues. The problem exists on MacOS versions 14.5 through 15.0.1...the MacOS boxes dont have chrome/MS Edge and just clean MacOS builds...the error message is "Authentication Failed due to problem navigating to the single sign-on URL"....Azure shows clean sign in without issue...anyone else hitting this? I tested this on two meraki implimentations with default configs...one thing I did see was mix match of TLS1.2 and TLS1.3 in the fiddler trace between meraki and azure...that lead me to a few rabbit holes, but nothing solid...

current Meraki MX105, firmware 18.211.2

anyone else seen similar?

1 Reply 1

cooke-jr
Level 1
Level 1

I'm in a similar situation. From what I can tell it comes from MacOS not being able to handle Azure's SAML authentication natively and requires a plugin (requires the use of an MDM platform like Intune with Company Portal). From the looks of it, the token is not properly being stored/converted to the correct URL that is sent back from the device. When I inspect the webpage with developer tools, I keep getting an error along the lines of "Failed to launch ‘anyconnectsso://<URL>’ because the scheme does not have a registered handler." From the research that I have done so far, it looks like it isn't replacing the anyconnectsso:// with https:// which then directs me to a blank page. I'm going to submit a TAC case to see if there is any way to modify the header for an alternate VPN profile for Mac machines, or if this is strictly an issue with how the machines process the headers. I've rarely touched MacOS, so I feel like there might be something done under the hood I'm not seeing.

Edit: I'm an idiot for not fully reading the error that you have. I also had a similar issue a few weeks ago at my job. The thing that prompted the error for us was due to a default browser being manually set, after we pushed out an update to remove Chrome so users would only be able to use Edge. Hopefully this is your solution. This also kind of leads into the issue that I am working on currently. 

I've done some additional research. Some of the information that I've found was incorrect in the sense that the protocol isn't replaced by some variable. The anyconnectsso:// refers to a protocol "handler" that then redirects to an application. Like to how https:// will redirect you to your default browser, or how mailto:// will redirect you to your default mail application. So when the token gets passed to the browser, it doesn't know what application to apply it to since it isn't "registered" (like the error I got). Hopefully your issue doesn't cascade into this, but hopefully this can help provide next steps if manually influencing the browser doesn't.