Microsoft Entra ID から Google Workspace への SSO を実装する
はじめに
Microsoft Entra ID(以降 Entra ID) で一元的にユーザー ID を管理している環境で、Google ドライブといった Google Workspace で管理される Google サービスに対してユーザーがアクセスを試みると、Entra ID の認証を経て Google Workspace にシングルサインオン(SSO)するアーキテクチャを検証しました。
また、Entra ID から Google Workspace へのユーザープロビジョニングもあわせて設定し、Google Workspace 側にユーザーを作成・同期できる構成を確認します。
SSOの実現方法
Entra ID による Google Workspace との SSO と Google サービスへのアクセスは SAML と ユーザープロビジョニング(SCIM) の仕組みによって実現します。
SAML
SAML(Security Assertion Markup Language) は、IdP(Identity Provider) と SP(Service Provider) の間で認証情報を安全に交換するための規格です。SAML において IdP はユーザー ID を管理しユーザー認証を提供するコンポーネントであり、SP は IdP から受け取った認証情報を利用してユーザーがアクセスするコンポーネントとして定義されています。今回の検証においては IdP = Entra ID、SP = Google Workspace の位置づけとなります。
ユーザーが IdP での認証に成功すると、IdP は SAML レスポンス に含まれる SAML アサーション と呼ばれる認証情報をユーザーに発行します。Google Workspace がこの情報を検証し信頼することで、ユーザーはパスワードを再入力することなくログイン(SSO)できるようになります。
ユーザープロビジョニング(SCIM)
SAML はユーザー認証を提供しますが、Google Workspace 側にそのユーザーのアカウント実体(Google アカウント)が存在しなければ Google にはログインできません。ユーザープロビジョニングは、Entra ID のユーザー情報を Google Workspace に自動的に同期(作成・更新・削除)する仕組みです。この仕組みにより Entra ID でユーザーを管理するだけで Google Workspace に Google アカウントとして同期され、ユーザーを一元的に管理できるようになります。
ユーザープロビジョニングを実現する方法として SCIM(System for Cross-domain Identity Management) というプロトコルが利用されます。SCIM は異なるサービス間でユーザーやグループなどの ID 情報を標準的な API で連携するための仕様です。
検証の前提
本ブログでは以下の前提で検証します。
- Entra ID のドメインを
example.com、Google Workspace のドメインをsub.example.comとし、異なるドメイン間で連携させる。 - Entra ID の UPN(UserPrincipalName) として
user@example.comを作成すると、Google アカウントuser@sub.example.comが Google Workspace に作成される(ユーザープロビジョニング)。 user@example.comで Entra ID にログインすると、user@sub.example.comとして Google Workspace にアクセスする(SAML)。- Entra ID の特定のセキュリティグループ(今回は
Google Users)に追加したユーザーのみをプロビジョニング、シングルサインオンさせる。 - セキュリティグループ自体のプロビジョニングはしない。
- Entra ID ユーザーのプロビジョニング先は特定の Google Workspace 組織部門(今回は
EntraID_Users)とする。また、EntraID_Usersに所属するユーザーのみをシングルサインオンさせる。
実現したい構成
Google Workspace の特権管理者に関する注意
今回 Google Workspace に作成する SSO プロファイルでは Google Workspace 特権管理者をシングルサインオン対象にできません。 Entra ID での認証後、Google へのログインが拒否されます。
今回の検証構成でいうと Google Workspace 組織部門 EntraID_Users に含めない、または、特権管理者用 Google グループを作成して 「SSO なし」の設定をオーバーライドしてください。
または「以前の SSO プロファイル(Legacy SSO Profile)」を利用して特権管理者を SSO プロファイルに紐づけることで Google にログインさせることはできるようになりますが、 この場合は Entra ID の認証がバイパスされ Google に直接ログインする動作となります。
いずれにせよ Google Workspace 特権管理者を SSO の対象とできないのは、IdP の侵害や障害時に全ユーザーが Google Workspace から完全にロックアウトされてしまうのを防止するためと認識しています。
なお、「以前の SSO プロファイル」には設定における制約(証明書を一つしか設定できないなど)もあるため、Google Workspace 特権管理者は最初から SSO 対象外とする設計とすることをおすすめします。
実装してみた
以下ドキュメントを参考に実装していきます。
0. 検証環境準備
今回は Google Workspace の代わりに Cloud Identity を利用して検証を行います。Cloud Identity は Google Workspace の ID 管理やエンドポイント管理のみを利用できるようにしたサービスです。Cloud Identity Free Edition は 50 ユーザー制限がありますが無償で利用ができ、Google ドライブへのアクセスも可能なことから検証環境として利用しています。Cloud Identity も Google Workspace も同一の管理コンソールから同じ手順でユーザー作成やシングルサインオン設定が可能です。表現上の混乱を避けるため、以降の手順では Cloud Identity の操作を 「Google Workspace」 と統一して表現しますのでご了承ください。
本検証ではそれぞれ以下の権限で設定をしていきます。
- Entra ID: グローバル管理者
- Google Workspace: 特権管理者
1. Entra ID ユーザーとセキュリティグループ作成
Microsoft Entra 管理センターにログインします。
Entra ID 側で検証用ユーザーを 2 件作成し、セキュリティグループ Google Users を作成して両名をメンバーに追加します。
| ユーザー | ユーザープリンシパルネーム | 姓 | 名 |
|---|---|---|---|
| User A | user.a@example.com | User | A |
| User B | user.b@example.com | User | B |
Entra ID の姓名 (surname / givenName) は Google Workspace 側の必須属性である姓名 (name.familyName / name.givenName) へマッピングされるため、空のままにせず入力しておきます。
セキュリティグループは以下のようにします。
| 項目 | 設定値 |
|---|---|
| グループの種類 | セキュリティ |
| グループ名 | Google Users |
その他のグループ設定はデフォルトのままとし、上記ユーザーをグループのメンバーに追加します。
Entra ID ユーザーとセキュリティグループ作成 完了時点の状態
2. Google Workspace 組織部門作成
Google Workspace の Admin Console にログインします。
親組織配下に組織部門 EntraID_Users を作成します。Entra ID で作成されたユーザーは後述の手順によってこの組織部門にプロビジョニングされます。
Google Workspace 組織部門作成 完了時点の状態
3. Entra ID エンタープライズアプリケーションの登録
Entra 管理センターで [Entra ID] > [エンタープライズアプリ] から [+ 新しいアプリケーション] をクリックします。
[アプリケーションを検索] に「google」と入力し、検索結果に表示された Google Cloud / G Suite Connector by Microsoft を選択します。
[名前] を任意の名前にします。デフォルトの名前がわかりにくいため、ここでは Google Workspace に変更します。[作成] をクリックします。
Entra ID エンタープライズ アプリケーション登録 完了時点の状態
4. Entra ID プロビジョニング設定
Google Workspace の認可
作成したエンタープライズアプリケーションで [管理] > [プロビジョニング] を選択します。
さらにもう一度 [管理] > [プロビジョニング] を選択します。
[プロビジョニングモード] を 自動 に設定します。[管理者資格情報] を開き、「アプリの承認は portal.azure.com からのみサポートされます。ここをクリックして portal.azure.com にリダイレクトし、アプリケーションへのアクセスを承認します。」をクリックします。
これにより Azure ポータルにリダイレクトされます。ユーザープロビジョニングを構成するには Google Workspace への API 接続が必要となります。API 接続に必要な OAuth 認可フローと管理者資格情報の取得は Azure ポータルでのみサポートしているようです。
ユーザー認証を経て Azure ポータルに遷移したら改めて [管理] > [プロビジョニング] を選択します。
また、改めて[プロビジョニングモード] を 自動 に設定、[管理者資格情報] を開き、[承認する] をクリックします。
Google Workspace の特権管理者 でログインします。
[続行] をクリックします。
コンソール画面の右上にある通知マークをクリックし、以下画面の通知が表示されたら完了です。
設定進捗がわかりにくくなるため、残りの設定は Microsoft Entra 管理センターで行うことにします。ここでは一旦 [保存] をクリックして、Azure ポータルは閉じてしまいます。
Microsoft Entra 管理センターに戻ります。
Google Workspace の認可 完了時点の状態
グループのアプリケーションへの割り当て
Microsoft Entra 管理センターのエンタープライズアプリケーション画面で一度ブラウザの画面更新をしておきます。
[管理] > [ユーザーとグループ] > [+ Add user/group] をクリックします。
[ユーザーとグループ] から、「1. Entra ID ユーザーとセキュリティグループ作成」で作成したセキュリティグループ Google Users にチェックし、[選択] をクリックします。
[割り当て] をクリックします。
グループのアプリケーションへの割り当て 完了時点の状態
ユーザーの属性マッピング
[管理] > [プロビジョニング] > [マッピング] > [Provision Microsoft Entra ID Users] をクリックします。
[属性マッピング] > [userPrincipalName] > [編集] をクリックします。
以下の設定を行います。
| 項目 | 設定値 |
|---|---|
| マッピングの種類 | 式 |
| 式 | Replace([userPrincipalName], "@example.com", , , "@sub.example.com", , ) |
本設定によってユーザープロファイルの UPN(userPrincipalName) に設定されたメールアドレスのドメイン @example.com を @sub.example.com に変換し、Google Workspace の属性 primaryEmail にマッピングします。
マッピング式に設定した関数 Replace のパラメータの詳細は以下をご参照ください。
設定後、[OK] をクリックします。
次に、姓名である surname と givenName の設定もチューニングします。この二つの項目は Google Workspace の必須項目となるため、Entra ID ユーザーの姓名が null の場合にプロビジョニングエラーとなります。エラー回避のために「null の場合の既定値」を設定しておきます。
[surname] > [編集] をクリックし、_ を設定し [OK] をクリックします。
[givenName] > [編集] をクリックし、_ を設定し [OK] をクリックします。
最後に、プロビジョニングしたユーザーが所属する Google Workspace 組織部門を定義します。今回は「2. Google Workspace 組織部門作成」で作成した EntraID_Users 組織部門にプロビジョニングします。
画面下部の [新しいマッピングの追加] をクリックします。
以下の設定を行い、[OK] をクリックします。
| 項目 | 設定値 |
|---|---|
| マッピングの種類 | 定数 |
| 定数値 | /EntraID_Users |
| 対象の属性 | OrgUnitPath |
最後に忘れずに [保存] > [はい] をクリックします。
右上の [×] をクリックします。
グループのマッピング無効化
今回はグループのマッピングをしない条件で検証するため、グループのマッピング設定を無効化します。
[Provision Microsoft Entra ID Groups] をクリックします。
[有効] を「いいえ」に設定し、[保存] > [はい] をクリック、最後に右上の [×] をクリックします。
プロビジョニングの開始
ではプロビジョニングを開始し、ユーザーの同期をしていきます。
[管理] > [プロビジョニング] > [プロビジョニング状態] を「オン」にし、[保存] をクリックします。
[概要] > [プロビジョニングの開始] > [はい] をクリックします。
現在のサイクルの状態が「100% 完了済み」となることを確認します。
Google Workspace の Admin Console にアクセスし、ユーザープロビジョニングの状態を確認します。
組織部門 EntraID_Users に Entra ID で作成した User A, User B が作成されていることがわかります。
Entra ID プロビジョニング設定 完了時点の状態
5. Google Workspace SAML プロファイルの作成
Google Workspace の Admin Console より、SAML プロファイルを作成します。
[セキュリティ] > [認証] > [サードパーティの IdP による SSO] を選択し、[サードパーティの SSO プロファイル] > [SAML プロファイルを追加] をクリックします。
[SSO プロファイル名] に任意の名前を入力します。今回は Entra ID としました。
[メールアドレスを自動入力] は ログインヒントを使用しない を選択します。ログインヒントを設定すると、Google アクセス後にリダイレクトされる Entra ID の認証画面で @sub.example.com のユーザーアカウントが事前に入力されている状態となります。今回の検証では Entra ID に @example.com のユーザーアカウントでログインするため、ログインヒントは使用しないようにします。
[IdP の詳細] はこの時点では空白のままにしておき、[保存] をクリックします。
保存後の画面に表示される [エンティティ ID] と [ACS の URL] は次の Entra ID 側の SAML 設定の手順で利用します。
Google Workspace SAML プロファイル作成 完了時点の状態
6. Entra ID SAML 設定
次は Entra ID 側の SAML 設定に移ります。Microsoft Entra 管理センターの画面より、[エンタープライズ アプリケーション] > Google Workspace を選択し、[2。シングルサインオンの設定] をクリックします。
[SAML] を選択します。
基本的な SAML 構成
[基本的な SAML 構成] > [編集] をクリックします。
[識別子 (エンティティ ID)] > [識別子の追加] をクリックし、Google Workspace の「エンティティ ID」 をコピーして貼り付けます。既定にチェックが入っていることを確認します。それ以外のデフォルト設定はすべて削除します。
[応答 URL (Assertion Consumer Service URL)] > [応答 URL の追加] をクリックし、Google Workspace の「ACS の URL」 をコピーして貼り付けます。
サインオン URL に以下をコピーして貼り付けます。
https://www.google.com/a/sub.example.com/ServiceLogin?continue=https://console.cloud.google.com/
最後に [保存] をクリックし、右上の [×] をクリックします。
属性とクレーム
[ユーザー属性とクレーム] > [編集] をクリックします。
[追加の要求] のクレームをすべて削除します。
[必要な要求] > [一意のユーザー識別子 (名前 ID)] をクリックします。
[ソース] を「変換」にします。
[変換の管理] で以下の設定を行います。
| 項目 | 設定値 | 備考 |
|---|---|---|
| 変換 | ExtractMailPrefix() | |
| パラメーター 1 | 属性 | |
| 属性名 | user.userprincipalname | 必ず、値を入力せずドロップダウンから選択します (Google 公式ドキュメントに記載の user.userPrincipalName をそのまま貼り付けると SSO で認証エラーとなります) |
[変換を追加する] をクリックし、以下を設定します。
| 項目 | 設定値 | 備考 |
|---|---|---|
| 変換 | Join() | |
| 区切り文字 | @ |
|
| パラメーター 2 | 属性 | |
| 属性名 | "sub.example.com" |
値を入力したあとドロップダウンから選択します |
この設定は、UPN のプレフィックス(user.a@example.com の user.a の部分)と sub.example.com を @ で結合するという変換式となります。
[追加] をクリック、[保存] をクリックします。
SAML 証明書のダウンロード
[SAML 証明書] > [証明書 (Base64)] > [ダウンロード] をクリックします。.cer の拡張子を持つファイルがローカルにダウンロードされます。
Google Workspace SAML 設定用の URL の確認
[Google Workspace のセットアップ] に表示される ログイン URL と Microsoft Entra 識別子 は、次の Google Workspace 側の SAML 設定で利用します。
Entra ID SAML 設定 完了時点の状態
7. Google Workspace SAML プロファイルの更新
Google Workspace の Admin Console に戻り、手順 「5. Google Workspace SAML プロファイルの作成」で作成した SAML プロファイル Entra ID の設定を続けます。
[IdP の詳細] の編集マークをクリックし、以下を設定します。
| 項目 | 設定値 |
|---|---|
| IdP エンティティ ID | 手順 6 の Microsoft Entra 識別子 をコピーして貼り付け |
| ログインページの URL | 手順 6 の ログイン URL をコピーして貼り付け |
| ログアウト ページの URL | https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 |
| パスワード変更用 URL | https://account.activedirectory.windowsazure.com/changepassword.aspx |
| 確認用の証明書 | 手順 6 でダウンロードした .cer をアップロード ※拡張子は変更しない |
ページ最下部の [保存] をクリックします。
Google Workspace SAML プロファイルの更新 完了時点の状態
8. Google Workspace SAML プロファイルの割り当て
[セキュリティ] > [認証] > [サードパーティの IdP による SSO] を選択し、[SSO プロファイルの割り当ての管理] > [管理] をクリックします。
[組織部門] で EntraID_Users を選択します。
[SSO プロファイルを選択] で手順 「5. Google Workspace SAML プロファイルの作成」 で作成した SAML プロファイル Entra ID を選択し、「Google でユーザー名の入力を求めた後、このプロファイルの IdP ログインページにリダイレクトする」 にチェックを入れ、[保存] をクリックします。
この設定により、EntraID_Users に所属するユーザーが Google にログインを試みると SAML プロファイルで設定した URL にリダイレクトされ、SAML による認証のプロセスが行われます。
Google Workspace SAML プロファイルの割り当て 完了時点の状態
（補足）SAML 証明書の有効期限
Entra ID の SAML 証明書はデフォルトの有効期限が 3 年となります。証明書の更新手順は以下をご参照ください。
確認してみた
User A(user.a@sub.example.com) で Google ドライブへのアクセスを試みます。Chrome でシークレットウインドウを起動し Google ドライブにアクセスします。
Entra ID のログイン画面にリダイレクトされました。
Entra ID でのユーザー認証が成功すると、Google アカウント user.a@sub.example.com として Google ドライブにアクセスできました。
おわりに
Entra ID と Google Workspace のユーザープロビジョニングと SSO を設定してみました。
設定自体は手順どおりに進めれば整理しやすい一方、ドメイン変換や SAML の名前 ID、組織部門への割り当てが絡むため、構成ミス時のトラブルシュートは難しくなりがちです。本手順が設定にお困りの皆様のご助力となれば幸いです。
