Workspace One UEM 3rd party compliance integration – Microsoft Graph API

Update1: device demo section, Android Sharepoint and Onedrive app error.
Update2: iOS SSO extension for compliance in Safari
Update3: Android Sharepoint and Onedrive Beta App Support information as well as Salesforce configuration to use native browser and enables compliance in the app was added
Update4: Videos added showing Salesforce(iOS/Android), Gmail(Android) and Boxer(iOS) working
Update5: Public Preview scheduled and device compliance moved to endpoint.microsoft.com

It is now pretty much a year since VMware announced that it would work with Microsoft to build an integration to feed compliance information from Workspace ONE UEM (Unified Endpoint Management) into Azure AD Conditional Access. It is now in preview and can be tested and evaluated by customers through a Beta before entering a Tech Preview.

Why?

Azure AD (AAD) is the main user store for all of Microsoft cloud applications, prime example being Office 365. It is also commonly used to bring together separate on premise AD (Active Directory) into one unified directory from which customers federate and provision applications. To access any of those federated applications users need to authenticate first with their Azure AD user account. This authentication can either happen on Azure AD directly for “managed” accounts or with a federated IDP (Identity Provider) for “federated” accounts. There are some restrictions with Azure AD as primary IDP that you don’t see as much with the other IDP. There can be only 1 federation for a specific email domain and with that also no differentiation for different device types or fallback scenarios. (Think unmanaged device is trying mobile SSO, which fails and the primary IDP would use a fallback method like MFA). You can’t send information that the device is managed in the SAML assertion either as you can do with OKTA for example. But in some cases customers want to only allow managed devices for certain apps but free access for others.

Azure AD knows devices objects as either AAD registered or AAD joined and if set can use their compliance information during the authentication flow by setting up AAD Conditional Access (AAD CA) rules. Workspace One used this feature for OOBE(Out Of the Box Experience) AAD joined Windows 10 devices managed by WS1 UEM already. If you want more info on this integration let me know and I prepare another blog post. Further it was also possible through Hybrid AD join to integrate on premise AD joined devices with it. But for mobile devices this was only available for Intune managed devices.

With the new Partner Compliance management feature, it is now possible to transfer the compliance and management information of mobile devices to AAD through the use of a new Intune Graph API. It uses the Microsoft Authenticator app on the device to register an AAD device object and WS1 UEM uses the Intune Graph API to set the management and compliance status of said device. Presently it comes with the caveat that only Apps that use the MSAL library can leverage the Authenticator app to get the required token linking device record and authentication request. On Android you can add a certificate through Authenticator to allow the compliance check in browser or apps using Chrome Custom Tabs, that do not have the MSAL library included. On iOS there is no solution yet. On iOS you can leverage the SSO extension to enable the conditional access in Safari and apps using the SafarViewController during auth.
The feature will rollout in several phases and initially work for managed iOS and Android devices, with further improvements to include more use cases and platforms in the future. For more info on this best contact you account representatives for a roadmap session.
It sports a remediation page to inform users that they require management and device registration in AAD to access resources. Ideally you want to preregister already managed devices before activating AAD CA policies with the feature enforced and this post shows how you can set this up.

Very high level integration diagram

Requirements

Workspace One side
At the moment WS1 UEM Preview tenant (usually the environments CN135/CN137) for customers in private preview.

Update: Latest message from the PM team is that the public preview will start with the UEM 2008 release.

WS1 Intelligence needs to be enabled (for on premise WS1 intelligence /ETL connector needs to be installed) -> no license needed, but make sure you did the opt in under Monitor > Intelligence.

Intelligence Opt In

Azure AD side
non production tenant with flighted Partner compliance management (talk to your Microsoft contact and provide the Tenant ID and domain)
VMware mobile compliance app will be added with following permissions
• Microsoft Graph – DeviceManagementServiceConfig.Read
• Intune – manage_partner_compliance_policy
• Intune – update_device_attributes

Device side
Microsoft Authenticator app for registration and authentication broker
Workspace One Intelligent Hub application

Setup

These are some best practice steps to set up the preview so far. Through the preview process VMware and Microsoft hope for further input to further enhance the experience.

Integration

Update: Device Compliance was moved out of Azure portal itself and can now be found in https://endpoint.microsoft.com.

First check your flighted AAD tenant for the Partner Compliance feature and +Add Compliance partner, choose “VMware Workspace ONE mobile compliance”, choose the platform “iOS” or “Android” and the user group that should have their devices managed by WS ONE UEM.

On the UEM side navigate to All settings > System > Enterprise Integration > Directory Services > Enable “Use Azure AD for Compliance (Tech Preview)” this will trigger a callback to the service hosted on the Intelligence tenant to integrate with AAD.

