第13章 Identity Management

DNS over TLS (DoT) を使用して暗号化された DNS を、RHEL 10 の Identity Management (IdM) デプロイメントのテクノロジープレビューとして利用できます。DNS クライアントと IdM DNS サーバー間のすべての DNS クエリーと応答を暗号化できます。

この機能を使い始めるには、IdM サーバーとレプリカに ipa-server-encrypted-dns パッケージをインストールし、IdM クライアントに ipa-client-encrypted-dns パッケージをインストールします。管理者は、インストール中に --dns-over-tls オプションを使用して DoT を有効にできます。

IdM は、Unbound をローカルキャッシュリゾルバーとして設定し、BIND を DoT 要求を受信するように設定します。この機能は、コマンドラインインターフェイス (CLI) および IdM の非対話型インストールを通じて利用できます。

IdM サーバー、レプリカ、クライアント、および統合 DNS サービスのインストールユーティリティーに次のオプションが追加されました。

デフォルトでは、IdM は、暗号化されていない DNS へのフォールバックを許可する、relaxed DNS ポリシーを使用します。新しい --dns-policy オプションを enforced 設定で使用することで、暗号化のみの通信を強制できます。

また、新しい DoT オプションを指定した ipa-dns-install を使用して統合 DNS サービスを再設定することにより、既存の IdM デプロイメントで DoT を有効にすることもできます。

Ansible を使用して、DNS クライアントと Identity Management (IdM) DNS サーバー間のすべての DNS クエリーと応答を暗号化できます。DNS over TLS (DoT) による暗号化された DNS は、RHEL 10 から IdM 環境でテクノロジープレビューとして利用可能になりました。RHEL 10.1 では、この機能は freeipa.ansible_freeipa コレクションのテクノロジープレビューとして利用できます。

ansible-freeipa を使用して IdM のデプロイ時に DoT を有効にするには、次のオプションを使用します。

さらに、dns_policy 変数を設定して DoT のみの通信を強制し、暗号化されていない DNS へのフォールバックを許可するデフォルトの動作をオーバーライドすることもできます。

SSSD は、DNS-over-TLS (DoT) を使用してすべての動的 DNS (dyndns) クエリーを実行することをサポートするようになりました。IP アドレスが変更された際に、Identity Management (IdM) や Active Directory サーバーなどの DNS レコードを安全に更新できます。この機能を有効にするには、bind9.18-utils パッケージから nsupdate ツールをインストールする必要があります。

sssd.conf ファイルで次の新しいオプションを使用して、DoT を有効にし、セキュアな DNS 更新用のカスタム証明書を設定できます。

これらのオプションの詳細は、システムの sssd-ad(5) および sssd-ad(5) man ページを参照してください。

RHEL 10 では、ansible-freeipa rpm は freeipa.ansible_freeipa コレクションのみをインストールします。

新しいコレクションを使用するには、ロールとモジュールの名前に freeipa.ansible_freeipa 接頭辞を追加します。Ansible の推奨事項に従うには、完全修飾名を使用します。たとえば、ipahbacrule モジュールを参照するには、freeipa.ansible_freeipa.ipahbacrule を使用します。

module_defaults を適用することで、freeipa.ansible_freeipa コレクションの一部であるモジュールの使用を簡素化できます。

Hardware Security Modules (HSM) が、Identity Management (IdM) で完全にサポートされるようになりました。IdM 認証局 (CA) および Key Recovery Authority (KRA) のキーペアと証明書を HSM に保存できます。これにより、秘密鍵マテリアルに物理的なセキュリティーが追加されます。

IdM は、HSM のネットワーク機能を利用してマシン間でキーを共有し、レプリカを作成します。HSM は、ほとんどの IPA 操作に目に見える影響を与えることなく、追加のセキュリティーを提供します。低レベルのツールを使用する場合、証明書とキーの処理方法は異なりますが、ほとんどのユーザーはシームレスに使用できます。

以下が必要です。

HSM にキーが保存されている CA または KRA をインストールするには、トークン名と PKCS#11 ライブラリーへのパスを指定する必要があります。以下に例を示します。

ipa-server-install -r EXAMPLE.TEST -U --setup-dns --allow-zone-overlap --no-forwarders -N --auto-reverse --random-serial-numbers --token-name=HSM-TOKEN --token-library-path=/opt/nfast/toolkits/pkcs11/libcknfast.so --setup-kra

RHEL 10 では、IdM の新しいレプリカで、期限切れの証明書の自動削除がデフォルトで有効になります。このための前提条件は、RSNv3 を使用して証明書のランダムなシリアル番号を生成することです。これもデフォルトで有効化されるようになりました。

その結果、証明書はランダムなシリアル番号で作成されようになり、有効期限が切れると、デフォルトの保持期間である有効期限後 30 日が経過すると自動的に削除されます。

以前は、Directory Server は Berkeley Database (BDB) を使用してインスタンスを作成していました。ただし、389-ds-base で使用される BDB バージョンを実装する libdb ライブラリーは、RHEL 10 では利用できなくなりました。

RHEL 10 以降、389-ds-base パッケージは、デフォルトでデータベースタイプとして Lightning Memory-Mapped Database (LMDB) を使用します。この変更は、以下に影響があります。

