第51章 認証および相互運用性

SSL 上で CA からユーザー証明書をインポートするときの問題

pki user-cert-addコマンドは、CA から直接ユーザー証明書をインポートするオプションを提供します。不適切なクライアントライブラリーの初期化が原因で、コマンドを SSL ポート上で実行すると以下のエラーメッセージが表示され、コマンドの実行に失敗します。
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
この問題を回避するには、pki cert-show コマンドを使用して CA からファイルに証明書をダウンロードします。その後、pki user-cert-add コマンドを使用してそのファイルから証明書をアップロードします。このように対応すると、ユーザー証明書が適切に追加されます。(BZ#1246635)

IdM web UI が Certificates テーブルですべての証明書を 1 つのページに表示

IdM (Identity Management) web UI の Authentication タブにある Certificates テーブルでは、20 エントリーのページサイズ制限が無視されます。21 個以上の証明書があると、ページごとに 20 個の証明書を表示せずに、すべての証明書が 1 つのページに表示されます (BZ#1358836)。

ipa-kra-installipa-ca-install、または ipa-replica-install を使用するとセキュリティー警告が表示される

ipa-kra-installipa-ca-install、および ipa-replica-install ユーティリティーを使用して追加の KRA (Key Recovery Authority) コンポーネント、認証局、またはレプリカをインストールすると以下の警告が表示されます。
SecurityWarning: Certificate has no `subjectAltName`,
falling back to check for a `commonName` for now.
This feature is being removed by major browsers and deprecated by RFC 2818.
このエラーは、サブジェクト識別名 (DN) のコモンネーム (CN) フィールドにサブジェクトホスト名を使用する慣例を廃止している RFC 2818 が原因で発生します。警告が表示されてもこれら 3 つのユーティリティーは正しく実行されるため、警告メッセージを無視してもかまいません (BZ#1358457)。

pam_pkcs11 が 1 つのトークンのみをサポート

opensc および coolkey パッケージの PKCS#11 モジュールはさまざまなタイプのスマートカードをサポートしますが、pam_pkcs11 モジュールは 1 度に 1 つのスマートカードのみをサポートします。そのため、同じ設定で PKCS#15 と CAC トークンを使用できません。この問題を回避するには、以下の 1 つ をインストールします。
  • PKCS#15 および PIV サポート用の opensc パッケージ
  • CAC、Coolkey、および PIV サポート用の coolkey パッケージ (BZ#1367919)

Directory Server が LDAPS で設定されていないと IdM レプリカで ipa-ca-install を使用できない

IdM (Identity Management) レプリカの Directory Server が LDAPS と設定されていないと (ポート 636 上の TLS プロトコルを使用)、そのレプリカで ipa-ca-install ユーティリティーを使用して CA (認証局) をインストールできません。以下のエラーが表示され、インストールに失敗します。
[2/30]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA
instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpsDHYbO' returned non-zero exit status 1
...
この場合、レプリカをインストールすることはできません。以下のオプションの 1 つを選択してください。
  • 代わりにマスターサーバーに CA をインストールする。
  • ipa-ca-install の実行前に手作業でレプリカ上の LDAPS を有効にする。
レプリカ上で LDAPS を有効にするには、以下を行います。
1. /etc/httpd/alias ファイルからサーバー証明書をエクスポートします。
$ pk12util -d /etc/httpd/alias -k /etc/httpd/alias/pwdfile.txt -o temp.p12 -n 'ca1/replica'
ca1/replica を証明書のニックネームに置き換えてください。
2. 信頼チェーンはすでにインポートされたため、証明書から信頼チェーンを削除します。
a. プライベートキーを抽出します。
$ openssl pkcs12 -in temp.p12 -nocerts -nodes -out temp.key
b. パブリックキーを抽出します。
$ openssl pkcs12 -in temp.p12 -nokeys -clcerts -out temp.pem
c. CA 証明書なしで PKCS#12 ファイルを作成します。
$ openssl pkcs12 -export -in temp.pem -inkey temp.key -out repl.p12 -name 'ca1/replica'
ca1/replica を証明書のニックネームに置き換えてください。
3. 作成した証明書を Directory Server の NSSDB データベースにインポートします。
$ pk12util -d /etc/dirsrv/slapd-EXAMPLE-COM -K '' -i repl.p12
4. 一時証明書ファイルを削除します。
$ rm -f temp.p12 temp.key temp.pem repl.p12
5. 以下が含まれる /tmp/enable_ssl.ldif というファイルを作成します。
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: off
-
replace: nsSSLClientAuth
nsSSLClientAuth: allowed
-
replace: nsSSL3Ciphers
nsSSL3Ciphers: default

dn: cn=config
changetype: modify
replace: nsslapd-security
nsslapd-security: on
6. LDAP 設定を変更して SSL を有効にします。
$ ldapmodify -H "ldap://localhost" -D "cn=directory manager" -f /tmp/enable_ssl.ldif -w dm_password
dm_password は Directory Manager のパスワードに置き換えてください。
7. 以下が含まれる /tmp/add_rsa.ldif というファイルを作成します。
dn: cn=RSA,cn=encryption,cn=config
changetype: add
objectclass: top
objectclass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: ca1/replica
nsSSLToken: internal (software)
nsSSLActivation: on
ca1/replica を証明書のニックネームに置き換えてください。
8. エントリーを LDAP に追加します。
$ ldapadd -H "ldap://localhost" -D "cn=directory manager" -f /tmp/add_rsa.ldif -w dm_password
dm_password は Directory Manager のパスワードに置き換えてください。
9. 一時ファイルを削除します。
$ rm -f /tmp/enable_ssl.ldif /tmp/add_rsa.ldif
10. ディレクトリーサーバーを再起動します。
# systemctl restart dirsrv@EXAMPLE-COM.service
この手順の実行後、LDAPS が有効になり、レプリカで ipa-ca-install を実行できるようになります (BZ#1365858)。

外部 CA の IdM へのインストール後、サードパーティーの証明書信頼フラグがリセットされる

外部 CA (認証局) を既存の IdM (Identity Management) ドメインにインストールするために使用される ipa-ca-install --external-caコマンドは、ユーザーが外部 CA に提出する必要がある CSR (証明書署名リクエスト) を生成します。
以前インストールしたサードパーティーの証明書を使用して CSR に署名すると、NSS データベースのサードパーティー証明書信頼フラグがリセットされます。そのため、信頼できる証明書として認識されなくなります。さらに、mod_nss モジュールによって実行されるチェックに失敗し、 httpd サービスが起動しません。このような場合、CA のインストールに失敗し、以下のメッセージが表示されます。
CA failed to start after 300 seconds
この問題を回避するには、上記のメッセージが表示された後にサードパーティーの証明書フラグを以前の状態にリセットし、httpd を再起動します。たとえば、ca1 証明書に C,, 信頼フラグがあった場合は以下を実行します。
# certutil -d /etc/httpd/alias -n 'ca1' -M -t C,,
# systemctl restart httpd.service
これにより、システムが適切な状態に復元されます (BZ#1318616)。

realmd が AD からコンピューターアカウントを削除できない

Red Hat Enterprise Linux は、AD (Active Directory) ドメインメンバーシップのデフォルトのバックエンドとして Samba を使用します。realm joinコマンドで --computer-name オプションを使用してコンピューター名を手動で設定する場合、ドメインから脱退した後に AD からそのアカウントを削除できません。この問題を回避するには、--computer-name オプションを使用せずに、コンピューター名を /etc/realmd.conf ファイルに追加します。例を以下に示します。
[domain.example.com]
computer-name = host_name
このように対応すると、ホストは正常にドメインへ参加し、realm leave --remove コマンドを使用してドメインから脱退するとアカウントが自動的に削除されます (BZ#1370457)。

SSSD が LDAP ツリーから autofs マッピングを管理できない

RFC2307 LDAP スキーマの使用時、SSSD (System Security Services Daemon) が autofs マッピングの誤ったデフォルト値を実装しました。パッチが適用され、スキーマと一致するようデフォルトが修正されました。しかし、以前使用したスキーマ SSSD とのマッピングが含まれる LDAP サーバーに接続するユーザーは autofs 属性を読み込みできません。影響を受けるユーザーは、以下のエラーが /var/log/messages ログファイルに記録されます。
Your configuration uses the autofs provider with schema set to rfc2307 and default attribute mappings. The default map has changed in this release, please make sure the configuration matches the server attributes.
この問題を回避するには、/etc/sssd/sssd.conf ファイルを編集し、既存の属性マッピングを使用するようドメインを設定します。
[domain/EXAMPLE]
...
ldap_autofs_map_object_class   = automountMap
ldap_autofs_map_name           = ou
ldap_autofs_entry_object_class = automount
ldap_autofs_entry_key          = cn
ldap_autofs_entry_value        = automountInformation
この結果、SSSD は属性から autofs マッピングを読み込みできるようになります (BZ#1372814)。

pkispawn の依存関係リストに openssl が含まれない

openssl パッケージがインストールされていない場合、pkispawn ユーティリティーを実行できず、以下のエラーが表示されます。
Installation failed: [Errno 2] No such file or directory
この問題は、pki-core 内に含まれる pki-server パッケージのランタイム依存関係として openssl パッケージが含まれていないため発生します。この問題を回避するには pkispawn の実行前に openssl をインストールします (BZ#1376488)。

多数のユーザーを列挙すると CPU の負荷が高くなり、他の操作が遅くなる

etc/sssd/sssd.conf ファイルに enumerate=true が設定され、LDAP サーバーに多数のユーザー (たとえば 30,000 ユーザー) が存在する場合、以下のようなパフォーマンスの問題が発生します。
  • sssd_be プロセスが CPU リソースの約 99% を消費する。
  • ローカルユーザーとしてのログインやログアウトなど、一部の操作の完了に予想外の時間がかかる。
  • sysdb および timestamp キャッシュで ldbsearch 操作の実行に失敗し、インデックスおよび完全検索の両方に失敗したというエラーが報告される。
これは新たな既知の問題ではなく、以前のリリースの SSSD でも問題が発生することに注意してください (BZ#888739, BZ#1379774)。

スマートカードを使用して GDM を認証できない

スマートカード認証を使用する場合、ログイン名が Kerberos ユーザープリンシパル名 (UPN) であるかを SSSD (System Security Services Daemon) の PAM レスポンダーが検証できません。そのため、ユーザープリンシパル名 (PAM) をログイン名として使用すると gdm-password プラグ可能認証モジュール (PAM) がスマートカード PIN のプロンプトではなくパスワードプロンプトを表示しました。そのため、GNOME ディスプレイマネージャー (GDM) へのスマートカード認証に失敗します (BZ#1389796)。

ユーザー名が大文字または大文字と小文字が混ざっていると ipa passwd コマンドを実行できない

IdM (Identity Management) 4.4.0 ではすべてのコマンドでユーザープリンシパルの処理が統一されましたが、一部のコマンドは完全に変更されませんでした。そのため、ユーザー名が大文字であったり大文字と小文字が混ざっていると、ipa passwd コマンドの実行に失敗します。この問題を回避するには、ipa passwd コマンドを使用するときにユーザー名に小文字のみを使用するようにします (BZ#1375133)。

IdM web UI が失効した証明書の状態を正しく認識しない

現在、IdM (Identity Management) web UI は証明書の失効の有無を判断することができません。そのため、以下のような問題が発生します。
  • ユーザー、サービス、またはホスト詳細ページから証明書を見ると、Revoked サインが表示されません。
  • 詳細ページで Revoke アクションが使用可能になります。すでに失効した証明証を失効しようとするとエラーダイアログが表示されます。
  • Certificate Hold (失効の理由 6) により、証明書が失効しても Remove Hold ボタンが常に無効化されます (BZ#1371479)。

SSSD が AD からの sudoUser 属性の値に小文字のみを適用

SSSD (System Security Services Daemon) が AD (Active Directory) から sudo ルールを取得する場合、 sudoUser 属性の大文字と小文字がルールが割り当てられたユーザーの samAccountName 属性と一致する必要があります。Red Hat Enterprise Linux 7.3 での不具合により sudoUser 属性が小文字の値のみと一致します。この問題を回避するには、sudoUser 属性の値を小文字に変更します。このように対応すると、sudoUser ルールは適切に適用されます (BZ#1380436)。

ipa-client および ipa-admintools パッケージを更新できない

Red Hat Enterprise Linux 7.2 から Red Hat Enterprise Linux 7.3 へのアップグレード中、ipa-client および ipa-admintools パッケージの更新に失敗することがあります。この問題を回避するには、Red Hat Enterprise Linux 7.3 にアップグレードする前に ipa-client および ipa-admintools をアンインストールし、その後これらのパッケージの新しいバージョンをインストールします (BZ#1390565)。

SSSD をアップグレードすると、sssd プロセスが終了することがある

sssd プロセスが予想よりも長い時間アクションを実行する場合は、内部ウォッチドッグプロセスが処理を終了します。 ただし、sssd プロセスは再び起動されません。この問題は通常、SSSD データベースに大量のエントリーが含まれる場合に、低速のシステムで SSSD をアップグレードしようとするときに発生します。
この問題を回避するには、以下の手順を実行します。
1. 中央認証サーバーが利用可能であることを確認します。これにより、ユーザーは次の手順で SSSD キャッシュを削除する前に認証することができます。
2. アップグレードする前に sss_cache ユーティリティーを使用して SSSD キャッシュを削除します。
この既知の問題に対する修正は、次のアップデートで利用できます (BZ#1392441)。

bind-dyndb-ldap スキーマエラーのためディレクトリーサーバーが失敗

ID 管理に含まれる bind-dyndb-ldap LDAP スキーマのバージョンは構文エラーを含み、1 つの属性の説明がありません。ユーザーがこのスキーマのバージョンを使用する場合、ディレクトリーサーバーコンポーネントは起動に失敗します。結果的に、正しくない構文についてユーザーに通知するエラーメッセージがジャーナルに記録されます。
この問題を回避するには、以下の手順を実行します。
  1. 修正されたスキーマファイルをアップストリーム git.fedorahosted.org リポジトリーから取得します。
    # wget https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/doc/schema.ldif?id=17711141882aca3847a5daba2292bcbcc471ec63 -O /usr/share/doc/bind-dyndb-ldap-10.0/schema.ldif
  2. 修正されたスキーマファイルをディレクトリーサーバーのインスタンス設定フォルダーにコピーします。
    # cp /usr/share/doc/bind-dyndb-ldap-10.0/schema.ldif /etc/dirsrv/slapd-[EXAMPLE-COM]/schema/[SCHEMA_FILE_NAME].ldif
  3. ディレクトリーサーバーを再起動します。
    # systemctl restart dirsrv.target
(BZ#1413805)