Compliance setup in WS1 UEM

Sign into AAD and Accept adding the integration app. This will add the app with the mentioned permissions.

You will be redirected to UEM, finish the process and in AAD the compliance partner integration should have switched to Active.

AAD partner compliance finished setup

Devices

You need to make sure the Authenticator app is rolled out to all devices before activating the feature. You could then set up AAD CA policies and the next time the user would access a thus secured resource he would be redirected to the remediation page.

Compliance remediation page

The flow is not very intuitive and require many clicks and closing the app in question completely.

Better is to prepare the rollout by initially sending out a link to register the devices before activating any AAD CA policy. The solution at the moment are weblinks, but ideally one could use Hub notifications. At the moment hub notifications can’t include custom URI scheme to start apps but it is addressed with VMware already.

WS1 UEM setup weblinks

For iOS create a link:

airwatch://conditionalaccess?partner=microsoft

For Android create a link :

awagent://com.airwatch.androidagent?component=conditionalaccess&partnertype=microsoft

The Registration flow supported by Mobile SSO looks as follows for the iOS and Android. Instruct the users to register the device in rollout phase of the feature and later initially before accessing any Microsoft resources on newly enrolled resources with AAD CA already active.

Android demo compliance registration flow
iOS demo compliance registration flow

The devices will now show up under Devices in AAD. At the moment there is sometimes still a significant delay between the devices being added as managed and setting the compliance status. In production this should not be seen anymore.

In case you want to understand or troubleshoot the flow use the Audit logs. The full registration process adds 5 entries from Adding, to setting management to finally setting the compliance state for each device.

Conditional Access

Now lets set up the AAD CA policies to only allow access to Office 365 apps from managed devices. Set up the policy for iOS and Android and modern authentication apps to only allow compliant devices.

Access to Office 365 resources on the devices should happen without any interruption. The Authenticator app will broker the authentication for the apps.

Android demo MSAL apps flow
iOS demo MSAL apps flow

There are issues with Android Sharepoint and Onedrive at the moment not picking up DeviceID from Authenticator, so it will loop through enroll/registration process. Access to Onedrive inside the office apps works so. Access to Sharepoint can work as described further below.
Update3: with Onedrive version 6.9 beta 2 and Sharepoint version 3.22.0 June Beta the apps now work correctly with the Authenticator app.

Android Sharepoint/Onedrive error versions before 6.9 Beta2/3.22.0 June Beta

And browser?

What happens if you send out links to Sharepoint sites in mails? They will open up in Safari on iOS by default and any of the installed browsers on Android, besides Edge non include the MSAL libraries required. For Android you can install a certificate to enable browser access from the authenticator app.
Update2: On iOS 13+ you can leverage the SSO extensions to allow apps in Safari to leverage the token with Device ID from Authenticator. https://developer.apple.com/videos/play/tech-talks/301/
The SSO Extension for Authenticator is in public preview at the moment. https://docs.microsoft.com/en-us/azure/active-directory/develop/apple-sso-plugin
The setup in UEM is straight forward, just create a SSO extension profile with the values specified at the Microsoft documentation.

iOS SSO extension profile in UEM

Other then mentioned in the Microsoft documentation, don’t use sharedDeviceMode as apps like Teams or Onedrive do not support it yet and will fail to login.

DON’T set the sharedDeviceMode or set it to false

The behaviour in Safari is then as follows, Sharepoint opens in unrestricted mode even so the configuration described below is active and the Salesforce app is able to start as well while requiring a compliant device.

Apps in Safari with SSO extension

For the user this is completely transparent, but you can check in the console logs to see the AuthenticationSSOextension at work.

SSO extension at work

Whilst this works for Safari, native apps would need to include the MSAL to use the token.
Update3: I tested with the Salesforce app and could see the SSO extension doing its work, but the app failed to use the returned token and was falling back to Mobile SSO which failed because of the Azure AD conditional access policy. The Salesforce app can be configured to use a SafariViewController and that supports the SSO extension just fine then.
https://help.salesforce.com/articleView?id=domain_name_login_mobile_auth_methods.htm&type=5
The assumption is that any app using the SafariViewController can use the SSO extension and device ID as well. One example is our own Workspace One Boxer app.

Salesforce app with native auth and Boxer working with SSO extension

For iOS 12 or older you could only allow limited browser access for services like Sharepoint and Exchange Online that support session control and app enforced restrictions. https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-session#application-enforced-restrictions

On the example of Sharepoint you need to enable the Access Control settings under Policies for unmanaged devices. This will create 2 new AAD conditional access policies automatically. Be aware and change them accordingly right away.

Now change the existing Conditional access policy you created before.

And add or change the one created by Sharepoint with the following settings.

