12.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 <domain_name> --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.<domain>@<server_name>
   [user@client ~]$ ping <fully_qualified_host_name_of_the_server>

   이 단계가 실패하면 /etc/resolv.conf 파일을 포함하여 DNS(Dynamic Name Service) 설정을 확인합니다. DNS 서버 순서 구성을 참조하십시오.

   참고

   기본적으로 SSSD 서비스는 DNS 서비스(SRV) 레코드를 통해 LDAP 서버 및 AD DC를 자동으로 검색하려고 합니다. SSSD를 특정 서버로 제한하려면 다음 옵션을 사용하여 sssd.conf 구성 파일에 정의합니다.

   • 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=<idm_user>

   2. LDAP 서버가 server.ad.example.com 과 같은 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=<idm_user>

   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=<idm_user>

   이 단계가 실패하면 데이터베이스 설정에서 호스트에서 LDAP 서버를 검색할 수 있는지 확인합니다.

5. SSSD 서비스는 Kerberos 암호화를 사용하므로 로그인할 수 없는 사용자로 Kerberos 티켓을 가져올 수 있는지 확인합니다.

   1. LDAP 서버가 IdM 서버인 경우:

      [user@client ~]$ kinit <idm_user>

   2. LDAP 서버 데이터베이스가 AD 서버인 경우:

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

   이 단계가 실패하면 Kerberos 서버가 올바르게 작동하고 모든 서버의 시간이 동기화되고 사용자 계정이 잠겨 있지 않은지 확인합니다.

6. 명령줄에 대한 사용자 정보를 검색할 수 있는지 확인합니다.

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

   이 단계가 실패하면 클라이언트의 SSSD 서비스가 사용자 데이터베이스에서 정보를 수신할 수 있는지 확인합니다.

   1. /var/log/messages 로그 파일에서 오류를 검토합니다.
   2. SSSD 서비스에서 세부 로깅을 활성화하고 디버깅 로그를 수집하고 로그에서 문제 소스에 대한 표시를 검토합니다.
   3. 선택 사항: Red Hat 기술 지원 케이스를 열고 수집한 문제 해결 정보를 제공합니다.

7. 호스트에 대한 sudo 권한이 있는 경우 sssctl 유틸리티를 사용하여 사용자가 로그인할 수 있는지 확인합니다.

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

   이 단계가 실패하면 PAM 구성, IdM HBAC 규칙 및 IdM RBAC 규칙과 같은 권한 부여 설정을 확인합니다.

   1. 사용자의 UID가 /etc/login.defs 파일에 정의된 UID_MIN 보다 크거나 같은지 확인합니다.
   2. /var/log/secure 및 /var/log/messages 로그 파일에서 권한 부여 오류를 검토합니다.
   3. SSSD 서비스에서 세부 로깅을 활성화하고 디버깅 로그를 수집하고 로그에서 문제 소스에 대한 표시를 검토합니다.
   4. 선택 사항: Red Hat 기술 지원 케이스를 열고 수집한 문제 해결 정보를 제공합니다.