検索

8.13. Identity Management

download PDF

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 認証に失敗するも併せて参照してください。

(BZ#2068935)

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 サブポリシーを設定する必要があります。も併せて参照してください。

(BZ#2077450)

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 を使用してユーザーを認証できませんも併せて参照してください。

(BZ#2060798)

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

(BZ#2057471)

referral mode で起動すると、Directory Server が予期せず終了する

バグにより、Directory Server ではグローバル参照モードが動作しません。dirsrv ユーザーとして refer オプションを指定して ns-slapd プロセスを開始すると、Directory Server はポート設定を無視し、予期せず終了します。root ユーザーが SELinux ラベルを変更し、サービスが将来通常モードで開始されないようにプロセスを実行しようとしています。回避策はありません。

(BZ#2053204)

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

これにより、接尾辞の参照の設定に失敗します。この問題を回避するには、以下のコマンドを実行します。

  1. 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
  2. バックエンド状態を設定します。

    # dsconf <instance_name> backend suffix set --state referral

その結果、回避策により、接尾辞の参照を設定できます。

(BZ#2063140)

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 属性が欠落しているか無効であるエントリーを修正します。

(BZ#2047175)

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)

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.