On iOS you now can see that access to Sharepoint works from Safari but you are not able to download files and some other restrictions. For comparison you can see how a managed browser like Edge has full access as it can deliver the compliance status of the device.

iOS demo browser based access Sharepoint

For Android you can improve on the experience by installing a certificate from the Authenticator app used by AAD to identify the device so it can check the compliance status. Go to Settings > Device registration > Enable browser access.

You can see in the demo that now Edge and Chrome behave similar with the main difference of the extra prompt in Chrome to pick the added certificate.

Android demo browser based access flow

Update3: Sadly this only works for browser based apps. Trying to use it inside Salesforce for example fails, it’s not prompting for the certificate and ends with the request to use it in another browser. It might be down to how Salesforce handles the webview for SAML authentication. So at least Salesforce can be configured to use a Chrome custom tab to allow it to use the browser access certificate. The assumption is that any application using chrome tabs will behave the same, but this needs to be verified. Another example of a working app is Gmail itself when configured for Exchange online. See the example below, Android is doing a good job saving the certificate preference and it will only prompt once (unless you keep adding certs from Authenticator where there seems no limit). So no prompt in the video(check it in the browser one) but you can see that it hits device.login.microsoftonline.com during auth.

Salesforce and Gmail auth with conditional access enabled using the browser access cert
Old error with Salesforce app and in app auth.

Conclusion

There is still room for improvement for the integration and new use cases to explore. If you take part in the preview, please share your experience and give feedback to VMware and Microsoft. Especially the access for non MSAL apps is a topic that needs to be addressed.

Written by

Technical tinkerer working for VMware as solutions architect in the customer success team for digital workspace topics. Been with VMware since 2015 through the acquisition of Airwatch.
Most of my time is spend on Workspace One Access configuration and integrations.

6 thoughts on “Workspace One UEM 3rd party compliance integration – Microsoft Graph API

  • Avatar
    Peter Meuser
    2020-05-12 at 15:02

    It’s really a shame, that this big partnership between Microsoft and VMware fails so short regarding the resulting solution that took more than a year to appear at least in beta. Supporting only MSAL on iOS and the unsatisfying user experience to enroll for compliance integration with Azure AD is just not enough for environments that are looking for “mobile first” and choose Azure AD as their central IAM solution not only for Office 365. Strong authentication combined with trusted (compliant) devices are the pillars of modern cloud security.

    A technical solution might be quite easy: If Microsoft would allow to upload CA certificates to validate third-party device certificates with the device id as subject by “device.login.microsoftonline.com”. This is not a new idea since another Microsoft product exactly allows this: CASB known as “Microsoft Cloud App Security” with its session control. So, come on Microsoft guys, give yourself a favor!

    • Sascha Warno
      Sascha Warno
      2020-05-12 at 18:34

      I think it’s a step in the right direction but there are scenarios and use cases that cannot be achieved. We have the same idea on solving those challenges. As you can see with the option to enable browser access on Android it is possible to link a certificate to the Device ID in AAD and check on it during the authentication process in a browser. But it is obviously not the way you would want to provide it on a managed device and so far it doesn’t work for all apps. After registering the device Workspace One UEM knows the Device ID and it would be easy enough to install a device certificate with the DeviceID as subject on the device. It would require to make the AAD tenant trust that certificate or better its issuing CA.

  • Avatar
    Sascha Milani
    2020-06-03 at 09:20

    Really nice article, Sascha. Well done and can’t agree more that there is “still room for improvement”.
    Microsoft just can’t expect any app developer to adopt/implement the MSAL – not mentioning that the app file size may increase or MSAL could be seen as a Trojan horse…

  • Avatar
    Peter Meuser
    2020-06-06 at 14:53

    Sascha, as always you have done some great research work on this rather complex topic. On the other side it‘s a shame to see how easy and user friendly AAD Conditional Access works with Intune.

  • Avatar
    Suresh Mudireddy
    2020-06-12 at 12:09

    Sascha,
    If a user want to get the his/her iOS device post CA policies active works as shown in the demo ?. If yes that CA policy will not block the attempt to authenticate and register the device saying the device must be compliant and must satisfy all other conditions defined in the applicable policies ?

    Thanks in advance for your reply.

    • Sascha Warno
      Sascha Warno
      2020-07-03 at 12:34

      The compliance is not set for the registration process. This would be a different “app” in AAD. At the moment compliance is only required for everything Office 365 and Salesforce in my environment.

Leave a Reply

Your email address will not be published. Required fields are marked *.

*
*
You may use these <abbr title="HyperText Markup Language">HTML</abbr> tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Theme BCF By aThemeArt - Proudly powered by WordPress .
BACK TO TOP