【Azure AD】WorkSpacesでハイブリッドSSO環境を構築してみた

記事タイトルとURLをコピーする

こんにちは、クラウドインテグレーション部 技術1課 宮形 です。 今年の冬は、自宅の作業部屋が寒すぎて困っております。

みなさんは AWS といえば何を思いつかれるでしょうか?EC2、RDS、Lambda 人それぞれだと思いますが、 私の場合は、なんといっても Amazon WorkSpaces !です。(以下 WorkSpaces と記)

オンプレミスで実現しようとすると、仮想デスクトップ環境(VDI)の構築が必要となります。これにはたくさんのハードウェア調達費用、設計、工期が 必要となりますが、AWS ですと数クリックでクラウド上に VDI が作れてしまいます。 はじめて体感したときは、とても感動しました。当社では WorkSpaces の導入サービスメニューを提供しておりますので、ご興味ありましたらぜひお声かけください。

www.serverworks.co.jp

昨今のリモートワーク普及により人気の WorkSpaces ですが、私がやってみたかったのは WorkSpaces と Microsoft Azure Active Directory (以下 Azure AD と記) を組み合わせた、ハイブリッドSSO環境の構築です。 クラウド市場ではライバルとなる同志の掛け合わせなので、なんだかドキドキ(?)しますね。

経緯

実現できれば、下記のようなユーザー様のニーズに答えることができると考えました。

  • VDI は WorkSpaces で実装したいが、クラウド認証基盤(IDaaS)は Azure AD を使いたい。
  • WorkSpaces でオンプレミスシステムとクラウドシステムのハイブリッドSSOを実現したい。
  • WorkSpaces で Teams や SharePoint Online をシームレスに利用したい。(※)

(※)WorkSpaces 上での Microsoft 製品およびサービスの利用については、ライセンス違反が無いよう十分ご確認ください。   https://aws.amazon.com/jp/windows/faq/

検証の概要

今回の検証目的としては、「WorkSpaces の Windows を Hybrid Azure AD 参加して、オンプレミスとクラウド両方のSSOが構築できるか」の確認となります。

従来利用されてきた「Active Directory ドメインサービス(以下ADDSと記)」と「Azure AD」は 名前は似ていますが、別の認証サービスとなっています。簡単に比較すると下記のようになります。

ADDS Azure AD
プロトコル NTLM、Kerberos、LDAPなど SAML、OAuth、OpenIDConnectなど
認証対象 Windows、ファイルサーバー、グループウェア等 主にオンプレミス側 Office365、サイボウズGaroon、Box、SalecForce 等 主にクラウド側
PC管理機能 グループポリシー Intune等の別ツール組み合わせ

通常の方法では Windows のドメイン参加は ADDS か Azure AD のどちらかのみとなります。 Hybrid Azure AD 参加 の環境を構築することで、両方にドメイン参加してオンプレミス側とクラウド側両方の SSO を実現できます。

WorkSpaces は標準では ADDS でのドメイン参加となりますが、環境を構築して Hybrid Azure AD 参加 を行えるか試してみたいと思います。

検証の手順

出来るだけ検証した手順や画面ショットは多く本BLOGに掲載したいと思いましたが、あまりに長文になってしまうことから記載は一部抜粋としました。 詳細な手順は Microsoft Docs に記載がありますのでご参照ください。下記あたりが参考になると思われます。

マネージド ドメイン用のハイブリッド Azure Active Directory 参加の構成 | Microsoft Docs Azure AD Connect:シームレス シングル サインオン - クイック スタート | Microsoft Docs

構成図

今回の検証で構築するAWSの構成図となります。

f:id:swx-miyagata:20211227123125p:plain
構成図
WorkSpaces と AD Connector 、ADDSを動かすEC2 は同じ Public Subnet 上に配置します。 Azure AD はインターネット上のどこからでも認証できるデフォルト設定としていますが、本番環境では Internet Gateway のパブリックIPアドレスに制限するなど考慮が必要かと思います。 なお、Azure AD を利用するからといって、AWS と Azure をVPN接続する必要はありません。

Azure AD の構築

今回検証では必要な Azure AD の機能を有する「Enterprise Mobility + Security E5」無償評価版を利用しました。下記サイトより利用開始できます。

