Cloud Identity または Google Workspace を外部 ID プロバイダ（IdP）と連携させる予定があり、かつ、既存の一般ユーザー向けアカウントの統合も必要な場合は、連携と統合の相互作用を正しく理解して評価するためにこのドキュメントを役立ててください。このドキュメントでは、既存の一般ユーザー向けアカウントの統合を妨げることなく連携を構成する方法についても説明します。
連携とユーザー アカウントの統合の相互作用
連携の設定では、外部の信頼できるソースによって Cloud Identity または Google Workspace にユーザー アカウントが自動的にプロビジョニングされるように、Cloud Identity または Google Workspace を外部の信頼できるソースに接続します。
通常、次の不変条件は連携設定に当てはまります。
- 信頼できるソースは、ID の唯一のソースです。
- Cloud Identity または Google Workspace に、信頼できるソースによってプロビジョニングされたもの以外のユーザー アカウントはありません。
- SAML ID プロバイダは、信頼できるソースがユーザー アカウントをプロビジョニングした ID 以外の ID には Google シングル サインオンを許可しません。
これらの不変条件は、Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスの内容を反映していますが、既存の一般ユーザー向けアカウントを移行する際には、問題が生じる可能性があります。
- 既存の一般ユーザー向けアカウントは、信頼できる提供元から提供されたものではありません。これらのアカウントはすでに存在しており、信頼できるソースが認識する ID にリンクされる必要があります。
- 既存の一般ユーザー向けアカウントは、Cloud Identity または Google Workspace に移行されると、信頼できるソースによってプロビジョニングされていないユーザー アカウントになります。これらの移行されたアカウントは信頼できるソースによって認識され、「承認」される必要があります。
- 既存の一般ユーザー向けアカウントの ID は SAML ID プロバイダにとって未知のものであるかもしれませんが、シングル サインオンを使用するように許可される必要があります。
既存の一般ユーザー向けアカウントを統合するには、安全な方法でアカウント統合が行われるように、一時的に連携を設定する必要があります。
アカウント統合で連携を安全に使用する
次の表は、アカウント統合の連携を安全にするための考慮事項を示したものです。外部 IdP を使用する予定で、引き続き既存の一般ユーザー向けアカウントを統合する必要がある場合は、最初にこれらの要件を満たすように設定を行う必要があります。既存の一般ユーザー向けアカウントの移行が完了したら、要件を満たす必要がなくなるため、構成を自由に変更できます。
| 要件 | 理由 |
|---|---|
| 一般ユーザー向けアカウントの ID でのシングル サインオンを許可する | 一般ユーザー向けアカウントを移行するには、アカウントの移行が必要です。Cloud Identity または Google Workspace 管理者がアカウントの移行を開始しますが、移行を完了するには、一般ユーザー向けアカウントのオーナーが移行に同意する必要があります。いつ同意が得られるか、つまりいつ移行が実施されるかについて管理者が制御できることは限定されています。 オーナーが同意し、移行が完了すると、それ以降のログインはすべて、外部 IdP を使用したシングル サインオンの対象となります。 移行が完了したかどうかに関係なく、シングル サインオンを成功させるには、移行を予定しているすべての一般ユーザー向けアカウントの ID に対して、外部 IdP でのシングル サインオンを許可します。 |
| 一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを禁止する | すでに一般ユーザー向けアカウントを持っている ID のユーザー アカウントをプロビジョニングする場合は、競合するアカウントを作成します。競合するアカウントがあると、一般ユーザー向けアカウントの所有権とその構成、関連付けられたすべてのデータは、Cloud Identity または Google Workspace に移行されなくなります。 多くの外部 IdP では、デフォルトの動作として、Cloud Identity または Google Workspace にユーザー アカウントが事前に作成されます。この動作によって、競合するアカウントが誤って作成されることがあります。 既存の一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことで、競合するアカウントが誤って作成されるのを避け、一般ユーザー向けアカウントを正常に移行できます。 |
外部 IdP に一致する ID のない一般ユーザー向けアカウント（正規のアカウントであり、Cloud Identity または Google Workspace に移行するアカウント）を識別した場合は、連携構成がこれらの一般ユーザー向けアカウントの移行を妨げないようにする必要があります。
| 要件 | 理由 |
|---|---|
| 外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐ | 外部 IdP に一致する ID のないユーザー アカウントが Cloud Identity または Google Workspace にある場合、IdP はこのユーザー アカウントが孤立しているとみなし、アカウントを一時停止または削除する可能性があります。 外部 IdP と ID を照合することなく、移行対象アカウントが外部 IdP によって一時停止または削除されるのを防ぐことで、影響を受けるアカウントに関連付けられた構成とデータが失われるのを防ぎ、手動でアカウントを構成とデータを一致させることができます。 |
アカウント統合で Microsoft Entra ID（旧 Azure AD）連携を安全に使用する
Cloud Identity や Google Workspace を Microsoft Entra ID（旧 Azure AD）と連携させる場合は、Google Workspace ギャラリー アプリを使用します。
プロビジョニングを有効にすると、Microsoft Entra ID に対応するものがない Cloud Identity や Google Workspace の既存のアカウントが Microsoft Entra ID で無視されるため、外部 IdP に一致する ID がない移行したアカウントの削除を防ぐという要件は必ず満たされます。
ギャラリー アプリの構成方法に応じて、次のことを行う必要があります。
これらの要件を満たす方法はいくつかあります。それぞれにメリットとデメリットがあります。
アプローチ 1: プロビジョニングを構成しない
このアプローチでは、シングル サインオンを処理するようにギャラリー アプリを構成しますが、自動ユーザー プロビジョニングは構成しません。ユーザー プロビジョニングを構成しないことで、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。
一般ユーザー向けアカウントの ID でのシングル サインオンを許可するには、既存の一般ユーザー向けアカウントが移行対象の場合でも、最終的に Google サービスにアクセスする必要があるすべての ID にアプリを割り当てます。
既存の一般ユーザー向けアカウントを持つユーザーには、移行リクエストが承認された時点で、対応する Cloud Identity または Google Workspace のユーザー アカウントが自動的に作成されます。そのユーザーはすぐにシングル サインオンを使用できます。
Cloud Identity または Google Workspace にユーザー アカウントがないユーザーには、手動で作成する必要があります。
このアプローチは要件を満たし、設定が最も簡単ですが、Microsoft Entra ID で実行される属性の変更やユーザーの停止は、Cloud Identity や Google Workspace に反映されないという制限があります。
アプローチ 2: 2 つのアプリの使用と手動での割り当て
このアプローチでは、既存のアカウントのないユーザーには Google Workspace または Cloud Identity でアカウントを手動で作成しなければならないという制限を回避できます。ここでは、プロビジョニング用とシングル サインオン用の 2 つのギャラリー アプリを使用します。
- 最初のアプリは、ユーザーとグループのプロビジョニング専用に使用し、シングル サインオンは無効にします。このアプリにユーザーを割り当てることで、Cloud Identity または Google Workspace にプロビジョニングされるアカウントを制御できます。
- 2 つ目のアプリはシングル サインオン専用に使用し、ユーザーをプロビジョニングする権限を付与しません。このアプリにユーザーを割り当てることで、サインオンを許可するユーザーを制御できます。
これら 2 つのアプリを使用して、次のようにユーザーを割り当てます。
- 最終的に Google サービスにアクセスする必要があるすべての ID をシングル サインオン アプリに割り当てます。既存の一般ユーザー向けアカウントの ID を含めて、一般ユーザー向けアカウントの ID でのシングル サインオンを許可します。
- プロビジョニング アプリに ID を割り当てる場合は、最終的に Google サービスにアクセスする必要がある ID を含めます。ただし、既存の一般ユーザー向けアカウントを持っている ID はすべて除外します。この操作により、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。
アプローチ 3: 2 つのアプリの使用とユーザー作成の無効化
プロビジョニングを構成するときに、Cloud Identity または Google Workspace アカウントを使用して、Microsoft Entra ID による Cloud Identity や Google Workspace へのアクセスを認可する必要があります。通常は、そのためだけの特権管理者アカウントを使用することをおすすめします。特権管理者アカウントはシングル サインオンの適用対象外であるためです（つまり、SSO の構成は適用されず、ログインには引き続きパスワードが使用されます）。
ただし、このシナリオでは、移行用にさらに制限をかけたアカウントを Microsoft Entra ID に使用させ、Microsoft Entra ID によるユーザーの作成を禁止できます。こうすることで、プロビジョニング アプリに割り当てられているユーザーに関係なく、Azure によって、一般ユーザー向けアカウントの ID でユーザー アカウントが自動的にプロビジョニングされるのを効果的に防止できます。
Cloud Identity または Google Workspace の制限付き管理者ユーザー アカウントには、次の権限のみが付与されます。
- [組織単位] > [読み取り]
- [ユーザー] > [読み取り]
- [ユーザー] > [更新]
- グループ
このアプローチのデメリットは、非マネージド アカウントを持たないユーザーには、Cloud Identity または Google Workspace に手動でアカウントを作成する必要があることです。
Microsoft Entra ID との連携: 比較
次の表は各アプローチを比較してまとめたものです。
| 一般ユーザー向けアカウントの ID でのシングル サインオンを許可する | 一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを禁止する | 外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐ | 新しいアカウントを自動プロビジョニングする | 移行対象アカウントを自動更新する | |
|---|---|---|---|---|---|
| アプローチ 1: プロビジョニングを設定しない | ✅ | ✅ | ✅ | X | X |
| アプローチ 2: 2 つのアプリの使用と手動での割り当て | ✅ | 手動によるエラーが発生しやすい | ✅ | ✅ | ✅ |
| アプローチ 3: 2 つのアプリの使用とユーザー作成の無効化 | ✅ | ✅ | ✅ | X | ✅ |
アカウントで Active Directory 連携を安全に使用する
Cloud Identity または Google Workspace を Active Directory と連携させる場合は、Google Cloud Directory Sync（GCDS）と Active Directory フェデレーション サービス（AD FS）を使用します。GCDS と AD FS を構成する際には、次のことを確実に行う必要があります。
- 一般ユーザー向けアカウントの ID でのシングル サインオンを許可する。
- 一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを禁止する。
- 外部 IdP で一致する ID のない移行対象アカウントの削除を防ぐ。
これらの要件を満たす方法はいくつかあります。それぞれにメリットとデメリットがあります。
アプローチ 1: GCDS を無効にする
このアプローチでは、AD FS でシングル サインオンを設定しますが、管理対象外のユーザー アカウントの移行が完了するまで GCDS は有効にしません。GCDS を無効にすると、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。
一般ユーザー向けアカウントの ID でのシングル サインオンを許可するには、既存の一般ユーザー向けアカウントが移行対象の場合でも、AD FS でカスタムのアクセス制御ポリシーを作成し、最終的に Google サービスにアクセスする必要があるすべての ID に割り当てます。
既存の一般ユーザー向けアカウントを持つユーザーには、移行リクエストが承認された時点で、対応する Cloud Identity または Google Workspace のユーザー アカウントが自動的に作成されます。カスタムのアクセス制御ポリシーを使用すると、ユーザーがすぐにシングル サインオンを使用できるようになります。
Cloud Identity または Google Workspace にユーザー アカウントがないユーザーには、手動で作成する必要があります。
このアプローチは要件を満たし、最も設定が簡単ですが、Active Directory で行われる属性の変更とユーザーの停止が Cloud Identity または Google Workspace に反映されないという制限があります。
アプローチ 2: GCDS の使用と手動での割り当て
このアプローチでは、既存のアカウントのないユーザーには Google Workspace または Cloud Identity でアカウントを手動で作成しなければならないという制限を回避できます。
アプローチ 1 と同じで、一般ユーザー向けアカウントの ID でのシングル サインオンを許可するには、既存の一般ユーザー向けアカウントが移行対象であっても、AD FS でカスタムのアクセス制御ポリシーを作成し、最終的に Google サービスにアクセスする必要があるすべての ID を割り当てます。
GCDS に自動的にプロビジョニングするユーザー アカウントを反映するグループを、Active Directory に作成します。メンバーのリストに、最終的に Google サービスにアクセスする必要がある ID を含めます。ただし、既存の一般ユーザー向けアカウントを持っている ID はすべて除外します。
このグループのメンバーである ID に対してのみ、ユーザー アカウントをプロビジョニングするように GCDS を構成します。この操作により、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。
このアプローチの主な制限事項は、外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐことができないことです。したがって、このアプローチは、外部 IdP に一致する ID のない一般ユーザー向けアカウントがない場合にのみ適用できます。
アプローチ 3: GCDS にユーザーの作成を許可しない
プロビジョニングを構成するときは、GCDS が Cloud Identity または Google Workspace へアクセスすることを認可する必要があります。通常は、そのための特権管理者アカウントを使用することをおすすめします。特権アカウントはシングル サインオンの適用対象外であるためです（つまり、SSO の構成は適用されず、ログインには引き続きパスワードが使用されます）。
ただし、このシナリオでは、移行用にさらに制限をかけたアカウントを GCDS に使用させ、GCDS によるユーザーの作成を禁止できます。この操作により、効果的に GCDS によって一般ユーザー向けアカウントの ID で、自動的にプロビジョニングされるのを防止し、外部 IdP に一致する ID のないアカウントが削除されるのを防ぎます。
Cloud Identity または Google Workspace の制限付き管理者ユーザー アカウントには、次の権限のみが付与されます。
- 組織部門
- [ユーザー] > [読み取り]
- [ユーザー] > [更新]
- [グループ]
- [スキーマの管理]
- ドメインの管理
このアプローチのデメリットは、非マネージド アカウントを持たないユーザーには、Cloud Identity または Google Workspace に手動でアカウントを作成する必要があることです。
Active Directory との連携: 比較
次の表は各アプローチを比較してまとめたものです。
| 一般ユーザー向けアカウントの ID でのシングル サインオンを許可する | 一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを禁止する | 外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐ | 新しいアカウントを自動プロビジョニングする | 移行対象アカウントを自動更新する | |
|---|---|---|---|---|---|
| アプローチ 1: プロビジョニングを構成しない | ✅ | ✅ | ✅ | X | X |
| アプローチ 2: GCDS の使用と手動での割り当て | ✅ | 手動によるエラーが発生しやすい | X | ✅ | ✅ |
| アプローチ 3: GCDS にユーザーの作成を許可しない | ✅ | ✅ | ✅ | X | ✅ |
アカウント統合で Okta 連携を安全に使用する
Cloud Identity または Google Workspace を Okta と連携させるには、Okta アプリカタログから Google Workspace アプリを使用します。このアプリは、シングル サインオンを処理し、Cloud Identity または Google Workspace にユーザーとグループをプロビジョニングできます。
プロビジョニングに Google Workspace アプリを使用すると、対応するアカウントが Okta にない Cloud Identity または Google Workspace の既存のユーザーは Okta に無視されるため、外部 IdP に一致する ID のない移行されたアカウントの削除を防ぐという要件が常に満たされます。
Okta の構成方法に応じて、次の操作を行う必要があります。
これらの要件を満たす方法はいくつかあります。それぞれにメリットとデメリットがあります。
アプローチ 1: プロビジョニングを構成しない
このアプローチでは、シングル サインオンを処理するために Google Workspace アプリを構成しますが、プロビジョニングはまったく構成しません。ユーザー プロビジョニングを構成しないことで、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。
一般ユーザー向けアカウントの ID でのシングル サインオンを許可するには、既存の一般ユーザー向けアカウントが移行対象の場合でも、最終的に Google サービスにアクセスする必要があるすべての ID にアプリを割り当てます。アプリに割り当てられているすべての ID の Okta ホームページに、Google Workspace または Google Cloud のアイコンが表示されます。ただし、対応するユーザー アカウントが Google 側に存在しないと、ログインは失敗します。
既存の一般ユーザー向けアカウントを持つユーザーには、移行リクエストが承認された時点で、対応する Cloud Identity または Google Workspace のユーザー アカウントが自動的に作成されます。そのユーザーはすぐにシングル サインオンを使用できます。
このアプローチは要件を満たし、最も設定が簡単ですが、Okta で行われる属性の変更とユーザーの停止が Cloud Identity または Google Workspace に反映されないという制限があります。このアプローチのもう一つのデメリットは、既存の一般ユーザー向けアカウントを持たないすべてのユーザーのアカウントを Cloud Identity または Google Workspace で手動で作成する必要があることです。
アプローチ 2: プロビジョニングと手動による割り当て
このアプローチでは、シングル サインオンとプロビジョニングを処理するように Google Workspace アプリを構成しますが、次のプロビジョニング機能のみを有効にします。
- ユーザーの作成
- ユーザー属性の更新
- ユーザーの無効化
アプリに ID を割り当てる際には、最終的に Google サービスにアクセスする必要がある ID を含めますが、既存の一般ユーザー向けアカウントを持つことが判明している ID はすべて除外します。この操作により、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。
ユーザーが移行リクエストを承認したらすぐに、そのユーザーをアプリに割り当て、シングル サインオンの使用と Google Workspace または Google Cloud へのアクセスが有効になるようにします。
このアプローチのデメリットの 1 つは、割り当てに誤りがあると、すぐに競合するアカウントが作成される可能性があるため、他のアプローチよりもリスクが高くなります。
もう 1 つのデメリットは、移行対象アカウントの一時的なロックアウトが発生することです。移転リクエストを受信した後、ユーザーは後続のすべてのサインオンを Okta を介して実行する必要があります。ユーザーを Okta のアプリに割り当てるまで、このサインオン試行は失敗することになります。
アプローチ 3: プロビジョニングとユーザー作成の無効化
このアプローチでは、シングル サインオンとプロビジョニングを処理するように Google Workspace を構成しますが、次のプロビジョニング機能のみを有効にします。
- ユーザー属性の更新
- ユーザーの無効化
[Create Users] オプションを無効にしたまま、最終的に Google サービスへのアクセスを必要とするすべての ID をアプリに割り当てます。既存の一般ユーザー向けアカウントの ID を含めて、一般ユーザー向けアカウントの ID でのシングル サインオンを許可します。
Okta によるアカウントの作成を許可しないことで、Okta による一般ユーザー向けアカウントの ID でのユーザー アカウントの自動的プロビジョニングを防ぎます。それに加えて、この構成では、対応する Google アカウントを持つユーザーのために Okta に引き続き Cloud Identity や Google Workspace に属性変更やユーザー停止を伝播させることができます。
Cloud Identity または Google Workspace に対応するユーザー アカウントがない ID の場合、Okta の Okta 管理コンソールにエラー メッセージが表示されることがあります。
既存の一般ユーザー向けアカウントを持つユーザーには、移行リクエストが承認された時点で、対応する Cloud Identity または Google Workspace のユーザー アカウントが自動的に作成されます。そのユーザーはすぐにシングル サインオンを使用できます。この時点でユーザー アカウントは機能していますが、ユーザーの Okta ホームページにはアイコンがまだ表示されず、代わりに管理 UI にエラー メッセージが表示される場合もあります。解決するには、Okta の管理者ダッシュボードで割り当てタスクを再試行します。
このアプローチでは、Okta によって一般ユーザー向けアカウントの ID で、自動的にプロビジョニングされるのを防止できますが、一般ユーザー向けアカウントの ID でのシングル サインオンは依然として可能です。また、2 つ目の方法よりも構成のミスが発生しにくくなります。ただし、既存の一般ユーザー向けアカウントを持たないユーザーには Cloud Identity または Google Workspace でユーザー アカウントを手動で作成する必要があるというデメリットはあります。
アプローチ 4: 2 つのアプリの使用と手動による割り当て
1 つはプロビジョニング用、もう 1 つはシングル サインオン用に 2 つのアプリを使用することで、これまでのアプローチの欠点がいくつか克服されます。
- プロビジョニングのみを処理するように Google Workspace アプリのインスタンスを 1 つ構成します。アプリのシングル サインオン機能は使用されません。このアプリにユーザーを割り当てることで、Cloud Identity または Google Workspace にプロビジョニングされるアカウントを制御できます。[Do not display application icon to users] オプションを有効にすると、アプリがユーザーに表示されなくなります。
- シングル サインオン専用に、Google Workspace アプリの別のインスタンスを構成します。このアプリにユーザーを割り当てることで、サインオンできるユーザーを管理できます。
これら 2 つのアプリを使用して、次のようにユーザーを割り当てます。
- 最終的に Google サービスにアクセスする必要があるすべての ID をシングル サインオン アプリに割り当てます。既存の一般ユーザー向けアカウントの ID を含めて、一般ユーザー向けアカウントの ID でのシングル サインオンを許可します。
プロビジョニング アプリに ID を割り当てる場合は、最終的に Google サービスにアクセスする必要がある ID を含めます。ただし、既存の一般ユーザー向けアカウントを持っている ID はすべて除外します。この操作により、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。
ユーザーが移行リクエストを受信するたびに、そのユーザーをそのアプリに割り当てていきます。
Okta との連携: 比較
次の表は各アプローチを比較してまとめたものです。
| 一般ユーザー向けアカウントの ID でのシングル サインオンを許可する | 一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを禁止する | 外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐ | 新しいアカウントを自動プロビジョニングする | 移行対象アカウントを自動更新する | |
|---|---|---|---|---|---|
| アプローチ 1: プロビジョニングを設定しない | ✅ | ✅ | ✅ | X | X |
| アプローチ 2: プロビジョニングと手動による割り当て | X | リスクが高い | ✅ | ✅ | ✅ |
| アプローチ 3: プロビジョニングとユーザー作成の無効化 | ✅ | ✅ | ✅ | X | ✅ |
| アプローチ 4: 2 つのアプリの使用と手動による割り当て | ✅ | リスクが高い | ✅ | ✅ | ✅ |
次のステップ
- Active Directory との連携を設定する方法、または Microsoft Entra ID との連携を設定する方法を確認する。
- Cloud Identity または Google Workspace のアカウントを準備して、オンボーディング プロセスを開始する。