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
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.
Microsoft went GA on October 8th 2020.
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.
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
Microsoft Authenticator app for registration and authentication broker
Workspace One Intelligent Hub application
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.
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.
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:
For Android create a link :
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.
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.
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.
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.
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.
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.
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.
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.
19 thoughts on “Workspace One UEM 3rd party compliance integration – Microsoft Graph API”
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!
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.
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…
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.
How does Intune solve this issue when the device is iOS managed by Intune, and you trigger an native iOS App authentication (e.g. Salesforce afaik) that has not the Microsoft MSAL/SDK integrated?
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.
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.
“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”
I would be very interested in that blog post.
On my azure portal if I select “Device compliance” I got the message that Microsoft Intune has moved!
Our new home is the Microsoft Endpoint Manager admin center. (https://endpoint.microsoft.com).
There’s no option to Add Compliance partner. is it the article updated ?
Sorry nobody moderated the Comment section for a while. I updated the section at some point, hope you found the new configuration page under the endpoint management tenant settings.
It looks like Airwatch and Microsoft are not on the same page and Microsoft released the feature in public preview but airwatch hasn’t released it to all customers. Very frustrating as I need this feature right now. Do you have any I formation on the airwatch rollout? Do you have any contacts that might be able to speak to why it isn’t available in all SaaS tenants?
Are there any news about the topics? Almost 4 months later it just seems to be a “tech preview” – meaning NOT available!
Official version 18.104.22.168 (2008) still says “Use compliance data in Azure conditional access policies (Tech Preview)”, but with Version 22.214.171.124 (2010) on cn137 the addition “Tech Preview” is gone. Please can you ask the PM about new release plans?
2010 is the GA for WS1 UEM and Microsoft released the feature with the O365 CA feature October 8th.
Great post …. Can not find information about if boxer and web from vmware supports this function. I have done the setup and my CA works fine, but only on Microsoft applications, and safari. I have tried to create an SSO Extension in WorkspaceOne, can make safari work but unfortunately not Boxer and WEB from Vmware. My latest SSO Extension:
AppAlowList com.air-watch.secure.browser, com.air-watch.boxer browser_sso_interaction_enabled 0 disable_explicit_app_prompt 1
Do you have any information here ?
Greate Guide …. Work fine with Microsoft app, Safari and vmware boxer. Can not get vmware web (browser) to work, any information about that ?
Had it working with Boxer. Need to test it with Web. What are your SSO extension settings?
Very thankful for this guide, mentions alot that I’ve been unable to find in other documentation. We’ve been able to set-up very satisfying scenarios for iOS and Android but we did have to make some automation on our own using Workspace1 and Graph API. One reason for this beeing migration, installation and reinstallation scenarios. Having applications and settings pushed based on if compliance status (Azure registration) has been done thru the links mentioned in the article required us to set tags in WS1 based on status in Azure and remove tags/devices based on changes in WS1.
Use this for mac: wsonehub://conditionalaccess?partner=microsoft