「Cloud Identityへ同期をしたオンプレADにドメイン参加することで、GoogleへSSOできる環境」をつくってみる

Last updated at 2024-03-11Posted at 2024-02-22

この記事について

Active Directory や Cloud Identity について、個人学習として検証環境を作った際の、備忘録記事です。
オンプレADにドメイン参加することで、GoogleにSSOできる環境を作ってみました。

と説明しても、言葉だけでは伝わりにくいので、
ポイントを動画にまとめています。

本記事では、設定手順と注意点を記載していきます。

設定手順

I. はじめる前に

AWS環境と、Cloud Identity 環境を持っていることを前提にしています
- Cloud Identity Free は無料で作れます
- 以下の検証も、Cloud Identity Free で進めています
- 以下の手順は、gw3.hgc.nanka-tsukuro.devのドメインで、Cloud Identityを発行している前提で記載しています
あくまで、個人的興味で検証環境を構築した際のメモとなります。お仕事などで構築される際は、しっかりとドキュメントを参照して進めてください

II. AWS 上に検証用のAD環境を構築する

Step-0. このセクションでやることの理解

AWS上にVPCを作成し、ADサーバ・GCDSサーバ・ADクライアントの計3台の Windows Server インスタンスを構築します
ADサーバには、ADドメインコントローラを設定し、ユーザを作成します
ADクライアントで、ドメインに参加します
ここまでの手順で、通常のドメイン参加までができる状態になります
構成図は以下の通り

Step-1. AWSにネットワークとサーバを用意

クリックして詳細を展開

「VPCを作成」の画面から、パブリックサブネット付きのVPCを構築
（VPCのCIDRなどは、構成図の通り）
セキュリティグループを作成
インバウンドルールに、家からのRDPと、サブネット内の通信を許可するルールをつける
EC2を3台起動
- Windows Server 2022 を選択
- インスタンスサイズは、t2.medium で問題ない
- キーペアは何かしら設定
- ネットワーク設定にて、先ほど作成したVPC、サブネット、セキュリティグループを選択
- パブリックIPの自動割り当ても有効化
- 高度なネットワーク設定で、サーバごとに以下を設定
  - AD-Server は、プライマリIPを 10.0.0.11 で設定
  - GCDS-Server は、プライマリIPを 10.0.0.12 で設定
  - AD-Client は、プライマリIPを 10.0.0.13 で設定
- 念のためストレージを40GiBにしておく
画面ショットは以下の通り（3台分実施する）
EC2にリモートデスクトップ接続できることを確認
- 家からRDPするにあたって、Elastic-IP （固定IP）を付与しておくとよいかも
- EC2からEC2にpingしても返答がない。これは、WIndows Defender ファイアウォールがブロックしているため
- 今後の作業のために、コンピュータ名（ホスト名）をAD-Serverなどに設定しておくことを推奨

Step-2. AD-Server に、ADドメインコントローラーを構築

手順は、こちらの記事が参考になる

ドメコン構築手順の個人メモ

サーバーマネージャーを起動し、右上の「管理」から、「役割と機能の追加」を選択
「役割と機能の追加ウィザード」が立ち上がるので、「次へ」
「役割ベースまたは機能ベースのインストール」を選択
「サーバープールからサーバーを選択」を選択の上、自身のコンピューターが選択されていることを確認して「次へ」
「役割の追加」で「ActiveDirectoryドメインサービス」を選択
必要な役割一覧が表示される。「機能の追加」をクリック
「ActiveDirectoryドメインサービス」にチェックが入っていることを確認して、「次へ」をクリック
「機能の選択」は何も選択せずに「次へ」をクリック
「Active Directory ドメインサービス」の画面で「次へ」をクリック
「必要に応じてサーバーを自動的に再起動する」にチェックを入れて、「インストール」をクリック
インストールが完了したら、「このサーバーをドメインコントローラーに昇格する」をクリック
配置構成で、「新しいフォレストを追加する」を選択し、ドメイン名を入力（私の場合は gw3.hgc.nanka-tsukuro.dev）
「ドメインコントローラーオプション」の画面では、以下が設定されていることを確認
- フォレスト機能レベル：　Windows Server 2016
- ドメイン機能レベル：　Windows Server 2016
- ドメインネームシステム（DNS）サーバー：（ON）
- DSRMのパスワードは適当に入力
「DNSオプション」は何も選択せずに「次へ」をクリック
NetBIOSドメイン名がGW3になっていることを確認
「パス」は変更なし
設定内容を確認して「次へ」をクリック
前提条件のチェックに引っかかる項目があっても、「インストール」をクリック
完了すると、ドメイン名がgw3.hgc.nanka-tsukuro.devとなっていて、ドメインコントローラーとして動作する

