手順

1. Group Policy Management Console を開きます。
2. デフォルトドメインポリシー を右クリックして、編集 を選択します。Group Policy Management Editor を閉じます。
3. コンピューターの設定 → ポリシー → Windows の設定 → セキュリティーの設定 → ローカルポリシー → セキュリティーオプション に移動します。
4. ネットワーク セキュリティー: Kerberos で許可する暗号化の種類を設定する をダブルクリックします。
5. AES256_HMAC_SHA1 を選択し、必要に応じて、将来の暗号化タイプ を選択します。
6. OK をクリックします。
7. Group Policy Management Editor を閉じます。
8. デフォルトのドメインコントローラーポリシー に対して手順を繰り返します。

9. Windows ドメインコントローラー (DC) がグループポリシーを自動的に適用するまで待ちます。または、GPO を DC に手動で適用するには、管理者権限を持つアカウントを使用して次のコマンドを入力します。

   C:\> gpupdate /force /target:computer

手順

1. update-crypto-policies コマンドを使用して、DEFAULT 暗号化ポリシーに加え AD-SUPPORT-LEGACY 暗号化サブポリシーを有効にします。

   [root@host ~]# update-crypto-policies --set DEFAULT:AD-SUPPORT-LEGACY
   Setting system policy to DEFAULT:AD-SUPPORT-LEGACY
   Note: System-wide crypto policies are applied on application start-up.
   It is recommended to restart the system for the change of policies
   to fully take place.

2. ホストを再起動します。

手順

1. 管理者権限で IdM Web UI にログインします。詳細は、Web ブラウザーでの IdM Web UI へのアクセス を参照してください。
2. Network Services タブをクリックします。
3. DNS タブをクリックします。

4. ドロップダウンメニューで、DNS Forward Zones 項目をクリックします。

   

5. Add ボタンをクリックします。
6. Add DNS forward zone ダイアログボックスにゾーン名を追加します。
7. Zone forwarders 項目で、Add ボタンをクリックします。
8. Zone forwarders フィールドに正引きゾーンを作成するサーバーの IP アドレスを追加します。

9. Add ボタンをクリックします。

   

手順

1. Windows サーバーにログインします。
2. Server Manager を開きます。
3. DNS Manager を開きます。

4. Conditional Forwarders で、以下を含む新しい条件フォワーダーを追加します。

   • IdM サーバーの IP アドレス
   • server.idm.example.com などの完全修飾ドメイン名
5. 設定を保存します。

手順

