Red Hat Training

A Red Hat training course is available for RHEL 8

32.9. フォレスト間の信頼設定に関するトラブルシューティング

この章では、Identity Management (IdM) 環境と Active Directory (AD) フォレストの間で、フォレスト間で信頼を設定するプロセスのトラブルシューティングについて説明します。

32.9.1. AD とのフォレスト間の信頼を確立する際の一連のイベント

ipa trust-add コマンドを使用して、Active Directory (AD) ドメインコントローラー (DC) とのフォレスト間の信頼を確立すると、コマンドを実行したユーザーに代わってコマンドが動作し、IdM サーバーで次のアクションを実行します。フォレスト間の信頼を確立する際に問題が発生した場合は、このリストを使用して、問題を絞り込み、トラブルシューティングすることができます。

パート 1: コマンドによる設定と入力の確認

  1. IdM サーバーに Trust Controller のロールがあることを確認します。
  2. ipa trust-add コマンドに渡されたオプションを確認します。
  3. 信頼されたフォレストルートドメインに関連付けられている ID 範囲を確認します。ID 範囲の種類とプロパティーを ipatrust-add コマンドのオプションとして指定しなかった場合、それらは Active Directory から検出されます。

パート 2: コマンドによる Active Directory ドメインへの信頼確立の試行

  1. 信頼方向ごとに個別の信頼オブジェクトを作成します。各オブジェクトは両サイド (IdM と AD) で作成されます。一方向の信頼を確立する場合、各サイドに 1 つのオブジェクトのみが作成されます。

  2. IdM サーバーは Samba スイートを使用して Active Directory のドメインコントローラー機能を処理し、ターゲット AD PDC 上に信頼オブジェクトを作成します。

    1. IdM サーバーは、ターゲット DC 上の IPC$ 共有への安全な接続を確立します。RHEL 8.4 以降、接続には、セッションに使用される AES ベースの暗号化で接続が十分に保護されていることを保証するために、少なくとも WindowsServer2012 以降での SMPB3 プロトコルが必要です。
    2. IdM サーバーは、LSA QueryTrustedDomainInfoByName 呼び出しを使用して、信頼されたドメインオブジェクト (TDO) の存在をクエリーします。

    3. TDO がすでに存在する場合は、LSA DeleteTrustedDomain 呼び出しを使用してその TDO を削除します。

      注記

      信頼の確立に使用される AD ユーザーアカウントに、Incoming Forest Trust Builders グループのメンバーなど、フォレストルートに対する完全な Enterprise Admin (EA) または Domain Admin (DA) 特権がない場合、この呼び出しは失敗します。古い TDO が自動的に削除されない場合、AD 管理者は手動で AD から削除する必要があります。

    4. IdM サーバーは、LSA CreateTrustedDomainEx2 呼び出しを使用して新しい TDO を作成します。TDO クレデンシャルは、Samba が提供する 128 文字のランダムなパスワードジェネレーターを使用してランダムに生成されます。

    5. 次に、新しい TDO を LSA SetInformationTrustedDomain 呼び出しで変更し、信頼でサポートされている暗号化タイプが適切に設定されていることを確認します。

      1. Active Directory の設計に基づき、RC4 キーが使用されていない場合でも、RC4_HMAC_MD5 暗号化タイプが有効になっている。
      2. AES128_CTS_HMAC_SHA1_96 および AES256_CTS_HMAC_SHA1_96 暗号化タイプが有効になっている。
  3. フォレストの信頼の場合、LSA SetInformationTrustedDomain 呼び出しでフォレスト内のドメインに推移的に到達できることを確認します。

  4. LSA RSetForestTrustInformation 呼び出しを使用して、他のフォレスト (AD と通信する場合は IdM、IdM と通信する場合は AD) に関する信頼トポロジー情報を追加します。

    注記

    この手順により、次の 3 つの理由のいずれかで競合が発生する可能性があります。

    1. LSA_SID_DISABLED_CONFLICT エラーとして報告される SID namespace の競合。この競合は解決できません。
    2. LSA_NB_DISABLED_CONFLICT エラーとして報告される NetBIOS namesapce の競合。この競合は解決できません。
    3. LSA_TLN_DISABLED_CONFLICT エラーとして報告される、DNS namespace とトップレベル名 (TLN) の競合。別のフォレストが原因で TLN の競合が発生した場合、IdM サーバーは自動的に解決できます。

    TLN の競合を解決するために、IdM サーバーは次の手順を実行します。

    1. 競合するフォレストのフォレスト信頼情報を取得します。
    2. IdM DNS namespace 間の除外エントリーを AD フォレストに追加します。
    3. 競合するフォレストのフォレスト信頼情報を設定します。
    4. 元のフォレストへの信頼確立を再試行します。

    IdM サーバーは、フォレストの信頼を変更できる AD 管理者の権限で ipa trust-add コマンドを認証した場合にのみ、これらの競合を解決できます。これらの権限にアクセスできない場合、元のフォレストの管理者は、Windows UI の Active Directory Domains and Trusts セクションで上記の手順を手動で実行する必要があります。

  5. 存在しない場合は、信頼されたドメインの ID 範囲を作成します。
  6. フォレストの信頼については、フォレストのトポロジーの詳細について、フォレストのルートから Active Directory ドメインコントローラーにクエリーします。IdM サーバーはこの情報を使用して、信頼されたフォレストから追加のドメインの追加 ID 範囲を作成します。

