翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Using Active Directory with WorkSpaces Applications
Amazon WorkSpaces Applications Always-On およびオンデマンド Windows フリートと Image Builder を Microsoft Active Directory のドメインに結合し、クラウドベースのドメインまたはオンプレミスの既存の Active Directory ドメインを使用して、ドメイン結合ストリーミングインスタンスを起動できます。 AWS Managed Microsoft AD とも呼ばれる を使用して AWS Directory Service for Microsoft Active Directory Active Directory ドメインを作成し、それを使用して WorkSpaces アプリケーションリソースをサポートすることもできます。 AWS Managed Microsoft AD の使用に関する詳細については、*AWS Directory Service 管理ガイド*で [Microsoft アクティブディレクトリ](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)について参照してください。
**注記**
Amazon Linux 2 フリート、Image Builder、Elastic フリート、App Block Builder は現在、ドメイン参加をサポートしていません。
WorkSpaces アプリケーションを Active Directory ドメインに結合することで、次のことが可能になります。
+ ストリーミングセッションからプリンターやファイル共有などのアクティブディレクトリリソースにアクセスすることをユーザーとアプリケーションに許可する。
+ グループポリシーマネジメントコンソール (GPMC) で使用できるグループポリシー設定を使用して、エンドユーザーエクスペリエンスを定義する。
+ アクティブディレクトリログイン認証情報を使用した認証をユーザーに義務付けるアプリケーションをストリーミングする。
+ エンタープライズコンプライアンスポリシーとセキュリティポリシーを WorkSpaces アプリケーションストリーミングインスタンスに適用します。
**Topics**
+ [アクティブディレクトリドメインの概要](active-directory-overview.md)
+ [Amazon WorkSpaces アプリケーションで Active Directory の使用を開始する前に](active-directory-prerequisites.md)
+ [チュートリアル: アクティブディレクトリのセットアップ](active-directory-directory-setup.md)
+ [証明書ベースの認証](certificate-based-authentication.md)
+ [WorkSpaces アプリケーションの Active Directory 管理](active-directory-admin.md)
+ [詳細情報](active-directory-more-info.md)
# アクティブディレクトリドメインの概要
WorkSpaces アプリケーションで Active Directory ドメインを使用するには、それらの連携方法と完了する必要がある設定タスクを理解する必要があります。次のタスクを実行する必要があります。
1. 必要に応じて、アプリケーションのエンドユーザーエクスペリエンスとセキュリティ要件を定義できるように、グループポリシーを設定します。
1. WorkSpaces Applications でドメイン結合アプリケーションスタックを作成します。
1. SAML 2.0 ID プロバイダーで WorkSpaces Applications アプリケーションを作成し、直接または Active Directory グループを介してエンドユーザーに割り当てます。
ユーザーがドメインに対して認証されるようにするには、これらのユーザーが WorkSpaces アプリケーションストリーミングセッションを開始するときにいくつかのステップを実行する必要があります。以下の図は、SAML 経由での最初のブラウザリクエストからアクティブディレクトリ認証までのエンドツーエンドのユーザー認証フローを示しています。
![\[Authentication flow diagram showing steps from user login to AWSWorkSpaces Applications session start.\]](http://docs.aws.amazon.com/ja_jp/appstream2/latest/developerguide/images/domain-join-UPDATED.png)
**ユーザー認証フロー**
1. ユーザーが `https://applications.exampleco.com` を参照します。サインインページがユーザーの認証をリクエストします。
1. フェデレーションサービスが組織の ID ストアからの認証をリクエストします。
1. ID ストアはユーザーを認証し、フェデレーションサービスに認証レスポンスを返します。
1. 認証が成功すると、フェデレーションサービスはユーザーのブラウザに SAML アサーションを送信します。
1. ユーザーのブラウザは、SAML アサーションを AWS サインイン SAML エンドポイント (`https://signin.aws.amazon.com/saml`) に投稿します。 AWS サインインは SAML リクエストを受け取り、リクエストを処理し、ユーザーを認証し、認証トークンを WorkSpaces アプリケーションサービスに転送します。
1. WorkSpaces Applications は AWS、 からの認証トークンを使用してユーザーを承認し、ブラウザにアプリケーションを提示します。
1. ユーザーはアプリケーションを選択し、WorkSpaces アプリケーションスタックで有効になっている Windows ログイン認証方法に応じて、Active Directory ドメインパスワードを入力するか、スマートカードを選択するように求められます。両方の認証方法が有効になっている場合、ユーザーはドメインパスワードを入力するか、スマートカードを使用するかを選択できます。証明書ベースの認証は、プロンプトを省略してユーザーの認証にも使用できます。
1. ドメインコントローラーに接続してユーザーを認証します。
1. ドメインで認証された後、ユーザーのセッションがドメインに接続できる状態で開始されます。
ユーザーの視点から見ると、このプロセスは透過的です。ユーザーはまず組織の内部ポータルに移動し、 AWS 認証情報を入力することなく WorkSpaces アプリケーションポータルにリダイレクトされます。アクティブディレクトリドメインのパスワードまたはスマートカードの認証情報のみが必要です。
ユーザーがこのプロセスを開始する前に、必要な資格およびグループポリシーを使用してアクティブディレクトリを設定し、ドメイン参加済みのアプリケーションスタックを作成する必要があります。
# Amazon WorkSpaces アプリケーションで Active Directory の使用を開始する前に
WorkSpaces アプリケーションで Microsoft Active Directory ドメインを使用する前に、以下の要件と考慮事項に注意してください。
**Topics**
+ [アクティブディレクトリドメイン環境](active-directory-prerequisites-domain-environment.md)
+ [ドメイン参加 WorkSpaces アプリケーションストリーミングインスタンス](active-directory-prerequisites-streaming-instances.md)
+ [グループポリシー設定](active-directory-prerequisites-group-policy-settings.md)
+ [スマートカード認証](active-directory-prerequisites-smart-card-authentication.md)
# アクティブディレクトリドメイン環境
Active Directory ドメイン環境は、以下の要件を満たしている必要があります。
+ ストリーミングインスタンスを参加させる Microsoft アクティブディレクトリドメインが必要です。Active Directory ドメインがない場合、またはオンプレミスの Active Directory 環境を使用する場合は、「 [AWS パートナーソリューションデプロイガイド」の「Active Directory ドメインサービス](https://aws-solutions-library-samples.github.io/cfn-ps-microsoft-activedirectory/)」を参照してください。
+ WorkSpaces アプリケーションで使用するドメイン内のコンピュータオブジェクトを作成および管理するためのアクセス許可を持つドメインサービスアカウントが必要です。詳細については、Microsoft ドキュメントで [How to Create a Domain Account in Active Directory](https://msdn.microsoft.com/en-us/library/aa545262(v=cs.70).aspx) を参照してください。
この Active Directory ドメインを WorkSpaces アプリケーションに関連付けるときは、サービスアカウント名とパスワードを指定します。WorkSpaces Applications はこのアカウントを使用して、 ディレクトリにコンピュータオブジェクトを作成および管理します。詳細については、「[アクティブディレクトリコンピュータオブジェクトを作成および管理するための許可の付与](active-directory-permissions.md)」を参照してください。
+ Active Directory ドメインを WorkSpaces アプリケーションに登録するときは、組織単位 (OU) 識別名を指定する必要があります。この目的のために OU を作成します。デフォルトのコンピュータコンテナは OU ではなく、WorkSpaces アプリケーションでは使用できません。詳細については、「[組織単位の識別子名を検索する](active-directory-oudn.md)」を参照してください。
+ WorkSpaces アプリケーションで使用するディレクトリは、ストリーミングインスタンスが起動される Virtual Private Cloud (VPC) を介して、完全修飾ドメイン名 (FQDNs) からアクセス可能である必要があります。詳細については、Microsoft ドキュメントの [Active Directory and Active Directory Domain Services Port Requirements](https://technet.microsoft.com/en-us/library/dd772723.aspx) を参照してください。
+ ドメインコントローラーへのアクセスは IPv6 経由でサポートすることもでき、[DHCP オプションセットの更新](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)が必要です。
# ドメイン参加 WorkSpaces アプリケーションストリーミングインスタンス
ドメイン参加済みの常時オンおよびオンデマンドフリートからのアプリケーションのストリーミングには SAML 2.0 ベースのユーザーフェデレーションが必要です。[CreateStreamingURL](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateStreamingURL.html) または WorkSpaces Applications ユーザープールを使用して、ドメインに参加しているインスタンスにセッションを起動することはできません。
また、Image Builder とフリートのアクティブディレクトリドメインへの参加をサポートするイメージを使用する必要があります。2017 年 7 月 24 日以降に公開されたすべてのパブリックイメージはアクティブディレクトリドメインへの参加をサポートします。詳細については、「[WorkSpaces アプリケーションベースイメージとマネージドイメージ更新リリースノート](base-image-version-history.md)」および「[チュートリアル: アクティブディレクトリのセットアップ](active-directory-directory-setup.md)」を参照してください。
**注記**
Always-On およびオンデマンドフリートストリーミングインスタンスを Active Directory ドメインに参加させることができます。サポートされているオペレーティングシステムには、Windows、Red Hat Enterprise Linux、Rocky Linux などがあります。
# グループポリシー設定
次のグループポリシー設定の内容を確認します。必要に応じて、このセクションの説明に従って設定を更新し、WorkSpaces アプリケーションがドメインユーザーの認証とログインをブロックしないようにします。そうしないと、ユーザーが WorkSpaces アプリケーションにログインしようとすると、ログインが成功しない可能性があります。「不明なエラーが発生しました」というエラーメッセージが表示される場合があります。
+ **[Computer Configuration] (コンピュータの構成) > [Administrative Templates] (管理用テンプレート) > [Windows Components] (Windows コンポーネント) > [Windows Logon Options] (Windows ログオンオプション) > [Disable or Enable software Secure Attention Sequence]** (ソフトウェアの Secure Attention Sequence を無効または有効にする) から、[**Services**] (サービス) に対して [**Enabled**] (有効) に設定します。
+ [**コンピュータの構成] > [管理用テンプレート] > [システム] > [ログオン] > [認証情報プロバイダーを除外する**] – `e7c1bab5-4b49-4e64-a966-8d99686f8c7c` および `f148bAed-5f7f-40c9-8D48-51e24e571825` の各 CLSID が一覧に*ない*ことを確認します。
+ [**Computer Configuration (コンピュータの構成)] > [Policies (ポリシー)] > [Windows Settings (Windows 設定)] > [Security Settings (セキュリティ設定)] > [Local Policies (ローカルポリシー)] > [Security Options (セキュリティオプション)] > [Interactive Logon (対話型ログオン)] > [Interactive Logon (対話型ログオン)]: ログオンしようとしているユーザーへのメッセージテキスト**から、この値を [**Not defined (未定義)**] に設定します。
+ [**Computer Configuration (コンピュータの構成)] > [Policies (ポリシー)] > [Windows Settings (Windows 設定)] > [Security Settings (セキュリティ設定)] > [Local Policies (ローカルポリシー)] > [Security Options (セキュリティオプション)] > [Interactive Logon (対話型ログオン)] > [Interactive Logon (対話型ログオン)]: ログオンしようとしているユーザーへのメッセージタイトル**から、この値を [**Not defined (未定義)**] に設定します。
+ **[コンピュータの構成] > [ポリシー] > [Windows 設定] > [セキュリティ設定] > [ローカルポリシー] > [ユーザー権限の割り当て] > [ローカルのログオンを許可]** – これを **[未定義]** に設定するか、ドメインユーザー/グループをこのリストに追加します。
+ **[コンピュータの構成] > [ポリシー] > [Windows 設定] > [セキュリティ設定] > [ローカルポリシー] > [ユーザー権限の割り当て] > [ローカルのログオンを拒否]** – これを **[未定義]** に設定するか、ドメインユーザー/グループがリストに含まれていないことを確認します。
マルチセッションフリートを使用している場合は、上記の設定に加えて、以下のグループポリシー設定も必要です。
+ **[コンピュータの構成] > [ポリシー] > [Windows 設定] > [セキュリティ設定] > [ローカルポリシー] > [ユーザー権限の割り当て] > [リモートデスクトップサービスを介したログオンを許可]** – これを**[未定義]** に設定するか、ドメインユーザー/グループをこのリストに追加します。
+ **[コンピュータの構成] > [ポリシー] > [Windows 設定] > [セキュリティ設定] > [ローカルポリシー] > [ユーザー権限の割り当て] > [リモートデスクトップサービスを介したログオンを拒否]** – これを **[未定義]** に設定するか、ドメインユーザー/グループがリストに含まれていないことを確認します。
# スマートカード認証
WorkSpaces Applications は、WorkSpaces Applications ストリーミングインスタンスへの Windows サインインに、Active Directory ドメインパスワードや[、Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) や [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) スマートカードなどのスマートカードの使用をサポートしています。サードパーティーの証明機関 (CA) を使用してスマートカードサインインを有効にするようにアクティブディレクトリ環境を構成する詳細方法については、Microsoft ドキュメントの [Guidelines for enabling smart card logon with third-party certification authorities](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities) を参照してください。
**注記**
WorkSpaces アプリケーションは、ユーザーがストリーミングインスタンスにサインインした後のセッション内認証にスマートカードの使用もサポートしています。この機能は、Windows バージョン 1.1.257 以降の WorkSpaces アプリケーションクライアントがインストールされているユーザーでのみサポートされています。その他の要件については、[スマートカード](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards) を参照してください。
# チュートリアル: アクティブディレクトリのセットアップ
WorkSpaces アプリケーションで Active Directory を使用するには、まず WorkSpaces アプリケーションで Directory Config オブジェクトを作成してディレクトリ設定を登録する必要があります。このオブジェクトには、ストリーミングインスタンスをアクティブディレクトリドメインに参加させるために必要な情報が含まれています。Directory Config オブジェクトを作成するには、WorkSpaces アプリケーション管理コンソール、 AWS SDK、または を使用します AWS CLI。その後、ディレクトリ設定を使用して、ドメイン参加済みの常時オンおよびオンデマンドフリートと Image Builder を起動できます。
**注記**
アクティブディレクトリドメインに参加させることができるのは、常時オンおよびオンデマンドフリートのストリーミングインスタンスのみです。
**Topics**
+ [ステップ 1: Directory Config オブジェクトを作成する](#active-directory-setup-config)
+ [ステップ 2: ドメイン結合 Image Builder を使用してイメージを作成する](#active-directory-setup-image-builder)
+ [ステップ 3: ドメイン結合フリートを作成する](#active-directory-setup-fleet)
+ [ステップ 4: SAML 2.0 を設定する](#active-directory-setup-saml)
## ステップ 1: Directory Config オブジェクトを作成する
WorkSpaces アプリケーションで作成した Directory Config オブジェクトは、後のステップで使用します。
AWS SDK を使用している場合は、[CreateDirectoryConfig](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateDirectoryConfig.html) オペレーションを使用できます。を使用している場合は AWS CLI、[create-directory-config](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-directory-config.html) コマンドを使用できます。
**WorkSpaces アプリケーションコンソールを使用して Directory Config オブジェクトを作成するには**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) で WorkSpaces アプリケーションコンソールを開きます。
1. ナビゲーションペインで、[**Directory Configs**]、[**Create Directory Config**] (Directory Config の作成) の順に選択します。
1. [**ディレクトリ名**] に、アクティブディレクトリドメインの完全修飾ドメイン名 (FQDN) (例: `corp.example.com`) を入力します。各リージョンは、特定のディレクトリ名を持つ [**Directory Config**] 値を 1 つのみ持つことができます。
1. [**Service Account Name**] (サービスアカウント名) に、コンピュータオブジェクトを作成でき、ドメインを結合するアクセス許可を持つアカウント名を入力します。詳細については、「[アクティブディレクトリコンピュータオブジェクトを作成および管理するための許可の付与](active-directory-permissions.md)」を参照してください。アカウント名は「`DOMAIN\username`」の形式である必要があります。
1. [**パスワード**] と [**パスワードの確認**] に、指定されたアカウントのディレクトリパスワードを入力します。
1. [**Organizational Unit (OU)**] に、少なくとも 1 つのストリーミングインスタンスコンピュータオブジェクトの OU 識別名を入力します。
**注記**
OU 名にスペースを含めることはできません。スペースを含む OU 名を指定した場合、フリートまたは Image Builder が Active Directory ドメインに再参加しようとすると、WorkSpaces アプリケーションはコンピュータオブジェクトを正しくサイクルできず、ドメインの再参加は成功しません。この問題のトラブルシューティング方法については、[Active Directory ドメイン参加](troubleshooting-notification-codes.md#troubleshooting-notification-codes-ad) の「アカウントが既に存在します」というメッセージで *DOMAIN\$1JOIN\$1INTERNAL\$1SERVICE\$1ERROR* トピックを参照してください。
さらに、デフォルトのコンピュータコンテナは OU ではなく、WorkSpaces アプリケーションでは使用できません。詳細については、「[組織単位の識別子名を検索する](active-directory-oudn.md)」を参照してください。
1. 複数の OU を追加するには、[**Organizational Unit (OU)**] (部門名 (UI)) の横にあるプラス記号 (**\$1**) を選択します。OU を削除するには、[**x**] アイコンを選択します。
1. [**次へ**] を選択します。
1. 設定情報を確認して、[**Create**] を選択します。
## ステップ 2: ドメイン結合 Image Builder を使用してイメージを作成する
次に、WorkSpaces Applications Image Builder を使用して、Active Directory ドメイン結合機能を備えた新しいイメージを作成します。フリートとイメージは、異なるドメインのメンバーにすることができます。Image Builder をドメインに結合してドメイン結合を有効にし、アプリケーションをインストールします。フリートドメイン結合については、次のセクションで説明します。
**ドメイン結合フリートを起動するためのイメージを作成するには**
1. 「[チュートリアル: WorkSpaces アプリケーションコンソールを使用してカスタム WorkSpaces アプリケーションイメージを作成する](tutorial-image-builder.md)」の手順に従います。
1. ベースイメージの選択ステップでは、2017 年 7 月 24 日以降にリリースされた AWS ベースイメージを使用します。リリースされた AWS イメージの現在のリストについては、「」を参照してください[WorkSpaces アプリケーションベースイメージとマネージドイメージ更新リリースノート](base-image-version-history.md)。
1. [**Step 3: Configure Network**] で、アクティブディレクトリ環境へのネットワーク接続がある VPC およびサブネットを選択します。VPC サブネットを使用してディレクトリにアクセスできるようにセットアップされたセキュリティグループを選択します。
1. また、**[ステップ 3: ネットワークの設定]** で、**[Active Directory ドメイン (オプション)]** セクションを展開し、Image Builder が結合される **[ディレクトリ名]** および **[ディレクトリ OU]** の値を選択します。
1. Image Builder 設定を確認して、[**Create**] を選択します。
1. 新しい Image Builder が [**Running**] 状態になるまで待機してから、[**Connect**] を選択します。
1. 管理者モード、またはローカル管理者権限を持つディレクトリユーザーとして Image Builder にログインします。詳細については、「[Image Builder のローカル管理者権限を付与する](active-directory-image-builder-local-admin.md)」を参照してください。
1. アプリケーションをインストールし、新しいイメージを作成するには、「[チュートリアル: WorkSpaces アプリケーションコンソールを使用してカスタム WorkSpaces アプリケーションイメージを作成する](tutorial-image-builder.md)」で説明されているステップを行います。
## ステップ 3: ドメイン結合フリートを作成する
前のステップで作成したプライベートイメージを使用して、アプリケーションをストリーミングするためのアクティブディレクトリドメイン参加済みの常時オンおよびオンデマンドフリートを作成します。ドメインは Image Builder でイメージを作成するために使用されたものと別のものにできます。
**ドメイン結合の常時オンまたはオンデマンドフリートを作成する**
1. 「[Amazon WorkSpaces アプリケーションでフリートを作成する](set-up-stacks-fleets-create.md)」の手順に従います。
1. イメージ選択ステップで、前のステップ ([ステップ 2: ドメイン結合 Image Builder を使用してイメージを作成する](#active-directory-setup-image-builder)) で作成したイメージを使用します。
1. **Step 4: Configure Network**] で、アクティブディレクトリ環境へのネットワーク接続がある VPC およびサブネットを選択します。ドメインと通信できるようにセットアップされたセキュリティグループを選択します。
1. また、**[ステップ 4: ネットワークの設定]** で、**[Active Directory ドメイン (オプション)]** セクションを展開し、フリートを参加させる **[ディレクトリ名]** と **[ディレクトリ OU]** の値を選択します。
1. フリート設定を確認して、[**Create**] を選択します。
1. フリートをスタックに関連付けて実行するには、「[Amazon WorkSpaces アプリケーションフリートとスタックを作成する](set-up-stacks-fleets.md)」の残りのステップを実行します。
## ステップ 4: SAML 2.0 を設定する
ユーザーは、SAML 2.0 ベースの ID フェデレーション環境を使用して、ドメイン参加済みフリートからストリーミングセッションを起動する必要があります。
**シングルサインオンアクセス用の SAML 2.0 を設定するには**
1. 「[SAML のセットアップ](external-identity-providers-setting-up-saml.md)」の手順に従います。
1. WorkSpaces Applications では、ログインしているユーザーの SAML\$1Subject `NameID`値を次のいずれかの形式で指定する必要があります。
+ `domain\username` (sAMAccountName を使用)
+ `username@domain.com` (userPrincipalName を使用)
sAMAccountName 形式を使用している場合、NetBIOS 名または完全修飾ドメイン名 (FQDN) を使用して `domain` を指定できます。
1. Active Directory ユーザーまたはグループへのアクセスを提供し、ID プロバイダーアプリケーションポータルから WorkSpaces アプリケーションスタックへのアクセスを有効にします。
1. 「[SAML のセットアップ](external-identity-providers-setting-up-saml.md)」の残りのステップを行います。
**SAML 2.0 を使用してユーザーにログインさせるには**
1. SAML 2.0 プロバイダーのアプリケーションカタログにログインし、前の手順で作成した WorkSpaces アプリケーション SAML アプリケーションを開きます。
1. WorkSpaces アプリケーションアプリケーションカタログが表示されたら、起動するアプリケーションを選択します。
1. ロード中アイコンが表示されたら、パスワードの入力を求められます。SAML 2.0 ID プロバイダーから提供されたドメインユーザー名がパスワードフィールドの上に表示されます。パスワードを入力して、[**ログイン**] を選択します。
ストリーミングインスタンスで Windows ログイン手順を実行すると、選択したアプリケーションが開きます。
# 証明書ベースの認証
Microsoft Active Directory に参加している WorkSpaces アプリケーションフリートでは、証明書ベースの認証を使用できます。これにより、ユーザーがログインするときに Active Directory ドメインパスワードの入力を求めるユーザープロンプトが省略されます。Active Directory ドメインで証明書ベースの認証を使用すると、以下のことを行うことができます。
+ SAML 2.0 ID プロバイダーに依頼してユーザーを認証し、Active Directory 内のユーザーと一致する SAML アサーションを提供する。
+ ユーザープロンプトの回数を減らして、シングルサインオンでログオンできるようにする。
+ SAML 2.0 ID プロバイダーを使用して、パスワードなしの認証フローを有効にする。
証明書ベースの認証では、 AWS で Private Certificate Authority (AWS Private CA) リソースを使用します AWS アカウント。 AWS プライベート CA を使用すると、ルート CA と下位 CAs を含むプライベート認証機関 (CA) 階層を作成できます。独自の CA 階層を作成し、そこから内部ユーザーを認証する証明書を発行することもできます。詳細については、[「 とは AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)」を参照してください。
証明書ベースの認証に AWS プライベート CA を使用すると、WorkSpaces アプリケーションは各 WorkSpaces アプリケーションフリートインスタンスのセッション予約時にユーザーの証明書を自動的にリクエストします。証明書でプロビジョニングされた仮想スマートカードを使用して、ユーザーを Active Directory に対して認証します。
証明書ベースの認証 (CBA) は、Windows インスタンスを実行する WorkSpaces Applications ドメイン結合フリート (単一セッションフリートとマルチセッションフリートの両方) でサポートされています。マルチセッションフリートで CBA を有効にするには、02-07-2025 以降にリリースされた WorkSpaces Applications エージェントを使用する WorkSpaces Applications イメージを使用する必要があります。または、 以降にリリースされたマネージド WorkSpaces アプリケーションイメージ更新をイメージで使用する必要があります02-11-2025。
**Topics**
+ [前提条件](certificate-based-authentication-prereq.md)
+ [証明書ベースの認証](certificate-based-authentication-enable.md)
+ [証明書ベースの認証の管理](certificate-based-authentication-manage.md)
+ [クロスアカウント PCA 共有を有効にする](pca-sharing.md)
# 前提条件
証明書ベースの認証を使用する前に、以下のステップを完了します。
1. ドメイン結合フリートを設定し、SAML 2.0 を設定する。必ず SAML\$1Subject `NameID` 用の `username@domain.com` `userPrincipalName` 形式を使用してください。詳細については、「[ステップ 5: SAML 認証レスポンスのアサーションを作成する](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions)」を参照してください。
**注記**
証明書ベースの認証を使用する場合は、スタック内の **Active Directory のスマートカードサインイン**を有効にしないでください。詳細については、「[スマートカード](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards)」を参照してください。
1. イメージで WorkSpaces Applications エージェントバージョン 10-13-2022 以降を使用します。詳細については、「[Amazon WorkSpaces アプリケーションイメージUp-to-Date状態に保つ](keep-image-updated.md)」を参照してください。
1. SAML アサーションの `ObjectSid` 属性を設定します。この属性を使用して、Active Directory ユーザーとの強力なマッピングを実行できます。`ObjectSid` 属性が SAML\$1Subject `NameID` で指定されたユーザーの Active Directory セキュリティ識別子 (SID) と一致しない場合、証明書ベースの認証は失敗します。詳細については、「[ステップ 5: SAML 認証レスポンスのアサーションを作成する](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions)」を参照してください。`ObjectSid` は、2025 年 9 月 10 日以降の証明書ベースの認証に必須です。詳細については、「[KB5014754 – Windows ドメインコントローラーでの証明書ベースの認証の変更](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16)」を参照してください。
1. SAML 2.0 設定で使用する IAM ロールの信頼ポリシーに `sts:TagSession` アクセス権限を追加します。詳細については、「[AWS STSでのセッションタグの受け渡し](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html)」を参照してください。この権限は、証明書ベースの認証を使用する場合に必要です。詳細については、「[ステップ 2: SAML 2.0 フェデレーション IAM ロールを作成する](external-identity-providers-setting-up-saml.md#external-identity-providers-grantperms)」を参照してください。
1. Active Directory で設定されていない場合は、 AWS プライベート CA を使用してプライベート認証機関 (CA) を作成します。証明書ベースの認証を使用するには、 AWS プライベート CA が必要です。詳細については、「[AWS Private CA デプロイの計画](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html)」を参照してください。証明書ベースの認証の多くのユースケースでは、次の AWS プライベート CA 設定が一般的です。
+ **CA タイプオプション**
+ **使用期間が短い証明書 CA 使用モード** – CA が証明書ベースの認証のためにエンドユーザー証明書のみを発行する場合に推奨されます。
+ **ルート CA を含む単一レベルの階層** – 下位 CA を選択して既存の CA 階層と統合します。
+ **主要なアルゴリズムオプション** – RSA 2048
+ **サブジェクト識別名オプション** – 最も適切なオプションを使用して、Active Directory の信頼されたルート証明機関ストアでこの CA を識別します。
+ **証明書失効オプション** – CRL のディストリビューション
**注記**
証明書ベースの認証には、WorkSpaces アプリケーションフリートインスタンスとドメインコントローラーの両方からアクセスできるオンライン CRL ディストリビューションポイントが必要です。これには、 AWS プライベート CA CRL エントリ用に設定された Amazon S3 バケットへの認証されていないアクセスが必要です。パブリックアクセスをブロックする場合は Amazon S3 バケットにアクセスできる CloudFront ディストリビューションが必要です。これらのオプションの詳細については、「[証明書失効リスト (CRL) の計画](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html)」を参照してください。
1. プライベート CA `euc-private-ca` に、WorkSpaces アプリケーション証明書ベースの認証で使用する CA を指定する権限を持つキーをタグ付けします。このキーには値は必要ありません。詳細については、「[プライベート CA のタグ管理](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html)」を参照してください。のリソースにアクセス許可を付与するために WorkSpaces アプリケーションで使用される AWS マネージドポリシーの詳細については AWS アカウント、「」を参照してください[AWS WorkSpaces アプリケーションリソースにアクセスするために必要な管理ポリシー](managed-policies-required-to-access-appstream-resources.md)。
1. 証明書ベースの認証では、仮想スマートカードを使用してログオンします。詳細については、「[サードパーティーの証明機関でスマートカードオンを有効にするためのガイドライン](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities)」を参照してください。以下の手順に従ってください。
1. スマートカードユーザーを認証するには、ドメインコントローラー証明書を使用してドメインコントローラーを設定します。Active Directory 証明書サービスのエンタープライズ CA が Active Directory に設定されている場合、スマートカードによるログオンを可能にするドメインコントローラーが証明書に自動的に登録されます。Active Directory 証明書サービスがない場合は、[「サードパーティー CA からのドメインコントローラー証明書の要件](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller)」を参照してください。 AWS は、ドメインコントローラー証明書の登録を自動的に管理するために Active Directory エンタープライズ認証機関を推奨します。
**注記**
AWS Managed Microsoft AD を使用する場合は、ドメインコントローラー証明書の要件を満たす Amazon EC2 インスタンスで証明書サービスを設定できます。[Active Directory 証明書サービスで設定された Managed Microsoft AD のデプロイ例については、「新しい Amazon Virtual Private Cloud に](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html) Active Directory をデプロイする」を参照してください。 AWS
AWS Managed Microsoft AD と Active Directory Certificate Services では、コントローラーの VPC セキュリティグループから Certificate Services を実行する Amazon EC2 インスタンスへのアウトバウンドルールも作成する必要があります。証明書の自動登録を有効にするには、セキュリティグループに TCP ポート 135 とポート 49152～65535 へのアクセスを提供する必要があります。Amazon EC2 インスタンスは、ドメインコントローラーを含むドメインインスタンスからの同じポートへのインバウンドアクセスも許可する必要があります。 AWS Managed Microsoft AD のセキュリティグループを見つける方法の詳細については、「VPC [サブネットとセキュリティグループを設定する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_mad.html#tutorial_setup_trust_open_vpc)」を参照してください。
1. AWS プライベート CA コンソール、または SDK または CLI で、プライベート CA 証明書をエクスポートします。詳細については、「[プライベート証明書のエクスポート](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html)」を参照してください。
1. プライベート CA を Active Directory に公開します。ドメインコントローラーまたはドメイン結合マシンにログオンします。プライベート CA 証明書を任意の `\` にコピーし、ドメイン管理者として次のコマンドを実行します。また、グループポリシーと Microsoft PKI Health ツール (PKIView) を使用して CA を公開することもできます。詳細については、「[設定手順](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities#configuration-instructions)」を参照してください。
```
certutil -dspublish -f \ RootCA
```
```
certutil -dspublish -f \ NTAuthCA
```
コマンドが正常に完了したことを確認してから、プライベート CA 証明書ファイルを削除します。Active Directory のレプリケーション設定によっては、CA がドメインコントローラーと WorkSpaces Applications フリートインスタンスに発行するまでに数分かかる場合があります。
**注記**
Active Directory は、ドメインに参加するときにWorkSpaces アプリケーションフリートインスタンスの信頼されたルート認証機関とエンタープライズ NTAuth ストアに CA を自動的に配布する必要があります。
Windows オペレーティングシステムの場合、CA (認証局) のディストリビューションは自動的に行われます。ただし、Rocky Linux および Red Hat Enterprise Linux の場合は、WorkSpaces Applications Directory Config が使用する CA からルート CA 証明書 (複数可) をダウンロードする必要があります。KDC ルート CA 証明書が異なる場合、それらもダウンロードする必要があります。証明書ベースの認証を使用する前に、これらの証明書をイメージまたはスナップショットにインポートする必要があります。
イメージには、/`etc/sssd/pki/sssd_auth_ca_db.pem` という名前のファイルが必要です。次のようになります。
```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate chain from ACM Private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate body from ACM private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded root CA KDC certificate chain
-----END CERTIFICATE-----
```
**注記**
リージョンやアカウント間でイメージをコピーする場合、またはイメージを新しい Active Directory に再関連付けする場合は、このファイルを Image Builder の関連する証明書で再設定し、使用前に再度スナップショットを作成する必要があります。
ルート CA 証明書をダウンロードする手順は次のとおりです。
1. Image Builder で、`/etc/sssd/pki/sssd_auth_ca_db.pem` という名前のファイルを作成します。
1. [AWS Private CA コンソール](https://console.aws.amazon.com/acm-pca/) を開きます。
1. WorkSpaces Applications Directory Config で使用されるプライベート証明書を選択します。
1. **[CA 証明書]** タブを選択します。
1. 証明書チェーンと証明書本文を Image Builder の `/etc/sssd/pki/sssd_auth_ca_db.pem` にコピーします。
KDCs で使用されるルート CA 証明書が WorkSpaces Applications Directory Config で使用されるルート CA 証明書と異なる場合は、以下の例の手順に従ってダウンロードします。
1. Image Builder と同じドメインに参加している Windows インスタンスに接続します。
1. `certlm.msc` を開きます。
1. 左側のペインで、**[信頼できるルート証明機関]** を選択し、**[証明書]** を選択します。
1. ルート CA 証明書ごとに、コンテキスト (右クリック) メニューを開きます。
1. **[すべてのタスク]** を選択し、**[エクスポート]** を選択して証明書エクスポートウィザードを開き、**[次へ]** を選択します。
1. **[Base64 でエンコードされた X.509 (.CER)]** を選択し、**[次へ]** を選択します。
1. **[参照]** を選択し、ファイル名を入力し、**[次へ]** を選択します。
1. [**Finish**] を選択してください。
1. エクスポートされた証明書をテキストエディタで開きます。
1. ファイルの内容を Image Builder の `/etc/sssd/pki/sssd_auth_ca_db.pem` にコピーします。
# 証明書ベースの認証
証明書ベースの認証を使用する前に、以下の手順を完了します。
**証明書ベースの認証**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) で WorkSpaces アプリケーションコンソールを開きます。
1. ナビゲーションペインで、[**Directory Configs**] (ディレクトリの設定) を選択します。設定するディレクトリ設定を選択し、[**編集**] を選択します。
1. [**証明書ベースの認証を有効にする**] を選択します。
1. プライベート CA の ARN がリストで関連付けられていることを確認します。リストに表示するには、プライベート CA を同じ AWS アカウント と に保存する必要があります AWS リージョン。また、プライベート CA には `euc-private-ca` という名前のキーをタグ付けする必要があります。
1. フォールバックのディレクトリログを設定します。フォールバックを使用すると、証明書ベースの認証に失敗した場合でも、ユーザーは AD ドメインのパスワードでログインできます。これは、ユーザーがドメインパスワードを知っている場合にのみ推奨されます。フォールバックがオフになっていると、ロック画面や Windows のログオフが発生した場合に、セッションによってユーザーの接続が切断される可能性があります。フォールバックがオンになっている場合、セッションはユーザーに AD ドメインパスワードの入力を求めます。
1. **[Save changes]** (変更の保存) をクリックします。
1. 証明書ベースの認証が有効になりました。ユーザーが WorkSpaces Applications ウェブクライアントまたは Windows 用クライアント (バージョン 1.1.1099 以降) のドメイン結合フリートを使用して WorkSpaces アプリケーションスタックに対して SAML 2.0 で認証すると、ドメインパスワードの入力を求めるプロンプトが表示されなくなります。証明書ベースの認証を有効にしたセッションに接続するときに、「証明書ベースの認証で接続中...」というメッセージがユーザーに表示されます。
# 証明書ベースの認証の管理
証明書ベースの認証を有効にしたら、次のタスクを確認します。
**Topics**
+ [プライベート CA 証明書](certificate-based-authentication-manage-CA.md)
+ [エンドユーザー証明書](certificate-based-authentication-manage-certs.md)
+ [監査レポート](certificate-based-authentication-manage-audit.md)
+ [ログ記録とモニタリング](certificate-based-authentication-manage-logging.md)
# プライベート CA 証明書
一般的な設定では、プライベート CA 証明書の有効期間は 10 年です。証明書の有効期限が切れたプライベート CA を置き換える方法、またはプライベート CA を新しい有効期間で再発行する方法の詳細については、「[プライベート CA ライフサイクルの管理](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html)」を参照してください。
# エンドユーザー証明書
WorkSpaces アプリケーション証明書ベースの認証用に AWS Private CA によって発行されたエンドユーザー証明書は、更新や取り消しを必要としません。これらは使用期間が短い証明書です。WorkSpaces Applications は、新しいセッションごとに新しい証明書を自動的に発行するか、長期間のセッションの場合は 24 時間ごとに新しい証明書を発行します。WorkSpaces アプリケーションセッションは、これらのエンドユーザー証明書の使用を管理します。セッションを終了すると、WorkSpaces アプリケーションはその証明書の使用を停止します。これらのエンドユーザー証明書の有効期間は、一般的な AWS プライベート CA CRL ディストリビューションよりも短くなります。そのため、エンドユーザー証明書を取り消さなくても、CRL に表示されなくなります。
# 監査レポート
プライベート CA が発行または取り消したすべての証明書を一覧表示する監査報告書を作成できます。詳細については、「[プライベート CA での監査レポートの使用](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html)」を参照してください。
# ログ記録とモニタリング
CloudTrail を使用して、WorkSpaces アプリケーションによるプライベート CA への API コールを記録できます。詳細については、「[AWS CloudTrailとは](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)」および「[CloudTrail の使用](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html)」を参照してください。CloudTrail イベント履歴では、WorkSpaces Applications**EcmAssumeRoleSession** ユーザー名によって作成された **acm-pca.amazonaws.com** イベントソースから **GetCertificate** イベント名と **IssueCertificate** イベント名を表示できます。これらのイベントは、WorkSpaces アプリケーション証明書ベースの認証リクエストごとに記録されます。詳細については、「[CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。
# クロスアカウント PCA 共有を有効にする
プライベート CA (PCA) のクロスアカウント共有を使用すると、他のアカウントに一元的な CA を使用するアクセス許可を付与できます。CA は、[AWS Resource Access Manager](https://aws.amazon.com/ram/) (RAM) を使用して証明書を生成および発行し、アクセス許可を管理できます。これにより、アカウントごとのプライベート CA は不要になります。プライベート CA クロスアカウント共有は、同じ 内の WorkSpaces アプリケーション証明書ベースの認証 (CBA) で使用できます AWS リージョン。
WorkSpaces Applications CBA で共有プライベート CA リソースを使用するには、次の手順を実行します。
1. 一元化された で CBA のプライベート CA を設定します AWS アカウント。詳細については、「[証明書ベースの認証](certificate-based-authentication.md)」を参照してください。
1. プライベート CA を WorkSpaces アプリケーションリソース AWS アカウント が CBA を利用するリソースと共有します。これを行うには、「[How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/)」の手順に従います。証明書を作成するために、ステップ 3 を完了する必要はありません。プライベート CA を個人と共有することも AWS アカウント、 を通じて共有することもできます AWS Organizations。個々のアカウントと共有する場合は、 AWS Resource Access Manager コンソールまたは APIs を使用して、リソースアカウントで共有プライベート CA を受け入れる必要があります。
共有を設定するときは、 AWS Resource Access Manager リソースアカウントのプライベート CA のリソース共有が `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority`マネージドアクセス許可テンプレートを使用していることを確認します。このテンプレートは、CBA 証明書の発行時に WorkSpaces アプリケーションサービスロールで使用される PCA テンプレートと一致しています。
1. 共有が成功したら、リソースアカウントのプライベート CA コンソールを使用して、共有プライベート CA を表示します。
1. API または CLI を使用して、WorkSpaces Applications Directory Config の CBA にプライベート CA ARN を関連付けます。現時点では、WorkSpaces アプリケーションコンソールは共有プライベート CA ARNs の選択をサポートしていません。CLI コマンドの例を次に示します。
`aws appstream update-directory-config --directory-name --certificate-based-auth-properties Status=,CertificateAuthorityArn=`
# WorkSpaces アプリケーションの Active Directory 管理
WorkSpaces アプリケーションで Active Directory をセットアップして使用するには、以下の管理タスクが必要です。
**Topics**
+ [アクティブディレクトリコンピュータオブジェクトを作成および管理するための許可の付与](active-directory-permissions.md)
+ [組織単位の識別子名を検索する](active-directory-oudn.md)
+ [Image Builder のローカル管理者権限を付与する](active-directory-image-builder-local-admin.md)
+ [ドメインの参加に使用するサービスアカウントの更新](active-directory-service-acct.md)
+ [ユーザーがアイドル状態の場合にストリーミングセッションをロックする](active-directory-session-lock.md)
+ [ディレクトリ設定を編集する](active-directory-config-edit.md)
+ [ディレクトリ設定を削除する](active-directory-config-delete.md)
+ [ドメイン信頼を使用するように WorkSpaces アプリケーションを設定する](active-directory-domain-trusts.md)
+ [Active Directory での WorkSpaces アプリケーションのコンピュータオブジェクトの管理](active-directory-identify-objects.md)
# アクティブディレクトリコンピュータオブジェクトを作成および管理するための許可の付与
WorkSpaces アプリケーションが Active Directory コンピュータオブジェクトオペレーションを実行できるようにするには、十分なアクセス許可を持つアカウントが必要です。ベストプラクティスとして、必要最小限のアクセス許可のみを持つアカウントを使用します。最小限のアクティブディレクトリ組織単位 (OU) 許可は以下のとおりです。
+ コンピュータオブジェクトの作成
+ パスワードの変更
+ [Reset Password] (パスワードのリセット)
+ 説明の書き込み
アクセス許可をセットアップする前に、まず以下の操作を行う必要があります。
+ ドメインに参加済みのコンピュータまたは EC2 インスタンスにアクセスします。
+ Active Directory User and Computers MMC スナップインをインストールします。詳細については、Microsoft ドキュメントの「[Installing or Removing Remote Server Administration Tools for Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx)」を参照してください。
+ 適切なアクセス権限を持つドメインユーザーとしてログインし、OU のセキュリティ設定を変更します。
+ アクセス権限を委任するユーザーアカウント、サービスアカウント、またはグループを作成または指定します。
**最小限のアクセス権限をセットアップするには**
1. ドメインまたはドメインコントローラーで [**Active Directory Users and Computers**] (アクティブディレクトリユーザーとコンピュータ) を開きます。
1. 左のナビゲーションペインで、ドメイン参加権限を提供する最初の OU を選択して、コンテキスト (右クリック) メニューを開き、[**制御の委任**] を選択します。
1. [**Delegation of Control Wizard**] ページで、[**Next**]、[**Add**] の順に選択します。
1. **[ユーザー、コンピュータ、グループの選択]** で、事前に作成したユーザーアカウント、サービスアカウント、またはグループを選択し、**[OK]** を選択します。
1. **[Tasks to Delegate]** (委任するタスク) ページで、**[Create a custom task to delegate]** (委任するカスタムタスクの作成) を選択し、**[Next** (次へ) を選択します。
1. [**Only the following objects in the folder**]、[**Computer objects**] を選択します。
1. [**Create selected objects in this folder**]、[**Next**] を選択します。
1. [**Permissions**] で、[**Read**]、[**Write**]、[**Change Password**]、[**Reset Password**]、[**Next**] の順に選択します。
1. [**Completing the Delegation of Control Wizard**] ページで情報を確認し、[**Finish**] を選択します。
1. これらのアクセス権限を必要とする追加の OU に対して、ステップ 2 ～ 9 を繰り返します。
グループにアクセス権限を委任した場合は、強力なパスワードを持つユーザーアカウントまたはサービスアカウントを作成し、そのアカウントをグループに追加します。こうすることで、ディレクトリにストリーミングインスタンスを接続するための十分な権限がこのアカウントに与えられます。WorkSpaces Applications ディレクトリ設定を作成するときに、このアカウントを使用します。
# 組織単位の識別子名を検索する
Active Directory ドメインを WorkSpaces アプリケーションに登録するときは、組織単位 (OU) 識別名を指定する必要があります。この目的のために OU を作成します。デフォルトのコンピュータコンテナは OU ではなく、WorkSpaces アプリケーションでは使用できません。以下に、この名前を取得する手順を示します。
**注記**
識別子名は、**OU=** で始まる必要があります。また、その名前をコンピュータオブジェクトに使用することはできません。
この手順を完了するには、まず以下の操作を行う必要があります。
+ ドメインに参加済みのコンピュータまたは EC2 インスタンスにアクセスします。
+ Active Directory User and Computers MMC スナップインをインストールします。詳細については、Microsoft ドキュメントの「[Installing or Removing Remote Server Administration Tools for Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx)」を参照してください。
+ 適切なアクセス権限を持つドメインユーザーとしてログインし、OU のセキュリティプロパティを読み取ります。
**OU 識別子名を確認するには**
1. ドメインまたはドメインコントローラーで [**Active Directory Users and Computers**] (アクティブディレクトリユーザーとコンピュータ) を開きます。
1. [**View**] で、[**Advanced Features**] が有効になっていることを確認します。
1. 左側のナビゲーションペインで、WorkSpaces Applications ストリーミングインスタンスコンピュータオブジェクトに使用する最初の OU を選択し、コンテキスト (右クリック) メニューを開き、**プロパティ**を選択します。
1. [**Attribute Editor**] を選択します。
1. [**Attributes**] の下の [**distinguishedName**] で、[**View**] を選択します。
1. [**値**] で識別子名を選択し、コンテキストメニューを開き、[**コピー**] を選択します。
# Image Builder のローカル管理者権限を付与する
デフォルトで、アクティブディレクトリドメインユーザーに Image Builder インスタンスのローカル管理者権限はありません。このアクセス権限を付与するには、ディレクトリのグループポリシーの設定を使用するか、手動で Image Builder のローカル管理者アカウントを使用します。ドメインユーザーにローカル管理者権限を付与すると、そのユーザーは WorkSpaces Applications Image Builder にアプリケーションをインストールし、イメージを作成できます。
**Topics**
+ [グループポリシー設定を使用する](group-policy.md)
+ [Image Builder でローカル管理者グループを使用する](manual-procedure.md)
# グループポリシー設定を使用する
ローカル管理者権限をアクティブディレクトリのユーザーやグループに付与したり、または指定された OU のすべてのコンピュータオブジェクトに付与したりするには、グループポリシー設定を使用します。ローカル管理者のアクセス許可を付与するアクティブディレクトリユーザーまたはグループが既に存在している必要があります。グループポリシー設定を使用するには、まず、以下の操作を行う必要があります。
+ ドメインに参加済みのコンピュータまたは EC2 インスタンスにアクセスします。
+ グループポリシーマネジメントコンソール (GPMC) の MMC スナップインをインストールします。詳細については、Microsoft ドキュメントの「[Installing or Removing Remote Server Administration Tools for Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx)」を参照してください。
+ アクセス許可を持つドメインユーザーとしてログインし、グループポリシーオブジェクト (GPO) を作成します。GPO を適切な OU にリンクします。
**グループポリシー設定を使用して、ローカル管理者のアクセス許可を付与するには**
1. ディレクトリまたはドメインコントローラーで、管理者としてコマンドプロンプトを開き、`gpmc.msc` と入力し、ENTER キーを押します。
1. 左のコンソールツリーで、新しい GPO を作成する OU、または既存の GPO を使用する OU を選択して、以下のいずれかの操作を行います。
+ コンテキスト (右クリック) メニューを開き、[**Create a GPO in this domain, Link it here**] を選択して、新しい GPO を作成します。[**Name**] に、この GPO のわかりやすい名前を入力します。
+ 既存の GPO を選択します。
1. GPO のコンテキストメニューを開き、[**編集**] を選択します。
1. コンソールツリーで、[**Computer Configuration**] (コンピュータの構成)、[**設定**]、[**Windows Settings**] (Windows 設定)、[**Control Panel Settings**] (コントロールパネル設定)、[**Local Users and Groups**] (ローカルユーザーおよびグループ) の順に選択します。
1. [**Local Users and Groups**] (ローカルユーザーおよびグループ) を選択して、コンテキストメニューを開き、[**新規**]、[**Local Group**] (ローカルグループ) の順に選択します。
1. [**Action**] で、[**Update**] を選択します。
1. [**Group name**] で、[**Administrators(built-in)**] を選択します。
1. **[メンバー]** で、**[追加]** を選択して、ストリーミングインスタンスに対するローカル管理者権限を割り当てるアクティブディレクトリユーザーアカウントまたはグループを指定します。[**Action**] で、[**Add to this group**] を選択し、[**OK**] を選択します。
1. この GPO を他の OU に適用するには、追加の OU を選択して、コンテキストメニューを開き、[**Link an Existing GPO**] (既存の GPO のリンク) を選択します。
1. ステップ 2 で指定した新規または既存の GPO 名を使用して、GPO までスクロールし、[**OK**] を選択します。
1. この設定が必要な追加の OU に対して、ステップ 9 および 10 を繰り返します。
1. 再度 [**OK**] を選択して、[**New Local Group Properties**] (新規のローカルグループプロパティ) ダイアログボックスを閉じます。
1. 再度 [**OK**] を選択し、GPMC を閉じます。
新しい設定を GPO に適用するには、実行中の Image Builder またはフロートを停止して再起動する必要があります。GPO がリンクされている OU の Image Builder およびフリートのローカル管理者権限が、ステップ 8 で指定したアクティブディレクトリユーザーおよびグループに自動的に付与されます。
# Image Builder でローカル管理者グループを使用する
Image Builder でアクティブディレクトリユーザーまたはグループのローカル管理者権限を付与するには、これらのユーザーまたはグループを Image Builder のローカル管理者グループに手動で追加します。これらの権限を使用してイメージから作成された Image Builder で、同様の権限を管理します。
ローカル管理者権限を付与するアクティブディレクトリユーザーまたはグループが既に存在している必要があります。
**アクティブディレクトリユーザーまたはグループを Image Builder のローカル管理者グループに追加するには**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) で WorkSpaces アプリケーションコンソールを開きます。
1. 管理者モードで Image Builder に接続します。Image Builder は実行中でありドメイン参加済みである必要があります。詳細については、「[チュートリアル: アクティブディレクトリのセットアップ](active-directory-directory-setup.md)」を参照してください。
1. [**開始**]、[**管理ツール**] の順に選択し、[**コンピュータの管理**] をダブルクリックします。
1. 左のナビゲーションペインで、[**Local Users and Groups**] を選択して [**Groups**] フォルダを開きます。
1. [**Administrators**] グループを開いて [**Add...**] を選択します。
1. ローカル管理者権限を割り当てるアクティブディレクトリユーザーまたはグループをすべて選択して、[**OK**] を選択します。再度 [**OK**] を選択して、[**管理者プロパティ**] ダイアログボックスを閉じます。
1. コンピュータの管理を閉じます。
1. アクティブディレクトリユーザーとしてログインし、テストユーザーに Image Builder のローカル管理者権限があることを確認するには、[**Admin Commands**] (管理者コマンド)、[**Switch user**] (ユーザーの切り替え) の順に選択し、該当するユーザーの認証情報を入力します。
# ドメインの参加に使用するサービスアカウントの更新
WorkSpaces Applications がドメインの結合に使用するサービスアカウントを更新するには、Image Builder とフリートを Active Directory ドメインに結合するために 2 つの個別のサービスアカウントを使用することをお勧めします。2 つの異なるサービスアカウントを使用することで、サービスアカウントを更新する必要がある場合 (例: パスワードの失効時) にサービスを中断しなくてすみます。
**サービスアカウントを更新するには**
1. アクティブディレクトリグループを作成し、グループに適切な許可を委任します。
1. サービスアカウントを新しいアクティブディレクトリグループに追加します。
1. 必要に応じて、新しいサービスアカウントのサインイン認証情報を入力して WorkSpaces Applications Directory Config オブジェクトを編集します。
新しいサービスアカウントを使用してアクティブディレクトリグループをセットアップすると、新しいストリーミングインスタンス操作では新しいサービスアカウントが使用されるのに対し、処理中のストリーミングインスタンス操作では、中断されることなく古いアカウントが引き続き使用されます。
処理中のストリーミングインスタンスオペレーションが完了するまでのサービスアカウントの重複時間は短時間 (1 日以内) です。重複期間が必要なのは、重複期間中に古いサービスアカウントのパスワードを削除または変更できないためです。これを行うと既存のオペレーションが失敗することがあります。
# ユーザーがアイドル状態の場合にストリーミングセッションをロックする
WorkSpaces Applications は、ユーザーが指定した時間アイドル状態になった後にストリーミングセッションをロックするように GPMC で設定した設定に依存します。GPMC を使用するには、まず、以下の操作を行う必要があります。
+ ドメインに参加済みのコンピュータまたは EC2 インスタンスにアクセスします。
+ GPMC をインストールします。詳細については、Microsoft ドキュメントの「[Installing or Removing Remote Server Administration Tools for Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx)」を参照してください。
+ アクセス許可を持つドメインとしてログインし、GPO を作成します。GPO を適切な OU にリンクします。
**ユーザーがアイドル状態のときに自動的にストリーミングインスタンスをロックするには**
1. ディレクトリまたはドメインコントローラーで、管理者としてコマンドプロンプトを開き、`gpmc.msc` と入力し、ENTER キーを押します。
1. 左のコンソールツリーで、新しい GPO を作成する OU、または既存の GPO を使用する OU を選択して、以下のいずれかの操作を行います。
+ コンテキスト (右クリック) メニューを開き、[**Create a GPO in this domain, Link it here**] を選択して、新しい GPO を作成します。[**Name**] に、この GPO のわかりやすい名前を入力します。
+ 既存の GPO を選択します。
1. GPO のコンテキストメニューを開き、[**編集**] を選択します。
1. [**User Configuration**] (ユーザーの構成) を [**ポリシー**]、[**Administrative Templates**] (管理用テンプレート)、[**コントロールパネル**] の順に展開し、[**Personalization**] (パーソナライズ) を選択します。
1. [**スクリーンセーバーの有効化**] をダブルクリックします。
1. [**Enable screen saver**] (スクリーンセーバーの有効化) ポリシー設定で、[**有効**] を選択します。
1. [**適用**]、[**OK**] の順に選択します。
1. [**スクリーンセーバーの指定**] をダブルクリックします。
1. [**Force specific screen saver**] (スクリーンセーバーの指定) ポリシー設定で、[**有効**] を選択します。
1. [**Screen saver executable name (スクリーンセーバーの実行ファイル名)**] に **scrnsave.scr** と入力します。この設定が有効になると、システムによってユーザーのデスクトップに黒いスクリーンセーバーが表示されます。
1. [**適用**]、[**OK**] の順に選択します。
1. [**スクリーンセーバーのパスワード保護**] をダブルクリックします。
1. [**Password protect the screen saver**] (スクリーンセーバーのパスワード保護) ポリシー設定で、[**有効**] を選択します。
1. [**適用**]、[**OK**] の順に選択します。
1. [**スクリーンセーバーのタイムアウト**] をダブルクリックします。
1. [**Screen saver timeout**] (スクリーンセーバーのタイムアウト) ポリシー設定で、[**有効**] を選択します。
1. [**Seconds**] (秒) に、スクリーンセーバーが適用されるまでのユーザーのアイドル時間の長さを指定します。アイドル時間を 10 分に設定するには、600 秒を指定します。
1. [**適用**]、[**OK**] の順に選択します。
1. コンソールツリーの [**User Configuration**] (ユーザーの構成) を、[**ポリシー**]、[**Administrative Templates**] (管理用テンプレート)、[**システム**] の順に展開し、[**Ctrl\$1Alt\$1Del Options**] を選択します。
1. [**コンピュータのロック解除**] をダブルクリックします。
1. [**Remove Lock Computer**] (コンピュータのロック解除) ポリシー設定で、[**無効**] を選択します。
1. [**適用**]、[**OK**] の順に選択します。
# ディレクトリ設定を編集する
WorkSpaces Applications ディレクトリ設定を作成したら、編集して組織単位の追加、削除、変更、サービスアカウントのユーザー名の更新、またはサービスアカウントのパスワードの更新を行うことができます。
**ディレクトリ設定を更新するには**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) で WorkSpaces アプリケーションコンソールを開きます。
1. 左のナビゲーションペインで、[**Directory Configs**] を選択し編集するディレクトリ設定を選択します。
1. **[Actions]**、**[Edit]** の順に選択します。
1. 変更するフィールドを更新します。追加の OU を追加するには、最上位の OU フィールドの横にあるプラス記号 (**\$1**) を選択します。OU フィールドを削除するには、フィールドの横にある [**x**] を選択します。
**注記**
少なくとも 1 つの OU が必要です。現在使用されている OU を削除することはできません。
1. 変更を保存するには、[**Update Directory Config**] を選択します。
1. [**Details**] タブの情報を、変更が反映されるように更新する必要があります。
サービスアカウントのサインイン認証情報の変更は、処理中のストリーミングインスタンスオペレーションに影響しません。新しいストリーミングインスタンスオペレーションでは更新された認証情報が使用されます。詳細については、「[ドメインの参加に使用するサービスアカウントの更新](active-directory-service-acct.md)」を参照してください。
# ディレクトリ設定を削除する
不要になった WorkSpaces Applications ディレクトリ設定を削除できます。Image Builder またはフリートに関連付けられているディレクトリ設定は削除できません。
**ディレクトリ設定を削除するには**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) で WorkSpaces アプリケーションコンソールを開きます。
1. 左のナビゲーションペインで、[**Directory Configs**] を選択し削除するディレクトリ設定を選択します。
1. **[アクション]**、**[削除]** の順に選択します。
1. ポップアップメッセージの名前を確認し、[**Delete**] を選択します。
1. [**Update Directory Config**] を選択します。
# ドメイン信頼を使用するように WorkSpaces アプリケーションを設定する
WorkSpaces アプリケーションは、ファイルサーバー、アプリケーション、コンピュータオブジェクトなどのネットワークリソースが 1 つのドメインに存在し、ユーザーオブジェクトが別のドメインに存在する Active Directory ドメイン環境をサポートします。コンピュータオブジェクトオペレーションに使用されるドメインサービスアカウントは、WorkSpaces アプリケーションコンピュータオブジェクトと同じドメインに存在する必要はありません。
ディレクトリ設定を作成する際、適切なアクセス許可を持つサービスアカウントを指定して、サーバー、アプリケーション、コンピュータオブジェクト、その他のネットワークリソースが存在するアクティブディレクトリドメインのコンピュータオブジェクトを管理します。
エンドユーザーアクティブディレクトリアカウントには、以下に対して「Allowed to Authenticate」許可が必要です。
+ WorkSpaces アプリケーションコンピュータオブジェクト
+ ドメインのドメインコントローラー
詳細については、「[アクティブディレクトリコンピュータオブジェクトを作成および管理するための許可の付与](active-directory-permissions.md)」を参照してください。
# Active Directory での WorkSpaces アプリケーションのコンピュータオブジェクトの管理
WorkSpaces Applications は、Active Directory からコンピュータオブジェクトを削除しません。これらのコンピュータオブジェクトはディレクトリで簡単に特定できます。ディレクトリ内の各コンピュータオブジェクトは、`Description` 属性で作成されます。この属性では、フリートまたは Image Builder インスタンスとその名前を指定します。
**コンピュータオブジェクトの Description 例**
| タイプ | 名前 | Description 属性 |
| --- | --- | --- |
| Fleet | ExampleFleet | `WorkSpaces Applications - fleet:ExampleFleet` |
| Image Builder | ExampleImageBuilder | `WorkSpaces Applications - image-builder:ExampleImageBuilder` |
WorkSpaces アプリケーションによって作成された非アクティブなコンピュータオブジェクトは、次の `dsquery computer` および `dsrm` コマンドを使用して識別および削除できます。詳細については、Microsoft ドキュメントの [Dsquery computer](https://technet.microsoft.com/en-us/library/cc730720.aspx) と [Dsrm](https://technet.microsoft.com/en-us/library/cc731865.aspx) を参照してください。
`dsquery` コマンドは、一定期間非アクティブなコンピュータオブジェクトを識別します。また、次の形式が使用されます。`dsquery` コマンドは、WorkSpaces Applications オブジェクトのみ`-desc "WorkSpaces Applications*"`を表示するには、 パラメータを使用して実行する必要があります。
```
dsquery computer "OU-distinguished-name" -desc "WorkSpaces Applications*" -inactive number-of-weeks-since-last-login
```
+ `OU-distinguished-name` は組織単位の識別名です。詳細については、「[組織単位の識別子名を検索する](active-directory-oudn.md)」を参照してください。*OU-distinguished-name* パラメータを指定しない場合、ディレクトリ全体が検索されます。
+ `number-of-weeks-since-last-log-in` は、アイドル状態の定義方法に基づく任意の値です。
たとえば、次のコマンドでは、過去 2 週間以内にログインされていない `OU=ExampleOU,DC=EXAMPLECO,DC=COM` 組織単位内のすべてのコンピュータオブジェクトが表示されます。
```
dsquery computer OU=ExampleOU,DC=EXAMPLECO,DC=COM -desc "WorkSpaces Applications*" -inactive 2
```
一致が検出された場合、結果は 1 つまたは複数のオブジェクト名です。`dsrm` コマンドは指定したオブジェクトを削除し、次の形式を使用します。
```
dsrm objectname
```
ここで、`objectname` は `dsquery` コマンドの出力で取得された完全なオブジェクト名です。たとえば、上記の `dsquery` コマンドの結果が「ExampleComputer」という名前のコンピュータオブジェクトであるとすると、これを削除する `dsrm` コマンドは次のようになります。
```
dsrm "CN=ExampleComputer,OU=ExampleOU,DC=EXAMPLECO,DC=COM"
```
これらのコマンドは、パイプ (`|`) 演算子を使用してチェーン処理することができます。たとえば、すべての WorkSpaces Applications コンピュータオブジェクトを削除し、それぞれの確認を求めるには、次の形式を使用します。確認を無効にするには、`dsrm` に `-noprompt` パラメータを追加します。
```
dsquery computer OU-distinguished-name -desc "WorkSpaces Applications*" –inactive number-of-weeks-since-last-log-in | dsrm
```
# 詳細情報
このトピックに関連する詳細情報については、以下のリソースを参照してください。
+ [通知コードのトラブルシューティング](troubleshooting-notification-codes.md)—通知コードエラーの解決策です。
+ [Active Directory のトラブルシューティング](troubleshooting-active-directory.md)—一般的な問題のヘルプです。
+ [Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) — の使用に関する情報 Directory Service。