검증 단계

1. SSSD에 대한 ssss 항목이 /etc/nsswitch.conf 에 있는지 확인하십시오 :

   passwd:     sss files
   group:      sss files
   netgroup:   sss files
   automount:  sss files
   services:   sss files
   ...

2. pam_sss .so 항목의 /etc/pam.d/system-auth 파일의 내용을 검토합니다.

   # Generated by authselect on Tue Sep 11 22:59:06 2018
   # Do not modify this file manually.
   
   auth        required        pam_env.so
   auth        required        pam_faildelay.so delay=2000000
   auth        [default=1 ignore=ignore success=ok]    pam_succeed_if.so uid >= 1000 quiet
   auth        [default=1 ignore=ignore success=ok]    pam_localuser.so
   auth        sufficient      pam_unix.so nullok try_first_pass
   auth        requisite       pam_succeed_if.so uid >= 1000 quiet_success
   auth        sufficient      pam_sss.so forward_pass
   auth        required        pam_deny.so
   
   account     required        pam_unix.so
   account     sufficient      pam_localuser.so
   ...

절차

1. authselect 프로필을 선택합니다. 예를 들면 다음과 같습니다.

   # authselect select sssd

2. 원하는 변경 사항으로 /etc/authselect/user-nsswitch.conf 파일을 편집합니다.

3. /etc/authselect/user-nsswitch.conf 파일의 변경 사항을 적용합니다.

   # authselect apply-changes

절차

1. authselect create-profile 명령을 사용하여 사용자 지정 프로필을 생성합니다. 예를 들어 준비된 sssd 프로필을 기반으로 user-profile이라는 사용자 지정 프로필을 생성하려면 /etc/nsswitch.conf 파일에서 직접 항목을 구성할 수 있습니다.

   # authselect create-profile user-profile -b sssd --symlink-meta --symlink-pam
   New profile was created at /etc/authselect/custom/user-profile

   주의

   /etc/authselect/custom/user-profile/{password-auth,system-auth,fingercard-auth,smartcard-auth,postlogin} 를 수정하려면 --symlink-pam 옵션 없이 위의 명령을 입력합니다. 이는 authselect-libs 를 업그레이드하는 동안 수정이 지속되도록 하기 위한 것입니다.

   명령에 --symlink-pam 옵션을 포함하면 PAM 템플릿이 복사 대신 원본 프로필 파일에 대한 심볼릭 링크임을 의미합니다. --symlink-meta 옵션을 사용하면 README 및 REQUIREMENTS와 같은 메타 파일이 복사 대신 원본 프로필 파일에 대한 심볼릭 링크입니다. 이렇게 하면 원래 프로필의 PAM 템플릿 및 메타 파일에 대한 향후 모든 업데이트가 사용자 지정 프로필에 반영됩니다.

   이 명령은 /etc/ authselect/custom/user-profile/ 디렉터리에 /etc/ nsswitch.conf 파일의 복사본을 생성합니다.

2. /etc/authselect/custom/user-profile/nsswitch.conf 파일을 구성합니다.

3. authselect select 명령을 실행하고 custom/name_of_the_profile을 매개 변수로 추가하여 사용자 지정 프로필을 선택합니다. 예를 들어 사용자 프로필 프로필 을 선택하려면 다음을 수행합니다.

   # authselect select custom/user-profile

   시스템에 대한 사용자 프로필 프로필 을 선택하면 나중에 Red Hat에서 sssd 프로필이 업데이트되면 /etc/nsswitch.conf 파일에 대한 업데이트를 제외하고 모든 업데이트를 활용할 수 있습니다.

   예 1.1. 프로파일 생성

   다음 절차에서는 dns 또는 myhostname 데이터베이스가 아닌 /etc/hosts 파일의 호스트 이름에 대한 로컬 정적 테이블 조회만 참조하는 sssd 프로필을 기반으로 프로필을 생성하는 방법을 보여줍니다.

   1. 다음 행을 편집하여 /etc/nsswitch.conf 파일을 편집합니다.

      hosts:      files

   2. /etc/nsswitch.conf에 대한 변경 사항을 제외하는 sssd 를 기반으로 사용자 지정 프로필을 생성합니다.

      # authselect create-profile user-profile -b sssd --symlink-meta --symlink-pam

   3. 프로필을 선택합니다.

      # authselect select custom/user-profile

   4. 선택적으로 사용자 지정 프로필을 선택할 수 있는지 확인합니다.

      • 선택한 sssd 프로필에 따라 /etc/pam.d/system-auth 파일을 생성

      • /etc/nsswitch.conf에 구성을 변경하지 않은 상태로 둡니다.

        hosts:      files

        참고

        authselect를 실행하면 sssd 가 반대로 하면 호스트 이름이 dns myhostname이 됩니다.

1. 클라이언트를 원격 프로바이더에 연결하여 ID 및 인증 정보를 검색합니다.
2. 가져온 인증 정보를 사용하여 클라이언트에서 사용자 및 자격 증명의 로컬 캐시를 생성합니다.

1. 기본 /etc/sssd/sssd.conf 파일
2. 기타 *.conf 파일은 /etc/sssd/conf.d/ 에 있는 알파벳순

절차

1. 필수 패키지를 설치합니다.

   # dnf -y install openldap-clients sssd sssd-ldap oddjob-mkhomedir

2. 인증 공급자를 sssd 로 전환 :

   # authselect select sssd with-mkhomedir

