5.7.9. ID 管理
すべての KRA メンバーが非表示レプリカの場合は、KRA のインストールに失敗します。
最初の KRA インスタンスが非表示レプリカにインストールされている場合、Key Recovery Authority (KRA) がすでに存在するクラスターでは ipa-kra-install ユーティリティーで問題が発生します。そのため、これ以上、追加の KRA インスタンスをクラスターに追加することはできません。
この問題を回避するには、新しい KRA インスタンスを追加する前に、KRA ロールが割り当てられた非表示レプリカを解除します。Ipa-kra-install が正常に終了してから、レプリカを再度非表示にできます。
--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムが破損します。
--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムの LDAP 設定が破損します。したがって、証明書システムは不安定になり、システムの復元に手動の操作が必要になる可能性があります。
PKI CA に接続する PKI ACME Responder が発行する証明書により、OCSP の検証が失敗する可能性があります。
PKI CA が提供するデフォルトの ACME 証明書プロファイルには、実際の OCSP サービスを参照しないサンプル OCSP URL が含まれています。これにより、PKI ACME Responder が PKI CA 発行者を使用するように設定されている場合、レスポンダーが発行する証明書は OCSP 検証に失敗する可能性があります。
この問題を回避するには、/usr/share/pki/ca/profiles/ca/acmeServerCert.cfg 設定ファイルの policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0 プロパティーを空の値に設定する必要があります。
-
ACME Responder 設定ファイルで
policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ocsp.example.comをpolicyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=に変更します。 - サービスを再起動して、証明書を再生成します。
これにより、PKI CA は、実際の OCSP サービスを参照する自動生成 OCSP URL で ACME 証明書を生成します。
FreeRADIUS が 249 文字を超える Tunnel-Passwords を断りなく切り捨てます。
Tunnel-Password が 249 文字を超える場合、FreeRADIUS サービスはそのパスワードを断りなく切り捨てます。これにより、他のシステムと矛盾する想定外のパスワードになる可能性があります。
この問題を回避するには、249 文字以下のパスワードを選択します。
IdM ホストの /var/log/lastlog 分析ファイルが、パフォーマンスの問題を引き起こす可能性があります。
IdM のインストール時に、利用できる合計 10,000 の範囲からの 200,000 の UID の範囲が無作為に選択され、割り当てられます。このようにランダムな範囲を選択すると、今後別の 2 つの IdM ドメインを統合する場合に、ID の競合が発生する可能性を大幅に削減できます。
ただし、UID が多いと、/var/log/lastlog ファイルで問題が発生する可能性があります。たとえば、1280000008 の UID を持つユーザーが IdM クライアントにログインすると、ローカルの /var/log/lastlog ファイルサイズは、約 400 GB に増えます。実際のファイルはスパースで、その領域をすべて使用しません。ただし、一部のアプリケーションはデフォルトではスパースファイルを識別するように設計されています。そのため、それらを処理する特定のオプションが必要になる場合があります。たとえば、設定が複雑でバックアップ、コピーアプリケーションがスパースファイルを正しく処理しない場合、ファイルはサイズが 400 GB であるかのようにコピーされます。この動作により、パフォーマンスの問題が発生する可能性があります。
この問題を回避するには、以下を実行します。
- 標準パッケージの場合は、そのドキュメントを参照して、スパースファイルを処理するオプションを特定します。
-
カスタムアプリケーションの場合、
/var/log/lastlogなどのスパースファイルを正しく管理できることを確認してください。
(JIRA:RHELPLAN-59111)
ldap_id_use_start_tls オプションのデフォルト値を使用する場合の潜在的なリスク
ID ルックアップに TLS を使用せずに ldap:// を使用すると、攻撃ベクトルのリスクが生じる可能性があります。特に、中間者 (MITM) 攻撃は、攻撃者が、たとえば、LDAP 検索で返されたオブジェクトの UID または GID を変更することによってユーザーになりすますことを可能にする可能性があります。
現在、TLS を強制する SSSD 設定オプション ldap_id_use_start_tls は、デフォルトで false に設定されています。セットアップが信頼できる環境で動作していることを確認し、id_provider = ldap に暗号化されていない通信を使用しても安全かどうかを判断してください。注記: id_provider = ad および id_provider = ipa は、SASL および GSSAPI によって保護された暗号化接続を使用するため、影響を受けません。
暗号化されていない通信を使用することが安全ではない場合は、/etc/sssd/sssd.conf ファイルで ldap_id_use_start_tls オプションを true に設定して TLS を強制します。デフォルトの動作は、RHEL の将来のリリースで変更される予定です。
(JIRA:RHELPLAN-155168)
グループのサイズが 1500 人を超えると、SSSD が取得するメンバーリストが不完全なものになる
SSSD と Active Directory の統合時に、グループサイズが 1500 メンバーを超えると、SSSD が取得するメンバーリストが不完全なものになります。この問題は、1 回のクエリーで取得できるメンバーの数を制限する Active Directory の MaxValRange ポリシーが、デフォルトで 1500 に設定されているために発生します。
この問題を回避するには、Active Directory の MaxValRange 設定を変更して、より大きなグループサイズに対応できるようにします。
(JIRA:RHELDOCS-19603)