Migrating consumer accounts to Cloud Identity or G Suite: Best practices for setting up federation

This article is the second part of a multi-part series that discusses how you can migrate consumer accounts to Cloud Identity or G Suite. We recommend reading the articles in order.

The series consists of these parts:

Introduction

As explained in the first part of this series, when you plan to federate Cloud Identity or G Suite with an external identity provider (IdP), you can either migrate consumer accounts before setting up federation or set up federation and single sign-on before starting the migration.

If you decide to set up federation before migrating, you must configure the external IdP to avoid the following:

The following sections describe how you can achieve this when federating with Azure AD, Active Directory, or Okta.

Federating with Azure AD

If you plan to federate Cloud Identity or G Suite with Azure AD, you can use the G Suite gallery app. It's possible to use a single instance of this app to provision users and handle single sign-on. Using a single instance implies that any account that's being provisioned for Cloud Identity or G Suite is allowed to use single sign-on, and vice versa.

When you enable provisioning, Azure AD ignores any accounts in Cloud Identity or G Suite that do not have a counterpart in Azure AD, so there is no risk of inadvertently deleting migrated accounts.

Depending on how you configure the gallery app, you might still be at risk of locking out migrated accounts or creating conflicting accounts. There are multiple approaches to mitigate these risks. Each approach has advantages and disadvantages.

Approach 1: Don't configure provisioning

In this approach, you configure the gallery app to handle single sign-on, but you don't configure automatic provisioning. By not configuring provisioning, you avoid the risk of having Azure AD create conflicting accounts. You can safely assign the app to all accounts relevant for Google, even to those accounts that are still subject to being migrated.

For a user who has an unmanaged account, the corresponding Cloud Identity or G Suite account is created automatically when the transfer request is accepted. That user can immediately use single sign-on. For users who don't yet have an unmanaged account, you must manually create accounts in G Suite or Cloud Identity.

Although this approach avoids the risks of creating conflicting accounts and locking out migrated accounts, it comes with the limitation that any attribute changes or user suspensions performed in Azure AD will not be propagated to Cloud Identity or G Suite.

Approach 2: Two apps with manual assignment

In this approach, you overcome the limitation of having to manually create accounts in G Suite or Cloud Identity for users that don't have an unmanaged account. The approach is to use two gallery apps, one for provisioning and one for single sign-on:

  • The first app is used exclusively for provisioning users and groups and has single sign-on disabled. By assigning users to this app, you control which accounts are being provisioned to Cloud Identity or G Suite.
  • The second app is used exclusively for single sign-on and is not authorized to provision users. By assigning users to this app, you control which users are allowed to sign on.

Using these two apps, assign users as follows:

  • Assign all accounts relevant for Google to the single sign-on app. This includes all unmanaged and migrated accounts. This way, you avoid lockout of migrated accounts.
  • Assign accounts relevant for Google, except assign all unmanaged accounts to the provisioning app to avoid creating conflicting accounts.

However, any mistake in assignment can lead immediately to a conflicting account being created, making this approach substantially more risky than other approaches.

Approach 3: Two apps with user creation disabled

When configuring provisioning, you need to authorize Azure AD to access Cloud Identity or G Suite using a Cloud Identity or G Suite account. Normally, it's best to use a dedicated super admin account for this purpose, because super admin accounts are exempted from single sign-on (that is, any SSO configuration doesn't apply to them; they will continue to use passwords for login).

However, for this scenario, you can have Azure AD use a more restricted account for migration, one that doesn't allow Azure AD to create users. That way, you effectively prevent Azure from inadvertently creating conflicting accounts, regardless of which users are assigned to the provisioning app.

You can create a restricted admin user account in Cloud Identity or G Suite as follows:

  1. Open the Admin Console and log in using a super admin account.
  2. In the menu, go to Directory > Users and click + to create a user.
  3. Provide an appropriate name and email address such as:
    1. First Name: Azure AD
    2. Last Name: Restricted Synchronizer
    3. Primary email: azuread-restricted-synchronizer
    4. Keep the primary domain for the email address.
  4. Set Automatically generate a new password to Disabled and enter a password.
  5. Set Ask for a password change at the next sign-in to Disabled.
  6. Click Add New User.
  7. Click Done.

