AD ConnectorでManaged Microsoft ADに接続して信頼しているドメインのユーザーでAmazon WorkSpacesを作成しようとしてみた
Managed Microsoft ADと別アカウントにWorkSpacesを作成したい
こんにちは、のんピ(@non____97)です。
皆さんはManaged Microsoft ADと別アカウントにAmazon WorkSpaces(以降WorkSpaces)を作成したいなと思ったことはありますか? 私はあります。
WorkSpacesを作成するときはManaged Microsoft ADやAD Connector、Simple ADなどDirectory Serviceが存在している必要があります。このDirectory ServiceがあるVPCにWorkSpacesは作成されます。
Managed Microsoft ADが別アカウントにある場合は、どうすれば良いのでしょうか。
Managed Microsoft ADを別アカウントに共有することは可能ですが、2022/9/29現在、共有されたManaged Microsoft ADを使ってWorkSpacesを作成することはできません。
現在、共有ディレクトリは、Amazon WorkSpaces での使用はサポートされていません。
では、どうするかというとWorkSpacesを起動したいアカウントのVPC上にAD Connectorを作成してManaged Microsoft ADを参照するようにします。AWS Black Belt Online Seminarにも紹介されています。
抜粋 : Amazon WorkSpaces Update - AWS Black Belt Online Seminar サービスカットシリーズ P.27
めでたし、めでたし。
というわけにもいきません。
Managed Microsoft ADが別のADと信頼関係を作成している場合に、信頼しているドメインのユーザーでWorkSpacesは作成できるのでしょうか。
以下AWSのFAQでは、Managed Microsoft ADがあるリージョンとは別リージョンでというシナリオですが、同様にADと信頼関係にあるManaged Microsoft ADに対してAD Connectorで接続して対応していました。
一方、以下AWS公式ドキュメントではAD Connectorは信頼しているドメインのユーザーではWorkSpacesを起動できないと記載がありました。
ただし、Simple AD または AD Connector を使用する WorkSpaces では、信頼されたドメインのユーザーに対して WorkSpaces を起動することはできません。
できないと記載がありますが、FAQでも紹介されているので何とも言えないですね。
悩むよりも試した方が早いので、実際に検証してみました。
いきなりまとめ
- 検証した限り、AD ConnectorでManaged Microsoft ADに接続して、信頼しているドメインのユーザーでWorkSpacesを作成するのはできない
- 信頼しているドメインに対してAD Connectorで接続して、WorkSpacesを作成した方が良いかも
検証環境
検証の環境は以下の通りです。
以下記事の環境にManaged Microsoft ADに接続するAD Connectorを追加しただけです。
この環境でAD Connectorを指定して、セルフマネージドADのユーザー(corp.non-97.net\test-2)のWorkSpacesを作成できるか確認します。
AD Connectorの作成
サービスアカウントの作成
以下記事とAWS公式ドキュメントに従って、AD Connectorを作成していきます。
まず、AD Connectorが使用するサービスアカウントを作成します。
専用のセキュリティグループとAD Connectorのサービスアカウント用のドメインユーザーを作成し、作成したドメインユーザーをセキュリティグループに所属させます。
# セキュリティグループを作成 > New-ADGroup ` -Name "Connectors" ` -GroupScope Global ` -GroupCategory Security ` -Path "OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net" ` # AD Connectorのサービスアカウント作成 > New-ADUser ` -Name "ad-connector" ` -UserPrincipalName "ad-connector@@managed-msad.non-97.net" ` -Accountpassword (Read-Host -AsSecureString "AccountPassword") ` -Path "OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net" ` -PasswordNeverExpires $True ` -Enabled $True AccountPassword: ******************************** # サービスアカウントをセキュリティグループに所属させる > Add-ADGroupMember -Identity "Connectors" -Members "ad-connector" # 作成したサービスアカウントの確認 > Get-ADUser -Filter 'Name -eq "ad-connector"' -SearchBase "OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net" DistinguishedName : CN=ad-connector,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net Enabled : True GivenName : Name : ad-connector ObjectClass : user ObjectGUID : 64c5d70d-006e-4e42-99cf-869412dacb2f SamAccountName : ad-connector SID : S-1-5-21-3454652377-3764961328-2350928461-1617 Surname : UserPrincipalName : [email protected]
権限をサービスアカウントに委任
AD ConnectorがManaged Microsoft ADに接続して、ユーザーの参照やコンピューターオブジェクトの書き込みができるように権限をサービスアカウントに委任します。
Active Directory User and Computersで、managed-msad OU配下のComputers OU上で右クリックして、Delegate Controlをクリックします。
今回はComputers OUを選択しましたが、本来はドメインルート(今回で言うとmanaged-msad.non-97.net)で行います。今回使用としているManaged Microsoft ADのAdminの権限ではドメインルートを操作できない、AWS公式ドキュメントに記載の通り、コンピューターオブジェクトが作成されるCompputers OU上で行いました。
[Active Directory User and Computers] (Active Directory ユーザーとコンピュータ) ナビゲーションツリーで、ドメインルートを選択します。メニューで [Action] (アクション) を選択し、[Delegate Control] (制御を委任する) を選択します。AD Connector が AWS Managed Microsoft AD に接続されている場合、ドメインのルートレベルで制御を委任するアクセス権限がありません。この場合、制御を委任するには、コンピュータオブジェクトが作成されるディレクトリ OU で OU を選択します。
ウィザードに従って進めていきます。
Computers OUのプロパティを確認して、AD Connectorのサービスアカウントが所属するセキュリティグループに権限が与えられていることを確認します。
AD Connectorの作成
下準備が完了したので、AD Connectorを作成します。
Directory Serviceのコンソールからディレクトリのセットアップをクリックします。
ディレクトリタイプでAD Connectorを選択して、次へをクリックします。
ディレクトリサイズでスモールを選択して、次へをクリックします。
VPCとサブネットを選択します。WorkSpacesが起動するサブネットを選択します。
接続するManaged Microsoft ADの情報と、サービスアカウントの情報を入力して次へをクリックします。
設定内容を確認して、ディレクトリの作成をクリックします。
10分ほど待つと、ステータスがアクティブになります。
WorkSpacesの作成
ディレクトリの登録
作成したAD ConnectorがWorkSpacesの認証で使えるように登録します。
WorkSpacesのコンソールからAD Connectorを選択して、アクション-登録をクリックします。
サブネットを選択して登録をクリックします。
ディレクトリの登録済みがTrueになりました。
WorkSpacesの作成
それではWorkSpacesを作成していきます。
ディレクトリでAD Connectorを選択して次へをクリックします。
ユーザーの作成はできないようなので、何もせずに次へをクリックします。
はい、Managed Microsoft ADと双方向の信頼関係であるセルフマネージドADのユーザtest-2がいません。
やはり、AWS公式ドキュメントの通り、AD Connectorで接続したドメインと信頼関係にあるドメインのユーザーではWorkSpacesを作成できないのかもしれません。
ただ、もうちょっと足掻いてみます。
AWS CLIからWorkSpacesを作成できないかチャレンジしてみます。
$ directory_id=d-9067b82237
$ user_name=test-2
$ bundle_id=wsb-dv5v4v37h
$ create_workspaces_input=$(cat <<EOM
{
"Workspaces": [
{
"DirectoryId": "$directory_id",
"UserName": "$user_name",
"BundleId": "$bundle_id",
"WorkspaceProperties": {
"RunningMode": "AUTO_STOP",
"RunningModeAutoStopTimeoutInMinutes": 60
}
}
]
}
EOM
)
$ aws workspaces create-workspaces \
--cli-input-json "$create_workspaces_input"
{
"FailedRequests": [
{
"WorkspaceRequest": {
"DirectoryId": "d-9067b82237",
"UserName": "test-2",
"BundleId": "wsb-dv5v4v37h",
"WorkspaceProperties": {
"RunningMode": "AUTO_STOP",
"RunningModeAutoStopTimeoutInMinutes": 60
},
"Tags": []
},
"ErrorCode": "ResourceNotFound.User",
"ErrorMessage": "The specified user could not be found in the directory."
}
],
"PendingRequests": []
}
「そんなユーザーはこのディレクトリにいない」と怒られてしまいました。
次にサービスアカウントを自分で作成したドメインユーザーではなく、Managed Microsoft ADのAdminにしてみました。
結果は変わらず、こちらも信頼しているドメインのユーザーtest-2を表示してくれませんでした。これはやはりできないのかもしれません。
回避策
回避策を考えます。
これはシンプルに信頼しているドメインに対してAD Connectorで直接接続して、WorkSpacesを作成する方法になります。使いたいユーザーにManaged Microsoft AD経由で参照できないのであれば直接見に行けば良いと言う発想ですね。
AWS公式ドキュメントのWorkSpacesのベストプラクティスでも紹介されています。
Managed Microsoft ADからセルフマネージドのADに対して片方向の信頼関係を作成しています。こうすることで、セルフマネージドADはManaged Microsoft ADにアクセスできるようになります。
もし、Managed Microsoft AD上で管理しているコンピューターオブジェクトがあったとしてもアクセスできるということですね。
また、紹介している例ではWorkSpacesのコンピューターオブジェクトが作成されるOUをManaged Microsoft AD上のOUにしていました。
Managed Microsoft ADを起点にWorkSpacesを作ろうとする場合は要注意
AD ConnectorでManaged Microsoft ADに接続して信頼しているドメインのユーザーでAmazon WorkSpacesを作成しようとしてみました。
今回の検証では「AD Connector → Managed Microsoft AD → セルフマネージドAD」のように数珠繋ぎのように上手くいきませんでした。
Managed Microsoft ADを起点にWorkSpacesを作ろうとする場合は要注意ということですね。ネットワーク的に直接到達できるのであれば、AD Connectorで信頼しているドメインを直接接続することも考える必要がありそうです。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート] QuickSight で IAM 権限を持たないユーザーでもカスタムアクセス許可（制限）が設定できるようになっていました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-19e77b9a51519e08b94d0f688c125729/4f439c75e1ee56c70e315fa46fa45f81/amazon-quicksight)
