Red Hat Training

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

付録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 が起動しなかったものはすべて、実行を停止したり、実行停止したりします。
1 重大なエラー。SSSD を強制終了しないが、少なくとも 1 つの主要な機能が適切に機能しなくなることを示すエラー。
2 深刻な不具合:特定の要求または操作が失敗したことを通知するエラー。
3 マイナーなエラー。この操作は、2 の操作に失敗するために切り替わるエラーです。
4 設定
5 機能データ
6 操作機能のメッセージを追跡します。
7 内部制御機能のメッセージを追跡します。
8 注意を引く可能性がある関数-内部変数のコンテンツ。
9 非常に低レベルトレース情報。
SSSD の実行中にデバッグレベルを変更するには、sssd-tools パッケージに含まれる sss_debuglevel ユーティリティーを使用します。仕組みの詳細は、sss_debuglevel の man ページを参照してください。

A.1.2. SSSD ログファイルの確認

SSSD は、ログファイルを多数使用して、/var/log/sssd/ ディレクトリーにある操作に関する情報を報告します。SSSD は、各ドメインのログファイルと sssd_pam.log ファイルと sssd_nss.log ファイルを生成する。
  • krb5_child.log: Kerberos 認証に関連する有効期限の短いヘルパープロセスのログファイル
  • ldap_child.log: LDAP サーバーとの通信に関連する有効期限の短いヘルパープロセスのログファイル
  • selinux_child.log: SELinux 情報を取得する有効期限の短いヘルパープロセスのログファイル
  • sssd.log: レスポンダープロセスと通信する SSSD のログファイル
  • sssd_[domain].log: 各 SSSD ドメインセクションは、LDAP サーバーとの通信に関する情報を個別のログファイルに記録します。
  • sssd_ifp.log: InfoPipe レスポンダーのログファイルがシステムバスを通じてアクセス可能なパブリック D-Bus インターフェースを提供します。
  • sssd_nss.log: ユーザーおよびグループ情報を取得する Name Services Switch(NSS)レスポンダーのログファイル
  • sssd_pac.log: Active Directory ユーザーおよびグループの管理方法を定義する Microsoft Privilege Attribute Certificate(PAC)レスポンダーサービスのログファイル
  • sssd_pam.log: PAM(Pluggable Authentication Module)レスポンダーのログファイル
  • sssd_ssh.log: SSH レスポンダープロセスのログファイル
さらに、/var/log/secure ファイルは、認証失敗と失敗の理由をログに記録します。

A.1.3. SSSD 設定に関する問題

問:
SSSD が起動に失敗します。
答:
SSSD では、デーモンを起動する前に設定ファイルを適切に設定する必要があります。
  • SSSD では、サービスが起動する前に、最低でもドメインを適切に設定する必要があります。ドメインがないと、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 ファイルの 1 つの 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
    
問:
getent グループの ID またはグループメンバーを持つグループは表示されません。
答:
これは、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 で実行するように設定する必要があります。TLS は、セキュアな LDAPS ポート(636)で標準の LDAP ポート(389)または 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
    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
    NSS サービスは、SSSD が Active: active(running) 状態で、出力に sssd_nss が含まれる場合に実行されます。
  • NSS を実行している場合は、プロバイダーが /etc/sssd/sssd.conf ファイルの [nss] セクションに適切に設定されていることを確認します。特に filter_users および filter_groups 属性を確認します。
  • NSS が SSSD が使用するサービスの一覧に含まれていることを確認してください。
  • /etc/nsswitch.conf ファイルの設定を確認します。「SSSD を使用するように NSS サービスを設定」
問:
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 設定の結果です。use_authtok オプションが /etc/pam.d/system-auth ファイルに正しく設定されていることを確認します。「サービスの設定: 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)]
このエラーを回避するには、Active Directory のホスト名に ad_server を設定するか、_srv_ キーワードを使用して DNS 「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. 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 コントロールおよび Status ユーティリティー

SSSD は、sssctl ユーティリティーを提供し、トラブルシューティング中にステータス情報の取得、データファイルの管理、およびその他の SSSD 関連のタスクです。
  1. sssctl を使用するには、sssd-tools パッケージをインストールします。
    [root@server ~]# yum install sssd-tools
  2. sssctl の一部のオプションは、SSSD InfoPipe レスポンダーを使用します。これを有効にするには、/etc/sssd/sssd.conf のサービスオプションに 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. ユーザーデータの表示

sssctl user-checks コマンドは、SSSD をユーザールックアップ、認証、および認可のバックエンドとして使用するアプリケーションでの問題のデバッグに役立ちます。このコマンドは、NSS から利用可能なユーザーデータ、D-Bus インターフェースの InfoPipe レスポンダーを表示します。表示されるデータは、ユーザーが system-auth の PAM サービスを使用してログインすることを許可されているかどうかを示します。
たとえば、admin ユーザーのユーザーデータを表示するには、以下を実行します
# sssctl user-checks admin
user: admin
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: admin
 - user id: 1194200000
 - group id: 1194200000
 - gecos: Administrator
 - home directory: /home/admin
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: admin
 - uidNumber: 1194200000
 - gidNumber: 1194200000
 - gecos: Administrator
 - homeDirectory: /home/admin
 - loginShell: /bin/bash

testing pam_acct_mgmt

pam_acct_mgmt: Success

PAM Environment:
 - no env -
その他のオプションは、sssctl user-checks --help コマンドの出力を参照してください。

A.1.5.3. ドメイン情報

ドメインのステータスにより、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.4. キャッシュされたエントリー情報

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
グループまたは netgroup のキャッシュ情報をクエリーするには、以下を使用します。
[root@server ~]# sssctl group-show groupname
[root@server ~]# sssctl netgroup-show netgroupname

A.1.5.5. ログファイルの切り捨て

問題をデバッグする際に、sssctl logs-remove を使用して、/var/log/sssd/ ディレクトリー内のすべての SSSD ログファイルを切り捨てて、新しく作成されたエントリーのみをキャプチャーできます。
[root@server ~]# sssctl logs-remove
Truncating log files...

A.1.5.6. 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.7. LDAP グループについての情報の取得(Longs Long)

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

エラー内容:

デフォルトでは、LDAP グループ情報の検索は、グループのすべてのメンバーを返します。大規模なグループまたはネスト化されたグループに関連する操作の場合、すべてのメンバーを返すとプロセスが長くなります。

問題を解決するには、以下を実行します。

ユーザーがグループに属するかどうかを評価する場合、グループルックアップで返されるメンバーシップリストは使用されません。特に ID 検索ではパフォーマンスを改善するには、グループメンバーシップの検索を無効にします。
  1. /etc/sssd/sssd.conf ファイルを開きます。
  2. [domain] セクションで、ignore_group_members オプションを true に設定します。
    [domain/domain_name]
    [... file truncated ...]
    ignore_group_members = true

このページには機械翻訳が使用されている場合があります (詳細はこちら)。