11.2.28. SSSD のトラブルシューティング

11.2.28.1. SSSD ドメイン用のデバッグログの設定

ドメインはそれぞれのデバッグログレベルを設定します。ログレベルを上げると、SSSD やドメイン設定での問題についての情報をより多く提供できます。
ログレベルを変更するには、追加のログを作成する sssd.conf ファイルで各セクションの debug_level パラメーターを設定します。以下に例を挙げます。 
[domain/LDAP]
enumerate = false
cache_credentials = true
debug_level = 9

表11.13 デバッグログレベル

レベル 詳細
0 致命的な失敗。SSSD の起動を妨げたり、SSSD の実行を停止させるもの。
1 重大な失敗。SSSD を強制終了するわけではないが、少なくとも 1 つのメジャーな機能が適切に動作していないことを示すエラー。
2 深刻な失敗。特定の要求や操作が失敗したことを告げるエラー。
3 マイナーな失敗。2 のオペレーション失敗を引き起こしかねないエラー。
4 設定セッティング
5 機能データ
6 操作関数のメッセージを追跡します。
7 内部制御関数のメッセージを追跡します。
8 関心のある可能性がある関数-内部変数のコンテンツ。
9 非常に低いレベルの追跡情報。

注記

SSSD 1.8 よりも古いバージョンでは、デバッグログレベルは [sssd] セクションでグローバル設定が可能です。各ドメインとサービスでは、それぞれのデバッグログレベルを設定する必要があります。
SSSD 設定ファイルのそれぞれの設定エリアにグローバル SSSD のデバッグログレベルをコピーするには、sssd_update_debug_levels.py スクリプトを使います。 
python -m SSSDConfig.sssd_update_debug_levels.py

11.2.28.2. SSSD ログファイルのチェック

SSSD は、その運用に関する情報を報告するために多くのログファイルを使用し、それを /var/log/sssd/ ディレクトリに配置します。SSSD は各ドメイン用のログファイルだけでなく、sssd_pam.log ファイルと sssd_nss.log ファイルも作製します。
更には、/var/log/secure ファイルは認証の失敗とその失敗の理由もログします。

11.2.28.3. SSSD 設定に伴う問題

問： SSSD の起動失敗
問： 'id' のあるグループや 'getent group' のあるグループメンバーが見当たりません。
問： LDAP に対する認証が失敗します。
問： 非標準ポートでの LDAP サーバーへの接続が失敗します。
問： NSS がユーザー情報提供に失敗します。
問： NSS が、誤ったユーザー情報を返す。
問： ローカルの SSSD ユーザー用のパスワード設定で、パスワードの入力が 2 回要求される。
問： Identity Management (IPA) プロバイダーで sudo ルールを使おうとしていますが、sudo が適切に設定されているのに sudo ルールが見つかりません。
問： 大きなディレクトリーでは パスワードルックアップ は、要求 1 件あたり数秒かかります。どうしたら改善できますか？
問： Active Directory ID プロバイダーは sssd.conf ファイルで適切に設定されているのに、SSSD は接続に失敗し、GSS-API エラーがでます。
問： SSSD を中央認証に設定しましたが、Firefox や Adobe などいくつかのアプリケーションが起動しません。
問： SSSDは、削除した自動マウントの場所を示しています。
問：
SSSD の起動失敗
答：
SSSD はデーモンが開始する前にすべての要求されたエントリを使用して設定ファイルが適切にセットアップされることを要求します。
  • SSSD には、サービスが開始する前に、少なくとも 1 つのドメインが適切に設定されていることが必要です。このようなドメインがない場合には、SSSD の起動を試みた際に、ドメインが設定されていないと言うエラーを返します: 
    # sssd -d4

[sssd] [ldb] (3): server_sort:Unable to register control with rootdse!
[sssd] [confdb_get_domains] (0): No domains configured, fatal error!
[sssd] [get_monitor_config] (0): No domains configured.
    /etc/sssd/sssd.conf のファイルを編集して、少なくとも１つのドメインを作成します。
  • SSSD には、起動する前に、少なくとも 1 つの利用可能なサービスプロバイダーが必要です。問題がサービスプロバイダーの設定にある場合、サービスが設定されていないことを示すエラーメッセージが表示されます: 
    [sssd] [get_monitor_config] (0): No services configured!
    /etc/sssd/sssd.conf ファイルを編集して、少なくとも 1 つのサービスプロバイダーを設定します。

    重要

    SSSD では、/etc/sssd/sssd.conf ファイル内の単一の services エントリに、カンマ区切りの一覧としてサービスプロバイダーを設定する必要があります。サービスが複数のエントリに記載されている場合は、最後のエントリのみが SSSD によって認識されます。
