前提条件 Active Directory グループの命名規則を計画する AWS 設定 Active Directory の設定設定をテストするでデフォルトの SAML アサーションエンドポイントを更新する ADFS

を使用した直接 IAM フェデレーションアプリケーションの 1 回限りのセットアップ ADFS

このガイドでは、IAM Identity Center が利用できない場合にへの緊急アクセスを有効にするADFSために、との直接 IAM フェデレーションを設定する 1 AWS アカウント回限りのセットアッププロセスについて説明します。

前提条件

AWS Managed Microsoft AD ADFSでを設定する場合は、まずマルチリージョンレプリケーションを設定し、回復性のためにプライマリリージョンではなく、追加のリージョンで次のステップに進むことをお勧めします。

Active Directory グループの命名規則を計画する

グループ名と IAM ロールの自動マッチングを可能にする特定の命名パターンを使用して AD AWS グループを作成します。

グループ命名形式: AWS-<AccountNumber>-<RoleName>

図については、緊急時のロール、アカウント、グループのマッピングを設計する方法の図の緊急アカウントを参照してください。ユーザーがこのグループに割り当てられると、アカウントのEmergencyAccess_Role1_ROロールへのアクセス権が付与されます123456789012。ユーザーが複数のグループに関連付けられている場合、によって使用可能なロールのリストが表示され AWS アカウント、引き受けるロールを選択できます。

AWS 設定

完全なセットアップには、緊急アクセスアカウントとワークロードアカウントの設定が含まれます。セットアップ全体の図については、「」を参照してください緊急時のロール、アカウント、グループのマッピングを設計する方法。

SAML ID プロバイダーを作成する
緊急アクセスロールを作成する
ワークロードアカウントロールを設定する

SAML ID プロバイダーを作成する

緊急アクセスアカウントで、「IAM で SAML ID プロバイダーを作成する」の手順に従って、IAM で SAML ID プロバイダーを作成します。ADFS サーバーから必要なメタデータをダウンロードします。

https://<yourADFSserverFQDN>/FederationMetadata/2007-06/FederationMetadata.xml

緊急アクセスロールを作成する

信頼できるエンティティタイプとして SAML 2.0 フェデレーションを使用して、緊急アカウントに緊急アクセスロールを作成します。前のステップで作成した SAML 2.0 プロバイダーを選択します。

考慮事項:

