この記事では、Microsoft Active Directory フェデレーション サービス(AD FS)と SAML フェデレーションを使用して、Active Directory 環境と Cloud Identity または Google Workspace アカウントの間のシングル サインオンを設定する方法について説明します。
この記事は、Active Directory ID 管理を Google Cloud に拡張する方法を理解している状態であり、ユーザー プロビジョニングを構成済みであることを前提としています。また、この記事では、Windows Server 2016 以降の Windows Server で稼働している AD FS 4.0 サーバーがあることを前提としています。
このガイドに従うには、Active Directory Domain Services と AD FS に関する知識が必要です。また、特権管理者権限を持つ Cloud Identity または Google Workspace のユーザーと、AD FS サーバーへの管理者権限を持つ Active Directory のユーザーが必要です。
目標
- Cloud Identity または Google Workspace が ID プロバイダとして使用できるように AD FS サーバーを構成する。
- Active Directory と Cloud Identity または Google Workspace の間の ID に一致する要求発行ポリシーを作成する。
- 認証を AD FS に委任するように Cloud Identity または Google Workspace アカウントを構成する。
費用
Cloud Identity Free Edition を使用している場合、この記事では Google Cloud の課金対象となるコンポーネントを使用しません。
始める前に
- AD FS サーバーが Windows Server 2016 以降で稼働していることを確認します。以前のバージョンの Windows Server と AD FS を使用してシングル サインオンを構成することもできますが、必要な構成手順はこの記事とは異なります。
- Active Directory ID 管理を Google Cloud に拡張する方法を十分に理解します。
- Active Directory と Cloud Identity または Google Workspace の間のユーザー プロビジョニングを構成します。
- AD FS が単一障害点にならないよう、サーバー ファーム構成での AD FS のセットアップを検討します。シングル サインオンを有効にした後、AD FS の可用性により、ユーザーが Google Cloud コンソールにログインできるかどうかが決まります。
シングル サインオンについて
Google Cloud Directory Sync を使用することで、すでにユーザーの作成とメンテナンスが自動化され、ライフサイクルが Active Directory のユーザーに結び付けられました。
GCDS ではユーザー アカウントの詳細がプロビジョニングされますが、パスワードは同期されません。ユーザーが Google Cloud で認証を必要とするときは常に Active Directory に認証を委任する必要があります。これは、AD FS と Security Assertion Markup Language(SAML)プロトコルが使用されます。この設定により、Active Directory が唯一、ユーザー認証情報にアクセスして既存のポリシーや多要素認証(MFA)メカニズムを適用することが確実になります。さらに、この設定ではオンプレミス環境と Google の間でのシングル サインオンも確立されます。
シングル サインオンの詳細については、シングル サインオンをご覧ください。
SAML プロファイルを作成する
AD FS でシングル サインオンを構成するには、まず Cloud Identity または Google Workspace のアカウントで SAML プロファイルを作成します。SAML プロファイルには、AD FS インスタンスに関連する設定(URL や署名証明書など)が含まれています。
SAML プロファイルは後で特定のグループまたは組織部門に割り当てます。
Cloud Identity または Google Workspace のアカウントに新しい SAML プロファイルを作成するには、次の操作を行います。
管理コンソールで、[サードパーティの IdP による SSO] に移動します。
[サードパーティの SSO プロファイル] > [SAML プロファイルを追加] をクリックします。
[SAML SSO プロファイル] ページで、次の設定を行います。
- 名前:
AD FS
IdP エンティティ ID:
https://ADFS/adfs/services/trust
ログインページの URL:
https://ADFS/adfs/ls/
ログアウト ページの URL:
https://ADFS/adfs/ls/?wa=wsignout1.0
パスワード変更用 URL:
https://ADFS/adfs/portal/updatepassword/
すべての URL で、
ADFS
を AD FS サーバーの完全修飾ドメイン名に置き換えてください。まだ確認証明書をアップロードしないでください。
- 名前:
[保存] をクリックします。
表示される [SAML SSO プロファイル] ページには、次の 2 つの URL が含まれています。
- エンティティ ID
- ACS の URL
次のセクションで AD FS を構成するときに、これらの URL が必要になります。
AD FS を構成する
AD FS サーバーを構成するには、証明書利用者信頼を作成します。
証明書利用者信頼を作成する
次の手順で新しい証明書利用者信頼を作成します。
- AD FS サーバーに接続して、AD FS 管理 MMC スナップインを開きます。
- [AD FS] > [証明書利用者信頼] を選択します。
- [アクション] ペインで、[証明書利用者信頼の追加] をクリックします。
- ウィザードの [ようこそ] のページで、[要求に対応する] を選択してから [開始] をクリックします。
- [データソースの選択] ページで、[証明書利用者についてのデータを手動で入力する] をオンにして [次へ] をクリックします。
- [表示名の指定] ページで
Google Cloud
などの名前を入力し、[次へ] をクリックします。 - [証明書の構成] ページで [次へ] をクリックします。
[URL の構成] ページで [SAML 2.0 WebSSO プロトコルのサポートを有効にする] を選択し、SAML プロファイルの ACS URL を入力します。[次へ] をクリックします。
[識別子の構成] ページで、SAML プロファイルのエンティティ ID を追加します。
[Next] をクリックします。
[アクセス制御ポリシーの選択] ページで適切なアクセス ポリシーを選択し、[次へ] をクリックします。
[信頼の追加の準備完了] ページで、設定内容を確認してから [次へ] をクリックします。
最後のページで、[このアプリケーションの要求発行ポリシーを構成する] チェックボックスをオフにしてからウィザードを閉じます。
証明書利用者信頼のリストに、新しく作成したエントリが表示されます。
ログアウト URL を構成する
ユーザーが複数のアプリケーションでシングル サインオンを使用できるようにする場合は、ユーザーが複数のアプリケーションでログアウトできるようにすることも重要です。
- 先ほど作成した証明書利用者信頼を開きます。
- [エンドポイント] タブを選択します。
[SAML を追加] をクリックして、次の設定を構成します。
- エンドポイントの種類: SAML ログアウト
- バインディング: POST
信頼できる URL:
https://ADFS/adfs/ls/?wa=wsignout1.0
ADFS
は、AD FS サーバーの完全修飾ドメイン名に置き換えてください。
[OK] をクリックします。
[OK] をクリックしてダイアログを閉じます。
要求のマッピングを構成する
AD FS はユーザーを認証すると、SAML アサーションを発行します。このアサーションは、認証が正常に行われた証拠としての役割を果たします。アサーションでは、認証されたユーザーが識別されている必要があります。その目的を果たすのが、NameID
要求です。
Google ログインで NameID
とユーザーを関連付けるには、NameID
にそのユーザーのメインのメールアドレスを含める必要があります。Active Directory と Cloud Identity または Google Workspace 間のユーザーのマッピング方法に応じて、NameID
には UPN または Active Directory ユーザーのメールアドレスを設定して、必要に応じてドメイン置換を適用する必要があります。
UPN
- 証明書利用者信頼のリストで、作成した信頼を選択し、[要求発行ポリシーの編集] をクリックします。
- [規則の追加] をクリックします。
- [Add transform claim rule] ウィザードの [Choose rule type] ページで、[Transform an incoming claim] を選択して、[次へ] をクリックします。
[要求規則の構成] ページで、次の設定を構成します。
- 要求規則名:
Name Identifier
- 入力方向の要求の種類: UPN
- 出力方向の要求の種類: 名前 ID
- Outgoing name ID format: メール
- 要求規則名:
[すべての要求値をパス スルーする] を選択し、[終了] をクリックします。
[OK] をクリックして、要求発行ポリシーのダイアログを閉じます。
UPN: ドメイン置換
- 証明書利用者信頼のリストで、作成した信頼を選択し、[要求発行ポリシーの編集] をクリックします。
- [規則の追加] をクリックします。
- [Add transform claim rule] ウィザードの [Choose rule type] ページで、[Transform an incoming claim] を選択して、[次へ] をクリックします。
[要求規則の構成] ページで、次の設定を構成します。
- 要求規則名:
Name Identifier
- 入力方向の要求の種類: UPN
- 出力方向の要求の種類: 名前 ID
- Outgoing name ID format: メール
- 要求規則名:
[入力方向の電子メール サフィックスの要求を新しい電子メール サフィックスに置き換える] を選択し、以下の設定を構成します。
- New e-mail suffix: Cloud Identity または Google Workspace アカウントで使用されるドメイン名。
[完了] をクリックしてから [OK] をクリックします。
メールアドレス
- 証明書利用者信頼のリストで、作成した信頼を選択し、[要求発行ポリシーの編集] をクリックします。
- 次の手順でメールアドレスを検索するルールを追加します。
- 表示されるダイアログで、[規則の追加] をクリックします。
- [LDAP 属性を要求として送信] をオンにしてから [次へ] をクリックします。
- 次のページでは、以下の設定を適用します。
- 要求規則名:
Email address
- 属性ストア: Active Directory
- 要求規則名:
- LDAP 属性マッピングのリストに行を追加します。
- LDAP 属性: E-Mail-Addresses
- 出力方向の要求の種類: メールアドレス
- [完了] をクリックします。
次の手順で別のルールを追加して、
NameID
を設定します。- [規則の追加] をクリックします。
- [Add transform claim rule] ウィザードの [Choose rule type] ページで、[Transform an incoming claim] を選択して、[次へ] をクリックします。
[要求規則の構成] ページで、次の設定を構成します。
- 要求規則名:
Name Identifier
- 入力方向の要求の種類: メールアドレス
- 出力方向の要求の種類: 名前 ID
- Outgoing name ID format: メール
- 要求規則名:
[すべての要求値をパス スルーする] を選択し、[終了] をクリックします。
[OK] をクリックして、要求発行ポリシーのダイアログを閉じます。
メール: ドメイン置換
- 証明書利用者信頼のリストで、作成した信頼を選択し、[要求発行ポリシーの編集] をクリックします。
- 次の手順でメールアドレスを検索するルールを追加します。
- 表示されるダイアログで、[規則の追加] をクリックします。
- [LDAP 属性を要求として送信] をオンにしてから [次へ] をクリックします。
- 次のページでは、以下の設定を適用します。
- 要求規則名:
Email address
- 属性ストア: Active Directory
- 要求規則名:
- LDAP 属性マッピングのリストに行を追加します。
- LDAP 属性: E-Mail-Addresses
- 出力方向の要求の種類: メールアドレス
- [完了] をクリックします。
次の手順で別のルールを追加して、
NameID
値を設定します。- [規則の追加] をクリックします。
- [Add transform claim rule] ウィザードの [Choose rule type] ページで、[Transform an incoming claim] を選択して、[次へ] をクリックします。
[要求規則の構成] ページで、次の設定を構成します。
- 要求規則名:
Name Identifier
- 入力方向の要求の種類: メールアドレス
- 出力方向の要求の種類: 名前 ID
- Outgoing name ID format: メール
- 要求規則名:
[入力方向の電子メール サフィックスの要求を新しい電子メール サフィックスに置き換える] を選択し、以下の設定を構成します。
- New e-mail suffix: Cloud Identity または Google Workspace アカウントで使用されるドメイン名。
[完了] をクリックして、[OK] をクリックします。
AD FS トークン署名証明書をエクスポートする
AD FS はユーザーの認証後に、SAML アサーションを Cloud Identity または Google Workspace に渡します。Cloud Identity と Google Workspace がそのアサーションの整合性と信頼性を検証できるように、AD AF は特別なトークン署名鍵を使用してアサーションに署名し、証明書を提供します。Cloud Identity または Google Workspace は、この証明書を使用して署名の検証を行います。
次の手順で AD FS から署名証明書をエクスポートします。
- AD FS 管理コンソールで、[サービス] > [証明書] をクリックします。
- [トークン署名] にリストされている証明書を右クリックし、[証明書の表示] をクリックします。
- [詳細] タブを選択します。
- [Copy to File] をクリックして証明書エクスポート ウィザードを開きます。
- [Welcome to the certificate export wizard] で [次へ] をクリックします。
- [Export private key] ページで [No, do not export the private key] を選択します。
- [Export file format] ページで [Base-64 encoded X.509 (.CER)] を選択して、[次へ] をクリックします。
- [File to export] ページでローカル ファイル名を入力して [次へ] をクリックします。
- [完了] をクリックして、ダイアログを閉じます。
- エクスポートされた証明書をローカル パソコンにコピーします。
SAML プロファイルを入力する
署名証明書を使用して、SAML プロファイルの構成を完了します。
管理コンソールに戻り、[セキュリティ] > [認証] > [サードパーティの IdP による SSO] に移動します。
先ほど作成した
AD FS
SAML プロファイルを開きます。[IdP の詳細] セクションをクリックして設定を編集します。
[証明書をアップロード] をクリックし、AD FS からエクスポートしたトークン署名証明書を選択します。
[保存] をクリックします。
SAML プロファイルは完成しましたが、引き続き完成したプロファイルを割り当てる必要があります。
SAML プロファイルを割り当てる
新しい SAML プロファイルを適用するユーザーを選択します。
管理コンソールの [サードパーティの IdP による SSO] ページで、[SSO プロファイルの割り当ての管理] > [管理] をクリックします。
左側のペインで、SSO プロファイルを適用するグループまたは組織部門を選択します。すべてのユーザーにプロファイルを適用するには、ルート組織部門を選択します。
右側のペインで、[別の SSO プロファイル] を選択します。
メニューで、先ほど作成した
AD FS - SAML
SSO プロファイルを選択します。[保存] をクリックします。
手順を繰り返して、別のグループまたは組織部門に SAML プロファイルを割り当てます。
シングル サインオンをテストする
シングル サインオンの構成が完了しました。では、SSO が意図したとおりに機能するか確認してみましょう。
次の条件を満たす Active Directory ユーザーを選択します。
- ユーザーが Cloud Identity または Google Workspace にプロビジョニングされている。
Cloud Identity ユーザーに特権管理者の権限がない。
特権管理者権限が割り当てられているユーザー アカウントは Google 認証情報を使用してログインする必要があるため、シングル サインオンのテストには適していません。
新しいブラウザ ウィンドウを開き、https://console.cloud.google.com/ に移動します。
表示される Google ログインページで、ユーザーのメールアドレスを入力し、[次へ] をクリックします。ドメイン置換を使用する場合は、その置換をメールアドレスに適用する必要があります。
AD FS にリダイレクトされます。フォームベースの認証を使用するように AD FS を構成した場合は、ログインページが表示されます。
Active Directory ユーザーの UPN とパスワードを入力し、[ログイン] をクリックします。
認証に成功すると、AD FS によって再び Google Cloud コンソールにリダイレクトされます。このユーザーがログインするのは今回が初めてのため、Google 利用規約とプライバシー ポリシーへの同意が求められます。
利用規約に同意する場合は、[同意する] をクリックします。
Google Cloud コンソールにリダイレクトされ、設定を確認して Google Cloud の利用規約に同意するよう求められます。利用規約に同意する場合は、[はい] をクリックしてから [同意して続行] をクリックします。
左上にあるアバター アイコンをクリックし、[ログアウト] をクリックします。
ユーザーが正常にログアウトされたことを確認する AD FS ページにリダイレクトされます。
ログインできない場合は、AD FS 管理ログで追加情報を確認できます。
特権管理者権限を持つユーザーはシングル サインオンから除外されるため、管理コンソールを使用して設定を確認または変更できます。
省略可: ドメイン固有サービスの URL のリダイレクトを構成する
内部ポータルまたはドキュメントから Google Cloud コンソールにリンクする場合は、ドメイン固有のサービス URL を使用してユーザー エクスペリエンスを向上させることができます。
通常のサービス URL(https://console.cloud.google.com/
など)とは異なり、ドメイン固有のサービス URL にはプライマリ ドメインの名前が含まれます。認証されていないユーザーがドメイン固有のサービス URL へのリンクをクリックすると、最初に Google ログインページが表示されるのではなく、AD FS にリダイレクトされます。
ドメイン固有のサービスの URL の例を次に示します。
Google サービス | URL | Logo |
---|---|---|
Google Cloud コンソール | https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://console.cloud.google.com |
|
Google ドキュメント | https://docs.google.com/a/DOMAIN |
|
Google スプレッドシート | https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://sheets.google.com
|
|
Google サイト | https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://slides.google.com |
|
Google ドライブ | https://drive.google.com/a/DOMAIN |
|
Gmail | https://mail.google.com/a/DOMAIN |
|
Google グループ | https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://groups.google.com |
|
Google Keep | https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://keep.google.com
|
|
Looker Studio | https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://lookerstudio.google.com |
ドメイン固有のサービス URL を AD FS にリダイレクトするように構成するには、次の操作を行います。
管理コンソールの [サードパーティの IdP による SSO] ページで、[ドメイン固有のサービスの URL] > [編集] をクリックします。
[ユーザーを以下の SSO プロファイルに含まれるサードパーティ IdP に自動的にリダイレクトする] を [有効] に設定します。
[SSO プロファイル] を
AD FS
に設定します。[保存] をクリックします。
省略可: ログイン時の本人確認を構成する
Google ログインでは、不明なデバイスからユーザーがログインした場合や、他の理由でログイン試行に不審な点がある場合に、追加の確認を求められる可能性があります。このようなログイン時の本人確認は、セキュリティの向上に役立つため、ログイン時の本人確認を有効のままにしておくことをおすすめします。
ログイン時の本人確認が原因でログインに過剰な時間を要する場合は、次の手順でログイン時の本人確認を無効にできます。
- 管理コンソールで、[セキュリティ] > [認証] > [ログイン時の本人確認] に移動します。
- 左側のペインで、ログイン時の本人確認を無効にする組織部門を選択します。すべてのユーザーのログイン時の本人確認を無効にするには、ルート組織部門を選択します。
- [他の SSO プロファイルを使用してログインするユーザーの設定] で、[Google による追加の確認をユーザーに要求しない] を選択します。
- [保存] をクリックします。
クリーンアップ
組織でシングル サインオンを有効にしない場合は、次の手順で Cloud Identity または Google Workspace でシングル サインオンを無効にします。
管理コンソールで、[SSO プロファイルの割り当ての管理] に移動します。
プロファイルの割り当てごとに、次の操作を行います。
- プロファイルを開きます。
- [継承] ボタンが表示されている場合は、[継承] をクリックします。[継承] ボタンが表示されない場合は、[なし] を選択して [保存] をクリックします。
[サードパーティの IdP による SSO] ページに戻り、AD FS SAML プロファイルを開きます。
[削除] をクリックします。
AD FS で構成をクリーンアップするには、次の手順に従います。
- AD FS サーバーに接続し、AD FS MMC スナップインを開きます。
- 左側のメニューで、[証明書利用者信頼] フォルダを右クリックします。
- 証明書利用者信頼のリストで、作成した証明書利用者信頼を右クリックし、[削除] をクリックします。
- [はい] をクリックして削除を確定します。