Entra ID federation with Google Workspace
Entra ID federation with Google Workspace
Google Workspace federation allows you to manage user identities in your Entra ID tenants while authenticating these users through Google. This can be beneficial if your company wants to use a single source of identities across different cloud platforms.
This article covers the scenario where your domain is already added and verified in Entra ID.
Requirements
To use Google Workspace federation, you need to ensure that your federated users are created in the Entra ID directory. This can be done through various methods such as auto-provisioning or using the Graph API.
Keep in mind, that the out-of-the box federation for Google only works for gmail.com personal accounts. In order to federate with work accounts managed in Google Workspace, you have to configure SAML IDP federation.
Configuring SAML Federation on Google Workspace side
To configure SAML federation in Google Workspace, follow these steps:
1. Create a Web Application in Google Admin Panel:
Navigate to https://admin.google.com/
Go to Apps -> Web and mobile apps
Click Add app -> Search for apps
Search for “Microsoft Office 365” and install it.
2. Download Metadata:
After installing the app, go to the app details and download the metadata.
Save the IdP metadata file (GoogleIDPMetadata.xml) as it will be used to set up Microsoft Entra ID later.
3. Enable Auto-Provisioning:
Enable auto-provisioning inside the “Microsoft Office 365” app.
4. Configure Service Provider Details:
On the Service Provider details page:
Select the option Signed response.
Verify that the Name ID format is set to PERSISTENT.
Under SAML attribute mapping, select Basic Information and map Primary email to IDPEmail.
5. Enable the App for Users in Google Workspace:
Go to Apps -> Web and mobile apps -> Microsoft Office 365 -> User access.
Select ON for everyone and save the changes.
Adding Federation for SAML Provider in Entra ID
Using the IdP metadata XML file downloaded from Google Workspace, modify the $DomainName variable in the following script to match your environment, and then run it in a PowerShell session:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
Install-Module Microsoft.Graph -Scope CurrentUser
Import-Module Microsoft.Graph
$domainId = “<your domain name>”
$xml = [Xml](Get-Content GoogleIDPMetadata.xml)
$cert = -join $xml.EntityDescriptor.IDPSSODescriptor.KeyDescriptor.KeyInfo.X509Data.X509Certificate.Split()
$issuerUri = $xml.EntityDescriptor.entityID
$signinUri = $xml.EntityDescriptor.IDPSSODescriptor.SingleSignOnService | ? { $_.Binding.Contains(‘Redirect’) } | % { $_.Location }
$signoutUri = “https://accounts.google.com/logout”
$displayName = “Google Workspace Identity”
Connect-MGGraph -Scopes “Domain.ReadWrite.All”, “Directory.AccessAsUser.All”
$domainAuthParams = @{
DomainId = $domainId
IssuerUri = $issuerUri
DisplayName = $displayName
ActiveSignInUri = $signinUri
PassiveSignInUri = $signinUri
SignOutUri = $signoutUri
SigningCertificate = $cert
PreferredAuthenticationProtocol = “saml”
federatedIdpMfaBehavior = “acceptIfMfaDoneByFederatedIdp”
}
New-MgDomainFederationConfiguration @domainAuthParams
To verify that the configuration is correct, you can use the following PowerShell command:
Get-MgDomainFederationConfiguration -DomainId $domainId |fl
Test the federation
To test the federation, navigate to https://portal.azure.com and sign in with a Google Workspace account:
As username, use the email as defined in Google Workspace. The user is redirected to Google Workspace to sign in.
After Google Workspace authentication, the user is redirected back to Microsoft Entra ID and signed in.
Troubleshooting
If you configured federation after users were created in Entra ID, it is possible that users will get an error AADSTS51004
AADSTS51004: The user account XXX does not exist in the YYY directory. To sign into this application, the account must be added to the directory.
This error is most likely caused by property ImmutableId being incorrect.
For Google Workspace federation ImmutableId has to be set as a primary email adress of the user.
Follow these steps to update the ImmutableID:
Convert the federated user to a cloud-only user (update the UPN to a non-federated domain)
Update the ImmutableId
Convert the user back to a federated user
Here’s a PowerShell example to update the ImmutableId for a federated user:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
Install-Module Microsoft.Graph -Scope CurrentUser
Import-Module Microsoft.Graph
Connect-MgGraph -Scopes ‘User.Read.All’, ‘User.ReadWrite.All’
#1. Convert the user from federated to cloud-only
Update-MgUser -UserId test@example.com -UserPrincipalName test@example.onmicrosoft.com
#2. Convert the user back to federated, while setting the immutableId
Update-MgUser -UserId test@example.onmicrosoft.com -UserPrincipalName test@example.com -OnPremisesImmutableId ‘test@example.com’
Conclusion
In summary, Entra ID federation with Google Workspace allows seamless user identity management and authentication across different cloud platforms.
Hit me up in comments if this worked for you!
Microsoft Tech Community – Latest Blogs –Read More