Menu Close
Settings Close

Language and Page Formatting Options

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の起動を妨げる、または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 ユーザーおよびグループの管理に SSSD が Kerberos と動作する方法を定義する 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 ファイルの単一の 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 group のグループではなく、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 で実行する必要があります。標準の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
    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) 状態のときに、NSS サービスが実行され、出力に 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 設定が間違っているためです。/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 サービスディスカバリーの設定」 の説明に従って _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 コントロールおよび Status ユーティリティー

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

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

エラー内容:

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

解決方法:

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