第14章 Identity Management
以下の章では、Identity Management (IdM) に関する RHEL 8 と RHEL 9 の間の最も重要な変更点を説明します。
14.1. 新機能
SSSD で新しいパスワードレスの認証方法が利用可能になる
RHEL 9.4 以降では、SSSD でパスワードレス認証を有効にして設定し、FIDO2 仕様と互換性のある生体認証デバイス (YubiKey など) を使用できるようになりました。事前に FIDO2 トークンを登録し、この登録情報を RHEL IdM、Active Directory、または LDAP ストアのユーザーアカウントに保存する必要があります。RHEL は、libfido2
ライブラリーを使用して FIDO2 の互換性を実装していますが、現在は USB ベースのトークンのみをサポートしています。
Identity Management API が完全にサポートされるようになる
RHEL 9.3 以降、Identity Management (IdM) API が完全にサポートされる機能になりました。
IdM API が拡張されて API コマンドの複数のバージョンが有効になった場合でも、ユーザーは既存のツールとスクリプトを使用できます。これらの機能拡張により、コマンドの動作が互換性のない方法で変更されることはありません。これには次の利点があります。
- 管理者は、管理しているクライアントではなくサーバー上で、IdM の以前のバージョンもしくは最近のバージョンを使用できます。
- サーバーで IdM のバージョンを変更しても、開発者は特定バージョンの IdM コールを使用できます。
たとえば、一方が機能の新しいオプションを導入した新しいバージョンを使用している場合でも、サーバーとの通信は可能です。
- 注記
- IdM API は JSON-RPC インターフェイスを提供しますが、このタイプのアクセスはサポートされていません。Red Hat では、代わりに Python を使用して API にアクセスすることを推奨します。Python を使用すると、サーバーからのメタデータの取得などの重要な部分が自動化され、使用可能なすべてのコマンドをリスト表示できるようになります。
Identity Management インストールパッケージがモジュール解除される
RHEL 8 以前では、IdM パッケージはモジュールとして配布されていたため、ストリームを有効にして、目的のインストールに対応するプロファイルをインストールする必要がありました。IdM インストールパッケージは、RHEL 9 でモジュール解除されているため、次の dnf コマンドを使用して IdM サーバーをインストールできます。
統合 DNS サービスがないサーバーの場合は、次のコマンドを実行します。
# dnf install ipa-server
統合 DNS サービスがあるサーバーの場合は、次のコマンドを実行します。
# dnf install ipa-server ipa-server-dns
SSSD 暗黙的なファイルプロバイダードメインが、デフォルトで無効化される
/etc/shadow
などのローカルファイルからユーザー情報を取得し、/etc/groups
からのグループ情報をグループ化する SSSD 暗黙的 files
プロバイダードメインが、デフォルトで無効になりました。
SSSD を使用してローカルファイルからユーザーおよびグループ情報を取得するには、次のコマンドを実行します。
SSSD を設定します。以下のいずれかのオプションを選択します。
sssd.conf
設定ファイルでid_provider=files
を使用して、ローカルドメインを明示的に設定します。[domain/local] id_provider=files ...
sssd.conf
設定ファイルでenable_files_domain=true
オプションを設定して、files
プロバイダーを有効にします。[sssd] enable_files_domain = true
ネームサービススイッチを設定します。
# authselect enable-feature with-files-provider
ユーザー情報のキャッシュと同期を復元するために、シンボリックリンクを作成して、
shadow-utils
とsssd_cache
の統合を有効にします。# ln -s /usr/sbin/sss_cache /usr/sbin/sss_cache_shadow_utils
FIPS 140-3 準拠のキー暗号化を有効にする KDC の新しいレルム設定テンプレート
今回の更新により、/var/kerberos/krb5kdc/kdc.conf
ファイルに新しい EXAMPLE.COM
レルム設定の例が提供されます。これにより、次の 2 つの変更が行われます。
-
FIPS 140-3 準拠の
AES HMAC SHA-2
ファミリーが、キー暗号化でサポートされるタイプのリストに追加されました。 -
KDC マスターキーの暗号化タイプが
AES 256 HMAC SHA-1
からAES 256 HMAC SHA-384
に切り替えられます。
この更新は、スタンドアロンの MIT レルムに関するものです。RHEL Identity Management で Kerberos Distribution Center (KDC) 設定を変更しないでください。
新しいレルムには、新しい設定テンプレートを使用することを推奨します。テンプレートは、すでにデプロイされているレルムには影響しません。テンプレートに従ってレルムの設定をアップグレードすることを計画している場合は、次の点を考慮してください。
マスターキーをアップグレードするには、KDC 設定の設定を変更するだけでは不十分です。MIT Kerberos のドキュメント に記載されているプロセスに従います。
AES HMAC SHA-2
ファミリーをキー暗号化のサポートされているタイプに追加しても、KDC 内の既存のエントリーに影響しないため、常に安全です。キーは、新しいプリンシパルを作成するとき、または認証情報を更新するときのみに生成されます。この新しいタイプのキーは、既存のキーに基づいて生成できないことに注意してください。これらの新しい暗号化タイプを特定のプリンシパルで使用できるようにするには、認証情報を更新する必要があります。つまり、サービスプリンシパルのキータブも更新する必要があります。
プリンシパルが AES HMAC SHA-2
キーを備えてはならない唯一のケースは、Active Directory (AD) クロスレルム ticket-granting ticket (TGT) のものです。AD は RFC8009 を実装していないため、AES HMAC SHA-2
暗号化タイプファミリーを使用しません。したがって、AES HMAC SHA-2
で暗号化されたクロスレルム TGT を使用するクロスレルム TGS-REQ は失敗します。MIT Kerberos クライアントが AD に対して AES HMAC SHA-2
を使用しないようにする最善の方法は、AD クロスレルムプリンシパルに AES HMAC SHA-2
キーを提供しないことです。これを行うには、AD ですべてサポートされているキー暗号化タイプの明示的なリストを使用して、クロスレルム TGT エントリーを作成してください。
kadmin.local <<EOF add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[MIT realm]@[AD realm] add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[AD realm]@[MIT realm] EOF
MIT Kerboros クライアントが AES HMAC SHA-2
暗号化タイプを使用するようにするには、これらの暗号化タイプをクライアントと KDC 設定の両方で permitted
に設定する必要もあります。RHEL では、この設定は crypto-policy システムによって管理されます。たとえば、RHEL 9 では、DEFAULT
暗号化ポリシーを使用するホストは AES HMAC SHA-2
および AES HMAC SHA-1
で暗号化されたチケットを許可しますが、FIPS
暗号化ポリシーを使用するホストは AES HMAC SHA-2
のみを受け入れます。
SSSD マルチスレッドパフォーマンスの向上
以前は、SSSD は、Red Hat Directory Server や Identity Management などのマルチスレッドアプリケーションからの並列リクエストをシリアル化していました。RHEL 9.1 以降では、nss
や pam
などの SSSD クライアントライブラリーは、リクエストをシリアル化しなくなりました。そのため、複数のスレッドからのリクエストを並行して実行できるようになり、パフォーマンスが向上しました。
以前のシリアル化の動作を有効にするには、環境変数 SSS_LOCKFREE
を NO
に設定します。
ansible-freeipa
が、ansible-freeipa-collection
サブパッケージ内の Ansible コレクションとして、ロールとモジュールを追加で提供するようになる
新しいコレクションを使用するには、次の手順を実行します。
-
ansible-freeipa-collection
サブパッケージをインストールします。 -
ロールとモジュールの名前に
freeipa.ansible_freeipa
接頭辞を追加します。Ansible の推奨事項に従うには、完全修飾名を使用します。たとえば、ipahbacrule
モジュールを参照するには、freeipa.ansible_freeipa.ipahbacrule
を使用します。
module_defaults
を適用することで、freeipa.ansible_freeipa
コレクションに含まれるモジュールの使用を簡素化できます。