Google Cloud と Active Directory の連携: シングル サインオンの構成

この記事では、Microsoft Active Directory フェデレーション サービス(AD FS)と SAML フェデレーションを使用して、Active Directory 環境と Cloud Identity または G Suite アカウントの間のシングル サインオンを設定する方法について説明します。

この記事は、Active Directory ID 管理を Google Cloud に拡張する方法を理解している状態であり、ユーザー プロビジョニングを構成済みであることを前提としています。また、この記事では、Windows Server 2016 以降の Windows Server で稼働している AD FS 4.0 サーバーがあることを前提としています。

このガイドに従うには、Active Directory Domain Services と AD FS に関する知識が必要です。また、特権管理者権限を持つ Cloud Identity または G Suite のユーザーと、AD FS サーバーへの管理者権限を持つ Active Directory のユーザーが必要です。

目標

  • Cloud Identity または G Suite が ID プロバイダとして使用できるように AD FS サーバーを構成する。
  • Active Directory と Cloud Identity または G Suite の間の ID に一致する要求発行ポリシーを作成する。
  • 認証を AD FS に委任するように Cloud Identity または G Suite アカウントを構成する。

費用

Cloud Identity Free Edition を使用している場合、この記事では Google Cloud の課金対象となるコンポーネントを使用しません。

始める前に

  1. AD FS サーバーが Windows Server 2016 以降で稼働していることを確認します。以前のバージョンの Windows Server と AD FS を使用してシングル サインオンを構成することもできますが、必要な構成手順はこの記事とは異なります。
  2. Active Directory ID 管理を Google Cloud に拡張する方法を十分に理解します。
  3. Active Directory と Cloud Identity または G Suite の間のユーザー プロビジョニングを構成します。
  4. AD FS サーバーで使用している Secure Sockets Layer(SSL)証明書が、社内ユーザーのブラウザで認識される有効なものであることを確認します。
  5. AD FS が単一障害点にならないよう、サーバー ファーム構成での AD FS のセットアップを検討します。シングル サインオンを有効にした後、AD FS の可用性により、ユーザーが Cloud Console にログインできるかどうかが決まります。

シングル サインオンについて

Cloud Directory Sync を使用することで、ユーザーの作成とメンテナンスを自動化し、Active Directory のユーザーにライフサイクルを結び付けることができます。

Cloud Directory Sync ではユーザー アカウントの詳細がプロビジョニングされますが、パスワードは同期されません。ユーザーが Google Cloud で認証を必要とするときは常に Active Directory に認証を委任する必要があります。これは、AD FS と Security Assertion Markup Language(SAML)プロトコルが使用されます。この設定により、Active Directory が唯一、ユーザー認証情報にアクセスして既存のポリシーや多要素認証(MFA)メカニズムを適用することが確実になります。さらに、この設定ではオンプレミス環境と Google の間でのシングル サインオンも確立されます。

SAML 2.0 には、「ID プロバイダ(IdP)」と「サービス プロバイダ(SP)」と呼ばれる二者間でのシングル サインオンの実装に使用できるプロトコルと XML 言語が定義されています。

  • SP は、ユーザーを認証しなければならない組織です。SP は認証そのものを行うように構成されていないため、認証を行う役目を IdP に委任します。
  • IdP は、ユーザー認証を行う組織です。認証対象のユーザーに関する事実を識別し、それらの事実を SP に中継します。事実のコレクションは「アサーション」と呼ばれます。

Active Directory と Google の間でシングル サインオンを実装するには、AD FS を IdP として、Cloud Identity または G Suite アカウントを SP として構成します。この設定を行うと、Cloud Console へのログインは次のようになります。