Step-3. AD-Server に、ユーザーの作成

手順は、こちらの記事が参考になる
なお、一般ユーザーだと、追加の設定をしない限りリモートデスクトップ接続ができず不便なので、Administrator権限のユーザを作成する

ユーザー作成手順の個人メモ

サーバーマネージャーを起動し、右上の「ツール」から「Active Directoryユーザーとコンピューター」を選択
「Active Directoryユーザーとコンピューター」の画面で、「gw3.hgc.nanka-tsukuro.dev」の左の三角印「▷」をクリック
「Users」をクリック
コピー対象のユーザーを選ぶために、「Administrator」をクリック
画面上部のメニューから「操作」→「コピー」をクリック
「姓」「名」「ユーザーログオン名」と、次の画面で「パスワード」を入力していく
完了すると、ユーザーが登録されていることが確認できる

Step-4. AD-Client で、参照先のDNSサーバをAD-Serverに変更

AD-Clientに Administrator でログインし、参照先のDNSサーバをAD-ServerのIPアドレスに変更する
手順は、こちらの記事が参考になる

DNS変更手順の個人メモ

画面左下のWindowsマークから「設定」をクリック
ネットワークとインターネット」をクリック
「アダプターのオプションを変更する」をクリック
インターネット接続のアイコンを右クリックして、プロパティをクリック
「インターネットプロトコルバージョン4（TCP/IPv4）を選択して「プロパティ」をクリック
「次のDNSサーバーのアドレスを使う」にチェックを入れて優先DNSサーバーにADサーバのIPアドレスを入力（私の場合は、10.0.0.11）

Step-5. AD-Client で、ドメインに参加

ドメイン参加する。手順は、こちらのドキュメントが参考になる

ドメイン参加の個人メモ

デスクトップで [スタート] ボタンをクリックし、「Control Panel」と入力して Enter キーを押下
[システムとセキュリティ] に移動し、[システム] をクリック
[詳細情報] の画面が開き、下部にある[このPCの名前を変更（詳細設定）]をクリック
[コンピューター名、ドメインおよびワークグループの設定] で [設定の変更] をクリック
[コンピューター名] タブで、[変更] をクリック
[所属するグループ] の下で [ドメイン] をクリックし、このコンピューターを参加させるドメイン名を入力して、[OK] をクリック（私の場合は、gw3.hgc.nanka-tsukuro.dev）
認証画面が出てくるので、ユーザー名には、Administrator パスワードには、AD-Server の Administrator のパスワード を入力
[コンピューター名/ドメインの変更] ダイアログボックスで [OK] をクリックし、コンピューターを再起動
ドメイン参加後、 gw3.hgc.nanka-tsukuro.dev\user1 もしくは user1@gw3.hgc.nanka-tsukuro.dev 等でサインインできるようになる

Step-6. 補足

GCDS-Server は、ドメインに参加する必要はありません
ここまでの手順と似たことを、過去に Hyper-V 環境で実施しました
こちらのページを参照ください

III. GCDS-Server のセットアップ

Step-0. このセクションでやることの理解

GCDSサーバ（Google Cloud Directory Syncを動かすサーバ）をセットアップします
ADサーバで作成したユーザーが、Cloud Identity に同期されることを確認します
手順は、公式ドキュメントに沿って実行しています

構築時の個人メモ

AD-Server でのGCDS用ユーザーの作成は、権限不足を防ぐために、[I-3. AD-Server に、ユーザーの作成] と同じように、Administrator権限で作っておくのが無難
UPN_SUFFIX_DOMAIN は、私の場合、gw3.hgc.nanka-tsukuro.devになる
エイリアスアドレスは同期しない設定にした
ユーザーとグループの削除ポリシーは検討しないことにした（今回はあくまで動作検証のため）
ロギングと通知の構成も検討しないことにした
念のため「FIle」→「Save」で設定を保存しておいた方が無難

