11.11. Identity Management
Directory Server で接尾辞の紹介の設定に失敗する
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 属性が欠落しているか無効であるエントリーを修正します。
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 クライアントに設定する必要があるも併せて参照してください。
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 にログインできない
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
ドメイン 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
ユーザー 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
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 を参照してください。
SSSD は DNS 名を適切に登録する
以前は、DNS が正しく設定されていない場合、SSSD は DNS 名の登録の最初の試行で常に失敗していました。この問題を回避するために、この更新では新しいパラメーター dns_resolver_use_search_list が提供されます。DNS 検索リストの使用を回避するには、dns_resolver_use_search_list = false を設定します。
Bugzilla:1608496
referral mode で起動すると、Directory Server が予期せず終了する
バグにより、Directory Server ではグローバル参照モードが動作しません。dirsrv ユーザーとして refer オプションを指定して ns-slapd プロセスを開始すると、Directory Server はポート設定を無視し、予期せず終了します。root ユーザーが SELinux ラベルを変更し、サービスが将来通常モードで開始されないようにプロセスを実行しようとしています。回避策はありません。
Directory Server は、/var/lib/dirsrv/slapd-instance_name/ldif/ からのみ LDIF ファイルをインポート可能
RHEL 8.3 以降、Red Hat Directory Server (RHDS) は独自のプライベートディレクトリーを使用し、LDAP サービスに対して PrivateTmp systemd ディレクティブがデフォルトで有効になっています。その結果、RHDS は、/var/lib/dirsrv/slapd-instance_name/ldif/ ディレクトリーからのみ LDIF ファイルをインポートできます。LDIF ファイルが /var/tmp、/tmp、/root などの別のディレクトリーに保存されている場合、インポートは次のようなエラーで失敗します。
Could not open LDIF file "/tmp/example.ldif", errno 2 (No such file or directory)
この問題を回避するには、以下の手順を実行します。
LDIF ファイルを
/var/lib/dirsrv/slapd-instance_name/ldif/ディレクトリーに移動します。# mv /tmp/example.ldif /var/lib/dirsrv/slapd-instance_name__/ldif/dirsrvユーザーがファイルを読み取れるようにする権限を設定します。# chown dirsrv /var/lib/dirsrv/slapd-instance_name/ldif/example.ldifSELinux コンテキストを復元します。
# restorecon -Rv /var/lib/dirsrv/slapd-instance_name/ldif/
詳細は、ソリューション記事 LDAP サービスがホストの /tmp および /var/tmp ディレクトリーにあるファイルにアクセスできない を参照してください。
EMS 強制により、FIPS モードで RHEL 9.2+ IdM サーバーを使用した RHEL 7 IdM クライアントのインストールが失敗する
TLS Extended Master Secret (EMS) 拡張機能 (RFC 7627) は、FIPS 対応の RHEL 9.2 以降のシステムでの TLS 1.2 接続に必須になりました。これは 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 クライアントのインストールは成功します。
