7.9. Identity Management
Certmonger は、登録に challengePassword が必要な場合に、AD を使用して SCEP 証明書を自動的に更新できるようになりました。
以前は、certmonger から Active Directory (AD) Network Device Enrollment Service (NDES) サーバーに送信された SCEP 証明書の更新要求には、証明書を最初に取得するために使用された challengePassword が含まれていました。ただし、AD は challengePassword をワンタイムパスワード (OTP) として扱います。その結果、更新リクエストは拒否されました。
この更新により、challenge_password_otp オプションが certmonger に追加されます。このオプションを有効にすると、certmonger が SCEP 更新要求とともに OTP を送信できなくなります。管理者は、AD レジストリーの HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP サブキーに値 1 の DisableRenewalSubjectNameMatch エントリーも追加する必要があります。この変更により、AD は署名者証明書と要求された証明書のサブジェクト名を一致させる必要がなくなりました。その結果、SCEP 証明書の更新は成功します。
SCEP 更新が機能するように certmonger と AD サーバーを設定するには、次のようにします。
-
AD サーバーで
regeditを開きます。 -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP サブキーに、新しい 32 ビットの REG_DWORD エントリー
DisableRenewalSubjectNameMatchを追加し、その値を1に設定します。 certmongerが実行されているサーバーで、/etc/certmonger/certmonger.confファイルを開き、次のセクションを追加します。[scep] challenge_password_otp = yes
certmonger を再起動します。
# systemctl restart certmonger
2 番目の FreeRADIUS サーバーが使用できない場合でも、FreeRADIUS プロキシーサーバーは動作を停止しなくなりました
FreeRADIUS サーバーがプロキシーサーバーとして設定されている場合、要求メッセージを別の FreeRADIUS サーバーに転送します。以前は、これら 2 つのサーバー間の接続が中断された場合、FreeRADIUS プロキシーサーバーは機能しなくなりました。この修正により、FreeRADIUS プロキシーサーバーは、他のサーバーが使用可能になったときに接続を再確立できるようになりました。
PBKDF2 ハッシュパスワードを使用した FIPS モードの Directory Server への認証が期待どおりに機能するようになりました。
Directory Server が FIPS (Federal Information Processing Standard) モードで実行している場合は、PK11_ExtractKeyValue() 機能を使用できません。これにより、パスワードベースの鍵派生機能 2 (PBKDF2) のハッシュパスワードを持つユーザーは、FIPS モードが有効になっているときにサーバーを認証できませんでした。今回の更新で、Directory Server が PK11_Decrypt() 機能を使用してパスワードハッシュデータを取得するようになりました。その結果、FIPS モードでの Directory Server への認証が、PBKDF2 ハッシュパスワードを使用するユーザーに対して機能するようになりました。
SSSD キャッシュが SSSD ユーザーとして tmpfs にマウントされている場合、SSSD のソケットアクティベーションは成功します。
以前は、sssd ユーザーが /var/lib/sss/db/config.ldb SSSD 設定ファイルを所有していなかったため、SSSD キャッシュが tmpfs 一時ファイルシステムにマウントされている場合は、SSSD のソケットアクティベーションが失敗していました。今回の修正により、SSSD は sssd ユーザーとして config.ldb ファイルを作成し、ソケットのアクティベーションが成功するようになりました。/var/lib/sssd/db/ SSSD ディレクトリーを tpmfs にマウントした場合は、sssd ユーザーとして再マウントして、SSSD がその場所に config.ldb ファイルを作成できるようにする必要があります。
以下の手順は、Identity Management でのパフォーマンスのチューニング ガイドの手順に従ってパフォーマンスを高速化するために SSSD キャッシュを tmpfs にマウントした場合にのみ実行してください。標準的な状況では、Red Hat は SSSD キャッシュのデフォルトの場所である標準ディスクストレージを代わりに使用することを推奨します。
手順
/var/lib/sss/dbがマウントポイントであることを確認します。# mount -t tmpfs | grep /var/lib/sss/db tmpfs on /var/lib/sss/db type tmpfs (rw,relatime,rootcontext=system_u:object_r:sssd_var_lib_t:s0,seclabel,size=307200k,mode=700)
/var/lib/sss/dbが有効なマウントポイントである場合は、rootユーザーが所有しているかどうかを確認します。# ls -l /var/lib/sss | grep db drwx------. 2 *root root* 40 Jul 26 04:48 db
dbディレクトリーがマウントポイントであり、rootユーザーが所有している場合は、/etc/fstabファイルの対応するエントリーにuid=sssd,gid=sssdを追加して、SSSD ユーザーとしてマウントします。tmpfs /var/lib/sss/db/ tmpfs size=300M,mode=0700,*uid=sssd,gid=sssd*,rootcontext=system_u:object_r:sssd_var_lib_t:s0 0 0
ディレクトリーを再マウントし、SSSD サービスを再起動します。
# systemctl stop sssd # umount /var/lib/sss/db # mount /var/lib/sss/db # systemctl start sssd
検証
/var/lib/sss/dbディレクトリーがsssdユーザーによって所有されていることを確認します。# ls -l /var/lib/sss | grep db drwx------. 2 sssd sssd 160 Jul 26 05:00 db
(BZ#2108316)