LDAP Configuration

User Accounts

Step-4. 動作確認と補足

「最初のユーザーのプロビジョニング」セクションまで実施すると、Cloud Identity にADのユーザー情報が同期される
同期されたユーザー情報は、管理者権限でCloud Identity のコンソールにログインし、「ディレクトリ」→「ユーザー」に進むことで確認できる
ただしADのパスワード情報は同期されないので、Google のログインページに行って、ADと同じID/PWを入力してのログインはできない
（以下のスクリーンショットは、ADのID/PWを使って、Google にログインできない画面ショット。IDは同期されているものの、パスワードは違うことが分かる）

IV. ADのシングルサインオン設定を実施

Step-0. このセクションでやることの理解

目指すことは...
- Cloud Identity のIDプロバイダーとして、ADFSサーバを使用できるようにする状態の実現
- これにより、GoogleにログインしようとするとADFSの認証画面が立ち上がり、ここでADのID/PWを入力することで、GoogleにSSOできる環境が出来上がる

このセクションを完了した際の動作イメージは、以下の通り
（記事の一番上に掲載した動画とは異なります。特に後半の動きが違います。）

作業はかなり複雑で...
- 最初に、ADFS の構築（途中にADCSの構築と証明書発行関連作業も必要）
- 次にSAMLフェデレーションの設定をする
手順は...
- ADFS の構築は、こちらのドキュメントの p10～p22が参考になる
- SAMLフェデレーションの設定は、公式ドキュメントが参考になる

Step-1. AD-Server にて、SSL証明書の作成

こちらの資料のp10～p19が参考になる

SSL証明書作成手順の個人メモ

SSL証明書の作成

AD FSの構成ではSSLサーバ証明書が必要なため、 AD CSを使用して自己証明書を作成する。

AD CSのインストール

サーバーマネージャーを起動して、画面上部[管理]から[役割と機能の追加]をクリックし、[役割と機能の追加ウィザード]を起動。[次へ]をクリック
[インストールの種類の選択]画面で「役割ベースまたは機能ベースのインストール」を選択して、[次へ]をクリック
[対象サーバーの選択]画面で「サーバープールからサーバー選択」を選択し、インストール先となるサーバーを選択。[次へ]をクリック
[サーバーの役割選択]画面で、「Active Directory証明書サービス」を選択します。 [次へ]をクリック
[機能の選択]画面では何も選択せず、[次へ]をクリック
[Active Directory Certificate Service]の画面でも、[次へ]をクリック
[役割サービスの選択]画面で「証明機関」を選択して、[次へ]をクリック
[インストール]をクリック

AD CSの構成

サーバーマネージャーの上部フラッグに警告マークが表示されているので、クリック
表示されたメニュー、展開後の構成から[対象サーバーにActiveDirectory証明書サービスを構成する]をクリックし、AD CSの構成ウィザードを起動
[資格情報]画面で証明書サービスを構成するための管理者アカウントを指定して、[次へ]をクリック
[役割サービス]画面で「証明機関」を選択して[次へ]をクリック
[セットアップの種類]画面で「エンタープライズCA」を選択して[次へ]をクリック
[CA種類]画面で「ルートCA」を選択して[次へ]をクリック
[秘密キー]画面で「新しい秘密キーを作成」を選択して[次へ]をクリック
[CAの暗号化]画面で「SHA256」を選択し、[次へ]をクリック
[CAの名前]画面で共通名を任意で変更し、[次へ]をクリック
[有効期間]画面で証明機関の有効期限を入力し、[次へ]をクリック
[CAデータベース]画面でデータベースの場所を任意で指定し、[次へ]をクリック
[確認]画面で設定した内容の確認が表示されます。確認後、問題なければ[構成]をクリック
[閉じる]をクリックしてAD CSの構成ウィザードを閉じる

証明書テンプレートの作成

サーバーマネージャーの[ツール]メニューから[証明機関]を選択
証明機関が起動したら、画面左から構成した認証局を展開し、[証明書テンプレート]の項目で右クリックして[管理]をクリック
[証明書テンプレートコンソール]が起動したら、テンプレートの一覧から[Webサーバー]を右クリックして[テンプレートの複製]をクリック
[新しいテンプレートのプロパティ]画面で以下を設定し、[適用]してから[OK]をクリック