3. OpenLDAP 서버의 SSL/TLS 인증서를 발급한 인증 기관에서 루트 CA 서명 인증서 체인이 포함된 core-dirsrv.ca.pem 파일을 /etc/openldap/certs 폴더에 복사합니다.

   # cp core-dirsrv.ca.pem /etc/openldap/certs

4. LDAP 서버의 URL 및 접미사를 /etc/openldap/ldap.conf 파일에 추가합니다.

   URI ldap://ldap-server.example.com/
   BASE dc=example,dc=com

5. /etc/openldap/ldap.conf 파일에서 TLS_CACERT 매개 변수를 /etc/openldap/certs/core-dirsrv.ca.pem에 가리키는 행을 추가합니다.

   # When no CA certificates are specified the Shared System Certificates
   # are in use. In order to have these available along with the ones specified
   # by TLS_CACERTDIR one has to include them explicitly:
   TLS_CACERT /etc/openldap/certs/core-dirsrv.ca.pem

6. /etc/sssd/sssd.conf 파일에서 ldap_uri 및 ldap_search_base 매개변수에 환경 값을 추가하고 ldap_id_use_start_tls 를 True 로 설정합니다.

   [domain/default]
   id_provider = ldap
   autofs_provider = ldap
   auth_provider = ldap
   chpass_provider = ldap
   ldap_uri = ldap://ldap-server.example.com/
   ldap_search_base = dc=example,dc=com
   ldap_id_use_start_tls = True
   cache_credentials = True
   ldap_tls_cacertdir = /etc/openldap/certs
   ldap_tls_reqcert = allow
   
   [sssd]
   services = nss, pam, autofs
   domains = default
   
   [nss]
   homedir_substring = /home
   …

7. /etc/sssd/sssd.conf 에서 [domain] 섹션의 ldap_tls_cacert 및 ldap_tls_reqcert 값을 수정하여 TLS 인증 요구 사항을 지정합니다.

   …
   cache_credentials = True
   ldap_tls_cacert = /etc/openldap/certs/core-dirsrv.ca.pem
   ldap_tls_reqcert = hard
   …

8. /etc/sssd/sssd.conf 파일에 대한 권한을 변경합니다.

   # chmod 600 /etc/sssd/sssd.conf

9. SSSD 서비스와 oddjobd 데몬을 다시 시작하고 활성화합니다.

   # systemctl restart sssd oddjobd
   # systemctl enable sssd oddjobd

10. (선택 사항) LDAP 서버가 더 이상 사용되지 않는 TLS 1.0 또는 TLS 1.1 프로토콜을 사용하는 경우 클라이언트 시스템의 시스템 전체 암호화 정책을 LEGACY 수준으로 전환하여 RHEL이 이러한 프로토콜을 사용하여 통신할 수 있도록 합니다.

    # update-crypto-policies --set LEGACY

    자세한 내용은 RHEL 8의 Strong crypto defaults 및 Red Hat Customer Portal의 약한 암호화 알고리즘 지식 베이스 문서 및 update-crypto-policies(8) 도움말 페이지를 참조하십시오.

절차

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. re_expression 옵션을 사용하여 사용자 지정 정규식을 정의합니다.

   예 4.1. 전역 정규식 정의

   모든 도메인에 대해 정규 표현식을 전역적으로 정의하려면 sssd.conf 파일의 [sssd] 섹션에 re_expression 을 추가합니다.

   다음 전역 표현식을 사용하여 도메인\\username 또는 domain@username 형식으로 사용자 이름을 정의할 수 있습니다:

   [sssd]
   [... file truncated ...]
   re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)

   예 4.2. 특정 도메인의 정규 표현식 정의

   특정 도메인에 대한 정규 표현식을 개별적으로 정의하려면 sssd.conf 파일의 해당 도메인 섹션에 re_expression 을 추가합니다.

   다음 전역 표현식을 사용하여 LDAP 도메인의 domain\\username 또는 domain@username 형식으로 사용자 이름을 정의할 수 있습니다.

   [domain/LDAP]
   [... file truncated ...]
   re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)

절차

1. 루트로 /etc/sssd/sssd.conf 파일을 엽니다.

2. 모든 도메인의 전역적으로 확장을 정의하려면 sssd.conf 의 [sssd] 섹션에 full_name_format 을 추가합니다.

   [sssd]
   [... file truncated ...]
   full_name_format = %1$s@%2$s

   이 경우 사용자 이름이 user@domain.test 로 표시됩니다.

3. 특정 도메인에 대한 사용자 이름 인쇄 형식을 정의하려면 sssd.conf 의 해당 도메인 섹션에 full_name_format 을 추가합니다.

   • %2$s\%1$s 를 사용하여 AD(Active Directory) 도메인의 확장을 구성하려면 다음을 수행합니다.

     [domain/ad.domain]
     [... file truncated ...]
     full_name_format = %2$s\%1$s

     이 경우 사용자 이름이 ad.domain\user 로 표시됩니다.

   • %3$s\%1$s 를 사용하여 AD(Active Directory) 도메인의 확장을 구성하려면 다음을 수행합니다.

     [domain/ad.domain]
     [... file truncated ...]
     full_name_format = %3$s\%1$s

     이 경우 Active Directory 도메인의 플랫 도메인 이름이 AD 로 설정된 경우 사용자 이름이 AD\user 로 표시됩니다.

