Windows Virtual Desktop の認証・認可のデータベース（リポジトリ）として Active Directory Domain Service (ADDS) が必要です。 以前の Windows Virtual Desktop Fall 2019 (いわゆる Classic)の検証時は Alibaba Cloud 上のECS の仮想インスタンスのWindows Server に ADDS を構築していたのですが今回は Azure AD Domain Services (AADS) を立ち上げ、このAADS をWVD の認証・認可に利用する構成をテストします。
この記事ではAADS のインスタンスの作成、仮想マシンのドメイン参加、Active Directory の管理ツールでの操作、FSMO構成などを簡単にまとめています。
目次
1. Azure AD Domain Services を購入
1.1. リソースの作成
Azure Portal にサインインし、リソースの作成画面に移動します。
“Azure AD domain Services “を検索します。
”作成”をクリックします
1.2. Azure AD Domain services の作成 > 基本
インスタンスのパラメタを設定していきます。
- DNS ドメイン名は重要。 ADDS の構成にかかわる。
- 地域もWVD のVirtual Machine (Windows 10 ) との接続性を考慮
- SKU は要件に応じて選択
- フォレストの種類では”ユーザー フォレスト” と”リソースフォレスト”の2つから選択
- WVD の利用ではユーザー フォレストで問題なし （認証・認可にこのAADS を使用する）
- 既存のフォレストを認証・認可先とし、このAADS はコンピュータなどのリソースのみを配置し、信頼関係を構成する場合はリソースフォレストを利用（AADS 登場したころは信頼関係は未対応でしたが今は可能になった模様）
“DNS 名の選択に関するヘルプ”の情報は以下の通り。
”フォレストの種類の選択に関するヘルプ”の情報は以下の通り。
“SKUの選択に関するヘルプ” は以下の通り。
1.3. Azure AD Domain services の作成 > ネットワーク
ネットワークのパラメタでは仮想ネットワーク(VNET)とサブネットを指定します。 WVD の仮想マシンを配置するVNET とするかそのVNET と通信できるVNET を指定します。 要は今回作成する AADS と Windows 10 仮想マシンは通信できる必要があるということです。
1.4. Azure AD Domain services の作成 > 管理
管理では”AAD DC 管理者”のメンバーシップの指定と通知を構成します。
”AAD DC 管理者”は従来のAADS には無かった概念（グループ）です。
”グループ メンバーシップの管理” をクリックします。 AAD DC Administrators に含めるAzure AD 上のユーザを選択し、”メンバーの追加”を実施します。
”AAD DC 管理者の選択に関するヘルプ” の情報は以下の通り。
1.5. Azure AD Domain services の作成 > 同期
同期の範囲を指定します。 Azure AD 上のユーザ、グループについてすべてAADS に同期するか、範囲を限定するか指定します。
”同期の種類の選択に関するヘルプ”の情報は以下の通り。
1.6. Azure AD Domain services の作成 > 確認および作成
内容を確認し”作成”をクリックします。
”知っておくべきこと”として以下が案内されます。 作成後に変更できないものとしてDNS名やサブスクリプション、リソースグループ、仮想ネットワーク、サブネットなどがあげられています。 また同期の範囲やフォレストの種類も変えられないということでほとんど変更の余地なしです。
構成を間違えれば再作成です。 また、AADSを利用するアプリケーションが不明な状況（よくあることかと）やシステムの統合・移行などで変更が予見出来るケースでは問題になる可能性が高そうです。 オブジェクトの移行ツールなどがあればよいのですがそのようなものが無い現状、一度運用したディレクトリを再作成は現実的ではないかなと。
1.7. デプロイ完了
デプロイは結構時間がかかります。 1時間を見ておきましょう。(実績ベースでは40分前後）
無事デプロイが完了すると”デプロイが完了しました” とメッセージが表示されます。
”リソースに移動”をクリックします。
この時点では”マネージド ドメインをプロビジョニング中です。 この操作には時間がかかる場合があります”とのことでまだ利用可能な状態とはなっていません。
“正常性の表示”をクリックします。
正常性は特に問題がないことを確認できます。 このあとちょっとして（5～10分のレベル）プロビジョニングも完了したことを確認しています。
2. Azure AD Domain Services の設定
2.1. 仮想ネットワークのDNS サーバー設定
デプロイしたAADS を利用するAzure 上の仮想マシンインスタンスについて、DNS クライアント設定を変更します。 仮想マシンが今回作成したフォレストをDNSのSRVレコードを通して見つけるには仮想マシンがAADSで提供されるDNSサーバを参照できる必要があります。
AADS の管理画面の概要から構成を進めます。 ”構成”をクリックするとVNETのDNS設定が変更されます。 特に確認もなく実施されます。
上記の操作のあとに警告として”仮想マシンを再起動しましょう”旨のメッセージが表示されます。 仮想マシンはDHCPでIPアドレスやDNSクライアント情報を取得しているためです。
実際にどこの設定が変更されたかですが、仮想ネットワーク（VNET）の設定から”DNS サーバー”を確認します。
カスタム設定で2つのIPアドレス”10.0.0.4″と”10.0.0.5″が追加されています。
2.2. 仮想マシンでのDNS 設定の確認
仮想ネットワーク上に別途展開した仮想マシンで確認します。
コマンドプロンプトでipconfig /all を実行し、DNS Servers を確認します。 AADS で提供されるDNS サーバーを参照していることを確認できます。
3. 仮想マシンのドメイン参加
Azure 上に構築したAADS のフォレストにWindows Server をドメイン参加します。
システムのプロパティから”Change settings”をクリックします。 なお画面は言語設定がEnglishのWindows Server 2016です。
”Change”をクリックします。
Active Directory ドメインを指定します。
ドメインの参加資格のあるユーザを入力します。 ここら辺は従来のActive Directory と違いはありません。
ドメイン参加した状態。
4. Azure AD Domain Services の管理
Azure AD Domain Services の管理には別のWindows 環境が必要です。 Azure 上の仮想マシンでもよいですし、ネットワーク通信が可能なオンプレミスの物理/仮想マシン、他クラウド上の仮想マシンでも問題ありません。
今回はAzure 上で同じVNET に所属する仮想マシン（Windows Server 2016)上にActive Directory の管理ツールをインストールし、AADS に接続します。
4.1. 管理ツールのインストール
サーバーマネージャから役割と機能の追加を実施します。
”Add roles and features”をクリックします。
Features から”AD DS and AD LDS Tools”を選択し、機能を追加します。 この機能はActive Directory の管理ツールです。 LDS はLightweight Direcory Services ということでActive Directory を単純なLDAP サーバとして提供するRoleがあるのですがそのための管理ツールです。 LDS は同期なども簡単に構成できますしユーザーに見えないところでLDSをリポジトリに利用しているシステムはよく見かけます。 VMware Horizon のブローカーなどもそうでしたね。
4.2. ユーザーとコンピューターの管理
従来のADDS でも使われているActive Directory ユーザーとコンピューターの管理を開きます。
サーバーマネージャのToolsメニューから起動します。
当たり前ですが従来と見え方は一緒です。 もちろん、既定のオブジェクトに違いはあります。 以下の画面でも右ペイントップの”AAD DC Service Accounts”は従来のADDS にはなかったですし、左ペインのOUでもAADから始まる見慣れないOUが複数あります。
4.3. Azure AD Domain Services の FSMO
FSMOを確認します。 ユーザーとコンピューターの管理ツールからはRIDとPDCとInfrastructure のFSMO を確認できます。
RIDは以下の通りです。 HXYCQE4JRQH4S53というコンピュータが現在のRIDのマスタです。 転送可能なコンピューターが1台ということでこのフォレスト・ドメインには2台のドメインコントローラが存在することがわかります。
PDCもRIDと同じ状況。
InfrastructureもRIDとPDCと同じです。
手順は省略しますが信頼関係の管理ツールからドメイン名前付のFSMOを確認します。 マスタはRIDなどと一緒ですが転送先は何故か自分自身です。 手元にActive Directory 環境がなかったのでこういうものだったのか思い出せず（RIDなどと同様もう一台のDomain Controller が転送先としてリストされそうなものですが）。
スキーママスタの確認はツールのインストールが必要であとにしようと思ったまま忘れて今回の環境を削除してしまったので実施出来るか不明です。 ただ、 Azure AD Domain Services は Schema を全く変更出来ないので多分使えないでしょう。良くて、Schema を参照できるだけになるかと。
確認出来た2台のDomain Controller はユーザーとコンピューターの管理ツールの”Domain Controllers”にコンピューターオブジェクトが存在することが確認できます。
4.4. Azure AD Domain Services のグループポリシー管理
グループポリシーを利用する場合はActive Directory と同様に管理用のコンピューターにツールを構成します。
Features から”Group Policy Management”を選択しインストールします。
インストール後、Group Policy Management ツールを開くとグループポリシーを作成したり管理することが可能です。 既定のGroup Policy Objects に違いはありますが操作などは従来と同じです。
5. まとめ
マネージドのActive Directory として利用できるAzure AD Domain Services のインスタンス作成から管理の方法まで一通り確認することが出来ました。
フォレスト・ドメインの展開については従来だと仮想マシンを作って、DNSやDomain Services の役割・機能を追加して、そしてDC昇格などちょっとした作業の実施が必要でした。 AADS ではパラメタさえ決まっていれば1時間もあれば出来上がります。 そして運用面でDomain Controller の管理から解放されること、これが一番のメリットであることは間違いありません。
しかし、Windows Virtual Desktop (WVD) の利用を考えた場合にいくつか課題があることも事実です。
まず、AADS のドメイン名やネットワークや同期内容など一度展開するとあとから変更ができないこと、つまり、将来の変更や移行も含めてしっかりと設計する必要があります。
例えば WVD の仮想マシンと同じ VNET にしている設計の場合、将来の拡張時にVNET上限などの制限を受けるかもしれません。 最初からAADS のVNETを独立し、WVD の仮想マシンのVNETとはVNET Peering などで接続する拡張性と柔軟性のあるトポロジーを設計したほうがよさそうです。
ドメイン名の変更が出来ない点。 会社の統廃合などでドメイン名を変更することはなくもありません。 今の仕様ではドメイン名を変更するには新規にAADS を構成し、仮想マシンはすべてドメイン再参加する必要があります。 リンククローンが利用できるHorizon、MCSやPVSが利用できるCitrix ならドメインの再参加といっても1,000や2,000台レベルの規模なら一晩もあれば簡単に変更できます。 しかし、今のWVD では1,000台のドメイン再参加はかなり大変です。
同期の範囲も変更出来ません。 利用してみるまでは Azure AD Connect のようにOUだったりで柔軟に変更できるものと思っていたのですが、あとから変更できません。 将来を見越した設計が出来ていればよいですが、なかなか大変です。 すべて同期しておけば柔軟性はありますがセキュリティの考慮、セキュリティの大原則といえる最小・最低と反する、も必要です。
フォレストのタイプでは”ユーザ フォレスト”と”リソース フォレスト”の2タイプがありこれも後から変更することは出来ません。 従来のADDS ではこの考えはなくあくまで設計というか使い方の問題でした。 Domain Controllerにインストールの仕方や構成に違いはなく、ユーザやグループやコンピュータのオブジェクトをどこにおいてどう信頼関係を構築するかというだけです。 Azure AD Domain Services では最初の展開時にどちらかのタイプを選択し後から変更出来ない点は注意が必要です。 上で触れた同期の変更が出来ない点と関連しているのですが、ユーザーフォレストとリソースフォレストでは同期する内容（範囲というよりは種別、特にパスワードハッシュを同期しない点）が異なります。
長くなってきたのでここら辺にしますが、本番環境のActive Directory としてAzure AD Directory Services を利用する場合は大分注意が必要というのが現時点での結論です。 もちろんマイクロソフトによりマネージド提供される点は大きなメリットがあるので上記の課題が今後の機能追加で解消されていけばと思いました。
以上
