翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 前提条件
証明書ベースの認証を使用する前に、以下のステップを完了します。
1. SAML 2.0 統合を使用して、証明書ベースの認証を使用するように WorkSpaces Pools ディレクトリを設定します。詳細については、「[SAML 2.0 を設定して WorkSpaces Pools ディレクトリを作成する](create-directory-pools.md)」を参照してください。
**注記**
証明書ベースの認証を使用する場合は、プールディレクトリ内で **[スマートカードサインイン]** を有効にしないでください。
1. SAML アサーションの `userPrincipalName` 属性を設定します。詳細については、「[ステップ 7: SAML 認証レスポンスのアサーションを作成する](create-directory-pools.md#saml-directory-create-assertions)」を参照してください。
1. SAML アサーションの `ObjectSid` 属性を設定します。この属性を使用して、Active Directory ユーザーとの強力なマッピングを実行できます。`ObjectSid` 属性が SAML\$1Subject `NameID` で指定されたユーザーの Active Directory セキュリティ識別子 (SID) と一致しない場合、証明書ベースの認証は失敗します。詳細については、「[ステップ 7: SAML 認証レスポンスのアサーションを作成する](create-directory-pools.md#saml-directory-create-assertions)」を参照してください。
**注記**
[Microsoft KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16) によると、`ObjectSid` 属性は 2025 年 9 月 10 日以降、証明書ベースの認証で必須となります。
1. SAML 2.0 設定で使用する IAM ロールの信頼ポリシーに `sts:TagSession` アクセス権限を追加します。詳細については、*「AWS Identity and Access Management ユーザーガイド」*の[「AWS STS でのタグ付けの規則」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html)を参照してください。この権限は、証明書ベースの認証を使用する場合に必要です。詳細については、「[ステップ 5: SAML 2.0 フェデレーション IAM ロールを作成する](create-directory-pools.md#saml-directory-saml-federation-role-in-iam)」を参照してください。
1. Active Directory で設定されていない場合は、AWS プライベート CA を使用してプライベート認証機関 (CA) を作成します。AWSプライベート CA は、証明書ベースの認証を使用する場合に必要です。詳細については、「*AWS Private Certificate Authority ユーザーガイド*」で [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 Pools の WorkSpaces とドメインコントローラーの両方からアクセスできるオンライン CRL ディストリビューションポイントが必要です。これには、AWS プライベート CA CRL エントリ用に設定された Amazon S3 バケットへの認証されていないアクセスが必要です。パブリックアクセスをブロックする場合は Amazon S3 バケットにアクセスできる CloudFront ディストリビューションが必要です。これらのオプションの詳細については、「*AWS Private Certificate Authority ユーザーガイド*」で[証明書失効リスト (CRL) の計画](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html)に関するセクションを参照してください。
1. プライベート CA に `euc-private-ca` という名前のキーでタグ付けし、WorkSpaces Pools の証明書ベースの認証で使用する CA を指定します。このキーには値は必要ありません。詳細については、「*AWS Private Certificate Authority ユーザーガイド*」の[プライベート CA のタグ管理](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html)に関するセクションを参照してください。
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 プライベート CA でドメインコントローラー証明書を作成できます。その場合は、使用期間の短い証明書用に設定されたプライベート CA を使用しないでください。
**注記**
AWS Managed Microsoft AD を使用する場合、ドメインコントローラー証明書の要件を満たす Amazon EC2 インスタンスで証明書サービスを設定できます。Active Directory 証明書サービスで設定された AWS マネージド Microsoft AD のデプロイ例については、「[新しい Amazon Virtual Private Cloud への Active Directory のデプロイ](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html)」を参照してください。
AWS Managed Microsoft AD と Active Directory 証明書サービスでは、コントローラーの VPC セキュリティグループから証明書サービスを実行している 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 Pools の WorkSpaces に公開されるまでに数分かかる場合があります。
**注記**
WorkSpaces Pools の WorkSpaces がドメインに参加したときに、Active Directory が、信頼されたルート認証機関とエンタープライズ NTAuth ストアに CA を自動的に配布する必要があります。
**注記**
証明書の強力な強制で証明書ベースの認証をサポートするには、Active Directory ドメインコントローラーを互換モードにする必要があります。詳細については、Microsoft Support ドキュメントの「[KB5014754 - Windows ドメインコントローラーでの証明書ベースの認証の変更](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16)」を参照してください。AWS マネージド Microsoft AD を使用している場合は、「[ディレクトリセキュリティ設定の構成](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_directory_settings.html)」で詳細を確認してください。