Cloud Console へのログイン。

  1. ユーザーがブラウザで Cloud Console を開きます。
  2. ユーザーがまだ認証されていないため、Cloud Console はブラウザを Google ログインにリダイレクトします。
  3. ユーザーに、メールアドレスの入力を求めるログインページが表示されます。
  4. ユーザーがメールアドレスを送信すると、Google ログインは、そのメールアドレスが AD FS を使用してフェデレーション認証用に構成された Cloud Identity または G Suite アカウントに属していることを認識します。その結果、ブラウザは AD FS にリダイレクトされます。
  5. AD FS はその構成に応じて、ユーザーをログインページに戻すか、ユーザー名とパスワードの入力を求めます。Kerberos ベースの認証が使用されている場合、ユーザーは自動的に認証されるため、認証情報を入力する必要はありません。
  6. ユーザーが認証情報を入力する必要がある場合、AD FS は入力されたユーザー名とパスワードを検証するために、Kerberos を使用して Active Directory キー配布センターとやり取りします。
  7. 認証情報が正常に検証されると、AD FS はブラウザをリダイレクトして Google ログインに戻します。
  8. Google ログインによってセッションが確立され、ブラウザが Cloud Console に返されます。これにより、アクセス権が付与されます。

AD FS の構成

Cloud Identity または G Suite でシングル サインオンを有効にする前に、AD FS を構成する必要があります。

証明書利用者信頼を作成する

AD FS を使用するには、AD FS を使用して認証を行うことになっている SP ごとに「証明書利用者信頼」を作成する必要があります。それにはまず、次の手順に従って Cloud Identity または G Suite 用の証明書利用者信頼を作成します。

  1. AD FS サーバーにログインし、AD FS MMC スナップインを開きます。
  2. 左側のメニューで、[証明書利用者信頼] フォルダを右クリックします。コンテキスト メニューから [証明書利用者信頼の追加] を選択します。
  3. ウィザードの最初のページで、[要求に対応する] を選択してから [開始] をクリックします。

    証明書利用者信頼ウィザード

  4. 次のページで、[証明書利用者についてのデータを手動で入力する] をオンにしてから [次へ] をクリックします。

  5. 次のページで、表示名(Cloud Identity など)を入力してから [次へ] をクリックします。

  6. 次のページでは、トークン暗号化証明書を入力するよう求められます。この手順は、Cloud Identity または G Suite アカウントに接続するために必要なものではありません。[次へ] をクリックしてください。

  7. 次に表示されるページで、[SAML 2.0 WebSSO プロトコルのサポートを有効にする] をオンにして、次の SSO サービス URL を入力します。

    https://www.google.com/a/[DOMAIN]/acs
    

    [DOMAIN] を Cloud Identity または G Suite アカウントのプライマリ ドメインに置き換え、[次へ] をクリックします。

    SAML 2.0 WebSSO プロトコルのサポートを有効にする

  8. ウィザードの次のページでは、証明書利用者信頼 ID を入力するよう求められます。次の ID をリストに追加します。

    • google.com/a/[DOMAIN][DOMAIN] を Cloud Identity または G Suite アカウントのプライマリ ドメインに置き換えます)
    • google.com

    証明書利用者信頼 ID

    [次へ] をクリックします

  9. 次のページで、アクセス ポリシーを選択します。MFA の構成はこの記事の対象外なので、ここでは [すべてのユーザーを許可] をクリックし、[次へ] をクリックします。

  10. [信頼の追加の準備完了] ページで、設定内容を確認してから [次へ] をクリックします。

  11. 最後のページで、[このアプリケーションの要求発行ポリシーを構成する] チェックボックスをオフにしてからウィザードを閉じます。証明書利用者信頼のリストに、新しく作成したエントリが表示されます。

ログアウト URL を構成する

ユーザーが複数のアプリケーションでシングル サインオンを使用できるようにする場合は、ユーザーが複数のアプリケーションでログアウトできるようにすることも重要です。

  1. AD FS 管理コンソールで、[証明書利用者信頼] にリストされている前の手順で作成した信頼を右クリックし、[プロパティ] をクリックします。
  2. [エンドポイント] タブで、[SAML の追加] をクリックします。
  3. [エンドポイントの追加] ダイアログで、次の設定を構成します。

    1. エンドポイントの種類: SAML ログアウト
    2. バインディング: POST
    3. 信頼できる URL: https://[ADFS]/adfs/ls/?wa=wsignout1.0

      [ADFS] は、AD FS サーバーの完全修飾ドメイン名に置き換えてください。

      エンドポイントの追加

  4. [OK] をクリックします。

  5. [OK] をクリックしてダイアログを閉じます。

