Anyconnect VPN with Azure idP and Conditional Access on Android

[Zimble]

Yeah, so the title's a mouthful, but here's the gist:

• Android device managed by intune

• Anyconnect using Azure for authentication

• Conditional access policy requiring device to be managed by Intune to join

• Device is 100% compliant with Intune, user can VPN from any non-android device just fine, other apps work no issues

I keep hoping they'll fix it, but it's literally been years. When you launch the Secure client from the work profile, it goes through login, prompts for MFA and then after auth MS isn't seeing the device as managed and tries to get you to set it up, but it already is. Whatever browser components its launching aren't coming from inside of the work profile, so it doesn't recognize the device status.

I get that it's kind of an edge case, but I can't possibly the only person annoyed to crap by this. It used to work, then it just stopped. So my options are no VPN on the phone, or neuter the conditional access which isn't happening. Meraki really can't do much because its the client that's the problem, the request never hits the MX because it's being blocked by Azure.

It seems to be launch Chrome from outside of the work profile because I can see open tabs, so I've disabled Chrome on personal and work profiles no joy.  Installing chrome in the work profile doesn't do anything...it's a really stupid bug but it's Android so no one cares.  Apple devices have zero issues.

Any ideas?

[alemabrahao]

I think you need to open a support case with the Microsoft.

[PhilipDAth]

This is not really a Cisco Secure Client AnyConncet issue ...

To be able to get the DeviceID attribute (which is what conditional access requires to do a compliance check), an application has to know to call the Microsoft MSAL library to do the authentication.  Microsoft has not created a design where there is any other way to get that device ID.

The problem for Cisco Secure Client AnyConnect is there is no way that it can know to do this.  All it gets is a SAML URL to call.  It could be a SAML URL for any Idp, Cisco DUO, Okta, anyone.  It can't tell that "this" URL is specifically for AzureAD and needs a non-standard SAML setup to be done.

This is more of an architectural design restriction (I would call it an error) that Microsoft has made.

Other Idp platforms (like Cisco Duo) do not experience this issue.  They have used a mechanism that lets device trust/compliance be asserted from within a standard micro-browser, which is what Cisco Secure Client AnyCoinncet uses.

A good solution I use with a lot of clients is Cisco Duo on top of Azure AD, and you use Cisco Duo to apply all the compliance policies.  Note that if you use federation and have Active Directory you don't even need an Azure AD P1 licence - so it can actually work out cheaper!

Duo's Device Trust is also more flexible, in that you can assert trust for devices not in your Intune - such as for contractors.  Using Intune and compliance policies and then trying to allow devices from other managed AzureADs is hellish otherwise (bordering on impossible).

https://duo.com/product/device-trust

But back to Microsoft - I don't think they'll correct or fix this design error they have made.