Integrating Workspace ONE Access with Microsoft Office 365

In this blog, I’m going to walk through configuring Workspace ONE Access as the Primary IDP for Office 365.

We will walk through the process of federating your Azure domain with Workspace ONE Access and run through a few test cases.

I will NOT be covering :

  • Creating Users in Azure AD (ms-DS-ConsistencyGUID is used if using Azure AD Connect v11.5224 or later)
  • Active Flows with Basic Authentication

Syncing Users into Workspace ONE Access

Its strongly recommended you use the Workspace ONE Access Connector to synchronize your users. Although its possible to do this without the connector, you will need to ensure Immutable ID is populated in Workspace ONE Access in the correct format. This becomes especially challenging if you using the ms-DS-ConsistencyGUID.

Some special notes on the ms-DS-ConsitencyGUID:

You need to use the Workspace ONE Access Connector version 19.03.01 or 20.10.

In the Directory Mapping Attribute, you need to map “sourceAnchor” to ms-DS-ConsistencyGUID:

In connector 19.03.01, only the “sourceAnchor” attribute can be used to map the ms-DS-ConsistencyGUID. In the 20.10 connector, you can use any custom attribute to map the attribute.
Please Note: The sourceAnchor attribute is not visible using Postman to view all attributes.

Getting Started with Windows PowerShell

  1. Launch Windows PowerShell from your start menu
  2. If you don’t have the MSOnline module installed, you will need to install it
Install-Module -Name MSOnline
  1. Once you have MSOnline installed, then type the following to enter your Office 365 admin credentials and connect to Azure Active Directory:
  1. Enter your Azure AD admin credentials
  1. Once you are logged in, run the following command to view your Azure AD domains

You will see a summary of your domains including the current authentication setting. You might have some domains in a “Managed” state and some domains in a “Federated” state.

  1. In this example, I’m going to federate my domain.

Preparing our Set-MsolDomainAuthentication Command

Building your PowerShell Command

PowerShell VariableValue
DomainNameThis is your AAD Domain that you will be federating to Workspace ONE Access: i.e..
IssuerUriThe IssuerUri is a unique identifier that will be used to identify this federation agreement. i.e.
FederationBrandNameEnter your company name ie. “The Identity Guy”
When configuring multiple domains, enter the domain ID for the specific domains.
When configuring multiple domains, enter the domain ID for the specific domains.
When configuring multiple domains, enter the domain ID for the specific domains.
-SigningCertificateIn your browser, access your IDP metadata:
Copy your signing certificate from the Signing Section.

I recommend you getting your signing certificate this way to remove all the line breaks that you would have if you downloaded the signing certificate from the access console.

Running your PowerShell Command

  1. In your PowerShell window, run the “Set-msoldomainAuthentication” command by combining all the above values. Note: For illustration purposes, I’ve truncated my signing certificate below:
Set-MsolDomainAuthentication –DomainName –IssuerUri  –Authentication Federated -FederationBrandName "The Identity Guy" -PassiveLogOnUri -ActiveLogOnUri -LogOffUri -MetadataExchangeUri -SigningCertificate MIIFDTCCAvWgAwIBAgIHAIPiCczH9TANBgkqhkiG9w0BAQsFADA+MSAwHgYDVQQDDBdWTXdhcmUgSWRlbnRpdHkgTWFuYWdlcjENMAsGA1UECgwERFNBUzELMAkGA1UEBhMCVVMwHhcNMTkwMjA4MTkyMjQxWhcNMjkwMjA1MTkyMjQxWjA+MSAwHgYDVQQDDBdWTXdhcmUgSWRlbnRpdHkgTWFuYWdlcjENMAsGA1UECgwERFNBUzELMAkGA1UEBhMCVVMwggIiMA0GC
  1. After running the above command, if you run a “get-msoldomain”, you should see the domain is now “Federated”

Setting up Workspace ONE Access

  1. In the Workspace ONE Access console, go to Catalog -> Web Apps
  2. Click New
  3. Click “or browse from Catalog”
  4. In the Search Filter, enter “Office” and Select “Office365 with Provisioning”. You will need to use this app even though we will not be using the provisioning capabilities.
  1. Click Next on the Definition Screen
  1. The next step will be different depending on whether you are configuring a single O365 domain or multiple O365 domains

Single O365 Domain

  • Under Application Parameters, enter your O365 Domain and your Issuer URI that we used in the above PowerShell Command

Multiple O365 Domains

  • Expand Advanced Properties
  • Enter each domain name and the corresponding Issuer URI’s that would of been used in your PowerShell Commands
  1. Scroll down to Custom Attribute Mapping, make sure the correct value is used for the ImmutableID.

Your value might be ${user.sourceAnchor} depending on your environment.

  1. Click Next, Next, Save
  2. Assign the application to your users.

Testing out the Configuration

  1. Open a browser, and go to
  2. Enter your email address with the domain that is federated to Workspace ONE Access
  1. When redirected to Workspace ONE Access, complete your authentication.
  2. Upon return, you should be logged into Office 365


  1. You received the error “AADSTS5000813: The SAML 1.1 credential must provide non empty value for claim of type ‘’.”

