この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
しばたです。
以前Amazon AppStream 2.0 ドメイン結合に対する私見を述べましたが、本記事ではAppStream 2.0 ドメイン結合の具体的な設定方法を解説します。
1. 全体構成
全体構成としてはこんな感じでです。
以前作成したAWS Managed Microsoft ADとAzure ADをID同期させた環境をベースにAppStream 2.0環境を作りドメイン結合機能を利用します。
全体として複雑な構成になりますので過去記事で紹介している部分については具体的な手順の解説を行いません。適宜リンク先の記事をご覧ください。
2. AWS Managed Microsoft AD + Azure ADの準備
まずはIdPの部分ですが、こちらの記事の手順に従いAWS Managed Microsoft ADでActive Directory環境を用意しAzure ADとID同期をさせます。
実環境においてはActive Directoryはオンプレ環境にあることが多いと思いますが、その場合でも上記手順で特に問題なく構成できると思います。
3. AppStream 2.0 の設定
ここから本記事のメインであるAppStream 2.0環境の設定に入ります。
公式な手順としては以下のドキュメントに記載されています。
環境によっては本記事で紹介する手順以外にグループポリシーの事前設定などが必要になることもありますので事前に一読しておいてください。
3-1. Active Directory 事前準備
まずは事前準備として、Active Directory環境に以下の2つのオブジェクトが必要になります。
- フリートインスタンスを配備する専用OU
- OU名にスペースが入ってはいけない
- Dicrectory configのための専用ユーザー
まずは最初に「AppStream」という名前のOUを作成しておきます。
名前はなんでも良いですがスペースが入らない様にしてください。
続けて専用ユーザーとして「AppStreamService」を作成します。
作成場所はどこでも構いませんが、Azure ADと同期する必要もないので先ほど作成したAppStreamOUに配置しておきます。
PowerShellコマンドだと以下の様な感じで作成できます。
# AppStream 2.0 用ユーザーを OU 指定で作成
$params = @{
Name = 'AppStreamService';
UserPrincipalName = 'AppStreamService@example.shibata.tech';
Description = 'Amazon AppStream 2.0 service user';
AccountPassword = ConvertTo-SecureString -AsPlainText 'P@ssword' -Force;
Enabled = $true;
PasswordNeverExpires = $true;
Path = 'OU=AppStream,OU=corp,DC=shibata,DC=local'
}
New-ADUser @params
そしてこのAppStreamServiceユーザーに各フリートインスタンスをドメインに参加させる権限を与えます。
こちらは「Active Directoryコンピューターとユーザー」のGUIから設定していきます。
AppStreamOUを右クリックして「制御の委任」を選択します。
ウィザードが開始されるので「次へ」
制御を委任する（権限を与える）ユーザーにAppStreamServiceユーザーを追加し「次へ」
「委任するカスタムタスクを作成する」を選択し「次へ」
委任する対象は「フォルダー内の次のオブジェクトのみ」から「コンピューターオブジェクト」を選択します。
そして「オブジェクトの作成」および「オブジェクトの削除」両方チェック *1して「次へ」をクリックします。
アクセス許可は以下の4権限をチェックし「次へ」
- 読み取り (チェック時に付随する権限も自動付与される)
- 書き込み (チェック時に付随する権限も自動付与される)
- パスワードの変更
- パスワードのリセット
設定内容に間違いがないことを確認し「完了」をクリック。
次の Active Directory フォルダー内のオブジェクトの
制御を委任することを選択しました:
shibata.local/corp/AppStream
制御を与えたグループ、ユーザー、または
コンピューター:
AppStreamService (AppStreamService@example.shibata.tech)
次のアクセス許可が与えられています:
読み取り
書き込み
すべてのプロパティの書き込み
パスワードの変更
パスワードのリセット
次のオブジェクトの種類:
コンピューターこれでActive Directory側の事前準備は完了です。
3-2. DHCPオプションセットの設定
次にAppStream 2.0のImage BuilderインスタンスおよびフリートインスタンスがActive Directoryドメインに参加できる様にするためVPCのDHCPオプションセットを更新しておきます。
下図の様に「ドメイン名」と「ドメインネームサーバー」をAWS Managed Microsoft ADのものに変更したDHCPオプションセットを用意しVPCにアタッチしておきます。
3-2. Directory Config 設定
ここからAppStream 2.0の各リソース設定に入ります。
まずは「Directory configs」から新しい「Directory config」を作成します。
Direcotry nameはAWS Managed Microsoft ADのドメイン名を指定し、Service Accounet Nameに前節で作成したAppStreamServiceユーザーを指定します。
そしてOrganizational NameにAppStreamOUの識別名(DN)を記載します。
作成結果はこんな感じでです。
3-3. Image Builderの作成
あとは通常のAppStream 2.0の構築とほぼ同様です。
Image Builderを作成する場合、ネットワーク設定の中で「Directory Config」の指定とImage Builderインスタンスを配置するOUの指定をしてやる点以外は変わりません。
これでImage Builderを作成するとこんな感じでドメインに参加した状態で各種設定が可能となります。
ドメインには下図の様に「AppStream 2.0 - image-builder:"Image Builder名"」といった説明が付いたコンピューターオブジェクトが追加されます。
なおインスタンス自体はドメイン参加されていますが、Image Builderで使えるOSユーザーは基本的にローカルユーザーです。
ちなみにですが、Image Builderはドメインに参加させずフリートだけドメイン結合を使うといった構成も可能です。
3-4. フリートの作成
Image Builder同様にフリートを作成する場合も「Directory Config」を指定してやればドメイン結合を利用できます。
作成後はこんな感じで「AppStream 2.0 - fleet:"フリート名"」なコンピューターがドメインに参加する形となります。
ちなみに本日時点では「Elastic Fleets」はドメイン結合に対応していませんのでご注意ください。
3-5. スタック設定
あとは任意の名前のスタックを作りフリートと紐づけておきます。
ただしスタックにUser Poolのユーザーを紐づけないでください。
ドメイン結合を使う場合スタックをユーザープールのユーザーから利用しようとすると以下の様なエラーメッセージが表示されます。
You cannot assign a stack to users when it is associated with a fleet (my-fleet) that is joined to an Active Directory domain.
ドメイン結合ではこの様な形でSAML 2.0を使った認証が強制されます。
3-6. SAML 2.0設定
次にSAML 2.0の設定をしてやるのですが、具体的な手順はこちらの記事の通りです。
Azure AD以外のIdPを使う場合はIdPに応じた設定をする形となります。
以上でAppStream 2.0の設定はすべて完了となります。
4. 動作確認
ここから実際に動作確認してみます。
この環境ではAzure ADのエンタープライズアプリケーションとしてAppStream 2.0を使う形になるのでhttps://myapps.microsoft.comへアクセスします。
Azure ADと同期済みユーザー(ここでは織田信長ユーザー)でログインすると下図の様に「Amazon AppStream 2.0」アプリケーションが表示されます。
この「Amazon AppStream 2.0」アプリケーションをクリックするとSAML 2.0を使った認証が行われAppStream 2.0のアプリケーションカタログが表示されます。
利用するアプリケーションを選ぶとフリートインスタンスへのログインが開始されるのでしばらく待ち、するとインスタンスOSへのログイン画面になるのでパスワードを入力しログインします。
これで無事ドメイン結合環境でAppStream 2.0アプリケーションを利用することができました。
ログインユーザーがちゃんとActive Directoryドメインユーザー(nobunaga@example.shibata.tech)となっています。
補足 : AppStream 2.0 Windowsクライアントを使う場合
AppStream 2.0 Windowsクライアントの初期状態ではAWS以外のURLへ接続できないため、以下のドキュメントにある様に事前にレジストリを変更しておく必要があります。
Windowsクライアントをインストール後に管理者としてPowerShellコンソールを開き、以下の様にクライアント起動時の初期認証URLを設定してやります。
# 要管理者権限
# HKLM配下のキーはデフォルトでは存在しないので新規作成
$registryPath="HKLM:\Software\Amazon\AppStream Client"
New-Item -Path "HKLM:\Software\Amazon" -Name "AppStream Client" -Force
# IdP毎の認証URLを指定 (Azure ADの場合は https://myapps.microsoft.com/)
New-ItemProperty -Path $registryPath -Name "StartUrl" -Value "https://myapps.microsoft.com/" -PropertyType String -Force | Out-Null
これでAppStream 2.0クライアント起動時に初期URLが設定され接続可能(「Connect」ボタンが押せる様)になります。
あとはWEBアクセスの場合と全く同じ手順でOKです。
結果はこんな感じになります。
終わりに
以上となります。
事前準備が結構大変ですが無事AppStream 2.0のドメイン結合を使うことができました。
最初に紹介した記事で私見を述べている様にドメイン結合の採用には注意が必要ですが、実際にドメイン結合が必要となる場合は本記事の内容を参考にしてください。
脚注
- ドキュメント上の真の最小権限だと削除権限は不要(AppStream 2.0が自動でコンピューターオブジェクトを削除することが無い)なのですが、私個人としては削除権限も与えておいた方が良いと考えます ↩
2