To enable Azure AD to manage groups and to update user accounts, you must assign a custom set of admin privileges to the user:

  1. In the menu, navigate to Account > Admin roles.
  2. Click Create New Role.
  3. Provide an appropriate name for the new role such as:
    1. Name: Azure AD Restricted Account Synchronizer
    2. Description: This role allows Azure AD to update accounts and groups
  4. Click Create.
  5. On the next screen, scroll down to Admin API privileges and select the following privileges. These settings permit Azure AD to update user accounts, but not create or delete accounts:
    1. Organization Units > Read
    2. Users > Read
    3. Users > Update
    4. Groups
  6. Click Save to create the role.
  7. Switch to the Admins tab and click Assign Admins.
  8. In the dialog, select the azuread-restricted-synchronizer account you created earlier, then click Confirm Assignment.

If you haven't configured Azure AD provisioning yet, follow federating GCP with Azure AD, but use the azuread-restricted-synchronizer account instead of a super-admin account when authorizing Azure AD.

If you've already set up Azure AD provisioning and single sign-on, follow these steps:

  1. In the Google Admin console, temporarily disable single sign-on.
  2. In the Azure Portal, re-initiate the authorization process for the provisioning app and use the azuread-restricted-synchronizer account instead of a super-admin account for authorization.
  3. In the Google Admin console, re-enable single sign-on.

Disallowing Azure AD from creating user accounts won't stop Azure AD from attempting to create user accounts. Therefore, you're likely to find errors in the Azure audit logs indicating that Azure AD failed to create user accounts in Cloud Identity or G Suite.

A downside of this approach is that for users without unmanaged accounts, you must manually create accounts in Cloud Identity or G Suite.

Federating with Azure AD: Comparison

The following table summarizes the approaches.

Avoids creating conflicting accounts Avoids deletion of migrated accounts Avoids locking out migrated accounts Auto-provisions new accounts Auto-updates migrated accounts
Approach 1: No provisioning X X
Approach 2: Two apps with manual assignment Risky
Approach 3: Two apps with user creation disabled X

Federating with Active Directory

If you plan to federate Cloud Identity or G Suite with Active Directory, you can use Google Cloud Directory Sync (GCDS) and Active Directory Federation Services (AD FS). Depending on how you configure GCDS and AD FS, a federated setup like this might put you at risk of locking out migrated accounts or creating conflicting accounts. There are multiple approaches to mitigate these risks. Each approach has advantages and disadvantages.

Approach 1: Disabling Cloud Directory Sync

In this approach, you set up single sign-on with AD FS, but you don't enable GCDS until you've finished migrating unmanaged user accounts. Assign all accounts relevant for Google to the access control policy of the relying party trust in AD FS.

By disabling GCDS, you avoid the risk of creating conflicting accounts. For a user who has an unmanaged account, the corresponding Cloud Identity/G Suite account is created automatically when the transfer request is accepted. That user can use single sign-on thereafter. For users without unmanaged accounts, you must manually create the accounts in Cloud Identity or G Suite.

While this approach avoids the risks of creating conflicting accounts and locking out migrated accounts, it comes with the limitation that any attribute changes or user suspensions performed in Active Directory will not be propagated to Cloud Identity or G Suite.

Approach 2: Disallowing Cloud Directory Sync to create users

When configuring provisioning, you must authorize Cloud Directory Sync to access Cloud Identity or G Suite. Normally, it's best to use a dedicated super-admin account for this purpose, because such accounts are exempted from single sign-on (that is, any SSO configuration doesn't apply to them; they will continue to use passwords for login).

To prevent Cloud Directory Sync from inadvertently creating or deleting migrated accounts, you configure it to use a restricted admin user account that lacks the privileges to create or delete users.

