Page 1 of 1

Authenticating on an Intune managed device

Posted: Wed Dec 04, 2024 5:58 am
by roanutil
My company requires devices be managed by Intune and does not allow authentication with our accounts on non-managed devices. When I try to connect to the company VPN with Viscosity, the authentication fails because it doesn't see the device as managed. Authentication is performed against Microsoft Entra ID. Is there a trick to make this work?

Other apps that are able to authenticate usually open the authentication flow in the default browser instead of what Viscosity does which seems to be a WKWebView. If it matters, the same OpenVPN configuration works when using OpenVPN Connect.

macOS 15.1.1 (24B91)
Viscosity 1.11.4 (1702)

Re: Authenticating on an Intune managed device

Posted: Sat Dec 21, 2024 11:11 am
by James
Hi roanutil,

You'll likely need to ask your system administrator to set an "Associated Domain" for Viscosity. Recent versions of macOS heavily restrict what web credentials, services, and APIs (such as WenAuthn) applications can access on a per-domain basis. By setting an associated domain, that will allow Viscosity full access for that particular domain. The domain should be the domain used for web authentication. You can refer your system administrator to the following article if needed:
https://support.apple.com/en-au/guide/d ... f64513/web

Another possibility is that your VPN Provider is explicitly blocking anything that isn't a web browser (e.g. they're looking the user agent header or something similar). I'm afraid if this is the case you'll need to reach out to your VPN Provider and ask if an exception can be made.

Cheers,
James

Re: Authenticating on an Intune managed device

Posted: Tue Feb 11, 2025 9:14 am
by roanutil
Thanks for the reply. It took a while, but a policy was added for associated domains and the behavior is the same as before.

A screenshot of the policy is available here: https://drive.proton.me/urls/A8Q36S6MTW#9aydzTWVjRS5

Re: Authenticating on an Intune managed device

Posted: Tue Feb 11, 2025 11:16 pm
by sam-mfb
I'm the admin that setup this policy for roanutil. FWIW, we have seen this type of issue before with other applications and it has generally been because the application is using a built in WebkitView rather than the default browser to do interactive browser auth.

As I understand it, the reason for this is because on managed devices SSO is mediated by the token broker/proxy -- which on a macOS inTune managed device is the Microsoft Company Portal app. Full browsers (e.g., Safari, Chrome, etc) will interact with Company Portal to get a token, whereas WebViews don't (at least not by default?).

The other wrinkle going on in this setup is that we require logins to use a passwordless, phishing resistant login, e.g., a FIDO2 key. A simple Webview doesn't present that option (whereas full browsers do). So it's not possible for the users to just bypass SSO and do a direct login (because the Webkit view won't give them the option to use a FIDO2 key).

I've only ever seen this work when the application gives some way to use the actual installed browser for the interactive auth rather than a browser-like view in the app.

You may know all this already, and perhaps I'm misunderstanding something, but thought I'd just add my 2c in case it's helpful.