5.9. Identity Management

IdM デプロイメントの移行では、HBAC ルールが重複しなくなりました。

ipa-migrate ユーティリティーを使用して 1 つの Identity Management (IdM) デプロイメントから別のデプロイメントに移行すると、移行先サーバーでホストベースのアクセス制御 (HBAC) ルールが重複することがありました。その結果、そのサーバーで "ipa hbacrule-find" コマンドを実行すると、"allow_all" および "allow_systemd-user" HBAC ルールが 2 回表示されました。

期限切れのトークンを使用した 2 要素認証の回避ができなくなる

以前は、特定の有効期限を持つ OTP トークンを作成することで、2 要素認証を回避できました。

サブ接尾辞を持つインスタンスを起動するときに、誤ったエラーが記録されなくなる

この更新前は、サブ接尾辞を持つインスタンスを起動すると、エラーログに次の誤ったメッセージが表示されることがありました。

ldapsearch が NETWORK_TIMEOUT 設定を期待通りに考慮するようになる

以前は、サーバーに到達できない場合、ldapsearch コマンドはタイムアウトを無視し、その結果、検索はタイムアウトになる代わりに無期限にハングしていました。この更新では、接続再試行とソケットオプションを調整することで、TLS 処理のロジックエラーが修正されました。

ページ結果検索における競合状態が解消され、T3 エラーコードによって接続が切断されなくなる

以前は、Directory Server は、タイムアウトイベントの接続のページ結果データをチェックするときに適切なスレッド保護を使用していませんでした。その結果、新たな操作が到着した際に、ページ結果のタイムアウト値が予期せず変更され、誤ったタイムアウトが発生してしまいました。これによりタイムアウトエラーが発生し、次の T3 エラーコードで接続が閉じられました。

拡張マッチングルールでインデックスされたソート属性を持つ VLV インデックスの再インデックス時に、Directory Server が失敗しなくなる

この更新前は、拡張一致ルールでインデックスされたソート属性を持つ仮想リストビュー (VLV) インデックスの再インデックス中に競合状態が発生していました。その結果、メモリーがリークされ、Directory Server は失敗しました。この更新により、Directory Server は VLV インデックスキーの生成をシリアライズし、失敗しなくなりました。

OpenLDAP ライブラリーは、リソースを解放しようとしても失敗しなくなる

この更新前は、OpenLDAP ライブラリーは、アプリケーションが直接または atexit() 関数経由で OPENSSL_cleanup() 関数を呼び出してこれらのリソースをすでにクリーンアップしているときに、デストラクターで SSL_CTX_free() 関数を使用してメモリーを解放しようとしていました。その結果、無効な SSL_CTX_free() 呼び出しによって、すでにクリーンアップされた SSL コンテキストリソースが解放されようとしたときに、ユーザーは障害や未定義の動作を経験しました。

高い接続負荷によって Directory Server の単一スレッドが過負荷にならなくなる

この更新前は、Directory Server が複数のリスニングスレッドをサポートしていても、最初の着信接続が同じリスナースレッドに割り当てられ、過負荷になっていました。その結果、一部のリクエストで wtime が長くなり、パフォーマンスが低下しました。この更新により、Directory Server は接続の負荷をすべてのリスニングスレッドに分散します。

LMDB 使用時に、VLV インデックスキャッシュが VLV インデックスと期待どおりに一致するようになる

この更新前は、仮想リストビュー (VLV) インデックスキャッシュが Lightning Memory-Mapped Database (LMDB) が割り当てられたインスタンスの VLV インデックス自体と一致していなかったため、VLV インデックスが無効値を返していました。この更新により、VLV インデックスキャッシュが VLV インデックスと一致し、正しい値が返されるようになりました。

オンラインバックアップが失敗しなくなる

この更新前は、ロックの順番が正しくないため、オンラインバックアップタスクが散発的にハングする可能性がありました。この更新により、オンラインバックアップは期待どおりに機能し、失敗しなくなりました。

cleanAllRUV が自身をブロックしなくなる

この更新前は、レプリケーショントポロジーからレプリカを削除した後に cleanAllRUV タスクを実行すると、同じタスクが古いレプリカ ID (rid) のレプリケーション changelog を消去しながら、レプリケーション設定エントリーを更新しようとしていました。その結果、サーバーは応答していませんでした。

