9.12. Identity Management
Samba をプリントサーバーとして実行し、RHEL 8.4 以前から更新する場合にアクションが必要です
今回の更新で、samba パッケージが /var/spool/samba/ ディレクトリーを作成しなくなりました。プリントサーバーとして Samba を使用し、[printers] 共有の /var/spool/samba/ を使用してプリントジョブをスプールすると、SELinux は Samba ユーザーがこのディレクトリーにファイルを作成しないようにします。したがって、印刷ジョブが失敗し、auditd サービスは /var/log/audit/audit.log に denied メッセージを記録します。8.4 以前からシステムを更新した後にこの問題を回避するには、以下を行います。
-
/etc/samba/smb.confファイルで[printers]共有を探します。 -
共有定義に
path = /var/spool/samba/が含まれる場合は、設定を更新して、pathパラメーターを/var/tmp/に設定します。 smbdサービスを再起動します。# systemctl restart smbd
Samba を RHEL 8.5 以降に新しくインストールした場合、アクションは不要です。その場合、samba-common パッケージが提供するデフォルトの /etc/samba/smb.conf ファイルは、すでに /var/tmp/ ディレクトリーを使用してプリントジョブをスプールします。
Bugzilla:2009213[1]
--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムが破損します。
--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムの LDAP 設定が破損します。したがって、Certificate System は不安定になり、システムの復元に手動の操作が必要になる可能性があります。
FIPS モードは、共有シークレットを使用したフォレスト間の信頼を確立することをサポートしません。
NTLMSSP 認証は FIPS に準拠していないため、FIPS モードでフォレスト間の信頼を確立できません。この問題を回避するには、FIPS モードが有効な IdM ドメインと AD ドメインとの間に信頼を確立する際に、Active Directory (AD) 管理アカウントで認証します。
バージョン 1.2.2 へのリベース後の authselect のダウングレードにより、システム認証の破損
authselect パッケージが、最新のアップストリームバージョン 1.2.2 にリベースされました。authselect のダウングレードはサポートされておらず、root を含むすべてのユーザーに対してシステム認証が破損しています。
authselect パッケージを 1.2.1 以前にダウングレードした場合は、この問題を回避するために以下の手順を実行します。
-
GRUB ブート画面で、起動するカーネルのバージョンを含む
Red Hat Enterprise Linuxを選択し、eを押してエントリーを編集します。 -
linuxで始まる行の末尾で、singleを、別の単語で入力し、Ctrl+Xを押して起動プロセスを開始します。 - シングルユーザーモードでの起動時に、root パスワードを入力します。
以下のコマンドを使用して authselect 設定を復元します。
# authselect select sssd --force
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>
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 から RHEL 8.7 以降への pki-core-debuginfo の更新が失敗する
RHEL 8.6 から RHEL 8.7 以降への pki-core-debuginfo パッケージの更新が失敗します。この問題を回避するには、以下のコマンドを実行します。
-
yum remove pki-core-debuginfo -
yum update -y -
yum install pki-core-debuginfo -
yum install idm-pki-symkey-debuginfo idm-pki-tools-debuginfo
Jira:RHEL-13125[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]
FIPS モードの IdM は、双方向のフォレスト間信頼を確立するための NTLMSSP プロトコルの使用をサポートしない
FIPS モードが有効な Active Directory (AD) と Identity Management (IdM) との間で双方向のフォレスト間の信頼を確立すると、New Technology LAN Manager Security Support Provider (NTLMSSP) 認証が FIPS に準拠していないため、失敗します。FIPS モードの IdM は、認証の試行時に AD ドメインコントローラーが使用する RC4 NTLM ハッシュを受け入れません。
Kerberos プリンシパルの有効期限を設定する際の誤った警告
Kerberos プリンシパルのパスワード有効期限を設定すると、32 ビットの符号付き整数変数を使用して、現在のタイムスタンプが有効期限のタイムスタンプと比較されます。有効期限が 68 年以上先の場合、整数変数のオーバーフローが発生し、次の警告メッセージが表示されます。
Warning: Your password will expire in less than one hour on [expiration date]
このメッセージは無視しても問題ありません。パスワードは設定された日時に正しく期限切れになります。
RHEL 8 で NIS マップ内の多数のエントリーを列挙するのが遅い
RHEL 8 に nis_nss パッケージをインストールした場合、/etc/default/NSS 設定ファイルがありません。このファイルは、glibc-common パッケージによって提供されなくなったためです。その結果、RHEL 8 では NIS マップ内の多数のエントリーを列挙するのに、RHEL 7 よりも大幅に時間がかかります。すべての要求が、デフォルトで一括ではなく個別に処理されるためです。
この問題を回避するには、次の内容の /etc/default/nss ファイルを作成し、SETENT_BATCH_READ 変数を TRUE に設定してください。
# /etc/default/nss
# This file can theoretically contain a bunch of customization variables
# for Name Service Switch in the GNU C library. For now there are only
# four variables:
#
# NETID_AUTHORITATIVE
# If set to TRUE, the initgroups() function will accept the information
# from the netid.byname NIS map as authoritative. This can speed up the
# function significantly if the group.byname map is large. The content
# of the netid.byname map is used AS IS. The system administrator has
# to make sure it is correctly generated.
#NETID_AUTHORITATIVE=TRUE
#
# SERVICES_AUTHORITATIVE
# If set to TRUE, the getservbyname{,_r}() function will assume
# services.byservicename NIS map exists and is authoritative, particularly
# that it contains both keys with /proto and without /proto for both
# primary service names and service aliases. The system administrator
# has to make sure it is correctly generated.
#SERVICES_AUTHORITATIVE=TRUE
#
# SETENT_BATCH_READ
# If set to TRUE, various setXXent() functions will read the entire
# database at once and then hand out the requests one by one from
# memory with every getXXent() call. Otherwise each getXXent() call
# might result into a network communication with the server to get
# the next entry.
SETENT_BATCH_READ=TRUE
#
# ADJUNCT_AS_SHADOW
# If set to TRUE, the passwd routines in the NIS NSS module will not
# use the passwd.adjunct.byname tables to fill in the password data
# in the passwd structure. This is a security problem if the NIS
# server cannot be trusted to send the passwd.adjuct table only to
# privileged clients. Instead the passwd.adjunct.byname table is
# used to synthesize the shadow.byname table if it does not exist.
#ADJUNCT_AS_SHADOW=TRUEJira:RHEL-34075[1]
新しいオプション local_auth_policy の導入後、スマートカード認証の設定更新が必要になる場合がある
RHEL 8.10 に更新すると、local_auth_policy オプションによって導入される変更により、スマートカード認証が失敗する可能性があります。local_auth_policy がデフォルト値 match に設定されていると、SSSD によって、オフライン認証方法がオンラインで利用可能な方法に制限されます。その結果、たとえば auth_provider = ldap を使用する場合など、設定されているバックエンドによってスマートカード認証が提供されない場合、ユーザーがスマートカード認証を利用できなくなります。この問題を回避するには、sssd.conf ファイルのドメインセクションに local_auth_policy = enable:smartcard を追加してスマートカード認証方法を明示的に有効にし、SSSD を再起動します。