https://www.microsoft.com/ja-jp/microsoft-365/enterprise-mobility-security/compare-plans-and-pricing

まず最初に独自ドメインを設定します。Azure AD は既定では (ユーザー毎一意のID).onmicrosoft.com というドメイン名が 割り当たりますが、このまま使うことはマレで、通常は自社独自ドメイン(当社ですと serverworks.co.jp)を設定します。 設定手順は割愛しますが、長年愛用しております私の「お名前.com」ドメインで設定しました。 独自ドメインの設定が完了し、Microsoft 365 管理センター と Azure Active Directory 管理センターでは下記のようになります。

f:id:swx-miyagata:20211227123428p:plain

f:id:swx-miyagata:20211227123451p:plain

Azure AD Connect の構築

Hybrid Azure AD 参加の構成では、オンプレミスの ADDS 上のユーザーアカウントと、Azure AD 上のユーザーアカウントが 同期する環境となります。同期を行うために「Azure AD Connect」というソフトウェアをオンプレミスドメインネットワーク上の Windows Server にインストールします。本来は推奨されませんが、本検証では ADDS サーバーに同居インストールとしました。

Aure AD Connect は下記からダウンロードします。

Download Microsoft Azure Active Directory Connect from Official Microsoft Download Center

あらかじめ、「Active Directory ユーザーとコンピューター」の画面より、 WorkSpaces のコンピュータとログインユーザーを登録する 組織ユニット(OU)を準備しておきます。

f:id:swx-miyagata:20211227123646p:plain

Azrue AD Connect の導入でポイントとなる箇所を説明します。 「ユーザー サインイン」では「パスワードハッシュ同期」を選択し、「シングルサインオンを有効にする:チェックあり」とします。

f:id:swx-miyagata:20211227142005p:plain

「Azure AD サインインの構成」では「Azure AD ユーザー名として使用するオンプレミスの属性を選択」を 「ユーザー プリンシパル名:mail」とします。「一部の UPS サフィックスが確認済みドメインに一致していなくても続行する」 は「チェックあり」としました。

f:id:swx-miyagata:20211227123725p:plain

「ドメインとOUのフィルタリング」では、先ほど準備した WorkSpaces ログインユーザーが参加するOUのみチェックします。 この設定は後で変更します。

f:id:swx-miyagata:20211227123802p:plain

他はデフォルトの設定でインストールを進めます。「構成が完了しました」となります。

f:id:swx-miyagata:20211227123821p:plain

しばらくすると、Microsoft 365 管理センター に WorkSpaces ログインユーザーが同期により自動的に作成されます。

f:id:swx-miyagata:20211227123924p:plain

この画面で、各ユーザーに「Enterprise Mobility + Security E5」のライセンスを付与すると、Azure AD の有償機能が使えるようになります。 続けて Hybrid Azure AD 参加 のために必要となる設定を進めます。

Hybrid Azure AD 環境の設定

ふたたび Azure AD Connect の管理ツールを起動し設定を行います。設定ウィザードが開始します。

f:id:swx-miyagata:20211227124008p:plain

「追加のタスク」より「同期オプションのカスタマイズ」を開始します。

f:id:swx-miyagata:20211227124030p:plain

「ドメインとOUのフィルタリング」では、WorkSpaces のコンピュータが割り当たるOUのチェックを追加します。

f:id:swx-miyagata:20211227124046p:plain

「オプション機能」では、「パスワードハッシュ同期」がチェックされていることを確認します。 「次へ」をクリックし、設定を完了します。

f:id:swx-miyagata:20211227124107p:plain

再度、Azure AD Connect の管理ツールを起動します。 「追加のタスク」より「デバイス オプションの構成」を開始します。

f:id:swx-miyagata:20211227124135p:plain

「デバイス オプション」では、「ハイブリッド Azure AD 参加の構成」を選択します。

f:id:swx-miyagata:20211227124156p:plain

「デバイスのオペレーティング システム」では、「Windows 10 以降のドメインに参加しているデバイス」を選択します。 WorkSpaces の OS は Windows Server 2019、Windows Server 2016 ですが、この選択で問題ありませんでした。

