4.13. Identity Management
SSSD で新しいパスワードレスの認証方法が利用可能になる
この更新により、SSSD でパスワードレス認証を有効にして設定し、FIDO2 仕様と互換性のある生体認証デバイス (YubiKey など) を使用できるようになりました。事前に FIDO2 トークンを登録し、この登録情報を RHEL IdM、Active Directory、または LDAP ストアのユーザーアカウントに保存する必要があります。RHEL は、libfido2 ライブラリーを使用して FIDO2 の互換性を実装していますが、現在は USB ベースのトークンのみをサポートしています。
Jira:RHELDOCS-17841[1]
ansible-freeipa ipauser および ipagroup モジュールが、新しい renamed 状態をサポートするようになる
この更新により、ansible-freeipa ipauser モジュールの renamed 状態を使用して、既存の IdM ユーザーのユーザー名を変更できるようになりました。また、ansible-freeipa ipagroup モジュールでこの状態を使用して、既存の IdM グループのグループ名を変更することもできます。
Identity Management ユーザーは、外部アイデンティティープロバイダーを使用して IdM に認証できるようになる
この機能拡張により、Identity Management (IdM) ユーザーを、OAuth 2 デバイス認証フローをサポートする外部アイデンティティープロバイダー (IdP) に関連付けることができるようになりました。このような IdP の例としては、Red Hat build of Keycloak、Microsoft Entra ID (旧 Azure Active Directory)、GitHub、Google などがあります。
IdM に IdP 参照と関連付けられた IdP ユーザー ID が存在する場合は、それらを使用して IdM ユーザーが外部 IdP で認証できるようにすることができます。外部 IdP で認証と認可を実行した後、IdM ユーザーはシングルサインオン機能を備えた Kerberos チケットを受け取ります。ユーザーは、RHEL 9.1 以降で使用可能な SSSD バージョンで認証する必要があります。
Jira:RHELPLAN-169666[1]
ipa がバージョン 4.11 にリベース
ipa パッケージがバージョン 4.10 から 4.11 に更新されました。主な変更点は、以下のとおりです。
- FIDO2 ベースのパスキーのサポート。
- Kerberos サービス用のリソースベースの制約付き委任 (RBCD) の初期実装。
-
ipalib.apiを自動的に設定、接続、切断するためのコンテキストマネージャー。 - IdM レプリカのインストールが、Kerberos 認証だけでなく、すべての IPA API および CA 要求に関しても、選択したサーバーに対して実行されるようになりました。
-
ansible-freeipaパッケージが、バージョン 1.11 から 1.12.1 にリベースされました。 -
ipa-healthcheckパッケージが、バージョン 0.12 から 0.16 にリベースされました。
詳細は、アップストリームのリリースノート を参照してください。
期限切れの KCM Kerberos チケットの削除
以前は、Kerberos Credential Manager (KCM) に新しい認証情報を追加しようとした際にすでにストレージ領域の上限に達していた場合、新しい認証情報は拒否されていました。ユーザーのストレージ領域は、max_uid_ccaches 設定オプション (デフォルト値は 64) によって制限されます。この更新により、ストレージ領域の上限にすでに達している場合は、最も古い期限切れの認証情報が削除され、新しい認証情報が KCM に追加されます。期限切れの認証情報がない場合、操作は失敗し、エラーが返されます。この問題を防ぐには、kdestroy コマンドを使用して認証情報を削除し、領域を解放します。
IdM は Ansible モジュール idoverrideuser、idoverridegroup、idview をサポートするようになりました
この更新により、ansible-freeipa パッケージに次のモジュールが含まれるようになりました。
idoverrideuser- Identity Management (IdM) LDAP サーバーに保存されているユーザーのユーザー属性 (ユーザーのログイン名、ホームディレクトリー、証明書、SSH キーなど) をオーバーライドできます。
idoverridegroup- IdM LDAP サーバーに保存されているグループの属性 (グループ名、GID、説明など) をオーバーライドできます。
idview- ユーザーおよびグループ ID のオーバーライドを整理し、特定の IdM ホストに適用できます。
将来的には、これらのモジュールを使用して、AD ユーザーがスマートカードを使用して IdM にログインできるようになります。
idp Ansible モジュールを使用すると、IdM ユーザーを外部 IdP に関連付けることができます
この更新により、idp ansible-freeipa モジュールを使用して、Identity Management (IdM) ユーザーを、OAuth 2 デバイス認可フローをサポートする外部アイデンティティープロバイダー (IdP) に関連付けることができます。IdM に IdP 参照および関連付けられた IdP ユーザー ID が存在する場合は、それらを使用して IdM ユーザーの IdP 認証を有効にすることができます。
外部 IdP で認証と認可を実行した後、IdM ユーザーはシングルサインオン機能を備えた Kerberos チケットを受け取ります。ユーザーは、RHEL 8.7 以降で使用可能な SSSD バージョンで認証する必要があります。
getcert add-ca は、証明書がすでに存在するか追跡されている場合に新しい戻りコードを返します
この更新により、すでに存在するか追跡されている証明書を追加または追跡しようとすると、getcert コマンドは特定の戻りコード 2 を返します。以前は、エラー状態が発生すると、このコマンドは戻りコード 1 を返していました。
DNS ゾーン管理の委譲が ansible-freeipa で有効になりました
dnszone ansible-freeipa モジュールを使用して、DNS ゾーン管理を委譲できるようになりました。dnszone モジュールの permission または managedby 変数を使用して、ゾーンごとのアクセス委譲権限を設定します。
すべての LDAP クライアントに OTP の使用を強制する
RHBA-2024:2558 アドバイザリーのリリースにより、RHEL IdM では、2 要素 (OTP) 認証が設定されたユーザーアカウントの LDAP サーバー認証におけるデフォルトの動作を設定できるようになりました。OTP が強制されている場合、LDAP クライアントは、関連付けられた OTP トークンを持つユーザーに対して、単一要素認証 (パスワード) を使用して LDAP サーバーに対して認証することはできません。この方法は、データなしの OID 2.16.840.1.113730.3.8.10.7 を使用した特別な LDAP 制御を使用することで、Kerberos バックエンドを通じてすでに実施されています。
すべての LDAP クライアントに OTP の使用を強制するには、管理者は次のコマンドを使用できます。
$ ipa config-mod --addattr ipaconfigstring=EnforceLDAPOTP
すべての LDAP クライアントに対して以前の OTP 動作に戻すには、次のコマンドを使用します。
$ ipa config-mod --delattr ipaconfigstring=EnforceLDAPOTP
Jira:RHEL-23377[1]
runasuser_group パラメーターが ansible-freeipa ipasudorule で利用できるようになる
この更新では、ansible-freeipa ipasudorule モジュールを使用して、sudo ルールの RunAs ユーザーのグループを設定できるようになりました。このオプションは、Identity Management (IdM) コマンドラインインターフェイスと IdM Web UI ですでに利用可能です。
389-ds-base がバージョン 2.4.5 にリベース
389-ds-base パッケージがバージョン 2.4.5 に更新されました。バージョン 2.3.4 への主なバグ修正および機能拡張は、以下のとおりです。
- https://www.port389.org/docs/389ds/releases/release-2-3-5.html
- https://www.port389.org/docs/389ds/releases/release-2-3-6.html
- https://www.port389.org/docs/389ds/releases/release-2-3-7.html
- https://www.port389.org/docs/389ds/releases/release-2-4-0.html
- https://www.port389.org/docs/389ds/releases/release-2-4-1.html
- https://www.port389.org/docs/389ds/releases/release-2-4-2.html
- https://www.port389.org/docs/389ds/releases/release-2-4-3.html
- https://www.port389.org/docs/389ds/releases/release-2-4-4.html
- https://www.port389.org/docs/389ds/releases/release-2-4-5.html
ns-slapd プロセスでは、Transparent Huge Pages がデフォルトで無効になりました
大規模なデータベースキャッシュを使用すると、Transparent Huge Pages (THP) によって、高い負荷がかかった状態の Directory Server のパフォーマンスに悪影響が生じる可能性があります。たとえば、メモリーフットプリントの増加、CPU 使用率の上昇、レイテンシースパイクなどが挙げられます。この機能拡張により、dirsrv systemd ユニットの /usr/lib/systemd/system/dirsrv@.service.d/custom.conf ドロップイン設定ファイルに、ns-slapd プロセスの THP を無効にする新しい設定オプション THP_DISABLE=1 が追加されました。
さらに、Directory Server ヘルスチェックツールが THP 設定を検出するようになりました。システム全体および Directory Server インスタンスに対して THP を有効にすると、ヘルスチェックツールは有効になっている THP について通知し、無効にする方法に関する推奨事項を出力します。
新しい lastLoginHistSize 設定属性が Account Policy プラグインで利用できるようになりました
以前は、ユーザーがバインドを正常に実行した場合、最後のログインの時刻しか利用できませんでした。この更新では、新しい lastLoginHistSize 設定属性を使用して、成功したログインの履歴を管理できます。デフォルトでは、成功したログインのうち最後の 5 回が保存されます。
lastLoginHistSize 属性で成功したログインの統計情報を収集するには、Account Policy プラグインの alwaysRecordLogin 属性を有効にする必要があります。
詳細は、lastLoginHistSize を参照してください。
Jira:RHEL-5133[1]
MFA バインドを識別する、アクセスログ内の新しい notes=M メッセージ
この更新により、MFA プラグインなどの事前バインド認証プラグインを使用してユーザーアカウントの二要素認証を設定すると、BIND 操作中に、Directory Server ログファイルに次のメッセージが記録されるようになりました。
アクセスログには、新しい
notes=Mnote メッセージが記録されます。[time_stamp] conn=1 op=0 BIND dn="uid=jdoe,ou=people,dc=example,dc=com" method=128 version=3 [time_stamp] conn=1 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000111632 optime=0.006612223 etime=0.006722325 notes=M details="Multi-factor Authentication" dn="uid=jdoe,ou=people,dc=example,dc=com"セキュリティーログには、新しい
SIMPLE/MFAバインドメソッドが記録されます。{ "date": "[time_stamp] ", "utc_time": "1709327649.232748932", "event": "BIND_SUCCESS", "dn": "uid=djoe,ou=people,dc=example,dc=com", "bind_method": "SIMPLE\/MFA", "root_dn": false, "client_ip": "::1", "server_ip": "::1", "ldap_version": 3, "conn_id": 1, "op_id": 0, "msg": "" }
アクセスログとセキュリティーログにこのようなメッセージを記録するには、バインドが事前バインド認証プラグインの一部である場合、事前バインド認証プラグインで SLAPI API を使用してフラグを設定する必要があります。
Jira:RHELDOCS-17838[1]
新しい inchainMatch マッチングルールが利用可能になる
この更新により、クライアントアプリケーションは新しい inchainMatch マッチングルールを使用して、LDAP エントリーの祖先を検索できるようになります。inchainMatch マッチングルールでは、member、manager、parentOrganization、memberof 属性が使用可能であり、次の検索を実行できます。
- ユーザーがメンバーになっているすべての直接または間接のグループを検索します。
- 特定のユーザーがマネージャーであるすべての直接または間接ユーザーを検索します。
- エントリーが属するすべての直接または間接的な組織を検索します。
- 特定のグループのすべての直接または間接メンバーを検索します。
パフォーマンス上の理由から、クライアントアプリケーションが inchainMatch マッチングルールを使用してこれらの属性に対する検索を実行する場合は、member、manager、parentOrganization、および memberof 属性をインデックス化する必要があることに注意してください。
Directory Server は、デフォルトで有効になっている In Chain プラグインを使用して、inchainMatch マッチングルールを実装します。ただし、inchainMatch の計算にはコストがかかるため、アクセス制御命令 (ACI) によってマッチングルールの使用が制限されます。
詳細は、inchainMatch マッチングルールを使用して LDAP エントリーの祖先を検索する を参照してください。
Jira:RHELDOCS-17256[1]
HAProxy プロトコルが 389-ds-base パッケージでサポートされるようになりました
以前は、Directory Server はプロキシークライアントと非プロキシークライアント間の着信接続を区別していませんでした。この更新により、新しい多値設定属性 nsslapd-haproxy-trusted-ip を使用して、信頼できるプロキシーサーバーのリストを設定できるようになりました。cn=config エントリーの下に nsslapd-haproxy-trusted-ip が設定されている場合、Directory Server は HAProxy プロトコルを使用して追加の TCP ヘッダー経由でクライアント IP アドレスを受信します。これにより、アクセス制御命令 (ACI) を正しく評価し、クライアントトラフィックをログに記録できるようになります。
信頼されていないプロキシーサーバーがバインド要求を開始した場合、Directory Server は要求を拒否し、エラーログファイルに次のメッセージを記録します。
[time_stamp] conn=5 op=-1 fd=64 Disconnect - Protocol error - Unknown Proxy - P4
詳細は、nsslapd-haproxy-trusted-ip を参照してください。
samba がバージョン 4.19.4 にリベース
samba パッケージはアップストリームバージョン 4.19.4 にアップグレードされ、以前のバージョンに対するバグ修正と機能拡張が提供されています。主な変更点は以下のとおりです。
-
一貫したユーザーエクスペリエンスを実現するために、
smbgetユーティリティーのコマンドラインオプションは名前が変更され、削除されました。ただし、これにより、ユーティリティーを使用する既存のスクリプトまたはジョブが破損する可能性があります。新しいオプションの詳細は、smbget --helpコマンドとsmbget(1)の man ページを参照してください。 winbind debug traceidオプションが有効になっている場合、winbindサービスは次のフィールドもログに記録するようになりました。-
traceid: 同じリクエストに属するレコードを追跡します。 -
depth: リクエストのネストレベルを追跡します。
-
- Samba は独自の暗号化実装を使用しなくなり、代わりに GnuTLS ライブラリーが提供する暗号化機能を全面的に使用するようになりました。
-
directory name cache sizeオプションが削除されました。
Samba 4.11 以降はサーバーメッセージブロックバージョン 1 (SMB1) プロトコルが非推奨となり、今後のリリースで削除されることに注意してください。
Samba を起動する前にデータベースファイルがバックアップされます。smbd、nmbd、またはwinbind サービスが起動すると、Samba が tdb データベースファイルを自動的に更新します。Red Hat は、tdb データベースファイルのダウングレードをサポートしていません。
Samba を更新した後、testparm ユーティリティーを使用して /etc/samba/smb.conf ファイルを確認します。
Identity Management API が完全にサポートされるようになりました
Identity Management (IdM) API は、RHEL 9.2 でテクノロジープレビューとして利用可能でした。RHEL 9.3 以降では完全にサポートされています。
IdM API が拡張されて API コマンドの複数のバージョンが有効になった場合でも、ユーザーは既存のツールとスクリプトを使用できます。これらの機能拡張により、コマンドの動作が互換性のない方法で変更されることはありません。これには次の利点があります。
- 管理者は、管理しているクライアントではなくサーバー上で、IdM の以前のバージョンもしくは最近のバージョンを使用できます。
- サーバーで IdM のバージョンを変更しても、開発者は特定バージョンの IdM コールを使用できます。
たとえば、一方が機能の新しいオプションを導入した新しいバージョンを使用している場合でも、サーバーとの通信は可能です。
- 注記
- IdM API は JSON-RPC インターフェイスを提供しますが、このタイプのアクセスはサポートされていません。Red Hat では、代わりに Python を使用して API にアクセスすることを推奨します。Python を使用すると、サーバーからのメタデータの取得などの重要な部分が自動化され、使用可能なすべてのコマンドをリスト表示できるようになります。
