Red Hat Training

A Red Hat training course is available for RHEL 8

8.4. 認証問題の範囲の制限

ユーザーを正常に認証するには、ユーザー情報を保存するデータベースから SSSD サービスでユーザー情報を取得できる必要があります。以下の手順では、認証プロセスの異なるコンポーネントをテストする手順を説明します。これにより、ユーザーがログインできない場合に認証の問題のスコープを制限する方法を説明します。

手順

  1. SSSD サービスおよびそのプロセスが実行していることを確認します。

    [root@client ~]# pstree -a | grep sssd
      |-sssd -i --logger=files
      |   |-sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
      |   |-sssd_be --domain example.com --uid 0 --gid 0 --logger=files
      |   |-sssd_ifp --uid 0 --gid 0 --logger=files
      |   |-sssd_nss --uid 0 --gid 0 --logger=files
      |   |-sssd_pac --uid 0 --gid 0 --logger=files
      |   |-sssd_pam --uid 0 --gid 0 --logger=files
      |   |-sssd_ssh --uid 0 --gid 0 --logger=files
      |   `-sssd_sudo --uid 0 --gid 0 --logger=files
      |-sssd_kcm --uid 0 --gid 0 --logger=files
  2. クライアントが IP アドレスを使用してユーザーデータベースサーバーに接続できることを確認します。

    [user@client ~]$ ping <IP_address_of_the_database_server>

    この手順が失敗した場合は、ネットワークとファイアウォール設定が、IdM クライアントとサーバー間の直接通信が許可されていることを確認してください。firewalld の使用および設定 を参照してください。

  3. クライアントが、完全修飾ホスト名を使用して IdM LDAP サーバー (IdM ユーザー用) または AD ドメインコントローラー (AD ユーザーの場合) を検出して連絡できることを確認します。

    [user@client ~]$ dig -t SRV _ldap._tcp.example.com @<name_server>
    [user@client ~]$ ping <fully_qualified_host_name_of_the_server>

    この手順が失敗した場合は、/etc/resolv.conf ファイルを含む Dynamic Name Service (DNS) の設定を確認してください。DNS サーバーの順序の設定 を参照してください。

    注記

    デフォルトでは、SSSD サービスは DNS サービス (SRV) レコードを介して LDAP サーバーと AD DC を自動的に検出しようとします。sssd.conf 設定ファイルで以下のオプションを設定すると、SSSD サービスが特定のサーバーを使用するように制限できます。

    • ipa_server = <fully_qualified_host_name_of_the_server>
    • ad_server = <fully_qualified_host_name_of_the_server>
    • ldap_uri = <fully_qualified_host_name_of_the_server>

    このオプションを使用する場合は、そのオプションに記載されているサーバーと通信できることを確認します。

  4. クライアントが LDAP サーバーに対して認証でき、ldapsearch コマンドでユーザー情報を取得できることを確認します。

    1. LDAP サーバーが server.example.com などの IdM サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。

      [user@client ~]$ kinit -k 'host/client.example.com@EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.example.com -b “dc=example,dc=com” uid=<user_name>
    2. LDAP サーバーが server.example.com などの Active Directory (AD) Domain Controller (DC) サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。

      [user@client ~]$ kinit -k 'CLIENT$@AD.EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.ad.example.com -b “dc=example,dc=com” sAMAccountname=<user_name>
    3. LDAP サーバーがプレーン LDAP サーバーであり、sssd.conf ファイルに ldap_default_bind_dn および ldap_default_authtok オプションを設定した場合は、同じ ldap_default_bind_dn アカウントとして認証されます。

      [user@client ~]$ ldapsearch -xLLL -D "cn=ldap_default_bind_dn_value" -W -h ldapserver.example.com -b “dc=example,dc=com” uid=<user_name>

    この手順が失敗した場合は、データベース設定で、ホストが LDAP サーバーを検索できることを確認します。

  5. SSSD サービスは Kerberos 暗号化を使用するため、ログインできないユーザーとして Kerberos チケットを取得できます。

    1. LDAP サーバーが IdM サーバーの場合:

      [user@client ~]$ kinit <user_name>
    2. LDAP サーバーデータベースが AD サーバーの場合:

      [user@client ~]$ kinit <user_name@AD.EXAMPLE.COM>

    この手順が失敗した場合は、Kerberos サーバーが適切に動作し、すべてのサーバーが同期され、ユーザーアカウントがロックされていないことを確認します。

  6. コマンドラインに関するユーザー情報を取得できることを確認します。

    [user@client ~]$ getent passwd <user_name>
    [user@client ~]$ id <user_name>

    この手順が失敗した場合は、クライアントの SSSD サービスがユーザーデータベースから情報を受信できることを確認します。

    1. /var/log/messages ログファイルのエラーを確認します。
    2. SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
    3. (オプション) Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。
  7. ホストで sudo を実行することが許可されている場合は、sssctl ユーティリティーを使用して、ユーザーがログインを許可されていることを確認します。

    [user@client ~]$ sudo sssctl user-checks -a auth -s ssh <user_name>

    この手順が失敗した場合は、PAM 設定、IdM HBAC ルール、IdM RBAC ルールなどの承認設定を確認します。

    1. ユーザーの UID が、/etc/login.defs ファイルで定義されている UID_MIN 以上であることを確認してください。
    2. /var/log/secure ログファイルおよび /var/log/messages ログファイルで認証エラーを確認します。
    3. SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
    4. (オプション) Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。