3.14. Identity Management
IdM ID 範囲の不一致を管理するための新しいツール
この更新により、Identity Management (IdM) が ipa-idrange-fix
ツールを提供します。ipa-idrange-fix
ツールを使用して、既存の IdM ID 範囲を分析し、これらの範囲外のユーザーとグループを識別して、それらを含める新しい ipa-local
範囲の作成を提案できます。
ipa-idrange-fix
ツールは次の処理を実行します。
- LDAP から既存の範囲を読み取って分析します。
-
ipa-local
範囲外のユーザーとグループを検索します。 -
特定されたユーザーとグループをカバーするために、新しい
ipa-local
範囲を提案します。 - 提案された変更を適用するようユーザーに促します。
このツールは、システムアカウントとの競合を防ぐために、1000 未満の ID をデフォルトで除外します。Red Hat では、提案された変更を適用する前に、完全なシステムバックアップを作成することを強く推奨します。
詳細は、ipa-idrange-fix(1)
man ページを参照してください。
Kerberos が Elliptic Curve Diffie-Hellman 鍵合意アルゴリズムをサポートするようになる
RFC5349 で定義されている PKINIT の Elliptic Curve Diffie-Hellman (ECDH) 鍵合意アルゴリズムがサポートされるようになりました。この更新により、krb5.conf ファイルの pkinit_dh_min_bits
設定で、デフォルトで ECDH を使用するように P-256
、P-384
、または P-521
を指定できるようになりました。
ansible-freeipa
が 1.14.5 にリベース
ansible-freeipa
パッケージが、バージョン 1.13.2 から 1.14.5 にリベースされました。以下は、主な機能拡張およびバグ修正です。
module_defaults
を使用して、複数のansible-freeipa
タスクの変数を定義できます。freeipa.ansible_freeipa
コレクションは、ansible-freeipa
モジュールの使用を簡素化するmodule_defaults
アクショングループを提供するようになりました。module_defaults
を使用すると、Playbook で使用されるコレクションのすべてのモジュールに適用するデフォルト値を設定できます。これを行うには、freeipa.ansible_freeipa.modules
という名前のaction_group
を使用します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow その結果、Playbook はより簡潔になります。
複数の IdM
sudo
ルールを単一の Ansible タスクで管理できるようになりましたこの機能拡張により、
ansible-freeipa
にsudorules
オプションが追加されます。sudorules
を使用すると、単一の Ansible タスクを使用して複数の Identity Management (IdM)sudo
ルールを追加、変更、および削除できます。これを行うには、ipasudorule
モジュールのsudorules
オプションを使用します。その結果、sudo
ルールをより簡単に定義し、より効率的に実行できるようになります。sudorules
オプションを使用すると、特定のsudo
ルールに適用される複数のsudo
ルールパラメーターを指定できます。このsudo
ルールはname
変数によって定義されます。これは、sudorules
オプションの唯一の必須変数です。ipagroup
モジュールを使用した外部メンバーの削除が正しく動作するようになりました。以前は、
externalmember
パラメーターを指定したansible-freeipa
ipagroup
モジュールを使用して、IdM グループに外部メンバーが存在しないことを確認しようとした場合、Ansible がタスクの結果をchanged
として表示したにもかかわらず、グループからメンバーが削除されませんでした。この修正により、externalmember
をipagroup
と併用すると、IdM グループに外部メンバーが確実に存在しなくなります。また、この修正により、AD ユーザーを識別するために DOM\name または name@domain のいずれかを使用することもできます。
389-ds-base
がバージョン 2.6.1 にリベース
389-ds-base
パッケージがバージョン 2.6.1 にリベースされました。バージョン 2.5.2 への主なバグ修正および機能拡張は、以下のとおりです。
- エラーログのログバッファリング
- 監査ログを JSON 形式で書き込むオプション
- グループが更新されたときにグループメンバーの更新を延期するオプション
- PBKDF2 のイテレーション回数を設定するオプション
-
logconv.py
ログアナライザーツール
openldap
がバージョン 2.6.8 にリベース
openldap
パッケージがバージョン 2.6.8 に更新されました。この更新には、次のようなさまざまな機能拡張とバグ修正が含まれています。
- TLS 接続の処理が改善されました。
-
Active Directory 証明書が Elliptic Curve Cryptography (ECC) 証明書であり、
SASL_CBINDING
がtls-endpoint
に設定されている場合でも、KerberosSASL
はSTARTTLS
で動作します。
Directory Server で新しい memberOfDeferredUpdate: on/off
設定属性が利用できるようになる
この更新により、Directory Server は MemberOf plug-in の新しい memberOfDeferredUpdate
設定属性を導入します。on
に設定すると、MemberOf plug-in はグループメンバーの更新を遅延させるため、特にグループの変更が多数のメンバーに影響する場合に、サーバーの応答性が向上します。
詳細は、Red Hat Directory Server 12 の「設定およびスキーマリファレンス」ドキュメントの memberOfDeferredUpdate を参照してください。
Directory Server が、エラー、監査、監査失敗のログのバッファリングを提供するようになる
この更新前は、アクセスログとセキュリティーログにのみログバッファリングがありました。この更新により、Directory Server はエラー、監査、監査失敗のログのバッファリングを提供するようになりました。ログバッファリングを設定するには、次の設定を使用します。
-
エラーログの
nsslapd-errorlog-logbuffering
。デフォルトでは無効になっています。 -
監査および監査失敗ログ用の
nsslapd-auditlog-logbuffering
。デフォルトでは有効です。
詳細は、Red Hat Directory Server の「設定およびスキーマリファレンス」ドキュメントの nsslapd-errorlog-logbuffering および nsslapd-auditlog-logbuffering を参照してください。
Directory Server が、バインドが成功した後、CRYPT または CLEAR ハッシュアルゴリズムでパスワードを更新できるようになる
この更新前は、Directory Server に、バインド成功時のパスワード更新から除外されるハッシュ化アルゴリズムのリストがハードコードされていました。Directory Server は、passwordStorageScheme
属性で設定された CRYPT または CLEAR ハッシュアルゴリズムを持つユーザーパスワードを更新しませんでした。
この更新により、nsslapd-scheme-list-no-upgrade-hash
設定属性を使用して、パスワード更新から除外する必要のあるハッシュアルゴリズムのリストを設定できるようになりました。デフォルトでは、nsslapd-scheme-list-no-upgrade-hash
には後方互換性のための CRYPT および CLEAR が含まれます。
HSM は IdM で完全にサポートされるようになる
Hardware Security Modules (HSM) が、Identity Management (IdM) で完全にサポートされるようになりました。IdM 認証局 (CA) および Key Recovery Authority (KRA) のキーペアと証明書を HSM に保存できます。これにより、秘密鍵マテリアルに物理的なセキュリティーが追加されます。
IdM は、HSM のネットワーク機能を利用してマシン間で鍵を共有し、レプリカを作成します。HSM は、ほとんどの IdM 操作に目に見える影響を与えることなく、追加のセキュリティーを提供します。低レベルのツールを使用する場合、証明書と鍵の扱い方が異なりますが、ほとんどのユーザーにとってこの違いはシームレスです。
既存の CA または KRA を HSM ベースのセットアップに移行することはサポートされていません。HSM 上のキーを使用して CA または KRA を再インストールする必要があります。
以下が必要です。
- サポートされている HSM。
- HSM Public-Key Cryptography Standard (PKCS) #11 ライブラリー。
- 利用可能なスロット、トークン、トークンのパスワード。
HSM にキーが保存されている CA または KRA をインストールするには、トークン名と PKCS #11 ライブラリーへのパスを指定する必要があります。以下に例を示します。
ipa-server-install -r EXAMPLE.TEST -U --setup-dns --allow-zone-overlap --no-forwarders -N --auto-reverse --random-serial-numbers -–token-name=HSM-TOKEN --token-library-path=/opt/nfast/toolkits/pkcs11/libcknfast.so --setup-kra
ipa-server-install -r EXAMPLE.TEST -U --setup-dns --allow-zone-overlap --no-forwarders -N --auto-reverse --random-serial-numbers -–token-name=HSM-TOKEN --token-library-path=/opt/nfast/toolkits/pkcs11/libcknfast.so --setup-kra
Jira:RHELDOCS-17465[1]