タブ	設定	設定値
全般	テンプレート表示名	任意の表示名（私の場合は、`Cert_Template_AD-Server`）
要求処理	秘密キーのエクスポートを許可する	チェックを入れる
セキュリティ	グループ名またはユーザー名	[追加]をクリックし、証明書の発行を許可するサーバーを追加（下のInfo参照）
セキュリティ	アクセス許可	追加したサーバーを選択した状態で、[登録]の許可にチェック

[セキュリティ]タブ-[グループ名またはユーザー名]の設定については、以下の手順で実施

前の手順にて、[新しいテンプレートのプロパティ]画面で[追加]をクリックし、[ユーザー、コンピューター、サービスアカウントまたはグループの選択]画面が表示されていることを確認
[オブジェクトの種類]をクリックし、[オブジェクトの種類]画面が表示されたら、「コンピューター」にチェックし、[OK]をクリック
[ユーザー、コンピューター、サービスアカウントまたはグループの選択]画面で、「選択するオブジェクト名を入力してください」の項目にコンピューター名を入力し、[名前の確認]をクリック（私の場合は、AD-Server）
コンピューターが検索され、コンピューター名に下線が付いたら、[OK]をクリック
[新しいテンプレートのプロパティ]画面にコンピューター名が登録されていることを確認

[証明書テンプレートコンソール] を閉じる
[証明機関]コンソールで、画面左の[証明書テンプレート]を右クリックして[新規作成]から[発行する証明書テンプレート]を選択する
先ほど作成したテンプレートを選択し、[OK]をクリック
証明機関コンソールの証明機関テンプレート一覧に作成したテンプレートが表示されていることを確認

証明書の発行

[ファイル名を指定して実行] (Winキー + R)で「MMC」を入力し、コンソールを起動
[ファイル]メニューから[スナップインの追加と削除]をクリック
[利用できるスナップイン]から[証明書]を選択し、[追加]をクリック
[証明書スナップイン]画面で[コンピューターアカウント]を選択し、[次へ]をクリック
[ローカルコンピューター]を選択して[完了]をクリック
[スナップインの追加と削除]画面で[OK]をクリック
画面左から[証明書]を展開し、[個人]の項目を右クリックして[すべてのタスク]から[新しい証明書の要求]をクリック
[証明書の登録]画面で[次へ]をクリック
[証明書の登録ポリシーの選択]画面で「Active Directory登録ポリシー」が選択された状態で[次へ]をクリック
[証明書の要求]画面で作成した証明書テンプレートをチェックし、 [この証明書を登録するには情報が不足しています。設定を構成するには、ここをクリックしてください]をクリック
[証明書のプロパティ]画面の[サブジェクト]タブで以下を入力し[Add]したのち、[OK]をクリック

設定種類値

サブジェクト名共通名ドメイン（私の場合はgw3.hgc.nanka-tsukuro.dev）

別名 DNS ドメイン（私の場合はgw3.hgc.nanka-tsukuro.dev）
[証明書の要求]画面で、作成した証明書テンプレートが選択し、[登録]をクリック
証明書の登録が完了すると、 [証明書インストールの結果]画面に「状態：成功」と表示される。[完了]をクリックし画面を閉じる

設定	種類	値
サブジェクト名	共通名	ドメイン（私の場合は`gw3.hgc.nanka-tsukuro.dev`）
別名	DNS	ドメイン（私の場合は`gw3.hgc.nanka-tsukuro.dev`）

サービスアカウントの作成

AD FSを使用するには、実行するためのサービスアカウントが必要。
ここで作成するサービスアカウントは「Group Managed ServiceAccount(以下gMSA)」と呼ばれるもので、ドメイン内で共通に使用することができる

KDSルートキーの作成

gMSAのパスワードを生成するために必要なKDSルートキーを作成する
PowerShell アイコンを右クリックで「管理者として実行」から起動し、以下のコマンドを実行する
※ エラーが出た際は、このドキュメントのコマンドを試す（コピペの問題かもしれない）

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

gMSAの作成

PowerShell アイコンを右クリックで「管理者として実行」から起動し、以下のコマンドを実行する

