11.11. Identity Management
PKINIT が AD KDC に対して機能するように、DEFAULT:SHA1 サブポリシーを RHEL 9 クライアントに設定する必要がある
SHA-1 ダイジェストアルゴリズムは RHEL 9 で非推奨になり、初期認証 (PKINIT) の公開鍵暗号化の CMS メッセージは、より強力な SHA-256 アルゴリズムで署名されるようになりました。
しかし、Active Directory (AD) Kerberos Distribution Center (KDC) は引き続き SHA-1 ダイジェストアルゴリズムを使用して CMS メッセージに署名します。その結果、RHEL 9 Kerberos クライアントは、AD KDC に対して PKINIT を使用してユーザーを認証できません。
この問題を回避するには、次のコマンドを使用して、RHEL 9 システムで SHA-1 アルゴリズムのサポートを有効にします。
# update-crypto-policies --set DEFAULT:SHA1
RHEL 9 Kerberos エージェントが RHEL-9 以外、AD 以外の Kerberos エージェントと通信すると、ユーザーの PKINIT 認証が失敗する
クライアントまたは Kerberos Distribution Center (KDC) のいずれかの RHEL 9 Kerberos エージェントが、Active Directory (AD) エージェントではない RHEL-9 Kerberos エージェントとやりとりすると、ユーザーの PKINIT 認証に失敗します。この問題を回避するには、以下のいずれかのアクションを実行します。
RHEL 9 エージェントの crypto-policy を
DEFAULT:SHA1に設定して、SHA-1 署名の検証を許可します。# update-crypto-policies --set DEFAULT:SHA1
RHEL 9 以外および AD 以外のエージェントを更新して、SHA-1 アルゴリズムを使用して CMS データを署名しないようにします。そのためには、Kerberos パッケージを SHA-1 の代わりに SHA-256 を使用するバージョンに更新します。
- CentOS 9 Stream: krb5-1.19.1-15
- RHEL 8.7: krb5-1.18.2-17
- RHEL 7.9: krb5-1.15.1-53
- Fedora Rawhide/36: krb5-1.19.2-7
- Fedora 35/34: krb5-1.19.2-3
その結果、ユーザーの PKINIT 認証が正しく機能します。
他のオペレーティングシステムでは、エージェントが SHA-1 ではなく SHA-256 で CMS データを署名するように krb5-1.20 リリースであることに注意してください。
PKINIT が AD KDC に対して機能するように、DEFAULT:SHA1 サブポリシーを RHEL 9 クライアントに設定する必要があるも併せて参照してください。
AD 信頼の FIPS サポートには、AD-SUPPORT 暗号サブポリシーが必要
Active Directory (AD) は、AES SHA-1 HMAC 暗号化タイプを使用します。これは、デフォルトで RHEL 9 の FIPS モードでは許可されていません。AD 信頼を使用する RHEL 9 IdM ホストを使用する場合は、IdM ソフトウェアをインストールする前に、AES SHA-1 HMAC 暗号化タイプのサポートを有効にしてください。
FIPS 準拠は技術的合意と組織的合意の両方を伴うプロセスであるため、AD-SUPPORT サブポリシーを有効にして技術的手段が AES SHA-1 HMAC 暗号化タイプをサポートできるようにする前に、FIPS 監査人に相談してから、RHEL IdM をインストールしてください。
# update-crypto-policies --set FIPS:AD-SUPPORT
Heimdal クライアントは、RHEL 9 KDC に対して PKINIT を使用してユーザーを認証できない
デフォルトでは、Heimdal Kerberos クライアントは、Internet Key Exchange (IKE) に Modular Exponential (MODP) Diffie-Hellman Group 2 を使用して、IdM ユーザーの PKINIT 認証を開始します。ただし、RHEL 9 の MIT Kerberos Distribution Center (KDC) は、MODP Group 14 および 16 のみに対応しています。
したがって、Heimdal クライアントで krb5_get_init_creds: PREAUTH_FAILED エラーが発生し、RHEL MIT KDC では Key parameters not accepted が発生します。
この問題を回避するには、Heimdal クライアントが MODP Group 14 を使用していることを確認してください。クライアント設定ファイルの libdefaults セクションで pkinit_dh_min_bits パラメーターを 1759 に設定します。
[libdefaults] pkinit_dh_min_bits = 1759
その結果、Heimdal クライアントは、RHEL MIT KDC に対する PKINIT 事前認証を完了します。
FIPS モードの IdM は、双方向のフォレスト間信頼を確立するための NTLMSSP プロトコルの使用をサポートしない
FIPS モードが有効な Active Directory (AD) と Identity Management (IdM) との間で双方向のフォレスト間の信頼を確立すると、New Technology LAN Manager Security Support Provider (NTLMSSP) 認証が FIPS に準拠していないため、失敗します。FIPS モードの IdM は、認証の試行時に AD ドメインコントローラーが使用する RC4 NTLM ハッシュを受け入れません。
Jira:RHEL-12154[1]
ドメイン 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[1]
RHEL 8.6 以前で初期化された FIPS モードの IdM デプロイメントに FIPS モードの RHEL 9 レプリカを追加すると失敗する
FIPS 140-3 への準拠を目的としたデフォルトの RHEL 9 FIPS 暗号化ポリシーでは、RFC3961 のセクション 5.1 で定義されている AES HMAC-SHA1 暗号化タイプのキー派生関数の使用が許可されていません。
この制約は、最初のサーバーが RHEL 8.6 システム以前にインストールされている FIPS モードの RHEL 8 IdM 環境に、FIPS モードの RHEL 9 Identity Management (IdM) レプリカを追加する際の障害となります。これは、AES HMAC-SHA1 暗号化タイプを一般的に使用し、AES HMAC-SHA2 暗号化タイプを使用しない、RHEL 9 と以前の RHEL バージョンの間に共通の暗号化タイプがないためです。
サーバーで次のコマンドを入力すると、IdM マスターキーの暗号化タイプを表示できます。
# kadmin.local getprinc K/M | grep -E '^Key:'
詳細は、KCS ソリューション AD Domain Users unable to login in to the FIPS-compliant environment を参照してください。
EMS 強制により、FIPS モードで RHEL 9.2 以降の IdM サーバーを使用した RHEL 7 IdM クライアントのインストールが失敗する
FIPS 対応の RHEL 9.2 以降のシステムで、TLS 1.2 接続に TLS Extended Master Secret (EMS) エクステンション (RFC 7627) が必須になりました。これは FIPS-140-3 要件に準拠しています。ただし、RHEL 7.9 以前で利用可能な openssl バージョンは EMS をサポートしていません。その結果、RHEL 9.2 以降で実行されている FIPS 対応の IdM サーバーに RHEL 7 Identity Management (IdM) クライアントをインストールすると失敗します。
IdM クライアントをインストールする前にホストを RHEL 8 にアップグレードできない場合は、FIPS 暗号化ポリシーに加えて NO-ENFORCE-EMS サブポリシーを適用して、RHEL 9 サーバーでの EMS 使用の要件を削除することで問題を回避します。
# update-crypto-policies --set FIPS:NO-ENFORCE-EMS
この削除は FIPS 140-3 要件に反することに注意してください。その結果、EMS を使用しない TLS 1.2 接続を確立して受け入れることができ、RHEL 7 IdM クライアントのインストールは成功します。
オンラインバックアップとオンライン自動メンバーシップ再構築タスクが、2 つのロックを取得してデッドロックを引き起こす可能性がある
オンラインバックアップとオンライン自動メンバーシップ再構築タスクが、同じ 2 つのロックを逆の順序で取得しようとすると、回復不能なデッドロックが発生し、サーバーを停止して再起動する必要が生じる可能性があります。この問題を回避するには、オンラインバックアップとオンライン自動メンバーシップ再構築タスクを並行して起動しないでください。
Jira:RHELDOCS-18065[1]
dsconf config replace で複数値属性を処理できない
現在、dsconf config replace コマンドで、nsslapd-haproxy-trusted-ip などの複数値属性に複数の値を設定できません。
この問題を回避するには、ldapmodify ユーティリティーを使用します。たとえば、複数の信頼できる IP アドレスを設定する場合は、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x << EOF dn: cn=config changetype: modify add: nsslapd-haproxy-trusted-ip nsslapd-haproxy-trusted-ip: 192.168.0.1 nsslapd-haproxy-trusted-ip: 192.168.0.2 nsslapd-haproxy-trusted-ip: 192.168.0.3 EOF
