フェデレーション ドメイン用(AD FSあり) Hybrid Azure AD Join を一から構成する

# はじめに

AD FSを利用する Federation Domain 環境の Hybrid Azure AD Join の環境構築は、下記 Microsoft 公開情報を参考に行えば、構成は問題なく行えます。

チュートリアル:フェデレーション ドメイン用のハイブリッド Azure Active Directory 参加の構成
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/devices/hybrid-azuread-join-federated-domains

フェデレーション ドメインはマネージド ドメイン環境とは違い、前提として、Azure AD にカスタム ドメインがフェデレーションとして登録されている必要があります。
具体的には、「Azure ポータル」 → 「Azure Active Directory」 → 「カスタム ドメイン」の順にクリックし、下記画面ショットのとおり、カスタム ドメインのフェデレーションにチェックが入っていることを確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/8e9052c6-e4b9-3da6-c65b-65c412a996a8.png)

もしくは、AD FS サーバーで下記コマンド レットを実行することで確認ができます。
まず、PowerShell を管理者として実行します。

Connect-MsolService コマンド レットを実行します。
フェデレーション先の Azure AD のグローバル管理者の資格情報を入力します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/04adf1bf-f57b-aa59-2409-9fb9467d8b80.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/59b107da-8365-7ac6-55cb-734a60381495.png)

PowerShell にて「get-msoldomain」と実行すると、下記のとおり、カスタム ドメインがフェデレーション ドメインであることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/f01ac192-0882-6026-2930-89c63c2f29d0.png)

#環境について
Azure AD テナント (カスタム ドメインがフェデレーション ドメインとして登録済)
オンプレミス AD 兼 Azure AD Connect (1.3.21.0) on Windows Server 2019 Datacenter
AD FS サーバー on Windows Server 2019 Datacenter
Windows 10 (1809)

#Azure AD Connect の設定

フェデレーション ドメイン環境においては、以下 2 つの設定が必須となります。

1. SCP (サービス接続 ポイント)
2. クレーム ルール

以前までは上記を手動で構成する必要がありましたが、現在では Azure AD Connect により容易に構成することが可能になっています。
MS としても最新の Azure AD Connect を利用して上記を構成することを推奨しています。
従って、本手順でも Azure AD Connect を利用して SCP と クレーム ルールを構成します。

Azure AD Connect へようこその画面で「構成」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/6e3891d1-7141-b220-d6b4-cd5ed733efc1.png)

追加のタスクの画面で「ユーザー サインインの変更」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/594ee952-0bad-602c-d335-f7ca6d276b4e.png)

Azure AD に接続の画面にて Hybrid Azure AD Join を構成する Azure AD テナントの全体管理者(グローバル管理者) の資格情報を入力し「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/40024734-70d3-8895-913b-9152600a7432.png)

ユーザー サインインの画面にて、サインイン方式を「AD FS とのフェデレーション」を選択し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/e785e7d2-dbe9-5358-2a59-d23dc0236f1f.png)

ドメイン管理者の資格情報の画面にて、オンプレミス AD の資格情報を入力し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/e57f98ba-a565-783b-0876-18d0481d0e73.png)

AD FS ファームの画面にて、「既存の AD FS ファームを使用する」を選択した状態で「参照」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/0d30d009-a8fc-a586-d5a6-9c09dc7e8a1f.png)

フェデレーション サーバーの選択画面にて AD FS サーバーのホスト名を入力後、虫眼鏡マークにて検索を行い、構成済みの AD FS サーバーの情報が表示されることを確認し、「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/99aca6b2-30fc-15b1-6df5-0127a73b434b.png)

サーバー名に正しい値がセットされることを確認し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/e3b83963-4366-32d0-9339-31a4e12dd2e4.png)

Azure AD ドメインにて、オンプレミス AD とフェデレーション関係にある、カスタム ドメインを選択し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/25851706-d285-b733-24ab-e1fcb5a58f62.png)

Azure AD 信頼の画面にて、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/766bdc09-92c9-8ea9-fa68-061c54e27f84.png)

下記画面ショットのとおり、Azure AD の証明者利用者の信頼のバックアップ、Azure AD 証明書利用者信頼の更新、カスタム ドメインの Azure AD 信頼の構成が行われます。
「構成」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/6353d465-619d-ff48-457c-659eb84c8633.png)

構成が完了しましたの画面にて、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/b8c6d8a3-35f4-993a-1f0f-041deec2cc40.png)

接続の検証画面にて、フェデレーションの接続性の検証を行い、接続検証を行います。
問題がなければそのまま「終了」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/d142850a-d793-14b0-2f9d-c95ea2613521.png)

次に、Hybrid Azure AD Join の構成を行います。Azure AD Connect を再度起動し、「構成」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/74fdb438-825b-059c-9960-7fc87a6d8ebe.png)