절차

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. domain 섹션에서 cache_credentials = true 설정을 추가합니다.

   [domain/your-domain-name]
   cache_credentials = true

3. 선택 사항이지만 권장 사항 : ID 공급자를 사용할 수 없는 경우 SSSD에서 오프라인 인증을 허용하는 기간에 대한 시간 제한을 구성합니다.

   1. SSSD에서 작동하도록 PAM 서비스를 구성합니다.

      자세한 내용은 authselect를 사용하여 사용자 인증 구성을 참조하십시오.

   2. offline_credentials_expiration 옵션을 사용하여 시간 제한을 지정합니다.

      제한은 일 단위로 설정됩니다.

      예를 들어 사용자가 마지막으로 로그인한 후 3일 동안 오프라인으로 인증할 수 있도록 지정하려면 다음을 사용합니다.

      [pam]
      offline_credentials_expiration = 3

절차

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. 기본 서버 값을 _srv_ 로 설정합니다.

   LDAP 공급자의 경우 기본 서버는 ldap_uri 옵션을 사용하여 설정됩니다.

   [domain/your-domain-name]
   id_provider = ldap
   ldap_uri = _srv_

3. 서비스 유형을 설정하여 암호 변경 공급자의 서비스 검색을 활성화합니다.

   [domain/your-domain-name]
   id_provider = ldap
   ldap_uri = _srv_
   
   chpass_provider = ldap
   ldap_chpass_dns_service_name = ldap

4. 선택 사항: 기본적으로 서비스 검색에서는 시스템 호스트 이름의 도메인 부분을 도메인 이름으로 사용합니다. 다른 DNS 도메인을 사용하려면 dns_discovery_domain 옵션을 사용하여 도메인 이름을 지정합니다.
5. 선택 사항: 기본적으로 서비스 검색은 LDAP 서비스 유형을 검사합니다. 다른 서비스 유형을 사용하려면 ldap_dns_service_name 옵션을 사용하여 유형을 지정합니다.
6. 선택 사항: 기본적으로 SSSD는 IPv4 주소를 조회합니다. 시도에 실패하면 SSSD에서 IPv6 주소를 조회하려고 시도합니다. 이 동작을 사용자 지정하려면 lookup_family_order 옵션을 사용합니다.

7. 서비스 검색을 사용할 모든 서비스에 대해 DNS 레코드를 DNS 서버에 추가합니다.

   _service._protocol._domain TTL priority weight port host_name

절차

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. access_provider 옵션을 simple 로 설정합니다.

   [domain/your-domain-name]
   access_provider = simple

3. 사용자에 대한 액세스 제어 규칙을 정의합니다.

   1. 사용자에 대한 액세스를 허용하려면 simple_allow_users 옵션을 사용합니다.

   2. 사용자에 대한 액세스를 거부하려면 simple_deny_users 옵션을 사용합니다.

      중요

      특정 사용자에 대한 액세스를 거부하는 경우 다른 모든 사용자에 대한 액세스를 자동으로 허용합니다. 특정 사용자에 대한 액세스 허용은 거부하는 것보다 안전한 것으로 간주됩니다.

4. 그룹에 대한 액세스 제어 규칙을 정의합니다. 다음 중 하나를 선택합니다.

   1. 그룹에 대한 액세스를 허용하려면 simple_allow_groups 옵션을 사용합니다.

   2. 그룹에 대한 액세스를 거부하려면 simple_deny_groups 옵션을 사용합니다.

      중요

      특정 그룹에 대한 액세스를 거부하면 다른 모든 그룹에 대한 액세스를 자동으로 허용합니다. 특정 그룹에 대한 액세스 허용은 거부하는 것보다 안전한 것으로 간주됩니다.

      예 4.3. 특정 사용자 및 그룹에 대한 액세스 허용

      다음 예제에서는 user1, user2 및 group1의 액세스를 허용하는 동시에 다른 모든 사용자에 대한 액세스를 거부합니다.

      [domain/your-domain-name]
      access_provider = simple
      simple_allow_users = user1, user2
      simple_allow_groups = group1

절차

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. [domain] 섹션에서 LDAP 액세스 제어 필터를 지정합니다.

   • LDAP 액세스 공급자의 경우 ldap_access_filter 옵션을 사용합니다. 자세한 내용은 sssd-ldap(5) 도움말 페이지를 참조하십시오.

   • AD 액세스 공급자의 경우 ad_access_filter 옵션을 사용합니다. 자세한 내용은 sssd-ad(5) 도움말 페이지를 참조하십시오.

     예 4.4. 특정 AD 사용자에게 액세스 허용

     예를 들어 admins 사용자 그룹에 속하고 unixHomeDirectory 특성이 설정된 AD 사용자에게만 액세스를 허용하려면 다음을 사용합니다.

     [domain/your-AD-domain-name]
     access provider = ad
     [... file truncated ...]
     ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))

절차

1. 사용자의 현재 정보를 표시합니다.

   # id username

   username 을 사용자 이름으로 바꿉니다.

2. 보조 사용자 이름을 추가합니다:

   # sss_override user-add username -n secondary-username

   username을 사용자 이름으로 바꾸고 secondary-username 을 새 사용자 이름으로 교체합니다.

3. sss_override user-add 명령을 사용하여 첫 번째 재정의를 생성한 후 SSSD를 재시작하여 변경 사항을 적용합니다.

   # systemctl restart sssd