要求のマッピングを構成する

AD FS はユーザーを認証すると、SAML アサーションを発行します。このアサーションは、認証が正常に行われた証拠としての役割を果たします。アサーションでは、認証されたユーザーが識別されている必要があります。その目的を果たすのが、NameID 要求です。

Google ログインで NameID とユーザーを関連付けるには、NameID にそのユーザーのメインのメールアドレスを含める必要があります。Active Directory と Cloud Identity または G Suite 間のユーザーのマッピング方法に応じて、NameID には UPN または Active Directory ユーザーのメールアドレスを含めて、必要に応じてドメイン置換を適用する必要があります。

UPN

  1. AD FS 管理コンソールで、[証明書利用者信頼] にリストされている新しく作成した信頼を右クリックし、[要求発行ポリシーの編集] をクリックします。
  2. 表示されるダイアログで、[規則の追加] をクリックします。
  3. [LDAP 属性を要求として送信] を選択してから [次へ] をクリックします。
  4. 次のページでは、以下の設定を適用します。
    1. 要求規則名: メールと名前 ID のマッピング
    2. 属性ストア: Active Directory
  5. LDAP 属性マッピングのリストに行を追加します。
    1. LDAP 属性: User-Principal-Name
    2. 送信要求タイプ: Name ID
  6. [完了] をクリックしてから [OK] をクリックします。

UPN: ドメイン置換

  1. AD FS 管理コンソールで、[証明書利用者信頼] にリストされている新しく作成した信頼を右クリックし、[要求発行ポリシーの編集] をクリックします。
  2. 表示されるダイアログで、[規則の追加] をクリックします。
  3. [カスタム規則を使用して要求を送信] をオンにしてから [次へ] をクリックします。
  4. 次のページでは、以下の設定を適用します。

    1. 要求規則名: UPN の読み込み
    2. カスタム規則:

      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
       => add(store = "Active Directory", types = ("http://temp.google.com/upn"), query = ";userPrincipalName;{0}", param = c.Value);
      

      この規則では、Active Directory から関連するユーザーのユーザー プリンシパル名(UPN)を読み込んで一時要求に保存します。

  5. [完了] をクリックします。

  6. [規則の追加] をクリックして 2 つ目の規則を作成します。

  7. [カスタム規則を使用して要求を送信] をオンにしてから [次へ] をクリックします。

  8. 次のページでは、以下の設定を適用します。

    1. 要求規則名: UPN の変換
    2. カスタム規則:

      c:[Type == "http://temp.google.com/upn"]
       => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = RegexReplace(c.Value, "@(.*?)$", "@[DOMAIN]"));
      

      この規則では、UPN が保存されている一時要求を開き、UPN のサフィックスとして付加されているドメインを [DOMAIN] に置き換えます。生成された要求は Google ログインに発行され、ユーザーを Cloud Identity または G Suite のユーザーに関連付けるために使用されます。

      [DOMAIN] は、Cloud Identity または G Suite アカウントのプライマリ ドメインに置き換えてください。

  9. [完了] をクリックしてから [OK] をクリックします。

    元の UPN によっては、異なる置換を適用しなければならない場合があります。その場合、追加の規則(可能な置換ごとに 1 つ)を作成し、条件を使用して各規則を適用する場合を限定します。たとえば、次のルールは UPN ドメインを corp.example.com に置き換えますが、元のドメインが corp.local の場合に限られます。

    c:[Type == "http://temp.google.com/upn", value =~ "^.+@corp.local$"]
     => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = RegexReplace(c.Value, "@(.*?)$", "corp.example.com"));
    

    複数の異なる置換を適用する場合は、置換ごとに別個の Cloud Directory Sync 構成を実行する必要があります。