追加のタスクの画面で「デバイス オプションの構成」を選択し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/5826d7f7-921d-0c27-b07a-e4a566c932da.png)

概要画面より「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/9612720a-4eb1-8e4b-d0e8-81e2985700be.png)

Azure AD に接続画面に Hybrid Azure AD Join としてデバイスを登録する Azure AD テナントの全体管理者(グローバル管理者) の資格情報を入力し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/3aa19f77-12aa-e44d-91fc-ac809b8e88a0.png)

デバイス オプションの画面にて「ハイブリット Azure AD 参加の構成」が選択されていることを確認し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/605963b4-6dfa-7f6c-fb2c-3d5ac1599c8a.png)

デバイスのオペレーティング システムの画面にて、「Windows 10 以降のドメインに参加しているデバイス」にチェックを入れて「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/bdbce544-7063-60ae-79c2-c19bfd477af0.png)

SCP の構成画面について説明します。
マネージド ドメイン環境においては、認証サービスが「Azure Active Directory」になりますが、フェデレーション ドメイン環境では「フェデレーション サービス名」が認証サービスになります。具体的には、 AD FS に対してコンピューター アカウントが認証されてトークンを取得し、 Azure AD DRS に対してデバイスを登録する動作になります。つまり、認証を Azure AD で行うのか、 AD FS が行うのか、という選択をここでしています。

今回はフェデレーション ドメイン環境の Hybrid Azure AD Join 環境を構成するので、「フェデレーション サービス名(sts.shyamag.work)」を選択します。
(デバイス登録のフローについては後述します)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/901088aa-46ed-ae26-133f-760c67a04d90.png)

認証サービスをフェデレーション サービス名を選択し、「追加」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/3aabf109-2840-90de-480b-f0db508953f6.png)

オンプレミス AD のエンタープライズ管理者の資格情報が要求されますので、資格情報を入力し、「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/218fd34c-4f36-2466-86fd-03efbf6c8456.png)

エンタープライズ管理者の情報がセットされることを確認し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/007c21cf-41db-b166-6c63-adb529e82a23.png)

フェデレーションの構成画面にて、 AD FS サーバーの管理者の資格情報を入力し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/dadcf03e-6d75-d52d-54e6-6cac30b4f60b.png)

Azure AD 信頼の画面にて、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/9678c1b0-68a7-df06-c9ef-d84b1c5ae76b.png)

構成の準備完了の画面にて「構成」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/8497c980-9a4b-57b9-682f-2d61430d0b80.png)

構成が完了しましたの画面にて、「終了」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/9a03d169-10be-2f61-f15b-07f2aed48b6a.png)

#クレーム ルールが追加されたことを確認する

Azure AD Connect のユーザー サインインの変更の Azure AD 信頼の画面にて、クレーム ルールが追加されました。
具体的には、下記手順にて確認ができます。

1. AD FS サーバーに管理者ユーザーでサインインします。
2. スタート → Windows 管理ツール → AD FS の管理の順にクリックします。
3. 証明書利用者信頼→ Microsoft Office 365 Identity Platform → 要求発行ポリシーの編集の順にクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/ea3c80e6-faf5-14ce-e0ec-af8113224538.png)

発行変換規則に下記のとおり、1 から 19 までのクレーム ルールが追加されていることを確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/d147d30f-207f-eb22-8671-1551ebce4725.png)

ちなみに以下が、クレーム ルールが追加される前の状態になります、明らかに増えていますね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/065ccb41-6842-4b93-b48e-3556d82ef5b3.png)

Hybrid Azure AD Join として必須のクレーム ルールは下記 の 3 つになります。
これらの情報は手動で Hybrid Azure AD Join を構成する際に参照する下記ドキュメントを参考にしてください。

チュートリアル:ハイブリッド Azure Active Directory 参加済みデバイスを手動で構成する
アカウントの種類の要求を発行する
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/devices/hybrid-azuread-join-manual#issue-account-type-claim

①クレーム名：Issue accounttype for domain-joined computers
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/e5ce42ba-fe27-e85c-5517-da52a4cef7e2.png)

オンプレミスのコンピューター アカウントの objectGUID を発行する
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/devices/hybrid-azuread-join-manual#issue-objectguid-of-the-computer-account-on-premises

②クレーム名：Issue onpremobjectguid for domain-joined computers
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/6e3c903e-6ee5-959a-a02e-16f2f1fc11e4.png)

オンプレミスのコンピューター アカウントの objectSID を発行する
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/devices/hybrid-azuread-join-manual#issue-objectsid-of-the-computer-account-on-premises

③クレーム名：Pass through primary SID
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/78c3649a-2093-65ca-45fd-4e6cc1510556.png)

