Google Workspace to Office 365 SSO & Provisioning Guide for Admins

Table of Contents

1. Topic Overview

Overview of our scenario and expected output .

Jump to section

2. System Requirements

Let us ensure system prerequisite for Google Workspace to Office SSO.

Jump to section

3. Office 365 ImmutableId

What is immutableId and how does it impact federation?

Jump to section

4. Google Workspace to Office 365 SSO

Step by step instructions to setup Google to Office 365 SSO.

Jump to section

5. Google to Office Provisioning

Instructions to setup Google Workspace to Office 365 user provisioning.

Jump to section

6. FAQs

Get answer to FAQs, or ask if you have any question.

Jump to section

Google Workspace to Office 365 SSO & Provisioning

Topic Overview & Expected Output

There might be use cases where you would like to setup Google Workspace SSO to office 365
so your Office 365 users can authenticate via their Google Workspace or Google Cloud Identity accounts.

A couple of use cases that I have seen are-:

Your organization has moved to Google Workspace, but a few users still have accounts in Office 365.
Your organization has moved to Google Cloud Identity as your Identity provider and now needs to authenticate to target applications including Office 365.

Google Cloud Identity is very flexible and it can be used as “Service Provider”, Identity provider or even both.

In this blog post, I would show you how you can use Google Cloud Identity or Google Workspace as identity provider and use Google Workspace SSO to sign in Office 365 via SAML 2.0 (or WS-Fed).

Let’s start with our expected output, we should see following after our setup-:

Our users should see the Office 365 application icon in their Google Workspace or Cloud Identity dashboard and launcher, and when they click on it, they should be logged into Office 365 (via their Google Identity) without being asked for credentials.
If our users directly go to Office 365, they should be redirected to their Google Cloud Identity (or Google Workspace) login page, and then back to Office 365 after success Google login.
Users should be automatically provisioned (and de-provisioned) in Office 365 when they are provisioned (and de-provisioned) in Google Workspace or Google Cloud Identity.

System Requirements

Lets look at the system requirements which you should complete for seamless federation and user lifecycle management from Google Workspace to Office 365.

Google Workspace to Office 365 SSO : System Requirements

Office 365 requirements :

Verified Domain (e.g yourdomain.com)
Global Administrator role
PowerShell (with Microsoft Azure Active Directory Module) installed
One Test user (user@yourdomain.com)

Notes :
1. If you have Azure Active Directory Premium, you might be able to create a custom role from Privileged Identity Management instead of assigning Global Admin role (e.g Hybrid Identity Administrator, Directory Synchronization Accounts).

2. You do not own the default Microsoft domain (e.g yourdomain.onmicrosoft.com), and hence can not setup federation on it. You would need to add the domain you own (e.g goldyarora.com) for it, you can find Microsoft’s documentation to add domain in Office here.

Google Workspace (or Google Cloud Identity) requirements :

Supported Google Workspace, Cloud Identity or Drive SKU (details below)
Google Workspace or Google Cloud Identity Super Administrator role
One Test user provisioned (e.g user@yourdomain.com)

List of Google subscriptions with SSO & Provisioning availability

Plan	SSO	Provisioning
Google Workspace Basic	Available	Available
Google Workspace Business	Available	Available
Google Workspace Enterprise	Available	Available
Google Cloud Identity Free	Available	Not Available
Google Cloud Identity Premium	Available	Available
Google Drive Enterprise	Available	Not Available
Google Workspace Education	Available	Available
Google Workspace Education Enterprise	Available	Available

Undestanding Office 365 ImmutableId

In this section, let’s understand Office 365 immutableId attribute, how does it impact our Google Workspace to Office 365 SSO, and how to fix it with a few PowerShell commands

Understand & Fix Office 365 ImmutableId

Office 365 has an immutableId attribute to uniquely identify users (primaryKey). It is similar to objectGUID in Active Directory.

Now what your users’ immutableId would look like depends on how you provision your users, lets look at various provisioning options along with their impact on immutableId-:

You have just setup Office 365 and the only user you have is someuser@somename.onmicrosoft.com : You do not need to worry about ImmutableId as you have not created users in Office 365 (except your default .onmicrosoft.com one), you can simply go to next section as you don’t need to fix immutableId).
Users created directly in Office 365 Admin Console on “Non-Federated” domain : ImmutableId would be blank.
Users created via Azure AD Sync : ImmutableId would be the base64 encoded version of Active Directory’s objectGUID (based on default directory sync configuration, but can be changed).
Users created via Identity Provider (e.g Okta) on a federated domain : ImmutableId would be the value you send to Office 365 when making create user API call via your IdP.

If you are in #2, #3 or #4 category, please read following carefully :

As your Office 365 users have immutableId which is different than their Office 365 UPN

You have two options to deal with it :

Option 1 : Custom Attribute in Google with your ImmutableId

Create a custom attribute in Google (e.g immutableId) → populate it with users’ office 365 immutableId → and then configure Google to send this custom attribute when responding to SAML request.

However, this option would be painful as it requires you to keep managing and populating Google users with their respective Office 365 immutableId.

If you decide to go with this option, you can skip the rest of this section, and go to next one where I show you how to setup Google Workspace to Office 365 SSO.

If you use Google Cloud Directory Sync Google Cloud Directory Sync does not provide attribute transformation option, so you can not send AD objectGUID → base64 encoding → send to Google custom attribute.

Option 2 : Change your users’ ImmutableId

Now, by definition, immutableId is not meant to be changed, however there might be scenarios like this where you might consider to change it.

You may keep reading if you decide to go with this option, as I would now show you how to change your Office 365 users’ immutableId.

Consult your team before changing ImmutableId You should consult with Microsoft or your internal Office 365 team to understand how changing immutableId would impact your other scenarios.

Change ImmutableId

You would need to disable Directory Sync to be able to change ImmutableId, you can do it with following PowerShell command :

Set-MsolDirSyncEnabled -EnableDirSync $false

1. Run the following Powershell command to see all your users UPN, ImmutableId, whencreated and last directory sync time.

Command to view users in PowerShell :

Get-MsolUser -All | Select-Object UserprincipalName,ImmutableID,WhenCreated,LastDirSyncTime

Command to download in csv :

$exportUsers = Get-MsolUser -All | Select-Object UserprincipalName,ImmutableID,WhenCreated,LastDirSyncTime | Export-Csv C:\csvfile

2. If your users’ immutableId is not equal to their Office 365 UPN, then run the following Powershell command to temporarily change their UPN to a non federated domain.

PowerShell command to change UPN of a single user (Change orange part to yours) :

Set-MsolUserPrincipalName -UserPrincipalName admin@id.goldyarora.com -NewUserPrincipalName admin@second.ci.goldyarora.com

PowerShell Command to change UPN of all users except where UPN starts with admin (Change the orange part to yours):

Get-MsolUser -all | Where { -Not $_.UserPrincipalName.ToLower().StartsWith(“admin“) } | ForEach { Set-MsolUserPrincipalName -ObjectId $_.ObjectId -NewUserPrincipalName ($_.UserPrincipalName.Split(“@”)[0] + “@second.ci.goldyarora.com“) }

3. Run the following PowerShell command to change ImmutableId of your users whom UPN is now temporarily changed to non federated domain.

PowerShell command to change ImmutableId of a single user (Change the orange part to yours) :

Set-MsolUser -UserPrincipalName admin@second.ci.goldyarora.com -ImmutableId admin@id.goldyarora.com

PowerShell Command to change ImmutableId of all users except where UPN starts with admin (Change the orange part to yours) :

Get-MsolUser -all | Where { -Not $_.UserPrincipalName.ToLower().StartsWith(“admin“) } | ForEach { Set-MsolUser -ObjectId $_.ObjectId -ImmutableId ($_.UserPrincipalName.Split(“@”)[0] + “@id.goldyarora.com“) }

4. Run the following powerShell command to change the UPN back to original as we have now changed the ImmutableId.

PowerShell command to change UPN of a single user (Change the orange part to yours):
Set-MsolUserPrincipalName -UserPrincipalName admin@second.ci.goldyarora.com -NewUserPrincipalName admin@id.goldyarora.com

PowerShell Command to change UPN of all users except where UPN starts with admin (Change the orange part to yours) :
Get-MsolUser -all | Where { -Not $_.UserPrincipalName.ToLower().StartsWith(“admin“) } | ForEach { Set-MsolUserPrincipalName -ObjectId $_.ObjectId -NewUserPrincipalName ($_.UserPrincipalName.Split(“@”)[0] + “@id.goldyarora.com“) }

5. Run the following PowerShell command to confirm that ImmutableId for our users have been changed and now matching the UPN.

Command to view users in PowerShell-:

Get-MsolUser -All | Select-Object UserprincipalName,ImmutableID Command to download in csv-:

$exportUsers = Get-MsolUser -All | Select-Object UserprincipalName, ImmutableID | Export-Csv C:\csvfile

Now you are ready to move to next step where we will setup Google Workspace to Office 365 Single Single On (SSO).

Google Workspace to Office 365 SSO Setup

Setup Office 365 as Service Provider in Google Workspace

1. Login to Google Workspace or Google Cloud Identity Admin Console (admin.google.com)

2. Go to Apps, and then click on SAML apps as shown in the screenshot below

Click on + icon to search and add Office as SAML application.

