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

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

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


<iframe width="560" height="315" src="https://www.youtube.com/embed/uGdLGUtcgoU?si=qDHa6Sdp-4I_0Sp6" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>


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


# 設定手順

## 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クライアントで、ドメインに参加します
- ここまでの手順で、通常のドメイン参加までができる状態になります
- 構成図は以下の通り

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/a657dfb3-f368-337e-75a8-4ae9b59833a8.png)



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

<details><summary>クリックして詳細を展開</summary>

- 「VPCを作成」の画面から、パブリックサブネット付きのVPCを構築
（VPCのCIDRなどは、構成図の通り）  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/c74f47d5-8cde-02a9-f5b0-fe0fdca8659f.png)
- セキュリティグループを作成  
インバウンドルールに、家からのRDPと、サブネット内の通信を許可するルールをつける  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/eb07f27c-e040-681b-9e64-0520cb2e4aa1.png)
- 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台分実施する）  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/5bb49d5d-51ed-c54f-8ceb-784365f9a463.png)
- EC2にリモートデスクトップ接続できることを確認
    - 家からRDPするにあたって、Elastic-IP （固定IP）を付与しておくとよいかも
    - EC2からEC2にpingしても返答がない。これは、[WIndows Defender ファイアウォールがブロックしている](https://www.server-world.info/query?os=Windows_Server_2022&p=initial_conf&f=6)ため
    - 今後の作業のために、[コンピュータ名（ホスト名）を`AD-Server`などに設定しておく](https://inab818.site/microsoft-windows-server-2022/hostnamechange082917/)ことを推奨  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/0922fb45-0718-61c4-4939-e33a61081dc3.png)

</details>

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

手順は、[こちらの記事](https://www.hitoriit.com/entry/2018/08/24/080300)が参考になる

<details><summary>ドメコン構築手順の個人メモ</summary>

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

</details>


### Step-3. AD-Server に、ユーザーの作成
手順は、[こちらの記事](https://thinkit.co.jp/story/2015/09/29/6431)が参考になる
なお、一般ユーザーだと、[追加の設定をしない限りリモートデスクトップ接続ができず](https://rainbow-engine.com/winserver-allow-rdp/)不便なので、Administrator権限のユーザを作成する

<details><summary>ユーザー作成手順の個人メモ</summary>

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

</details>



### Step-4. AD-Client で、参照先のDNSサーバをAD-Serverに変更
AD-Clientに Administrator でログインし、参照先のDNSサーバをAD-ServerのIPアドレスに変更する
手順は、[こちらの記事](https://faq.interlink.or.jp/faq2/View/wcDisplayContent.aspx?sso_step=1&id=639)が参考になる

<details><summary>DNS変更手順の個人メモ</summary>

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

</details>


### Step-5. AD-Client で、ドメインに参加
ドメイン参加する。手順は、[こちらのドキュメント](https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/deployment/join-a-computer-to-a-domain)が参考になる

<details><summary>ドメイン参加の個人メモ</summary>

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

1. ドメイン参加後、 `gw3.hgc.nanka-tsukuro.dev\user1` もしくは `user1@gw3.hgc.nanka-tsukuro.dev` 等でサインインできるようになる  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/bffb1569-d316-4ac0-e912-e6f3a7ae46d4.png)

</details>

### Step-6. 補足
- GCDS-Server は、ドメインに参加する必要はありません
- ここまでの手順と似たことを、過去に Hyper-V 環境で実施しました  
[こちらのページを参照ください](https://qiita.com/hayate_h/items/e569a500e85b46491aa4)


## III. GCDS-Server のセットアップ
### Step-0. このセクションでやることの理解
- GCDSサーバ（Google Cloud Directory Syncを動かすサーバ）をセットアップします
- ADサーバで作成したユーザーが、Cloud Identity に同期されることを確認します
- 手順は、[公式ドキュメントに沿って実行](https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-synchronizing-user-accounts)しています
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/27f4aa5b-ebed-a429-ea23-67048175a2bc.png)


### Step-1. Cloud Identity に GCDS用の特権ユーザを作成
[公式ドキュメントの、ここの部分の通り](https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-synchronizing-user-accounts?hl=ja#creating_a_cloud_identity_user_account_for_synchronization)

### Step-2. AD-Serverにて、GCDS 用の Acrive Directory ユーザーを作成
[公式ドキュメントの、ここの部分の通り](https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-synchronizing-user-accounts?hl=ja#creating_an_active_directory_user_for_gcds)

### Step-3. GCDS サーバに、GCDS をインストールし、各種設定
[公式ドキュメントの、ここの部分以降](https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-synchronizing-user-accounts?hl=ja#installing_gcds)

<details><summary>構築時の個人メモ</summary>

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

LDAP Configuration
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/dae10cf5-ce90-4dcc-710c-8581c7aca197.png)
User Accounts
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/39542a76-38b9-7ab2-f133-0778cf75a95c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/6bf2b831-677d-21bb-384a-0fcb020c5e1f.png)

</details>


### Step-4. 動作確認と補足
- 「[最初のユーザーのプロビジョニング](https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-synchronizing-user-accounts?hl=ja#initial_user_provisioning)」セクションまで実施すると、Cloud Identity にADのユーザー情報が同期される
- 同期されたユーザー情報は、管理者権限で[Cloud Identity のコンソール](https://admin.google.com)にログインし、「ディレクトリ」→「ユーザー」に進むことで確認できる
- ただしADのパスワード情報は同期されないので、Google のログインページに行って、ADと同じID/PWを入力してのログインはできない  
（以下のスクリーンショットは、ADのID/PWを使って、Google にログインできない画面ショット。IDは同期されているものの、パスワードは違うことが分かる）  <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/59b426f1-4119-e5f0-16cb-c96b01a4edaa.png" width="500">


## IV. ADのシングルサインオン設定を実施
### Step-0. このセクションでやることの理解
- 目指すことは...
    - Cloud Identity のIDプロバイダーとして、ADFSサーバを使用できるようにする状態の実現
    - これにより、GoogleにログインしようとするとADFSの認証画面が立ち上がり、ここでADのID/PWを入力することで、GoogleにSSOできる環境が出来上がる  

このセクションを完了した際の動作イメージは、以下の通り
（記事の一番上に掲載した動画とは異なります。特に後半の動きが違います。）
<iframe width="560" height="315" src="https://www.youtube.com/embed/AW6_5fHxx0o?si=UPR3hzAbNfSrTU_m" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

- 作業はかなり複雑で...
    - 最初に、ADFS の構築（途中にADCSの構築と証明書発行関連作業も必要）
    - 次にSAMLフェデレーションの設定をする
- 手順は...
    - ADFS の構築は、[こちらのドキュメントの p10～p22](https://support.createwebflow.jp/doc/files/saml_adfs.pdf)が参考になる
    - SAMLフェデレーションの設定は、[公式ドキュメント](https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-configuring-single-sign-on)が参考になる

### Step-1. AD-Server にて、SSL証明書の作成
[こちらの資料のp10～p19が参考になる](https://support.createwebflow.jp/doc/files/saml_adfs.pdf#page=10)

<details><summary>SSL証明書作成手順の個人メモ</summary>

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

##### AD CSのインストール

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

##### AD CSの構成

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

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

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

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

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

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

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

##### 証明書の発行
1. [ファイル名を指定して実行] (Winキー + R)で「MMC」を入力し、コンソールを起動
2. [ファイル]メニューから[スナップインの追加と削除]をクリック
3. [利用できるスナップイン]から[証明書]を選択し、[追加]をクリック
4. [証明書スナップイン]画面で[コンピューターアカウント]を選択し、[次へ]をクリック
5. [ローカルコンピューター]を選択して[完了]をクリック
6. [スナップインの追加と削除]画面で[OK]をクリック
7. 画面左から[証明書]を展開し、[個人]の項目を右クリックして[すべてのタスク]から[新しい証明書の要求]をクリック
8. [証明書の登録]画面で[次へ]をクリック
9. [証明書の登録ポリシーの選択]画面で「Active Directory登録ポリシー」が選択された状態で[次へ]をクリック
10. [証明書の要求]画面で作成した証明書テンプレートをチェックし、 [この証明書を登録するには情報が不足しています。設定を構成するには、ここをクリックしてください]をクリック
11. [証明書のプロパティ]画面の[サブジェクト]タブで以下を入力し[Add]したのち、[OK]をクリック
    | 設定 | 種類 | 値 |
    | --- | --- | --- |
    | サブジェクト名 | 共通名 | ドメイン（私の場合は`gw3.hgc.nanka-tsukuro.dev`）|
    | 別名 | DNS | ドメイン（私の場合は`gw3.hgc.nanka-tsukuro.dev`） |

12. [証明書の要求]画面で、作成した証明書テンプレートが選択し、[登録]をクリック
13. 証明書の登録が完了すると、 [証明書インストールの結果]画面に「状態：成功」と表示される。[完了]をクリックし画面を閉じる

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

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

##### KDSルートキーの作成

gMSAのパスワードを生成するために必要なKDSルートキーを作成する
PowerShell アイコンを右クリックで「管理者として実行」から起動し、以下のコマンドを実行する
※ エラーが出た際は、[このドキュメントのコマンド](https://learn.microsoft.com/ja-jp/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key#to-create-the-kds-root-key-in-a-test-environment-for-immediate-effectiveness)を試す（コピペの問題かもしれない）
```powershell
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
```

##### gMSAの作成

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

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

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

(私の場合は...)

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

</details>


### Step-2. AD-Server にて、ADFSのセットアップ
[こちらの資料のp20～p22が参考になる](https://support.createwebflow.jp/doc/files/saml_adfs.pdf#page=20)

<details><summary>ADFSセットアップ手順の個人メモ</summary>

#### AD FSのインストール

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

#### AD FSの構成

1. サーバーマネージャーの上部フラッグに警告マークが表示されているので、クリック
2. 表示されたメニュー、展開後の構成から[このサーバーにフェデレーションサービスを構築します]をクリックし、Active Directoryフェデレーションサービス構成ウィザードを起動
3. 今回は新しいフェデレーションサーバーを作成のため、「フェデレーションサーバーファームに最初のフェデレーションサーバーを作成します。」を選択。[次へ]をクリック
4. [Active Directory ドメインサービスへの接続]画面で、AD DSのドメイン管理者のアクセス許可をもっているアカウントを指定
5. [サービスのプロパティの指定]画面で以下を設定し、[次へ]をクリック
    | 設定 | 設定値 |
    | --- | --- |
    | SSL証明書 | 「IV-1. SSL証明書の作成」で作成したSSL証明書 （私の場合は、`gw3.hgc.nanka-tsukuro.dev` ここで、`AD-Server`が付くものを選ぶと、**後半で証明書エラーがありうまくいかなかった**） |
    | フェデレーションサービス名 | 証明書の登録後に自動的に設定される。 |
    | フェデレーションサービスの表示名 | 任意の文字列。（ここで設定した値が、認証画面に表示される）（私の場合は、`GW3-SSO`と設定）|

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

</details>

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

[公式ドキュメントの、ここの部分以降を参照](https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-configuring-single-sign-on#configuring_adfs)

<details><summary>構築時の個人メモ</summary>

- ドキュメント内の`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`になる

</details>

### Step-4. 動作確認

[シングル サインオンのテスト](https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-configuring-single-sign-on?hl=ja#testing_single_sign-on)まで行うことで、GoogleにログインしようとするとADFSの認証画面が立ち上がり、ここでADのID/PWを入力することで、Googleにログインできる環境が出来上がる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/4604fc4a-0b86-9639-ec37-ba11df8bdf31.png)

詳細は[前述の動画](https://youtu.be/AW6_5fHxx0o)を参照ください

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

### Step-0. このセクションでやることの理解
- ADFS のサインオンページを有効化することで、Google のログイン画面からだけでなく、ADFS のページからのログインも可能にする
    - 注：ただし、[Google の SAML 実装は、SP から開始される SSO のみをサポートしているので、ADFS のページから SSO を開始しようとすると、エラーが表示される](https://support.pingidentity.com/s/article/SSO-to-Google-Apps70144NEW)
        - エラー文は、`Google Workspace - The required response parameter RelayState was missing.`
    - しかし上記設定を有効にしておくことで、事前にADFS へログインしておくことで、Google ログイン時にパスワードを入力する必要がなくなる
- 構築手順は、[公式ドキュメントに沿って実行](https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-initiatedsignon)
- 動作イメージは、以下の通り（前述の動画とは異なります）  
<iframe width="560" height="315" src="https://www.youtube.com/embed/U29c1gEioNw?si=blHCwlH1rJ2lM-xX" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>


### Step-1. サインオンページの有効化
[ドキュメントのこの部分を参照](https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-initiatedsignon#enable-the-idp-initiated-sign-on-page)

<details><summary>構築時の個人メモ</summary>

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

</details>

### Step-2. 動作確認
[ドキュメントのこの部分を参照](https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-initiatedsignon#test-authentication)


<details><summary>構築時の個人メモ</summary>

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

</details>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/95d86881-1dad-5365-3cfa-2be29a21e50f.png)


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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/4cccac80-af76-5a04-7fbb-0c8f4b09a512.png)




注*：ドキュメントによって「[統合 Windows 認証（IWA）](https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/integrated-windows-authentication)」という名前や、「[Windows 統合認証（WIA）](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wia?WT.mc_id=M365-MVP-5002496)」という名前が混在しています。この記事ではIWAの呼び方で進めていきます。

### Step-1. AD-Server にて、IWA対象のブラウザを追加
これらの記事が参考になる → [記事1 （*Windows SSO の部分）](https://plugins.miniorange.com/ja/guide-joomla-single-sign-sso-using-adfs-idp)/ [記事2](https://help.hcltechsw.com/domino/12.0.2/ja/admin/secu_enabling_iwa_adfs30.html) / [記事3](https://mitomoha.hatenablog.com/entry/2020/08/25/023043)

<details><summary>構築時の個人メモ</summary>

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

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

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

</details>

### Step-2. AD-Client にて、インターネットオプションの設定を変更
[ドキュメントのこの部分を参照](https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-initiatedsignon#test-authentication-with-seamless-sign-in)

<details><summary>構築時の個人メモ</summary>

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

</details>

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

<iframe width="560" height="315" src="https://www.youtube.com/embed/uGdLGUtcgoU?si=qDHa6Sdp-4I_0Sp6" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>


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

<details><summary>作業内容メモ</summary>

1. DNSのホストゾーンに、AD-Serverの外部IPアドレスを、Aレコードとして追加
（以下の画像は、Route53でホストしている場合の参考画面）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/1020107b-9e7b-eb4f-22d4-63d684dba619.png)

1. セキュリティグループのインバウンドルールに以下2つのルールを追加
    1. Type:`HTTP(TCP-80)`  Source:`AD-Clientの外部IPアドレス`
    1. Type:`HTTPS(TCP-443)`  Source:`AD-Clientの外部IPアドレス`
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341404/eadb8f8d-22f5-18e0-83f9-8fb935d5c21c.png)


1. AD-Client に Administrator でログインし、以下の２つ作業を実施
    1. DNS の参照先をデフォルトに戻す
        1. [手順はII-4を参照](https://qiita.com/drafts/e43f1b3d3c91c8150062/edit#step-4-ad-client-%E3%81%A7%E5%8F%82%E7%85%A7%E5%85%88%E3%81%AEdns%E3%82%B5%E3%83%BC%E3%83%90%E3%82%92ad-server%E3%81%AB%E5%A4%89%E6%9B%B4)
        1. Amazon Provided DNSの場合は`10.0.0.2` を設定すればOK
    1. NLA認証の無効化設定をする
        1. [参考サイト](https://tarufu.info/network-level-authentication/)
        1. もしくは、ドメインに再参加すれば、NLA認証の無効化設定は不要という認識
（試していないが、その場合はセキュリティグループのインバウンドルールにLDAPも追加する必要がありそう...）

</details>

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