1. UDP サービスレコードの Kerberos、および TCP サービスレコード上の LDAP に、DNS クエリーを実行します。

   [admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com.
   0 100 88 server.idm.example.com.
   
   [admin@server ~]# dig +short -t SRV _ldap._tcp.idm.example.com.
   0 100 389 server.idm.example.com.

   コマンドは、すべての IdM サーバーをリストで表示する必要があります。

2. IdM Kerberos レルム名を使用して、TXT レコードに DNS クエリーを実行します。取得した値は、IdM のインストール時に指定した Kerberos レルムと一致することが予想されます。

   [admin@server ~]# dig +short -t TXT _kerberos.idm.example.com.
   "IDM.EXAMPLE.COM"

   前の手順で想定されるレコードがすべて返されなかった場合は、欠落しているレコードで DNS 設定を更新します。

   • IdM 環境で統合 DNS サーバーを使用する場合は、システムレコードを更新するオプションを指定せずに ipa dns-update-system-records コマンドを実行します。

     [admin@server ~]$ ipa dns-update-system-records

   • IdM 環境で統合 DNS サーバーを使用しない場合は、以下を行います。

     1. IdM サーバーで、IdM DNS レコードをファイルにエクスポートします。

        [admin@server ~]$ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate

        このコマンドは、関連する IdM DNS レコードで dns_records_file.nsupdate という名前のファイルを作成します。

     2. nsupdate ユーティリティーおよび dns_records_file.nsupdate ファイルを使用して DNS サーバーに DNS 更新リクエストを送信します。詳細は、RHEL 7 ドキュメントの nsupdate を使用した外部 DNS レコード更新 を参照してください。または、DNS レコードの追加については、お使いの DNS サーバーのドキュメントを参照してください。

3. IdM が、TCP サービスレコードで Kerberos および LDAP の DNS クエリーを実行するコマンドを使用して、AD のサービスレコードを解決できることを確認します。

   [admin@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
   0 100 88 addc1.ad.example.com.
   
   [admin@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
   0 100 389 addc1.ad.example.com.

手順

1. --domain=IPA_DNS_Domain を指定して IdM クライアントをインストールし、SSSD (System Security Services Daemon) が IdM サーバーと通信できるようにします。

   [root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com

   このオプションは、Active Directory DNS ドメインの SRV レコードの自動検出を無効にします。

2. /etc/krb5.conf 設定ファイルの [domain_realm] セクションで、Active Directory ドメインの既存のマッピングを見つけます。

   .ad.example.com = IDM.EXAMPLE.COM
   ad.example.com = IDM.EXAMPLE.COM

3. 両方の行を、Active Directory DNS ゾーンの Linux クライアントの完全修飾ドメイン名 (FQDN) を IdM レルムにマッピングするエントリーに置き換えます。

   idm-client.ad.example.com = IDM.EXAMPLE.COM

   デフォルトのマッピングを置き換えても、Kerberos が Active Directory ドメインの要求を IdM Kerberos Distribution Center (KDC) に送信しないようにします。Kerberos は、SRV DNS レコードを介して自動検出を使用して KDC を見つけます。

手順

1. IdM サーバーに新しいホストオブジェクトを作成します。

   [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force

   ホスト名は CNAME であり、A/AAAA レコードではないため、--force オプションを使用します。

2. IdM サーバーで、IdM DNS ホスト名が、IdM データベースの Active Directory ホストエントリーを管理できるようにします。

   [root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \
         --hosts=idm-client.idm.example.com

3. これで、Active Directory DNS ドメイン内のホスト名に dNSName 拡張レコードを使用して、IdM クライアントの SSL 証明書を要求できるようになります。

   [root@idm-client.idm.example.com ~]# ipa-getcert request -r \
         -f /etc/httpd/alias/server.crt \
         -k /etc/httpd/alias/server.key \
         -N CN=`hostname --fqdn` \
         -D `hostname --fqdn` \
         -D idm-client.ad.example.com \
         -K host/idm-client.idm.example.com@IDM.EXAMPLE.COM \
         -U id-kp-serverAuth

手順

1. 必要なパッケージをインストールします。

   [root@ipaserver ~]# dnf install ipa-server-trust-ad samba-client

2. IdM 管理ユーザーとして認証します。

   [root@ipaserver ~]# kinit admin

3. ipa-adtrust-install ユーティリティーを実行します。

   [root@ipaserver ~]# ipa-adtrust-install

   統合 DNS サーバーとともに IdM がインストールされていると、DNS サービスレコードが自動的に作成されます。

   IdM が統合 DNS サーバーなしで IdM をインストールすると、ipa-adtrust-install は、続行する前に DNS に手動で追加する必要があるサービスレコードのリストを出力します。

4. スクリプトにより、/etc/samba/smb.conf がすでに存在し、書き換えられることが求められます。

   WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
   
   Do you wish to continue? [no]: yes

5. このスクリプトは、従来の Linux クライアントが信頼できるユーザーと連携できるようにする互換性プラグインである slapi-nis プラグインを設定するように求めるプロンプトを表示します。

   Do you want to enable support for trusted domains in Schema Compatibility plugin?
   This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
   
   Enable trusted domains support in slapi-nis? [no]: yes

6. プロンプトが表示されたら、IdM ドメインの NetBIOS 名を入力するか、Enter を押して提案された名前を使用します。

   Trust is configured but no NetBIOS domain name found, setting it now.
   Enter the NetBIOS name for the IPA domain.
   Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
   Example: EXAMPLE.
   
   NetBIOS domain name [IDM]:

7. SID 生成タスクを実行して、既存ユーザーに SID を作成するように求められます。

   Do you want to run the ipa-sidgen task? [no]: yes

   これはリソースを集中的に使用するタスクであるため、ユーザー数が多い場合は別のタイミングで実行できます。

8. (必要に応じて) デフォルトでは、Windows Server 2008 以降での動的 RPC ポートの範囲は 49152-65535 として定義されます。ご使用の環境に異なる動的 RPC ポート範囲を定義する必要がある場合は、Samba が異なるポートを使用するように設定し、ファイアウォール設定でそのポートを開くように設定します。以下の例では、ポート範囲を 55000-65000 に設定します。

   [root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000
   [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp
   [root@ipaserver ~]# firewall-cmd --runtime-to-permanent

9. 信頼の DNS 設定の確認 に従って、DNS が適切に設定されていることを確認します。

   重要

   Red Hat では、IdM または AD が統合 DNS サーバーを使用しない場合に、ipa-adtrust-install を実行してから 信頼に対する DNS 設定の確認 に従って DNS 設定を検証することが強く推奨されます。

10. ipa サービスを再起動します。

    [root@ipaserver ~]# ipactl restart

11. smbclient ユーティリティーを使用して、Samba が IdM からの Kerberos 認証に応答することを確認します。

    [root@ipaserver ~]# smbclient -L server.idm.example.com -U user_name --use-kerberos=required
    lp_load_ex: changing to config backend registry
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (Samba 4.15.2)
    ...

手順

1. 管理者権限で IdM Web UI にログインします。詳細は、Web ブラウザーでの IdM Web UI へのアクセス を参照してください。
2. IdM Web UI で、IPA Server タブをクリックします。
3. IPA Server タブで、Trusts タブをクリックします。

4. ドロップダウンメニューで、Trusts オプションを選択します。

   

5. Add ボタンをクリックします。
6. Add Trust ダイアログボックスで、Active Directory ドメインの名前を入力します。

7. Account フィールドおよび Password フィールドに、Active Directory 管理者の管理者認証情報を追加します。

   

8. (オプション) AD ユーザーおよびグループが IdM のリソースにアクセスできるようにする場合は、Two-way trust を選択します。ただし、IdM の双方向の信頼では、AD の一方向の信頼ソリューションと比較して、ユーザーに追加の権限が付与されません。デフォルトのフォレスト間信頼の SID フィルタリング設定により、両方のソリューションの安全性は同じであると見なされます。
9. (オプション) AD フォレストのルートドメインではない AD ドメインで信頼を設定する場合は、External trust を選択します。フォレストの信頼では常に IdM と Active Directory フォレストのルートドメインとの間で信頼関係を確立する必要がありますが、IdM から AD フォレスト内の任意のドメインへの外部の信頼関係も確立できます。

10. (オプション) デフォルトでは、信頼インストールスクリプトは適切な ID 範囲タイプの検出を試みます。以下のオプションのいずれかを選択して、ID 範囲タイプを明示的に設定することもできます。

    1. SSSD が SID に基づいて AD ユーザーの UID および GID を自動的に生成するには、Active Directory domain ID 範囲タイプを選択します。これが最も一般的な設定です。

    2. Active Directory でユーザーに POSIX 属性を設定し (uidNumber、gidNumberなど)、SSSD がこの情報を処理する必要がある場合は、Active Directory domain with POSIX attributes ID 範囲タイプを選択します。

       

       警告

       Range type 設定をデフォルトの Detect オプションに残すと、IdM はフォレストルートドメインの AD ドメインコントローラーから詳細を要求することで、適切な範囲タイプを自動的に選択しようとします。IdM が POSIX 属性を検出しない場合、信頼インストールスクリプトは Active Directory domain ID 範囲を選択します。

       IdM がフォレストルートドメインの POSIX 属性を検出すると、信頼インストールスクリプトは、Active Directory domain with POSIX attributes ID 範囲を選択し、UID および GID が AD に正しく定義されていることを前提とします。POSIX 属性が AD で正しく設定されていない場合は、AD ユーザーを解決できません。

       たとえば、IdM システムへのアクセスを必要とするユーザーおよびグループがフォレストルートドメインの一部ではなく、フォレストドメインの子ドメインにある場合は、インストールスクリプトで、子 AD ドメインで定義された POSIX 属性が検出されない場合があります。この場合、Red Hat は、信頼の確立時に POSIX ID 範囲タイプを明示的に選択することを推奨します。

11. Add をクリックします。

手順

1. ~/MyPlaybooks/ ディレクトリーに移動します。

   $ cd ~/MyPlaybooks/

2. ユースケースに基づいて、以下のいずれかのシナリオを選択します。

   • SSSD が SID に基づいて AD ユーザーおよびグループの UID および GID を自動的に生成する ID マッピング信頼合意を作成するには、以下の内容で add-trust.yml Playbook を作成します。

     ---
     - name: Playbook to create a trust
       hosts: ipaserver
     
       vars_files:
       - /home/user_name/MyPlaybooks/secret.yml
       tasks:
         - name: ensure the trust is present
           ipatrust:
             ipaadmin_password: "{{ ipaadmin_password }}"
             realm: ad.example.com
             admin: Administrator
             password: secret_password
             range_type: ipa-ad-trust
             state: present

     上記の例では、以下のようになります。

     • realm は、AD レルム名文字列を定義します。
     • admin は AD ドメイン管理者文字列を定義します。
     • Password は、AD ドメイン管理者のパスワード文字列を定義します。

   • SSSD が AD に保存されている POSIX 属性 (uidNumber や gidNumber など) を処理する POSIX 信頼合意を作成するには、以下の内容で add-trust.yml Playbook を作成します。

     ---
     - name: Playbook to create a trust
       hosts: ipaserver
     
       vars_files:
       - /home/user_name/MyPlaybooks/secret.yml
       tasks:
         - name: ensure the trust is present
           ipatrust:
             ipaadmin_password: "{{ ipaadmin_password }}"
             realm: ad.example.com
             admin: Administrator
             password: secret_password
             range_type: ipa-ad-trust-posix
             state: present

   • フォレストルートドメインの AD ドメインコントローラーからの詳細を要求して、IdM が適切な範囲タイプ ipa-ad-trust または ipa-ad-trust-posix を選択しようとする信頼合意を作成するには、以下の内容を含む add-trust.yml Playbook を作成します。

     ---
     - name: Playbook to create a trust
       hosts: ipaserver
     
       vars_files:
       - /home/user_name/MyPlaybooks/secret.yml
       tasks:
         - name: ensure the trust is present
           ipatrust:
             ipaadmin_password: "{{ ipaadmin_password }}"
             realm: ad.example.com
             admin: Administrator
             password: secret_password
             state: present

   警告

   信頼の作成時に ID 範囲タイプを指定せず、IdM が AD フォレストルートドメインの POSIX 属性を検出しない場合は、信頼インストールスクリプトで Active Directory ドメイン ID 範囲を選択します。

   IdM がフォレストルートドメインの POSIX 属性を検出すると、信頼インストールスクリプトは、Active Directory domain with POSIX attributes ID 範囲を選択し、UID および GID が AD に正しく定義されていることを前提とします。

   ただし、POSIX 属性が AD で正しく設定されていない場合は、AD ユーザーを解決できません。たとえば、IdM システムへのアクセスを必要とするユーザーおよびグループがフォレストルートドメインの一部ではなく、フォレストドメインの子ドメインにある場合は、インストールスクリプトで、子 AD ドメインで定義された POSIX 属性が検出されない場合があります。この場合、Red Hat は、信頼の確立時に POSIX ID 範囲タイプを明示的に選択することを推奨します。

3. ファイルを保存します。

4. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

   $ ansible-playbook --vault-password-file=password_file -v -i inventory add-trust.yml

手順

1. Active Directory (AD) ユーザーのチケットを要求します。

   [root@ipaserver ~]# kinit user@AD.EXAMPLE.COM

2. IdM ドメイン内のサービスのサービスチケットを要求します。

   [root@server ~]# kvno -S host server.idm.example.com

   AD サービスチケットが正常に許可されると、その他の要求されたすべてのチケットと共に記載されたレルム間の TGT (Ticket-Granting Ticket) があります。TGT の名前は、krbtgt/IPA.DOMAIN@AD.DOMAIN です。

手順

1. UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に、DNS クエリーを実行します。

   [root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com.
   0 100 88 server.idm.example.com.
   
   [root@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com.
   0 100 389 server.idm.example.com.

   以下のコマンドは、ipa-adtrust-install を実行した IdM サーバーをリスト表示します。ipa-adtrust-install が IdM サーバーで実行していない場合、通常は最初の信頼関係を確立する前に出力が空になります。

2. TCP サービスレコード上の Kerberos と LDAP で DNS クエリーを実行して、IdM が AD のサービスレコードを解決できることを確認します。

   [root@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
   0 100 88 addc1.ad.example.com.
   
   [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
   0 100 389 addc1.ad.example.com.

手順

1. AD サーバーに、サービスレコードを検索する nslookup.exe ユーティリティーを設定します。

   C:\>nslookup.exe
   > set type=SRV

2. UDP サービスレコード上の Kerberos、および TCP サービスレコード上の LDAP に、ドメイン名を入力します。

   > _kerberos._udp.idm.example.com.
   _kerberos._udp.idm.example.com.       SRV service location:
       priority                = 0
       weight                  = 100
       port                    = 88
       svr hostname   = server.idm.example.com
   > _ldap._tcp.idm.example.com
   _ldap._tcp.idm.example.com       SRV service location:
       priority                = 0
       weight                  = 100
       port                    = 389
       svr hostname   = server.idm.example.com

3. サービスの種類を TXT に変更し、IdM Kerberos レルム名で TXT レコードに DNS クエリーを実行します。

   C:\>nslookup.exe
   > set type=TXT
   > _kerberos.idm.example.com.
   _kerberos.idm.example.com.        text =
   
       "IDM.EXAMPLE.COM"

4. UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に、DNS クエリーを実行します。

   C:\>nslookup.exe
   > set type=SRV
   > _kerberos._udp.dc._msdcs.idm.example.com.
   _kerberos._udp.dc._msdcs.idm.example.com.        SRV service location:
       priority = 0
       weight = 100
       port = 88
       svr hostname = server.idm.example.com
   > _ldap._tcp.dc._msdcs.idm.example.com.
   _ldap._tcp.dc._msdcs.idm.example.com.        SRV service location:
       priority = 0
       weight = 100
       port = 389
       svr hostname = server.idm.example.com

   Active Directory は、その他の AD ドメインコントローラーや IdM 信頼コントローラーなど、AD 固有のプロトコル要求に応答できるドメインコントローラーの検出のみを想定します。ipa-adtrust-install ツールを使用して、IdM サーバーを信頼コントローラーに昇格し、どのサーバーが信頼コントローラーであるかを確認するには、ipa server-role-find --role 'AD trust controller' コマンドを使用します。

5. AD サービスが AD サーバーで解決可能であることを検証します。

   C:\>nslookup.exe
   > set type=SRV

6. UDP サービスレコード上の Kerberos、および TCP サービスレコード上の LDAP に、ドメイン名を入力します。

   > _kerberos._udp.dc._msdcs.ad.example.com.
   _kerberos._udp.dc._msdcs.ad.example.com. 	SRV service location:
       priority = 0
       weight = 100
       port = 88
       svr hostname = addc1.ad.example.com
   > _ldap._tcp.dc._msdcs.ad.example.com.
   _ldap._tcp.dc._msdcs.ad.example.com. 	SRV service location:
       priority = 0
       weight = 100
       port = 389
       svr hostname = addc1.ad.example.com

手順

1. 既存の信頼コントローラーで、ipa-adtrust-install --add-agents コマンドを実行します。

   [root@existing_trust_controller]# ipa-adtrust-install --add-agents

   このコマンドは、対話型設定セッションを開始し、エージェントの設定に必要な情報の入力を求めます。

2. 信頼エージェントで IdM サービスを再起動します。

   [root@new_trust_agent]# ipactl restart

3. 信頼エージェントの SSSD キャッシュからすべてのエントリーを削除します。

   [root@new_trust_agent]# sssctl cache-remove

4. レプリカに AD 信頼エージェントロールがインストールされていることを確認します。

   [root@existing_trust_controller]# ipa server-show new_replica.idm.example.com
   ...
   Enabled server roles: CA server, NTP server, AD trust agent

手順

1. すべての ID 範囲を表示し、変更する AD ID 範囲を書き留めます。

   [root@server ~]# ipa idrange-find
   ----------------
   2 ranges matched
   ----------------
     Range name: IDM.EXAMPLE.COM_id_range
     First Posix ID of the range: 882200000
     Number of IDs in the range: 200000
     Range type: local domain range
   
     Range name: AD.EXAMPLE.COM_id_range
     First Posix ID of the range: 1337000000
     Number of IDs in the range: 200000
     Domain SID of the trusted domain: S-1-5-21-4123312420-990666102-3578675309
     Range type: Active Directory trust range with POSIX attributes
   ----------------------------
   Number of entries returned 2
   ----------------------------

2. ipa idrange-mod コマンドを使用して、AD ID 範囲の自動プライベートグループの動作を調整します。

   [root@server ~]# ipa idrange-mod --auto-private-groups=hybrid AD.EXAMPLE.COM_id_range

3. SSSD キャッシュをリセットして、新しい設定を有効にします。

   [root@server ~]# sss_cache -E

手順

1. ユーザー名とパスワードを使用して IdM Web UI にログインします。
2. IPA Server → ID Ranges タブを開きます。
3. AD.EXAMPLE.COM_id_range など、変更する ID 範囲を選択します。

4. Auto private groups ドロップダウンメニューから、hybrid オプションを選択します。

   

5. Save ボタンをクリックして変更を保存します。

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

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

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

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

5. 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 暗号化タイプが有効になっている。

         注記

         デフォルトでは、RHEL 9 は AD が必要とするアルゴリズムである SHA-1 暗号化を許可していません。AD-SUPPORT システム全体の暗号化サブポリシーを有効にして、AD ドメインコントローラーとの通信のために RHEL 9 サーバーで SHA-1 暗号化を許可していることを確認してください。<リンク TBA> を参照してください。

6. フォレストの信頼の場合、LSA SetInformationTrustedDomain 呼び出しでフォレスト内のドメインに推移的に到達できることを確認します。

7. 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 セクションで上記の手順を手動で実行する必要があります。

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

手順

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 -cvf debugging-trust.tar /var/log/httpd/error_log /var/log/samba/log.*

    2. Red Hat テクニカルサポートケースを開き、試行からのタイムスタンプとデバッグログを提供します。

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 サービスに接続できるようになります。

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 サービスに接続できるようになります。

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 サービスに接続できます。