8.13. Identity Management
RHEL 9 クライアントが Heimdal KDC に対して PKINIT を使用してユーザーを認証できません
RHEL 9 Kerberos クライアントでの IdM ユーザーの PKINIT 認証中に、Kerberos クライアントが supportedCMSTypes フィールドをサポートしていないため、RHEL 9 以前の Heimdal Kerberos Distribution Center (KDC) は SHA-1 バックアップ署名アルゴリズムを使用します。ただし、SHA-1 アルゴリズムは RHEL 9 で非推奨になっているため、ユーザー認証は失敗します。
この問題を回避するには、次のコマンドを使用して、RHEL 9 クライアントで SHA-1 アルゴリズムのサポートを有効にします。
# update-crypto-policies --set DEFAULT:SHA1
その結果、PKINIT 認証は Kerberos クライアントと Heimdal KDC の間で機能します。
サポートされているバックアップ署名アルゴリズムの詳細は、CMS アルゴリズム識別子に対して定義された Kerberos 暗号化タイプ を参照してください。
RHEL 9 Kerberos エージェントが RHEL 9 以外の Kerberos エージェントと通信すると、ユーザーの PKINIT 認証に失敗するも併せて参照してください。
RHEL 9 Kerberos エージェントが RHEL 9 以外の Kerberos エージェントと通信すると、ユーザーの PKINIT 認証に失敗する
RHEL 9 の Kerberos エージェントが環境内の別の RHEL 9 Kerberos エージェントと相互作用すると、ユーザーの初期認証 (PKINIT) 認証の公開鍵暗号化に失敗します。この問題を回避するには、以下のいずれかのアクションを実行します。
RHEL 9 エージェントの crypto-policy を
DEFAULT:SHA1に設定して、SHA-1 署名の検証を許可します。# update-crypto-policies --set DEFAULT:SHA1
RHEL 9 以外のエージェントを更新して、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
パッチが適用されていないエージェントが Kerberos クライアントか Kerberos Distribution Center (KDC) であるかに関わらず、これらのアクションのいずれかを実行する必要があります。
その結果、ユーザーの PKINIT 認証が正しく機能します。
他のオペレーティングシステムでは、エージェントが SHA-1 ではなく SHA-256 で CMS データを署名するように krb5-1.20 リリースであることに注意してください。
PKINIT が古い RHEL KDC および AD KDC に対して機能するには、RHEL 9 クライアントで DEFAULT:SHA1 サブポリシーを設定する必要があります。も併せて参照してください。
PKINIT が古い RHEL KDC および AD KDC に対して機能するには、RHEL 9 クライアントで DEFAULT:SHA1 サブポリシーを設定する必要があります。
SHA-1 ダイジェストアルゴリズムは RHEL 9 で非推奨になり、初期認証 (PKINIT) の公開鍵暗号化の CMS メッセージは、より強力な SHA-256 アルゴリズムで署名されるようになりました。
RHEL 7.9 および RHEL 8.7 以降では、SHA-256 がデフォルトで使用されますが、RHEL 7.8 および RHEL 8.6 の古い Kerberos Key Distribution Centers (KDC) は、引き続き SHA-1 ダイジェストアルゴリズムを使用して CMS メッセージに署名するために使用されます。Active Directory (AD) KDC も同様です。
その結果、RHEL 9 Kerberos クライアントは、以下に対して PKINIT を使用してユーザーを認証できません。
- RHEL 7.8 以前で実行されている KDC
- RHEL 8.6 以前で実行されている KDC
- AD KDC
この問題を回避するには、次のコマンドを使用して、RHEL 9 システムで SHA-1 アルゴリズムのサポートを有効にします。
# update-crypto-policies --set DEFAULT:SHA1
RHEL 9 クライアントが Heimdal KDC に対して PKINIT を使用してユーザーを認証できませんも併せて参照してください。
AD 信頼の FIPS サポートには、AD-SUPPORT 暗号サブポリシーが必要
Active Directory (AD) は、AES SHA-1 HMAC 暗号化タイプを使用します。これは、デフォルトで RHEL 9 の FIPS モードでは許可されていません。AD トラストで RHEL 9 ホストを使用する場合は、IdM ソフトウェアをインストールする前に、AESSHA-1HMAC 暗号化タイプのサポートを有効にしてください。
FIPS 準拠は技術的合意と組織的合意の両方を伴うプロセスであるため、AD-SUPPORT サブポリシーを有効にして技術的手段が AES SHA-1 HMAC 暗号化タイプをサポートできるようにする前に、FIPS 監査人に相談してから、RHEL IdM をインストールしてください。
# update-crypto-policies --set FIPS:AD-SUPPORT
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)
