11.13. 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-polices --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 ハッシュを受け入れません。
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>"
FIPS モードで IdM Vault 暗号化および復号化に失敗します
FIPS モードが有効な場合は、OpenSSL RSA-PKCS1v15 パディング暗号化がブロックされます。その結果、現在は IdM が PKCS1v15 パディングを使用してセッションキーをトランスポート証明書でラップするため、Identity Management (IdM) Vault が正しく機能しません。
ドメイン 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)
referral mode で起動すると、Directory Server が予期せず終了する
バグにより、Directory Server ではグローバル参照モードが動作しません。dirsrv ユーザーとして refer オプションを指定して ns-slapd プロセスを開始すると、Directory Server はポート設定を無視し、予期せず終了します。root ユーザーが SELinux ラベルを変更し、サービスが将来通常モードで開始されないようにプロセスを実行しようとしています。回避策はありません。
Directory Server で接尾辞の referral の設定に失敗する。
Directory Server でバックエンド参照を設定すると、dsconf <instance_name> backend suffix set --state referral コマンドを使用したバックエンドの状態設定に失敗し、次のエラーが表示されます。
Error: 103 - 9 - 53 - Server is unwilling to perform - [] - need to set nsslapd-referral before moving to referral state
これにより、接尾辞の参照の設定に失敗します。この問題を回避するには、以下のコマンドを実行します。
nsslapd-referralパラメーターを手動で設定します。# ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: nsslapd-referral nsslapd-referral: ldap://remote_server:389/dc=example,dc=com
バックエンド状態を設定します。
# dsconf <instance_name> backend suffix set --state referral
その結果、回避策により、接尾辞の参照を設定できます。
dsconf ユーティリティーには、entryUUID プラグインの修正タスクを作成するオプションがありません。
dsconf ユーティリティーは、entryUUID プラグインの修正タスクを作成するオプションを提供しません。その結果、管理者は dsconf を使用して、既存のエントリーに entryUUID 属性を自動的に追加するタスクを作成することはできません。回避策として、タスクを手動で作成します。
# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x dn: cn=entryuuid_fixup_<time_stamp>,cn=entryuuid task,cn=tasks,cn=config objectClass: top objectClass: extensibleObject basedn: <fixup base tree> cn: entryuuid_fixup_<time_stamp> filter: <filtered_entry>
タスクが作成された後、Directory Server は entryUUID 属性が欠落しているか無効であるエントリーを修正します。
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)
