This document shows you how you can extend Azure Active Directory (Azure AD) user provisioning and single sign-on to enable single sign-on (SSO) for Azure AD B2B collaboration users.
The document assumes that you use Microsoft Office 365 or Azure AD in your organization and that you've already configured Azure AD user provisioning and single sign-on as in the following diagram.
In this diagram, users from external identity providers (IdPs) and from other Azure AD tenants sign on to the Azure AD tenant through B2B sign-on.
Objectives
- Extend the Azure AD user provisioning configuration to cover Azure B2B guest users.
- Extend the Azure AD SSO configuration to cover Azure B2B guest users.
- Configure Cloud Identity to limit session lengths for guest users.
Before you begin
Make sure you've set up Azure AD user provisioning and single sign-on.
Azure B2B guest users
Azure AD lets you invite external users as guests to your Azure AD tenant. When you invite an external user, Azure AD creates a guest user account in your tenant. These guest user accounts differ from regular Azure AD user accounts in multiple ways:
- Guest users don't have a password. To sign on, guest users are automatically redirected to their home tenant or to the external identity provider (IdP) that they've been invited from.
- The user principal name (UPN) of the guest user account uses a prefix
derived from the invitee's email address, combined with the tenant's
initial domain—for example:
prefix#EXT#@tenant.onmicrosoft.com
. - If you invite a user from a different Azure AD tenant and the user is later deleted in its home tenant, then the guest user account remains active in your Azure AD tenant.
These differences affect the way you configure user provisioning and single sign-on:
Because
onmicrosoft.com
is a Microsoft-owned DNS domain, you cannot addtenant.onmicrosoft.com
as a secondary domain to your Cloud Identity or Google Workspace account. This caveat means that you cannot use the guest user's UPN as primary email address when provisioning the user to Cloud Identity or Google Workspace.To provision guest users to Cloud Identity or Google Workspace, you must set up a mapping that transforms the guest user's UPN into a domain used by your Cloud Identity or Google Workspace account.
In this document, you set up a UPN mapping as indicated in the following table.
Original UPN in Azure AD Primary email address in Cloud Identity or Google Workspace Regular user alice@example.com
alice@example.com
Azure AD guest charlie@altostrat.com
charlie_altostrat.com@example.com
External guest user@hotmail.com
user_hotmail.com@example.com
When a user is deleted in its home tenant, Azure AD won't suspend the corresponding user in Cloud Identity or Google Workspace. This poses a security risk: Although any attempts to use single sign-on will fail for such a user, existing browser sessions and refresh tokens (including those used by the Google Cloud CLI) might remain active for days or weeks, allowing the user to continue accessing resources.
Using the approach presented in this document, you can mitigate this risk by provisioning guest users to a dedicated organizational unit in Cloud Identity or Google Workspace, and by applying a policy that restricts the session length to 8 hours. The policy ensures that browser sessions and existing refresh tokens are invalidated at most 8 hours after the user has been deleted in its home tenant, effectively revoking all access. The user in Cloud Identity or Google Workspace stays active, however, until you delete the guest user from your Azure AD account.
Preparing your Cloud Identity or Google Workspace account
Create an organizational unit in your Cloud Identity or Google Workspace account that all guest users will be provisioned to.
- In the Admin Console, go to Organizational units and click add.
- Enter the following settings:
- Name of organizational unit:
guests
- Description:
Azure B2B guest users
- Name of organizational unit:
- Click Create.
Apply a policy to the organizational unit that limits the session length to 8 hours. The session length not only applies to browser sessions, but also restricts the lifetime of OAuth refresh tokens.
- In the Admin Console, go to Security > Google Cloud session control.
- Select the organizational unit guests.
- Select Set session duration and select 8 hours. This duration reflects the maximum amount of time a guest user might still be able to access Google Cloud resources after it has been suspended in Azure AD.
- Set re-authentication method to Password. This setting ensures that users have to re-authenticate by using Azure AD after a session has expired.
- Click Override.
Configure Azure AD provisioning
You are now ready to adjust your existing Azure AD configuration to support provisioning of B2B guest users.
- In the Azure portal, go to Azure Active Directory > Enterprise applications.
- Select the enterprise application Google Cloud (Provisioning), which you use for user provisioning.
- Click Manage > Provisioning.
- Click Edit provisioning.
- Under Mappings, click Provision Azure Active Directory Users.
- Select the row userPrincipalName.
In the Edit Attribute dialog, apply the following changes:
- Mapping type: Change from Direct to Expression.
Expression:
Replace([originalUserPrincipalName], "#EXT#@TENANT_DOMAIN", , , "@PRIMARY_DOMAIN", , )
Replace the following:
TENANT_DOMAIN
: the.onmicrosoft.com
domain of your Azure AD tenant, such astenant.onmicrosoft.com
.PRIMARY_DOMAIN
: the primary domain name used by your Cloud Identity or Google Workspace account, such asexample.org
.
Click OK.
Select Add new mapping.
In the Edit Attribute dialog, configure the following settings:
- Mapping type: Expression.
Expression:
IIF(Instr([originalUserPrincipalName], "#EXT#", , )="0", "/", "/guests")
Target attribute: OrgUnitPath
Click OK.
Click Save.
Click Yes to confirm that saving changes will result in users and groups being resynchronized.
Close the Attribute Mapping dialog.
Configuring Azure AD for single sign-on
To ensure that guest users can authenticate by using single sign-on, you now extend your existing Azure AD configuration to enable single sign-on for guests:
- In the Azure portal, go to Azure Active Directory > Enterprise applications.
- Select the Google Cloud enterprise application, which you use for single sign-on.
- Click Manage > Single sign-on.
- On the ballot screen, click the SAML card.
- On the User Attributes & Claims card, click Edit.
- Select the row labeled Unique User Identifier (Name ID).
- Under Choose name identifier format, select Unspecified. This
ensures that Cloud Identity or Google Workspace accepts a
NameID
claim even if ithe claimt doesn't contain a domain name. - Select Claim conditions.
- Add a conditional claim for external guests:
- User type: External guests
- Source: Transformation
- Transformation: Select Extract() and Before matching
- Parameter 1 (Input): user.userprincipalname
- Value:
#EXT#@TENANT_DOMAIN
. ReplaceTENANT_DOMAIN
with the.onmicrosoft.com
domain of your Azure AD tenant, for exampletenant.onmicrosoft.com
.
- Click Add.
Add a conditional claim for Azure AD guests from different tenants:
- User type: AAD guests
- Source: Transformation
- Transformation: Select Extract() and Before matching
Parameter 1 (Input): user.localuserprincipalname
Value:
#EXT#@TENANT_DOMAIN
. ReplaceTENANT_DOMAIN
with the.onmicrosoft.com
domain of your Azure AD tenant, for exampletenant.onmicrosoft.com
.
Click Add.
Add a conditional claim for regular Azure AD users:
- User type: Members
- Source: Attribute
- Value: user.userprincipalname
Click Save.
On the User Attributes & Claims screen, select Add new claim.
Enter the following settings:
- Name:
_upn
- Source: Attribute
- Source attribute: user.userprincipalname
- Name:
Click Save.
Testing single sign-on
To verify that the configuration works correctly, you need three test users in your Azure AD tenant:
- A regular Azure AD user.
- An Azure AD guest user. This is a user that has been invited from a different Azure AD tenant.
- An external guest user. This is a user that has been invited using a
non–Azure AD email address such as a
@hotmail.com
address.
For each user, you perform the following test:
- Open a new incognito browser window and go to the https://console.cloud.google.com/.
In the Google Sign-In page that appears, enter the email address of the user as it appears in the Primary email address in Cloud Identity or Google Workspace column of the earlier table. Refer to that table to see how the email address in Cloud Identity or Google Workspace derives from the user principal name.
You are redirected to Azure AD where you see another sign-in prompt.
At the sign-in prompt, enter the UPN of the user and follow the instructions to authenticate.
After successful authentication, Azure AD redirects you back to Google Sign-In. Because this is the first time you've signed in using this user, you are asked to accept the Google Terms of Service and privacy policy.
If you agree to the terms, click Accept.
You are redirected to the Google Cloud console, which asks you to confirm preferences and accept the Google Cloud Terms of Service.
If you agree to the terms, choose Yes, and then click Agree and continue.
Click the avatar icon, and then click Sign out.
You are redirected to an Azure AD page confirming that you have been successfully signed out.
What's next
- Learn more about federating Google Cloud with Azure AD.
- Read about best practices for planning accounts and organizations and best practices for federating Google Cloud with an external IdP.