Integrate Microsoft Office 365

You must configure Microsoft Office 365 for Identity as a Service before configuring mobile Microsoft Office 365 applications for single sign-on.

Note: The user attributes received through Active Directory (AD) synchronization are retrieved as strings. If an attribute comes in as a byte array, it is base64 encoded before being used as part of the SAML response.

Note: When integrated with Identity as a Service, Microsoft Office 365 accounts are configured for single logout (SLO). Logging out of Office 365 automatically logs the user out of Identity as a Service. The user is not logged out of other SAML application accounts by logging out of Microsoft Office 365 and logging out of an Identity as a Service account does not log the user out their Microsoft Office 365 account.

Note: This guide was tested using previous versions of Identity as a Service and Microsoft Office 365. Other versions of Microsoft Office 365 may require integration and configuration steps that differ from those documented in this procedure. For newer versions of Microsoft Office 365, this integration guide may be used as an initial approach for integrating Microsoft Office 365. In the event of other issues, contact support@entrust.com for assistance.

To integrate Microsoft Office 365 with Identity as a Service, you must do the following:

Step 1: Complete the following prerequisites

Create custom user attributes in Identity as a Service

You need to create custom user attributes to fully integrate Microsoft Office 365 with Identity as a Service.

Repeat this procedure to create the following user attributes:

● ImmutableID (for example name it, O365 Immutable ID)

1. Log in to your Identity as a Service account.

2. Click > Members > Attributes. The User Attributes List page appears.

3. Under Custom User Attributes, click . The Add User Attribute dialog box appears.

4. Enter a User Attribute Name for the custom user attribute. For example, O365 ImmutableID.

5. Optional: Check Required to make the user attribute mandatory.

6. Click Add to create the attribute. The attribute now appears in the list of Custom User Attributes.

If you want to connect Microsoft Office 365 with Identity as a Service AD sync, map your Immutable ID attribute to the ObjectGUID attribute within your Identity as a Service Active Directory configuration or the onPremisesImmutableId attribute within your Identity as a Service Entra ID Directory configuration. Mapping the Immutable ID attribute to the ObjectGUID (for Active Directory) or onPremisesImmutableId (for Entra ID Directory) allows the Immutable ID attribute in each user account to be auto-populated with the value located in your directory. See Map ImmutableID attribute to a directory attribute for more information.

● Confirm that your Office 365 account supports single sign-on (SSO) and Federation by reviewing Microsoft's Plan Comparisons.

Step 2: Prepare Microsoft Office 365 for configuration

Prepare Microsoft Office 365 for configuration

1. Install PowerShell. You must use Powershell to setup and federate the Office 365 domain with Identity as a Service. See https://learn.microsoft.com/en-us/powershell/entra-powershell/installation for installation instructions.

2. Install Microsoft Graph Module and confirm modules are installed:

a. Install-Module Microsoft.Graph

b. Get-InstalledModule

3. Connect to MS Graph using Powershell. In Powershell, enter this command and follow the prompts to authenticate as an Administrator:

Connect-MgGraph -Scopes "User.ReadWrite.All", "Domain.ReadWrite.All", "Directory.ReadWrite.All", "Directory.AccessAsUser.All”,”LicenseAssignment.ReadWrite.All” -UseDeviceAuthentication

Note: Use a web browser to complete device authenticate using the supplied URL and code.

4. Log in to your Office 365 admin account.

5. Click Admin. The Admin Center appears.

6. Go to Setup > Get your custom domain setup > Manage.

7. If you do not have a domain, add a domain to federate through Office 365. See Add a domain to Microsoft 365.

8. If the domain you want to federate is set to default, you must federate another domain.

9. Note the domain name as you will need to provide it later in this procedure.

Step 3: Add Microsoft Office 365 to Identity as a Service

Add Microsoft Office 365 as an application to Identity as a Service

1. Log into your Identity as a Service administrator account.

2. Click > Security > Applications. The Applications Lists page appears.

3. Click Add. The Select an Application Template page appears.

4. Under SAML Cloud Integrations, click Microsoft Office 365. The Add Microsoft Office 365 page appears.

5. Enter an Application Name.

6. Enter an Application Description.

7. Optional. Add a custom application logo.

a. Click next to Application Logo. The Upload Logo dialog box appears.

b. Click to select an image file to upload.

