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 によく発生するレプリカの問題について説明します。
その他のリソース:
  • Red Hat Directory Server でのレプリカ問題に関する説明については、『Directory Server 『Administration Guide』』の 「Solving Common Replication Conflicts」 セクションを参照してください。
  • レプリケーションが機能しているかどうかをテストする方法については、「新規レプリカのテスト」 を参照してください。
  • Directory Server repl-monitor スクリプトはレプリケーションの進捗状況を表示するので、レプリカ問題のトラブルシューティングに役立ちます。このスクリプトについての詳細情報は、『Directory Server 『Administration Guide』』の 「repl-monitor (Monitors Replication Status)」 セクションを参照してください。

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

Identity Management-Active Directory 信頼設定で新規レプリカをインストールした後、Active Directory (AD) ユーザーを IdM レプリカに対して認証しようとすると失敗します。

エラー内容:

レプリカは信頼コントローラーや信頼エージェントではないため、AD 信頼空の情報を処理できません。

解決方法:

レプリカを信頼エージェントとして設定します。詳細は、『『Windows Integration Guide』』の Trust Controllers and Trust Agents を参照してください。

B.2.2. レプリカを起動すると Directory Server ログに SASL、GSS-API、および Kerberos などのエラーが発生する問題

レプリカが起動すると、認証情報のキャッシュが見つからなかったため GSS-API 接続に失敗したことを示す一連の SASL bind エラーが Directory Server ログに記録されます。 
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 プロセスが終了すると、認証情報キャッシュが破棄されます。
レプリカが再起動すると、DS は KDC サーバーが起動する前に起動します。この起動順序のために、DS が起動しても Kerberos 認証情報は認証情報キャッシュに保存されておらず、これが理由でエラーが発生します。
最初の失敗の後、DS は KDC の起動後に GSS-API 接続を再試行します。この再試行は成功し、レプリカは想定通りに機能します。
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

エラー内容:

1 つの 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 つのレプリカ間の証明書サーバー複製を有効にします。command. See 「複製合意の作成と削除」 を参照してください。
  2. 一方のレプリカをもう一方のレプリカから再度初期化して、同期します。「レプリカの再初期化」 を参照してください。

    警告

    再初期化を行ったレプリカのデータは、もう一方のレプリカのデータで上書きされ、情報が失われる可能性があります。

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 を見つけるには、トポロジー内の全ノードに対して以下の 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. 失われた CA サーバーの復旧

注記

このソリューションは、ドメインレベル 0 に適用可能です。詳細は7章ドメインレベルの表示と引き上げを参照してください。
CA が 1 つのサーバーにしかインストールされていない状態で、このサーバーが失敗して失われてしまいました。

エラー内容:

IdM ドメインの CA 設定が利用できません。

解決方法:

オリジナルの CA サーバーのバックアップがある場合は、サーバーを復旧してレプリカに CA をインストールすることが可能です。
  1. CA サーバーをバックアップから復旧します。詳細は 「バックアップの復元」 を参照してください。
    これで CA サーバーがレプリカで利用可能になります。
  2. 元のサーバーとレプリカ間の複製合意を削除して、複製の競合を防ぎます。詳細は 「複製合意の作成と削除」 を参照してください。
  3. CA をレプリカにインストールします。「レプリカのマスター CA サーバーへのプロモート」 を参照してください。
  4. オリジナルの CA サーバーの使用を停止します。詳細は 「レプリカの削除」 を参照してください。
元の CA サーバーのバックアップがない場合は、サーバーが失敗すると CA 設定は失われ、復旧できなくなります。