エントリー RDN が接尾辞 DN と同じ値を持つ場合、再インデックス化が失敗しなくなる

この更新前は、エントリーの相対識別名 (RDN) がディレクトリー内の接尾辞識別名 (DN) と同じ値を持つ場合、entryrdn インデックスが壊れていました。その結果、Directory Server が遅い検索リクエストを実行したり、無効な結果を返したり、エラーログに警告メッセージを書き込んだりする可能性がありました。

Account Policy プラグインが、レプリケーショントポロジーの更新に適切なフラグを使用するようになる

この更新前は、Account Policy プラグインは更新に適切なフラグを使用していませんでした。その結果、レプリケーショントポロジーでは、Account Policy プラグインがログイン履歴を更新しましたが、この更新はコンシューマーサーバー上で失敗し、次のエラーメッセージが記録されました。

LMDB を使用するサプライヤーにおいて、オフラインインポート時に nsuniqueid の重複が生成されなくなる

この更新前は、Lightning Memory-Mapped Database (LMDB) を使用するサプライヤーで、レプリケーションされていない基本エントリーをオフラインインポートすると、一意である必要がある運用属性 nsuniqueid の重複が生成されることがありました。その結果、レプリケーションの問題が発生していました。この更新により、オフラインインポートでサプライヤーに重複が生成されなくなりました。

TLS 1.3 を使用して、FIPS モードで実行されている LDAP サーバーに接続できるようになる

この更新前は、FIPS モードで LDAP サーバーに接続するときに TLS 1.3 を明示的に設定しようとすると、使用される TLS バージョンは 1.2 のままでした。その結果、TLS 1.3 を使用して LDAP サーバーに接続しようとしても失敗しました。この更新により、FIPS モードにおける TLS バージョンの上限が 1.3 に変更され、TLS 1.3 を使用した LDAP サーバーへの接続試行が失敗しなくなりました。

以前のバックアップが失敗していた場合でも、Directory Server のバックアップが正常に実行されるようになる

この更新前は、最初のバックアップ試行が失敗した場合、バックエンドが以前のバックアップを完了しようとしてビジー状態になっていたため、次の Directory Server のバックアップに失敗していました。その結果、インスタンスの再起動が必要でした。この更新により、以前の試行に失敗した後に Directory Server のバックアップが失敗しなくなり、インスタンスの再起動が不要になりました。

証明書ベースの認証を使用しているときにサプライヤー間のレプリケーションが失敗した場合に、よりわかりやすいエラーメッセージが表示されるようになる

この更新前は、サプライヤー間のレプリケーション中に必要な CA 証明書ファイルが欠落していて TLS 接続の確立に失敗した場合でも、問題を特定できるような明確なエラーメッセージが表示されませんでした。この更新により、TLS セットアップエラーが発生した場合、Directory Server はより詳細なエラー情報をログに記録します。証明書が見つからない場合には、No such file or directory といったメッセージが表示されるようになり、問題の解決が容易になりました。

dsconf config replace コマンドが複数値属性を期待どおりに正しく扱えるようになる

この更新前は、dsconf config replace コマンドは、nsslapd-haproxy-trusted-ip などの属性に対して 1 つの値しか設定できませんでした。このリリースでは、次のコマンドを使用して複数の値を設定できます。

OR (|) および NOT (!) 演算子を含む複合フィルターを使用した場合に、Directory Server が正しいエントリーセットを返すようになる

この更新前は、OR (|) および NOT (!) 演算子を使用した LDAP 検索では、Directory Server は正しいエントリーセットを返しませんでした。その理由は、Directory Server がアクセス権とエントリーの一致を誤って評価し、これらの手順を 1 つのフェーズで実行したためです。この更新により、Directory Server はアクセス権の評価とエントリーの一致判定を 2 つのフェーズに分けて実行するようになり、OR (|) および NOT (!) 演算子を含む複合フィルターを使用した検索でも、正しいエントリーの集合が返されるようになりました。

Directory Server の再起動後に、サプライヤーのレプリカ合意にコンシューマーのステータスが正しく表示される

この更新前は、レプリケーショントポロジーのサプライヤーで、Directory Server の再起動時にレプリケーション合意のコンシューマーのステータスがリセットされていました。その結果、表示されるコンシューマーの初期化日時およびレプリケーションのステータスが正しくありませんでした。