c. Browse to select your file and click Open. The Upload Logo dialog box reappears showing your selected image.

d. If required, resize your image.

e. Click OK.

8. Select the Authentication Flow that appears to users during login.

9. Click Next. The General page appears.

10. If available, use the Upload Metadata XML file option to auto-populate the following fields, if available in the file:

● Default Assertion Consumer Service URL

● Alternative Assertion Consumer URLs

● Service Provider Entity ID (Issuer)

● Single Logout Service URL

● SAML Signing Certificate

● SAML NameID Encoding Format

● SAML Signature Algorithm

11. To import the Metadata file:

a. Click and browse to select the file. The Metadata Configuration dialog box appears.

b. If required, click Merge with existing values to merge new values with existing values for Alternative Assertion Consumer Services URLs and SAML attribute names.

c. Click Save.

12. If you do not have a metadata file, use the information provided in the next steps to populate the fields.

a. Enter the Default Assertion Consumer Service URL for your application.

https://login.microsoftonline.com/login.srf

b. Enter the Service Provider Entity ID (Issuer) that is used by Identity as a Service to identify your application.

urn:federation:MicrosoftOnline

c. Enter the Single Logout Service URL for your application.

https://login.microsoftonline.com/login.srf

d. From the SAML Name ID Attribute drop-down list, select the user attribute Identity as a Service attribute that represents the Immutable ID (for example, O365 ImmutableID). You created this attribute in Step 1: Prerequisites.

13. Optional. Enter the SAML Username Parameter Name as Username to identify the userID being requested for authentication.

14. Enter the SAML Session Timeout to the time when the SAML Assertion times out. The maximum is 720 minutes.

15. Enter the Max Authentication Age (seconds) to set the maximum amount of time that can elapse before a user is required to reauthenticate during a new login attempt. This applies for both SP-initiated and IDP-initiated login. Set this field to -1 to disable this feature.

16. Optional: Select Sign complete SAML response to ensure the message integrity of the SAML response sent to the application during authentication.

17. Deselect Enable Go Back Button if you do not want users to be able to go back to the Microsoft Office login page to log in.

18. Select Show Default Assertion Consumer URL Service in the My Profile. When selected, the Default Assertion Consumer URL appears in a user's My Profile page in addition to relay states and Alternative Assertion Consumer URLs.

19. Optional: Add additional SAML Domains, as follows:

a. Click Add. The Add SAML Domain dialog box appears.

b. Enter the SAML Domain.

c. Click OK.

d. Repeat these steps to add additional domains.

Note: If you have multiple domains in Office 365 that will be federated, add a domain entry for each one. If you only have a single domain,it is not necessary to add a domain.

20. Optional: Select Enable Active Sync to allow users to access other desktop and mobile Microsoft Office 365 applications through Identity as a Service authentication.

The Active Logon URI field appears. This is a security feature that supports Active Sync authentication. If you are configuring multiple domains, a different Active Login URI must be used for each respective domain.

21. If you are using Active Sync, click to copy the Active Logon URIs because it is only visible when configuring the Microsoft Office 365 application. You need to paste the Active Logon URI value as part of the final PowerShell command in Step 7: Configure Microsoft Office 365 for Identity as a Service Using PowerShell.

Note: You can regenerate a new Account Logon URI value by clicking . If you regenerate the value then you must also reconfigure the O365 account using PowerShell to include the newly-generated partner secret.

If you are using multiple domains, then the value must be updated for each domain that has been updated with a new partner secret.

22. Optional. Add Alternative Assertion Consumer Service URLs, as follows:

a. Click Add.

b. Enter a Name.

c. Enter a URL Value.

d. Select Show in My Profile to display the Alternative Consumer Service URL in a user's My profile page.

e. Optional. Add an Application Logo.

f. Click Add.

g. Repeat these steps to add more Alternative Assertion Consumer Service URLs.

23. Optional. Add a Relay State as follows:

a. Under Relay State, click Add. The Add Relay State dialog box appears.

b. Enter a Name for the relay state.

c. Enter the Value for the relay state. This setting specifies the application or URL that is a user is redirected to after successful authentication.

d. Select Show in My Profile to display the relay state on the user's My Profile page.

Notes: After you add relay states, you can also enable or disable them on the Add/Edit application page. Click next to the relay state to disable it or click to re-enable it.