Search Google’s SAML apps catalogue for Office 365.
Go to Microsoft Office 365 from the search results.
Click on the right arrow (shown as #3 in screenshot below) to configure Office 365 as SAML application.

Download IDP metadata from option two (we will use the values from it when configuring Google as IDP in Office 365 later).
Click on Next after your downloaded metadata.

You may leave the default values for Application name and click on next

1. Enable Signed Response by checking the box as shown in the screenshot below.

2. Select Basic Information –> Primary Email to be sent in Name ID

3. Select “Persistent” as the Name ID format.

Note : If you did not change your Office 365 users’ immutableId to UPN, and rather decided to go with immutableId itself, then select your custom attribute which contains users’ immutableId here, and not primary email.

Select Basic Information –> Primary Email for the IDPEmail attribute mapping.
Click on “Finish” to complete SAML application setup for Office 365.

Create Powershell variables for Office 365 SSO

Office 365 needs a few properties for federation setup so it can securely send SAML request to Google, and can also parse the the response.

Property Name	Why we need it?	Property Value
Domain Name	This will our Office 365 domain name that we want to federate to Google.	Domain Name that we want to federate.
Authentication	We would need to tell Office 365 our authentication method.	Federated
Federation Brand Name	This is for our reference, we can provide any contextual name here (e.g Google)	Google Cloud Identity
Issuer URI	Microsoft needs to know who issued the SAML response, here we would put our Google Entity ID here.	Entity ID (Available in the IDP metadata that we downloaded from Google)
Active and passive logon URI	This would be the Identity provider (Google in our case) URL, which Office 365 would refer to as SSO URL.	Google SSO URL (available in the IDP metadata file that we downloaded from Google)
LogOffUri	To specify where should Office 365 redirect our users when they log out. You can put URL any URL here.	https://accounts.google.com/logout
Signing Certificate	This would be the public key which Google provided us, Office 365 would use this to identity itself in the SAML request, and also to parse SAML response.	X509Certificate Value (available in the IDP metadata file that we downloaded from Google)
PreferredAuthenticationProtocol	To specify the preferred authentication protocol.	SAMLP

Your variables would look like this (with your own values for domain name, federated brand name, issuerUri, activeLogOnUri, PassiveLogOnUri, Signing Certificate)

Watch video above for clarity You can also watch the video above to see if need step by step instructions.

$domainName = “id.goldyarora.com”
$Authentication = “Federated”
$FederationBrandName = “Google Cloud Identity”
$IssuerUri = “https://accounts.google.com/o/saml2?idpid=C03a9sjs9”
$PassiveLogOnUri = “https://accounts.google.com/o/saml2/idp?idpid=C03a9sjs9”
$ActiveLogOnUri = “https://accounts.google.com/o/saml2/idp?idpid=C03a9sjs9”
$LogOffUri = “https://accounts.google.com/logout”
$SigningCertificate = “MIIDdDCCAlygAwIBAgIGAXEQDuMqMA0GCSqGSIb3DQEBCwUAMHsxFDASBgNVBAoTC0dvb2dsZSBJbmMuMRYwFAYDVQQHEw1
Nb3VudGFpbiBWaWV3MQ8wDQYDVQQDwZHb29nbGUxGDAWBgNV
BAsTD0dvb2dsZSBGb3IgV29yazELMAkGA1UEBhMCVVMxEzARBgN
VBAgTCkNhbGlmb3JuaWEwHhcNMjAwMzI1MDQ1OTAxWhcNMjUw
MzI0MDQ1OTAxWjB7MRQwEgYDVQQKEwtHb29nbGUgSW5jLjEWMB
QGA1UEBxMNTW91bnRhaW4gVmlldzEPMA0GA1UEAxMGR29vZ2xlM
RgwFgYDVQQLEw9Hb29nbGUgRm9yIFdvcmsxCzAJBgNVBAYTAlVTM
RMwEQYDVQQIEwpDYWxpZm9ybmlhMIIBIjANBgkqhkiG9w0BAQEFAA
OCAQ8AMIIBCgKCAQEA6GfDWaCspEWgMKE8aTpUq3W95p9JulrT4UE
ROj6s3/RJDpyCeZQYOPOcFiJqEIPwiEK5QFkQFHOZUEgjqhHAcyDUf1D”

Now let us copy our variables, and run them in Powershell

Open Microsoft Powershell

Connect to Office 365 with the command Connect-MsolService

Now a window would pop up asking for your Office 365 credentials.
Enter your Office 365 Administrator Email Id.

Enter your Office 365 Administrator Password.

If you are enrolled in to MFA, verify your identity by authentication via MFA.

Now paste the copied variables that you created above as shown in the screenshot and press enter.
If everything went fine here, you won’t see any error, and Powershell would be ready to take next command.

Now we need to run command to setup federation (or change it if you already have federation setup) which would ask PowerShell to fetch values of the federation properties from the variables we just defined.
You can also run this command to check whether your domain is already federated or not.
Get-MSolDomainFederationSettings -DomainName id.goldyarora.com | Format-List *

Run the following PowerShell command IF this is the first time you are setting up federation on this domain:

Set-MsolDomainAuthentication -DomainName $domainName -Authentication $Authentication -FederationBrandName $FederationBrandName -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PassiveLogOnUri $PassiveLogOnUri -LogOffUri $LogOffUri -SigningCertificate $SigningCertificate -PreferredAuthenticationProtocol SAMLP

Run the following PowerShell command IF you already have federation on this domain, and now need to change it to Google :

Set-MsolDomainFederationSettings -DomainName $domainName -Authentication $Authentication -FederationBrandName $FederationBrandName -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PassiveLogOnUri $PassiveLogOnUri -LogOffUri $LogOffUri -SigningCertificate $SigningCertificate -PreferredAuthenticationProtocol SAMLP

Now let us test to ensure federation settings are set for our domain.
Run the following Powershell command replacing id.goldyarora.com with your own domain.
Get-MSolDomainFederationSettings -DomainName id.goldyarora.com | Format-List *
You should see the values of your variables against the federation properties as shown in the screenshot below.

Provide Office 365 SAML application access to our Google users

Now, as we are done with Google Cloud Identity or Google Workspace to Office 365 SSO setup, we need to assign Office 365 SAML application to our required users.

You can either assign this application to all of your users in Google tenant, OR only to a subset of users via their OrgUnit or Group membership.

I would recommend you to put one test user in a group (lets called Office365testgroup), and then give Office 365 SAML app access only to this group.

This way we would be able to test our SSO before we roll it out to broader audience.

Once you create your Group and add a test user in it, assign Office 365 app to this group as shown in below screenshot :

(Note -: The test user you add in this group, should already be provisioned in Google)

Go to Office 365 SAML app that you created in Google.
In the left hand navigation, search for your Group.
Enable the App for this group.
Save changes.

Testing our SSO (Google / Identity Provider Initiated)

Login to Google with your test user and to https://gsuite.google.com/dashboard
Here you should see Office 365 application as it has been assigned to you via test group membership.

As you are already logged in to your Google account, Google would send the SAML assertion to Office 365 when you click on the application icon.
You should have been logged in successfully to your Office 365 application.

Note-: If your Office 365 Administrator has enabled MFA, and if you haven’t set it up yet, you would be asked to register it.

Testing our SSO (Office 365 / Service provider Initiated)

Now, as we have federation in place, when our user tries to login directly to Office 365, he should be redirected to Google.

Office 365 is redirecting our user to Google as we have setup Google as our identity provider.

Now if the user is already logged into Google, then user would straight away land to Office 365 page.

If the user is not already logged into Google, then would require to login to Google first.

Then, if our user would be asked to login to Google (if not already logged in), and should landing at Office 365 after successful login to Google.

Now, Google would send the SAML response to Office 365, and user should be logged into Office 365.

As you have now successfully tested both IdP initiated and SP initiated sign on, feel free to assign Office 365 application to all / required users.

You can turn off SSO if required (may be for troubleshooting) with following command (replace my domain name with yours) :

Set-MsolDomainAuthentication -DomainName id.goldyarora.com -Authentication managed

Google Workspace to Office 365 Provisioning

In this section, let us understand how we can manage our Office 365 users lifecycle via Google Cloud Identity (or Google Workspace).

Click on the Office 365 application that you created earlier (Google Workspace Admin Console –> SAML Apps –> Office 365) as shown in the screenshot below.

Click on User Provisioning to start the configuration of Google Workspace to Office 365 provisioning.

Note : If you do not see User Provisioning here, that means you either do not have Super Admin role in Google, or you have Google Workspace or Google Cloud Identity plan that does not offer auto user provisioning.

Click on “Set up user provisioning”.

You would need to authorize Google to be able to create and manage users in Office 365, click on “Authorize”.

Enter your Office 365 Administrator password

Approve the sign in request if you have MFA enabled on your Office 365 Admin account.

Attribute Mapping :

You would now need to map attributes (e.g which attributes should Google send to Office 365 to create and manage your users.
These 4 attributes shown below are required ones including “onPremisesImmutableId” where you would need to provide mapping.
You can any value that you want for immutableId, I would go with Google Workspace user’s primary email for it.
You can also click on “Show All” to map other optional attributes.

Here you should add your Google group which you would be using for provisioning to Office 365.

Whoever is in this group, would be created as user in Office 365.

Click Ok

Now as we have mapped the attributes along with defining our provisioning scope via Google group, we are all set to activate provisioning from Google Workspace to Office 365.

Click on “Activate Provisioning” as shown in the screenshot below.

At this stage, Google would inform us one more time to ensure we have mapped the attributes correctly along with defining our provisioning scope, because once we turn on Activate here, Google would start the provisioning right away.

As we are all set with these requirements, let us go ahead and activate provisioning by clicking on “Activate” button.

At this time, users in your scoping group should be created in Office 365.

These actions (including create, suspend or update users) would be logged in your Google Admin Console –> Reporting –> Audit –> Admin.

You should also go to your Office 365 Admin console to confirm that you users are created and/or updated there.

FAQs

Here am listing some of the frequently asked questions about Google Workspace to Office 365 SSO & User Lifecycle management, please comment in the bottom if you have any question, and I will add it (along with the answer) to FAQs.

FAQ

Most frequent questions and answers about Google Workspace to Office 365 SSO and Provisioning.

How can we provision Groups & memberships?

Google does not provide an option to provision / manage groups and memberships to Office 365.

I do not see an option to add SAML application

Only Google Workspace or Google Cloud Identity Super Administrators can add SAML applications.

Please make sure you are assigned Super Admin role.

Can we configure 3rd party MFA (e.g DUO)?

No, Google does not support 3rd party MFA integration.

However you should be able to leverage Google’s MFA (which supports multiple MFA methods including security key).

Google’s MFA is available to Google Workspace and Google Cloud Identity customers without any additional cost.

What kind of logs does Google provide for SAML Apps?

Google Cloud Identity (or Google Workspace) Administrators with Reporting priveleges can look at SAML and Provisioning logs.

Following SAML Login logs are available at this path Admin Console –> Reports –> Audit –> SAML

SAML Login Logs :

Event Nama – (e.g Successful login)
Event description (e.g Goldy Arora logged in)
User (e.g admin@id.goldyarora.com)
Application Name (e.g Microsoft Office 365)
Organization name (user’s orgUnit name like /Contractors)
Initiated by (who initiated the login e.g Service provider or Identity Provider)
Failure type (if any failure, e.g Application not configured)
Response status (e.g SUCCESS_URI)
Response second level status
IP Address (login user’s IP address, e.g 96.248.xxx.xx)
Date (date and time of user login, e.g 3 Feb 2020, 08:47:59 GMT-5)

Following provisioning (and deprovisioning) logs are available at this path Admin Console –> Reports –> Audit –> Admin

Event Name (e.g Update Auto Provisioned User)
Event Description (e.g User admin@id.goldyarora.com was updated on application Microsoft Office 365 by auto provisioning)
Admin (which Admin performed this operation)
Date (date and time when this operation was performed, e.g 24 Apr 2020, 13:59:30 GMT-4)
IP (IP address of the Admin who performed this operation, e.g 96.248.XXX.XX)

I have a question, what should I do?

Ask it in the comments below, and I would try to answer it (if i can) as soon as I get time.

RECOMMENDED READING

As you just read Google Workspace to Office 365 SSO and Provisioning Guide, I would recommend following as complimentary reading.

Admin Google Workspace Security SSO

Definitive Guide to Okta & Google Integration

Google Conflicting Accounts

Definitive Guide to Google Conflicting Accounts

Admin Google Workspace Security SSO

Securely login to any app with Google Workspace Password Vaulted Apps

Fabio
August 10, 2023 at 2:53 am

Hi, I got the Google certificate of federation expired, so I generated a new one. I sent to Microsoft the new values by powershell. Apparently all went smooth but when I try to access office 365 from google I got the following error
AADSTS5000811: Unable to verify token signature. The signing key identifier does not match any valid registered keys.
Using the command Get-MsolDomainFederationSettings I noticed that Microsoft didn’t update the new parameters that I sent with powershell and it still keeps the old setting. So I wonder how I could force office 365 to get the new setting . Thanks a lot in advance for your help
Fabio

Reply
Mustafa B
April 19, 2023 at 1:59 am

Hi,

Thanks for the great article
I had a question related to autoprovisioning of users.
Will the existing Azure AD users be affected if we enable auto provisioning at Google workspace level?

Reply
Kyle
January 25, 2023 at 3:18 pm

Hello so I have been testing this and everything in the web works. It seems when you try to activate office desktop apps I get a 404 error. Google support says that with SSO enabled it’s not supported for desktop apps like Outlook, word, etc. Is this true or is there a workaround?

Reply
Patrick
December 15, 2022 at 12:24 am

Hi, thanks for this guide. It should make things easier to follow I hope.I am going to setup my schools windows devices to connect to azure and manage with intune.
When they log in to windows after connecting to azure will it pop up with the google login screen before logging in to the device?
I havent found any information yet if this will work with azure/intune managed devices.

cheers

patrick

Reply
1. Ray
  January 30, 2023 at 10:41 pm
  
  I’m also trying to use this method and import users in Azure AD for Windows Account purposes with Intune and having the users authenticate with windows.
  
  can we assume this method is ONLY for Office365 account access and NOT Windows (even though the article describes WS-Fed is supported which is what Windows Account uses)
  
  Reply
Carmelo
October 29, 2022 at 2:41 am

All good as long as the google certificate has not expired. I renewed the certificate, I rerun the powershell procedure to register the new certificate; the commands are correctly executed; but following the command Get-MSolDomainFederationSettings -DomainName $ domainName | Format-List * I always get the old certificate (the expired one). What am I getting wrong?

Reply
1. Fabio
  August 10, 2023 at 1:04 pm
  
  Hi Carmelo I have got your same problem. How were you able to solve it
  Thanks for your suggestion
  fabio
  
  Reply
Hank
September 22, 2022 at 10:44 am

Great guide.

May I make a suggestion — put something in bold letters about auto provisioning that it should not be set to delete users.

If a user gets deleted and 30 days passes Microsoft permanently deletes that user. I have not been able to find a way to recreate a user that is deleted by Microsoft this way.

So auto provisioning should always be set to “suspend” unless you’re absolutely sure you will never need that user again.

Reply
Droid
August 3, 2022 at 7:50 am

Hello,
it’s 2022, thnak you for the guide. I am trying to set Google Workspace to sign guests account into Office 365 without using OTP.

I am following the guide, but the Set-MSOLDomainFederationSettings if it is the first time setting it up or if already exists. In my instance, it is the first time setting it up. However the command executes but states: “This domain does not exist. Check the name and try again”

Is there a different command for creating the domain federation initially?

Reply
Alexander
March 6, 2022 at 8:37 am

Hello! How can I disable all this?
We no longer need to use Gsuite as IDP for Office 365

Regards

Reply
1. Goldy Arora
  April 17, 2022 at 2:15 pm
  
  please look at this article again, it covers how to disable SSO.
  
  Reply
2. Michal
  May 16, 2022 at 9:51 am
  
  First of all – peace of a great job!
  I’ve a question related to M365/Azure. As the SSO and Auto provisioning is working.
  Is it possible to “Domain Join (Azure AD) a device using the SSO feature by Google Workspace?
  In a theory if devices ‘Azure Domain Join” is turned on for all accounts – it should work, isn’t it?
  
  Reply
Oscar
February 5, 2022 at 10:11 pm

Hello:
I have a domain “mydomain.com” and subdomain “other.mydomain.com”. On Microsoft 365 admin center both are federated, but when Google sync only user with the domain “mydomain.com” are created, no one with the subdomain.
What I need to do?

Reply
1. Oscar
  February 6, 2022 at 8:59 am
  
  The problem was time, 24 hours later users on subdomain show up.
  Thanks.
  
  Reply
Tom W
January 5, 2022 at 11:27 am

Hi, Thanks for the guide – very hekful and have been using O365 with Google sign in successfully for several months.

Currently have an issue with several users having a “You need to verify your identity” challenge from MS, which loops forver sending SMS verifications – after the correct SMS code is entered, it asks users to confirm password and goes back to the SMS i.e. they cannot login.

I assume this is an MFA or security setting that needs to be removed in Azure?

Reply
Paul Vincent
December 6, 2021 at 7:36 am

Hi Goldy,

A fantastic tutorial – many thanks for this! SSO is working for most of our users, but a number of them are reporting the error ‘XXXXXX user does not exist in the directory’ when trying to sign in via Google. I’ve checked and they have the immutable ID set as their email/username, so I can’t work out why this error is occurring.

I did notice that the Principal ID has a capital letter at the start, whereas the Immutable ID doesn’t, but when I’ve tried replicating this difference for a test user, that user is still able to sign in via SSO, so I’m stumped! The user is also being synced from Google, which wasn’t previously the case, but syncing doesn’t seem to have helped either.

Do you have any other pointers short of deleting accounts for re-provisioning (some users have several Gb of data in their OneDrive)?

Many thanks again!

Paul

Reply
David Moreta
October 7, 2021 at 5:08 pm

Thanks a lot for the time and effort on making this great tutorial! I was struggling to make Google SSO work with M365 for a client of mine and with your very detailed explanations I was able to make it work. Thank you so much, Goldy.

Reply
Vittorio
August 23, 2021 at 8:44 am

Hi Goldy,
it’me again but when I’ve configured auto provisioning the gsuite portal doesn’t show me the Office 365, click on “Authorize” passage, it redirect me to gsuite login autentication and doesn’t ask me to insert the “.onmicrosoft.com” credential…
I’ve also try to re-authoryze the saml apps but all gone in the same way
I’m not sure if i’ll well explained the problem …

thanks in advance
Vittorio

Reply
Vittorio
August 23, 2021 at 5:20 am

Hi Goldy,
your guide it’s wonderfull, i’ve configuerd all and auth it’s working good
but every time I logged in I receive a “Stay signed in” message from browser,
also if I check “Don’t show this again” option…
Have you any idea ?

thanks in advance
Vittorio

Reply
James Cox
August 17, 2021 at 7:59 am

Thanks for the in-depth tutorial. All is working except for some users who were bulk uploaded to Azure before the federation, we deleted these users from Azure hoping they would auto-provision from Google, but they are not. Have tried adding these users to different groups, turned provisioning on and off. Nothing, any suggestions would be welcome. Thanks

Reply
1. Rory
  November 4, 2021 at 11:50 pm
  
  If they are still in the “deleted users” then permanently delete them.
  
  Reply
Drilon
August 12, 2021 at 3:46 pm

hey, thank you for the tutorial
when i run:
PS C:\Windows\system32> Set-MsolDomainFederationSettings -DomainName $domainName -Authentication $Authentication -FederationBrandName $FederationBrandName -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PassiveLogOnUri $PassiveLogOnUri -LogOffUri $LogOffUri -SigningCertificate $SigningCertificate -PreferredAuthenticationProtocol SAMLP

I get the below output and i am not able to bypass it, any idea what is causing the error ?

Set-MsolDomainFederationSettings : A parameter cannot be found that matches parameter name ‘Authentication’.
At line:1 char:58
+ … ainFederationSettings -DomainName $domainName -Authentication $Authen …
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Set-MsolDomainFederationSettings], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.Online.Administration.Automation.SetDomainFederationSettings

thank you

Reply
Fabio
August 8, 2021 at 4:01 am

Hi thanks for your article that it’s very useful; I succeeded to make all the parts of the operation but during the provisioning for a little group of users I got an error of this kind
StatusCode: 400 : Bad Request : { error :{ code : Request_BadRequest message : Invalid value specified for property ‘department’ of resource ‘User’. details :[{ target : department code : InvalidLength }] innerError :{ date : 2021-08-05T20:45:38 request-id : 0dc4f079-0b32-4eda-b9c1-e357a4ba8c39 client-request-id : 0dc4f079-0b32-4eda-b9c1-e357a4ba8c39 }}}
At the end these users they weren’t in the office365 platform
Do you know how I could solve this problem?
Thanks a lot in advance for any help
Best regards
Fabio

Reply
1. Goldy Arora
  August 9, 2021 at 6:47 pm
  
  Not sure, but it indicates “target : department code : InvalidLength” something wrong with the value that you are sending from Google for it.
  
  Reply
Jeroen Potters
August 6, 2021 at 7:45 am

Great article, thanks. I’ve set it up a year ago works great. Only recently we found something broke the setup.

When adding a new user to the OfficeGroup in Google we get an error 17013 ( Generating access token for the SP failed) and user is not federated to MS365.

Any thoughts?

Reply
1. Goldy Arora
  August 9, 2021 at 6:48 pm
  
  Not sure, try re-authenticating your office 365 app from Google Admin console –> SAML apps page.
  
  Reply
  1. Jeroen Potters
    August 11, 2021 at 9:42 am
    
    Tried re-authenticating first, but no success. Finally removed Auto-provisioning and re-added it again, with more success on that! Thanks for the help
    
    Reply
    1. Goldy Arora
      August 12, 2021 at 9:32 pm
      
      glad you figured it out.
      
      Reply
      1. Dom
        January 19, 2022 at 11:31 pm
        
        I’ve used these instructions to install SSO to MS Office for around 4 or 5 businesses now, and this exact error is slowly creeping across all the clients. It seems to happen after Auto Provisioning has been installed for 6 months to a year, then it stops working with the error “error 17013 (Generating access token for the SP failed). Users can still authenticate, but provisioning actions (suspension, deletion, creation) all fail.
        
        Reauthenticating doesn’t work. Looks like (another) bug in Google’s services.
        
        As per Jeroen, the easiest fix seems to be:
        1) Delete the Auto Provisioning configuration (NOT the App, just the Auto Provisioning).
        2) Create a new OU for “No Office” and move any users that failed provisioning into the new OU
        3) In the App settings, turn OFF Office for the “No Office” OU.
        4) Wait ~10 minutes for your changes to Auto Provisioning to propagate. It will let you create a new configuration in this time but it won’t let you save it, generates random errors.
        5) Re-create Auto Provisioning and map the fields
        6) Turn Auto Provisioning On
        7) Move the failed users from a “No Office” OU to an Office enabled OU.
        8) Wait about an hr. Auto Provisioning works on it’s own timetable, and it should provision in the next hr or so.
