今回は、AVD環境を構築するにあたり、既存のActive Directoryとは別にAVD専用の
Active Directoryを導入するパターンを検証してみたいと思います。
ドメインを追加する事で、「レプリカトラフィックの抑制」「セキュリティポリシーの分離」「管理権限の分離」などが行えます。

というのも、AVDの導入を検討するにあたり、このような要望があるためです。

・既存のActive Directoryに変更を加えたくない
・Active Directoryの担当者に依頼しづらい
・親会社がActive Directoryを管理しているため作業ができない
・構築を委託するベンダーにActive Directory内の情報を閲覧させたくない
・Active Directoryを含めて外部ベンダーに委託したいので、既存ADとは分離したい

通常だと、[AzureAD Domain Service]を利用するところですが、テナントごとに１つしか作成できないといった制限や、信頼関係が出力方向のみ、管理用のサーバーが必要など採用に至らない場合があります。

今回の元となる構成です。

既存Active Directoryは、M365利用のためにAAD Connectを利用し、AzureADと同期している環境です。本来なら、セッションホストは、既存ドメイン[wvd.com]に参加するのですが、今回は、新規にドメインを追加するパターンを確認していきます！
※セッションホストは、必ずしも同期済みADに参加する必要は無いと言う事です。

子ドメイン構成 (親子信頼)

【ポイント】

・[wvd.com]での作業は不要
・設定には[wvd.com]の「Enterprise Admins」アカウントが必要
・自動で[双方向の信頼]が設定される　※一方向は不可
・[child.wvd.com]のDNSフォワーダーを[168.63.129.16]に設定
・[child.wvd.com]の条件付きフォワーダーにて[wvd.com]を設定
・[child.wvd.com]にてユーザーアカウントの作成は不要
・GPOは[child.wvd.com]にてコンピュータオブジェクトに適用
・セッションホスト[Remote Desktop Users]に既存ADのアカウントが登録される
・アカウントポリシー、パスワードポリシーを分けられる。

双方向信頼のため、認証情報が共有されます。[wvd.com]側の認可(アクセス権)設定にて
拒否する必要があります。

ツリードメイン構成 (ツリールート信頼)

【ポイント】

・[wvd.com]での作業は不要
・設定には[wvd.com]の「Enterprise Admins」アカウントが必要
・自動で[双方向の信頼]が設定される　※一方向は不可
・[wwvd.com]のDNSフォワーダーを[168.63.129.16]に設定
・[wwvd.com]の条件付きフォワーダーにて[wvd.com]を設定
・[wwvd.com]にてユーザーアカウントの作成は不要
・GPOは[wwvd.com]にてコンピュータオブジェクトに適用
・セッションホスト[Remote Desktop Users]に既存ADのアカウントが登録される
・アカウントポリシー、パスワードポリシーを分けられる。

双方向信頼のため、認証情報が共有されます。[wvd.com]側の認可(アクセス権)設定にて
拒否する必要があります。

外部ドメイン構成 (フォレスト/外部信頼)

【ポイント】

・[wvd.com]での作業は不要
・設定には[wvd.com]の「Enterprise Admins」アカウントが必要
・手動で信頼設定が必要。　※双方向/一方向どちらでも可
・[wvdwvd.com]のDNSフォワーダーを[168.63.129.16]に設定
・[wvdwvd.com]の条件付きフォワーダーにて[wvd.com]を設定
・[wvdwvd.com]にてユーザーアカウントの作成は不要
・GPOは[wvdwvd.com]にてコンピュータオブジェクトに適用
・セッションホスト[Remote Desktop Users]に既存ADのアカウントが登録される
・アカウントポリシー、パスワードポリシーを分けられる。
・グローバルカタログを分けられる。
・Azure Filesを利用する場合は、[フォレスト信頼]が必要

一方向信頼にする事で、[wvd.com]への認証情報の共有を禁止する事ができます。
外部ベンダーに、[wvdwvd.com]のみの管理を委託する事ができる。
※当然ですが、[wvd.com]アカウントを渡さないでください。

認証シーケンス

[child.wvd.com]に所属するPCから、[child.wvdwvd.com]に所属するサーバーへの認証経路

①PCから[child.wvd.com]に認証を受けサインインを行う。サーバーへのサービスチケット要求を[child.wvd.com]に行うが、”DB””GC”に情報が無いので、信頼関係先である[wvd.com]の宛先をPCに返答する。
②PCから[wvd.com]に問い合わせるが”DB””GC”に情報が無いので、信頼関係先である[wvdwvd.com]の宛先をPCに返答する。
③PCから[wvdwvd.com]に問い合わせると情報があるので、[child.wvdwvd.com]の宛先をPCに返答する。
④PCから[child.wvdwvd.com]に問い合わせ、サービスチケットを取得する。
※サーバーへのアクセス可否(認可)はアクセス権限によります。
※信頼関係とは、認証情報の共有(信頼)である。

同期元のActiveDirectoryが複数存在する場合

ActiveDirectoryが複数存在する下記のような構成の場合、それぞれのドメイン名を利用してAzure Virtual Desktop にサインインする事ができます。

先ずは前提の確認、AzureADとActiveDirectoryでの認証には”同じドメイン名”を利用することも、”違うドメイン名”を利用する事も可能です。また、ユーザーごとに違うドメイン名を利用することも可能です。

最初にAzureADでの認証ですがここで利用できるドメイン名は、AzureADに登録された「ユーザープリンシパル名」のみとなります。
なので、[onmicrosoft.com]か[Custom Domain]が利用できます。

続きまして、ActiveDirectoryでの認証ですが、こちらは「ドメイン名」と「サフィックス名」が利用できます。
サフィックスは下記で設定した場合のみ利用可能となり、AzureAD側で同名のカスタムドメイン登録をしていると、AzureADの「ユーザープリンシパル名」が書き換わります。
※カスタムドメイン登録が無い場合は、規定のドメイン名(onmicrosoft.com)になります。