Office 365 SSO with External Identity Provider

Updated 2 years ago by admin

It is not currently possible to place a third party service, such as the IDaaS broker, in between Azure AD and Office 365 apps, if Azure AD is also managing the domain. Please read this Product Notice for further information.
Following this guide will require you to federate your domain with a third party Identity Provider, e.g. the IDaaS product.
This article requires Azure AD administrator privileges and access to PowerShell.

This article describes how to federate your Azure Active Directory custom domain to use the IDaaS product as its Identity Provider.

In this article, we will use the domain mxclear.com which has an Azure tenant name of mxclearcom.onmicrosoft.com. For the IDaaS product, the vanity domain acmetesting.dev.clouduss.com will be used. Replace these values with your own. The custom domain will be federated to use JumpCloud as its Identity Provider instead of Azure AD. See Configuring JumpCloud as an Identity Provider. At this point, Azure AD is a directory for Office apps however the source of authentication is set to JumpCloud.

This guide can be followed for alternative Identity Providers too by replacing the JumpCloud specific steps with those of the alternative Identity Provider.

Before you begin, make sure that you have a Global Administrator user on the non-federated domain i.e. mxclearcom.onmicrosoft.com and you can log in successfully as a full administrator via the Azure Portal. Failure to do this could prevent access to your Azure tenant should the configuration be applied incorrectly.
  1. Make sure you have read and understood the warning panel above
  2. Open PowerShell with Administrator privileges
  3. If you have not already done so, install the MsOnline cmdlet with: Install-Module MsOnline
  4. Type Connect-MsolService and sign-in to your Azure tenant as an administrator
  5. Next, in Azure AD, check that the custom domain is not the primary domain. You cannot federate a domain if it is already in use. Navigate to Azure Active Directory -> Custom domain names and check that the onmicrosoft.com tenant is the Primary. If not, set it to be the primary domain
  6. Ensure that you have an Identity Provider configured other than Azure AD, such as JumpCloud
  7. Navigate to App Launcher -> Add Apps within the IDaaS product
  8. Select the Office 365 app tile for the app you are adding, such as Outlook. If you do not see a tile that matches the desired Office 365 App, select the Office 365 App (Generic) tile and change the Application Name to the name of the app you are setting up
  9. Select an existing category or create a new category by using the Manage option. The app tile will appear in this category for IDaaS users.
  10. Refer to the table below and set the corresponding Application URL for the app you are configuring

App Name

Application URL

Office 365 Admin

https://admin.microsoft.com/

Outlook Web Access

https://outlook.office.com/

SharePoint

https://<your-domain>.-my.sharepoint.com

Office e.g. Word, PowerPoint

https://www.office.com

  1. Select an Identity Provider other than Microsoft Azure e.g. JumpCloud
  2. Click Next
  3. Click Download Certificate and then open the resulting .pem file in a text editor. Copy all of the text between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tags, and remove the line breaks. You can use an online tool (external link) and paste the text into input and then copy the output to the clipboard and paste it in to your text editor for use in the next step
  4. Return to the PowerShell prompt and set up some variables to use for the configuration
$dom="mxclear.com"
$BrandName="SAML 2.0 IdP"
$LogOnUrl="https://acmetesting.dev.beyondsso.com/idp/saml/sso"
$MyURI="https://acmetesting.dev.beyondsso.com/idp/saml/metadata"
$Protocol="SAMLP"
$MySigningCert="<INSERT ONE LINE CERTIFICATE>"

Be sure to replace mxclear.com with your custom domain name to federate and acmetesting.dev.beyondsso.com with your IDaaS vanity domain, leaving the path in place. Ensure the certificate is pasted in without any line breaks as described in the previous step. Your terminal should look similar to this:

  1. Now execute the command to federate the domain using the variables you have set:
Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $BrandName -Authentication Federated -IssuerUri $MyURI -PassiveLogOnUri $LogOnUrl -LogOffUri $MyURI -PreferredAuthenticationProtocol $Protocol -MetadataExchangeUri $MyURI -SigningCertificate $MySigningCert
At the time of writing, the IDaaS product does not currently implement a logoff URL however it is given in the above command as it is a mandatory requirement. This feature will be implemented in the future.
  1. In the Azure portal, you should see the federated tick is added to your custom domain. This may take several minutes to appear
  2. Return to the IDaaS configuration screen to complete the Add Application wizard. Click Next and then click Paste Metadata XML. Paste in the following XML:
<EntityDescriptor entityID="urn:federation:MicrosoftOnline"
	xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
	<SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
		<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
		<AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"            Location="https://login.microsoftonline.com/login.srf" />
	</SPSSODescriptor>
</EntityDescriptor>
Important: if you plan to add multiple Office 365 app tiles, the first app that uses the entityID urn:federation:MicrosoftOnline will determine the Identity Provider that all subsequent Office 365 related app tiles will use if more are added at the end of this guide. Put simply, it is not possible to split Office 365 Apps access across multiple Identity Providers.
  1. Microsoft requires IDPEmail and NameID attributes (external) to be provided. The IDaaS product will attempt to add the IDPEmail attribute automatically, however the NameID attribute needs to map to the ImmutableID of the user that is authenticating. On the Identity Provider side, we need to create a custom attribute to store the ImmutableID of the Azure user.

If you are using JumpCloud, you can find the corresponding Office (Azure AD) user within the JumpCloud users list and under Details add a new attribute, e.g. azureid with a value of the Azure AD user's ImmutableID.

By default, users created in the cloud without AD Connect sync from On-Premise will not have an immutable ID set.

To check if a user has an ImmutableID, return to the PowerShell screen:

Get-MsolUser -UserPrincipalName <upn> | select ImmutableID

e.g. Get-MsolUser -UserPrincipalName tim@mxclear.com | select ImmutableID

If the ImmutableID is blank, you can set it otherwise you can skip the next command. To set the ImmutableID to be the same as the UPN of the user, use this command:

Set-MsolUser -UserPrincipalName <upn> -ImmutableId <upn>

e.g. Set-MsolUser -UserPrincipalName tim@mxclear.com -ImmutableId tim@mxclear.com

Finally, in the JumpCloud user details panel, ensure the chosen attribute name has the ImmutableID value you obtained or created for the user.

  1. Still within JumpCloud, click the SSO menu option and select the Identity Provider connection that you set up previously. Navigate to the SSO tab and scroll down to the SAMLSubject NameID Format select box and change this to urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
  2. Scroll further down to the Attributes section. Add a new attribute to assert that azureid should be provided if the service provider requires it. Map this to the newly created azureid attribute.
  3. Return to the IDaaS configuration screen. Test the authentication by clicking the newly created Outlook tile and when prompted sign in with your identity provider credentials

Additional Office 365 App tiles

Once a user has authenticated with the Office 365 app that has been configured they can switch between Office Apps using the selector menu.

However, it is also possible to add additional Office 365 app tiles to the Applications list if required.

To add another app, such as SharePoint, repeat the same steps 7-12 and step 17 taking care to use a unique EntityID in step 17, e.g. entityID="sharepoint". It doesn't matter what the entity ID is at this stage as all apps will share the original urn:federation:MicrosoftOnline. Failing to do this will generate an error that an application already exists with the given metadata.

Further reading

How did we do?