You can create a restricted admin user account in Cloud Identity or G Suite as follows:

  1. Open the Admin Console and log in using a super-admin account.
  2. In the menu, navigate to Directory > Users and click + to create a user.
  3. Provide an appropriate name and email address such as:
    1. First Name: Active Directory
    2. Last Name: Restricted Synchronizer
    3. Primary email: ad-restricted-synchronizer
    4. Keep the primary domain for the email address.
  4. Set Automatically generate a new password to Disabled and enter a password.
  5. Set Ask for a password change at the next sign-in to Disabled.
  6. Click Add New User.
  7. Click Done.

To enable Cloud Directory Sync to manage groups and to update user accounts, you must assign a custom set of admin privileges to the user:

  1. In the menu, navigate to Account > Admin roles.
  2. Click Create New Role.
  3. Provide an appropriate name for the new role such as:
    1. Name: Active Directory Restricted Account Synchronizer
    2. Description: This role allows GCDS to update accounts and groups
  4. Click Create.
  5. On the next screen, scroll down to Admin API privileges and select the following privileges. This allows Active Directory to update user accounts, but not create or delete accounts:
    1. Organizational Units
    2. Users > Read
    3. Users > Update
    4. Groups
    5. Schema Management
    6. Domain Management
  6. Click Save to create the role.
  7. Switch to the Admins tab and click Assign Admins.
  8. In the dialog, select the ad-restricted-synchronizer account you created earlier, then click Confirm Assignment.

If you haven't configured Cloud Directory Sync provisioning yet, follow our guide on federating GCP with Active Directory, but use the azuread-restricted-synchronizer account instead of a super-admin account when authorizing Azure AD.

If you've already set up Cloud Directory Sync provisioning and single sign-on, follow these steps:

  1. In the Google Admin console, temporarily disable single sign-on.
  2. In Cloud Directory Sync, re-initiate the authorization process for the provisioning app and use the ad-restricted-synchronizer account instead of a super-admin account for authorization.
  3. In the Google Admin console, enable single sign-on again.

Disallowing Cloud Directory Sync from creating user accounts won't stop Cloud Directory Sync from attempting to create user accounts. Therefore, you're likely to find errors in the Cloud Directory Sync log indicating that Cloud Directory Sync failed to create user accounts in Cloud Identity or G Suite.

A downside of this approach is that for users without unmanaged accounts, you must manually create accounts in Cloud Identity or G Suite.

Federating with Active Directory: Comparison

The following table summarizes the approaches:

Avoids creating conflicting accounts Avoids deletion of migrated accounts Avoids locking out migrated accounts Auto-provisions new accounts Auto-updates migrated accounts
Approach 1: Don't configure provisioning X X
Approach 2: Disallow GCDS to create users X

Federating with Okta

To federate Cloud Identity or G Suite with Okta, you can use the G Suite or Google Cloud Platform (GCP) apps from the library of applications available in the Okta administration interface. Because the apps have complementary capabilities, you might have to use them in combination:

When you use the G Suite app for provisioning, Okta ignores any accounts in Cloud Identity or G Suite that do not have a counterpart in Okta. So when you enable provisioning, you don't risk inadvertently deleting migrated accounts.

However, depending on the way you configure the G Suite or GCP apps, you might still be at risk of locking out migrated accounts or creating conflicting accounts. There are multiple approaches you can take to mitigate these risks. Each approach has advantages and disadvantages.

Approach 1: Don't configure provisioning

In this approach, you configure the G Suite or GCP app to handle single sign-on, but don't configure provisioning at all. By not configuring provisioning, you avoid the risk of having Okta create conflicting accounts. You can then safely assign the app to all accounts relevant for Google, even to those accounts that are still subject to being migrated.

The G Suite or GCP icons appear on the Okta homepage of all users that have been assigned to the app. However, signing in will fail unless a corresponding account happens to exist on the Google side.

For a user who has an unmanaged account, the corresponding Cloud Identity or G Suite account is created automatically when the transfer request is accepted. That user can then use single sign-on thereafter.

While this approach avoids the risks of creating conflicting accounts and locking out migrated accounts, it comes with the limitation that any attribute changes or user suspensions performed in Okta won't be propagated to Cloud Identity or G Suite. Another downside of this approach is that you must manually create accounts in G Suite or Cloud Identity for all users who don't have an unmanaged account.

