Single Sign-on Microsoft 365 (Azure AD) via Google IdP
Overview
The purpose of this post is to provide instructions for configuring a Google identity provider with Microsoft 365 (Azure AD) as the relying party.
The overall setup instruction can be found below Google official link. In the following parts of this post, we will call this documentation “Google IdP doc”.
Set up SSO via SAML for Microsoft Office 365
This post will not exactly follow the steps of the Google IdP doc, and some details will be added to make it more understandable.
1. Set up the Domain Federation in AAD
1.1 Before We Go
From an AAD perspective, we are transitioning our original managed domain to a federated domain and have now become the relying party for Google. Our trust is established through SAML 2.0, and for future reference, we will refer to the corresponding documentation as the “Azure AD SAML doc”.
Azure AD Connect: Use a SAML 2.0 Identity Provider for Single Sign On – Azure – Microsoft Entra | Microsoft Learn
In addition, we can locate the documentation that outlines the actual setup process between Google Workspace and Azure AD using the following resource.
Configure federation between Google Workspace and Azure AD – Windows Education | Microsoft Learn
Although the above documentation still recommends using the MSOL module, it is likely to be deprecated in the future and is no longer supported in PowerShell 7 and later versions. To perform our Google federation setup, we will instead be using the MgGraph module.
1.2 Azure AD MgGraph Module
In the Azure AD SAML 2.0 documentation, the following MSOL module command was used:
Set-MsolDomainAuthentication
We found out the equivalent MgGraph module command:
New-MgDomainFederationConfiguration
Reference: Find Azure AD and MSOnline cmdlets in Microsoft Graph PowerShell | Microsoft Learn
Given that we are utilizing the MGGraph module for configuration this time, focusing on configuring domain federation settings, we will employ the following command to establish a connection with MgGraph:
Connect-MgGraph -Scopes “Domain.ReadWrite.All”, “Directory.AccessAsUser.All”
* Originally, domain.readwrite.all should be sufficient, but I recall that adding just this wasn’t enough before. To be on the safe side, let’s also include directory.AccessAsUser.all.
1.3 Set up the Domain Federation
As combined the MgGraph module and the sample command on the Azure AD SAML doc, you can perform the federation domain setup directly by using following script:
$DomainName = "your domain name" $FederationBrandName = "Google SAML 2.0 IDP" $PassiveLogOnUrl = "https://accounts.google.com/o/saml2/" $ActiveLogOnUri = "https://accounts.google.com/o/saml2/" $LogOffUri = "https://www.google.com/accounts/Logout" $IssuerURI = "https://accounts.google.com/o/saml2" $SigningCertificate = "google token singing cert" $PreferredAuthenticationProtocol = "saml" New-MgDomainFederationConfiguration ` -DomainId $DomainName ` -DisplayName $FederationBrandName ` -PassiveSignInUri $PassiveLogOnUrl ` -ActiveSignInUri $ActiveLogOnUri ` -SigningCertificate $SigningCertificate ` -IssuerUri $IssuerURI ` -SignOutUri $LogOffUri ` -PreferredAuthenticationProtocol $PreferredAuthenticationProtocol ` -FederatedIdpMfaBehavior "rejectMfaByFederatedIdp"
Those pre-defined values could be found in the previous Google IdP doc:
1.4 Things to Know
1. The “PreferredAuthenticationProtocol” parameter has fixed values:
Reference: Update internalDomainFederation – Microsoft Graph v1.0 | Microsoft Learn
2. Google is using SAMLP – SAML 2.0 as preferred authentication protocol, the corresponding MgGraph value would be saml.
3. The “FederatedIdpMfaBehavior” parameter is mandatory, just keep the same value that provided in the script.
4. The command “New-MgDomainFederationConfiguration” is more likely helps us create the new federation profile, and the setup for actual domain federation has not finished yet. Please follow the next the section 1.5 to complete update the federation profile ID to the domain.
1.5 Update our Domain with the Federation Profile
$DomainName = "your domain name" $FederationID = "your federation ID" Update-MgDomainFederationConfiguration ` -DomainId $DomainName ` -InternalDomainFederationId $FederationID
If there’s nothing prompts, the federation setup should be successful.
1.6 Verify our Federation Settings
You can check the federation configuration by using following command:
Get-MgDomainFederationConfiguration -DomainId $DomainName | fl
The configuration will need some time to take effect. And once the settings applied in AAD, when you type the Google federated domain that we just configured in Microsoft Sign-in page. The home realm discovery will start and redirect you to the google for authentication.
2. User Matching/Provisioning
Azure AD is using the attribute ImmutableID as the source anchor to link the users between IdP and SP. Additionally, the Google IdP doc has already provided us detailed steps to perform the user matching or auto provisioning. I used the steps that provided by Google, and created my own Azure AD ImmutableID attribute:
3. Add the M365 SSO app in your Google Workspace
3.1 Add the Microsoft Office 365 App
When Google sends SAML response, the response token will not directly convert the custom attribute we configured into a NameID and submit it to AAD. We actually do this through the next section by Google Driecotry attribute mapping.
Please follow the Google IdP doc and add the Microsoft Office 365 App for your Google Workspace:
3.2 Configure the SAML Attribute Mapping
While the following description presents only one approach (changed the ImmutableID for the AAD managed user), it is important to note that there may be discrepancies between the proposed idea and the actual implementation.
By default, response will be accepted by our relying party M365 (Azure AD), and the mapping attribute in AAD would be Azure AD user ImmutableID.
In Google side, user is called liangzai@mail.ruianding.com. The source anchor will appear in SAML response NameID claim.
Let’s check the SAML response that sent by Google:
We can see the NameID of the login user is liangzai@mail.ruianding.com:
In AAD side, user global1@rayaki.onmicrosoft.com was set up as the mapped user on Google side. All we need is to configure the ImmutableID:
In order words, the Google User liangzai@mail.ruianding.com is mapped to global1@rayaki.onmicrosoft.com via the source anchor ImmutableID.
AAD will match the NameID claim in SAML token and the ImmutableIDs of users in AAD. We can see the corresponding user global1@rayaki.onmicrosoft.com was successfully signed in.
