はじめに

今回は、AVD(旧WVD)でAD FSを使ったSSO(シングルサインオン)の検証環境のご紹介です。
「AVDでAD FSによるSSO」がGAされてから、とても興味をもっておりました。しかし何度か検証をおこなってみてもなかなか思った動きをしてくれませんでした。いろいろと試行錯誤をしてやっと期待した動作の確認がとれました。 こうしたことから、この記事では構築手順のポイントやSSO環境の気づきをご説明したいと思います。

---

全体構成

サーバーや端末は、すべてAzure 上のIaaSとして構成しています。

構成要素

• Azure Virtual Desktop(AVD)
• Active Directory ドメインサービス(AD DS)
• Active Directory 証明書サービス(AD CS)
• Active Directory フェデレーションサービス(AD FS)、および外部公開用Web Application Proxy(WAP)
• Azure AD Connect
• Azure キーコンテナー
• 端末(最新まで更新したWindows 10、Windows Desktop Client(AVD Client)をインストール)

---

構築手順のポイント

構築方法は以下のMSのサイトに手順が記載されております。
Configure AD FS single sign-on for Azure Virtual Desktop
詳細な構築手順はそちらをご参考にして頂き、ここでは簡単な流れやポイントを示します。

手順の前提条件

• AD DS、AD FS、AD CS、WAPの各サービスが正常に動作
• AVDが正常に動作
• キーコンテナー上に利用可能なKey Vaultを作成済み

1. AD CSサーバー上で実行

「1-2.スマートカードログオンの証明書テンプレートの作成」

　証明書の「有効期間」を8時間、「更新期間」を1時間に短縮が推奨

2.AD FSサーバー上で「PowerShell」を実行

「1. AD CSサーバー上で実行」の直後に続けて作業を行う場合は、AD FSサーバー上で以下のコマンドを実行

gpupdate /force

「2-1. Azure PowerShellのインストール」

以下のコマンドを実行

Install-Module -Name Az -AllowClobber

「2-3. Key Vaultのアクセスポリシー設定」

　AD FSサーバーの構成が1台か複数台かで、Key Vaultに設定すべきものが変わる

　今回の検証では1台構成で共有キーを選択している

「2-4. 「ConfigureWVDSSO」のダウンロード・展開」

　ダウンロードを選択しファイルの拡張子を[.nupkg]から[.zip]に変更して任意のフォルダーに展開

　その後のコマンドは展開したフォルダーで実行

ダウンロード画面

「2-5. 「ConfigureWVDSSO」の実行、およびAVDへの適用」

　複数のスクリプトで共通に用いている変数があるため、以降はPowerShellのコンソールは閉じずに一気に実行

　途中で閉じてしまった場合は一旦設定を削除してやり直しが必要

---

構築作業後の確認ポイント

正常系の確認ポイントのみを記載します。

設定の確認

AD FSサーバー上で以下のPowerShellコマンド実行。設定した値が入っていることを確認

Get-AdfsCertificateAuthority

Get-AzWvdHostPool -Name <ホストプール名> -ResourceGroupName <リソースグループ名>

AD FS上の「AD FSの管理」>「証明書利用信頼」に、「Windows Virtual Desktop ADFS Logon SSO」が追加されていることを確認

動作の確認

AVD サインイン時に、2回目の認証画面が表示されない(以下のような認証画面がスキップされる)

ブラウザの場合

AVD Clientの場合

AD CS上の「証明機関」>「発行した証明書」一覧に、サインイン毎1個以上のクライアント証明書が発行される(以下の図を参考)

---

気づき

公的なSSL証明書が必要(と思われる)

AD CSが発行する自己証明書で動作すると考えて検証を進めてみましたが、結局公的なものでないとSSO環境が作れませんでした。
ただし切り分けが不十分なため、公的なSSL証明書が必須といった断言はここでは避けたいと思います。
また余談ではありますが、今回の検証環境ではSSL証明書として公的でフリーなものを採用しました。

AVD クライアントのSSO条件

AVDへの接続は、ブラウザだと無条件にSSOが動作しました。しかし、AVD Clientの場合、「組織がデバイスを管理できるようにする」(以下の画面を参照)にチェックがON(既定値)のままにしておく必要がありました。チェックを外した場合は最初の接続だけは2回目の認証が求められる動きとなりました。(2度目の接続ではSSOとなります。)
このデバイスを組織管理下におく設定が必須だと、BYOD端末等では適用が難しいケースもあるかもしれないと感じました。

クライアント証明書の有効期限に関して

証明書は有効期限および失効が可能なことによって安全性が担保されると考えられます。そのため有効期限を短縮することや失効可能な状態を保つことは重要です。
しかしこれらに反するような2つの推奨事項が今回の設定にはあり、クライアント証明書の有効期限設定は運用に合わせた検討が必要になると考えられます。

1. クライアント証明書の有効期限を短縮
• 　有効期限が短いと再認証を要求される頻度が上がります
2. クライアント証明書発行時にDBへの書き込み停止設定( AD CS上の「証明機関」が持つCAデータベースの肥大化防止のため)
• 　サインイン毎に1個以上のクライアント証明書が発行される仕様からですが、DBに書き込まれないと失効ができません。

(参考)有効期限切れの証明書と失効の実行画面

---

まとめ

AVDでSSOができると使い勝手がとてもよくなるのでは？と考えて検証環境の構築を始めました。当初は、うまく動作していなかったのでその解決に少々手間取りました。結局AD FSやWAPに適用したSSL証明書をAD CS発行の自己証明書から公的なものに変更したことで動作するようになりました。
正常動作に至るまでの過程はAD DS、およびAD CSのイベントログのエラーをひとつずつ探るという古典的な技法をとって調べていきました。証明書の障害切り分けは大変だと実感させられました。
実際の動作に関して、AVDへのサインイン時に2回目の認証画面が表示されないことはとても新鮮でした。MSのサイトにもAVDでサポートされるSSOはAD FSであり、それ以外でセッションホストの認証情報を要求されない唯一の方法は認証情報をクライアントに保存する事と記載がありました。 そんなAD FSですが、前述の気づきなどのようにいろいろな検討事項もあり、実環境に採用する場合はもう少し議論の余地があるとも感じています。
ぜひ、皆さんもAVDでAD FSの検証環境を構築してみて、実際のユーザーエクスペリエンスを確認して頂ければと思います。 最後に、AD FSは敷居が高いと考えている方には以前に「簡単、ADFS検証環境の構築」なるブログも書いておりますので、ご参考にして頂ければと思います。