절차

1. 사용자의 현재 UID를 표시합니다.

   # id -u user-name

   user-name 을 사용자 이름으로 변경합니다.

2. 사용자 계정의 UID를 재정의합니다.

   # sss_override user-add user-name -u new-UID

   user-name 을 사용자 이름으로 바꾸고 new-UID 를 새 UID 번호로 바꿉니다.

3. 메모리 내 캐시를 만료합니다.

   # sss_cache --users

4. sss_override user-add 명령을 사용하여 첫 번째 재정의를 생성한 후 SSSD를 재시작하여 변경 사항을 적용합니다.

   # systemctl restart sssd

절차

1. 사용자의 현재 GID를 표시합니다.

   # id -g user-name

   user-name 을 사용자 이름으로 변경합니다.

2. 사용자 계정의 GID를 재정의합니다.

   # sss_override user-add user-name -g new-GID

   user-name 을 사용자 이름으로 바꾸고 new-GID 를 새 GID 번호로 바꿉니다.

3. 메모리 내 캐시를 만료합니다.

   # sss_cache --users

4. sss_override user-add 명령을 사용하여 첫 번째 재정의를 생성한 후 SSSD를 재시작하여 변경 사항을 적용합니다.

   # systemctl restart sssd

절차

1. 사용자의 현재 홈 디렉토리를 표시합니다.

   # getent passwd user-name
   user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash

   user-name 을 사용자 이름으로 변경합니다.

2. 사용자의 홈 디렉터리를 재정의합니다.

   # sss_override user-add user-name -h new-home-directory

   user-name 을 사용자 이름으로 바꾸고 new-home-directory 를 새 홈 디렉터리로 교체합니다.

3. SSSD를 재시작하여 변경 사항을 적용합니다.

   # systemctl restart sssd

절차

1. 사용자의 현재 쉘을 표시합니다.

   # getent passwd user-name
   user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash

   user-name 을 사용자 이름으로 변경합니다.

2. 사용자의 쉘을 재정의합니다.

   # sss_override user-add user-name -s new-shell

   user-name 을 사용자 이름으로 바꾸고 new-shell 을 새 쉘로 바꿉니다.

3. SSSD를 재시작하여 변경 사항을 적용합니다.

   # systemctl restart sssd

절차

1. sssctl 명령에 대한 도움말을 표시하려면 다음을 입력합니다.

   [root@client1 ~]# sssctl --help
   ....

2. 사용 가능한 도메인 목록을 표시하려면 다음을 입력합니다.

절차

1. sssctl 명령에 대한 도움말을 표시하려면 다음을 입력합니다.

   [root@client1 ~]# sssctl --help

2. 특정 도메인에 대한 사용자 데이터를 표시하려면 다음을 입력합니다.

   [root@client1 ~]# sssctl domain-status idm.example.com
   Online status: Online
   
   Active servers:
   IPA: server.idm.example.com
   
   Discovered IPA servers:
   - server.idm.example.com

절차

1. 필요한 도메인 또는 도메인에 액세스하도록 SSSD를 구성합니다. /etc/sssd/sssd.conf 파일의 domain 옵션에서 SSSD를 인증할 수 있는 도메인 을 정의합니다.

   [sssd]
   domains = domain1, domain2, domain3

2. PAM 구성 파일에서 domain 옵션을 설정하여 인증할 수 있는 도메인 또는 도메인을 지정합니다. 예를 들면 다음과 같습니다.

   auth        sufficient    pam_sss.so forward_pass domains=domain1
   account     [default=bad success=ok user_unknown=ignore] pam_sss.so
   password    sufficient    pam_sss.so use_authtok

   이 예에서는 PAM 서비스가 domain1 에 대해서만 인증할 수 있습니다.

절차

1. 현재 인증 구성을 백업합니다.

   # authselect apply-changes -b --backup=ldap-configuration-backup

2. SSSD 패키지를 설치합니다.

   # yum install sssd-ldap sssd-ad sssd-client \
                 sssd-common sssd-common-pac \
                 sssd-krb5 sssd-krb5-common

3. nslcd 및 nscd 서비스를 중지하고 비활성화합니다.

   # systemctl stop nslcd nscd
   # systemctl disable nslcd nscd

4. SSSD 를 사용하여 인증 설정:

   # authselect select sssd with-mkhomedir --force

5. SSSD 구성 파일에 필요한 소유권 및 권한을 설정합니다.

   # chown root:root /etc/sssd/sssd.conf
   # chmod 600 /etc/sssd/sssd.conf

6. 편집을 위해 /etc/sssd/sssd.conf 파일을 엽니다.

7. 다음 구성을 입력하고 example.com 및 dc=example,dc=com 과 같은 값을 환경에 적합한 값으로 바꿉니다.

   [sssd]
   config_file_version = 2
   services = nss, pam
   domains = EXAMPLE.COM
   debug_level = 6
   
   [domain/EXAMPLE.COM]
   id_provider = ldap
   auth_provider = ldap
   ldap_uri = ldap://server.example.com/
   ldap_search_base = dc=example,dc=com
   ldap_default_bind_dn = CN=binddn,DC=example,DC=com
   ldap_default_authtok_type = password
   ldap_default_authtok = <bind_account_password>
   cache_credentials = True

   참고

   SSSD 구성에서 LDAP 스키마를 지정해야 할 수 있습니다.

   디렉터리 서버에서 RFC-2307bis 스키마를 사용하는 경우 [domain/EXAMPLE.COM] 섹션에 다음 행을 추가하십시오.

   ldap_schema = rfc2307bis

   Microsoft Active Directory 서버를 사용하는 경우 [domain/EXAMPLE.COM] 섹션에 다음 행을 추가하여 LDAP 기반 인증을 활성화합니다.

   ldap_schema = ad

   Kerberos 인증이 필요한 경우 Red Hat은 SSSD 서비스를 자동으로 구성하는 realm 명령을 사용하여 RHEL 클라이언트를 AD 도메인에 가입하는 것이 좋습니다.