f:id:swx-miyagata:20211227124213p:plain

「SCPの構成」では、一覧より WorkSpaces のログインユーザーが所属するドメインをチェックします。 「認証サービス」より「Azure Active Directory」を選択します。「エンタープライズ管理者」に 適切な権限を有するユーザーIDとパスワードを指定します。

f:id:swx-miyagata:20211227124231p:plain

画面を進めて、設定ウィザードを完了します。この操作により、オンプレミスの ADDS 上に サービス接続ポイント(SCP)という情報が登録されます。SCP には、Azure AD のテナントIDやドメイン名といった情報が保持されます。

f:id:swx-miyagata:20211227124323p:plain

UPNサフィックスの登録

この操作は、たとえば オンプレミス ADDS のドメイン名 serverworks.local で、Azure AD のドメイン名が serverworks.co.jp といったように ドメイン名が不一致の場合に設定します。

ADDSサーバーの「管理ツール」-「Active Directory ドメインと信頼関係」より、Azure AD のドメイン名をUPNサフィクスとして登録します。

f:id:swx-miyagata:20211227124353p:plain

続けて「Active Directory ユーザーとコンピュータ」より、WorkSpaces ログインユーザーの UPNサフィクスを変更します。先ほど登録したドメイン名へ変更します。数が多い場合は PowerShell で Set-ADUser -UserPrincipalName "user@serverworks.co.jp" といった感じで、一括変更するバッチファイルを用意します。

f:id:swx-miyagata:20211227124418p:plain

グループポリシーの設定

長い手順となりましたが、もう少しで終わります。「グループポリシー管理エディター」より グループポリシーを設定します。WorkSpaces のログインユーザーが属するOUが対象となります。

[ユーザーの構成] > [ポリシー] > [管理用テンプレート] > [Windows コンポーネント] > [Internet Explorer] > [インターネット コントロール パネル] > [セキュリティ ページ] > [サイトとゾーンの割り当て一覧]

設定:「有効」 とし、「ここにゾーンの割り当てを入力してください。:表示」より下記のようにURLを登録します。

値の名前
https://enterpriseregistration.windows.net 1
https://login.microsoftonline.com 1
https://device.login.microsoftonline.com 1
https://autologon.microsoftazuread-sso.com 1

f:id:swx-miyagata:20211227124439p:plain

[ユーザーの構成] > [ポリシー] > [管理用テンプレート] > [Windows コンポーネント] > [Internet Explorer] > [インターネット コントロール パネル] > [セキュリティ ページ] > [イントラネット ゾーン] > [スクリプトを介したステータス バーの更新を許可する]

設定:「有効」として、「スクリプトを介したステータス バーの更新:有効」とします。

f:id:swx-miyagata:20211227124549p:plain

WorkSpaces ログインユーザーが属するOUへグループポリシーオブジェクトをリンクします。

f:id:swx-miyagata:20211227145817p:plain

以上で Hybrid Azure AD 参加 の環境構築は完了です。WorkSpaces の環境が正しく Hybrid Azure AD でのドメイン参加がおこなわれることを確認します。

ドメイン参加の動作確認

注意としては、Hybrid Azure AD でのドメイン参加は、対象のコンピュータに Azure AD のライセンスを有するユーザーがログインした後にしばらく時間経過して行われることです。 WorkSpaces にログインすると、自動的に下記タスクスケジューラが起動します。

[タスクスケジューラ] > [タスクスケジューラ ライブラリ] > [Microsoft] > [Windows] > [Workplace Join] タスク名 : Automatic-Device-Join

f:id:swx-miyagata:20211227125104p:plain

Automatic-Device-Join が動作すると、自動的に ADDS上のコンピュータアカウントの userCertificate に値がセットされます。

f:id:swx-miyagata:20211227124647p:plain

その後しばらくすると、Azure AD Connect がコンピュータアカウントを Azure AD へ同期します。 この同期処理はデフォルトでは 30分毎に1回行われます。 Azure Active Directory 管理センターの「デバイス」に、WorkSpaces のコンピュータが表示されるようになります。 しかし、この時点では Hybrid Azure AD でのドメイン参加は未完了です。