This is the most common issue when integrating with Office 365. There are several things we need to look at:

Use a SAML Tracer to validate all the attributes are being sent from Workspace ONE Access to O365

I currently use the following SAML Tracer in Chrome

In my WS-FED/SAML Tracer, I can see the following Response:

In this case, my ImmutableID that is being sent is blank. This is extremely common. If this is your issue, verify the attribute that you are sending for the Immutable ID is correct.

  • ${user.sourceAnchor}
  • ${user.objectGUID}

Please pay special attention as this is Case-Sensitive so make sure it matches your directory sync settings. Also check your Directory Sync settings to verify this attribute is synchronized to Workspace ONE Access.

If you are using the sourceAnchor attribute, there is unfortunately no way look at the attribute in Workspace ONE Access. If you are using any other attribute, please see my blog on how to view all your Workspace ONE Attributes.

If you see an Immutable ID in your WS-FED/SAML Trace, verify that this matches the value in Azure AD by running the following PowerShell Command.

Get-MsolUser -UserPrincipalName | select ImmutableID

Some Helpful PowerShell Commands

Install MSOnline

Install-Module -Name MSOnline

Connect to AD Azure
Get Domain Details
Update ImmutableID for User
Set-MSOLuser -UserPrincipalName -ImmutableID h28aKnu0+UqfakeIDasdfI7w==
Show User Details:
Get-MsolUser -UserPrincipalName | Select-Object *
Show ImmutableID
Get-MsolUser -UserPrincipalName | select ImmutableID
Get Federation Settings:
Get-MsolDomainFederationSettings -DomainName
Disable a Domain for Federation
Set-MsolDomainAuthentication –DomainName  –Authentication Managed
Update a UPN for a User
Set-MsolUserPrincipalName -UserPrincipalName "" -NewUserPrincipalName ""
Create User
New-MsolUser -UserPrincipalName -DisplayName "MS User 2" -FirstName "MSUser2" -LastName "MSUser2" -Password "S#)K#Dasdf" -ForceChangePassword $false -ImmutableID /fbnEHGfakeidUGrSj1ISaw==
Change Password for User
Set-MsolUserPassword -UserPrincipalName "" -NewPassword "S#)K#Dasdf" -ForceChangePassword $false

28 thoughts on “Integrating Workspace ONE Access with Microsoft Office 365

  1. Have you find a way to pass the username from the Office 365 login prompt into the username field of the Workspace ONE Access login prompt so users don’t have to enter their username twice?


      1. For this case, yes, password authentication with Verify MFA.

        Certificate auth works fine on physical devices, but isn’t viable for within Horizon instant clones that I have found.

        Reading further through your blog, i see some indication that my disabling domain selection and selecting a default domain in Access might be messing with it.


  2. Hi Steven,

    we are testing WSO on Ios devices and we have tried to setup keys for Outlook (office 365) on WSO , account is discovered but it ask for user password

    here settings: {EmailAddress} ModernAuth
    IntuneMAMAllowedAccountsOnly Disabled
    IntuneMAMUPN {UserPrincipalName} {UserPrincipalName}

    I’ve enabled yet Mobile Single Sign-On settings on WSO , user account is discovered but always ask for pw (error code 50058 at the bottom of the page)

    Do you have any suggestion?

    thanks for help)


      1. Device is enrolled with active directory credentials.
        When I open outlook email address is correctly recognised, I press add account button and then office 365 ask me for pw.

        Thanks for help )


  3. I’m not close to notebook and I can’t check, but I think is correct. So should I convert domain into a federate one?

    Thanks for help


    1. If you want to use Workspace ONE to authenticate into O365, the domain should be federated as per my blog. If you don’t federate, you will use Azure AD authentication into O365.
      I hope that helps. Have a great weekend. !


  4. Hi Steve,
    Do you know if the domain would show as Federated if a customer is already setup ADFS? Also, in this case, if we need to federate to Access, what would be the roll back options?


      1. Thanks for the clarification. So if we need to federate to Access, then we need to make the domain as managed again and then do the federation?


      2. Not necessarily, there are multiple deployment options including using ADFS to route traffic to WS1. Obviously, federating directly is Access is an option as well I recommend you talk with your VMware account team or support to discuss.


  5. Ms-ds-consistencyguid used by AD Connect,
    Use the custom attribute Ms-ds-consistencyguid in access,
    Powershell has federated with O365, and is successfully authenticated by Access when logging into
    Pop-up error:
    AADSTS51004: The user account bnVsbA== does not exist in the *******-dd4b-477d-aec8-******** directory. To sign into this application, the account must be added to the directory.


  6. Hi Steve,

    This blog help a lot to achieve VIDM conditional access for user that try to login outlook via browser, it will redirect to VIDM. but i’m curious to know how i achieve same conditional access on mobile outlook. if i integrate office 365 with VIDM then all device(laptop, desktop and mobile outlook) authentication will go through VIDM. we just need to access VIDM on mobile outlook. how it i possible for only mobile outlook.


      1. Hi Steve,

        How can differentiate with mobile traffic only. user who wanted to access outlook from mobiles, those users only need to get VMware access policies.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s