Mila
July 25, 2021 at 7:37 pm

When a primary email address is modified, immutable id on MS O-365 is not updated. what parameter should I set the Basic-Information ( I tried ‘Username’ or ‘Primary email’, but unsuccessful) to on Google side when auto-provisioning so the changes are reflected, or is there any other way they can fix this issue? Thank you.

Reply
1. Tomas
  October 5, 2022 at 9:08 am
  
  Hi Mila, have you find a solution for this? I recently renamed the primary email address of a user and unfortunately she cannot log in anymore.
  
  Reply
Jim
June 4, 2021 at 10:29 am

Great article and I was able to get my office 365 federated through Google. My cert is about to expire next month and any information on how to update it would be helpful. I believe I have the instructions, but it was difficult to find. Most documentation assumes you are using AD for federation.

Reply
Refaad
June 4, 2021 at 5:20 am

Hi Goldy,

Thank you for this, I have though run into a issue when it comes to provisioning.
Gsuite/workplace is the IDP with no users on offfice365, so when i setup the auto-provision i get the below error.

, 45003, StatusCode: 400 : Bad Request : { error :{ code : Request_BadRequest message : Cannot convert a primitive value to the expected type ‘Edm.String’. See the inner exception for more details. innerError :{ date : 2021-06-04T09:48:42 request-id : cbfaf3f1-f331-4276-a706-81f27fdda592 client-request-id : cbfaf3f1-f331-4276-a706-81f27fdda592 }}}

