8.4. 인증 문제 범위 줄이기

절차

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 파일을 포함하여 DNS(동적 이름 서비스) 설정을 확인합니다. DNS 서버 순서 구성을 참조하십시오.

   참고

   기본적으로 SSSD 서비스는 SRV(DNS 서비스) 레코드를 통해 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.ad.example.com 과 같은 DC(Active Directory) 도메인 컨트롤러인 경우 호스트에 대한 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 기술 지원 케이스를 열고 수집한 문제 해결 정보를 제공합니다.