メール

  1. AD FS 管理コンソールで、[証明書利用者信頼] にリストされている新しく作成した信頼を右クリックし、[要求発行ポリシーの編集] をクリックします。
  2. 表示されるダイアログで、[規則の追加] をクリックします。
  3. [LDAP 属性を要求として送信] を選択してから [次へ] をクリックします。
  4. 次のページでは、以下の設定を適用します。
    1. 要求規則名: メールと名前 ID のマッピング
    2. 属性ストア: Active Directory
  5. LDAP 属性マッピングのリストに行を追加します。
    1. LDAP 属性: E-Mail-Addresses
    2. 送信要求タイプ: Name ID
  6. [完了] をクリックしてから [OK] をクリックします。

メール: ドメイン置換

  1. AD FS 管理コンソールで、[証明書利用者信頼] にリストされている新しく作成した信頼を右クリックし、[要求発行ポリシーの編集] をクリックします。
  2. 表示されるダイアログで、[規則の追加] をクリックします。
  3. [カスタム規則を使用して要求を送信] をオンにしてから [次へ] をクリックします。
  4. 次のページでは、以下の設定を適用します。

    1. 要求規則名: メールアドレスの読み込み
    2. カスタム規則:

      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
       => add(store = "Active Directory", types = ("http://temp.google.com/mail"), query = ";mail;{0}", param = c.Value);
      

      このルールは、それぞれのユーザーのメールアドレスを Active Directory から読み込み、一時要求に保存します。

  5. [完了] をクリックします。

  6. [規則の追加] をクリックして 2 つ目の規則を作成します。

  7. [カスタム規則を使用して要求を送信] をオンにしてから [次へ] をクリックします。

  8. 次のページでは、以下の設定を適用します。

    1. 要求規則名: メールアドレスの変換
    2. カスタム規則:

      c:[Type == "http://temp.google.com/mail"]
       => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = RegexReplace(c.Value, "@(.*?)$", "@[DOMAIN]"));
      

      この規則では、メールアドレスが保存されている一時要求を読み取り、そのドメインを [DOMAIN] に置き換えます。生成された要求は Google ログインに発行され、Cloud Identity または G Suite でユーザーを識別するために使用されます。

      [DOMAIN] は、Cloud Identity または G Suite アカウントのプライマリ ドメインに置き換えてください。

  9. [完了] をクリックしてから [OK] をクリックします。

AD FS トークン署名証明書をエクスポートする

AD FS からアサーションが発行されたら、Cloud Identity はそのアサーションの整合性と信頼性を検証する必要があります。この目的のために、SAML では「トークン署名鍵」という特殊な鍵を使用してアサーションに署名を付けることを要件としています。トークン署名鍵は、指定の公開鍵/秘密鍵ペアの秘密鍵のほうです。このペアの公開鍵は「トークン署名証明書」という形で SP に対して使用可能にされます。SP はこのトークン署名証明書を使用してアサーションの署名を検証できます。

Cloud Identity アカウントまたは G Suite アカウントを構成する前に、AD FS からトークン署名証明書をエクスポートする必要があります。

  1. AD FS 管理コンソールで、[サービス] > [証明書] をクリックします。
  2. [トークン署名] にリストされている証明書を右クリックし、[証明書の表示] をクリックします。
  3. [詳細] タブをクリックします。
  4. [Copy to File] をクリックして証明書エクスポート ウィザードを開きます。
  5. [次へ] をクリックします。
  6. 形式として [DER Encoded Binary X.509 (*.cer)] を選択し、[次へ] をクリックします。
  7. ローカル ファイル名を入力してから [次へ] をクリックします。
  8. [完了] をクリックしてエクスポートを確定します。
  9. エクスポートが正常に完了したことを確認するメッセージ ボックスが表示されたら、[OK] をクリックしてメッセージ ボックスを閉じます。
  10. エクスポートされた証明書をローカルのコンピュータにコピーします。

Cloud Identity または G Suite アカウントを構成する

