13.2.31. SSSD のトラブルシューティング
SSSD ドメインのデバッグログの設定
各ドメインは、独自のデバッグログレベルを設定します。ログレベルを増やすと、SSSD またはドメイン設定の問題に関する詳細情報が提供されます。
ログレベルを変更するには、
sssd.conf
ファイルの各セクションに debug_level
パラメーターを設定し、追加のログを生成します。以下に例を示します。
[domain/LDAP]
cache_credentials = true
debug_level = 9
レベル | 説明 |
---|---|
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 が起動に失敗する
- 問: 「id」または「getent group」を持つグループメンバーを持つグループは表示されません。
- 問: 認証は LDAP に対して失敗します。
- 問: 非標準ポートで LDAP サーバーへの接続に失敗します。
- 問: NSS がユーザー情報を返すことができません
- 問: NSS が間違ったユーザー情報を返す
- 問: ローカルの SSSD ユーザーのパスワードを設定すると、パスワードが 2 回要求されます。
- 問: Identity Management(IPA)プロバイダーで sudo ルールを使用しようとすると、sudo が適切に設定されていない場合でも sudo ルールは見つかりません。
- 問: 大規模なディレクトリーのパスワード検索には、要求ごとに数秒かかる場合があります。どのように改善できるのでしょうか?
- 問: Active Directory アイデンティティープロバイダーは sssd.conf ファイルで適切に設定されていますが、SSSD は接続に失敗し、GSS-API エラーが出されます。
- 問: SSSD が中央認証用に設定されましたが、アプリケーション(Firefox、Adobe など)が複数起動しません。
- 問: 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 を使用すると、ネストされたグループも保守できます。
グループルックアップが情報が返されない場合は、以下を行います。
- ldap_schema を rfc2307bis に設定します。
- Delete
/var/lib/sss/db/cache_DOMAINNAME.ldb
. - 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
証明書を信頼するには、次のコマンドを実行します。
- LDAP サーバー証明書に署名するために使用される認証局の公開 CA 証明書のコピーを取得してローカルシステムに保存します。
- ファイルシステムの CA 証明書を参照する
sssd.conf
ファイルに行を追加します。ldap_tls_cacert = /path/to/cacert
- 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 情報を更新するには、次のコマンドを実行します。
- 「SSSD キャッシュのパージ」 の説明に従って、autofs キャッシュを削除します。
- 「SSSD の起動および停止」 にあるように、SSSD を再起動します。