f:id:swx-miyagata:20211227124707p:plain

WorkSpaces のコンピュータが定期的に Azure AD へドメイン参加を試みます。しばらくすると参加処理が完了します。 管理者でコマンドプロンプトより dsregcmd /stauts と実行すると状態を確認できます。 「Device State」が「AzureAdJoined:YES」「DomainJoined:YES」であれば Hybrid Azure AD でのドメイン参加が完了しています。

f:id:swx-miyagata:20211227124726p:plain

Azure Active Directory 管理センターの「デバイス」の画面で「統合の種類:Hybrid Azure AD joined」となり 「登録済み:日付」となっていることが確認できます。

f:id:swx-miyagata:20211227142624p:plain

つづけて、WorkSpaces のデスクトップ操作でハイブリッドSSOの動作を確認します。

ハイブリッドSSOの動作確認

ここまでの Hybrid Azure AD 参加 の環境構築、および WorkSpaces のドメイン参加が正しく行われていれば、 WorkSpaces の Windows から、ADDSでのオンプレミスの SSO、および Azure AD で認証するサービスの SSO により、各々で自動的に認証が行われるはずです。

先ずはオンプレミスADDSで認証するサービスを確認します。Windowsファイル共有フォルダにアクセスして、IDパスワードが聞かれなければOKとします。

f:id:swx-miyagata:20211227151846p:plain

f:id:swx-miyagata:20211227144137p:plain

次に、Azure AD で認証するサービスを確認します。 下記画面では Microsoft Edge を起動した画面ですが、すでにサインインが完了しているため 「プロファイルを同期」のポップアップが表示されます。

f:id:swx-miyagata:20211227125553p:plain

Office 365 ポータル https://portal.office.com にSSOでログインできます。

f:id:swx-miyagata:20211227125637p:plain

マイアプリ https://myapps.microsoft.com にSSOでログインできます。

f:id:swx-miyagata:20211227125715p:plain

Azure AD で認証するサービスのSSOが動作していることが確認できました。

今回検証ではブラウザは Microsoft Edge を利用しましたが、WorkSpaces ではデフォルトブラウザが Firefox になっているケースがあります。 Firefox でも グループポリシーテンプレートを適用することでSSOが実現できます。 policy-templates/README.md at master · mozilla/policy-templates · GitHub

まとめ

WorkSpaces のイメージは Windows Server 2019 日本語PCoIP版、Windows Server 2016 日本語PCoIP版 の2つで検証しましたが、どちらも成功しました。 Azure AD を利用していたがために Amazon WorkSpaces の利用やSSO諦めていたユーザー様に、今回の検証結果が参考になれば幸いと思います。

はじめて WorkSpaces にログインした後、30分~60分ほど待たないと Hybrid Azure AD でのドメイン参加が完了しないのですが、これは WorkSpaces のみではなく従来の物理パソコンでも同様となります。 環境構築の手順は複雑に思えますが、1回正しく動作することが確認できれば 運用フェーズではログインユーザーを配置するOUだけ気を付ければ、処理はすべて自動的に行われるので手間は掛からないと思います。 Teams や SharePoint Online、Azure ADへフェデレーションした サイボウズGaroon、Box、SalecForce 等も SSOで利用可能となります。

1点残念だったのが、Microsoft の MDM にあたる Intune が利用できなかったことです。 グループポリシーで設定しましたが、動作しませんでした。 システム要件を確認すると、対象OSに Windows Server 2019、Windows Server 2016 が入っていなかったので この為と思われます。Intune が利用できれば、アプリケーション配布や Windows Update 管理など、WorkSpaces のマスタイメージ管理の手間を省けるメリットとなりえました。 Microsoft が機能改善してくれることを願いたいと思います。

Microsoft Intune でサポートされているオペレーティング システムとブラウザー | Microsoft Docs

クラウドの普及が進むと、AWS と Azure を連携するケースも出てくると思われます。需要は多くないかもしれませんが、細々とこういったBLOGの執筆は続けていきたいと思うのでした。

宮形純平(執筆記事の一覧)

エンタープライズクラウド部 ソリューションアーキテクト1課

好きなお酒は缶チューハイと本格焼酎