Azure AD B2B user provisioning and single sign-on

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.

Configuring Azure AD user provisioning and single sign-on.

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 add tenant.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 gcloud command-line tool) 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.

  1. In the Admin Console, go to Organizational units and click .
  2. Enter the following settings:
    1. Name of organizational unit: guests
    2. Description: Azure B2B guest users
  3. 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.

  1. In the Admin Console, go to Security > Google Cloud session control.
  2. Select the organizational unit guests.
  3. 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.
  4. Set re-authentication method to Password. This setting ensures that users have to re-authenticate by using Azure AD after a session has expired.
  5. Click Override.

Configure Azure AD provisioning

You are now ready to adjust your existing Azure AD configuration to support provisioning of B2B guest users.

  1. In the Azure portal, go to Azure Active Directory > Enterprise applications.
  2. Select the enterprise application Google Cloud (Provisioning), which you use for user provisioning.
  3. Click Manage > Provisioning.
  4. Click Edit provisioning.
  5. Under Mappings, click Provision Azure Active Directory Users.
  6. Select the row userPrincipalName.
  7. In the Edit Attribute dialog, apply the following changes:

    1. Mapping type: Change from Direct to Expression.
    2. Expression:

      Replace([originalUserPrincipalName], "#EXT#@TENANT_DOMAIN", , , "@PRIMARY_DOMAIN", , )

      Replace the following:

      • TENANT_DOMAIN: the initial domain of your Azure AD tenant tenant.onmicrosoft.com.
      • PRIMARY_DOMAIN: the primary domain name used by your Cloud Identity or Google Workspace account, such as example.org.
  8. Click OK.

  9. Select Add new mapping.

  10. In the Edit Attribute dialog, configure the following settings:

    1. Mapping type: Expression.
    2. Expression:

      IIF(Instr(originalUserPrincipalName, "#EXT#", , )="0", "/", "/guests")

    3. Target attribute: OrgUnitPath

  11. Click OK.

  12. Click Save.

  13. Click Yes to confirm that saving changes will result in users and groups being resynchronized.

  14. 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:

  1. In the Azure portal, go to Azure Active Directory > Enterprise applications.
  2. Select the Google Cloud enterprise application, which you use for single sign-on.
  3. Click Manage > Single sign-on.
  4. On the ballot screen, click the SAML card.
  5. On the User Attributes & Claims card, click Edit.
  6. Select the row labeled Unique User Identifier (Name ID).
  7. 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.
  8. Select Claim conditions.
  9. Add a conditional claim for external guests:
    1. User type: External guests
    2. Source: Transformation
    3. Transformation: Select Extract() and Before matching
    4. Parameter 1 (Input): user.userprincipalname
    5. Value: #EXT#@TENANT_DOMAIN. Replace TENANT_DOMAIN with the initial domain of your Azure AD tenant in tenant.onmicrosoft.com.
  10. Click Add.
  11. Add a conditional claim for Azure AD guests from different tenants:

    1. User type: AAD guests
    2. Source: Transformation
    3. Transformation: Select Extract() and Before matching
    4. Parameter 1 (Input): user.localuserprincipalname

    5. Value: #EXT#@TENANT_DOMAIN. Replace TENANT_DOMAIN with the default domain of your Azure AD tenant such as tenant.onmicrosoft.com

  12. Click Add.

  13. Add a conditional claim for regular Azure AD users:

    1. User type: Members
    2. Source: Attribute
    3. Value: user.userprincipalname
  14. Click Save.

  15. On the User Attributes & Claims screen, select Add new claim.

  16. Enter the following settings:

    1. Name: _upn
    2. Source: Attribute
    3. Source attribute: user.userprincipalname
  17. 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:

  1. Open a new incognito browser window and go to the https://console.cloud.google.com/.
  2. 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.

  3. 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.

  4. If you agree to the terms, click Accept.

    You are redirected to the Cloud Console, which asks you to confirm preferences and accept the Google Cloud Terms of Service.

  5. If you agree to the terms, choose Yes, and then click Agree and continue.

  6. 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