A.3. IdM サーバーの問題
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 接続の失敗は、接続が正常に確立されていれば無視できます。
