Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

B.2. Identity Management レプリカ

本ガイドでは、Red Hat Enterprise Linux における Identity Management に関する一般的なレプリケーション問題を説明します。
関連情報

B.2.1. 新しいレプリカで AD ユーザーの認証に失敗する

Identity Management（Active Directory 信頼設定）に新しいレプリカをインストールした後、IdM レプリカに対する Active Directory(AD)ユーザーの認証に失敗します。

エラー内容：

レプリカは、信頼コントローラーも信頼エージェントも ありません。このため、AD 信頼からの情報を提供できません。

問題を解決するには、以下を実行します。

レプリカを信頼エージェントとして設定します。『Windows 『統合ガイド』の「信頼コントローラーおよび信頼エージェント』 」を参照してください。

B.2.2. Directory Server ログの SASL、GSS-API、および Kerberos エラーからレプリカの開始

レプリカが起動すると、一連の SASL バインドエラーが Directory Server(DS)ログに記録されます。クレデンシャルキャッシュが見つからないため、GSS-API 接続が失敗していることを示すエラー。 
slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ...
さらに、サーバーがホストプリンシパルの Kerberos 認証情報を取得できなかったことを示す他のメッセージが発生する可能性があります。 
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)

エラー内容：

IdM は、Kerberos 接続に GSS-API を使用します。DS インスタンスは、Kerberos 認証情報キャッシュをメモリーに保持します。IdM レプリカが停止したときになど、DS プロセスが終了すると、認証情報キャッシュが破棄されます。
レプリカが再起動すると、KDC サーバーを起動する前に DS が起動します。この開始順序により、DS の起動時に Kerberos 認証情報は認証情報キャッシュに保存されていません。これがエラーの原因になります。
最初の失敗後に、KDC の起動後に GSS-API 接続を確立するために DS re-attempts 接続を確立します。2 回目の試行に成功し、レプリカが想定どおりに機能することを確認します。
GSS-API 接続が正常に確立され、レプリカが予想通りに機能している限り、記述された起動エラーを無視できます。以下のメッセージは、接続が成功したことを示しています。 
Replication bind with GSSAPI auth resumed

B.2.3. DNS 正引きレコードは逆アドレスと一致しません

新しいレプリカを設定すると、一連の証明書エラーが発生してインストールが失敗し、DNS 転送レコードが逆引きアドレスと一致しない DNS エラーが続きます。 
ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer
ipa: DEBUG: cert valid True for "CN=replica.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = 192.0.2.2:9444
Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)

...

ipa: DEBUG: Created connection context.ldap2_21534032
ipa: DEBUG: Destroyed connection context.ldap2_21534032
The DNS forward record replica.example.com. does not match the reverse address replica.example.org

エラー内容：

複数のホスト名が単一の PTR レコードに使用されます。DNS 標準はこのような設定を許可しますが、IdM レプリカのインストールに失敗します。

問題を解決するには、以下を実行します。

の説明に従って、DNS 「正引きおよび逆引き DNS 設定の確認」。

B.2.4. シリアル番号が検出されないエラー

注記
このソリューションは、ドメインレベル 0 に適用できます。詳しくは 7章ドメインレベルの表示と評価、を参照してください。
証明書のシリアル番号が見つからないことを示すエラーが表示されます。 
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)

エラー内容：

2 つのレプリカ間の証明書レプリカ合意が削除されましたが、データのレプリカ合意は引き続き設定されています。両方のレプリカは引き続き証明書を発行するままになりますが、証明書に関する情報は複製されなくなりました。
状況例：
  1. レプリカ A がホストに証明書を発行します。
  2. レプリカ A とレプリカ B の間には証明書複製合意がないため、この証明書はレプリカ B に複製されません。
  3. ユーザー は、レプリカ B を使用してホストの管理を試行します。
  4. レプリカ B は、ホストの証明書のシリアル番号を検証できないエラーを返します。これは、レプリカ B にデータディレクトリーにホストに関する情報がありますが、証明書ディレクトリーにホスト証明書がないためです。

問題を解決するには、以下を実行します。

  1. ipa-csreplica-manage connect コマンドを使用して、2 つのレプリカ間で証明書サーバーのレプリケーションを有効にします。「レプリカ合意の作成と削除」。
  2. レプリカの 1 つを再初期化して、それを同期します。を参照してください 「レプリカの再初期化」。
    警告
    再初期化により、再初期化されたレプリカのデータが、他のレプリカからのデータで上書きされます。一部の情報は失われる可能性があります。