Reply
1. Drilon
  September 27, 2021 at 2:31 am
  
  Hey Refaad,
  
  were you able to fix it?
  i have the same issue myself, and still haven’t found an answer for it
  
  Reply
  1. Augareth
    August 7, 2023 at 1:55 am
    
    Did anyone Rafaad or Drilon find a fix for this? Have the same issue and waiting for Google support but won’t hold my breath.
    
    Reply
Massimo
May 18, 2021 at 5:03 am

If both users (Workspace and O365) have a mailbox.
How’s mail managed? Merged in one mailbox?

Reply
1. Goldy Arora
  July 27, 2021 at 6:03 pm
  
  It really depends on what you want, it can go to either place or to both.
  
  Reply
  1. Prasad
    July 1, 2023 at 1:11 am
    
    Dear Goldy
    
    Thanks for this very helpful article.
    
    I have set up the Google Workspace SSO and auto provisioning with Microsoft 365 successfully. Our DNS records are configured to receive all emails in the Gmail mailboxes for all users which is working as expected. However, emails generated by apps in the Microsoft 365 platform end up in Outlook 365 mailbox and are never reflected in the Gmail mailbox. For example, we use Power Automate to send automated mails based on events in various apps. These end up only in the Outlook 365 mailbox. What can I do to have these emails are sent to the Gmail inbox?
    
    Appreciate your help.
    
    Reply
MH
April 18, 2021 at 5:58 am

Hello Goldy,

Great guideline! It helps a lot!

I have a question. Is it possible to set exception of not using SSO at certain link? For e.g. if accessing to SharePoint online, I want to use MSFT account, not the Google Account.

Does not seem to have a place to input this kind of exception URL. Once we setup the SSO, all the login of MSFT will redirected to Google?

Reply
Bernhard
April 5, 2021 at 8:08 am

Thanks for that perfect instruction. It seems to work. I do however have a question, that I don’t find an answer to:
If I need to change the email address of an employee (after a marriage for example), the primary email address changes. Those changes are propagated to Office 365 and result in a changes “SignInName” and changed “UserPrincipalName”. Unfortunately the ImmutableId is not being changed. So SSO does not work anymore…

Is there a way, that changing the primary email address would propagate completely? Or do you have another idea?

Reply
Anna
March 21, 2021 at 2:17 pm

Hi Goldy, we followed step by step your guide but we can’t connect with power shell in any way. The module seams to be installed and imported but we ha ve the same error every time no matter the power shell version we are using. What can we do to solve our problem?

Reply
Tony Sheets
March 12, 2021 at 5:30 pm

Hey Goldy! Long time my friend, hope you’ve been well. I’ve struggled with a wrinkle and wondered if you have insights. Secondary domains…. from what I gather the IssueUrl has to be unique for each O365 Federated domain. But, I can’t add another O365 SAML app in Google Workspace. A new cert only modifies the cert but not the IssueUrl.

The source Google environment has about 7 different domains with those as the primary addresses.

Do I need to setup custom SAML apps for each domain?

Reply
1. Goldy Arora
  August 3, 2021 at 3:41 pm
  
  Hi Tony – My apologies, I just noticed your comment, things are good, hope all is well with you.
  Can you give me some more context on this?
  Do you have a single google tenant with multiple domains –> SSO to an office 365 tenant with multiple domains?
  
  Reply
Kirupananthan
February 15, 2021 at 4:27 am

Dear Goldy Arora,
Thanks for your guides, very helpful and we able to follow the instruction and setup our office 365 access using Google SSO. I have a question regarding the auto-provision

Today morning we tested to create a user account in google admin and the user account has been auto-provisioned to Microsoft office365 and able to login to the office 365 using the google login credential. Later 1 hour I have created another test account in google admin but the account has not been provisioned to office 365 until now, waiting for more than 2 hours still nothing. Both user account falls under the same group on google. Does the auto-provision take effect immediately to sync with office 365 when a new user account created in Google or is there any sync frequency or any app that we need to use to sync.

Reply
Pingback: G Suite (IdP) + Office 365: How to switch federated users to gmail? – 365 admin service
Alex
January 30, 2021 at 11:55 am

Thank you so much!
I’ve manage to do it and everything works fine.
Now I only need to find how to automatically assign licenses to imported users 😉

Cheers

Reply
1. Daniele Pelosi
  May 24, 2022 at 7:56 am
  
  Hello, same here 🙂 I have also the issue that users provisioned do not directly get assign a location when created, so I need to somehow find a way to do that or licenses will not be assigned.
  
  About automatic assignment, you need to be able to create dynamic groups in AD (depends on your license level), assign the license level to that group, and in theory users should inherit it.
  
  Reply
Enzo
January 20, 2021 at 2:30 am