AD FS の構成が完了したら、Cloud Identity または G Suite アカウントでシングル サインオンを構成できます。

  1. 管理コンソールで、[セキュリティ] > [設定] をクリックします。
  2. [サードパーティの ID プロバイダを使用したシングル サインオン(SSO)の設定] をクリックします。
  3. [サードパーティの ID プロバイダで SSO を設定する] が有効になっていることを確認します。
  4. 次の設定を入力します。すべての URL で、[ADFS] を AD FS サーバーの完全修飾ドメイン名に置き換えてください。
    1. ログインページの URL: https://[ADFS]/adfs/ls/
    2. ログアウト ページの URL: https://[ADFS]/adfs/ls/?wa=wsignout1.0
    3. パスワード変更用 URL: https://[ADFS]/adfs/portal/updatepassword/
  5. [認証の確認] で [ファイルを選択] をクリックし、前にダウンロードした AD FS トークン署名証明書を選択します。
  6. [保存] をクリックします。
  7. 次のページで、シングル サインオンを有効にすることを確認し、[理解して、同意します] をクリックします。
  8. 管理コンソールからログアウトするには、右上にあるアバターをクリックし、[ログアウト] をクリックします。

シングル サインオンをテストする

これで、AD FS と Cloud Identity または G Suite の両方でシングル サインオンの構成が完了しました。シングル サインオンが意図したとおりに機能するかどうかを確認するには、次のテストを実行します。

  1. 以前に Cloud Identity または G Suite にプロビジョニングされていて、特権管理者権限が割り当てられていない Active Directory ユーザーを選択します。特権管理者権限を持つユーザーは常に Google 認証情報を使用してログインする必要があるため、シングル サインオンのテストには適していません。
  2. 新しいブラウザ ウィンドウを開き、https://console.cloud.google.com/ に移動します。
  3. 表示される Google ログインページで、ユーザーのメールアドレスを入力し、[次へ] をクリックします。ドメイン置換を使用する場合は、その置換をメールアドレスに適用する必要があります。

    ユーザーのメールアドレスを入力する

    AD FS にリダイレクトされます。フォームベースの認証を使用するように AD FS を構成した場合は、この時点でログインページが表示されます。

  4. Active Directory ユーザーの UPN とパスワードを入力し、[ログイン] をクリックします。

    Active Directory ユーザーの UPN とパスワードを入力する。

  5. 認証が成功すると、AD FS によって再び Google Identity Platform にリダイレクトされます。このユーザーがログインするのは今回が初めてのため、Google 利用規約とプライバシー ポリシーに同意するよう求められます。

  6. 利用規約に同意する場合は、[同意する] をクリックします。

  7. Cloud Console にリダイレクトされ、設定を確認して Google Cloud の利用規約に同意するよう求められます。利用規約に同意する場合は、[はい] をクリックしてから [同意して続行] をクリックします。

  8. 左上にあるアバター アイコンをクリックし、[ログアウト] をクリックします。

    これにより、ユーザーが正常にログアウトされたことを確認する AD FS ページにリダイレクトされます。

ログインする際に問題が発生した場合、AD FS サーバーで AD FS デバッグログを有効化すると、問題を診断する際に役立つ可能性があります。統合 Windows 認証を使用している場合は、さまざまなユーザーで簡単にテストできるように一時的にフォームベースの認証に切り替えることを検討してください。

特権管理者権限を持つユーザーはシングル サインオンから除外されるため、管理コンソールを使用して設定を確認または変更できます。

クリーンアップ

組織でシングル サインオンを有効にしない場合は、次の手順で Cloud Identity または G Suite でシングル サインオンを無効にします。

  1. 管理コンソールで、[セキュリティ] > [設定] をクリックします。
  2. [サードパーティの ID プロバイダを使用したシングル サインオン(SSO)の設定] をクリックします。
  3. [サードパーティの ID プロバイダで SSO を設定する] チェックボックスをオフにします。
  4. [保存] をクリックします。

AD FS で構成をクリーンアップするには、次の手順に従います。

  1. AD FS サーバーにログインし、AD FS MMC スナップインを開きます。
  2. 左側のメニューで、[証明書利用者信頼] フォルダを右クリックします。
  3. 証明書利用者信頼のリストで、[Cloud Identity] を右クリックし、[削除] をクリックします。
  4. [はい] をクリックして削除を確定します。

次のステップ