運用しているすべてのリージョンを含める — アクティブなワークロードがあるすべてのリージョンを選択して、リージョンの中断時にフェデレーションが引き続き利用可能になるようにします。
1 つのリージョンで運用している場合でも、少なくとも 1 つの追加のリージョンエンドポイントを設定します。たとえば、でのみ運用している場合はus-east-1、をセカンダリエンドポイントus-west-2として追加します。IdP を SAML us-west-2 サインインエンドポイントにフェイルオーバーしても、のワークロードがなくてもus-east-1リソースにアクセスできますus-west-2。
非リージョンエンドポイントとリージョンエンドポイントの両方を有効にする — 非リージョンエンドポイント (https://signin.aws.amazon.com/saml) は高可用性ですが、単一のでホストされます。一方us-east-1、リージョンエンドポイント (https://<region>.signin.aws.amazon.com/saml) は AWS リージョン、単一のグローバルエンドポイントへの依存を減らすことで回復性を向上させます。

信頼ポリシーを設定する

複数のサインインリージョンエンドポイントを持つ信頼ポリシーの例Okta でダイレクト IAM フェデレーションアプリケーションの 1 回限りの設定を行うについては、「」を参照してください。サンプルリージョンエンドポイントと SAML プロバイダー ARNs をに置き換えます。

アクセス許可ポリシーを設定する

緊急アクセスロールにアタッチするアクセス許可ポリシーの例Okta でダイレクト IAM フェデレーションアプリケーションの 1 回限りの設定を行うについては、「」を参照してください。

ワークロードアカウントロールを設定する

ワークロードアカウントロールには、緊急アクセスアカウントの緊急アクセスロールが引き受けることを許可するカスタム信頼ポリシーを設定します。アカウント123456789012が緊急アクセスアカウントである信頼ポリシーの例Okta でダイレクト IAM フェデレーションアプリケーションの 1 回限りの設定を行うについては、「」を参照してください。

Active Directory の設定

次の手順では、緊急アクセスADFS用に Active Directory とを設定する方法について説明します。

グループの作成
証明書利用者を作成する
クレームルールを作成する

グループの作成

前述の命名規則 ( などAWS-123456789012-EmergencyAccess_Role1_RO) に従って、Active Directory に緊急グループを作成します。既存のプロビジョニングメカニズムを使用して、これらのグループにユーザーを割り当てます。

証明書利用者を作成する

ADFS フェデレーションには、証明書利用者の設定が必要です。証明書利用者は AWS Security Token Service (AWS STS) であり、ID プロバイダーADFSとしてに認証をアウトソースします。

ADFS マネジメントコンソールで、アクションメニューを使用して、証明書利用者の信頼の追加を選択します。証明書利用者を追加するときに認識するクレームを選択します。
フェデレーションメタデータの場合は、IAM コンソールの ID プロバイダーメタデータ情報からメタデータ URL を入力します。例えば、次のようになります。

https://signin.aws.amazon.com/static/saml/SAMLSPXXXXXX/saml-metadata.xml
証明書利用者の表示名 (AWS アカウントアクセスなど) を設定し、次へを選択します。
アクセスを有効にするユーザーを選択します AWS。特定のグループを選択し、MFA などの要件を定義できます。
完了ページで閉じるを選択して、証明書利用者信頼の追加ウィザードを完了します。 AWS は証明書利用者として設定されました。

クレームルールを作成する

ADFS はクレームルール言語を使用して、クレームプロバイダーと証明書利用者の間でクレームを発行および変換します。、NameId、RoleSessionNameGet AD Groups、および AWS アクセス用のロールの 4 つのクレームルールを作成する必要があります。

証明書利用者を右クリックし、クレーム発行ポリシーの編集を選択します。ルールの追加 を選択してルールを追加します。

1NameId.

受信クレームの変換を選択し、次へを選択します。
以下の設定を使用します。
- クレームルール名: NameId
- 受信クレームタイプ: Windows Account Name
- 送信クレームタイプ: Name ID
- 送信名 ID 形式: Persistent Identifier
- すべてのクレーム値をパススルーする: チェック
[OK] を選択してください。

2。 RoleSessionName

[ルールの追加] を選択します。
クレームルールテンプレートリストで、クレームとして LDAP 属性を送信するを選択します。
以下の設定を使用します。
- クレームルール名: RoleSessionName
- 属性ストア: Active Directory
- LDAP 属性: E-Mail-Addresses
- 送信クレームタイプ: https://aws.amazon.com/SAML/Attributes/RoleSessionName
[OK] を選択してください。

3。AD グループの取得

[ルールの追加] を選択します。
クレームルールテンプレートリストで、カスタムルールを使用してクレームを送信するを選択し、次へを選択します。
クレームルール名にを入力しGet AD Groups、カスタムルールに次のように入力します。
```
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);
```
このカスタムルールは、クレームルール言語のスクリプトを使用して、認証されたユーザーがメンバーであるすべてのグループを取得し、という名前の一時クレームに配置しますhttp://temp/variable。

注記
予期しない結果を避けるため、末尾に空白がないことを確認します。

4. ロール属性

[ルールの追加] を選択します。
クレームルールテンプレートリストで、カスタムルールを使用してクレームを送信を選択し、次へを選択します。
クレームルール名にを入力しRoles、カスタムルールに次のように入力します。
```
c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-([\d]{12})"]
=> issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-([\d]{12})-", "arn:aws:iam::$1:saml-provider/<ADFS>,arn:aws:iam::$1:role/"));
```
このカスタムルールは正規表現を使用して、フォームの各グループメンバーシップをが AWS 想定する AWS-<Account Number>-<Role Name> IAM ロール ARN および IAM フェデレーションプロバイダー ARN フォームに変換します。

注記
上記のルール言語例では、は ID プロバイダーのセットアップで SAML ID AWS プロバイダーに与えられた論理名ADFSを表します。これは、ID プロバイダーの IAM コンソールで選択した論理名に基づいて変更します。

設定をテストする

でを認証して、ソリューションが機能することをテストしますhttps://<yourADFSserverFQDN>/adfs/ls/IdpInitiatedSignOn.aspx。サイトのドロップダウンリストから、作成した証明書利用者の名前を選択します。

でデフォルトの SAML アサーションエンドポイントを更新する ADFS

重要

で証明書利用者の信頼を設定する場合ADFS、SAML Assertion エンドポイントはデフォルトでに設定されます。 https://signin.aws.amazon.com/ はグローバルエンドポイントではなく、にありますus-east-1。デフォルトのエンドポイントを、IAM アイデンティティセンターの回復性が設定されているとは異なるリージョンエンドポイントに変更することをお勧めします。たとえば、IAM アイデンティティセンターがにデプロイus-east-1されていて、でも操作している場合はus-west-2、デフォルトの SAML Assertion コンシューマーエンドポイントをに変更しますhttps://us-west-2.signin.aws.amazon.com/saml。

証明書利用者の信頼のプロパティを選択し、モニタリングタブに移動します。チェックボックスをオフにして、証明書利用者を自動的に更新します。
エンドポイントタブに移動し、任意のサインインエンドポイントを選択し、編集を選択します。
チェックボックスをオンにします。信頼された URL をデフォルトに設定します。OK を選択し、設定を適用して有効にします。

注記

ほとんどの IdPs では、必要になるまでアプリケーション統合を無効にしておくことができます。緊急アクセスが必要となるまで、IdP のダイレクト IAM フェデレーションアプリケーションを無効にしたままにしておくことをお勧めします。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Okta でダイレクト IAM フェデレーションアプリケーションの 1 回限りの設定を行う

セキュリティ