8. SSSD 서비스를 활성화하고 시작합니다.

   # systemctl enable sssd
   # systemctl start sssd

검증 단계

1. LDAP 사용자에 대한 정보를 검색할 수 있는지 확인합니다.

   # id ldapuser
    uid=100424(ldapuser) gid=100424(ldapuser) groups=100424(ldapuser)
   
   # getent passwd ldapuser
   ldapuser:*: 100424: 100424:User, LDAP:/home/ldapuser:/bin/bash

2. LDAP 사용자로 로그인할 수 있는지 확인합니다.

   # ssh -l ldapuser localhost
   ldapuser@localhost's password:
   Last login: Tue Dec 07 19:34:35 2021 from localhost
   -sh-4.2$

1. getent 명령은 libc 라이브러리에서 getpwnam 호출을 트리거합니다.
2. libc 라이브러리는 /etc/nsswitch.conf 구성 파일을 참조하여 사용자 정보 제공을 담당하는 서비스를 확인하고 SSSD 서비스에 대한 항목을 검색합니다.
3. libc 라이브러리는 nss_sss 모듈을 엽니다.
4. nss_sss 모듈은 사용자 정보에 대한 메모리 매핑 캐시를 확인합니다. 데이터가 캐시에 있는 경우 nss_sss 모듈에서 해당 데이터를 반환합니다.
5. 사용자 정보가 메모리 매핑 캐시에 없는 경우 요청이 SSSD sssd_nss 응답자 프로세스에 전달됩니다.
6. SSSD 서비스는 해당 캐시를 확인합니다. 데이터가 캐시에 있고 유효한 경우 sssd_nss 응답자가 캐시에서 데이터를 읽고 애플리케이션에 반환합니다.
7. 데이터가 캐시에 없거나 만료된 경우 sssd_nss 응답자가 적절한 백엔드 프로세스를 쿼리하고 응답을 기다립니다. SSSD 서비스는 sssd.conf 구성 파일에서 id_provider=ipa 를 설정하여 활성화되는 IdM 환경에서 IPA 백엔드를 사용합니다.
8. sssd_be 백엔드 프로세스는 IdM 서버에 연결하고 IdM LDAP 디렉터리 서버에서 정보를 요청합니다.
9. IdM 서버의 SSSD 백엔드는 IdM 클라이언트의 SSSD 백엔드 프로세스에 응답합니다.
10. 클라이언트의 SSSD 백엔드는 결과 데이터를 SSSD 캐시에 저장하고 캐시가 업데이트되었음을 응답 프로세스를 경고합니다.
11. sssd_nss 프론트엔드 응답자 프로세스는 SSSD 캐시에서 정보를 검색합니다.
12. sssd_nss 응답자가 사용자 정보를 nss_sss 응답자에게 전송하여 요청을 완료합니다.
13. libc 라이브러리는 사용자 정보를 요청한 애플리케이션에 반환합니다.

1. IdM 클라이언트는 AD 사용자 정보를 위해 로컬 SSSD 캐시를 찾습니다.
2. IdM 클라이언트에 사용자 정보가 없거나 정보가 오래된 경우 클라이언트의 SSSD 서비스는 IdM 서버의 extdom_extop 플러그인에 연결하여 LDAP 확장 작업을 수행하고 정보를 요청합니다.
3. IdM 서버의 SSSD 서비스는 로컬 캐시에서 AD 사용자 정보를 찾습니다.
4. IdM 서버에 SSSD 캐시에 사용자 정보가 없거나 정보가 오래된 경우 LDAP 검색을 수행하여 AD 도메인 컨트롤러에서 사용자 정보를 요청합니다.
5. IdM 서버의 SSSD 서비스는 AD 도메인 컨트롤러에서 AD 사용자 정보를 수신하여 캐시에 저장합니다.
6. extdom_extop 플러그인은 IdM 서버의 SSSD 서비스에서 LDAP 확장 작업을 완료하는 정보를 받습니다.
7. IdM 클라이언트의 SSSD 서비스는 LDAP 확장 작업에서 AD 사용자 정보를 받습니다.
8. IdM 클라이언트는 AD 사용자 정보를 SSSD 캐시에 저장하고 요청한 애플리케이션에 정보를 반환합니다.

1. ssh 명령을 사용한 인증 시도는 libpam 라이브러리를 트리거합니다.

2. libpam 라이브러리는 인증 시도를 요청하는 서비스에 해당하는 /etc/pam.d/ 디렉터리에서 PAM 파일을 참조합니다. 이 예에서는 로컬 호스트의 SSH 서비스를 통한 인증과 함께 libpam 라이브러리에서 /etc/pam.d/system-auth 구성 파일을 확인하고 SSSD PAM에 대한 pam_sss.so 항목을 검색합니다.

   auth    sufficient    pam_sss.so

