第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 つのページにすべての証明書を表示します。
Identity Management (IdM) Web UI の Authentication タブで利用可能な Certificates テーブルは、20 エントリーのページサイズ制限を無視します。20 を超える証明書が利用可能な場合、この表には、ページごとに 20 個の証明書のみを表示するのではなく、1 ページにすべての証明書が表示されます。(BZ#1358836)
ipa-kra-install、ipa-ca-install、または ipa-replica-installを使用する場合のセキュリティー警告
ipa-kra-install ユーティリティー、ipa-ca-install ユーティリティー、および ipa-replica-install ユーティリティーを使用して、追加の鍵回復機関(KRA)コンポーネント、認証局、またはレプリカをインストールすると、以下の警告が表示されます。
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.
このエラーは、RFC 2818 が原因で発生します。これは、サブジェクト識別名(DN)コモンネーム(CN)フィールドにサブジェクトホスト名を取るプラクティスを非推奨にします。ただし、3 つのユーティリティーは成功します。したがって、警告メッセージは無視できます。(BZ#1358457)
pam_pkcs11 は 1 つのトークンのみをサポートします。
opensc および coolkey パッケージの PKCS#11 モジュールは、さまざまなタイプのスマートカードに対応します。ただし、pam_pkcs11 モジュールは、一度に 1 つだけサポートします。したがって、同じ設定を使用して PKCS#15 および CAC トークンを使用することはできません。この問題を回避するには、以下のいずれかをインストールします。
- PKCS#15 および PIV サポート用の opensc パッケージ
- CAC、Coolkey、および PIV サポートの coolkey パッケージ(BZ# 1367919)
Directory Server が LDAPS で設定されていない場合に、IdM レプリカで ipa-ca-install を使用すると失敗する
レプリカの Directory Server が LDAPS で設定されていない場合（ポート 636 で TLS プロトコルを使用して）Identity Management (IdM)レプリカに
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 ...
この状況でレプリカをインストールすることはできません。回避策として、以下のいずれかのオプションを選択します。
- 代わりに、マスターサーバーに 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)を既存の Identity Management (IdM)ドメインにインストールするために使用される 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 は、Active Directory (AD)ドメインメンバーシップのデフォルトバックエンドとして 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 スキーマの使用時に、System Security Services Daemon (SSSD)が 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
この問題は、openssl パッケージが pki-core パッケージに含まれる pki-server パッケージのランタイム依存関係として含まれていないために発生します。回避策として、
pkispawn を実行する前に openssl をインストールします。(BZ#1376488)
多数のユーザーを列挙すると、CPU の負荷が高く、他の操作が遅くなります。
etc/sssd/sssd.conf ファイルで enumerate=true を設定し、多数のユーザー（たとえば、30,000 ユーザー）が LDAP サーバーにある場合、パフォーマンスの問題が発生します。
sssd_beプロセスは、CPU リソースのほぼ 99% を消費します。- ローカルユーザーとしてログインしたりログアウトしたりするなどの特定の操作は、完了するまでに長い時間がかかる
sysdbでldbsearch操作を実行し、タイムスタンプのキャッシュがインデックス化および完全な検索が失敗したことを示すエラーで失敗する
GDM がスマートカードを使用した認証に失敗する
スマートカード認証を使用する場合、System Security Services Daemon (SSSD)の PAM レスポンダーは、ログイン名が Kerberos ユーザープリンシパル名(UPN)であるかどうかを確認しません。これにより、ユーザープリンシパル名(UPN)をログイン名として使用する場合、
gdm-password のプラグ可能な認証モジュール(PAM)は、スマートカードの PIN プロンプトではなくパスワードプロンプトを表示します。その結果、GNOME ディスプレイマネージャー(GDM)へのスマートカードの認証に失敗します。(BZ#1389796)
大文字または混合のケースユーザー名を使用する場合、ipa passwd コマンドが失敗する
Identity Management (IdM) 4.4.0 では、すべてのコマンドでユーザープリンシパルの統合処理が導入されました。ただし、一部のコマンドは完全に変換されませんでした。その結果、ユーザー名で大文字または混合の大文字を使用すると、ipa passwd コマンドが失敗します。この問題を回避するには、ipa passwd コマンドを使用する場合は、ユーザー名の小文字のみを使用します。(BZ#1375133)
IdM Web UI が、失効した証明書のステータスを正しく認識しない
Identity Management (IdM)の Web UI は、現在、証明書が取り消されたかどうかを判断できません。これにより、以下のようになります。
- ユーザー、サービス、またはホストの詳細ページから証明書を表示すると、
Revoked記号は表示されません。 Revokeアクションは、詳細ページで引き続き利用できます。すでに取り消された証明書を取り消すと、エラーダイアログが表示されます。Remove Holdボタンは、証明書の保留（失効理由 6）により証明書が取り消された場合でも常に無効になります。(BZ#1371479)
SSSD は、小文字で AD の sudoUser 属性の値のみを適用します。
以前は、System Security Services Daemon (SSSD)が Active Directory (AD)から sudo ルールを取得すると、
sudoUser 属性は、ルールが割り当てられたユーザーの samAccountName 属性の正確なケースに一致する必要がありました。Red Hat Enterprise Linux 7.3 のリグレッションにより、sudoUser 属性は小文字の値にのみ一致するようになりました。この問題を回避するには、sudoUser 属性値の名前を小文字に変更します。回避策として、sudo ルールが正しく適用されます。(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 スキーマエラーが原因で Directory Server が失敗する
Identity Management に含まれる
bind-dyndb-ldap LDAP スキーマのバージョンには構文エラーが含まれ、1 つの属性の説明がありません。ユーザーがこのバージョンのスキーマを使用する場合、Directory Server コンポーネントは起動に失敗します。その結果、エラーメッセージがジャーナルに記録され、間違った構文についてユーザーに通知します。
この問題を回避するには、以下を実行します。
- アップストリームの
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
- 修正されたスキーマファイルを Directory Server のインスタンス設定フォルダーにコピーします。
# cp /usr/share/doc/bind-dyndb-ldap-10.0/schema.ldif /etc/dirsrv/slapd-[EXAMPLE-COM]/schema/[SCHEMA_FILE_NAME].ldif
- Directory Server を再起動します。
# systemctl restart dirsrv.target
(BZ#1413805)
