Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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

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

各ドメインは、独自のデバッグログレベルを設定します。ログレベルを増やすと、SSSD またはドメイン設定の問題に関する詳細情報が提供されます。
ログレベルを変更するには、sssd.conf ファイルの各セクションに debug_level パラメーターを設定し、追加のログを生成します。以下に例を示します。
[domain/LDAP]
cache_credentials = true
debug_level = 9

表13.13 デバッグログレベル

レベル 説明
0 致命的な障害。SSSDの起動を妨げる、またはSSSDの実行を停止させるもの。
1 重大なエラー。SSSD を強制終了しないものの、少なくとも 1 つの主要な機能が適切に機能していないことを示すエラー。
2 深刻なエラー。特定の要求または操作が失敗したことを示すエラー。
3 マイナーな障害。これらのエラーが浸透して、2の動作不良の原因となるのです。
4 構成設定。
5 関数データ。
6 操作関数のメッセージを追跡します。
7 内部制御関数のメッセージのトレース。
8 対象の関数内部変数の内容。
9 非常に低いレベルのトレース情報。
注記
1.8 よりも古い SSSD のバージョンでは、[sssd] セクションにデバッグログレベルをグローバルに設定できます。今回のリリースより、各ドメインおよびサービスは独自のデバッグログレベルを設定する必要があります。
グローバル SSSD デバッグログレベルを SSSD 設定ファイルの各設定領域にコピーするには、sssd_update_debug_levels.py スクリプトを使用します。
python -m SSSDConfig.sssd_update_debug_levels.py

SSSD ログファイルの確認

SSSD は、/var/log/sssd/ ディレクトリーにある操作に関する情報を報告するログファイルを使用します。SSSD は、各ドメインのログファイルと sssd_pam.log および sssd_nss.log ファイルを生成します。
さらに、/var/log/secure ファイルは認証の失敗と、失敗の原因を記録します。

SSSD 設定に関する問題

問:
SSSD が起動に失敗する
答:
SSSD では、デーモンを起動する前に、必要なすべてのエントリーで設定ファイルを適切に設定する必要があります。
  • SSSD では、サービスが起動する前に、最低でもドメインを適切に設定する必要があります。ドメインがないと、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 ファイルを編集し、最低でも 1 つのドメインを作成します。
  • 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 サーバーでは、グループメンバーは、このグループのメンバーであるユーザーまたはグループの DN を含む多値 member または uniqueMember 属性として保存されます。RFC2307bis を使用すると、ネストされたグループも保守できます。
グループルックアップが情報が返されない場合は、以下を行います。
  1. ldap_schemarfc2307bis に設定します。
  2. Delete /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 で実行する必要があります。標準のLDAPポート(389)でTLSを有効にするか、セキュアLDAPSポート(636)でSSLを有効にする必要があります。SSLまたはTLSのいずれかを使用する場合、LDAPサーバーも有効な証明書の信頼で構成する必要があります。
無効な証明書の信頼は、LDAPに対する認証に関する最も一般的な問題の1つです。クライアントがLDAPサーバー証明書を適切に信頼していない場合、接続を検証できず、SSSDはパスワードの送信を拒否します。LDAP プロトコルでは、パスワードをプレーンテキストで LDAP サーバーに送信する必要があります。暗号化されていない接続でプレーンテキストでパスワードを送信することは、セキュリティーの問題です。
証明書が信頼されていない場合は、TLS 暗号化を開始できなかったことを示す syslog メッセージが書き込まれます。証明書設定は、SSSD とは別に LDAP サーバーにアクセスできるかどうかを確認してテストできます。たとえば、以下は、test.example.com への TLS 接続を介して匿名バインドをテストします。
$ 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 = /path/to/cacert
  3. LDAP サーバーが自己署名証明書を使用する場合は、sssd.conf ファイルから ldap_tls_reqcert 行を削除します。
    このパラメーターにより、SSSD が CA 証明書により発行された証明書を信頼するように指示します。これは、自己署名の CA 証明書を使用するセキュリティーリスクになります。
問:
非標準ポートで LDAP サーバーへの接続に失敗します。
答:
SELinux を Enforcing モードで実行する場合は、クライアントの 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 属性を確認します。
  • NSS が SSSD が使用するサービスの一覧に含まれていることを確認します。
  • /etc/nsswitch.conf ファイルの設定を確認します。
問:
NSS が間違ったユーザー情報を返す
答:
検索が正しくないユーザー情報を返した場合は、別のドメインでユーザー名が競合していないことを確認してください。複数のドメインがある場合は、/etc/sssd/sssd.conf ファイルで use_fully_qualified_domains 属性を true に設定します。これは、同じ名前の異なるドメインの異なるユーザーを区別します。
問:
ローカルの SSSD ユーザーのパスワードを設定すると、パスワードが 2 回要求されます。
答:
ローカルの SSSD ユーザーのパスワードを変更しようとすると、パスワードを 2 回求められる場合があります。
[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 サーバーに正常に認証でき、sudo ルールの LDAP ディレクトリーを適切に検索します。ただし、ルールが存在しないことを示します。たとえば、ログで以下を行います。
(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
問:
大規模なディレクトリーのパスワード検索には、要求ごとに数秒かかる場合があります。どのように改善できるのでしょうか?
答:
最初のユーザールックアップは、LDAP サーバーへの呼び出しです。インデックスのない検索はリソース集約型が多いため、サーバーはディレクトリー内のすべてのエントリーが一致するかどうかをチェックするため、インデックス化された検索よりも時間がかかります。ユーザー検索を迅速化するには、SSSD が検索する属性をインデックス化します。
  • uid
  • uidNumber
  • gidNumber
  • gecos
問:
Active Directory アイデンティティープロバイダーは 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 キャッシュにアクセスするために使用する SSSD のバージョンが 32 ビットである必要があります。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 の場合は、現在のシステムユーザーが認識されていないことを示すエラーが表示されます。
~]$ acroread 
(acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown
user id (366)
他のアプリケーションは同様のユーザーまたはパーミッションエラーが表示される可能性があります。
問:
SSSD は、削除された自動マウントの場所を表示します。
答:
自動マウントの場所の SSSD キャッシュは、場所が後で変更または削除しても持続します。SSSD で autofs 情報を更新するには、次のコマンドを実行します。
  1. 「SSSD キャッシュのパージ」 の説明に従って、autofs キャッシュを削除します。
  2. 「SSSD の起動および停止」 にあるように、SSSD を再起動します。