#Hybrid Azure AD Join 構成までの流れ

マネージド ドメイン環境の Hybrid Azure AD Join の流れと、フェデレーション ドメイン環境の Hybrid Azure AD Join の流れは異なります。

復習もかねて、マネージド ドメイン環境の場合のフローは下記になります。

##### マネージド ドメイン環境の場合
1. Windows 10 コンピューターを、オンプレミス AD に参加します。
2. オンプレミス AD 上のコンピューター オブジェクトの userCertificate 属性に Windows 10 コンピューターを認証するための証明書が当該コンピューターにより、追加されます。
3. オンプレミス AD 上のコンピューター オブジェクトの userCertificate 属性値に証明書が追加されると、Azure AD Connect がコンピューター オブジェクトを Azure AD に同期します。 (通常は 30 分間隔)
4. 当該コンピューター上のタスク スケジューラにより証明書を使用して、 Azure Active Directory 上にデバイスが登録します。 
       (このタイミングで dsregcmd /status のコマンドレットをたたくと AzureADJoined の値が YES になります)
5. オンプレミス AD と Azure AD 間で同期しているユーザーで当該の Windows 10 コンピューターにサインインしたとき、Azure AD による認証後、サインインしたユーザーの PRT (Primary Refresh Token) が発行され、Hybrid Azure AD Join として Azure AD (Office 365) にサインインできます。  
        (このタイミングで dsregcmd /status のコマンドレットをたたくと AzureADPrt の値が YES になります)

図式化するとこんな感じです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/3249f6de-ebcf-1b48-7233-f30a194c5e2b.png)

#### フェデレーション ドメイン環境の場合

まずはフローを図式化したものを参照ください。
お気づきでしょうか、何かがありませんね、そう、Azure AD Connect がありません。
マネージド ドメイン環境の場合は、Windows 10 コンピューターの userCertificate 属性に証明書がセットされることをトリガーに、**Azure AD Connect** がデバイスを Azure AD に同期していましたね。

フェデレーション ドメイン環境の場合はフローが異なります。
SCP を構成したときを思い出してください、 Azure Active Directory ではなくて、フェデレーション サービス名 (AD FS) を指定しましたよね。
つまり、Windows 10 のコンピューター アカウントが SCP を参照した結果、認証先は Azure AD ではなくて AD FS サーバーであることがわかり、 AD FS に対してトークンを要求する動作となります。フローを箇条書きに書くと以下のような感じになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/550ed5a9-45c6-8723-e6c9-7d9fa2379da4.png)

1. Windows 10 コンピューターにユーザーがサインインした際に、Automatic-Device-Join のタスクが稼働します。
2. サービス接続ポイント (SCP) へ接続を行い Azure AD への接続を試行します。
3. Azure AD 側でフェデレーション ドメインであることを判定されます。
4. AD FS にコンピューター アカウントが認証され、認証トークンが発行されます。
5. クライアント端末が発行されたトークンを Azure AD に提供し、デバイス登録が実施されます。
     (このタイミングで dsregcmd /status のコマンドレットをたたくと AzureADJoined の値が YES になります)
6. デバイス認証用の証明書鍵がデバイス内にインポートされます。
7. オンプレミス AD と Azure AD 間で同期しているユーザーで当該の Windows 10 コンピューターにサインインしたとき、AD FS による認証後、サインインしたユーザーの PRT (Primary Refresh Token) が発行され、Hybrid Azure AD Join として Azure AD (Office 365) にサインインできます。  
        (このタイミングで dsregcmd /status のコマンドレットをたたくと AzureADPrt の値が YES になります)
	
上述のとおり、フェデレーション ドメイン環境の場合は Azure AD Connect で同期を行わなくても Hybrid Azure AD Join が構成できますが、以下の理由で Azure AD Connect によるデバイス同期を行うことを推奨しています。

例えば、オンプレミス AD 側の構成が変更されて、オンプレミス AD と Azure AD 間のデバイス構成情報に差分が発生したとします。
その場合、Azure AD Connect がないと、デバイスの差分を補ってくれません。
極端な話をすると、オンプレミス AD 側で 1000 台 Hybrid Azure AD Join を構成するフォレストから別のフォレストに移動した場合、Azure AD Connect がないと、デバイス情報を手動で削除しない限りは、Azure AD 側に残ったままになります。

上記のような運用面のコストを考えると、Azure AD Connect  によりデバイスを同期しておくことをお勧めします。

ちなみに、フェデレーション ドメイン環境の場合も Windows 10 コンピューターの userCertificate 属性に証明書がセットされる動作になります。
実際に見てみましょう。