3. 사용 가능한 인증 방법을 결정하기 위해 libpam 라이브러리는 pam_sss 모듈을 열고 SSSD 서비스의 sssd _pam PAM 응답자에게 SSS_PAM_ PREAUTH 요청을 전송합니다.
4. 스마트 카드 인증이 구성된 경우 SSSD 서비스는 스마트 카드를 확인하고 여기에서 인증서를 검색하는 임시 p11_child 프로세스를 생성합니다.
5. 사용자에 대해 스마트 카드 인증이 구성된 경우 sssd_pam responder는 사용자와 함께 스마트 카드의 인증서 일치를 시도합니다. sssd_pam responder는 그룹 멤버십이 액세스 제어에 영향을 미칠 수 있으므로 사용자가 속한 그룹에 대한 검색도 수행합니다.
6. sssd_pam responder는 SSS_PAM_PREAUTH 요청을 sssd_be 백엔드 응답자에게 전송하여 서버가 지원하는 인증 방법(예: 암호 또는 2 단계 인증)을 확인합니다. SSSD 서비스가 IPA 응답자를 사용하는 IdM 환경에서 기본 인증 방법은 Kerberos입니다. 이 예에서는 사용자가 간단한 Kerberos 암호를 사용하여 인증합니다.
7. sssd_be 응답자는 temporary krb5_child 프로세스를 생성합니다.
8. The krb5_child 프로세스는 IdM 서버의 KDC에 접속하고 사용 가능한 인증 방법을 확인합니다.

9. KDC는 요청에 응답합니다.

   1. The krb5_child 프로세스는 응답을 평가하고 결과를 sssd_be 백엔드 프로세스로 다시 보냅니다.
   2. sssd_be 백엔드 프로세스는 결과를 수신합니다.
   3. sssd_pam responder는 결과를 수신합니다.
   4. pam_sss 모듈은 결과를 수신합니다.
10. 사용자에 대해 암호 인증이 구성된 경우 pam_sss 모듈은 사용자에게 암호를 요청합니다. 스마트 카드 인증이 구성된 경우 pam_sss 모듈은 사용자에게 스마트 카드 PIN을 묻는 메시지를 표시합니다.

11. 이 모듈은 SSS_PAM_AUTHENTICATE 요청을 보냅니다. 이 요청은 다음과 같이 이동합니다.

    1. sssd_pam 응답자.
    2. sssd_be 백엔드 프로세스.
12. sssd_be 프로세스는 KDC에 연결하기 위해 temporary krb5_child 프로세스를 생성합니다.
13. The krb5_child 프로세스는 사용자가 제공한 사용자 이름과 암호를 사용하여 KDC에서 Kerberos Ticket Granting Ticket(TGT)을 검색하려고 시도합니다.
14. The krb5_child 프로세스는 인증 시도의 결과를 수신합니다.

15. The krb5_child 프로세스:

    1. TGT를 자격 증명 캐시에 저장합니다.
    2. sssd_be 백엔드 프로세스에 인증 결과를 반환합니다.

16. 인증 결과는 sssd_be 프로세스에서 다음과 같이 이동합니다.

    1. sssd_pam 응답자.
    2. pam_sss 모듈.
17. pam_sss 모듈은 다른 애플리케이션에서 참조할 수 있도록 사용자 TGT의 위치로 환경 변수를 설정합니다.

절차

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_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 기술 지원 케이스를 열고 수집한 문제 해결 정보를 제공합니다.

절차

1. 텍스트 편집기에서 /etc/sssd/sssd.conf 파일을 엽니다.

2. 파일의 모든 섹션에 debug_level 옵션을 추가하고 debug 수준을 선택한 상세 정보로 설정합니다.

   [domain/example.com]
   debug_level = 6
   id_provider = ipa
   ...
   
   [sssd]
   debug_level = 6
   services = nss, pam, ifp, ssh, sudo
   domains = example.com
   
   [nss]
   debug_level = 6
   
   [pam]
   debug_level = 6
   
   [sudo]
   debug_level = 6
   
   [ssh]
   debug_level = 6
   
   [pac]
   debug_level = 6
   
   [ifp]
   debug_level = 6

3. sssd.conf 파일을 저장하고 닫습니다.

4. SSSD 서비스를 다시 시작하여 새 구성 설정을 로드합니다.

   [root@server ~]# systemctl restart sssd

절차

1. IdM 서버에서 자세한 SSSD 디버그 로깅을 활성화합니다.

   [root@server ~]# sssctl debug-level 6

2. 인증 문제가 발생한 사용자에 대해 SSSD 캐시에 있는 개체를 무효화하므로 LDAP 서버를 우회하지 않고 SSSD에 이미 캐시된 정보를 검색하지 않습니다.

   [root@server ~]# sssctl cache-expire -u idmuser

3. 이전 SSSD 로그를 제거하여 문제 해결 최소화.

   [root@server ~]# sssctl logs-remove

4. 시도 전후에 타임 스탬프를 수집하는 동안 인증 문제가 발생한 사용자로 전환하십시오. 이러한 타임스탬프는 데이터 공간의 범위를 더 좁힙니다.

   [root@server sssd]# date; su idmuser; date
   Mon Mar 29 15:33:48 EDT 2021
   su: user idmuser does not exist
   Mon Mar 29 15:33:49 EDT 2021

