*Attention* - Federating a on-premises domain with WorkspaceOne Access affects all of the domain users' authentication with Office365. It is highly recommended to perform this procedure using a test domain and test Office365 tenant first.
Federating Office 365 with Workspace One Access provides several benefits:
- Users can access their Office 365 applications directly from the Intelligent Hub catalog using Single Sign On (SSO)
- Conditional access policies can be created in Workspace One Access to validate whether a user can access their Office 365 applications or not based on device type, IP address range, whether the device is being managed by Workspace One UEM, whether the device is compromised etc..
- Besides providing single sign on capability with Browser access, with Workspace ONE UEM managing the devices mobile SSO policies can be used to provide SSO to the Office 365 native mobile apps in IOS and Android devices
Today's post illustrates how I federated my Office 365 domain with my Workspace One Access tenant.
Office 365 can be integrated with Workspace One Access when Office 365 is federated with the on-premises domain
These were the components required in order to set up this integration:
- A publicly registered domain
- A Workspace One Access tenant
- A Workspace One UEM tenant
- A Windows on-premises Active Directory domain already integrated with the WorkspaceOne Access tenant
- An Office 365 subscription
- A public CA issued certificate
Before starting with the actual integration I had to work on a fix for a situation with my on-premises active directory domain, which has a non-routable domain suffix, .local, and as such would not be able to connect to Azure. I had to add a routable suffix to my domain before proceeding. This Microsoft article explains how to accomplish this: Article
The next step was to federate my on-premises domain with Azure AD in order for my on-premises domain users to be entitled to O365 licenses. This step required the installation and configuration of Active Directory Federation Services (ADFS) in my on-premises domain. The ADFS endpoint requires a public issued CA certificate. I used letsencrypt.org to create the certificate for my domain but any public CA would work as well. I will publish a post later one with instructions on how to use letsencrypt.org to create certificated for lab scenarios.
ADFS is a Windows Server role that can be installed using Server Manager.
After installing the ADFS role I also added two powershell modules into the ADFS server:
- Install-Module -Name AzureAD
- Install-Module -Name MSOnline
Then I used the following powershell commands to ensure the modules were installed:
- Get-Module -ListAvailable |findstr MSOnline
- Get-Module -ListAvailable |findstr AzureAD
Before proceeding with the AzureAD configuration first I downloaded, installed and executed the Microsoft IDfix tool. This tool shows any possible synchronization issue with AzureAD. It is useful to run it and remediate the synchronization issues before configuring your AzureAD federation. The IDfix tool can be downloaded using the following link: Link
Once I executed the IDfix tool and fixed all possible synchronization issues with my on-premises domain user accounts I installed the AzureAD connect tool to synchronize my on-premises user accounts with AzureAD. The AzureAD connect tool can be downloaded using this link: Link
Once the Azure AD Connect tool is installed in the local ADFS server the tool will periodically synchronize the on-premises domain with AzureAD.
Once I finished setting up my Azure AD connect and federating my on-premises domain to AzureAD I went to my Azure portal and verified my on-premises domain status in Azure Active Directory \ Azure AD Connect and in Azure Active Directory \ Azure AD Connect \ Federation
At this point my lab on-premises domain was ready to be federated with my WorkspaceOne Access tenant. In order to do so I used this command on my ADFS server:
- set-MsolDomainDomainAuthentication
This command requires several attributes, some from the on-premises Active Directory domain and some from the WorkspaceOne Access tenant. This is how the command was customized for my lab:
- set-MsolDomainAuthentication –DomainName lvalente.com –Authentication Federated –IssuerUri td-valentel.vidmpreview.com -FederationBrandName lvalenteInc -PassiveLogOnUri https://td-valentel.vidmpreview.com/SAAS/API/1.0/POST/sso -LogOffUri https://login.microsoftonline.com/logout.srf -ActiveLogOnUri https://td-valentel.vidmpreview.com/SAAS/auth/wsfed/active/logon -MetadataExchangeUri https://td-valentel.vidmpreview.com/SAAS/auth/wsfed/services/mex -SigningCertificate <WS1 Access Tenant Certificate>
In order to issue the command I needed my WS1 Access Tenant certificate. I was able to retrieve this certificate my logging in my WS1 Access Admin Console. This certificate is located in Catalog \ Web Apps \ Settings \ SAML Metadata
Once I executed the above command successfully I used the following command to confirm my on-premises domain was now federated to my WorkspaceOne Access tenant:
- Connect-MsolService
- Get-MsolDomain
Next I had to confirm I was synching the necessary attributes required by for Office 365 SSO SAML assertion between my on-premises domain and my WorkspaceOne Access tenant. Reminding here that the pre-reqs listed at the beginning of this article included the integration between the on-premises AD domain and the WorkspaceOne Access tenant using the WorkspaceOne Access Connector was a pre-req for this exercise.
In order for the SAML communication between WorkspaceOne Access and Office 365 to succeed the following domain attributes are required to be mapped.
- ObjectGUID
- UserPrincipalName
I did not have the ObjectGUID attribute mapped in my WorkspaceOne Access initially. I added it in WorkspaceOne Access in Identity & Access Management \ Setup \ User Attributes
I then made sure the two attributes were correctly mapped to domain values in Identity & Access Management \ Manage \ Directories \ Sync Settings \ Mapped Attributes
I was getting close now. The last step before testing was to set up the O365 App in WorkspaceOne Access and entitle it to my users
I went into my WorkspaceOnce Access tenant admin console and selected Catalog \ Web Apps \ New and then clicked on or browse from catalog and finally typed Office365 to filter the list of available apps and picked Office365 Portal.
When setting up the App I had to make sure that:
- the tenant attribute was mapped to my on-premises AD domain routable suffix
- that the issuer attribute was mapped to my WorkspaceOne Access tenant URL
- that in Advanced Properties the UPN attribute was mapped to the variable ${user.userPrincipalName}
- and that the ImmutableID attribute was mapped to the variable ${user.objectGUID}
And that was that! At this point all I had to do was to test and make sure SSO was working properly while initiated either from the IDP - WorkspaceOne Access or from the SP - Office 365. This was the result:
Now that I have my Office 365 tenant properly federated to my WorkspaceOne Access tenant I can setup Authentication policies in WorkspaceOne Access to for example just authorize access to Office 365 from devices enrolled in WorkspaceOne UEM and I can set up compliance policies in WorkspaceOne UEM blocking access to Office 365 to devices that fail my compliance policies.
This document helped me tremendously with this integration: Article
Happy testing!
