ぴろログ

Output Driven

Azure AD ユーザで Amazon WorkSpaces ( Windows 10 ) を利用する構成の検証② - AD Connector・AAD DS 接続編

Azure AD のユーザで Amazon WorkSpaces ( Windows 10) を使用するための検証手順②です。

前回の記事で、AD Connector (および Amazon WorkSpaces ) が配置されるネットワークと Azure AD Domain Services ( AAD DS ) が配置されるネットワークを、両者のマネージド VPN で接続しました。

blog.pirox.dev

本記事では、 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 を作成します。

f:id:pirox07:20200114033337p:plain

#ユーザ情報をそれぞれ任意に設定
$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

ポータル画面で、アカウントが作成されたことを確認します。 f:id:pirox07:20200114035045p:plain

ステップ② AD Connector を作成する

AAD DS の 設定確認

AAD DS のプロパティ画面で、① DNS ドメイン名② 仮想ネットワーク上の IP アドレレスを確認しておきます。

f:id:pirox07:20200114040928p:plain

AWS Workspaces のディレクトリ設定

AWS のマネジメントコンソールにうつり、WorkSpaces のサービス画面でディレクトを作成します。

f:id:pirox07:20200114041301p:plain

ディレクトリタイプは AD Connector を選択します。

f:id:pirox07:20200114041549p:plain

検証目的ですので、ディレクトリのサイズはスモールにします。 f:id:pirox07:20200114041613p:plain

前回作成した WorkSpaces 用の VPC とサブネットを選択します。

f:id:pirox07:20200114041729p:plain

AAD DS への接続情報を設定します。

f:id:pirox07:20200114042029p:plain

このあと各種設定の確認画面が表示されますので、問題がなければ作成を続行してください。

10分ほどでステータスが Active になります。

f:id:pirox07:20200114042447p:plain

AD Connector の登録

作成したAD Connector を WorkSpaces に登録します。 f:id:pirox07:20200114043438p:plain

WorkSpaces 用の2つのサブネットを指定します。 セルフサービスアクセス、Amazon WorkDocks の有効化は任意で設定します。(今回の検証には影響しません。)

f:id:pirox07:20200114043510p:plain

ステップ③ WorkSpace の展開

実際に WorksSpace を作成します。

f:id:pirox07:20200114043928p:plain

ディレクトリの選択

今回作成したディレクトリを指定します。

f:id:pirox07:20200114044150p:plain

ユーザーの特定

「すべてのユーザーの表示」をクリックすると、Azure AD に登録されているユーザーの一覧が表示されます。(ちょっと感動。)

ws-user01 を指定して「選択項目を追加」をクリックします。

f:id:pirox07:20200114044410p:plain

バンドルの選択

無料利用枠の対象である Standard with Windows 10 を選択します。

f:id:pirox07:20200114044527p:plain

その他の設定は以下のとおりとしました。

  • 言語: Japanese
  • ルートボリューム: 80 GB (デフォルト値)
  • ユーザボリューム: 50 GB (デフォルト値)

WorkSpaces の設定

実行モードを AutoStop (時間課金)とし、1時間操作がない場合には自動停止するよう設定します。ボリュームも暗号化しておきます。 f:id:pirox07:20200114044613p:plain

このあとで設定確認画面が表示されるので、内容に問題がなければ作成を続行します。

20分ほど待つと、作成が完了します。

ディレクトリ管理に AD Connector を使用する場合、WorkSpaces が使用可能となってもメール通知されないため、コンソール画面でステータスが AVAILABLE となることを確認します。 f:id:pirox07:20200114044939p:plain

サインイン

アプリをインストールして、WorkSpace に接続してみます。

clients.amazonworkspaces.com

接続に必要な登録コードはマネジメントコンソール画面で確認できます。

f:id:pirox07:20200114045250p:plain

ws-user01 ユーザ名・パスワードでサインインしてみます。

f:id:pirox07:20200114045743p:plain

WorkSpace に接続することができました。

f:id:pirox07:20200114051156p:plain

コマンドプロンプトから、対象の 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 の仮想ネットワーク向けの通信を確認してみます。

f:id:pirox07:20200118163457p:plain

AD Connector から AAD DS 向けへの通信(ポート番号)を3種類確認できました。

  • 53 ( DNS )
  • 88 ( Kerberos )
  • 389 ( LDAP )

WorkSpace ( Windows 10 ) からは以下のとおりです。

  • 53 ( DNS )
  • 123 ( W32Time )
  • 135 ( RPC エンドポイント マッパー )
  • 389 ( LDAP )
  • 445 ( SMB )
  • 32912 〜 49158 ( 各種 RPC ) ※ポート番号はとびとび

ネットワークセキュリティグループの設定内容からは、これらの通信プロトコルが許可されているようには見えず。。( VPN Gateway 経由の通信は仮想ネットワーク内の通信と認識される、等あるのでしょうか。。)

f:id:pirox07:20200114051626p:plain

Azure 仮想ネットワークの構成はこのようになっています。(Azure のダイアグラム機能で自動作成。なにコレ超便利!!)

f:id:pirox07:20200114055224p:plain

まだ疑問は解決していないので、深堀りしていこうと思います。

まとめ

  • 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 機能)、等の施策を組みあわせて、セキュリティを担保する方針が良いかもしれないですね。

参考情報

docs.microsoft.com

Amazon WorkSpaces の IP アドレスとポートの要件

docs.microsoft.com

docs.microsoft.com

docs.microsoft.com