今回、Windows10-18091 というコンピューターを Hybrid Azure AD Join させますが、下記のとおり、userCertificate 属性に証明書がセットされていますね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/e64e9031-d656-5318-5ce3-d66ff187f077.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/b09c1453-0a3d-0e62-70fd-beca1a522c09.png)

続いて、Azure AD Connect  側の同期ポリシーを見てみましょう。

Azure AD Connect の同期ルールを見てみると、 userCertificate 属性が ISNOTNULL (証明書がセットされていることが必須) であることが分かります。
[Synchronization Rules Editor] から Direction を「Outbound」を選択し、[Out to AAD - Device Join SOAInAD]を選択後に「View」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/c51b6b7e-f59b-6ac0-a4ee-15a4a2412478.png)

Scoping Filter をクリックすると、 userCertificate が ISNOTNULL であることがわかります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/69599f07-92e2-7491-91ca-33d1b75a9d54.png)

つまり、フェデレーション ドメイン環境にて Hybrid Azure AD Join を構成し、Azure AD Connect にてデバイス同期を行っている場合 、マネージド ドメイン環境と同じように、userCertificate 属性に証明書がセットされている場合も Azure AD にデバイスが Hybrid Azure AD Join として同期されますし、上記のフェデレーション ドメインのフローによりデバイスが Hybrid Azure AD Join として登録されるという **2 通りの方法が存在する**ということになります。
(厳密にどちらの方法でデバイスが登録されたかを都度都度追いかける必要はありません。方法が 2 通りあるということを覚えていただければと思います。)

#####エンド ポイントの注意点
上記フェデレーション ドメインのフロー図において、AD FS にトークンを取得するためにアクセスするエンド ポイントは「/adfs/services/trust/13/windowstransport」と記載されていますね。つまりこのエンドポイントが有効になっていないと、デバイスの登録に失敗します。
下記画面ショットにありますが、デフォルトでは「/adfs/services/trust/13/windowstransport」が無効になっているので手動で有効にする必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/c052d88b-cf35-01cf-6f4e-88d0f4136eeb.png)

エンドポイント「/adfs/services/trust/13/windowstransport」を選択し、右クリックより「有効」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/014f1b2b-30c1-b217-af7a-74b60956bb4c.png)

AD FS サービスの再起動を要求されるので、「OK」を押して画面を閉じます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/742b1dcb-0ab0-32fd-8bae-97ab8188aec3.png)

再度同じエンドポイントを選択し右クリックより「プロキシに対して有効にする」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/534b3bb1-b747-135b-788b-12e763279c06.png)

同じように AD FS サービスの再起動を要求されるので、「OK」を押して画面を閉じます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/04de44bd-2a32-031c-65b1-267a1ff51f64.png)

サービス画面より Active Directory フェデレーション サービス (AD FS)を右クリックし、「再起動」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/d7c1129c-ddc8-65a0-824c-c520f21a0598.png)

この時点で Azure AD Join は完了しているはずなので確認してみます。
Windows 10 コンピューターにログオンし、dsregcmd /status コマンド レットを実行すると、下記のとおり、AzureAdJoined が YES になっていることが分かります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/08f021e1-411d-3df3-63c8-e55fa1ee19f7.png)


#PRT を取得する。

PRT を取得するためには、Azure AD に同期済みのオンプレミス AD ユーザーでログオンする必要があるのは、フェデレーション ドメインの場合でも同様です。
Azure AD に同期済みの下記「test001@shyamag.work」で Windows 10 コンピューター (Windows10-18091)にログオンします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/46086bb5-9c1c-4021-364c-7d1a986ad2b6.png)

資格情報を入力してログオンします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/a82758cc-3a30-bc0a-2545-2a80e6575484.png)

コマンドプロンプトを起動し、このタイミングで dsregcmd /status のコマンドレットをたたくと AzureADPrt の値が YES になることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/6c5af364-be39-ab2e-7cd0-b597abc57bde.png)

#おわりに
今回はフェデレーション ドメイン環境における Hybrid Azure AD Join の構築手順をご紹介しました。
フェデレーション ドメイン環境の場合も Azure AD Connect により、SCP およびクレーム ルールを構成することができます。

本 Blog ではマネージド ドメイン環境とフェデレーション ドメイン環境の Hybrid Azure AD Join の登録フローの違いを説明しました。
フェデレーション ドメイン環境の場合は、 Azure AD Connect は必須ではないですが、オンプレミス AD 側はデバイスの削除を行うと、同期を行えないため Azure AD 上でのデバイス情報に差分が発生する、というデメリットがあります。

確実にデバイスを管理したい、という方は Azure AD Connect によるデバイス同期をお勧めします。
(今回 Hybrid Azure AD Join も Azure AD Connect で構成してますので、 Azure AD Connect を使わない手はないと思います)

今回の Blog が少しでも環境構築の参考になれば幸いです。