Relay states apply to the Default Assertion Consumer Service URLs and not the Alternative Assertion Consumers URLs.

e. Optional. Add a Relay State custom logo.

f. Click Add.

g. Repeat these steps to add more Relay States.

24. From the Microsoft Office 365 SAML2 Attribute Value drop-down list, select User Principal Name. You will enter the User Principal Name as the attribute value in Step 6: Prepare users for Microsoft Office 365.

Note: An Identity as a Service account that is synchronized with a corporate directory containing User Principal Name values, auto-populates the User Principal Name in the user profile information when directory synchronization occurs. This value is stored in the user’s User Principal Name system attribute. See Trigger on-demand synchronization to trigger an immediate directory synchronization.

If the User Principal Name is not populated by directory synchronization, you must populate the user’s User Principal Name system attribute manually for every user integrated with Microsoft Office 365.

25. Click Submit.

Step 4: Create a resource rule to protect access to Microsoft Office 365

Create a resource rule to protect access to a SAML application

1. Log in to your Identity as a Service administrator account.

2. Click > Security > Resource Rules. The Resource Rules List page appears.

3. Click + next to the application you want to protect with a resource rule. The Add Resource Rules page appears.

4. Enter a Rule Name and Rule Description for the resource rule.

5. In the Groups list, select the group or groups of users restricted by the resource rule.

These are the groups to which the resource rule applies. If you do not select any groups, by default the resource rule applies to all groups.

6. Click Next. The Authentication Conditions Settings page appears.

7. Optional: Select Disable Single Sign-On for Application to force a user to re-authenticate whenever they attempt a new login.

8. If you do not Enable Advanced Risk Factors, do the following:

a. Select the Authentication Flow from the drop-down list. The Authentication Flow flowchart updates based on the selection.

b. Click Submit to save the Resource Rule.

9. If you want to Enable Advanced Risk Factors, complete the remaining steps in this procedure.

10. Select Enable Advanced Risk Factors to add additional risk factors to the resource rule.

11. Select Enable Strict Access for Application to set the resource rule to deny access regardless of the outcome from other resource rules. If this option is disabled for any resource rule that denies access, the user is allowed access if at least one resource rule allows access.

12. For each Advanced Risk Factor, click the Deny option to deny access to the application if the risk factor fails regardless of the results of the other risk factors.

13. Click Date/Time to set the conditions as follows:

a. Select one of the following:

– Allow Date/Time to set when a user can access the application.

– Deny Date/Time to set when the user cannot access the application.

The Date/Time Context Condition Settings appear.

b. Select the Condition Type:

– Specific Date Range Condition—Allows or denies access to the application during a select period of days.

– Time-of-day and/or Day of Week Recurring Conditions—Allows or denies access to the application on a specific time of day, day of the week, or both. Recurring times selected only apply to days not denied.

– Clear Selection—Clears existing Date and Time conditions.

c. Set the Condition Type settings, as follows:

i) Select Use local time zone to use the local time zone or deselect Use local time zone to use the local time zone and begin typing the time zone in the Begin Typing Timezone name field and select the time zone from the drop-down list.

ii) If you selected Specific Date Range Condition, click Start Date to select a start date from the pop-up calendar. Optionally, select the End Date.

iii) If you selected Time-of-Day and/or Day-of-Week, click Start Time and select the start time from the pop-up clock. Optionally set the End Time. You must also select the days of the week for the condition.

d. Click Save to return to the Authentication Conditions Settings page.

14. Click Geolocation to set the Location Condition Settings, as follows:

a. Select Allow or Deny to create an allowed or denied country list.

b. From the Selected Countries drop-down list, select the countries to add or deny access to the application. Repeat until you have added all the desired countries to the list.

c. Select Allow Anonymous IP Address to increase the risk of users authenticating from an anonymous IP.

d. Click Save to save to return to the Authentication Conditions Settings page.

15. Click Source IP Address. The IP Address Risk Setting dialog box appears. Do one of the following:

a. Select Custom and add the required IP Allowed Addresses and IP Denied Addresses.

b. Select IP List Address and select the IP List to allow or deny.

c. Select None to not restrict any IP addresses.

d. Click OK to return to the Authentication Conditions Settings.

16. Click Machine Authentication to set the Machine Authentication Condition Settings, as follows:

a. Set the Machine Authentication Risk is less than or equal to the value that the machine authenticator's total risk score must be less than during authentication to pass this condition.

The risk score is based on the attribute differences between a user's Machine Authentication information and that recorded on Identity as a Service before the condition fails. If an attribute does not match, the attribute incurs the number of risk points shown in Non-Matching Risk Points for that attribute. The Non-Matching Risk Points values of each non-matching attribute are added together, resulting in a total risk score. This score is normalized to be out of 100 as follows:

Total Risk Score = (Total Risk Points of Failing Attributes / Maximum Risk Points of All Enabled Attributes) * 100

The resource rule condition fails when the number of non-matching risk points exceeds the Machine Authentication Risk value defined in this step. A value of 0 means that a single attribute difference causes the Device Fingerprint condition to fail. The default value is 3. The value between 0-50 can be entered.

The default value is defined by the Machine Risk Limit. See Modify machine authenticator settings.

b. Click Save.

17. Define the Location History / Known Locations and Travel Velocity conditions. The Risk-Based Authentication (RBA) settings of your Identity as a Service account define the location history and travel velocity conditions. See Manage risk-based authentication settings for more information.

18. Set the Device Certificates risk factor to require the client to perform client-authenticated SSL with a certificate issued from a trusted CA to pass.

19. Set the risk score for application conditions to set the risk percentage a user receives if they fail to meet the condition, as follows:

● Click the dot next to the condition setting and slide the risk scale to the risk percentage

-or-

● Click the 0% and enter the risk points and then click OK.

The default setting is 0%. The Risk percentage determines the authentication requirements as set by the Authentication Decision. When a user attempts to authenticate to an application, the final risk percentage is the sum of all failed conditions.

20. Set the Authentication Decision risk level for Medium Risk and High Risk as follows:

a. Click the risk threshold percentage to the right of Medium Risk or High Risk. The Risk Threshold dialog box appears.

b. Enter the risk percentage.

c. Click OK.

21. Select the Authentication Flows for Low Risk, Medium Risk, and High Risk from the drop-down lists. The Authentication Flows flowchart updates based on your selections.

22. Click Submit to create the resource rule.

Step 5: Download the Metadata file from Identity as a Service

Download the Metadata file from Identity as a Service

1. In Identity as a Service, click > Security > Applications. The Applications List page appears.

2. Do one of the following:

● Click next to the application you are integrating with Identity as a Service.

–or–

● Click next to the application you are integrating with Identity as a Service and select SAML IDP Metadata.

The SAML Application Metadata dialog box appears.

3. Select the certificate to include in the SAML IDP Metadata file from the drop-down list.

4. If applicable, Select the domain to include in the SAML IDP Metadata file from the drop-down list.

5. Enter the Lifetime, in days, for the SAML IDP Metadata file. The value must be between 2 and 730.

6. Do one of the following, as required:

a. Copy the Public Endpoint to paste into your SAML application being used Identity Provider authentication.

b. Click Download.

Note: If you are using multiple domains, you must download each domain's metadata file separately because the values in the metadata file vary for each domain.

Step 6: Prepare users for Microsoft Office 365 access

Add users for Microsoft Office 365 access

This procedure describes how to add user accounts on Microsoft Office 365 and Identity as a Service so that single sign-on (SSO) attempts from Microsoft Office 365 to Identity as a Service are successful. You can add users as follows:

● Add users one at a time

● Add users through external directory synchronization

● Add users using PowerShell

Attention: To simplify configuring Active Sync on a mobile device, when creating new users, ensure that the user name is the same as the Identity as a Service User ID. For example, if the User ID in Identity as a Service is agrey assign the user name agrey@mycompany.com to the new user in Microsoft Office 365.

1. Create users for Microsoft Office 365 using one of the following methods.

a. Create users one at a time.

To add users individually to your Microsoft Office 365 account, see Add users and assign licenses at the same time for instructions.

b. Create users using external Directory Synchronization.

If you are using external Directory Synchronization tools such as AD Connect to create users in Microsoft Office 365, the user’s on-premise directory objectGUID is synchronized as the Microsoft Office 365 ImmutableID and then skip to Step 3.

Note: In cases where your user moves directory forests, the ObjectID will change but the ImmutableID will not. In such cases, you need to manually modify the ImmutableID as described in Reconnecting Cloud Users with Old/Previous/Moved AD User Objects.