関連情報

32.9.2. AD の信頼を確立するための前提条件のチェックリスト

次のチェックリストを使用して、AD ドメインとの信頼を作成するための前提条件を確認できます。

表32.4 テーブル

コンポーネント設定詳細

製品バージョン

Active Directory ドメインは、サポートされているバージョンの Windows Server を使用しています。

サポート対象の Windows Server バージョン

AD 管理者権限

Active Directory 管理アカウントは、次のいずれかのグループのメンバーです。

  • AD フォレストの Enterprise Admin (EA) グループ
  • AD フォレスト用のフォレストルートドメインの Domain Admins (DA) グループ
 

ネットワーク

IPv6 サポートは、すべての IdM サーバーの Linux カーネルで有効になっています。

IdM における IPv6 要件

日時

両方のサーバーの日付と時刻の設定が一致していることを確認します。

IdM のタイムサービス要件

暗号化タイプ

次の AD アカウントに AES 暗号化キーがあります。

  • AD 管理者
  • AD ユーザーアカウント
  • AD サービス

最近 AD で AES 暗号化を有効にした場合は、次の手順で新しい AES キーを生成します。

  1. フォレスト内の AD ドメイン間の信頼関係を再確立します。
  2. AD 管理者、ユーザーアカウント、およびサービスのパスワードを変更します。

ファイアウォール

双方向通信のために、IdM サーバーと AD ドメインコントローラーで必要なすべてのポートを開いています。

IdM と AD との間の通信に必要なポート

DNS

  • IdM と AD には、それぞれ固有のプライマリー DNS ドメインがあります。
  • IdM ドメインと AD DNS ドメインは重複していません。
  • LDAP および Kerberos サービスの適切な DNS サービス (SRV) レコード。
  • 信頼内のすべての DNS ドメインから DNS レコードを解決できます。
  • Kerberos レルム名は、プライマリー DNS ドメイン名を大文字にしたものです。たとえば、DNS ドメイン example.com には、対応する Kerberos レルム EXAMPLE.COM があります。

信頼用の DNS およびレルムの設定の設定

トポロジー

信頼コントローラーとして設定した IdM サーバーとの信頼を確立しようとしていることを確認します。

信頼コントローラーおよび信頼エージェント

32.9.3. AD の信頼を確立する試みのデバッグログを収集

IdM 環境と AD ドメイン間の信頼確立で問題が発生した場合は、次の手順を使用して詳細なエラーログを有効にし、信頼を確立する試みのログを収集できるようにします。これらのログを確認してトラブルシューティング作業に役立てたり、Red Hat テクニカルサポートケースで提供したりできます。

前提条件

  • IdM サービスを再起動するには root 権限が必要です。

手順

  1. IdM サーバーのデバッグを有効にするには、次の内容でファイル /etc/ipa/server.conf を作成します。 

    [global]
debug=True

  2. httpd サービスを再起動して、デバッグ設定をロードします。 

    [root@trust_controller ~]# systemctl restart httpd

  3. smb および winbind サービスを停止します。 

    [root@trust_controller ~]# systemctl stop smb winbind

  4. smb および winbind サービスのデバッグログレベルを設定します。 

    [root@trust_controller ~]# net conf setparm global 'log level' 100

  5. IdM フレームワークで使用される Samba クライアントコードのデバッグログを有効にするには、/usr/share/ipa/smb.conf.empty 設定ファイルを編集して次の内容にします。 

        [global]
    log level = 100

  6. 以前の Samba ログを削除します。 

    [root@trust_controller ~]# rm /var/log/samba/log.*

  7. smb サービスおよび winbind サービスを起動します。 

    [root@trust_controller ~]# systemctl start smb winbind

  8. 詳細モードを有効にして信頼の確率を試みる際に、タイムスタンプを出力します。 

    [root@trust_controller ~]# date; ipa -vvv trust-add --type=ad ad.example.com

  9. 失敗したリクエストについては、次のエラーログファイルを確認してください。

    1. /var/log/httpd/error_log
    2. /var/log/samba/log.*

  10. デバッグを無効にします。 

    [root@trust_controller ~]# mv /etc/ipa/server.conf /etc/ipa/server.conf.backup
[root@trust_controller ~]# systemctl restart httpd
[root@trust_controller ~]# systemctl stop smb winbind
[root@trust_controller ~]# net conf setparm global 'log level' 0
[root@trust_controller ~]# mv /usr/share/ipa/smb.conf.empty /usr/share/ipa/smb.conf.empty.backup
[root@trust_controller ~]# systemctl start smb winbind

  11. (オプション) 認証問題の原因を判断できない場合は、以下を行います。

    1. 最近生成したログファイルを収集してアーカイブします。 

      [root@trust_controller ~]# tar -xcvf debugging-trust.tar /var/log/httpd/error_log /var/log/samba/log.*
    2. Red Hat テクニカルサポートケースを開き、試行からのタイムスタンプとデバッグログを提供します。

関連情報