New-ADServiceAccount <サービスアカウント名> -DNSHostName <ドメイン名> -ServicePrincipalNames <サービス プリンシパル名 (SPN名) >

※<サービスアカウント名>は任意ですが、後の作業で使うためメモが必要

(私の場合は...)

New-ADServiceAccount AdfsGmsa -DNSHostName gw3.hgc.nanka-tsukuro.dev -ServicePrincipalNames http/gw3.hgc.nanka-tsukuro.dev

Step-2. AD-Server にて、ADFSのセットアップ

こちらの資料のp20～p22が参考になる

ADFSセットアップ手順の個人メモ

AD FSのインストール

サーバーマネージャーを起動して、画面上部[管理]から[役割と機能の追加]をクリックし、[役割と機能の追加ウィザード]を起動。[次へ]をクリック
[インストールの種類の選択]画面で「役割ベースまたは機能ベースのインストール」を選択して、[次へ]をクリック
[対象サーバーの選択]画面で「サーバープールからサーバー選択」を選択し、インストール先となるサーバーを選択。[次へ]をクリック
[サーバーの役割選択]画面で、「Active Directory Federation Services」を選択し、[次へ]をクリック
[サーバーの機能]画面で何も選択せず、[次へ]をクリック
AD FSを利用する上での注意事項が表示される。[次へ]をクリック
インストールオプションの確認が表示される。確認後、問題がなければ[インストール]をクリック
AD FSのインストールが完了すると、「構成が必要です。(マシン名)でインストールが正常に完了しました」と表示される。[閉じる]をクリックして[役割と機能の追加ウィザード]を閉じる

AD FSの構成

サーバーマネージャーの上部フラッグに警告マークが表示されているので、クリック
表示されたメニュー、展開後の構成から[このサーバーにフェデレーションサービスを構築します]をクリックし、Active Directoryフェデレーションサービス構成ウィザードを起動
今回は新しいフェデレーションサーバーを作成のため、「フェデレーションサーバーファームに最初のフェデレーションサーバーを作成します。」を選択。[次へ]をクリック
[Active Directory ドメインサービスへの接続]画面で、AD DSのドメイン管理者のアクセス許可をもっているアカウントを指定

[サービスのプロパティの指定]画面で以下を設定し、[次へ]をクリック

設定	設定値
SSL証明書	「IV-1. SSL証明書の作成」で作成したSSL証明書（私の場合は、`gw3.hgc.nanka-tsukuro.dev` ここで、`AD-Server`が付くものを選ぶと、後半で証明書エラーがありうまくいかなかった）
フェデレーションサービス名	証明書の登録後に自動的に設定される。
フェデレーションサービスの表示名	任意の文字列。（ここで設定した値が、認証画面に表示される）（私の場合は、`GW3-SSO`と設定）

[サービスアカウントの指定]画面で「既存のドメインユーザーアカウントまたはグループ管理されたサービスアカウントを使用してください」を選択し、「サービスアカウントの作成」で作成したgMSAを設定する。[次へ]をクリック
[構成データベースの指定]画面で、「Windows Internal Databaseを使用してサーバーにデータベースを作成します。」を選択。 [次へ] をクリック
[オプションの確認]画面で設定した内容の確認が表示される。確認後、問題なければ[次へ]をクリック
[前提条件のチェック]画面では、警告が表示されるが、「すべての前提条件のチェックに合格しました。」というメッセージが表示されていれば問題ないため、 [構成] をクリック
[閉じる]をクリックしてAD FS構成ウィザードを閉じる
再起動した方がよいかも...
ADFSの起動には時間がかかる場合があるので、気長に待つ。（インストール時に再起動していれば早い？）

Step-3. Cloud Identity との SAMLフェデレーションを設定

公式ドキュメントの、ここの部分以降を参照

構築時の個人メモ