5. (선택 사항) 자세한 SSSD 로그를 계속 수집하지 않으려면 디버그 수준을 낮춥니다.

   [root@server ~]# sssctl debug-level 2

6. 실패한 요청에 대한 정보는 SSSD 로그를 검토합니다. 예를 들어, /var/log/sssd/sssd_example.com.log 파일을 검토하면 SSSD 서비스에서 cn=accounts,dc=example,dc=com LDAP 하위 트리에서 사용자를 찾지 못했음을 확인할 수 있습니다. 이는 사용자가 없거나 다른 위치에 있음을 나타낼 수 있습니다.

   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][name=idmuser@example.com]
   ...
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=idmuser)(objectclass=posixAccount)(uid=)(&(uidNumber=)(!(uidNumber=0))))][cn=accounts,dc=example,dc=com].
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results.
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory)
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:49 2021) [sssd[be[example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request

7. 인증 문제의 원인을 확인할 수 없는 경우:

   1. 최근에 생성한 SSSD 로그를 수집합니다.

      [root@server ~]# sssctl logs-fetch sssd-logs-Mar29.tar

   2. Red Hat 기술 지원 케이스를 열고 다음을 제공합니다.

      1. SSSD 로그: sssd-logs-Mar29.tar

      2. 로그에 해당하는 요청의 타임스탬프 및 사용자 이름을 포함한 콘솔 출력입니다.

         [root@server sssd]# date; id idmuser; date
         Mon Mar 29 15:33:48 EDT 2021
         id: ‘idmuser’: no such user
         Mon Mar 29 15:33:49 EDT 2021

절차

1. 클라이언트에서 다음을 수행합니다. 텍스트 편집기에서 /etc/sssd/sssd.conf 파일을 엽니다.

2. 클라이언트에서 다음을 수행합니다. ipa_server 옵션을 파일의 [domain] 섹션에 추가하고 IdM 서버로 설정합니다. 이렇게 하면 IdM 클라이언트가 다른 IdM 서버를 자동으로 검색하지 않으므로 이 테스트가 하나의 클라이언트와 서버로만 제한됩니다.

   [domain/example.com]
   ipa_server = server.example.com
   ...

3. 클라이언트에서 다음을 수행합니다. sssd.conf 파일을 저장하고 닫습니다.

4. 클라이언트에서 다음을 수행합니다. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.

   [root@client ~]# systemctl restart sssd

5. 서버 및 클라이언트에서 다음을 수행합니다. 자세한 SSSD 디버그 로깅을 활성화합니다.

   [root@server ~]# sssctl debug-level 6

   [root@client ~]# sssctl debug-level 6

6. 서버 및 클라이언트에서 다음을 수행합니다. 인증 문제가 발생한 사용자에게 SSSD 캐시에 있는 개체를 무효화하므로 LDAP 데이터베이스를 우회하지 않고 SSSD에 이미 캐시된 정보를 검색하지 않습니다.

   [root@server ~]# sssctl cache-expire -u idmuser

   [root@client ~]# sssctl cache-expire -u idmuser

7. 서버 및 클라이언트에서 다음을 수행합니다. 이전 SSSD 로그를 제거하여 문제 해결 최소화.

   [root@server ~]# sssctl logs-remove

   [root@server ~]# sssctl logs-remove

8. 클라이언트에서 다음을 수행합니다. 시도 전후에 타임스탬프를 수집하는 동안 인증 문제가 발생한 사용자로 전환합니다. 이러한 타임스탬프는 데이터 공간의 범위를 더 좁힙니다.

   [root@client sssd]# date; su idmuser; date
   Mon Mar 29 16:20:13 EDT 2021
   su: user idmuser does not exist
   Mon Mar 29 16:20:14 EDT 2021

9. (선택 사항) 서버 및 클라이언트에서 다음을 수행합니다. 자세한 SSSD 로그를 계속 수집하지 않으려면 디버그 수준을 낮추십시오.

   [root@server ~]# sssctl debug-level 0

   [root@client ~]# sssctl debug-level 0

10. 서버 및 클라이언트에서 다음을 수행합니다. 실패한 요청에 대한 정보는 SSSD 로그를 검토합니다.

    1. 클라이언트 로그에서 클라이언트의 요청을 검토합니다.
    2. 서버 로그에서 클라이언트의 요청을 검토합니다.
    3. 서버 로그에서 요청 결과를 검토합니다.
    4. 서버에서 요청의 결과를 수신한 클라이언트의 결과를 검토합니다.

11. 인증 문제의 원인을 확인할 수 없는 경우:

    1. IdM 서버 및 IdM 클라이언트에서 최근에 생성한 SSSD 로그를 수집합니다. 호스트 이름 또는 역할에 따라 레이블을 지정합니다.

       [root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar

       [root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar

    2. Red Hat 기술 지원 케이스를 열고 다음을 제공합니다.

       1. SSSD 디버그 로그:

          1. sssd-logs-server-Mar29.tar 서버에서
          2. 클라이언트에서 sssd-logs-client-Mar29.tar

       2. 로그에 해당하는 요청의 타임스탬프 및 사용자 이름을 포함한 콘솔 출력입니다.

          [root@client sssd]# date; su idmuser; date
          Mon Mar 29 16:20:13 EDT 2021
          su: user idmuser does not exist
          Mon Mar 29 16:20:14 EDT 2021

절차

1. SSSD 로그 파일을 검토하려면 less 유틸리티를 사용하여 로그 파일을 엽니다. 예를 들어 /var/log/sssd/sssd_example.com.log:

   [root@server ~]# less /var/log/sssd/sssd_example.com.log

2. 클라이언트 요청에 대한 정보는 SSSD 로그를 검토합니다.

   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_destructor] (0x0400): [RID#3] Number of active DP request: 0
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_reply_std] (0x1000): [RID#3] DP Request AccountDomain #3: Returning [Internal Error]: 3,1432158301,GetAccountDomain() not supported
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] DP Request Account #4: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] Number of active DP request: 1

   SSSD 로그 파일의 이 샘플 출력은 두 개의 다른 요청에 대한 고유 식별자 RID#3 및 RID#4 를 보여줍니다.

절차

1. Firefox의 주소 표시줄에서 about:config 를 입력하여 현재 구성 옵션 목록을 표시합니다.
2. Filter(필터 ) 필드에 negotiate 를 입력하여 옵션 목록을 제한합니다.
3. network.negotiate- auth.trusted-uris 항목을 두 번 클릭합니다.

4. 앞의 기간(.)을 포함하여 인증할 도메인의 이름을 입력합니다. 여러 도메인을 추가하려면 쉼표로 구분된 목록에 입력합니다.

   그림 13.1. 수동 Firefox 설정

   

절차

1. Mozilla Firefox에서 Firefox 메뉴를 열고 Preferences(기본 설정 )를 선택합니다.

   

2. 왼쪽 패널에서 Privacy & Security (개인 정보 보호 및 보안) 섹션을 선택합니다.

   
3. Certificates (인증서) 섹션까지 아래로 스크롤합니다.

4. View Certificates (인증서 보기)를 클릭하여 인증서 관리자를 엽니다.

   

절차

1. Open Certificate Manager (인증서 관리자 열기).

2. Authorities(권한 ) 탭을 선택하고 Import(가져오기 )를 클릭합니다.

   그림 13.2. Firefox에서 CA 인증서 가져오기

   
3. 장치에서 다운로드한 CA 인증서를 선택합니다.

사전 요구 사항

1. 인증서를 가져왔습니다.

절차

1. Open Certificate Manager (인증서 관리자 열기).
2. Authorities(권한 ) 탭에서 적절한 인증서를 선택하고 Edit Trust(신뢰 편집 )를 클릭합니다.

3. 인증서 신뢰 설정을 편집합니다.

   그림 13.3. Firefox에서 인증서 신뢰 설정 편집

   

사전 요구 사항

1. 개인 인증서가 장치에 저장되어 있습니다.

절차

1. Open Certificate Manager (인증서 관리자 열기).

2. Certificates(인증서 ) 탭을 선택하고 Import(가져오기 )를 클릭합니다.

   그림 13.4. Firefox에서 인증용 개인 인증서 가져오기

   
3. 컴퓨터에서 적절한 인증서를 선택합니다.

절차

1. Mozilla Thunderbird에서 주 메뉴를 열고 Preferences(기본 설정 )를 선택합니다.

   그림 13.5. 메뉴에서 기본 설정 선택

   

2. 왼쪽 패널에서 Privacy & Security (개인 정보 보호 및 보안) 섹션을 선택합니다.

   그림 13.6. 보안 섹션 선택

   
3. Certificates (인증서) 섹션까지 아래로 스크롤합니다.

4. Manage Certificates (인증서 관리)를 클릭하여 인증서 관리자를 엽니다.

   그림 13.7. 인증서 관리자 열기

   

절차

1. Open Certificate Manager (인증서 관리자 열기).

2. Authorities(권한 ) 탭을 선택하고 Import(가져오기 )를 클릭합니다.

   그림 13.8. Thunderbird에서 CA 인증서 가져오기

   
3. 다운로드한 CA 인증서를 선택합니다.

절차

1. Open Certificate Manager (인증서 관리자 열기).
2. Authorities(권한 ) 탭에서 적절한 인증서를 선택하고 Edit Trust(신뢰 편집 )를 클릭합니다.

3. 인증서 신뢰 설정을 편집합니다.

   그림 13.9. Thunderbird의 인증서 신뢰 설정 편집

   

사전 요구 사항

1. 개인 인증서가 장치에 저장되어 있습니다.

절차

1. Open Certificate Manager (인증서 관리자 열기).

2. Your Certificates(인증서 ) 탭에서 Import(가져오기 )를 클릭합니다.

   그림 13.10. Thunderbird에서 인증을 위한 개인 인증서 가져오기

   
3. 컴퓨터에서 필요한 인증서를 선택합니다.
4. Certificate Manager 를 닫습니다.

5. 메인 메뉴를 열고 Account Settings (계정 설정)를 선택합니다.

   그림 13.11. 메뉴에서 계정 설정 선택

   

6. 계정 이메일 주소의 왼쪽 패널에서 End-To-End Encryption 을 선택합니다.

   엔드 투 엔드 암호화 섹션 선택.

   
7. S/유럽 섹션에서 첫 번째 선택 버튼을 클릭하여 메시지에 서명하는 데 사용할 개인 인증서를 선택합니다.

8. S/유럽 섹션에서 두 번째 선택 버튼을 클릭하여 메시지를 암호화하고 해독할 개인 인증서를 선택합니다.

   서명 및 암호화/암호 해독을 위한 인증서 선택.