Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

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

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

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.
    Copy to Clipboard Toggle word wrap
    /etc/sssd/sssd.conf ファイルを編集し、最低でも 1 つのドメインを作成します。
  • SSSD は、開始する前に、少なくとも 1 つ以上の利用可能なサービスプロバイダーも必要です。問題がサービスプロバイダー設定にある場合、エラーメッセージはサービスが設定されていないことを示します。 
    [sssd] [get_monitor_config] (0): No services configured!
    Copy to Clipboard Toggle word wrap
    /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_schema を rfc2307bis に設定します。
  2. Delete /var/lib/sss/db/cache_DOMAINNAME.ldb.
  3. SSSD を再起動します。
これが機能しない場合は、この行を sssd.conf に追加します。 
ldap_group_name = uniqueMember
Copy to Clipboard Toggle word wrap
次に、キャッシュを削除し、再度 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
Copy to Clipboard Toggle word wrap
証明書信頼が適切に設定されていない場合、テストは以下のエラーを出して失敗します。 
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
Copy to Clipboard Toggle word wrap
証明書を信頼するには、次のコマンドを実行します。
  1. LDAP サーバー証明書に署名するために使用される認証局の公開 CA 証明書のコピーを取得してローカルシステムに保存します。
  2. ファイルシステムの CA 証明書を参照する sssd.conf ファイルに行を追加します。 
    ldap_tls_cacert = /path/to/cacert
    Copy to Clipboard Toggle word wrap
  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
Copy to Clipboard Toggle word wrap
問：
NSS がユーザー情報を返すことができません
答：
これは通常、SSSD が NSS サービスに接続できないことを意味します。
  • NSS が実行していることを確認します。 
    # service sssd status
    Copy to Clipboard Toggle word wrap
  • 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.
Copy to Clipboard Toggle word wrap
これは、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)
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
問：
大規模なディレクトリーのパスワード検索には、要求ごとに数秒かかる場合があります。どのように改善できるのでしょうか？
答：
最初のユーザールックアップは、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
Copy to Clipboard Toggle word wrap
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)]
Copy to Clipboard Toggle word wrap
このエラーを回避するには、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)
Copy to Clipboard Toggle word wrap
Adobe Reader の場合は、現在のシステムユーザーが認識されていないことを示すエラーが表示されます。 
~]$ acroread 
(acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown
user id (366)
Copy to Clipboard Toggle word wrap
他のアプリケーションは同様のユーザーまたはパーミッションエラーが表示される可能性があります。
問：
SSSD は、削除された自動マウントの場所を表示します。
答：
自動マウントの場所の SSSD キャッシュは、場所が後で変更または削除しても持続します。SSSD で autofs 情報を更新するには、次のコマンドを実行します。
  1. 「SSSD キャッシュのパージ」 の説明に従って、autofs キャッシュを削除します。
  2. 「SSSD の起動および停止」 にあるように、SSSD を再起動します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat