Windows Virtual Desktop #23 ADDSでWVD展開～AADC構築編～

この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。

前回記事では Azure 上にWindows Server 2019 の Spot Virtual Machine をデプロイし Active Directory Domain Services を立ち上げました。　今回は Azure AD Connect をインストールし、Azure AD とハイブリッド構成を行っていきます。（赤枠部分）

Azure AD Connect のインストールですが、以前に自分自身で書いた以下の記事を見ながら、思い出しながら実施します。　この時は Alibaba Cloud 上の仮想マシンを利用したこととAzure AD のドメイン名と ADDS のドメインが名が違うという点で今回の構成とは一部手順が変わっていきます。

ECS上のADDSをAzure ADと同期する #2

まずは Azure AD Connect のインストールモジュールを入手します。公式サイトからダウンロードします。 2020年5月7日に公開された Version 1.5.30.0 になります。

ダウンロードしたインストーラを起動し、Azure AD Connect のインストールを進めます。

まずは “license terms” と “privacy notice” の確認です。

全部は紹介しませんが、この Terms 文書だけではなく SQL Server など関連して使用するプロダクトの条項も確認しなければなりません。　あとは他のプロダクトとほぼ同じ内容です。

Express Settings では単一フォレスト構成の場合に実施される構成内容が簡単に説明されています。　詳しくは公式文書を見つつ、簡単にまとめると以下です。

インストーラを実行しているホストのドメインのオブジェクトを同期する
パスワードハッシュ同期を有効化する
初期同期も実行する
すべての属性を同期する
自動更新を有効化する

せっかくなので “Customize” 画面も。　以下の構成を指定可能です。

インストール先
既存のSQL Server を指定
既存のアカウントをサービス用アカウントに指定
同期グループの変更

今回は”Customize” は特に実施せず、一つ前の画面に戻ります。

実は以前にAlibaba Cloud のECS インスタンスでハイブリッド構成を一度組んでいるのですがその連携を解除することなく AADC が構成されたAlibaba Cloud のWindows Server はリリースしてしまっています。　今回、新たに同期設定を実施しますが失敗するかもしれません。　とりあえず、”Use express settings” を実行します。　

Azure AD の Global Administrator の資格を持つユーザを指定します。

ここでは Active Directory Domain Services のEnterprise Administrator の資格情報を持つアカウントを指定します。

“Install” を実行します。　

最初に SQL Server が構成されていきます。

予想に反してすんなりインストールと初期セットアップは完了しました。

ただ3点ある案内のうち2点は対応が必要そうなので確認します。 Recycle Bin (ゴミ箱)は有効になっていないよ、有効化を強くお勧めするよ、とのこと。　

公式ドキュメントを確認すると”It is recommended that you enable the AD Recycle Bin feature for your on-premises Active Directories, which are synchronized to Azure AD.” とのことで、Azure AD と連携時はゴミ箱の使用をすすめるとのこと。　Azure AD 側もゴミ箱に連動してオブジェクトをリストアできる（既定で30日間Azure AD 上で保持）ため将来の事故、誤ってオブジェクトを削除する、に対応できるということです。　記載の通りなので有効化します。

Acitve Directory Administrative Center から”Enable Recycle bin” を実行するだけです。

気になる点の2つ目は”mS-DS-ConsistencyGuid” の属性が source anchor 属性といて構成されているとのこと。

公式ドキュメントを見るとAzure AD Connect のversion 1.1.524.0 からAnchor が”mS-DS-ConsistencyGuid”になっているというだけの話でした。

ここからは動作を確認していきます。

まずはサーバ上の Azure AD Connect に関するアプリケーションを見ていきます。スタートメニューに3つアプリケーションが追加されています。 “Synchronization Service”をクリックします。

Microsoft のIdentity Management ソリューション

Microsoft が提供するメールサービス（古くはHotmail、次のOutlook、現在のOffice365/Microsoft365）とActive Directory のアカウント同期にはMIM が使われてきました。この仕組みは自体は10数年前から変わっていないですよね。 OSに統合された現在の Microsoft Identity Management (MIM) 、1つ前のForefront Identity Management (FIM) 、その前のIdentity Lifecycle Management(ILM) と製品名は変わって来ていますがメタディレクトリ型のIDMという基本的なアーキテクチャは変わっていません。画面の作りもあまり変化は見られません。　本格的なIDM として利用できるMIMをAzure AD とのアカウント同期のために機能を限定し提供しているわけです。

IDM（アカウント同期や他システム連携、SSOなど）は20年位前からかなり色々やっているのですがMicrosoft のはコストの観点で提案することは少なかったです。モノが悪いということはなかったのですが。今はOS に統合されたので特定機能を利用する分には無償ですのでIDM のツールを探している場合はまずはMIM を検討してみましょう。

私自身のMIM 経験ですが、2000年代後半にGoogle やYahoo! やMicrosoft がメールサービスをAcademic に無償提供し私も複数の学校さんに Live@edu （当時はHotmaiベース）を提供する中でILM を扱ったのが初めてだったはず。　あとはその時々でIDM の提案を行う際にフルスクラッチだったりLDAP Manager だったり、今は亡きサン・マイクロシステムズのIDMだったり、提案したり構築したりしてきました。　去年久々MIM を扱うことがありILM / FIM からの扱っていたこともありとても懐かしい思いがあったりもしました。

“Synchronization Service” が起動しました。ほんと10数年前からインターフェースに大きな変更はありません。　まあ、IDM で必要なIF はそう変わるものではないですが。

とりあえずすべてのStatus は”success”です。　大きな問題は無さそうです。