LMDB では、新しい cn=mdb,cn=config,cn=ldbm database,cn=plugins,cn=config 設定エントリーの下に保存される次の設定パラメーターが導入されています。

新しい LMDB 設定に加えて、nsslapd-db-home-directory データベース設定パラメーターも引き続き使用できます。

BDB インスタンスは Directory Server ではサポートされなくなりました。したがって、すべてのインスタンスを LMDB に移行します。

この更新前は、データベース内のサブツリー間でエントリーを移動できないように Directory Server を設定できました。安定性の問題のため、この機能は削除されました。したがって、nsslapd-subtree-rename-switch パラメーターは存在しなくなりました。

その結果、サブツリー間でのエントリーの移動を無効にできなくなりました。代替策として、アクセス制御命令 (ACI) を作成することにより、エントリーの移動を無効にできます。

RHEL 10 では、authselect-libs パッケージが /etc/nsswitch.conf と、一部の PAM 設定 (/etc/pam.d/ 内の system-auth、password-auth、smartcard-auth、fingerprint-auth、postlogin など) を所有するようになりました。これらのファイルの所有権は、authselect-libs パッケージに移行されました。以前は、/etc/nsswitch.conf は glibc パッケージが所有し、PAM 設定ファイルは pam パッケージが所有していました。authselect は pam パッケージに必要なので、アンインストールできません。

以前の RHEL バージョンからのシステムアップグレードの場合:

特別な設定が必要な場合は、カスタムの authselect プロファイルを作成します。システムに合わせてカスタムプロファイルを最新の状態に保つには、手動で更新する必要があることに注意してください。

authselect の使用をオプトアウトできます:

# authselect opt-out

RHEL 10.0 で SSSD ファイルプロバイダーが削除されたため、SSSD に依存せずにローカルユーザー管理を処理するための新しい authselect local プロファイルが導入されました。local プロファイルは以前の minimal プロファイルを置き換え、sssd プロファイルの代わりに、新しいインストールのデフォルトの authselect プロファイルになります。

アップグレード中、authselect ユーティリティーは既存の設定を minimal から local プロファイルに自動的に移行します。

さらに、sssd authselect プロファイルが更新され、with-files-domain および with-files-access-provider オプションが削除され、これらのオプションを介したローカルユーザーアカウントの直接処理がされなくなりました。これらのオプションに依存していた場合は、files provider ではなく proxy provider を使用するように SSSD 設定を更新する必要があります。

sssd プロファイルは、SSSD によって管理されるユーザーのセッション記録を有効にする --with-tlog オプションをサポートするようになりました。

RHEL 10.1 以降、SSSD が新しいオプションである ldap_read_rootdse を提供するようになりました。これは、SSSD が LDAP サーバーから Root Directory Service Entry (RootDSE) を読み取る方法を制御するためのオプションです。デフォルトでは、SSSD はユーザーが認証する前に RootDSE を匿名で読み取ろうとします。しかし、このデフォルトの動作は、厳格なセキュリティーポリシーと競合する場合があります。厳格なセキュリティーポリシーは、通常、LDAP サーバーへのすべての匿名バインドを制限します。

この動作を管理するには、ldap_read_rootdse オプションを authenticated に設定して、ユーザー認証が成功した後にのみ SSSD が RootDSE を読み取るように指示するか、このオプションを never に設定して、SSSD による読み取りを完全に防止してください。

RHEL 10.1 で、SSSD のスマートカード認証が強化され、複数の PKCS#11 トークンが同時に挿入される環境で認証を処理できるようになりました。これにより、特に複数のユーザーアカウントが必要で、それぞれが異なる特権を持ち、多くの場合個別の PKI トークンに関連付けられている STIG 準拠の環境での認証が改善されます。

以前は、最初にチェックされたトークンに適合する証明書が含まれていない場合、SSSD が認証に失敗することがありました。これは、SSSD が他の利用可能なトークンにある適切な証明書を続けて検索していなかったためです。この更新により、SSSD は挿入されたすべての PKCS#11 トークンをスキャンして適合する認証証明書を探すようになりました。その結果、ユーザーが正常に認証できるようになりました。

FIPS 140-3 に準拠した Red Hat Enterprise Linux (RHEL) 10 のデフォルトの FIPS 暗号化ポリシーでは、AES HMAC-SHA1 暗号化タイプの鍵導出機能の使用が許可されていません。

この制約により、SHA-1 ベースの Kerberos マスターキーを使用する既存の IdM 環境に、FIPS モードの RHEL 10 Identity Management (IdM) レプリカを追加することはできません。RHEL 9 と RHEL 10 はどちらもデフォルトで AES HMAC-SHA2 を使用しますが、IdM のデプロイメントが RHEL 8.6 以前で最初に初期化された場合は、SHA-1 マスターキーが使用される可能性があります。

RHEL 10 では、FreeRADIUS の提供内容に以下の外部認証モジュールは含まれていません。

削除されたモジュールの代替は、Fedora プロジェクトなどのコミュニティーでサポートされているパッケージで見つけることができます。

さらに、freeradius パッケージのサポートは、以下のユースケースに限定されています。

これらの削除とは対照的に、Red Hat は FreeRADIUS を使用して以下の外部認証モジュールのサポートを強化しています。

これらのインテグレーションオプションに重点を置くことは、Red Hat IdM の戦略的方向性に一致します。