ドキュメント内のDOMAIN は、私の場合 gw3.hgc.nanka-tsukuro.dev になる
- 証明書やAD-Server構築時のドメイン名と合わせる必要がある
- SAML 2.0 WebSSO Service URL は、私の場合 https://www.google.com/a/gw3.hgc.nanka-tsukuro.dev/acs になる
- Configure identifiers は、google.com/a/gw3.hgc.nanka-tsukuro.dev になる
ドキュメント内のADFS も、私の場合 gw3.hgc.nanka-tsukuro.dev になる
- ドキュメントにはFQNDを書くように記載があるが、ad-server.gw3.hgc.nanka-tsukuro.devを指定した際は動かなかった（ここだけの問題ではなかった可能性も高いが...）
- Trusted URL は、https://gw3.hgc.nanka-tsukuro.dev/adfs/ls/?wa=wsignout1.0
Google Workspace account の SSO 設定箇所のADFSも、上と同じくgw3.hgc.nanka-tsukuro.devになる

Step-4. 動作確認

シングルサインオンのテストまで行うことで、GoogleにログインしようとするとADFSの認証画面が立ち上がり、ここでADのID/PWを入力することで、Googleにログインできる環境が出来上がる

詳細は前述の動画を参照ください

V. IdPによって開始されるサインオンページの有効化

Step-0. このセクションでやることの理解

ADFS のサインオンページを有効化することで、Google のログイン画面からだけでなく、ADFS のページからのログインも可能にする
- 注：ただし、Google の SAML 実装は、SP から開始される SSO のみをサポートしているので、ADFS のページから SSO を開始しようとすると、エラーが表示される
  - エラー文は、Google Workspace - The required response parameter RelayState was missing.
- しかし上記設定を有効にしておくことで、事前にADFS へログインしておくことで、Google ログイン時にパスワードを入力する必要がなくなる
構築手順は、公式ドキュメントに沿って実行
動作イメージは、以下の通り（前述の動画とは異なります）

Step-1. サインオンページの有効化

ドキュメントのこの部分を参照

構築時の個人メモ

AD-Server にて、Windows PowerShell を開く
Get-AdfsProperties と入力して、Enter キーを押す
EnableIdpInitiatedSignonPage プロパティが false に設定されていることを確認する
PowerShell で、Set-AdfsProperties -EnableIdpInitiatedSignonPage $true と入力して、Enter キーを押す
Get-AdfsProperties コマンドをもう一度入力し、EnableIdpInitiatedSignonPage プロパティが true になったことを確認する

Step-2. 動作確認

ドキュメントのこの部分を参照

構築時の個人メモ

AD-Client にて、Web ブラウザーを開き、Idp サインオンページに移動（シークレットウィンドウを推奨）
1. URL は https://gw3.hgc.nanka-tsukuro.dev/adfs/ls/idpinitiatedsignon.aspx
「Sign in to this site.」を選択
AD登録したユーザーのID/PWを入力
「You are signed in.」と表示される
Google のページへアクセスし、ADのIDを入力して「次へ」を選択
IDとPWの入力をせずにGoogleにログインできる

VI. 統合 Windows 認証（IWA）を用いた SSO の実現

Step-0. このセクションでやることの理解

AD管理のユーザーでPCにサインインしている場合、「統合 Windows 認証（IWA*）」の機能を有効化することで、ADFS のサインオンページでのIDとPWの力を不要にできる
すなわち、以下のような動作を実現できる

注*：ドキュメントによって「統合 Windows 認証（IWA）」という名前や、「Windows 統合認証（WIA）」という名前が混在しています。この記事ではIWAの呼び方で進めていきます。

Step-1. AD-Server にて、IWA対象のブラウザを追加

これらの記事が参考になる → 記事1 （*Windows SSO の部分）/ 記事2 / 記事3

構築時の個人メモ

AD-Server にて PowerShell を開き、以下のコマンドを実行

# Chrome ブラウザを追加（EdgeもこれでOK）
Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents) + "Chrome")

# Chrome が追加されていることを確認
Get-AdfsProperties | Select -ExpandProperty WIASupportedUserAgents;

Step-2. AD-Client にて、インターネットオプションの設定を変更

ドキュメントのこの部分を参照

構築時の個人メモ

AD-Client にて、[スタート] を選択し、「インターネットオプション」と入力し、[インターネットオプション] を選択
[セキュリティ] タブを選択し、[ローカルイントラネット]、[サイト] の順に選択
ADFSのURL を入力し、[追加] をクリックし、画面を閉じる
1. 私の場合、ADFSのURLは、https://gw3.hgc.nanka-tsukuro.devになる
【補足】今回は手動でインターネットオプションの設定をしましたが、せっかくADを構築しているので、グループポリシーで設定を配布するのもよいと思います（未調査）