Hi!
Thank you very much for everything.
It works great but I get some generic errors like this:
45003 – StatusCode: 400 : Bad Request : { error : {
code : Request_BadRequest
message : Property displayName is invalid.
innerError : {
details : [
{
target : displayName
code : GenericError
}

But on Google Workspace accounts works correctly.
Can you advise me what to do?
Thanks!

Reply
Akshay
January 4, 2021 at 7:50 am

Hi Goldy,

Thanks for your tutorial on G-Suite to Office365 SSO and provisioning. I have been able to succesfully set up the single-sign on and provisioning on my domain. However, I am trying one additional step beyond what you explained and I am not getting results there. After having done all that you explained above, I tried the following steps:
1. Connected a PC using “Join to Azure AD”
2. Tried to login into the Windows 10 PC using the credentials of one of the users of G-suite identity – it was not working, used to give an error “Incorrect user or password”
3. Tried to login into the PC using the credentials of one of the primary tenant (onmicrosoft.com) – all users are able to login.

Can you please help me understand and resolve the problem where the users of G suite are unable to login into Windows 10 using their g-suite identity.

Reply
1. Edomer Csury
  February 17, 2021 at 4:37 pm
  
  Hi, has anyone figured that out yet? We want to roll out Google SSO for 130 People and we want to have this solved for our co-workers… Thank you!
  
  Reply
2. Edömér Csúry
  July 2, 2021 at 8:33 am
  
  Any news on that topic? I have the same problem effecting 100+ employee…
  
  Reply
3. Edömér Csúry
  July 2, 2021 at 8:33 am
  
  Any news on that topic? I have the same problem effecting 100+ employee…
  
  Reply
Sam Dickinson
December 29, 2020 at 4:32 pm

Many thanks for your helpful article. I have successfully configured our Not-For-Profit Google Workspace and Office 365 platforms to use a shared SSO (on Google). However I have now encountered an issue which I am unable to resolve and I am hoping that you can help.
If I authenticate in a web browser everything works fine however, if I try to log in through any of the desktop office apps (on a Windows 10 platform) I get the following: –
– “Let’s get you signed in” > “Use a different account” > “Work or school account”
– Microsoft sign in appears > “Next”
– “We can’t connect you. Looks like we can’t connect to one of our services right now. Please try again later, or contact your helpdesk if the issue persists.” – HTTP 404 – accounts.google.com

As you can see the application is failing to communicate with the appropriate Google authentication page.

Do you have any suggestions about how I might resolve this?

Reply
Akshay
December 27, 2020 at 6:46 am

Thanks Goldy! This blog was very useful to help me set up gsuite to azure AD SSO using gsuite as identity provider. I have a question if you could help me with:
My SSO sign on (both active and passive) into Office 365/Azure and user provisioning in Azure is working perfectly. I have joined a device to Azure AD after this. But now, I am unable to have my gsuite users login into the AzureAD joined PC using their credentials (domain.com). All users who are created on the tenant (domain.onmicrosoft.com) are able to login into this PC with their Azure AD, but Gsuite users are unable to login using their domain.com credentials. Could you please suggest what is going wrong? Thanks a lot for all your help.

Reply
Tobias Linder
November 22, 2020 at 4:39 pm

Hi Goldy
Thank you so much for this wonderful admin guide.

I have one little question for which I probably already know the answer, but just to be sure:

The client has two completely separate Google instances (students.schoolname.com and schoolname.com). I have no idea what made them setup separate instances and it’s quite silly actually.

The client would like to use SSO to connect to M365 with users from both google instances but from what I see M365 only takes one federation instance, and I can’t connect both Google instances. I would probably also have to setup two separate M365 instances, right?

Thank you in advance for your highly appreciated answer.

Reply
1. Goldy Arora
  December 11, 2020 at 8:46 pm
  
  Your welcome Tobias, though I think Office 365 does not support multiple identity providers, but am not 100% sure, would be better to check with MS support.
  
  Reply
Robert
November 18, 2020 at 1:00 am

Hi Goldy,

Your article in section 4: “Create Powershell variables for Office 365 SSO” you mention to watch a video for step by step instructions on creating variables. There is no link, or I’m finding it hard to locate this?

Reply
1. Goldy Arora
  December 11, 2020 at 8:48 pm
  
  Hi Robert, am sorry, I planned to create one but then got stuck with a few things, i’ll see if I can create in coming days/weeks.
  
  Reply
Piero
November 14, 2020 at 4:50 am

Hi, first of all thanks a lot for you guide!
My name is Piero, I work in a school in Palermo (Italy); I did all the steps and everythings seems to
be Ok but when I try to login with the test account it doesn’t work and I receice this error: “500. That’s an error”.
If I try to login to the microsoft portal with the google credential i receive this error:

403. That’s an error.

Error: app_not_configured_for_user

Service is not configured for this user.

Request Details
idpid=C0123drdu
RelayState=estsredirect=2&estsrequest=rQIIAa1VS6vsWBk9dc69p–9oF5ERJzYB9pGGuqcvJO6crVTSaoqqTwqj6okNQl5VlJ5v1P7F-iscSQ6aoc9UNSJOHJ8QeixP8CBIxEEJw3WnTh1oLD3hg8Wi_V9rL2-Vx_gj-gj9Ah9cgc_wm8-QigPJ8iImMME4s-xCMfmi4ULzQmKIiOUIj3P95tvvnpt5n_94c93v1E-X0Gvb37_259-Mfte3HVV–bpaRzHxzzxm7Ito-7RL_OnpJsn3R9msy9ns5_dflQ15eB-mvhD0nVlk5Rh7hZ9mIVd2IDyMQz6x6T74rYlUBKDFhgGkYsFgWAYjj5KiBZLBn055monnWlgXyBINo9n0eQQxeA6Od8DO5cwhaUnic1yGXCoZO6BbKidfJZTRb_icxVc8ahiSJ0EgrNiHGMZqJgE4vgvt99Q6L6LkffPVRoI_3H7Miqb3KnKtvvF3Z9fKlVY8AFTFkXod4_vYWHRJb7bJWWxa8oqbLokbN_SNEfTgqYunAqyiIIUpbBg9GM9DcTBr3eqgM8tvLQm1zDGoB3X_Hy-RfGdGQ2dMWx5yXE2yFafbJSUNxPfOYK22SeAUm0W1pWtbF4W63MWrCSYMT0a2lictvDA0IWsSgWCa8GRJS9FvziDwD6cCAfyCgxeR-pgmhMisnA-9Fy91-xhtBYlRB6Wu1JfK-mx0_LJ1s9G6zc-Yy7KSBwTeOnGmGBmFrkV0pXJm7QRFcfacTzf2aRSZi2PubSS9Cif3Cz3mDYGPZQwGMTIEhKAyYTnK3GxKBgL4VCvAixRHqBLO7rYeYjMWi8OuxNUTr3naB0yJWdz5eRgWsK1LQgnZXdRje1-gspdTO_z5oDWHVpt0Kbz_CNOypo8V3B1Cg7tKQe4j_ItDu0HZ_CiOQrT9PJ6RG4_cllmnsayD1ZL3kpGMc6v9pETBCSMTRO7dIGNEdnu4bBiaQNtdruubTbRKjNQV4Bpa0LyUu7xHveDLTpuK98h9FBCCy33Ngdb24vKgo8GcK4abH6Z12p8SvpgngRC1ccQ0Qg0zLemc5yUbHMKHQk_5ql9iCx621oGmOgY9bFtn0Z8mtoTPnkKQp0ZOix1pWYouMrl3TIjJROQViaqe6YcEAfXKYR04UtJwrJb1IoUD-LmBDjdcTG4VCGjlkRVANBFydic7VEWzQE6tCV30QK1Ehproc97Ttjk6VaNtXxVe3yBbeb55iSNF1tjfDrW56kpjphQKWgu-2R3nJ8PCFCg8Xxh8_17f9PmXAJDtmjY1rGLpIYd1kVxmgC-jY8ZueeK1C-tUcqgy35lg4NJMEx3Zp1TUAMudHaCWANAD7ZY206sGca63MJN7Wg4dThYBev61tTFO85voANNSCoH-gTBqKl1h5oM6FW868u-DJNk6Z2E9iwsKZkjm9SaD6lPS0u_W0ormle7pltmwNP357wYyaFsUDTXuAC15E21d2MppiokjnYoWE2Yag59ndI1z1O6CqcX_DSdaFFba5c8dbhuAgmicwwWrcO91AdWrWsMlQ48RS2TopBOF1WhrnPgz9zBy4GRZPWBoa_CI5Mu_a5UsH0iQk6d1mh2xoTAHQ8iQQPHqQqt4Rxf2AA7KZ21Dza2H5unrXgpHX4j6WEFj0tfssS2Mh00RPMDz9n1MJHFStDWZCgtz7DSclnMUaOucF5JkD1cX796CafL0VukLdaalSEmqiCrdMSNh8wB0Y7-3d39NZ3zsnh39_VrdBVJ8OE1m6MkC798Nvvbs2-_eP767js3H9784FvQ3ZsXL169vnlf_evZ7FfPrxvgR59-RTnf_efq89knvxT0-5t3z5_SyCXXWMba8REQgbEFmic_hVvtPA0qmPJeOu0kxlp0Tw3_FnkDf3Y_–z-_t39S551ZM7AcPjv97OffHDzx5e_vv0vy-THYeQkwVuO5l1eLT0mlvg-cLVWYZakyh9i4ogyMaJZp-V7p9q0fk3k03aPD6yzHLnvo-76etuP_z8srZOO_pWHFh8wBFs8oA8ICqMIjhEkSeEP4cPD6eHhP018rDA8-5bmWQSGIBgjHJ2TnP9Rwp–dvNv0
SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCBJRD0iXzllZjI5OTJkLWU4NjktNDFkMi1iMTQyLWUyYjQwYzlhNWYzMSIgVmVyc2lvbj0iMi4wIiBJc3N1ZUluc3RhbnQ9IjIwMjAtMTEtMTRUMDk6NDg6MDAuNzg5WiIgeG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCI+PElzc3VlciB4bWxucz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+dXJuOmZlZGVyYXRpb246TWljcm9zb2Z0T25saW5lPC9Jc3N1ZXI+PHNhbWxwOk5hbWVJRFBvbGljeSBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiLz48L3NhbWxwOkF1dGhuUmVxdWVzdD4=
username=prova@icvittorioemanueleterzo.edu.it

Can you help me please?! =)

Reply
1. Goldy Arora
  December 11, 2020 at 8:57 pm
  
  Your error indicates that application has not been assigned to this user, you should assign it from the google console, also check your certs.
  
  Reply
Nicole
November 3, 2020 at 4:44 pm

Excellent guide, great job!
We setup the SAML SSO, and had been using it for a while. One day, we all received error [‘AADSTS5000811: Unable to verify token signature
. We ran the cmdlet Get-MsolDomainFederationSettings -DomainName “domainname” | Format-List * , we found out that the SigningCertificate was changed. Also, there is a nextSigningCertificate show up from nowhere. We were able to fix it by re-run Set-MsolDomainAuthentication with the correct certificate. However, we are still not able to find out the root cause. Do you have any idea why the SSO SigningCertificate got changed in the Microsoft? Are there any logs I can look up?

Reply
1. Goldy Arora
  December 11, 2020 at 9:07 pm
  
  I am sorry Nicole, this is the first time am hearing such issue, Microsoft support should be your best bet here.
  
  Reply
Ferdinando Bassi
October 31, 2020 at 12:57 pm

Thank you, great tutorial!!

Reply
1. Goldy Arora
  December 11, 2020 at 9:08 pm
  
  Your welcome, glad it helped you setup google workspace sso to office 365.
  
  Reply
Bianca
October 31, 2020 at 7:47 am

I did federation and everything works. if users log in by chrome with nine-dot in the app everything works. if they log in with credentials from the office portal or from the teams desktop app appears 404 error. I don’t know what to do to solve ..help me please🙏

Reply
1. Goldy Arora
  December 11, 2020 at 9:09 pm
  
  Hard to figure out this way, I would suggest to install a SAML parser –> trace the SAML request and response, and see where it gets stuck.
  
  Reply
Rino
October 23, 2020 at 5:49 pm

Hi Goldy, I have a problem with SSO, the string in powershell $ PassiveLogOnUri and $ ActiveLogOnUri:
“https://accounts.google.com/o/saml2?idpid=C010ug3p3”
if I try to log into portal.office.com I get the message
“404. That’s an error.The requested URL was not found on this server. That’s all we know.”
Help me please

Reply
Peter
October 21, 2020 at 1:03 pm

Hi, what is this error ?
name@school.edu.it, 45003, StatusCode: 403 : Forbidden : {
error : {
code : Authorization_RequestDenied
message : Insufficient privileges to complete the operation.
innerError : {
date : 2020-10-21T16:18:07
request-id : 49435902-d9eb-4cae-843c-03e475fbba3d
client-request-id : 49435902-d9eb-4cae-843c-03e475fbba3d
}
}
}
Tanks

Reply
1. Goldy Arora
  December 11, 2020 at 9:19 pm
  
  whatever operation you are doing is not permitted as this user does not have required privileges.
  
  Reply
2. Clifton Parker
  June 28, 2023 at 7:29 am
  
  WEre you able to figure out this error?
  
  Reply
Christian Maak
October 16, 2020 at 2:40 am

Hi, I really liked your manual although I found it to late and followed a similar one on github.

Maybe you can help me anyway?
I have a problem with one user.
He was part of a test run with the goal to make sure that the autoprovisioning part would work.
So I added him to google group and made the group the sync filter or sync scope (or whatever it is called).
It worked. he appeard in the AAD.
Then I deleted him in from AAD.
Then I added more users to the google group (him still being a member of the group).
But the user from the test run did not appear again in the AAD.
So I removed him from the google group.
Then at least I got a sync error after a view hours saying

user@somedomain.com, 45003, StatusCode: 404 : Not Found : {
error : {
code : Request_ResourceNotFound
message : Resource [some ID]’ does not exist or one of its queried reference-property objects are not present.
innerError : {
date : 2020-10-14T13:02:20
request-id : [some other ID]
client-request-id : [some other ID]
}
}
}

So I added the user to the google group again hoping he would get provisioned again – but even after a workday he did not appear in the AAD and there was no new entry in the Google Workspace audit log.
So I tried adding him using the invite process in the AAD, but I can’t invite him because my domain is verified.
Is there any way to solve this?

Reply
Massimo Baronti
October 12, 2020 at 4:54 pm

Hello Goldy.
I’m following your guide “Gsuite to Microsoft365 SSO & provisioning”.
I have two questions.
1) The scenario is as follows: our school has a domain for GSuite “@ schoolname.education” and the microsoft subdomain “@ schoolname.onmicrosoft.com”. Can I federate the two domains or I need to purchase another domain to be configured as default on microsoft 365?
2) I created users on microsoft365 and then deleted them. Is imutableID activated?
On powershell I got the csv file (As you can see the immutableID field is empty):
————————-
“UserPrincipalName”, “ImmutableId”, “WhenCreated”, “LastDirSyncTime”
“admin@icbientinabuti.onmicrosoft.com” ,, “24/09/2020 17:12:33”,
———————————-

Regards,

Reply
1. Goldy Arora
  December 11, 2020 at 9:32 pm
  
  1. Yes, you would need your own domain, you do not have ownership on … onmicrosoft.com and it cant be used for federation.
  
  2. It should not, try creating that user again.
  
  Reply
Andrea Lombardini
October 6, 2020 at 3:36 pm

Thank you a lot.
Really excellent guide.
I found a little error when i tryed to change the federation params by PowerShell command:

Set-MsolDomainFederationSettings -DomainName $domainName -Authentication $Authentication -FederationBrandName $FederationBrandName -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PassiveLogOnUri $PassiveLogOnUri -LogOffUri $LogOffUri -SigningCertificate $SigningCertificate -PreferredAuthenticationProtocol SAMLP

the answer was:
Set-MsolDomainFederationSettings : Impossibile trovare un parametro corrispondente al nome ‘Authentication’.
In riga:1 car:58

So I deleted the Authentication param and all went OK. In this way:

Set-MsolDomainFederationSettings -DomainName $domainName -FederationBrandName $FederationBrandName -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PassiveLogOnUri $PassiveLogOnUri -LogOffUri $LogOffUri -SigningCertificate $SigningCertificate -PreferredAuthenticationProtocol SAMLP

hope this can help.
Cheers from Italy,
Andrea

Reply
1. Goldy Arora
  December 11, 2020 at 9:35 pm
  
  thank you, ideally, it should have worked, but not sure what went wrong, thank you for the update.
  
  Reply
Prasad
October 4, 2020 at 11:27 pm

Thank you so much for this detailed article. You are a life saver! We have a Google Workspace for Education and recently received licenses of Microsoft 365 for Education as well. I am now able to provision users from Google Workspace to Microsoft 365 and use SSO.

Only comment is that until I configured the auto provisioning, testing the SSO was unsuccessful. I kept getting the ‘AADSTS51004 user does not exist in the directory’ error. However, after configuring the auto provisioning and waiting for a while for the synchronization, it is working well.

Thank you once again!

Reply
1. Goldy Arora
  December 11, 2020 at 9:38 pm
  
  your very welcome, glad it could help you configure google workspace sso to office 365.
  
  Reason behind the error you saw is, that when you created these users via google, their email became their immutableId, and it worked fine, however if you create users directly in Office 365 / Ad sync, then you would first need to ensure immutableId = user’s email address.
  
  Reply
  1. IT Support
    August 24, 2021 at 2:29 pm
    
    Hello,
    
    Thank you so much for your generous sharing.
    
    I have the same directory error. Which step should I start from? Do I need to redo the steps of running the variables in the PowerShell?
    
    Reply
2. Paul
  December 3, 2021 at 11:13 am
  
  Also many thanks from me Goldy – your tutorial filled in lots of gaps for me!
  I’ve also had the same ‘user does not exist in the directory’ error, but although I haven’t yet enabled SSO for all users (just staff, not students), I did set the immutableIds to equal the usernames on all users. Will enabling provisioning for all users fix this issue, or is it some other cause in this case, given that the Ids are already matching?
  
  Many thanks again!
  Paul
  
  Reply
Raj K
September 30, 2020 at 12:57 pm

Hi, I posted a comment yesterday regarding the error that I am receiving after setting up SSO between GSuite account and Office 365/MS Teams app.

AADSTS50107: The requested federation realm object ‘https://accounts.google.com/o/saml2?idpid=’ does not exist.

That comment is not appearing here yet. But I wanted to share how I resolved the error.

I had already made sure immutableId and Primary Email are the same – Thanks to Goldy for all Powershell scripts provided here. I also confirmed that certificate from Google has been installed in Azure AD via Powershell

Please note that slight difference between the URLs to use for $IssuerUri and $PassiveLogOnUri/$ActiveLogOnUri. This actually got me. Once I corrected that, then everything worked perfectly.

o/saml2?idpid= and o/saml2/idp?idpid=

Thanks Goldy for the guide. It helped me in great deal.

Reply
1. Goldy Arora
  December 11, 2020 at 9:40 pm
  
  Appreciate your update Raj, it would help others here, thank you.
  
  Reply
linda
September 29, 2020 at 12:37 pm

Hi Goldy,
thank your work and your excellent guide.
When I’m testing my SSO (Google/Identity Provider Initiated) everything works well, after I’ve changed my Immutableid in Powershell as you recommended.
Instead, when I’m testing my SSO (Microsoft 365/Service provider Initiate) I see the message
“Taking you to your organization’s sign-in page” and, after few second, a new page with tis error
“Google -null. That’s an error.
Error parsing the request, No SAML message present in request That’s all we know”
I contacted Microsoft support, but they told me that the problem is in Gsuite…
What can I do?
Thank you very much
Linda

Reply
1. Goldy Arora
  December 11, 2020 at 9:42 pm
  
  Hi Linda – hard to figure it out this way, I would recommend you to install a SAML chrome extension, and parse the SAML request/response, it should help you troubleshoot.
  
  Reply
Raj K
September 29, 2020 at 6:38 am

Hi Goldy – Great article. It helped to configure MS Teams with Google Authentication. Thank you so much for that.

But, in the step to test the SSO or when I tried to login Office 365 or MS Teams,
I am getting the error
AADSTS50107: The requested federation realm object ‘https://accounts.google.com/o/saml2?idpid=……… does not exist.
Please advise.
When I tried to login Office 365 or MS Teams, it correctly redirected me to organization login page. After entering login and password information, I get the above error. I checked and confirm the uri information is correct.
I am not sure if I am missing any other configurations. Or Does it take a while to propagate the changes to all users?

Reply
1. Raj K
  September 29, 2020 at 6:39 am
  
  I see that others had similar problem but not sure if they resolved the issue and how.
  
  Reply
Vittorio
September 23, 2020 at 2:50 pm

At the step:
“You would need to disable Directory Sync to be able to change ImmutableId, you can do it with following PowerShell command :
Set-MsolDirSyncEnabled -EnableDirSync $false

you disable the dir sync.
After the config process end, we must enable it again ?

Reply
1. Goldy Arora
  December 11, 2020 at 9:47 pm
  
  You should not if you would be using Google to provision the users too.
  if you plan to keep using AAD, then you would need to either keep dealing with changing of immutableIds to email address OR rather provide the immutableId when sending SAML response from google (e.g create custom attribute in google and populate it with immutableId, and send this in saml response).
  
  Reply
Stuart Burns
August 30, 2020 at 6:43 am

Hi Goldy,
Super useful tutorial!
When I run Get-MSolDomainFederationSettings -DomainName mydomain.com | Format-List * to check the federated settings, I do not the screen you have identified nor does it return an error, it simply accepts the command and then present the PS> cursor ready to take the next command. Any thoughts? I have been able to provision users into Office365 from GSuite, however when I try to log in using my GSuite credentials the GSuite account password is not recognised.
Thanks for any advice, Stuart

Reply
1. Goldy Arora
  December 11, 2020 at 10:04 pm
  
  your welcome Stuart, am sorry, am not sure why the powershell command doesn’t show you that information.
  
  Reply
Anamika
August 23, 2020 at 8:40 am

Hi Goldy,
Need to clarify if you have different domain in Azure AD (@abc.com (need to federate with gsuite sso)and different(@xyz.com) Gusite, which matching attribute should be taken care to auto proviso the user from gusite to Azure AD for SSO. (reason I am worried about existing user of AZure AD as need to change Immutable ID)

Reply
1. Goldy Arora
  December 11, 2020 at 10:11 pm
  
  onpremiseimmutableId attribute should be set to username in google provision setting, i think i have added a screenshot of it in this article.
  
  Reply
Juan Jacome
August 19, 2020 at 11:02 pm

Hello, I really appreciate what you have done with this tutorial, thank you so much, please if is possible for you helping me with this error after adding this command.

Set-MsolDomainFederationSettings -DomainName $domainName -Authentication $Authentication -FederationBrandName $FederationBrandName -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PassiveLogOnUri $PassiveLogOnUri -LogOffUri $LogOffUri -SigningCertificate $SigningCertificate -PreferredAuthenticationProtocol SAMLP
Set-MsolDomainFederationSettings : A parameter cannot be found that matches parameter name ‘Authentication’.
At line:1 char:58
+ … ainFederationSettings -DomainName $domainName -Authentication $Authen …
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Set-MsolDomainFederationSettings], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.Online.Administration.Automation.SetDomainFederationSettings

Please I don’t know what to do from here, and additionally when I write this command Get-MSolDomainFederationSettings -DomainName id.goldyarora.com | Format-List *(I use my domain) but nothing shows.
Thank you so much

Reply
1. Juan Jacome
  August 20, 2020 at 12:00 am
  
  Sorry I added the wrong error message, this is the one.
  Set-MsolDomainAuthentication : You cannot remove this domain as the default domain without replacing it with another
  default domain. Use the the Set-MsolDomain cmdlet to set another domain as the default domain before you delete this
  domain.
  At line:1 char:1
  + Set-MsolDomainAuthentication -DomainName $domainName -Authentication …
  + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  + CategoryInfo : OperationStopped: (:) [Set-MsolDomainAuthentication], MicrosoftOnlineException
  + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.DefaultDomainUnsetException,Microsoft.Online.
  Administration.Automation.SetDomainAuthentication
  
  Thanks
  
  Reply
  1. Goldy Arora
    December 11, 2020 at 10:15 pm
    
    thats right, you can federate to onmicrosoft domain as you don’t own it, add your own domain, please look at the system requirements section in this article.
    
    Reply
Michael
August 19, 2020 at 1:07 am

Hello,

I am getting the following error.

Is there something I’m missing?

PS C:\WINDOWS\system32> Set-MsolDomainAuthentication -DomainName $domainName -Authentication $Authentication -FederationBrandName $FederationBrandName -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PassiveLogOnUri $PassiveLogOnUri -LogOffUri $LogOffUri -SigningCertificate $SigningCertificate -PreferredAuthenticationProtocol SAMLP
Set-MsolDomainAuthentication : You cannot remove this domain as the default domain without replacing it with another
default domain. Use the the Set-MsolDomain cmdlet to set another domain as the default domain before you delete this
domain.
At line:1 char:1
+ Set-MsolDomainAuthentication -DomainName $domainName -Authentication …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Set-MsolDomainAuthentication], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.DefaultDomainUnsetException,Microsoft.Online.
Administration.Automation.SetDomainAuthentication

Reply
Joseph
August 12, 2020 at 7:58 am

Hi, I got this error after login with GSuite account and click on Office365 APP:

AADSTS50107: The requested federation realm object ‘https://accounts.google.com/o/saml2?idpid=C02XXXXXX’ does not exist.

How can I solved it? Thank you

Reply
1. Goldy Arora
  August 13, 2020 at 7:56 pm
  
  You should look at couple of things-:
  
  1. Check the immutableId of the user in concern, it should match the user’s primary email address.
  
  2. Ensure that the certificate has been installed from Google to Office 365 (PowerShell) correctly.
  
  Reply
Torben
August 4, 2020 at 3:31 am

Hi Goldy,

first let me say thank you very much for this detailed and helpful article, it helped us to complete the task of setting up SSO finally after struggling for a very long time! I highly appreciate your work!

Unfortunately we are still running into two issues.
1. When trying to authenticate via Powershell tools (eg Connect-AzAccount) to Azure via a federated GSuite Account, a windows opens in which we enter the user’s email and get forwarded to Google sign-in. After entering the email id (to Google sign-in), a javascript error is coming up (Row 0, Character 0, Error: Script error, Code: 0, URL: https://ssl.gstatic.com/accounts/static/_/js/k=gaia.gaiafe_signin.en_GB.NDip7jdsosI.O/am=DAEAAAAAAAAAAAAIJQ/d=1/ct=zgms/rs=ABkqax2W4vQiXsXmnqnIgR1x4YkH6EPDxA/m=signin,signin_challenge) and asks me whether to proceed with script execution yes/no. Clicking yes or no, i get asked for my password and MFA token, but i’m unable to finalize the authentication properly (MFA does not get approved, probably because of the script error). The window does not change any more, and does not close. Do you know what can be done to resolve this issue? While googling we found a couple of references to a local MS Teams issue (involving clearing local caches), but this has not resolved our problem. We have Chrome installed as the default browser on Win10.

2. We assigned a Office 365 license to a GSuite SSO user and are able to activate the local installation on a Windows 10 machine successfully. However, after some days, or after a reboot, we are getting a warning saying “There are issues with your account, please login again.” This works, but has to be done every day and is therefore annoying. Do you have any idea on this?

Again, thanks for all your great how-to’s, it’s greatly appreciated!

All the best Torben

Reply
1. Goldy Arora
  August 13, 2020 at 8:14 pm
  
  You’re welcome Torben.
  1. Try installing a SAML tracer chrome plugin and use to trace the saml request and response, this should help figure out, I slightly recall seeing this error but didn’t document what i did to fix it:(.
  
  2. Sorry, I don’t much idea on this 2nd one.
  
  Reply
keith
August 3, 2020 at 8:08 am

Hi Seem to have a problem everything works fine in the browser but some users require a full office install licence but when they try and log in all they get is a looks like we cant connect to one of our services right now please try again later HTTP 400 error accounts.google.com

Reply
1. Goldy Arora
  August 13, 2020 at 8:18 pm
  
  If you are getting the error only when authentication local clients via Google Workspace, then check modern authentication support for these clients, more info here https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online
  
  Reply
Lucas
July 26, 2020 at 3:38 am

ok, I solved all problem but not provisioning, I got this error in gsuite console:
Error during Office365 sync: 17007 error code

Reply
1. Goldy Arora
  July 30, 2020 at 7:28 pm
  
  I have not seen this error, but after googling it a bit, it seems related to granting access to Google to create users in Office 365, try providing the OAuth consent again.
  
  Reply
Lucas
July 25, 2020 at 6:50 am

I got this error afeter login to Google on https://gsuite.google.com/dashboard and click on Office365 APP:
AADSTS5000811: Unable to verify token signature. The signing key identifier does not match any valid registered keys.

Reply
1. Goldy Arora
  July 30, 2020 at 7:31 pm
  
  It indicates an issue with matching keys, please ensure you enter the key provided by Google exactly in Office 365 via PowerShell.
  
  Reply
Niek
July 24, 2020 at 9:04 am

Thank you very much! I got the link to your explanation from Microsoft Support (Adrian) and managed to get it up and running. Our school will be very happy to have automatic access to Office365 and Minecraft Education.
It’s a shame I cannot automatically assign licenses in O365 (for instance using OU or groups in Gsuite to choose the right license in O365), that would make it fully automated.

Reply
1. Goldy Arora
  July 30, 2020 at 7:40 pm
  
  Your very welcome, glad to hear Microsoft also reads my blog ;).
  
  Yeah, you are right, there doesn’t seem like an out of the box to assign licenses, you might be able to script it with following-:
  1. https://developers.google.com/admin-sdk/directory/v1/reference/users/watch
  2. https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/licensing-groups-assign
  
  Reply
  1. Vivek
    September 17, 2020 at 2:43 pm
    
    Hi ,
    First off great post.
    We are experimenting with this in our Org and are still in the concept phase.
    So wanted to see if the below is feaasibe:
    
    Could we use dynamic group membership:
    https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-create-rule
    
    And apply the group based licensing to assign license automatically.
    
    Reply
    1. Goldy Arora
      December 11, 2020 at 9:56 pm
      
      I think your question is about assigning licenses to Office 365 users via dynamic groups in Office 365 itself? if yes, then i have not tried it but it should work i think.
      
      Reply
SirMark
July 15, 2020 at 8:36 am

hi! If I already have user with @gsuitedomain in offce365 and manage it for a fake SSO creating manually user in Gsuite and Off365 with same username @gsuitedomain but different pwd, what’s happen if I change immutableID of off365 user @gsuitedomain ?

thanks!

Reply
1. Goldy Arora
  July 16, 2020 at 7:58 pm
  
  I didn’t understand your question, how would you create the user in Office 365 if you already have it with that email?
  if your question is about creating the user in Google Workspace with the same email that you have in Office 365, then it’ll not work right away, you would need to change the immutableId in Office 365 to match Google Workspace user’s email address (unless you want to go with other option that is to put current immutableId in Google Workspace as a custom attribute and then rather send this custom attribute as nameId in SAML response).
  
  Reply
  1. Sirmark
    July 25, 2020 at 5:22 am
    
    hi! I add gsuite domain in off365 only with TXT DNS record. When I create user in off365 I use @gsuitedomain also in off365 but different pwd, so I have:
    1. gsuite account @gsuitedomain
    2. off365 account @gsuitedomain with different pwd of 1.
    
    So I have a fake SSO.
    
    If I want use your real SSO procedure, what’s happen if I change immutableID of off365 user @gsuitedomain ?
    
    I hope to be more clear.
    ThankS
    
    Reply
    1. Goldy Arora
      July 30, 2020 at 7:35 pm
      
      You have two options here-:
      1. Take the immutable id of off365 user @gsuitedomain –> create a custom attribute in Google Workspace –> and put immutable id as its value –> send this attribute as SAML nameId value.
      OR
      2. Change the immutableId of off365 user @gsuitedomain to match user’s primary email address, if you do that, nothing will change on the front (e.g you can still login directly to off365 user @gsuitedomain as usual), however it’ll make your SSO setup and management easy.
      
      Reply
Thukral
July 10, 2020 at 1:31 am

In the step to test the SSO, I am getting the error
AADSTS50107: The requested federation realm object ‘https://accounts.google.com/o/saml2?idpid=……… does not exist Please advise

Reply
1. Goldy Arora
  July 12, 2020 at 2:00 pm
  
  It seems like a mismatch in the issuer Uri provided by Google, and the one entered in Office 365, please check and ensure they are exactly same.
  
  Reply
2. Joseph
  August 13, 2020 at 1:32 pm
  
  Did you solved it? I’ve the same error, any suggestion? Thank you.
  
  Reply
Suporte
July 9, 2020 at 6:40 pm

NICE tutorial!
Is there a way to automatically assign licenses to new synchronized users?

Reply
1. Goldy Arora
  July 12, 2020 at 2:03 pm
  
  It seems your question is, how can I assign licenses in Office 365 to the users created via Google Workspace?
  
  if yes, this Microsoft documentation should help https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/licensing-groups-assign
  
  Reply
Leonardo
July 9, 2020 at 3:13 am

This tutorial is exact what i looking for.
I administer a Google Suite of a faculty (eg faculty.com), now we are trying to associate Office 365 to our users.

We are using only the default domain in 365 (faculty.onmicrosoft.com)

I was following the tutorial and now i am stuck in this part (below)

* I dont understand the error, the domain name (faculty.com) must be set in office 365? How can i do this?

*Thank you for sharing your knowledge

PS C:\Windows\system32> Set-MsolDomainAuthentication -DomainName $domainName -Authentication $Authentication -FederationBrandName $FederationBrandName -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PassiveLogOnUri $PassiveLogOnUri -LogOffUri $LogOffUri -SigningCertificate $SigningCertificate -PreferredAuthenticationProtocol SAMLP

Set-MsolDomainAuthentication : This domain does not exist. Check the name and try again.
No linha:1 caractere:1
+ Set-MsolDomainAuthentication -DomainName $domainName -Authentication …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Set-MsolDomainAuthentication], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.DomainNotFoundException,Microsoft.Online.Administration.Automation.SetDomainAuthentication

Reply
1. Goldy Arora
  July 12, 2020 at 2:17 pm
  
  You’re welcome.
  
  I have this requirement listed in the system requirements section, you do not own/control faculty.onmicrosoft.com, it is Microsoft’s domain, hence you can not setup federation on it.
  
  You would need to add your domain (e.g faculty.com) in Office 365, you would find Microsoft’s documentation on adding domain under the system requirements section in this post.
  
  Reply
Carlos
June 23, 2020 at 10:23 pm

How can I federate (powershell) if I don’t have a local server.

Reply
1. Goldy Arora
  July 1, 2020 at 1:12 pm
  
  Unfortunately, like Google Workspace, Office 365 does not allow setting up federation within the user interface, so you would have to go with powershell.
  
  You don’t need any specific server for this thought, any regular windows machine (e.g windows 10, even virtual machine) which can run powershell should be enough.
  
  Reply
Carlos
June 22, 2020 at 2:18 am

Dear,
First of all thank your work and the excellent guide.
I have a question, that nobody in Microsoft support has been able to answer.
I am managing GSuite for education and registered the domain in Office365, I am trying to use the GSuite credentials to authenticate in Office365.
But the step of where you have to use Powershell I cannot do it, because there is no local server, everything is in the cloud.
I have tried to use Windows 10 PowerShell but it does not recognize the commands.
I don’t know what I’m doing wrong or how else to integrate SSO into Office365 with GSuite.

Reply
1. Goldy Arora
  July 1, 2020 at 1:17 pm
  
  Unfortunately, like Google Workspace, Office 365 does not allow setting up federation within the user interface, so you would have to go with powershell.
  
  I would recommend you to google some help on how to install powershell and its associated modules to interact with Office 365.
  
  Reply
Edömér Csúry
May 26, 2020 at 6:11 pm

I just love you man, have been searching for an understandable guide a few days now and you sir helped me with this a lot to complete my contract. Detailed instruction and it worked on the first try! You won a fan today!!! Cheers to you and thank you!!!

Reply
1. Goldy Arora
  June 8, 2020 at 3:59 pm
  
  haha, your very welcome, glad you find this Google Workspace to Office 365 SSO guide helpful.
  
  Reply
Michael Kerry
May 20, 2020 at 10:37 am

Hi,
I want to disable federation for temporarily (for troubleshooting). I can see powershell command for that.
But how will I go back to federation, without any issue.

Reply
1. Goldy Arora
  June 8, 2020 at 4:35 pm
  
  You can turn off SSO by running the command Set-MsolDomainAuthentication -DomainName yourdomainname.com -Authentication managed
  
  however, if you need to federate after this, you would need to re-do the process (e.g create powershell variables, run the federation command).
  
  Reply
A R Ansari
May 19, 2020 at 11:27 pm

Hi Sir,
G suite identity service will with Microsoft Tenant domain i.e abc.onmicrosoft.com . or we need own domain instead of Microsoft.

Reply
1. Goldy Arora
  June 8, 2020 at 4:36 pm
  
  You can not federate .onmicrosoft.com domain, add your own custom domain for federation.
  
  Reply
David Guidry
May 12, 2020 at 4:44 pm

I went through the setup steps. When I try to authenticate my test user, it redirects to Google, but when I get to the Microsoft page, I get: “AADSTS5000811: Unable to verify token signature. The signing key identifier does not match any valid registered keys.” I checked the signing certificate with Get-MsolDomainFederationSettings. It seems to match what I have in the metadata file. Any suggestions?

Reply
1. Goldy Arora
  May 13, 2020 at 11:41 am
  
  Please ensure there is not space in the cert which you copied from Google, otherwise PowerShell will take it but later you would see an error during user authentication.
  
  Reply
David Guidry
May 12, 2020 at 1:26 pm

You document which Google licensing I need in order to set up SSO, but not the Microsoft license. I’m working with Microsoft 365 Apps for Business. Do you know if I’m still able to set up SSO with this Microsoft licensing level?

Reply
1. Goldy Arora
  May 13, 2020 at 11:40 am
  
  I tested it Office 365 Basic plan (which is the starting tier), so i assume it’ll work on all of their plans.
  
  Reply
David Guidry
May 11, 2020 at 8:31 pm

If I’m in a non-federated domain, I’m still unclear on what changes I need to make to the O365 user accounts. Do I change the UPN and immutable ID to the corresponding user’s GSuite email address?

Reply
1. Goldy Arora
  May 11, 2020 at 8:35 pm
  
  1. I would suggest you to first do a quick look up at your Office 365 users’ immutableId via the provided PowerShell script in this post.
  
  2. If your immutableId is not equal to your Google Workspace users’ primary email address, then you should either change it to match Google Workspace email OR create a custom attribute in Google Workspace –> populate it with your Office 365 ImmutableId and then use to send this in SAML response.
  
  Reply
  1. David Guidry
    May 11, 2020 at 8:49 pm
    
    Your article states that in a non-federated scenario the immutable Id should be blank. If that’s the case, I can set it to the user’s corresponding GSuite address, and I don’t have to do anything to the UPN. Am I understanding correctly?
    
    Reply
    1. Goldy Arora
      May 11, 2020 at 8:52 pm
      
      Yes, that is correct.
      
      Reply

1. Topic Overview

2. System Requirements

3. Office 365 ImmutableId

4. Google Workspace to Office 365 SSO

5. Google to Office Provisioning

6. FAQs

Google Workspace to Office 365 SSO & Provisioning

System Requirements

Google Workspace to Office 365 SSO : System Requirements

List of Google subscriptions with SSO & Provisioning availability

Undestanding Office 365 ImmutableId

You have two options to deal with it :

Google Workspace to Office 365 SSO Setup

Setup Office 365 as Service Provider in Google Workspace

Create Powershell variables for Office 365 SSO

Provide Office 365 SAML application access to our Google users

Testing our SSO (Google / Identity Provider Initiated)

Testing our SSO (Office 365 / Service provider Initiated)

Google Workspace to Office 365 Provisioning

FAQ

Most frequent questions and answers about Google Workspace to Office 365 SSO and Provisioning.

RECOMMENDED READING

Definitive Guide to Okta & Google Integration

Definitive Guide to Google Conflicting Accounts

Securely login to any app with Google Workspace Password Vaulted Apps

138 thoughts on “Google Workspace to Office 365 SSO and Provisioning Guide”

Leave a Comment Cancel Reply

1. Topic Overview

2. System Requirements

3. Office 365 ImmutableId

4. Google Workspace to Office 365 SSO

5. Google to Office Provisioning

6. FAQs

Google Workspace to Office 365 SSO & Provisioning

System Requirements

Google Workspace to Office 365 SSO : System Requirements

List of Google subscriptions with SSO & Provisioning availability

Undestanding Office 365 ImmutableId

You have two options to deal with it :

Google Workspace to Office 365 SSO Setup

Setup Office 365 as Service Provider in Google Workspace

Create Powershell variables for Office 365 SSO

Provide Office 365 SAML application access to our Google users

Testing our SSO (Google / Identity Provider Initiated)

Testing our SSO (Office 365 / Service provider Initiated)

Google Workspace to Office 365 Provisioning

FAQ

Most frequent questions and answers about Google Workspace to Office 365 SSO and Provisioning.

RECOMMENDED READING

Definitive Guide to Okta & Google Integration

Definitive Guide to Google Conflicting Accounts

Securely login to any app with Google Workspace Password Vaulted Apps

138 thoughts on “Google Workspace to Office 365 SSO and Provisioning Guide”

Leave a Comment Cancel Reply

Start typing and press enter to search