検索

A.3. IdM サーバーの問題

download PDF

A.3.1. レプリカの起動時に、389 Directory Server ログには SASL、GSS-API、および Kerberos エラーがあります。

レプリカが起動すると、389 Directory Server ログに一連の SASL バインドエラーが記録され、認証情報を見つけられないため、GSS-API 接続が失敗したと報告されます。
slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ...
レプリカは /tmp/krb5cc_496 の認証情報キャッシュを探しており (496 は 389 Directory Server のユーザー ID)、これを見つけられません。
また、「サーバーがホストプリンシパルの Kerberos 認証情報を取得できなかった」というメッセージが表示される場合もあります。
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)
このエラーは、389 Directory Server インスタンスが Kerberos 認証情報キャッシュを読み込む方法とタイミングの両方に関連します。
389 Directory Server 自体は複数の異なる認証メカニズムをサポートしますが、Identity Management は Kerberos 接続に GSS-API のみを使用します。Identity Management の 389 Directory Server インスタンスは、Kerberos 認証情報キャッシュをメモリーに保持します。IdM レプリカが停止した場合など、389 Directory Server プロセスが終了すると、認証情報キャッシュが破棄されます。
また、389 Directory Server は KDC のプリンシパル情報のバックエンドストレージとして使用されます。
レプリカが再起動すると、KDC の情報を提供し、KDC サーバーを起動するため、389 Directory Server インスタンスが最初に起動します。この開始順序は、GSS-API および Kerberos 接続エラーの原因となります。
389 Directory Server は GSS-API 接続を開こうとしますが、認証情報キャッシュがなく、KDC が起動していないため、GSS 接続は失敗します。同様に、ホストの認証情報の取得を試みると失敗します。
これらのエラーは一時的なものです。389 Directory Server は、KDC の起動後に GSS-API 接続を再使用し、認証情報キャッシュを持ちます。389 Directory Server のログは bind resumed メッセージを記録します。
これらの起動時の GSS-API 接続の失敗は、接続が正常に確立されていれば無視できます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.