11.11. IdM (Identity Management)
Directory Server에서 접미사에 대한 압축을 구성하지 못했습니다.
Directory Server에서 백엔드 추천을 설정하는 경우 dsconf <instance_name> 백엔드 접미사 set --state computation 명령을 사용하여 백엔드 상태를 설정하면 다음 오류와 함께 실패합니다.
Error: 103 - 9 - 53 - Server is unwilling to perform - [] - need to set nsslapd-referral before moving to referral state
결과적으로 접미사에 대한 약어를 구성하는 데 실패합니다. 문제를 해결하려면 다음을 수행합니다.
nsslapd-referral매개변수를 수동으로 설정합니다.# ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: nsslapd-referral nsslapd-referral: ldap://remote_server:389/dc=example,dc=com
백엔드 상태를 설정합니다.
# dsconf <instance_name> backend suffix set --state referral
결과적으로 해결방법을 사용하여 접미사에 대한 유효성 검사를 구성할 수 있습니다.
dsconf 유틸리티에는 UUID 플러그인에 대한 수정 작업을 생성하는 옵션이 없습니다.
dsconf 유틸리티는 UUID 플러그인에 대한 수정 작업을 생성하는 옵션을 제공하지 않습니다. 결과적으로 관리자는 dsconf 를 사용하여 기존 항목에 entryUUID 특성을 자동으로 추가하는 작업을 생성할 수 없습니다. 이 문제를 해결하려면 작업을 수동으로 생성합니다.
# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x dn: cn=entryuuid_fixup_<time_stamp>,cn=entryuuid task,cn=tasks,cn=config objectClass: top objectClass: extensibleObject basedn: <fixup base tree> cn: entryuuid_fixup_<time_stamp> filter: <filtered_entry>
작업이 생성되면 Directory Server는 누락되거나 유효하지 않은 entryUUID 속성이 있는 항목을 수정합니다.
MIT Kerberos는 PKINIT에 대한 ECC 인증서를 지원하지 않습니다.
MIT Kerberos는 PKINIT( initial authentication)를 위한 공개 키 암호화(ECC) 지원 설계를 설명하는 주석 문서에 대한 RFC5349 요청을 구현하지 않습니다. 결과적으로 RHEL에서 사용하는 MIT>-<5-pkinit 패키지는 ECC 인증서를 지원하지 않습니다. 자세한 내용은 Kerberos (PKINIT)에서 초기 인증의 공개 키 암호화에 대한 ECC (Elliptic Curve Cryptography) 지원을 참조하십시오.
PKINIT가 AD KDC에 대해 작동하도록 RHEL 9 클라이언트에서 DEFAULT:SHA1 하위 정책을 설정해야 합니다.
SHA-1 다이제스트 알고리즘은 RHEL 9에서 더 이상 사용되지 않으며 PKINIT(초기 인증)에 대한 공개 키 암호화에 대한 CMS 메시지는 이제 강력한 SHA-256 알고리즘으로 서명됩니다.
그러나 AD(Active Directory) Kerberos Distribution Center(KDC)는 여전히 SHA-1 다이제스트 알고리즘을 사용하여 CMS 메시지에 서명합니다. 결과적으로 RHEL 9 Kerberos 클라이언트는 ADECDHE에 PKINIT를 사용하여 사용자를 인증하지 못합니다.
이 문제를 해결하려면 다음 명령을 사용하여 RHEL 9 시스템에서 SHA-1 알고리즘에 대한 지원을 활성화합니다.
# update-crypto-policies --set DEFAULT:SHA1
RHEL 9 Kerberos 에이전트가 비 RHEL-9 및 비AD Kerberos 에이전트와 통신하는 경우 사용자의 PKINIT 인증이 실패합니다.
클라이언트 또는 Kerberos 배포 센터(KDC)인 RHEL 9 Kerberos 에이전트가 AD(Active Directory) 에이전트가 아닌 RHEL-9 Kerberos 에이전트와 상호 작용하는 경우 사용자의 PKINIT 인증이 실패합니다. 문제를 해결하려면 다음 작업 중 하나를 수행합니다.
SHA-1 서명을 확인할 수 있도록 RHEL 9 에이전트의 crypto-policy를
DEFAULT:SHA1로 설정합니다.# update-crypto-policies --set DEFAULT:SHA1
SHA-1 알고리즘을 사용하여 CMS 데이터에 서명하지 않도록 RHEL-9 및 비AD 에이전트를 업데이트합니다. 이를 위해 Kerberos 클라이언트 또는 10.0.0.1 패키지를 SHA-1 대신 SHA-256을 사용하는 버전으로 업데이트합니다.
- CentOS 9 스트림:ECDHE5-1.19.1-15
- RHEL 8.7: krb5-1.18.2-17
- RHEL 7.9: krb5-1.15.1-53
- Fedora Rawhide/36:>-<5-1.19.2-7
- Fedora 35/34:>-<5-1.19.2-3
결과적으로 사용자의 PKINIT 인증이 올바르게 작동합니다.
다른 운영 체제의 경우 에이전트가 SHA-1 대신 SHA-256을 사용하여 CMS 데이터에 서명하도록 하는or5-1.20 릴리스입니다.
PKINIT가 AD KDC에 대해 작동하도록 RHEL 9 클라이언트에서 DEFAULT:SHA1 하위 정책을 설정해야 합니다. 을 참조하십시오.
AD 신뢰에 대한 FIPS 지원에는 AD-SUPPORT 암호화 하위 정책이 필요합니다.
Active Directory(AD)는 기본적으로 RHEL 9의 FIPS 모드에서 허용되지 않는 AES SHA-1 HMAC 암호화 유형을 사용합니다. AD 신뢰와 함께 RHEL 9 IdM 호스트를 사용하려면 IdM 소프트웨어를 설치하기 전에 AES SHA-1 HMAC 암호화 유형에 대한 지원을 활성화합니다.
FIPS 컴플라이언스는 기술 및 조직 계약이 모두 포함된 프로세스이므로 AD-SUPPORT 하위 정책을 활성화하여 AES SHA-1 HMAC 암호화 유형을 지원하는 기술 조치를 허용하기 전에 FIPS 감사자를 참조한 다음 RHEL IdM을 설치합니다.
# update-crypto-policies --set FIPS:AD-SUPPORT
RHEL 9ECDHE에 대해 PKINIT를 사용하여 사용자를 인증하지 못했습니다.
기본적으로 Heimdal Kerberos 클라이언트는IKE(Internet Key Exchange)용MODP(MoDP) Diffie-Hellman Group 2를 사용하여 IdM 사용자의 PKINIT 인증을 시작합니다. 그러나 RHEL 9의 MIT Kerberos Distribution Center(KDC)는 MODP 그룹 14 및 16만 지원합니다.
결과적으로 사전 예상 요청이 RHEL MITECDHE에서 허용되지 않는 Heimdal 클라이언트의 PREAUTH_FAILED 오류와 함께Forwarded5_get_init_creds: PREAUTH_FAILED 오류와 함께 실패합니다.
이 문제를 해결하려면 Heimdal 클라이언트가 MODP Group 14를 사용하는지 확인하십시오. 클라이언트 구성 파일의 libdefaults 섹션에 pkinit_dh_min_bits 매개변수를 1759로 설정합니다.
[libdefaults] pkinit_dh_min_bits = 1759
결과적으로 Heimdal 클라이언트는 RHEL MITECDHE에 대한 PKINIT 사전 인증을 완료합니다.
FIPS 모드에서 IdM은 양방향 교차 트러스트를 구축하기 위해 NTLMSSP 프로토콜 사용을 지원하지 않습니다.
New Technology LAN Manager Security Support Provider(NTLMSSP) 인증이 FIPS와 호환되지 않기 때문에 AD(Active Directory)와 FIPS 모드가 활성화된 IdM(Identity Management) 간 신뢰를 두방향으로 설정할 수 없습니다. FIPS 모드에서 IdM은 AD 도메인 컨트롤러가 인증을 시도할 때 사용하는 RC4 NTLM 해시를 허용하지 않습니다.
AD 교차 영역 TGS 요청으로 IdM이 실패
IdM Kerberos 티켓의 PAM(Privilege Properties Certificate) 정보는 이제 AD(Active Directory)에서 지원하지 않는 AES SHA-2 HMAC 암호화로 서명됩니다.
결과적으로 AD 간 TGS 요청(즉, 양방향 신뢰 설정)으로의 IdM이 실패하고 다음 오류가 발생합니다.
Generic error (see e-text) while getting credentials for <service principal>
FIPS 모드에서 IdM Vault 암호화 및 암호 해독 실패
FIPS 모드가 활성화된 경우 OpenSSL RSA-PKCS1v15 패딩 암호화가 차단됩니다. 결과적으로 IdM(Identity Management) Vault는 현재 전송 인증서로 세션 키를 래핑하기 위해 PKCS1v15 패딩을 사용하므로 올바르게 작동하지 않습니다.
iPXE가 없는 사용자는 업그레이드 후 IdM에 로그인할 수 없습니다.
IdM 복제본을 RHEL 9.2로 업그레이드한 후 IdM Kerberos Distribution Center(KDC)는 계정에 할당된 SID(Security Identifiers)가 없는 사용자에게 TGT( ticket-granting ticket)를 발행하지 못할 수 있습니다. 따라서 사용자는 자신의 계정에 로그인할 수 없습니다.
이 문제를 해결하려면 토폴로지의 다른 IdM 복제본에서 IdM 관리자로 다음 명령을 실행하여 CloudEvents를 생성합니다.
# ipa config-mod --enable-sid --add-sids
이후 사용자가 여전히 로그인할 수 없는 경우 Directory Server 오류 로그를 검사합니다. 사용자 POSIX ID를 포함하도록 ID 범위를 조정해야 할 수 있습니다.
자세한 내용은 RHEL9로 업그레이드할 때 IDM 사용자가 더 이상 지식베이스 솔루션에 로그인할 수 없습니다.
Jira:RHELPLAN-157939
레지스트리가 일치하지 않아 마이그레이션된 IdM 사용자가 로그인할 수 없습니다.
ipa migrate-ds 스크립트를 사용하여 한 IdM 배포에서 다른 IdM 배포로 사용자를 마이그레이션하는 경우 이전에 기존의 SID(Security Identifiers)에 현재 IdM 환경의 domainknative가 없기 때문에 IdM 서비스를 사용하는 데 문제가 있을 수 있습니다. 예를 들어 사용자는 kinit 유틸리티를 사용하여 Kerberos 티켓을 검색할 수 있지만 로그인할 수는 없습니다. 이 문제를 해결하려면 다음 지식 베이스 문서를 참조하십시오. 도메인이 일치하지 않아서 로그인할 수 없는 IdM 사용자는 다음 지식 베이스 문서를 참조하십시오.
Jira:RHELPLAN-109613
MIT ECDHE5 사용자가 사용자 PAC를 생성하는 호환되지 않는 암호화 유형으로 인해 AD TGT를 가져오지 못했습니다.
MIT ECDHE5 1.20 이상 패키지에서는 기본적으로 모든 Kerberos 티켓에 권한 속성 인증서(PAC)가 포함됩니다. MIT Kerberos Distribution Center(KDC)는 현재 RFC8009에 정의된 AES HMAC-SHA2 암호화 유형인 PAC에서 CloudEvent 체크섬을 생성할 수 있는 가장 강력한 암호화 유형을 선택합니다. 그러나 AD(Active Directory)는 이 RFC를 지원하지 않습니다. 그 결과, AD-MIT 교차현실 설정에서 MITECDHE 5 사용자가 AD 티켓-granting 티켓(TGT)을 받지 못하는데, MITECDHE에서 생성한 교차 실제 TGT에는 PAC에 호환되지 않는ECDHE 체크섬 유형이 포함되어 있기 때문입니다.
이 문제를 해결하려면 /var/kerberos/krb5kdc/kdc.conf 구성 파일의 [realms] 섹션에 있는 MIT 영역에 대해 disable_pac 매개변수를 true 로 설정합니다. 결과적으로 MITECDHE는 PAC 없이 티켓을 생성하는데, 이는 AD에서 실패한 체크섬 확인을 건너뛰고 MIT TGT 사용자가 AD TGT를 받을 수 있음을 의미합니다.
ldap_id_use_start_tls 옵션에 기본값을 사용할 때 발생할 수 있는 위험
TLS없이 ldap:// 를 ID 조회에 사용하는 경우 공격 벡터가 발생할 위험이 있습니다. 특히 MITM(Man-in-the-middle) 공격으로 공격자는 LDAP 검색에 반환된 오브젝트의 UID 또는 GID를 변경하여 사용자를 가장할 수 있습니다.
현재 TLS를 적용하는 SSSD 구성 옵션인 ldap_id_use_start_tls 는 기본값은 false 입니다. 설정이 신뢰할 수 있는 환경에서 작동하고 id_provider = ldap 에 대해 암호화되지 않은 통신을 안전하게 사용할 수 있는지 결정합니다. 참고 id_provider = ad 및 id_provider = ipa 는 SASL 및 GSSAPI로 보호되는 암호화된 연결을 사용하므로 영향을 받지 않습니다.
암호화되지 않은 통신을 사용하는 것이 안전하지 않은 경우 /etc/sssd/sssd.conf 파일에서 ldap_id_use_start_tls 옵션을 true 로 설정하여 TLS를 적용합니다. 기본 동작은 RHEL의 향후 릴리스에서 변경될 예정입니다.
Jira:RHELPLAN-155168
RHEL 8.6 또는 이전 버전에서 초기화된 FIPS 모드의 IdM 배포에 FIPS 모드에서 RHEL 9 복제본을 추가하는 데 실패합니다.
FIPS 140-3을 준수하려는 기본 RHEL 9 FIPS 암호화 정책은 RFC3961 섹션 5.1에 정의된 대로 AES HMAC-SHA1 암호화 유형의 키 파생 기능을 사용할 수 없습니다.
이 제약 조건은 FIPS 모드에서 RHEL 9 IdM(Identity Management) 복제본을 RHEL 8.6 시스템에 설치된 FIPS 모드의 RHEL 8 IdM 환경에 추가할 때 차단기입니다. 이는 RHEL 9와 이전 RHEL 버전 간에 일반적으로 AES HMAC-SHA1 암호화 유형을 사용하지만 AES HMAC-SHA2 암호화 유형을 사용하지 않기 때문입니다.
서버에 다음 명령을 입력하여 IdM 마스터 키의 암호화 유형을 볼 수 있습니다.
# kadmin.local getprinc K/M | grep -E '^Key:'
이 문제를 해결하려면 RHEL 9 복제본에서 AES HMAC-SHA1을 사용하도록 설정하십시오.
update-crypto-policies --set FIPS:AD-SUPPORT
- 경고
- 이 해결방법은 FIPS 규정 준수를 위반할 수 있습니다.
결과적으로 IdM 배포에 RHEL 9 복제본을 올바르게 추가합니다.
RHEL 7 및 RHEL 8 서버에서 누락된 AES HMAC-SHA2- 암호화 Kerberos 키를 생성하는 절차를 제공하는 작업이 진행 중입니다. 이렇게 하면 RHEL 9 복제본에서 FIPS 140-3 컴플라이언스를 얻을 수 있습니다. 그러나 Kerberos 키 암호화의 설계로 인해 기존 키를 다른 암호화 유형으로 변환할 수 없기 때문에 이 프로세스가 완전히 자동화되지 않습니다. 유일한 방법은 사용자에게 암호를 업데이트하도록 요청하는 것입니다.
SSSD에서 DNS 이름을 올바르게 등록합니다.
이전 버전에서는 DNS가 잘못 설정된 경우 SSSD에서 항상 첫 번째 DNS 이름을 등록하지 못했습니다. 이 문제를 해결하기 위해 이 업데이트에서는 새로운 매개변수 dns_resolver_use_search_list 를 제공합니다. DNS 검색 목록을 사용하지 않도록 dns_resolver_use_search_list = false 를 설정합니다.
Bugzilla:1608496
추천 모드로 시작하면 Directory Server가 예기치 않게 종료됨
버그로 인해 전역 참조 모드가 Directory Server에서 작동하지 않습니다. dirsrv 사용자로 refer 옵션을 사용하여 ns-slapd 프로세스를 시작하면 Directory Server는 포트 설정을 무시하고 예기치 않게 종료됩니다. root 사용자가 프로세스를 실행하면 SELinux 레이블이 변경되고 서비스가 일반 모드에서 시작되지 않습니다. 사용 가능한 해결방법이 없습니다.
Directory Server는 /var/lib/dirsrv/slapd-instance_name/ldif/에서만 LDIF 파일을 가져올 수 있습니다.
RHEL 8.3부터 RHDS(Red Hat Directory Server)는 자체 프라이빗 디렉터리를 사용하며 LDAP 서비스에 대해 privateTmp systemd 지시문이 기본적으로 활성화됩니다. 따라서 RHDS는 /var/lib/dirsrv/slapd--instance_name/ldif/ 디렉터리에서 LDIF 파일만 가져올 수 있습니다. LDIF 파일이 /var/tmp,/tmp, /root 와 같은 다른 디렉토리에 저장되면 가져오기가 실패하고 다음과 유사한 오류가 발생합니다.
Could not open LDIF file "/tmp/example.ldif", errno 2 (No such file or directory)
이 문제를 해결하려면 다음 단계를 완료하십시오.
LDIF 파일을
/var/lib/dirsrv/slapd-instance_name/ldif/디렉터리로 이동합니다.# mv /tmp/example.ldif /var/lib/dirsrv/slapd-instance_name__/ldif/dirsrv사용자가 파일을 읽을 수 있는 권한을 설정합니다.# chown dirsrv /var/lib/dirsrv/slapd-instance_name/ldif/example.ldifSELinux 컨텍스트를 복원합니다.
# restorecon -Rv /var/lib/dirsrv/slapd-instance_name/ldif/
자세한 내용은 솔루션 문서 LDAP Service에서 호스트의 /tmp 및 /var/tmp 디렉터리 아래의 파일에 액세스할 수 없습니다.
FIPS 모드에서 RHEL 9.2+ IdM 서버를 사용하여 RHEL 7 IdM 클라이언트 설치 실패
이제 FIPS 지원 RHEL 9.2 이상 시스템에서 TLS 1.2 연결에 TLS 7627)이 필요합니다. 이는 FIPS-140-3 요구 사항에 따라 수행됩니다. 그러나 RHEL 7.9 이상에서 사용할 수 있는 openssl 버전은 Cryostat를 지원하지 않습니다. 결과적으로 RHEL 9.2에서 실행되는 FIPS 지원 IdM 서버를 사용하여 RHEL 7 IdM(Identity Management) 클라이언트를 설치하는 데 실패합니다.
IdM 클라이언트를 설치하기 전에 호스트를 RHEL 8로 업그레이드하는 경우 FIPS 암호화 정책 상단에 NO-ENFORCE- Cryostat 하위 정책을 적용하여 RHEL 9 서버에서 ECDSA 사용에 대한 요구 사항을 제거하여 문제를 해결합니다.
# update-crypto-policies --set FIPS:NO-ENFORCE-EMS
이 제거는 FIPS 140-3 요구 사항에 대해 수행됩니다. 결과적으로 ECDSA를 사용하지 않는 TLS 1.2 연결을 설정하고 수락할 수 있으며 RHEL 7 IdM 클라이언트 설치에 성공합니다.