問：
'id' のあるグループや 'getent group' のあるグループメンバーが見当たりません。
答：
これは、sssd.conf の [domain/DOMAINNAME] セクションにある ldap_schema の誤った設定が原因である可能性があります。
SSSD は、RFC 2307 と RFC 2307bis スキーマタイプをサポートします。デフォルトでは、SSSD はより一般的な RFC 2307 スキーマを使用します。
RFC 2307 と RFC 2307bis の違いは、グループメンバーシップが LDAPサーバーに保存される方法の違いです。RFC 2307 サーバーでは、グループメンバーは複数値の memberuid 属性として保存され、これにはメンバーであるユーザーの名前が含まれます。RFC2307bis サーバーでは、グループメンバーは複数値の member または uniqueMember 属性として保存され、これにはこのグループのメンバーであるユーザーもしくはグループの DN が含まれます。RFC2307bis は、ネスト化されたグループのメンテナンスも可能にします。
グループルックアップがいかなる情報も返さない場合は、以下を行います。
  1. ldap_schema を rfc2307bis に設定。
  2. /var/lib/sss/db/cache_DOMAINNAME.ldb を削除。
  3. SSSD を再起動。
これが機能しない場合は、以下の行を sssd.conf に追加します。 
ldap_group_name = uniqueMember
その後にキャッシュを削除して、再度 SSSD を再起動します。
問：
LDAP に対する認証が失敗します。
答：
認証を実行するには、SSSD は通信チャンネルの暗号化を要求します。このため、sssd.conf が標準プロトコル (ldap://) で接続するように設定されている場合、Start TLS との通信チャンネルを暗号化しようとします。sssd.conf がセキュアなプロトコル (ldaps://)で接続するように設定されている場合は、SSSD は SSL を使用します。
つまり、LDAP サーバーは SSL または TLS で実行するように設定される必要があります。TLS は標準 LDAP ポート (389) で、SSL はセキュアな LDAPS ポート (636) で有効とする必要があります。SSL と TLS のいずれの場合も、LDAP サーバーは有効な証明書信頼で設定される必要があります。
無効な証明書信頼は、LDAP に対する認証における最も一般的な問題の一つです。クライアントに LDAP サーバー証明書の適切な信頼がないと、接続を確認できず、SSSD はパスワードの送信を拒否します。LDAP プロトコルでは、パスワードがプレーンテキストで LDAP サーバーに送信されることが要求されます。暗号化されていない接続でパスワードをプレーンテキストで送信することは、セキュリティー問題となります。
証明書が信頼されないと、syslog メッセージが書き込まれ、TLS 暗号化が開始できないことを意味します。証明書設定は、LDAP サーバーが SSSD 以外からアクセス可能かどうかをチェックすることでテストできます。以下の例では、TLS 接続で test.example.com への匿名バインドをテストします。 
$ ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com
証明書信頼が適切に設定されていない場合、以下のエラーが出てテストは失敗します。 
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
証明書を信頼するには、以下を行います。
  1. LDAP されていない証明書の署名に使われる証明書権限用の公開 CA 証明書のコピーを取得して、ローカルシステムに保存します。
  2. ファイルシステム上の CA 証明書に向けた sssd.conf ファイルに以下の行を追加します。 
    ldap_tls_cacert
  3. LDAP サーバーが自己署名証明書を使用する場合は、sssd.conf ファイルから ldap_tls_reqcert の行を削除します。
    このパラメーターは CA 証明書が発行する証明書をいかなるものでも信頼するように SSSD に指示しますが、自己署名の CA 証明書ではセキュリティーリスクとなります。
問：
非標準ポートでの LDAP サーバーへの接続が失敗します。
答：
enforcing モードで SELinux を実行する場合、クライアントの SELinux ポリシーは非標準ポートで LDAP サーバーに接続するように修正する必要があります。以下に例を挙げます。 
# semanage port -a -t ldap_port_t -p tcp 1389
問：
NSS がユーザー情報提供に失敗します。
答：
これは通常、SSSD が NSS サービスに接続できないことを意味します。
  • NSS が稼働していることを確認します: 
    # service sssd status
  • NSS が稼働している場合、プロバイダーが /etc/sssd/sssd.conf ファイル内の [nss] セクションで正しく設定されていることを確認します。特に、filter_users 属性と filter_groups 属性をチェックして下さい。
  • SSSD が使用するサービスのリスト内に NSS が含まれていることを確認します。
  • /etc/nsswitch.conf ファイル内の設定をチェックします。
問：
NSS が、誤ったユーザー情報を返す。
答：
ユーザー情報の検索で間違ったデータが返された場合には、別のドメインでユーザー名の競合がないことをチェックしてください。複数のドメインを使用している場合、/etc/sssd/sssd.conf ファイル内の use_fully_qualified_domains 属性を true に設定します。これが異なるドメインで同じ名前を持つ異なるユーザーを区別します。
問：
ローカルの SSSD ユーザー用のパスワード設定で、パスワードの入力が 2 回要求される。
答：
ローカルの SSSD ユーザーのパスワードの変更を試みると、パスワードを２回要求されることがあります。 
[root@clientF11 tmp]# passwd user1000
Changing password for user user1000.
New password:
Retype new password:
New Password:
Reenter new Password:
passwd: all authentication tokens updated successfully.
これは、PAM 設定が正しくないために生じます。使用している /etc/pam.d/system-auth ファイル内で use_authtok オプションが正しく設定されていることを確認して下さい。
問：
Identity Management (IPA) プロバイダーで sudo ルールを使おうとしていますが、sudo が適切に設定されているのに sudo ルールが見つかりません。
答：
SSSD クライアントは正常に Identity Management サーバーを認証し、LDAP ディレクトリーで適切に sudo ルールを検索しています。しかし、ルールが存在しないことを示しています。例えばログでは以下のようになります。 
(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with base [ou=sudoers,dc=ipa,dc=test]
(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sdap_sudo_load_sudoers_done] (0x0400): Received 0 rules
(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sdap_sudo_purge_sudoers] (0x0400): Purging SUDOers cache of user's [admin] rules
(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sysdb_sudo_purge_byfilter] (0x0400): No rules matched
(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sysdb_sudo_purge_bysudouser] (0x0400): No rules matched
(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sdap_sudo_load_sudoers_done] (0x0400): Sudoers is successfuly stored in cache
(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [be_sudo_handler_reply] (0x0200): SUDO Backend returned: (0, 0, Success)
SSSD に Identity Management プロバイダーを使用する場合、SSSD は Kerberos/GSS-API を使って基礎的な LDAP ディレクトリーに接続しようとします。しかし、デフォルトではSSSD は匿名接続を使って LDAP に接続し、sudo ルールを取得します。つまり、デフォルト設定では、SSSD は Identity Management サーバーから sudo ルールを取得できないことになります。
Kerberos/GSS-API 接続での sudo ルール取得をサポートするには、sssd.conf の ID プロバイダー設定で GSS-API を認証メカニズムとして有効にします。以下に例を挙げます。 
[domain/ipa.example.com]
id_provider = ipa
ipa_server = ipa.example.com
ldap_tls_cacert = /etc/ipa/ca.crt

sudo_provider = ldap
ldap_uri = ldap://ipa.example.com
ldap_sudo_search_base = ou=sudoers,dc=ipa,dc=example,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/hostname.ipa.example.com
ldap_sasl_realm = IPA.EXAMPLE.COM
krb5_server = ipa.example.com
問：
大きなディレクトリーでは パスワードルックアップ は、要求 1 件あたり数秒かかります。どうしたら改善できますか？
答：
最初のユーザールックアップは、LDAP サーバーへのコールです。インデックス化されていない検索は、よりリソース集約的なのでインデックス化されている検索よりも時間が長くかかります。これは、サーバーが一致を求めてディレクトリー内のすべてのエントリーをチェックするためです。ユーザールックアップを迅速化するには、SSSD が検索する属性をインデックス化します。
  • uid
  • uidNumber
  • gidNumber
  • gecos
問：
Active Directory ID プロバイダーは sssd.conf ファイルで適切に設定されているのに、SSSD は接続に失敗し、GSS-API エラーがでます。
答：
SSSD はホスト名を使ってのみ、Active Directory プロバイダーに接続できます。ホスト名が提供されないと、SSSD クライアントはホストへの IP アドレスが解決できず、認証に失敗します。
例えば以下の設定だと、 
[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 255.255.255.255
ad_domain = example.com
krb5_canonicalize = False
SSSD クライアントは以下の GSS-API エラーを返して、認証要求が失敗します。 
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Cannot determine realm for numeric host address)]
このエラーを避けるには、ad_server を Active Directory ホストの名前に設定します。
問：
SSSD を中央認証に設定しましたが、Firefox や Adobe などいくつかのアプリケーションが起動しません。
答：
64 ビットシステム上でも 32 ビットのアプリケーションはパスワードや ID キャッシュへのアクセスに 32 ビットバージョンの SSSD を必要とします。32 ビットバージョンの SSSD が利用できない場合でも、システムは SSSD キャッシュを使うように設定されており、したがって 32 ビットのアプリケーションは起動に失敗します。
例えば、Firefox は権限拒否のエラーで失敗します。 
Failed to contact configuration server. See http://www.gnome.org/projects/gconf/
for information. (Details -  1: IOR file '/tmp/gconfd-somebody/lock/ior'
not opened successfully, no gconfd located: Permission denied 2: IOR
file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd
located: Permission denied)
Adobe Reader の場合、以下のエラーは現行のシステムはユーザーが認識されていないことを示しています。 
[jsmith@server ~]$ acroread 
(acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown
user id (366)
他のアプリケーションでも、同様のユーザーもしくは権限エラーが表示される可能性があります。
問：
SSSDは、削除した自動マウントの場所を示しています。
答：
自動マウントのロケーションの SSSD キャッシュは、ロケーションがその後で変更されたり削除されたりしても、消えずに残ります。SSSD の autofs 情報を更新するには、以下を行います。
  1. 「SSSD キャッシュの削除」 の説明にあるように、autofs キャッシュを削除します。
  2. 「SSSD の起動と停止」 にあるように、SSSD を再起動します。