Red Hat Training

A Red Hat training course is available for RHEL 8

34.10. 他のフォレストのサービスへのクライアントアクセスに関するトラブルシューティング

Identity Management (IdM) 環境と Active Directory (AD) 環境の間に信頼を設定した後、一方のドメインのクライアントがもう一方のドメインのサービスにアクセスできないという問題が発生する場合があります。次の図を使用して、問題のトラブルシューティングを行ってください。

34.10.1. AD フォレストルートドメイン内のホストが IdM サーバーのサービスをリクエストする場合の情報の流れ

次の図は、Active Directory (AD) クライアントが Identity Management (IdM) ドメインのサービスをリクエストする際の情報の流れを説明しています。

AD クライアントから IdM サービスにアクセスする際に問題が発生した場合は、この情報を使用してトラブルシューティングの作業を絞り込み、問題の原因を特定できます。

diagram showing how an AD client communicates with an AD Domain Controller and an IdM server

  1. AD クライアントは AD Kerberos Distribution Center (KDC) に接続して、IdM ドメインのサービスに対して TGS リクエストを実行します。
  2. AD KDC は、サービスが信頼された IdM ドメインに属していることを認識します。
  3. AD KDC は、信頼された IdM KDC への参照とともに、クライアントにレルム間のチケット保証チケット (TGT) を送信します。
  4. AD クライアントは、レルム間 TGT を使用して IdM KDC へのチケットをリクエストします。
  5. IdM KDC は、クロスレルム TGT で送信される特権属性証明書 (MS-PAC) を検証します。
  6. IPA-KDB プラグインは、LDAP ディレクトリーをチェックして、外部プリンシパルがリクエストされたサービスのチケットを取得できるかどうかを確認する場合があります。
  7. IPA-KDB プラグインは、MS-PAC をデコードし、データを検証およびフィルタリングします。LDAP サーバーで検索を行い、、ローカルグループなどの追加情報で MS-PAC を拡張する必要があるかどうかを確認します。
  8. 次に、IPA-KDB プラグインは PAC をエンコードして署名し、サービスチケットに添付して AD クライアントに送信します。
  9. AD クライアントは、IdM KDC によって発行されたサービスチケットを使用して IdM サービスに接続できるようになります。

34.10.2. AD 子ドメイン内のホストが IdM サーバーのサービスをリクエストする場合の情報の流れ

次の図は、子ドメイン内の Active Directory (AD) ホストが Identity Management (IdM) ドメインのサービスをリクエストする際の情報の流れを説明しています。このシナリオでは、AD クライアントは子ドメインの Kerberos Distribution Center (KDC) に接続し、次に AD フォレストルートの KDC に接続し、最後に IdM KDC に接続して IdM サービスへのアクセスをリクエストします。

AD クライアントから IdM サービスにアクセスする際に問題が発生し、AD クライアントが AD フォレストルートの子ドメインであるドメインに属する場合、この情報を使用してトラブルシューティングの作業を絞り込み、問題の原因を特定できます。

diagram showing how an AD client in a chile domain communicates with multiple layers of AD Domain Controllers and an IdM server

  1. AD クライアントは 独自ドメイン内の AD Kerberos Distribution Center (KDC) に接続して、IdM ドメインのサービスに対して TGS リクエストを実行します。
  2. 子ドメインである child.ad.example.com 内の AD KDC は、サービスが信頼された IdM ドメインに属していることを認識します。
  3. 子ドメイン内の AD KDC は、AD フォレストルートドメイン ad.example.com の参照チケットをクライアントに送信します。
  4. AD クライアントは、IdM ドメインのサービスについて、AD フォレストルートドメインの KDC に接続します。
  5. フォレストルートドメインの KDC は、サービスが信頼された IdM ドメインに属していることを認識します。
  6. AD KDC は、信頼された IdM KDC への参照とともに、クライアントにレルム間のチケット保証チケット (TGT) を送信します。
  7. AD クライアントは、レルム間 TGT を使用して IdM KDC へのチケットをリクエストします。
  8. IdM KDC は、クロスレルム TGT で送信される特権属性証明書 (MS-PAC) を検証します。
  9. IPA-KDB プラグインは、LDAP ディレクトリーをチェックして、外部プリンシパルがリクエストされたサービスのチケットを取得できるかどうかを確認する場合があります。
  10. IPA-KDB プラグインは、MS-PAC をデコードし、データを検証およびフィルタリングします。LDAP サーバーで検索を行い、、ローカルグループなどの追加情報で MS-PAC を拡張する必要があるかどうかを確認します。
  11. 次に、IPA-KDB プラグインは PAC をエンコードして署名し、サービスチケットに添付して AD クライアントに送信します。
  12. AD クライアントは、IdM KDC によって発行されたサービスチケットを使用して IdM サービスに接続できるようになります。

34.10.3. IdM クライアントが AD サーバーのサービスをリクエストする場合の情報の流れ

次の図は、Identity Management (IdM) と Active Directory (AD) の間に双方向の信頼を設定した場合に、IdM クライアントが AD ドメインでサービスをリクエストする場合の情報の流れを説明しています。

IdM クライアントから AD サービスにアクセスする際に問題が発生した場合は、この情報を使用してトラブルシューティングの取り組みを絞り込み、問題の原因を特定できます。

注記

デフォルトでは、IdM は AD への一方向の信頼を確立します。つまり、AD フォレスト内のリソースに対してレルム間のチケット保証チケット (TGT) を発行することはできません。信頼された AD ドメインからサービスへのチケットをリクエストできるようにするには、双方向の信頼を設定します。

diagram showing how an IdM client communicates with an IdM server and an AD Domain Controller

  1. IdM クライアントは、接続する AD サービスの IdM Kerberos Distribution Center (KDC) にチケット保証チケット (TGT) を要求します。
  2. IdM KDC は、サービスが AD レルムに属していることを認識し、レルムが既知で信頼されていること、およびクライアントがそのレルムからサービスをリクエストできることを確認します。
  3. IdM Directory Server からのユーザープリンシパルに関する情報を使用して、IdM KDC は、ユーザープリンシパルに関する特権属性証明書 (MS-PAC) レコードを使用してレルム間 TGT を作成します。
  4. IdM KDC は、レルム間 TGT を IdM クライアントに送り返します。
  5. IdM クライアントは AD KDC に接続して、AD サービスのチケットをリクエストし、IdM KDC によって提供される MS-PAC を含むレルム間 TGT を提示します。
  6. AD サーバーは PAC を検証およびフィルタリングし、AD サービスのチケットを返します。
  7. これで、IPA クライアントは AD サービスに接続できます。