부록 A. 문제 해결
A.1. SSSD 문제 해결
A.1.1. SSSD 도메인의 디버그 로그 설정
각 도메인은 디버그 로그 수준을 설정합니다. 로그 수준을 늘리면 SSSD 또는 도메인 구성과 관련된 문제에 대한 자세한 정보를 제공할 수 있습니다.
로그 수준을 변경하려면 추가 로그를 생성할
sssd.conf 파일의 각 섹션에 대해 debug_level 매개변수를 설정합니다. 예를 들어 다음과 같습니다.
[domain/LDAP]
cache_credentials = true
debug_level = 9| level | Description |
|---|---|
| 0 | 치명적인 오류. SSSD가 시작되지 않거나 실행이 중단되는 모든 항목. |
| 1 | 중요한 오류. SSSD를 강제 종료하지 않지만 하나 이상의 주요 기능이 제대로 작동하지 않을 것임을 나타내는 오류입니다. |
| 2 | 심각한 오류. 특정 요청 또는 작업이 실패했음을 알리는 동안 오류가 발생했습니다. |
| 3 | 사소한 오류. 이는 작업 실패가 발생하여 2를 발생시키는 오류입니다. |
| 4 | 구성 설정. |
| 5 | 기능 데이터. |
| 6 | 작업 기능에 대한 메시지를 추적합니다. |
| 7 | 내부 제어 기능에 대한 메시지를 추적합니다. |
| 8 | 흥미로운 함수 내부 변수의 내용. |
| 9 | 매우 낮은 수준의 추적 정보. |
SSSD가 실행되는 동안 디버그 수준을 변경하려면
sssd-tools 패키지에 포함된 sss_debuglevel 유틸리티를 사용합니다. 작동 방식에 대한 자세한 내용은 sss_debuglevel 도움말 페이지를 참조하십시오.
A.1.2. SSSD 로그 파일 확인
SSSD는 여러 로그 파일을 사용하여
/var/log/sssd/ 디렉터리에 있는 작업에 대한 정보를 보고합니다. SSSD는 각 도메인에 대한 로그 파일과 sssd_pam.log 및 sssd_nss.log 파일을 생성합니다.
krb5_child.log: Kerberos 인증에 관련된 단기 도우미 프로세스의 로그 파일ldap_child.log: LDAP 서버와 통신하는 데 관련된 수명이 짧은 도우미 프로세스의 로그 파일selinux_child.log: SELinux 정보를 검색하는 짧은 도우미 프로세스의 로그 파일sssd.log: 응답자 프로세스와 통신하는 SSSD의 로그 파일sssd_[domain].log: 각 SSSD domain 섹션은 LDAP 서버와의 통신에 대한 정보를 별도의 로그 파일로 기록합니다.sssd_ifp.log: InfoPipe 응답자의 로그 파일은 시스템 버스를 통해 액세스할 수 있는 공용 D-Bus 인터페이스를 제공합니다.sssd_nss.log: 사용자 및 그룹 정보를 검색하는NSS(Name Services Switch)의 로그 파일sssd_pac.log: SSSD가 Kerberos로 작동하는 방식을 정의하는 PAC(Microsoft Privilege Attribute Certificate) 응답자 서비스에 대한 로그 파일 Active Directory 사용자 및 그룹 관리sssd_pam.log: PAM(Pluggable Authentication Module) 응답자의 로그 파일sssd_ssh.log: SSH 응답자 프로세스의 로그 파일
또한
/var/log/secure 파일은 인증 실패와 실패 이유를 기록합니다.
A.1.3. SSSD 설정 문제
- 질문 SSSD 시작 실패
- 질문 getent 그룹이 있는 id 또는 그룹 멤버가 있는 그룹은 표시되지 않습니다.
- 질문 LDAP에 대한 인증이 실패합니다.
- 질문 비표준 포트의 LDAP 서버에 연결하지 못했습니다.
- 질문 NSS에서 사용자 정보를 반환하지 못했습니다
- 질문 NSS가 잘못된 사용자 정보를 반환합니다
- 질문 로컬 SSSD 사용자의 암호 설정에 대해 두 번 메시지가 표시됩니다.
- 질문 Active Directory ID 공급자는 sssd.conf 파일에 올바르게 구성되어 있지만 SSSD가 GSS-API 오류와 함께 연결할 수 없습니다.
- 질문 중앙 인증을 위해 SSSD를 구성했지만 이제 내 애플리케이션(예: Firefox 또는 Adobe)이 시작되지 않습니다.
- 질문 SSSD에서 제거한 자동 마운트 위치를 보여줍니다.
질문
SSSD 시작 실패
답변
SSSD에서는 데몬을 시작하기 전에 필요한 모든 항목을 구성 파일을 올바르게 설정해야 합니다.
- SSSD를 사용하려면 서비스를 시작하기 전에 하나 이상의 올바르게 구성된 도메인이 필요합니다. 도메인이 없으면 SSSD를 시작하려고 하면 도메인이 구성되지 않은 오류가 반환됩니다.
# sssd -d4 -i [sssd] [ldb] (3): server_sort:Unable to register control with rootdse! [sssd] [confdb_get_domains] (0): No domains configured, fatal error! [sssd] [get_monitor_config] (0): No domains configured.
/etc/sssd/sssd.conf파일을 편집하고 하나 이상의 도메인을 생성합니다. - SSSD를 시작하기 전에 하나 이상의 사용 가능한 서비스 공급자도 필요합니다. 서비스 공급자 구성에 문제가 있으면 서비스가 구성되지 않았음을 오류 메시지에 표시합니다.
[sssd] [get_monitor_config] (0): No services configured!
/etc/sssd/sssd.conf파일을 편집하고 하나 이상의 서비스 공급자를 구성합니다.중요SSSD를/etc/sssd/sssd.conf파일의 단일서비스항목에 쉼표로 구분된 목록으로 구성해야 합니다. 서비스가 여러 항목에 나열된 경우 마지막 항목만 SSSD에서 인식됩니다. - SSSD에는
/etc/sssd/sssd.conf의 소유권 및 권한도 올바르게 설정되어야 합니다. 소유권 또는 권한이 잘못 설정된 경우 SSSD를 시작하면 다음 오류 메시지를 반환합니다.[sssd] [confdb_ldif_from_ini_file] (0x0020): Permission check on config file failed. [sssd] [confdb_init_db] (0x0020): Cannot convert INI to LDIF [1]: [Operation not permitted] [sssd] [confdb_setup] (0x0010): ConfDB initialization has failed [1]: Operation not permitted [sssd] [load_configuration] (0x0010): Unable to setup ConfDB [1]: Operation not permitted [sssd] [main] (0x0020): Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root.
/etc/sssd/sssd.conf파일의 올바른 소유권 및 권한을 설정합니다.# chmod 600 /etc/sssd/sssd.conf # chown root:root /etc/sssd/sssd.conf
질문
getent 그룹이 있는 id 또는 그룹 멤버가 있는 그룹은 표시되지 않습니다.
답변
이는
sssd.conf 의 [domain/DOMAINNAME] 섹션에 있는 잘못된 ldap_schema 설정으로 인해 발생할 수 있습니다.
SSSD는 RFC 2307 및 RFC 2307bis 스키마 유형을 지원합니다. 기본적으로 SSSD에서는 보다 일반적인 RFC 2307 스키마를 사용합니다.
RFC 2307과 RFC 2307bis의 차이점은 그룹 멤버십이 LDAP 서버에 저장되는 방식입니다. RFC 2307 서버에서 그룹 멤버는 멤버인 사용자 이름을 포함하는 다중 값
memberuid 속성으로 저장됩니다. RFC2307bis 서버에서 그룹 멤버는 이 그룹의 멤버인 사용자 또는 그룹의 DN을 포함하는 다중 값 멤버 또는 uniqueMember 속성으로 저장됩니다. RFC2307bis를 사용하면 중첩 그룹도 유지 관리할 수 있습니다.
그룹 조회가 정보를 반환하지 않는 경우:
- ldap_schema 를 rfc2307bis 로 설정합니다.
- Delete
/var/lib/sss/db/cache_DOMAINNAME.ldb. - SSSD 다시 시작.
이 기능이 작동하지 않으면 다음 행을
sssd.conf 에 추가하십시오.
ldap_group_name = uniqueMember
그런 다음 캐시를 삭제하고 SSSD를 다시 시작합니다.
질문
LDAP에 대한 인증이 실패합니다.
답변
인증을 수행하려면 SSSD에서 통신 채널을 암호화해야 합니다. 즉,
sssd.conf 가 표준 프로토콜(ldap://)을 통해 연결하도록 구성된 경우 Start TLS를 사용하여 통신 채널을 암호화하려고 합니다. sssd.conf 가 보안 프로토콜(ldaps://)을 통해 연결하도록 구성된 경우 SSSD는 SSL을 사용합니다.
즉, LDAP 서버는 SSL 또는 TLS에서 실행되도록 구성해야 합니다. 보안 LDAPS 포트(636)에서 표준 LDAP 포트(389) 또는 SSL을 활성화하려면 TLS를 활성화해야 합니다. SSL 또는 TLS를 사용하면 LDAP 서버도 유효한 인증서 신뢰로 구성해야 합니다.
잘못된 인증서 신뢰는 LDAP 인증에 가장 일반적인 문제 중 하나입니다. 클라이언트에 LDAP 서버 인증서에 대한 신뢰가 없으면 연결을 검증할 수 없으며 SSSD에서 암호를 보내는 것을 거부합니다. LDAP 프로토콜에서는 일반 텍스트로 암호를 LDAP 서버로 보내야 합니다. 암호화되지 않은 연결을 통해 일반 텍스트로 암호를 전송하는 것은 보안 문제입니다.
인증서를 신뢰할 수 없는 경우 TLS 암호화를 시작할 수 없음을 나타내는
syslog 메시지가 기록됩니다. 인증서 구성은 SSSD와 별도로 LDAP 서버에 액세스할 수 있는지 확인하여 테스트할 수 있습니다. 예를 들어, 이 테스트에서는 TLS 연결을 통해 test.example.com 에 대한 익명 바인딩을 테스트합니다.
$ ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com
인증서 신뢰가 올바르게 구성되지 않은 경우 이 오류와 함께 테스트가 실패합니다.
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
인증서를 신뢰하려면 다음을 수행합니다.
- LDAP 서버 인증서에 서명하는 데 사용되는 인증 기관의 공용 CA 인증서 사본을 가져와 로컬 시스템에 저장합니다.
- 파일 시스템의 CA 인증서를 가리키는
sssd.conf파일에 행을 추가합니다.ldap_tls_cacert = /path/to/cacert
- LDAP 서버에서 자체 서명된 인증서를 사용하는 경우
sssd.conf파일에서 ldap_tls_reqcert 행을 제거합니다.이 매개변수는 자체 서명된 CA 인증서가 있는 보안 위험인 CA 인증서에서 발급한 인증서를 신뢰하도록 SSSD에 지시합니다.
질문
비표준 포트의 LDAP 서버에 연결하지 못했습니다.
답변
강제 모드에서 SELinux를 실행하는 경우 비표준 포트를 통해 LDAP 서버에 연결하도록 클라이언트의 SELinux 정책을 수정해야 합니다. 예를 들어 다음과 같습니다.
# semanage port -a -t ldap_port_t -p tcp 1389
질문
NSS에서 사용자 정보를 반환하지 못했습니다
답변
일반적으로 SSSD는 NSS 서비스에 연결할 수 없음을 의미합니다.
- NSS 서비스가 실행 중인지 확인합니다.
# service sssd status Redirecting to /bin/systemctl status sssd.service sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) Active: active (running) since Wed 2015-01-14 10:17:26 CET; 1min 30s ago Process: 683 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) Main PID: 745 (sssd) CGroup: /system.slice/sssd.service ├─745 /usr/sbin/sssd -D -f ├─746 /usr/libexec/sssd/sssd_be --domain default --debug-to-files... ├─804 /usr/libexec/sssd/sssd_nss --debug-to-files └─805 /usr/libexec/sssd/sssd_pam --debug-to-filesSSSD가활성(실행 중) 상태이고 출력에있습니다.sssd_nss가 포함된 경우 NSS 서비스가 실행되고 - NSS가 실행 중인 경우
/etc/sssd/sssd.conf파일의[nss]섹션에 공급자가 올바르게 구성되었는지 확인합니다. 특히filter_users및filter_groups속성을 확인합니다. - NSS가 SSSD에서 사용하는 서비스 목록에 포함되어 있는지 확인합니다.
/etc/nsswitch.conf파일에서 구성을 확인합니다. 자세한 내용은 “SSSD를 사용하도록 NSS 서비스 구성” 의 내용을 참조하십시오.
질문
NSS가 잘못된 사용자 정보를 반환합니다
답변
검색에서 잘못된 사용자 정보를 반환하는 경우 별도의 도메인에 사용자 이름과 충돌하지 않는지 확인합니다. 도메인이 여러 개인 경우
/etc/sssd/sssd.conf 파일에서 use_fully_qualified_domains 속성을 true 로 설정합니다. 이는 동일한 이름으로 다른 도메인의 여러 사용자 간에 구분됩니다.
질문
로컬 SSSD 사용자의 암호 설정에 대해 두 번 메시지가 표시됩니다.
답변
로컬 SSSD 사용자 암호를 변경하려고 할 때 암호를 두 번 입력하라는 메시지가 표시될 수 있습니다.
[root@clientF11 tmp]# passwd user1000 Changing password for user user1000. New password: Retype new password: New Password: Reenter new Password: passwd: all authentication tokens updated successfully.
이는 잘못된 PAM 구성의 결과입니다.
use_authtok 옵션이 /etc/pam.d/system-auth 파일에 올바르게 구성되었는지 확인합니다. 올바른 구성의 예는 7.5.2절. “서비스 구성: PAM” 을 참조하십시오.
질문
Active Directory ID 공급자는
sssd.conf 파일에 올바르게 구성되어 있지만 SSSD가 GSS-API 오류와 함께 연결할 수 없습니다.
답변
SSSD는 호스트 이름을 사용하여 Active Directory 공급자만 연결할 수 있습니다. 호스트 이름을 지정하지 않으면 SSSD 클라이언트가 IP 주소를 호스트로 확인할 수 없으며 인증에 실패합니다.
예를 들어 이 구성은 다음과 같습니다.
[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 172.16.0.1
ad_domain = example.com
krb5_canonicalize = False
SSSD 클라이언트는 이 GSS-API 오류를 반환하고 인증 요청이 실패합니다.
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot determine realm for numeric host address)]
이 오류를 방지하려면
ad_server 를 Active Directory 호스트의 이름으로 설정하거나 7.4.3절. “DNS 서비스 검색 구성” 에 설명된 대로 _srv_ 키워드를 사용하여 DNS 서비스 검색을 사용합니다.
질문
중앙 인증을 위해 SSSD를 구성했지만 이제 내 애플리케이션(예: Firefox 또는 Adobe)이 시작되지 않습니다.
답변
64비트 시스템에서도 32비트 애플리케이션에는 암호 및 ID 캐시에 액세스하는 데 사용할 32비트 버전의 SSSD 클라이언트 라이브러리가 필요합니다. 32비트 버전의 SSSD를 사용할 수 없지만 시스템이 SSSD 캐시를 사용하도록 구성된 경우 32비트 애플리케이션을 시작하지 못할 수 있습니다.
예를 들어 권한 거부 오류가 있는 Firefox가 실패할 수 있습니다.
Failed to contact configuration server. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied 2: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied)
Adobe Reader의 경우 오류에 현재 시스템 사용자가 인식되지 않음이 표시됩니다.
[jsmith@server ~]$ acroread (acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (366)
기타 애플리케이션에는 유사한 사용자 또는 권한 오류가 표시될 수 있습니다.
질문
SSSD에서 제거한 자동 마운트 위치를 보여줍니다.
답변
자동 마운트 위치에 대한 SSSD 캐시는 이후에 위치가 변경되거나 제거되어도 유지됩니다. SSSD에서 autofs 정보를 업데이트하려면 다음을 수행합니다.
- A.1.4절. “UID 또는 GID가 변경된 후에는 사용자가 로그인할 수 없습니다.” 에 설명된 대로 autofs 캐시를 제거합니다.
- SSSD를 다시 시작합니다.
# systemctl restart sssd
A.1.4. UID 또는 GID가 변경된 후에는 사용자가 로그인할 수 없습니다.
사용자 또는 그룹 ID가 변경되면 SSSD에서 사용자가 로그인하지 못하도록 합니다.
이것이 의미하는 바:
SSSD는 UID(사용자 ID) 및 그룹 ID(GID)를 기반으로 사용자와 그룹을 인식합니다. 기존 사용자 또는 그룹의 UID 또는 GID가 변경되면 SSSD는 사용자 또는 그룹을 인식하지 못합니다.
문제를 해결하려면 다음을 수행합니다.
sss_cache 유틸리티를 사용하여 SSSD 캐시를 지웁니다.
- sssd-tools 가 설치되어 있는지 확인합니다.
- 특정 사용자에 대한 SSSD 캐시를 지우고 나머지 캐시 레코드를 그대로 두려면 다음을 수행합니다.
# sss_cache --user user_name
전체 도메인에 대한 캐시를 삭제하려면 다음을 수행합니다.# sss_cache --domain domain_name
유틸리티는 사용자, 그룹 또는 도메인에 대해 SSSD 캐시의 레코드를 무효화합니다. 이 후 SSSD는 ID 프로바이더에서 레코드를 검색하여 캐시를 새로 고칩니다.
sss_cache 에 대한 자세한 내용은 sss_cache(8) 도움말 페이지를 참조하십시오.
A.1.5. SSSD 제어 및 상태 유틸리티
SSSD는 sssctl 유틸리티를 제공하여 상태 정보를 가져오고, 문제 해결 중에 데이터 파일을 관리하며, 기타 SSSD 관련 작업을 수행합니다.
- sssctl 을 사용하려면 sssd-tools 패키지를 설치합니다.
[root@server ~]# yum install sssd-tools
- sssctl 의 일부 옵션은 SSSD InfoPipe 응답자를 사용합니다. 이를 활성화하려면
/etc/sssd/sssd.conf의services옵션에ifp를 추가합니다.[sssd] services = nss, sudo, pam, ssh, ifp - SSSD를 다시 시작합니다.
[root@server ~]# systemctl restart sssd.service
A.1.5.1. SSSD 설정 유효성 검사
sssctl config-check 명령은 SSSD 구성 파일에 대한 정적 분석을 수행합니다. 이를 통해 SSSD를 다시 시작하기 전에
/etc/sssd/sssd.conf 파일과 /etc/sssd/conf.d/* 파일을 검증하여 보고서를 수신할 수 있습니다.
명령은 SSSD 구성 파일에서 다음 검사를 수행합니다.
- 권한
- 소유자와 그룹 소유자는
root:root로 설정하고 권한을600으로 설정해야 합니다. - 파일 이름
/etc/sssd/conf.d/의 파일 이름은 접미사.conf를 사용해야 하며 마침표(히드된 파일)로 시작하지 않아야 합니다.- 오타 오류
- 섹션 및 옵션 이름에서 오타 오류가 확인됩니다. 값은 확인되지 않습니다.
- 옵션
- 옵션은 올바른 섹션에 배치해야 합니다.
구성을 확인하려면 다음을 실행합니다.
# sssctl config-check Issues identified by validators: 3 [rule/allowed_sections]: Section [paM] is not allowed. Check for typos. [rule/allowed_domain_options]: Attribute 'offline_timeoutX' is not allowed in section 'domain/idm.example.com'. Check for typos. [rule/allowed_sudo_options]: Attribute 'homedir_substring' is not allowed in section 'sudo'. Check for typos. Messages generated during configuration merging: 2 File /etc/sssd/conf.d/wrong-file-permissions.conf did not pass access check. Skipping. File configuration.conf.disabled did not match provided patterns. Skipping. Used configuration snippet files: 1 /etc/sssd/conf.d/sample.conf
A.1.5.2. 사용자 데이터 표시
sssctl user-checks 명령은 SSSD를 사용자 조회, 인증 및 권한 부여의 백엔드로 사용하는 애플리케이션의 문제를 디버깅하는 데 도움이 됩니다. 명령은 NSS를 통해 사용할 수 있는 사용자 데이터 및 D-Bus 인터페이스에 대한 InfoPipe 응답자를 표시합니다. 표시된 데이터는 사용자가
system-auth PAM 서비스를 사용하여 로그인할 권한이 있는지 여부를 표시합니다.
예를 들어
admin 사용자의 사용자 데이터를 표시하려면 다음을 수행합니다.
# sssctl user-checks admin user: admin action: acct service: system-auth SSSD nss user lookup result: - user name: admin - user id: 1194200000 - group id: 1194200000 - gecos: Administrator - home directory: /home/admin - shell: /bin/bash SSSD InfoPipe user lookup result: - name: admin - uidNumber: 1194200000 - gidNumber: 1194200000 - gecos: Administrator - homeDirectory: /home/admin - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Success PAM Environment: - no env -
추가 옵션은 sssctl user-checks --help 명령의 출력을 참조하십시오.
A.1.5.3. 도메인 정보
도메인 상태에 도메인 SSSD 액세스 목록이 표시되고 해당 상태를 검색할 수 있습니다.
- 신뢰할 수 있는 도메인을 포함하여 SSSD 내에서 사용 가능한 모든 도메인을 나열합니다.
[root@server ~]# sssctl domain-list idm.example.com ad.example.com
- 도메인 idm.example.com의 상태를 검색합니다.
[root@server ~]# sssctl domain-status idm.example.com Online status: Online
A.1.5.4. 캐시된 항목 정보
sssctl 명령을 사용하면 캐시된 항목에 대한 정보를 검색하여 캐시 관련 인증 문제를 조사하고 디버깅할 수 있습니다.
사용자 계정
관리자 의 캐시 정보를 쿼리하려면 다음을 실행합니다.
[root@server ~]# sssctl user-show admin Name: admin Cache entry creation date: 07/10/16 16:09:18 Cache entry last update time: 07/14/16 10:13:32 Cache entry expiration time: 07/14/16 11:43:32 Initgroups expiration time: Expired Cached in InfoPipe: No
그룹 또는 넷 그룹의 캐시 정보를 쿼리하려면 다음을 사용합니다.
[root@server ~]# sssctl group-show groupname [root@server ~]# sssctl netgroup-show netgroupname
A.1.5.5. 로그 파일 잘라내기
문제를 디버깅할 때 sssctl logs-remove 를 사용하여
/var/log/sssd/ 디렉토리의 모든 SSSD 로그 파일을 잘라 새로 생성된 항목만 캡처할 수 있습니다.
[root@server ~]# sssctl logs-remove Truncating log files...
A.1.5.6. SSSD 캐시 제거
SSSD 캐시 데이터베이스 파일을 제거하기 위해 sssctl 명령은
remove-cache 옵션을 제공합니다. 데이터베이스를 제거하기 전에 명령은 자동으로 백업을 생성합니다.
다음 명령을 사용하여 모든 로컬 데이터를 백업하고 SSSD 캐시를 제거합니다.
[root@server ~]# sssctl cache-remove SSSD must not be running. Stop SSSD now? (yes/no) [yes] Creating backup of local data... Removing cache files... SSSD needs to be running. Start SSSD now? (yes/no) [yes]
참고
백업은 로컬 덮어쓰기와 같은 로컬 데이터만
/var/lib/sss/backup/ 디렉터리에 저장합니다.
백업된 콘텐츠를 자동으로 가져오려면 sssctl restore-local-data 를 실행합니다.
A.1.5.7. LDAP 그룹에 대한 정보 얻기에 걸림
LDAP 그룹에 대한 정보를 찾는 데 필요한 작업은 특히 대규모 그룹 또는 중첩 그룹의 경우 매우 오래 걸립니다.
이것이 의미하는 바:
기본적으로 LDAP 그룹 정보 조회는 그룹에 대한 모든 구성원을 반환합니다. 대규모 그룹 또는 중첩 그룹이 포함된 작업의 경우 모든 구성원을 반환하면 프로세스가 더 길어집니다.
문제를 해결하려면 다음을 수행합니다.
사용자가 그룹에 속하는지 평가할 때 그룹 조회에 반환된 멤버십 목록은 사용되지 않습니다. 특히 ID 조회의 경우 성능을 개선하려면 그룹 멤버십 조회를 비활성화합니다.
/etc/sssd/sssd.conf파일을 엽니다.[domain]섹션에서ignore_group_members옵션을true로 설정합니다.[domain/domain_name] [... file truncated ...]
ignore_group_members = true
참고
배포에 compat 트리가 있는 IdM 서버가 포함된 경우 이 옵션을
true 로 설정하지 않아야 합니다.