c. Create users using Powershell.

There are two ways to create users in PowerShell: manually (one-by-one) or bulk importing user profiles using a CSV file.

Manually creating users in PowerShell

To create a user using PowerShell, connect to Microsoft Graft and enter the following command to get the license information:

Get-MgSubscribedSku | Select SkuPartNumber, SkuId

Once identified, enter the following to create a new user:

PasswordProfile = @{Password = ‘<initial password'}
New-MgUser -DisplayName "<Name>" -GivenName "<First name>" -SurName "<LastName>" -UserPrincipalName <name>@<domain> -OnPremisesImmutableID <character string> -MailNickname “<Mail Nickname>” -UsageLocation <Location initials> -AccountEnabled -PasswordProfile $PasswordProfile

You can enter any value for <character string>.

Based on licenses viewed above, set the appropriate license for the user, as follows:

Set-MgUserLicense -UserId <name>@<domain> -AddLicenses @{SkuId = ‘<license-sku-id>’} -RemoveLicenses @()

Note: If a user requires an update to their OnPremisesImmutableId, the domain must be set back to managed, the user can be updated, and the domain can be re-federated.

The same command structure for creating a user can be used to create a PowerShell script.

Bulk importing user profiles using a CSV file

Follow the steps in described in Create user accounts with Microsoft Office 365 PowerShell. Be sure to include the OnPremisesImmutableID parameter when creating the users.

2. Verify that your users have been created by reviewing your list of users in the Microsoft Office 365 UI.

3. Return to the PowerShell command line interface. Enter the following to get the User Principal Name (UPN) and ImmutableID values:

Get-MgUser -All -Property DisplayName,OnPremisesImmutableId,UserPrincipalName,AssignedLicenses | Select DisplayName,OnPremisesImmutableId,UserPrincipalName,AssignedLicenses

4. Create an Immutable ID for each user that does not have one by entering:

Update-MgUser -UserId <name>@<domain> -OnPremisesImmutableID <character string>

You can enter any value for <character string>.

Note: If you have synced with On-premises AD, replace -ImmutableID <character string> with the Identity as a Service user profile ImmutableID value. For example,
-ImmutableID +FELF0aANBcvfWMLSD=

To find the user's ImmutableID, on Identity as a Service, go to Members > Users to display the Users List page. Click the user to view the user profile and scroll to Optional Attributes.

For more information, see Step 1: Optional. Map the Immutable ID attribute to the directory attribute.

5. Log in to your Identity as a Service account.

6. Add the users that you created for your Microsoft Office 365 account on Identity as a Service. You can do this through Active Directory Synchronization, Bulk import, or adding users individually.

7. Enter the ImmutableIDs and UPN values listed in PowerShell into the Identity as a Service O365 ImmutableID and O365 UPN attribute fields. To do this:

a. Click > Members > Users. The Users List page appears.

b. Click the User ID for the profile you want to edit. The User Profile page appears.

c. Under Attributes, do the following:

d. Locate the attribute you created for the O365 ImmutableID and on the line below it, enter the O365 ImmutableID from PowerShell.

e. Locate the attribute you created for the O365 UPN and on the line below it, enter the O365 UPN from PowerShell.

f. Click Save.

Step 7: Configure Microsoft Office for Identity as a Service using PowerShell

Configure Microsoft Office 365 for Identity as a Service using PowerShell

1. Open PowerShell.

2. Connect to Microsoft Graph using PowerShell.

3. Complete the following for each domain:

a. Ensure that the domain to be federated with Identity as a Service is not the default domain in Microsoft Office. (The default domain in Microsoft Office cannot be federated through SAML authentication).

If your domain has not previously been federated with a Identity as a Service or (Active Directory Federation Services) (AD FS), you can skip to step h .

b. If you have already added a Federated Domain and it is federated with an IDP, including Identity as a Service or AD FS, you must break the existing federation by following these steps for each domain that will be federated.

Tip: If you are not using AD FS you can skip steps b-f in this step.

c. Verify which domains are federated by entering:

Get-MgDomain.

d. Set authentication to be managed by Microsoft Office 365:

Update-MgDomain -DomainId <domain to convert> -AuthenticationType Managed

e. Convert the domain to standard (as opposed to federated).

f. Enter Convert-MsolDomainToStandard -DomainName <domain to convert> -SkipUserConversion:$true -PasswordFile C:\userpasswords.txt.

Note: The password text file can be given any name.

g. Set authentication to be managed by Microsoft Office 365: Set-MsolDomainAuthentication -Authentication Managed -DomainName <domain to convert>.

h. Enter each of the following variables in PowerShell. You must do this for every domain.

$domain="<Microsoft Office 365 domain>"
$issuer="<EntityID>"

Note: Open the metadata file you downloaded in Step 5: Download the Metadata file from Identity as a Service and locate the value for the EntityID.

$logon="https://<Identity as a Service_Domain>/api/saml/SAML2/SSO"
$logoff="https://<Identity as a Service_Domain>/logout.html"

Note: Where Identity as a Service_Domain is the domain of your custom Identity as a Service account URL.

$cert="<ds:X509Certificate>"

Attention: If you are updating the certificate, ensure that the new certificate is set correctly.

Note: Open the metadata file you downloaded in Configure Identity as a Service for Microsoft Office 365 access and locate the value for ds:X509Certificate. You must copy the entire value.

If you enabled ActiveSync in Step 3: Add Microsoft Office 365 to Identity as a Service, enter the following:

$activeLogOnUri="<Active Logon URI>"

If you did not set ActiveSync, set the value as follows:

$activeLogOnUri=$logon

Note: If you have multiple domains in Office 365 that will be federated, then append the domain value (for example,“?domain=<domainname>”) to the $logon and $activeLogOnUri values (similar to how the domain is added for the $issuer value). For example:

$logon="https://<Identity as a Service_Domain>/api/saml/SAML2/SSO?domain=<domainname>"

i. Enter the following:

New-MgDomainFederationConfiguration -DomainId $domain -DisplayName $domain -PassiveSignInUri $logon -ActiveSignInUri $activeLogOnUri -IssuerUri $issuer -SignOutUri $logoff -PreferredAuthenticationProtocol “saml” -SigningCertificate $cert -FederatedIdpMfaBehavior “acceptIfMfaDoneByFederatedIdp”

If the operation is successful, PowerShell does not return a response in the command line. If you receive an error, double check the format and syntax of your commands.

Examples

The following are examples for reference:

● A single domain used in Office 365 for SAML

Set-MsolDomainAuthentication -Authentication Managed -DomainName test.example.com

$domain=test.example.com
$issuer="https://test.trustedauth.com/api/saml"
$logon="https://test.trustedauth.com/api/saml/SAML2/SSO"
$logoff="https://test.trustedauth.com/logout.html"
$cert="MIID7zCC…"
$activeLogOnUri="https://test.trustedauth.com/api/saml/SAML2/SSOSoap/A0FFF35A7CB6D9A1D96B4606793551A85D7B5F07"
New-MgDomainFederationConfiguration -DomainId $domain -DisplayName $domain -PassiveSignInUri $logon -ActiveSignInUri $activeLogOnUri -IssuerUri $issuer -SignOutUri $logoff -PreferredAuthenticationProtocol “saml” -SigningCertificate $cert -FederatedIdpMfaBehavior “acceptIfMfaDoneByFederatedIdp”

● Two domains used in Office 365 for SAML

Update-MgDomain -DomainId this.sample.com -AuthenticationType Managed

$domain=this.sample.com
$issuer="https://test.trustedauth.com/api/saml?domain=this.sample.com"
$logon="https://sales.trustedauth.com/api/saml/SAML2/SSO?domain=this.sample.com"
$logoff="https://sales.trustedauth.com/logout.html"
$cert="MIID4xDE…"
$activeLogOnUri="https://sales.trustedauth.com/api/saml/SAML2/SSOSoap/9C4A75F5EB0DDC9A0C826C39B83EFD4C7ECD02EE?domain=this.example.com"
New-MgDomainFederationConfiguration -DomainId $domain -DisplayName $domain -PassiveSignInUri $logon -ActiveSignInUri $activeLogOnUri -IssuerUri $issuer -SignOutUri $logoff -PreferredAuthenticationProtocol “saml” -SigningCertificate $cert -FederatedIdpMfaBehavior “acceptIfMfaDoneByFederatedIdp”

Integrate Microsoft Office 365 with Identity as a Service