B.2.5. レプリカ更新ベクトル(RUV)エラーのクリーニング

注記
このソリューションは、ドメインレベル 0 に適用できます。詳しくは 7章ドメインレベルの表示と評価、を参照してください。
IdM トポロジーからレプリカが削除されると、廃止された RUV レコードが 1 つ以上のレプリカに表示されるようになりました。
考えられる原因：

エラー内容：

他のレプリカは、削除されたレプリカから更新を受け取ることが予想されます。
注記
レプリカを削除する正しい手順は、「レプリカの削除」。

問題を解決するには、以下を実行します。

更新を受け取る必要のあるレプリカで RUV レコードを削除します。
  1. ipa-replica-manage list-ruv コマンドを使用して、以前の RUV の詳細を表示します。このコマンドは、レプリカ ID を表示します。 
    # ipa-replica-manage list-ruv
server1.example.com:389: 6
server2.example.com:389: 5
server3.example.com:389: 4
server4.example.com:389: 12
  2. ipa-replica-manage clean-ruv replica_ID コマンドを使用して、破損した RUV を消去します。このコマンドは、指定したレプリカに関連付けられた RUV を削除します。
    廃止された RUV のあるすべてのレプリカについてコマンドを繰り返します。以下に例を示します。 
    # ipa-replica-manage clean-ruv 6
# ipa-replica-manage clean-ruv 5
# ipa-replica-manage clean-ruv 4
# ipa-replica-manage clean-ruv 12
    警告
    ipa-replica-manage clean-ruv を使用する場合は、細心の注意を払ってください。有効なレプリカ ID に対してコマンドを実行すると、レプリケーションデータベースでそのレプリカに関連するすべてのデータが破損します。
    「レプリカの再初期化」。
  3. ipa-replica-manage list-ruv を再度実行します。
    • コマンドで破損した RUV が表示されなくなった場合には、レコードが正常に消去されています。
    • 引き続き破損した RUV が表示される場合には、このタスクを使用して手動で消去します。 
      dn: cn=clean replica_ID, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: replica_ID
replica-force-cleaning: no
cn: clean replica_ID
RUV をクリーンアップするレプリカが分からない場合は、次のコマンドを実行します。
  1. すべてのサーバーでアクティブなレプリカ ID を検索します。関連していないレプリカ ID のリストと信頼できるレプリカ ID のリストを作成します。
    有効なレプリカの ID を見つけるには、トポロジー内のすべてのノードに対してこの LDAP クエリーを実行します。 
    # ldapsearch -p 389 -h IdM_node -D "cn=directory manager" -W -b "cn=config" "(objectclass=nsds5replica)" nsDS5ReplicaId
  2. すべてのサーバーで ipa-replica-manage list-ruv を実行します。関連付けられていないレプリカ ID の一覧にないレプリカ ID をメモします。
  3. 破損したレプリカ ID ごとに ipa-replica-manage clean-ruv replica_ID を実行します。

B.2.6. ラost CA サーバーの復旧

注記
このソリューションは、ドメインレベル 0 に適用できます。詳しくは 7章ドメインレベルの表示と評価、を参照してください。
CA がインストールされているサーバーは 1 台しかありません。このサーバーが失敗し、失われました。

エラー内容：

IdM ドメインの CA 設定は利用できなくなりました。

問題を解決するには、以下を実行します。

元の CA サーバーのバックアップがある場合は、サーバーを復元し、CA をレプリカにインストールできます。
  1. CA サーバーをバックアップから復元します。詳しくは 「バックアップの復元」、を参照してください。
    これにより、CA サーバーがレプリカで利用できるようになります。
  2. 初期サーバーとレプリカ間のレプリカ合意を削除し、レプリケーションの競合を回避します。を参照してください 「レプリカ合意の作成と削除」。
  3. CA をレプリカにインストールします。を参照してください 「マスター CA サーバーへのレプリカのプロモート」。
  4. 元の CA サーバーの使用を停止します。を参照してください 「レプリカの削除」。
元の CA サーバーのバックアップがない場合、サーバーが失敗し、回復できない場合に CA 設定が失われていました。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。