付録A トラブルシューティング

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

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

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

表A.1 デバッグログレベル

レベル説明
0致命的な失敗。SSSD の起動を妨げたり、SSSD の実行を停止させるもの。
1重大な失敗。SSSD を強制終了するわけではないが、少なくとも 1 つのメジャーな機能が適切に動作していないことを示すエラー。
2深刻な失敗。特定の要求や操作が失敗したことを知らせるエラー。
3マイナーな失敗。レベル 2 の操作の失敗を引き起こしかねないエラー。
4設定
5機能データ
6操作機能のメッセージを追跡します。
7内部制御機能のメッセージを追跡します。
8注意を引く可能性がある関数-内部変数のコンテンツ。
9非常に低いレベルの追跡情報。
SSSD の稼働中にデバッグレベルを変更するには、sss_debuglevel ユーティリティーを使用します。これは、sssd-tools パッケージの一部です。このユーティリティーの機能方法に関する情報は、sss_debuglevel の man ページを参照してください。

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

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

A.1.3. SSSD 設定に伴う問題

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

[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 が認識するのは最後のエントリーのみです。
  • SSSD には、/etc/sssd/sssd.conf の所有権とパーミッションが正確に設定されていることも必要です。所有権またはパーミッションが正確に設定されていない場合、SSSD の起動を試みた際に以下のようなエラーメッセージが返ってきます。 
    [sssd] [confdb_ldif_from_ini_file] (0x0020): Permission check on config file failed.
[sssd] [confdb_init_db] (0x0020): Cannot convert INI to LDIF [1]: [Operation not permitted]
[sssd] [confdb_setup] (0x0010): ConfDB initialization has failed [1]: Operation not permitted
[sssd] [load_configuration] (0x0010): Unable to setup ConfDB [1]: Operation not permitted
[sssd] [main] (0x0020): Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root.
    正確な所有権とパーミッションを /etc/sssd/sssd.conf ファイルに設定します。 
    # chmod 600 /etc/sssd/sssd.conf
# chown root:root /etc/sssd/sssd.conf
問：
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://) による接続が設定されている場合、SSSD は Start TLS で通信チャンネルの暗号化を試みます。sssd.conf でセキュアなプロトコル (ldaps://) による接続が設定されている場合は、SSSD は SSL を使用します。
つまり、LDAP サーバーは SSL または TLS で実行するように設定される必要があります。TLS は標準 LDAP ポート (389) で、SSL はセキュアな LDAPS ポート (636) で有効にする必要があります。SSL と TLS のいずれの場合も、LDAP サーバーは有効な証明書信頼で設定されている必要があります。
無効な証明書信頼は、LDAP に対する認証における最も一般的な問題の 1 つです。クライアントに 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 = /path/to/cacert
  3. LDAP サーバーが自己署名証明書を使用している場合は、sssd.conf ファイルから ldap_tls_reqcert の行を削除します。
    このパラメーターは、SSSD が認証局による証明書を信頼するように指示しますが、これは自己署名型の CA 証明書ではセキュリティーリスクとなります。
問：
非標準ポートでの LDAP サーバーへの接続が失敗します。
答：
enforcing モードで SELinux を実行する場合、クライアントの SELinux ポリシーは非標準ポートで LDAP サーバーに接続するように修正する必要があります。以下に例を挙げます。 
# semanage port -a -t ldap_port_t -p tcp 1389
問：
NSS がユーザー情報提供に失敗します。
答：
これは通常、SSSD が NSS サービスに接続できないことを意味します。
  • NSS サービスが稼働していることを確認します。 
    # service sssd status
Redirecting to /bin/systemctl status sssd.service
  sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: active (running) since Wed 2015-01-14 10:17:26 CET; 1min 30s ago
   Process: 683 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 745 (sssd)
   CGroup: /system.slice/sssd.service
            ├─745 /usr/sbin/sssd -D -f
	    ├─746 /usr/libexec/sssd/sssd_be --domain default --debug-to-files...
	    ├─804 /usr/libexec/sssd/sssd_nss --debug-to-files
	    └─805 /usr/libexec/sssd/sssd_pam --debug-to-files
    SSSD が Active: active (running) 状態で、かつ出力に sssd_nss が含まれていれば、NSS サービスは稼働しています。
  • NSS が稼働している場合は、プロバイダーが /etc/sssd/sssd.conf ファイル内の [nss] セクションで正しく設定されていることを確認してください。特に、filter_users 属性と filter_groups 属性をチェックしてください。
  • SSSD が使用するサービスのリスト内に NSS が含まれていることを確認します。
  • /etc/nsswitch.conf ファイル内の設定を確認します。詳細は、「NSS サービスを設定して SSSD を使用」 を参照してください。
問：
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 オプションが正しく設定されていることを確認してください。正しい設定例については、「サービスの設定: PAM」 を参照してください。
問：
Active Directory アイデンティティープロバイダーは sssd.conf ファイルで適切に設定されているのに、SSSD は接続に失敗し、GSS-API エラーがでます。
答：
SSSD は、ホスト名を使用しないと Active Directory プロバイダーに接続できません。ホスト名が提供されないと、SSSD クライアントはホストへの IP アドレスが解決できず、認証に失敗します。
たとえば、以下の設定の場合、 
[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 172.16.0.1
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 ホストの名前に設定するか、「DNS Service Discovery の設定」 にあるように _srv_ キーワードを DNS サービスディスカバリーに使用します。
問：
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. 「UID または GID の変更後、ユーザーのログインは不可」 の説明にあるように、autofs キャッシュを削除します。
  2. SSSD を再起動します。 
    # systemctl restart sssd

A.1.4. UID または GID の変更後、ユーザーのログインは不可

ユーザーまたはグループ ID の変更後、SSSD はユーザーのログインを阻止します。

エラー内容:

SSSD は、ユーザー ID (UID) およびグループ ID (GID) ベースでユーザーとグループを認識します。既存のユーザーまたはグループが UID または GID を変更すると、SSSD はそのユーザーまたはグループを認識しません。

解決方法:

sss_cache ユーティリティーを使用して SSSD キャッシュを削除します。
  1. sssd-tools がインストールさていることを確認します。
  2. 特定のユーザーの SSSD キャッシュを削除し、残りのキャッシュのレコードをそのまま残しておくには、以下を実行します。 
    # sss_cache --user user_name
    ドメイン全体のキャッシュを削除するには、以下を実行します。 
    # sss_cache --domain domain_name
ユーティリティーは、SSSD キャッシュにあるユーザーやグループ、ドメインのレコードを無効にします。続いて、SSSD はアイデンティティープロバイダーからレコードを取得し、キャッシュをリフレッシュします。
sss_cache の詳細は、sss_cache(8) の man ページを参照してください。

A.1.5. SSSD コントロールとステータスユーティリティー

SSSD には、ステータス情報の取得、トラブルシューティング時のデータファイルやその他の SSSD 関連タスクの管理を行う sssctl ユーティリティーが含まれます。
  1. sssctl を使用するには、sssd-tools パッケージをインストールします。 
    [root@server ~]# yum install sssd-tools
  2. sssctl のオプションは、SSSD InfoPipe 応答を使用します。これを有効化するには /etc/sssd/sssd.conf の services オプションに ifp を追加します。 
    [sssd]
services = nss, sudo, pam, ssh, ifp
  3. SSSD を再起動します。 
    [root@server ~]# systemctl restart sssd.service

A.1.5.1. SSSD 設定の検証

sssctl config-check コマンドは、SSSD 設定ファイルの静的な解析を実行します。これにより、/etc/sssd/sssd.conf ファイルと /etc/sssd/conf.d/* ファイルを検証して、SSSD を再起動する前にレポートを取得することができます。
このコマンドは、SSSD 設定ファイルに以下のチェックを実行します。
パーミッション
所有者およびグループの所有者は root:root に、パーミッションは 600 に設定する必要があります。
ファイル名
/etc/sssd/conf.d/ のファイル名は .conf というサフィックスを使用する必要があり、. (ピリオド) で開始できないものとします。
誤字誤植
セクションとオプション名の誤字誤植がチェックされます。値はチェックされない点に注意してください。
オプション
オプションは、正しいセクションに配置するようにしてください。
設定を検証するには、以下を実行します。 
# sssctl config-check
Issues identified by validators: 3
[rule/allowed_sections]: Section [paM] is not allowed. Check for typos.
[rule/allowed_domain_options]: Attribute 'offline_timeoutX' is not allowed in section 'domain/idm.example.com'. Check for typos.
[rule/allowed_sudo_options]: Attribute 'homedir_substring' is not allowed in section 'sudo'. Check for typos.

Messages generated during configuration merging: 2
File /etc/sssd/conf.d/wrong-file-permissions.conf did not pass access check. Skipping.
File configuration.conf.disabled did not match provided patterns. Skipping.

Used configuration snippet files: 1
/etc/sssd/conf.d/sample.conf

A.1.5.2. ドメイン情報

ドメインのステータスにより、SSSD がアクセスするドメイン一覧を表示し、ステータスを取得することができます。
  1. 信頼済みのドメインなど、SSSD 内で利用可能なドメインをすべて表示します。 
    [root@server ~]# sssctl domain-list
idm.example.com
ad.example.com
  2. idm.example.com ドメインのステータスを取得します。 
    [root@server ~]# sssctl domain-status idm.example.com
Online status: Online

A.1.5.3. キャッシュされたエントリーの情報

sssctl コマンドにより、キャッシュされたエントリーの情報を取得して、キャッシュ関連の認証問題を調査、デバッグすることができます。
ユーザーアカウント admin のキャッシュ情報を照会するには、以下を実行します。 
[root@server ~]# sssctl user-show admin
Name: admin
Cache entry creation date: 07/10/16 16:09:18
Cache entry last update time: 07/14/16 10:13:32
Cache entry expiration time: 07/14/16 11:43:32
Initgroups expiration time: Expired
Cached in InfoPipe: No
グループまたはネットグループのキャッシュ情報を照会するには、以下を使用します。 
[root@server ~]# sssctl group-show groupname
[root@server ~]# sssctl netgroup-show netgroupname

A.1.5.4. ログファイルの省略

問題をデバッグする場合には sssctl logs-remove を使用して /var/log/sssd/ ディレクトリーのすべての SSSD ログファイルを省略して、新たに作成されたエントリーのみを取得することができます。 
[root@server ~]# sssctl logs-remove
Truncating log files...

A.1.5.5. SSSD キャッシュの削除

SSSD キャッシュのデータベースを削除するには sssctl コマンドを使用して remove-cache オプションを指定します。データベースを削除する前に、このコマンドにより自動的にバックアップが作成されます。
以下のコマンドを実行して、すべてのローカルデータをバックアップし、SSSD キャッシュを削除します。 
[root@server ~]# sssctl cache-remove
SSSD must not be running. Stop SSSD now? (yes/no) [yes]
Creating backup of local data...
Removing cache files...
SSSD needs to be running. Start SSSD now? (yes/no) [yes]

注記

このバックアップでは、/var/lib/sss/backup/ ディレクトリーに、ローカルの上書きなどのローカルデータのみを保存します。
バックエンドのコンテンツを自動的にインポートするには sssctl restore-local-data を実行します。

A.1.5.6. LDAP グループの情報取得には長時間必要

LDAP グループについての情報をルックアップする操作は、非常に時間がかかります。大規模なグループやネスト化されたグループの場合は、特に時間がかかります。

エラー内容:

デフォルトでは、LDAP グループについての情報をルックアップしている際には、そのグループのすべてのメンバーが返されます。大規模なグループやネスト化されたグループの操作の場合、すべてのメンバーを返すため、処理に時間がかかります。

解決方法:

グループのルックアップに返されたメンバーシップ一覧は、ユーザーがグループに所属しているかどうかを評価する際には使用されません。パフォーマンスの向上、特にアイデンティティールックアップのパフォーマンスの向上には、グループメンバーシップのルックアップを無効にします。
  1. /etc/sssd/sssd.conf ファイルを開きます。
  2. [domain] セクションで、ignore_group_members オプションを true に設定します。 
    [domain/domain_name]
[... file truncated ...]
ignore_group_members = true