11.11. Identity Management
MIT Kerberos は PKINIT の ECC 証明書をサポートしない
MIT Kerberos は、初期認証 (PKINIT) の公開鍵暗号化における楕円曲線暗号化 (ECC) サポートの設計を説明するコメントドキュメントに、RFC5349 要求を実装していません。したがって、RHEL で使用される MIT krb5-pkinit パッケージは ECC 証明書に対応していません。詳細は、Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) を参照してください。
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 にログインできない
IdM レプリカを RHEL 9.2 にアップグレードした後、IdM Kerberos Distribution Center (KDC) は、アカウントにセキュリティー識別子 (SID) が割り当てられていないユーザーに Ticket-Granting Ticket (TGT) を発行できない場合があります。その結果、ユーザーは自分のアカウントにログインできなくなります。
この問題を回避するには、トポロジー内の別の IdM レプリカで IdM 管理者として次のコマンドを実行して SID を生成します。
# ipa config-mod --enable-sid --add-sids
その後もユーザーがログインできない場合は、Directory Server のエラーログを調べてください。ユーザーの POSIX ID を含めるように ID 範囲を調整する必要がある場合があります。
詳細は、ナレッジベースのソリューション記事 When upgrading to RHEL9, IDM users are not able to login anymore を参照してください。
Jira:RHELPLAN-157939[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]
ユーザー PAC を生成する暗号化タイプに互換性がないため、MIT krb5 ユーザーは AD TGT の取得に失敗する
MIT krb5 1.20 以降のパッケージでは、デフォルトですべての Kerberos チケットに特権属性証明書 (PAC) が含まれています。MIT Kerberos Distribution Center (KDC) は、PAC で KDC チェックサムを生成するために使用できる最も強力な暗号化タイプを選択します。これは現在、RFC8009 で定義されている AES HMAC-SHA2 暗号化タイプです。ただし、Active Directory (AD) はこの RFC をサポートしていません。その結果、AD-MIT クロスレルム設定では、MIT KDC によって生成されたクロスレルム TGT に互換性のない KDC チェックサムタイプが PAC に含まれているため、MIT krb5 ユーザーは AD チケット認可チケット (TGT) を取得できません。
この問題を回避するには、/var/kerberos/krb5kdc/kdc.conf 設定ファイルの [realms] セクションで MIT レルムの disable_pac パラメーターを true に設定します。その結果、MIT KDC は PAC なしでチケットを生成します。これは、AD が失敗したチェックサム検証をスキップし、MIT krb5 ユーザーが AD TGT を取得できることを意味します。
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[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:'
この問題を回避するには、RHEL 9 レプリカで AES HMAC-SHA1 の使用を有効にします。
update-crypto-policies --set FIPS:AD-SUPPORT
- WARNING
- この回避策は FIPS 準拠に違反する可能性があります。
その結果、RHEL 9 レプリカの IdM デプロイメントへの追加が正しく進行します。
RHEL 7 および RHEL 8 サーバー上で欠落している AES HMAC-SHA2 暗号化 Kerberos キーを生成する手順を提供する作業が進行中であることに注意してください。これにより、RHEL 9 レプリカで FIPS 140-3 準拠が達成されます。ただし、Kerberos キー暗号化の設計により、既存のキーを別の暗号化タイプに変換することができないため、このプロセスは完全には自動化されません。唯一の方法は、ユーザーにパスワードの更新を求めることです。
SSSD は DNS 名を適切に登録する
以前は、DNS が正しく設定されていない場合、SSSD は DNS 名の登録の最初の試行で常に失敗していました。この問題を回避するために、この更新では新しいパラメーター dns_resolver_use_search_list が提供されます。DNS 検索リストの使用を回避するには、dns_resolver_use_search_list = false を設定します。
Bugzilla:1608496[1]
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]
