51장. 인증 및 상호 운용성
SSL을 통해 CA에서 사용자 인증서를 가져올 때 문제
pki user-cert-add 명령은 CA에서 직접 사용자 인증서를 가져오는 옵션을 제공합니다. 잘못된 클라이언트 라이브러리 초기화로 인해 SSL 포트를 통해 명령이 실행되면 다음 오류 메시지와 함께 명령이 실패합니다.
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
이 문제를 해결하려면 pki cert-show 명령을 사용하여 CA의 인증서를 파일로 다운로드합니다. 그런 다음 pki user-cert-add 명령을 사용하여 파일에서 인증서를 업로드합니다. 이 해결 방법을 사용하면 사용자 인증서가 올바르게 추가됩니다. (BZ#1246635)
IdM 웹 UI는 VMDK 테이블의 한 페이지에 모든 인증서를 표시합니다.
IdM(Identity Management) 웹 UI의 Authentication 탭에서 사용할 수 있는 CloudEvent 테이블은 20개 항목의 페이지 크기 제한을 무시합니다. 20개 이상의 인증서를 사용할 수 있는 경우 테이블은 페이지당 20개의 인증서만 표시하는 대신 한 페이지에 모든 인증서를 표시합니다. (BZ#1358836)
ipa-kra-install,ipa-ca-install 또는 ipa-replica-install사용 시 보안 경고
ipa-kra-install,ipa-ca -install 유틸리티를 사용하여 추가 키 복구 기관(KRA) 구성 요소, 인증 기관 또는 복제본을 설치하는 경우 다음 경고가 나타납니다.
SecurityWarning: Certificate has no `subjectAltName`, falling back to check for a `commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818.
이 오류는 RFC 2818로 인해 발생하며, 이 경우 주체 고유 이름(CN) 일반 이름(CN) 필드에 대상 호스트 이름을 이전하는 관행을 더 이상 사용하지 않습니다. 그러나 세 가지 유틸리티가 성공합니다. 따라서 경고 메시지를 무시할 수 있습니다. (BZ#1358457)
gRPC_pkcs11 은 하나의 토큰만 지원합니다.
opensc 및 coolkey 패키지의 PKCS#11 모듈은 다양한 유형의 스마트 카드를 지원합니다. 그러나 CloudEvent_pkcs11 모듈은 한 번에 하나의 모듈만 지원합니다. 결과적으로 동일한 구성을 사용하여 PKCS#15 및 CAC 토큰을 사용할 수 없습니다. 문제를 해결하려면 다음 중 하나를 설치합니다.
- PKCS#15 및 PIV용 opensc 패키지
- CAC, Coolkey 및 PIV 용 coolkey 패키지 (BZ#1367919)
LDAPS로 디렉터리 서버가 구성되지 않은 경우 IdM 복제본에 ipa-ca-install 사용 실패
복제본의 Directory Server가 LDAPS로 구성되지 않은 경우(포트 636)를 통해 TLS 프로토콜을 사용하여 ID 관리(IdM) 복제본에
ipa-ca-install 유틸리티를 사용하여 CA(인증 기관)를 설치할 수 없습니다. 이 오류와 함께 시도가 실패합니다.
[2/30]: configuring certificate server instance ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpsDHYbO' returned non-zero exit status 1 ...
이 경우 복제본을 설치할 수 없습니다. 해결 방법으로 다음 옵션 중 하나를 선택합니다.
- 대신 마스터 서버에 CA를 설치합니다.
ipa-ca-install을 실행하기 전에 복제본에서 LDAPS를 수동으로 활성화합니다.
복제본에서 LDAPS를 수동으로 활성화하려면 다음을 수행합니다.
1.
/etc/httpd/alias 파일에서 서버 인증서를 내보냅니다.
$ pk12util -d /etc/httpd/alias -k /etc/httpd/alias/pwdfile.txt -o temp.p12 -n 'ca1/replica'
ca1/replica 를 인증서의 별 이름으로 바꿉니다.
2. 인증서에서 신뢰 체인을 제거합니다. 이미 가져왔기 때문입니다.
a. 개인 키를 추출합니다.
$ openssl pkcs12 -in temp.p12 -nocerts -nodes -out temp.key
b. 공개 키를 추출합니다.
$ openssl pkcs12 -in temp.p12 -nokeys -clcerts -out temp.pem
c. CA 인증서 없이 PKCS#12 파일을 생성합니다.
$ openssl pkcs12 -export -in temp.pem -inkey temp.key -out repl.p12 -name 'ca1/replica'
ca1/replica 를 인증서의 별 이름으로 바꿉니다.
3. 생성된 인증서를 Directory Server의 NSSDB 데이터베이스로 가져옵니다.
$ pk12util -d /etc/dirsrv/slapd-EXAMPLE-COM -K '' -i repl.p12
4. 임시 인증서 파일을 삭제합니다.
$ rm -f temp.p12 temp.key temp.pem repl.p12
5. 다음 콘텐츠와 함께
/tmp/enable_ssl.ldif 파일을 생성합니다.
dn: cn=encryption,cn=config changetype: modify replace: nsSSL3 nsSSL3: off - replace: nsSSLClientAuth nsSSLClientAuth: allowed - replace: nsSSL3Ciphers nsSSL3Ciphers: default dn: cn=config changetype: modify replace: nsslapd-security nsslapd-security: on
6. SSL을 활성화하도록 LDAP 설정을 수정합니다.
$ ldapmodify -H "ldap://localhost" -D "cn=directory manager" -f /tmp/enable_ssl.ldif -w dm_password
dm_password 를 Directory Manager 암호로 바꿉니다.
7. 다음 콘텐츠와 함께
/tmp/add_rsa.ldif 파일을 만듭니다.
dn: cn=RSA,cn=encryption,cn=config changetype: add objectclass: top objectclass: nsEncryptionModule cn: RSA nsSSLPersonalitySSL: ca1/replica nsSSLToken: internal (software) nsSSLActivation: on
ca1/replica 를 인증서의 별 이름으로 바꿉니다.
8. LDAP에 항목을 추가합니다.
$ ldapadd -H "ldap://localhost" -D "cn=directory manager" -f /tmp/add_rsa.ldif -w dm_password
dm_password 를 Directory Manager 암호로 바꿉니다.
9. 임시 파일을 삭제합니다.
$ rm -f /tmp/enable_ssl.ldif /tmp/add_rsa.ldif
10. 디렉터리 서버를 다시 시작:
# systemctl restart dirsrv@EXAMPLE-COM.service
이 단계를 수행한 후 LDAPS가 활성화되고 복제본에서
ipa-ca-install 을 성공적으로 실행할 수 있습니다. (BZ#1365858)
IdM에 외부 CA를 설치한 후 타사 인증서 신뢰 플래그가 재설정됩니다.
기존 IdM(Identity Management) 도메인에 외부 CA(인증 기관)를 설치하는 데 사용되는 ipa-ca-install --external-ca 명령은 사용자가 외부 CA에 제출해야 하는 CSR(인증서 서명 요청)을 생성합니다.
이전에 설치한 타사 인증서를 사용하여 CSR에 서명하는 경우 NSS 데이터베이스의 타사 인증서 신뢰 플래그가 재설정됩니다. 결과적으로 인증서가 더 이상 trusted로 표시되지 않습니다. 또한
mod_nss 모듈에서 수행한 검사가 실패하고 httpd 서비스가 시작되지 않습니다. 이 상황에서 다음 메시지와 함께 CA 설치에 실패합니다.
CA failed to start after 300 seconds
해결 방법으로 이 메시지가 표시되면 타사 인증서 플래그를 이전 상태로 재설정한 후
httpd 를 다시 시작합니다. 예를 들어 이전에 ca1 인증서에 C, trust 플래그가 있는 경우:
# certutil -d /etc/httpd/alias -n 'ca1' -M -t C,, # systemctl restart httpd.service
이렇게 하면 시스템을 올바른 상태로 복원합니다. (BZ#1318616)
realmd AD에서 컴퓨터 계정을 제거하지 못했습니다.
Red Hat Enterprise Linux는 AD(Active Directory) 도메인 멤버십의 기본 백엔드로 Samba를 사용합니다. 이 경우 realm join 명령과 함께 --ECDHE-name 옵션을 사용하여 컴퓨터 이름을 수동으로 설정한 경우 도메인을 떠나는 경우 AD에서 계정을 제거할 수 없습니다. 이 문제를 해결하려면 --ECDHE-name 옵션을 사용하지 말고 대신
/etc/realmd.conf 파일에 컴퓨터 이름을 추가하십시오. 예를 들면 다음과 같습니다.
[domain.example.com] computer-name = host_name
이 해결 방법을 사용하면 호스트가 도메인에 성공적으로 결합되고 realm leave --remove 명령을 사용하여 도메인을 종료하면 계정이 자동으로 제거됩니다. (BZ#1370457)
SSSD가 LDAP 트리에서 CloudEvent 매핑을 관리하지 못했습니다.
이전에는 SSSD(System Security Services Daemon)가
RFC2307 LDAP 스키마를 사용할 때 CloudEvent 매핑에 대한 잘못된 기본값을 구현했습니다. 패치가 적용되어 스키마와 일치하는 기본값을 수정했습니다. 그러나 이전에 사용한 스키마 SSSD를 사용한 매핑이 포함된 LDAP 서버에 연결하는 사용자는 CloudEvent 특성을 로드할 수 없습니다. 영향을 받는 사용자는 /var/log/ ECDHE 로그 파일에 보고된 다음 오류를 볼 수 있습니다.
Your configuration uses the autofs provider with schema set to rfc2307 and default attribute mappings. The default map has changed in this release, please make sure the configuration matches the server attributes.
이 문제를 해결하려면
/etc/sssd/sssd.conf 파일을 수정하고 기존 특성 매핑을 사용하도록 도메인을 설정합니다.
[domain/EXAMPLE] ... ldap_autofs_map_object_class = automountMap ldap_autofs_map_name = ou ldap_autofs_entry_object_class = automount ldap_autofs_entry_key = cn ldap_autofs_entry_value = automountInformation
따라서 SSSD는 속성에서 CloudEvent 매핑을 로드할 수 있습니다. (BZ#1372814)
pkispawn 의 종속성 목록은 포함되지 않음 openssl
openssl 패키지가 설치되지 않으면
pkispawn 유틸리티를 사용하면 다음과 같은 오류와 함께 실패합니다.
Installation failed: [Errno 2] No such file or directory
이 문제는 openssl 패키지가 pki-core 패키지에 포함된 pki-server 패키지의 런타임 종속성으로 포함되지 않기 때문에 발생합니다. 작업으로
pkispawn 을 실행하기 전에 openssl 를 설치합니다. (BZ#1376488)
많은 사용자 수를 지정하면 CPU 로드가 증가하여 다른 작업이 느려집니다.
enumerate=true 가 etc/sssd/sssd.conf 파일에 설정되고 많은 수의 사용자(예: iPXE 사용자)가 LDAP 서버에 있는 경우 특정 성능 문제가 발생합니다.
sssd_be프로세스는 CPU 리소스의 거의 99 %를 사용합니다.- 로컬 사용자로 로그인하거나 로그아웃하는 등의 특정 작업은 완료하는 데 예기치 않은 시간이 걸립니다.
sysdb및timestamp캐시에서ldbsearch작업을 실행하면 인덱싱된 전체 검색이 모두 실패했음을 보고하는 오류와 함께 실패합니다.
GDM 에서 스마트 카드를 사용하여 인증하지 못했습니다.
스마트 카드 인증을 사용하는 경우 SSSD(System Security Services Daemon) PAM 응답자는 로그인 이름이 Kerberos 사용자 주체 이름(UPN)인지 확인하지 않습니다. 그 결과,
gdm-password pluggable authentication module (PAM)은 사용자 주체 이름(UPN)을 로그인 이름으로 사용할 때 스마트 카드 generated 프롬프트 대신 암호 프롬프트를 표시합니다. 결과적으로 GNOME 디스플레이 관리자(GDM)에 대한 스마트 카드 인증이 실패합니다. (BZ#1389796)
대문자 또는 혼합 케이스 사용자 이름을 사용하는 경우 ipa passwd 명령이 실패합니다.
IdM(Identity Management) 4.4.0은 모든 명령에서 사용자 주체의 통합 처리를 도입했습니다. 그러나 일부 명령은 완전히 변환되지 않았습니다. 그 결과 사용자 이름에 대문자 또는 혼합된 대소문자를 사용하는 경우 ipa passwd 명령이 실패합니다. 이 문제를 해결하려면 ipa passwd 명령을 사용할 때 사용자 이름에 소문자만 사용하십시오. (BZ#1375133)
IdM 웹 UI에서 해지된 인증서의 상태를 올바르게 인식하지 못했습니다.
현재 IdM(Identity Management) 웹 UI에서 인증서 해지 여부를 확인할 수 없습니다. 결과적으로 다음을 수행합니다.
- 사용자, 서비스 또는 호스트 세부 정보 페이지에서 인증서를 볼 때
Revoked기호가 표시되지 않습니다. Revoke작업은 세부 정보 페이지에서 계속 사용할 수 있습니다. 이미 취소된 인증서를 취소하려고 하면 오류 대화 상자가 생성됩니다.- 인증서 보유 (vocation reason 6)로 인해 인증서가 취소 된 경우에도
Remove Hold버튼을 항상 사용할 수 없습니다. (BZ#1371479)
SSSD는 소문자를 사용하여 AD의 sudoUser 속성의 값만 적용합니다.
이전에는 SSSD(System Security Services Daemon)에서 AD(Active Directory)에서
sudo 규칙을 가져올 때 규칙이 할당된 사용자의 samAccountName 속성의 정확한 케이스와 일치해야 했습니다. Red Hat Enterprise Linux 7.3의 회귀 문제로 인해 sudoUser 특성은 이제 소문자 값과만 일치합니다. 이 문제를 해결하려면 sudoUser 특성 값의 이름을 소문자로 변경합니다. 이 해결 방법을 사용하면 sudo 규칙이 올바르게 적용됩니다. (BZ#1380436)
ipa-client 및 ipa-admintools 패키지를 업데이트하지 못할 수 있습니다.
Red Hat Enterprise Linux 7.2에서 Red Hat Enterprise Linux 7.3으로 업그레이드하는 동안 ipa-client 및 ipa-admintools 패키지 업데이트가 실패하는 경우가 있습니다. 이 문제를 해결하려면 Red Hat Enterprise Linux 7.3으로 업그레이드하기 전에 ipa-client 및 ipa-admintools 를 제거한 다음 새 버전의 패키지를 설치합니다. (BZ#1390565)
SSSD 업그레이드로 인해 sssd 프로세스가 종료될 수 있습니다.
sssd 프로세스가 예기치 않게 장기간 작업을 수행하면 내부 워치독 프로세스가 종료됩니다. 그러나 sssd 프로세스는 다시 시작되지 않습니다. 이 문제는 일반적으로 SSSD 데이터베이스에 많은 수의 항목이 포함된 경우 느린 시스템에서 SSSD를 업그레이드하려고 시도하는 동안 발생합니다.
이 문제를 해결하려면 다음을 수행합니다.
1. 중앙 인증 서버를 사용할 수 있는지 확인합니다. 그러면 사용자가 다음 단계에서 SSSD 캐시를 제거한 후 인증할 수 있습니다.
2. 업그레이드하기 전에
sss_cache 유틸리티를 사용하여 SSSD 캐시를 제거합니다.
이 알려진 문제에 대한 수정 사항은 다음 업데이트와 함께 제공됩니다. (BZ#1392441)
디렉터리 서버가 바인딩-dyndb-ldap 스키마 오류로 인해 실패합니다.
Identity Management에 포함된
bind-dyndb-ldap LDAP 스키마 버전에는 구문 오류가 포함되어 있으며 하나의 속성에 대한 설명이 누락되어 있습니다. 사용자가 이 버전의 스키마를 사용하는 경우 Directory Server 구성 요소가 시작되지 않습니다. 결과적으로 오류 메시지가 저널에 기록되어 사용자에게 잘못된 구문을 알립니다.
이 문제를 해결하려면 다음을 수행합니다.
- 업스트림
git.fedorahosted.org리포지토리에서 수정된 스키마 파일을 가져옵니다.# wget https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/doc/schema.ldif?id=17711141882aca3847a5daba2292bcbcc471ec63 -O /usr/share/doc/bind-dyndb-ldap-10.0/schema.ldif
- 수정된 스키마 파일을 Directory Server의 인스턴스 구성 폴더에 복사합니다.
# cp /usr/share/doc/bind-dyndb-ldap-10.0/schema.ldif /etc/dirsrv/slapd-[EXAMPLE-COM]/schema/[SCHEMA_FILE_NAME].ldif
- Directory Server를 다시 시작하십시오.
# systemctl restart dirsrv.target
(BZ#1413805)
