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

• By -Sascha Warno

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

• Posted on 2020-05-12
• Posted in Android, iOS, Workspace ONE UEM

Note : This blog post is not very recent and is kept for archiving reasons.
For the most up to date info on the partner compliance integration with Azure AD go to Techzone https://techzone.vmware.com/resource/compliance-integration-ms-office-365-using-graph-apis and also check out other possible compliance integrations to Azure AD with Tunnel https://techzone.vmware.com/resource/compliance-integration-ms-office-365-using-workspace-one-tunnel or Access https://techzone.vmware.com/resource/compliance-integration-ms-office-365-using-workspace-one-access

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
Update6: GA for Microsoft and in WS1 UEM 2010

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. The product went GA with Workspace One UEM 2010 in the cloud and with the upcoming release 2011 On Premise.

https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/services/Directory_Service_Integration/GUID-800FB831-AA66-4094-8F5A-FA5899A3C70C.html

Microsoft went GA on October 8th 2020.

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.

Requirements

Workspace One side
UEM console version 2010 in the cloud and 2011 OnPremise.

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.

Azure AD side
Partner compliance management configured in endpoint management portal.
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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

For the user this is completely transparent, but you can check in the console logs to see the AuthenticationSSOextension 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.

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.

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.

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.

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.