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 Integration Guide』のTrust Controllers and Trust Agentsを参照してください。

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 認証情報が認証情報キャッシュに保存されません。これがエラーの原因になります。
初期障害の後、DS は、KDC の起動後に GSS-API 接続の確立を再試行します。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

エラー内容:

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. レプリカには証明書のレプリケーション合意が確立されていないため、証明書はレプリカ B にレプリケートされません。
  3. ユーザーがレプリカ B を使用してホストを管理しようとします。
  4. レプリカ B は、ホストの証明書のシリアル番号を検証できないというエラーを返します。これは、レプリカ B のデータディレクトリーにホストに関する情報がありますが、証明書ディレクトリーにホスト証明書がないためです。

解決方法:

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

B.2.5. Replica Update Vector (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 台しかインストールされていませんでした。このサーバーに障害が発生して、CA サーバーがなくなってしまいました。

エラー内容:

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

解決方法:

使用可能な元の CA サーバーのバックアップがある場合は、サーバーを復元して、レプリカに CA をインストールできます。
  1. バックアップから CA サーバーを復元します。詳細は「バックアップの復元」を参照してください。
    これにより、CA サーバーがレプリカで使用できるようになります。
  2. レプリカの競合を回避するため、初期サーバーとレプリカとの間のレプリカ合意を削除します。「レプリカ合意の作成と削除」を参照してください。
  3. レプリカに CA をインストールします。「レプリカのマスター CA サーバーへのプロモート」を参照してください。
  4. 元の CA サーバーを停止します。「レプリカの削除」を参照してください。
元の CA サーバーのバックアップがないと、サーバーに障害が発生したときに CA 設定が失われ、復旧できません。