Approach 2: Provision with manual assignment

In this approach, you configure the G Suite app to handle single sign-on and provisioning, and enable the Create Users, Update User Attributes, and Deactivate Users provisioning options. To add the GCP icon to users' Okta homepages, you can optionally configure the GCP app.

Assign accounts relevant for Google to the app, but ensure that you leave out all unmanaged accounts. This enables all users without unmanaged accounts to immediately start using G Suite or GCP. By leaving out unmanaged accounts, you also avoid creating conflicting accounts.

Whenever a user accepts a transfer request, assign the user to the app so that they are enabled to use single sign-on and access G Suite or GCP. One downside of this approach is that any mistake that you make in assignment can immediately lead to a conflicting account being created, whic makes this approach much riskier than the other approaches.

Another downside of this approach is that it causes temporary lockouts of migrated accounts. After accepting a transfer request, a user has to perform any subsequent sign-ons through Okta. These sign-on attempts will fail until you have assigned the user to the app in Okta.

Approach 3: Provision with user creation disabled

In this approach, you configure the G Suite to handle single sign-on and provisioning; enable the Update User Attributes and Deactivate Users provisioning options, but disable the Create Users option. To add the GCP icon to users' Okta homepages, you can optionally configure the GCP app.

Assign all accounts relevant for Google to the app. By disallowing Okta to create accounts, you prevent Okta from creating conflicting accounts, so it's safe to also assign the app to all unmanaged accounts. At the same time, this configuration still lets Okta propagate attribute changes and user suspensions to Cloud Identity or G Suite for those users that have a corresponding Google Account.

For users who don't have a corresponding Cloud Identity or G Suite account, Okta might display an error message in the Admin console:

Okta displaying an error message in the Admin console

When a user accepts a transfer request, the corresponding Cloud Identity or G Suite account is created automatically and the user can immediately use single sign-on. Although the account is functional at this point, Okta might not display an icon on the user's home page yet and might instead continue to display the error message in the Admin UI. To fix this, retry the assignment task in the Okta Administrator Dashboard:

Retrying the assignment task in the Okta Administrator Dashboard

This approach prevents Okta from creating conflicting accounts and locking out migrated accounts and is less prone to accidental misconfiguration than the second approach. One downside is that for users without unmanaged accounts, you must manually create accounts in Cloud Identity or G Suite.

Approach 4: Two apps with manual assignment

You can overcome some of the disadvantages of the previous approaches by using two apps, one for provisioning and one for single sign-on:

  • Configure the G Suite app to handle provisioning only. The single sign-on functionality of the app is not used. By assigning users to this app, you control which accounts are being provisioned to Cloud Identity or G Suite. You can ensure that this app is effectively hidden from your users by enabling the Do not display application icon to users option.
  • Configure either the GCP app or another instance of the G Suite app for single sign-on purposes only. By assigning users to this app, you control who is allowed to sign on and who sees the GCP icon on their Okta homepage.

Using these two apps, assign users as follows:

  • Assign accounts relevant for Google to the provisioning app, but leave out all unmanaged accounts. Whenever a user accepts a transfer request, assign the user to the app as well.
  • Assign all accounts relevant for Google to the single sign-on app. Include all unmanaged and migrated accounts. This way, you avoid lockout of migrated accounts.

Similar to Approach 2, a downside of this approach is that any mistake that you make in assignment can immediately lead to a conflicting account being created, making this approach substantially more risky than other approaches.

Federating with Okta: Comparison

The following table summarizes the approaches:

Avoids creating conflicting accounts Avoids deletion of migrated accounts Avoids locking out migrated accounts Auto-provisions new accounts Auto-updates migrated accounts
Approach 1: No provisioning X X
Approach 2: Provision with manual assignment Risky X
Approach 3: Provision with user creation disabled X
Approach 4: Two apps with manual assignment Risky

What's next

Was this page helpful? Let us know how we did:

Send feedback about...