Azure AD のユーザで Amazon WorkSpaces ( Windows 10) を使用するための検証手順②です。
前回の記事で、AD Connector （および Amazon WorkSpaces ） が配置されるネットワークと Azure AD Domain Services ( AAD DS ) が配置されるネットワークを、両者のマネージド VPN で接続しました。
本記事では、 AD Connector と AAD DS を接続することで、 WorkSpaces 上に展開した Windows 10 に対して Azure AD 管理のユーザでサインインが可能であることを確認します。
ステップ① 接続用のサービスアカウントを作成する
AD Connector と AAD DS を接続する際に、AAD DS の 管理者権限をもつアカウントでの認証が必要になります。
Azure の Cloud Shell を使って、 PowerShell コマンドを実行し、AAD DC Administrators グループに所属するユーザ ws-user01@pirox.dev を作成します。
#ユーザ情報をそれぞれ任意に設定 $password = "HogeHoge123!" #パスワード文字列 $displayName = "Amazon WorkSpaces Service Account 01" #表示名 $upn = "ws-user01@pirox.dev" #UPN プレフィックス （ユーザー アカウント名） @ UPN サフィックス (DNS ドメイン名) $mailName = "ws-user01" #メーラーでの表示名 #デフォルトの AAD DS 管理者グループ名を指定 $aadAdmins = "AAD DC Administrators" #ユーザ作成 $PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile $PasswordProfile.ForceChangePasswordNextLogin = $false $PasswordProfile.Password = $password $newaaduser = New-AzureADUser -DisplayName $displayName -PasswordProfile $PasswordProfile -UserPrincipalName $upn -AccountEnabled $true -MailNickName $mailName #作成したユーザを AAD DS 管理者グループに所属 Get-AzureADGroup |where {$_.displayname -like $aadAdmins} |Add-AzureADGroupMember -RefObjectId $newaaduser.ObjectId
ポータル画面で、アカウントが作成されたことを確認します。
ステップ② AD Connector を作成する
AAD DS の 設定確認
AAD DS のプロパティ画面で、① DNS ドメイン名と② 仮想ネットワーク上の IP アドレレスを確認しておきます。
AWS Workspaces のディレクトリ設定
AWS のマネジメントコンソールにうつり、WorkSpaces のサービス画面でディレクトリを作成します。
ディレクトリタイプは AD Connector を選択します。
検証目的ですので、ディレクトリのサイズはスモールにします。
前回作成した WorkSpaces 用の VPC とサブネットを選択します。
AAD DS への接続情報を設定します。
このあと各種設定の確認画面が表示されますので、問題がなければ作成を続行してください。
10分ほどでステータスが Active になります。
AD Connector の登録
作成したAD Connector を WorkSpaces に登録します。
WorkSpaces 用の2つのサブネットを指定します。 セルフサービスアクセス、Amazon WorkDocks の有効化は任意で設定します。（今回の検証には影響しません。）
ステップ③ WorkSpace の展開
実際に WorksSpace を作成します。
ディレクトリの選択
今回作成したディレクトリを指定します。
ユーザーの特定
「すべてのユーザーの表示」をクリックすると、Azure AD に登録されているユーザーの一覧が表示されます。（ちょっと感動。）
ws-user01 を指定して「選択項目を追加」をクリックします。
バンドルの選択
無料利用枠の対象である Standard with Windows 10 を選択します。
その他の設定は以下のとおりとしました。
- 言語：
Japanese - ルートボリューム：
80 GB（デフォルト値） - ユーザボリューム：
50 GB（デフォルト値）
WorkSpaces の設定
実行モードを AutoStop （時間課金）とし、1時間操作がない場合には自動停止するよう設定します。ボリュームも暗号化しておきます。
このあとで設定確認画面が表示されるので、内容に問題がなければ作成を続行します。
20分ほど待つと、作成が完了します。
※ディレクトリ管理に AD Connector を使用する場合、WorkSpaces が使用可能となってもメール通知されないため、コンソール画面でステータスが AVAILABLE となることを確認します。
サインイン
アプリをインストールして、WorkSpace に接続してみます。
接続に必要な登録コードはマネジメントコンソール画面で確認できます。
ws-user01 ユーザ名・パスワードでサインインしてみます。
WorkSpace に接続することができました。
コマンドプロンプトから、対象の Windows 10 がドメイン参加 していることも確認できました。
C:\Windows\system32>ipconfig /all
Windows IP 構成
ホスト名. . . . . . . . . . . . . . .: IP-C613B84C
プライマリ DNS サフィックス . . . . .: pirox.dev
ノード タイプ . . . . . . . . . . . .: ハイブリッド
IP ルーティング有効 . . . . . . . . .: いいえ
WINS プロキシ有効 . . . . . . . . . .: いいえ
DNS サフィックス検索一覧. . . . . . .: pirox.dev
ap-northeast-1.compute.internal
気になったこと
AWS 側から AAD DS 向けに発生する通信が、 Azure のネットワークセキュリティグループでブロックされないことを疑問に感じました。
VPC Flow Logs で、 Azure の仮想ネットワーク向けの通信を確認してみます。
AD Connector から AAD DS 向けへの通信（ポート番号）を3種類確認できました。
WorkSpace ( Windows 10 ) からは以下のとおりです。
- 53 ( DNS )
- 123 ( W32Time )
- 135 ( RPC エンドポイント マッパー )
- 389 ( LDAP )
- 445 ( SMB )
- 32912 〜 49158 ( 各種 RPC ) ※ポート番号はとびとび
ネットワークセキュリティグループの設定内容からは、これらの通信プロトコルが許可されているようには見えず。。（ VPN Gateway 経由の通信は仮想ネットワーク内の通信と認識される、等あるのでしょうか。。）
Azure 仮想ネットワークの構成はこのようになっています。（Azure のダイアグラム機能で自動作成。なにコレ超便利！！）
まだ疑問は解決していないので、深堀りしていこうと思います。
まとめ
- AD Connector を利用して、 Azure AD 管理のユーザで WorkSpaces にサインインすることができた
- 対象の WorkSpace ( Windows 10 ) が AAD DS のマネージドドメインに参加していることが確認できた
コンピューターとしてドメイン参加しているので、 WorkSpace を GPO で管理することも可能です。 Azure 上で GPO 管理用の VM を立ち上げて、 WorkSpaces 環境とローカルデバイス間 の各種制御が可能であることも確認できてきます。…が、 VM を使うと負けな感じがするので、 PowerShell で実現する方法がないか確認したいと思います。
グループポリシーを使用した Windows WorkSpaces の管理
認証に関する所感
SSO について
これで Azure AD との SSO が実現できるのかも、と期待を抱いていましたが、この構成では実現できませんでした。。サードパーティのツールが必要となりそうです。
MFA について
WorkSpaces を RADIUS サーバと連携させることで MFA を提供することが可能なようですが、「 Azure AD の ユーザ ID ・ パスワード 」+「WorkSpaces 用の MFA 」の組み合わせはユーザにとって少々わかりづらい運用となる気がします。
かといって、 ID ・パスワードのみの認証には強度に懸念があります。パスワード長を十分に長くする ( Azure AD 機能)、 WorkSpace へアクセス可能なグローバル IP アドレス制限（ WorkSpaces 機能）やクライアント証明書によるデバイス認証（ WorkSpaces 機能）、等の施策を組みあわせて、セキュリティを担保する方針が良いかもしれないですね。
