12.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 서버(Id 사용자용) 또는 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(Dynamic Name Service) 설정을 확인합니다. 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.ad.example.com 과 같이 AD(Active Directory) DC(Domain Controller)인 경우 호스트에 대한 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_dnldap_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 기술 지원 케이스를 열고 수집한 문제 해결 정보를 제공합니다.