Step-3. 動作確認

Google にログインする際、ADFSの画面に一時的に遷移するものの、ID/PWを入力する必要がなくログインが完了し、Googleのページに戻ります。
動作イメージは、以下の通りです。（記事の一番上に掲載した動画と同じです。）

VII. （オプション）AD-Clientの参照先DNSを、AD-Serverから通常のDNSに変更した場合

上記の構成では、AD-Client の参照先のDNSサーバは、AD-Server になっています（II-4 で設定済）
この状態でも問題はないのですが、参照先のDNSを通常のDNSに変更する場合は、以下の手順でできました

作業内容メモ

DNSのホストゾーンに、AD-Serverの外部IPアドレスを、Aレコードとして追加
（以下の画像は、Route53でホストしている場合の参考画面）
セキュリティグループのインバウンドルールに以下2つのルールを追加
1. Type:HTTP(TCP-80) Source:AD-Clientの外部IPアドレス
2. Type:HTTPS(TCP-443) Source:AD-Clientの外部IPアドレス
AD-Client に Administrator でログインし、以下の２つ作業を実施
1. DNS の参照先をデフォルトに戻す
  1. 手順はII-4を参照
  2. Amazon Provided DNSの場合は10.0.0.2 を設定すればOK
2. NLA認証の無効化設定をする
  1. 参考サイト
  2. もしくは、ドメインに再参加すれば、NLA認証の無効化設定は不要という認識
    （試していないが、その場合はセキュリティグループのインバウンドルールにLDAPも追加する必要がありそう...）

まとめ & 最後に

「Cloud Identity へ同期をしたオンプレADにドメイン参加することで、Google へ SSO できる環境」をつくりました
私は様々なトラブルシューティングをしながら進めたので、休日を丸3日溶かしました
- 時間をかけて記事にまとめたので、次にやる際は1～2時間で作れたら嬉しいです
公式ドキュメントのみならず、先駆者の方々の様々なブログ記事を参考にさせていただきました。ありがとうございました
- 参考にした記事は、本記事内の当該箇所にてリンクを貼っています

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

「Cloud Identityへ同期をしたオンプレADにドメイン参加することで、GoogleへSSOできる環境」をつくってみる

この記事について

設定手順

I. はじめる前に

II. AWS 上に検証用のAD環境を構築する

Step-0. このセクションでやることの理解

Step-1. AWSにネットワークとサーバを用意

Step-2. AD-Server に、ADドメインコントローラーを構築

Step-3. AD-Server に、ユーザーの作成

Step-4. AD-Client で、参照先のDNSサーバをAD-Serverに変更

Step-5. AD-Client で、ドメインに参加

Step-6. 補足

III. GCDS-Server のセットアップ

Step-0. このセクションでやることの理解

Step-1. Cloud Identity に GCDS用の特権ユーザを作成

Step-2. AD-Serverにて、GCDS 用の Acrive Directory ユーザーを作成

Step-3. GCDS サーバに、GCDS をインストールし、各種設定

Step-4. 動作確認と補足

IV. ADのシングルサインオン設定を実施

Step-0. このセクションでやることの理解

Step-1. AD-Server にて、SSL証明書の作成

SSL証明書の作成

AD CSのインストール

AD CSの構成

証明書テンプレートの作成

証明書の発行

サービスアカウントの作成

KDSルートキーの作成

gMSAの作成

Step-2. AD-Server にて、ADFSのセットアップ

AD FSのインストール

AD FSの構成

Step-3. Cloud Identity との SAMLフェデレーションを設定

Step-4. 動作確認

V. IdPによって開始されるサインオンページの有効化

Step-0. このセクションでやることの理解

Step-1. サインオンページの有効化

Step-2. 動作確認

VI. 統合 Windows 認証（IWA）を用いた SSO の実現

Step-0. このセクションでやることの理解

Step-1. AD-Server にて、IWA対象のブラウザを追加

Step-2. AD-Client にて、インターネットオプションの設定を変更

Step-3. 動作確認

VII. （オプション）AD-Clientの参照先DNSを、AD-Serverから通常のDNSに変更した場合

まとめ & 最後に