In this third part of the video series on leveraging Workspace ONE conditional with
Office 365 we are done with the preparations for Seamless Sign-On and will now federate
Office 365 with Workspace ONE Access.
We have a look at the compliance rules and setup the integration inside of Workspace
ONE Intelligence with Azure AD to revoke Refresh tokens for users with non-compliant devices.
The setup inside of Access starts by adding the Office365 application.
You can configure it to work on tenants with multiple domains and you need to make sure
the ImmutableID attribute which is used to identify the user is synced correctly from
your identity source be it an on-premises AD or other identity sources like Okta.
If you also plan to do OOBE enrollment or want to avoid MFA prompts which Azure AD requires
for certain actions like setting up Hello for Business which require a more secure level
of authentication, you can add another attribute as well.
Specify the authnmethodsreferences attribute which informs Azure that either MFA or other
forms of authentications were used.
We also specify an access policy that decides which methods to use for the specific device
types when authenticating for Office 365.
We set up our seamless sign on method for each device type based on their user agent,
like Mobile SSO for iOS and require a compliance check as second factor.
Again, if you plan to do OOBE enrollment you can specify the Windows 10 enrollment device
type and as those devices just enroll, they are not configured yet with seamless sign-on
so you need to specify another authentication method and second factor, like username/password
and Hub Verify for MFA.
On the Microsoft side we need to setup the federation, which is usually done using PowerShell
connecting to the msolservice and configuring it with the IdP settings for your Access tenant,
like the active and passive endpoints as well as the signing certificate which needs to
be an unformatted string without any line breaks.
The integration is done per email domain and will affect all users with that domain configured,
there is no way to target a subset other than changing the UPN for them in Azure.
The link to the integration guide as well as a commented sample script are in the article.
The rules for compliance are set in UEM by specifying compliance rules which run based
on the information received from the devices and across attributes like the application
list, compromised state or encryption depending on the platform.
The device will be marked as non-compliant and certain actions will be triggered directly
by UEM.
All that information is also available in Intelligence so, and allows us to build dashboard,
reports, and automations around it.
In our case we want to build a Workflow Connector with Azure to revoke refresh token.
On the Azure side we need to do an App registration to create an endpoint that Intelligence can
communicate with.
We set and approve the required Graph API permissions and create the Client secrets
to request OAuth tokens from the Intelligence side.
To let the custom connector in Intelligence, know which actions it can do we need to create
a Postman collection with the request for revokeSignInSessions with a Path parameter
so Intelligence can later use the affected users UPN which we then export.
From there we go through the setup of the custom connector in Intelligence with the
initial step setting up the authentication for OAuth, specifying the graph.windows.com
endpoint, the correct token request path for the tenant and scope for the token received
and then import the postman collection.
Now we can use that action inside a new Automation we set up whenever a devices status changes
to noncompliant and inform the user as well as run the action.
With that we have all the configurations in place and check out how it looks like on devices
next.