11.12. Identity Management
--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムが破損します。
--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムの LDAP 設定が破損します。したがって、証明書システムは不安定になり、システムの復元に手動の操作が必要になる可能性があります。
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)
FIPS モードは、共有シークレットを使用したフォレスト間の信頼を確立することをサポートしません。
NTLMSSP 認証は FIPS に準拠していないため、FIPS モードでフォレスト間の信頼を確立できません。この問題を回避するには、FIPS モードが有効な IdM ドメインと AD ドメインとの間に信頼を確立する際に、Active Directory (AD) 管理アカウントで認証します。
FreeRADIUS サーバーが FIPS モードでの実行に失敗する
デフォルトでは、FIPS モードでは、OpenSSL は MD5 ダイジェストアルゴリズムの使用を無効にします。RADIUS プロトコルでは、RADIUS クライアントと RADIUS サーバー間のシークレットを暗号化するために MD5 が必要であるため、FreeRADIUS サーバーが FIPS モードで失敗します。
この問題を回避するには、以下の手順に従います。
手順
radiusdサービスの環境変数RADIUS_MD5_FIPS_OVERRIDEを作成します。systemctl edit radiusd [Service] Environment=RADIUS_MD5_FIPS_OVERRIDE=1
変更を適用するには、
systemd設定を再読み込みし、radiusdサービスを開始します。# systemctl daemon-reload # systemctl start radiusd
デバッグモードで FreeRADIUS を実行するには、以下を実行します。
# RADIUS_MD5_FIPS_OVERRIDE=1 radiusd -X
FreeRADIUS は FIPS モードで実行できますが、FIPS モードでは弱い暗号と関数が使用されるため、これは FIPS に準拠するわけではありません。
FIPS モードでの FreeRADIUS 認証の設定方法は、FIPS モードで FreeRADIUS 認証を設定する方法 を参照してください。
IdM から AD へのレルム間の TGS 要求が失敗します
IdM Kerberos チケットの 特権属性証明書 (PAC) 情報は、Active Directory (AD) でサポートされていない AES SHA-2 HMAC 暗号化で署名されるようになりました。
その結果、IdM から AD へのレルム間 TGS 要求 (双方向の信頼の設定) は、以下のエラーを出して失敗します。
"Generic error (see e-text) while getting credentials for <service principal>"
ドメイン SID の不一致により、移行した IdM ユーザーがログインできない可能性がある
ipa migrate-ds スクリプトを使用して IdM デプロイメントから別のデプロイメントにユーザーを移行する場合、そのユーザーの以前のセキュリティー識別子 (SID) には現在の IdM 環境のドメイン SID がないため、ユーザーが IdM サービスを使用する際に問題が発生する可能性があります。たとえば、これらのユーザーは kinit ユーティリティーを使用して Kerberos チケットを取得できますが、ログインできません。この問題を回避するには、ナレッジベースの記事 Migrated IdM users unable to log in due to mismatching domain SIDs を参照してください。
(JIRA:RHELPLAN-109613)
FIPS モードの IdM は、双方向のフォレスト間信頼を確立するための NTLMSSP プロトコルの使用をサポートしない
FIPS モードが有効な Active Directory (AD) と Identity Management (IdM) との間で双方向のフォレスト間の信頼を確立すると、New Technology LAN Manager Security Support Provider (NTLMSSP) 認証が FIPS に準拠していないため、失敗します。FIPS モードの IdM は、認証の試行時に AD ドメインコントローラーが使用する RC4 NTLM ハッシュを受け入れません。
FIPS モードで IdM Vault 暗号化および復号化に失敗する
FIPS モードが有効な場合は、OpenSSL RSA-PKCS1v15 パディング暗号化がブロックされます。その結果、現在は IdM が PKCS1v15 パディングを使用してセッションキーをトランスポート証明書でラップするため、Identity Management (IdM) Vault が正しく機能しません。
Samba をプリントサーバーとして実行し、RHEL 8.4 以前から更新する場合にアクションが必要です
今回の更新で、samba パッケージが /var/spool/samba/ ディレクトリーを作成しなくなりました。プリントサーバーとして Samba を使用し、[printers] 共有の /var/spool/samba/ を使用してプリントジョブをスプールすると、SELinux は Samba ユーザーがこのディレクトリーにファイルを作成しないようにします。したがって、印刷ジョブが失敗し、auditd サービスは /var/log/audit/audit.log に denied メッセージを記録します。8.4 以前からシステムを更新した後にこの問題を回避するには、以下を行います。
-
/etc/samba/smb.confファイルで[printers]共有を探します。 -
共有定義に
path = /var/spool/samba/が含まれる場合は、設定を更新して、pathパラメーターを/var/tmp/に設定します。 smbdサービスを再起動します。# systemctl restart smbd
Samba を RHEL 8.5 以降に新しくインストールした場合、アクションは不要です。その場合、samba-common パッケージが提供するデフォルトの /etc/samba/smb.conf ファイルは、すでに /var/tmp/ ディレクトリーを使用してプリントジョブをスプールします。
(BZ#2009213)
バージョン 1.2.2 へのリベース後の authselect のダウングレードにより、システム認証の破損
authselect パッケージが、最新のアップストリームバージョン 1.2.2 にリベースされました。authselect のダウングレードはサポートされておらず、root を含むすべてのユーザーに対してシステム認証が破損しています。
authselect パッケージを 1.2.1 以前にダウングレードした場合は、この問題を回避するために以下の手順を実行します。
-
GRUB ブート画面で、起動するカーネルのバージョンを含む
Red Hat Enterprise Linuxを選択し、eを押してエントリーを編集します。 -
linuxで始まる行の末尾で、singleを、別の単語で入力し、Ctrl+Xを押して起動プロセスを開始します。 - シングルユーザーモードでの起動時に、root パスワードを入力します。
以下のコマンドを使用して authselect 設定を復元します。
# authselect select sssd --force
NSS で有効になっている暗号の default キーワードは、他の暗号と組み合わせても機能しません
Directory Server では、default キーワードを使用して、ネットワークセキュリティーサービス (NSS) で有効になっているデフォルトの暗号を参照することができます。しかし、コマンドラインまたは Web コンソールを使用してデフォルトの暗号および追加の暗号を有効にする場合、Directory Server は default キーワードの解決に失敗します。その結果、サーバーは追加で指定された暗号のみを有効にし、次のようなエラーをログに記録します。
Security Initialization - SSL alert: Failed to set SSL cipher preference information: invalid ciphers <default,+cipher_name>: format is +cipher1,-cipher2... (Netscape Portable Runtime error 0 - no error)
回避策としては、追加で有効にしたいものも含めて、NSS でデフォルトで有効になっているすべての暗号を指定してください。
RHEL 8.6 から RHEL 8.7 への pki-core-debuginfo の更新が失敗する
RHEL 8.6 から RHEL 8.7 への pki-core-debuginfo パッケージの更新が失敗します。この問題を回避するには、以下のコマンドを実行します。
-
yum remove pki-core-debuginfo -
yum update -y -
yum install pki-core-debuginfo -
yum install idm-pki-symkey-debuginfo idm-pki-tools-debuginfo
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)
