12.4. 認証問題の範囲の制限
ユーザーを正常に認証するには、ユーザー情報を保存するデータベースから SSSD サービスでユーザー情報を取得できる必要があります。以下の手順では、認証プロセスの異なるコンポーネントをテストする手順を説明します。これにより、ユーザーがログインできない場合に認証の問題のスコープを制限する方法を説明します。
手順
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
クライアントが IP アドレスを使用してユーザーデータベースサーバーに接続できることを確認します。
[user@client ~]$ ping <IP_address_of_the_database_server>
この手順が失敗した場合は、ネットワークとファイアウォール設定が、IdM クライアントとサーバー間の直接通信が許可されていることを確認してください。firewalld の使用および設定 を参照してください。
クライアントが、完全修飾ホスト名を使用して 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>
このオプションを使用する場合は、そのオプションに記載されているサーバーと通信できることを確認します。
-
クライアントが LDAP サーバーに対して認証でき、
ldapsearch
コマンドでユーザー情報を取得できることを確認します。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>
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>
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 サーバーを検索できることを確認します。
SSSD サービスは Kerberos 暗号化を使用するため、ログインできないユーザーとして Kerberos チケットを取得できます。
LDAP サーバーが IdM サーバーの場合:
[user@client ~]$ kinit <user_name>
LDAP サーバーデータベースが AD サーバーの場合:
[user@client ~]$ kinit <user_name@AD.EXAMPLE.COM>
この手順が失敗した場合は、Kerberos サーバーが適切に動作し、すべてのサーバーが同期され、ユーザーアカウントがロックされていないことを確認します。
コマンドラインに関するユーザー情報を取得できることを確認します。
[user@client ~]$ getent passwd <user_name> [user@client ~]$ id <user_name>
この手順が失敗した場合は、クライアントの SSSD サービスがユーザーデータベースから情報を受信できることを確認します。
-
/var/log/messages
ログファイルのエラーを確認します。 - SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
- (オプション) Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。
-
ホストで
sudo
を実行することが許可されている場合は、sssctl
ユーティリティーを使用して、ユーザーがログインを許可されていることを確認します。[user@client ~]$ sudo sssctl user-checks -a auth -s ssh <user_name>
この手順が失敗した場合は、PAM 設定、IdM HBAC ルール、IdM RBAC ルールなどの承認設定を確認します。
-
ユーザーの UID が、
/etc/login.defs
ファイルで定義されているUID_MIN
以上であることを確認してください。 -
/var/log/secure
ログファイルおよび/var/log/messages
ログファイルで認証エラーを確認します。 - SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
- (オプション) Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。
-
ユーザーの UID が、