IdM と AD との間の信頼のインストール

手順

1. Group Policy Management Console を開きます。
2. Default Domain Policy を右クリックし、Edit を選択します。Group Policy Management Editor が開きます。
3. Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options に移動します。
4. Network security: Configure encryption types allowed for Kerberos ポリシーをダブルクリックします。
5. AES256_HMAC_SHA1 を選択します。必要に応じて、Future encryption types を選択します。
6. OK をクリックします。
7. Group Policy Management Editor を閉じます。
8. Default Domain Controller Policy に対して手順を繰り返します。

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

   C:\> gpupdate /force /target:computer

   Copy to Clipboard Toggle word wrap

手順

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

   [root@host ~]# update-crypto-policies --set LEGACY:AD-SUPPORT-LEGACY
   Setting system policy to LEGACY: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.

   Copy to Clipboard Toggle word wrap
2. ホストを再起動します。

手順

1. 管理者権限で 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.

   Copy to Clipboard Toggle word wrap

   このコマンドにより、IdM サーバーの SRV レコードが返されます。

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

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

   Copy to Clipboard Toggle word wrap

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

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

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

     Copy to Clipboard Toggle word wrap

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

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

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

        Copy to Clipboard Toggle word wrap

        このコマンドは、関連する 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.

   Copy to Clipboard Toggle word wrap

手順

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

   Copy to Clipboard Toggle word wrap

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

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

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   デフォルトのマッピングを置き換えても、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

   Copy to Clipboard Toggle word wrap

   ホスト名は 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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

手順

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

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

   Copy to Clipboard Toggle word wrap

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

   [root@ipaserver ~]# kinit admin

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   統合 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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

7. オプション: 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

   Copy to Clipboard Toggle word wrap

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

   重要

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

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

   [root@ipaserver ~]# ipactl restart

   Copy to Clipboard Toggle word wrap

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

    [root@ipaserver ~]# smbclient -L ipaserver.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)
    ...

    Copy to Clipboard Toggle word wrap

手順

1. IdM Web UI で、IPA Server タブをクリックします。
2. IPA Server タブで、Trusts タブをクリックします。

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

   

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

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

   

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

9. オプション: デフォルトでは、信頼インストールスクリプトが適切な 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 属性が検出されない場合があります。この場合、信頼を確立するときに POSIX ID 範囲タイプを明示的に選択してください。

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

手順

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

   $ cd ~/MyPlaybooks/

   Copy to Clipboard Toggle word wrap

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
             state: present

     Copy to Clipboard Toggle word wrap

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

     • 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

     Copy to Clipboard Toggle word wrap

   • フォレストルートドメインの 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

     Copy to Clipboard Toggle word wrap
   警告

   信頼の作成時に 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 属性が検出されない場合があります。この場合、信頼を確立するときに POSIX ID 範囲タイプを明示的に選択してください。

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

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

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

   Copy to Clipboard Toggle word wrap

手順

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

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   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.

   Copy to Clipboard Toggle word wrap

   以下のコマンドは、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.

   Copy to Clipboard Toggle word wrap

手順

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

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

手順

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

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

   Copy to Clipboard Toggle word wrap

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

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

   [root@new_trust_agent]# ipactl restart

   Copy to Clipboard Toggle word wrap

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

   [root@new_trust_agent]# sssctl cache-remove

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

手順

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
   ----------------------------

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   [root@server ~]# sss_cache -E

   Copy to Clipboard Toggle word wrap

手順

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 範囲の種類とプロパティーを ipa trust-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 ベースの暗号化で接続が十分に保護されていることを保証するために、少なくとも Windows Server 2012 以降での 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 IdM サーバーで 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 namespace の競合。この競合は解決できません。
   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

   Copy to Clipboard Toggle word wrap

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

   [root@trust_controller ~]# systemctl restart httpd

   Copy to Clipboard Toggle word wrap

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

   [root@trust_controller ~]# systemctl stop smb winbind

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

       [global]
       log level = 100

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   [root@trust_controller ~]# systemctl start smb winbind

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

    Copy to Clipboard Toggle word wrap

11. オプション: 認証の問題の原因を特定できない場合は、次の手順を実行します。

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

       [root@trust_controller ~]# tar -cvf debugging-trust.tar /var/log/httpd/error_log /var/log/samba/log.*

       Copy to Clipboard Toggle word wrap
    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 サービスに接続できます。