11.11. IdM (Identity Management)
MIT Kerberos는 PKINIT의 ECC 인증서를 지원하지 않음
MIT Kerberos는 초기 인증(PKINIT)을 위한 공개 키 암호화(Public Key Cryptography) 지원의 설계를 설명하는 댓글 문서에 대한 RFC5349 요청을 구현하지 않습니다. 결과적으로 RHEL에서 사용하는 MIT krb5-pkinit 패키지는 ECC 인증서를 지원하지 않습니다. 자세한 내용은 PKINIT (PKINIT)의 초기 인증을 위한 공개 키 암호화에 대한 ECC(Elliptic Curve Cryptography) 지원을 참조하십시오.
PKINIT가 AD KDC에 대해 작동하도록 RHEL 9 클라이언트에서 DEFAULT:SHA1 하위 정책을 설정해야 합니다.
SHA-1 다이제스트 알고리즘은 RHEL 9에서 더 이상 사용되지 않으며 초기 인증(PKINIT)을 위한 공개 키 암호화(PKINIT)의 CMS 메시지가 더 강력한 SHA-256 알고리즘으로 서명됩니다.
그러나 AD(Active Directory) Kerberos Distribution Center(KDC)는 여전히 SHA-1 다이제스트 알고리즘을 사용하여 CMS 메시지에 서명합니다. 결과적으로 RHEL 9 Kerberos 클라이언트가 AD KDC에 대해 PKINIT를 사용하여 사용자를 인증하지 못합니다.
이 문제를 해결하려면 다음 명령을 사용하여 RHEL 9 시스템에서 SHA-1 알고리즘에 대한 지원을 활성화합니다.
# update-crypto-policies --set DEFAULT:SHA1
RHEL 9 Kerberos 에이전트가 RHEL-9 및 비AD Kerberos 에이전트와 통신하면 사용자의 PKINIT 인증이 실패합니다.
클라이언트 또는 Kerberos Distribution Center(KDC) 중 하나인 RHEL 9 Kerberos 에이전트가 Active Directory(AD) 에이전트가 아닌 RHEL-9 Kerberos 에이전트와 상호 작용하는 경우 사용자의 PKINIT 인증이 실패합니다. 이 문제를 해결하려면 다음 작업 중 하나를 수행합니다.
SHA-1 서명을 확인할 수 있도록 RHEL 9 에이전트의 crypto-policy를
DEFAULT:SHA1로 설정합니다.# update-crypto-policies --set DEFAULT:SHA1
비 RHEL-9 및 AD가 아닌 에이전트를 업데이트하여 SHA-1 알고리즘을 사용하여 CMS 데이터에 서명하지 않도록 합니다. 이를 위해 Kerberos 클라이언트 또는 KDC 패키지를 SHA-1 대신 SHA-256을 사용하는 버전으로 업데이트합니다.
- CentOS 9 스트림: krb5-1.19.1-15
- RHEL 8.7: krb5-1.18.2-17
- RHEL 7.9: krb5-1.15.1-53
- Fedora Rawhide/36: krb5-1.19.2-7
- Fedora 35/34: krb5-1.19.2-3
결과적으로 사용자의 PKINIT 인증이 올바르게 작동합니다.
다른 운영 체제의 경우 에이전트가 SHA-1 대신 CMS 데이터에 서명하도록 하는 krb5-1.20 릴리스입니다.
PKINIT가 AD KDC에 대해 작동하도록 RHEL 9 클라이언트에서 DEFAULT:SHA1 하위 정책을 설정해야 합니다. 을 참조하십시오.
Heimdal 클라이언트가 RHEL 9 KDC에 PKINIT를 사용하여 사용자를 인증하지 못했습니다.
기본적으로 Heimdal Kerberos 클라이언트는 인터넷 키 교환(IKE)용 Modular Exponential (MODP) Diffie-Hellman Group 2를 사용하여 IdM 사용자의 PKINIT 인증을 시작합니다. 그러나 RHEL 9의 MIT Kerberos Distribution Center(KDC)는 MODP 그룹 14 및 16만 지원합니다.
결과적으로 krb5_get_init_creds: Heimdal 클라이언트의 PREAUTH_FAILED 오류와 RHEL MIT KDC에서 허용되지 않는 키 매개변수를 사용하여 사전 확인 요청이 실패합니다.
이 문제를 해결하려면 Heimdal 클라이언트가 MODP 그룹 14를 사용하는지 확인하십시오. 클라이언트 구성 파일의 libdefaults 섹션에서 pkinit_dh_min_bits 매개변수를 1759로 설정합니다.
[libdefaults] pkinit_dh_min_bits = 1759
결과적으로 Heimdal 클라이언트는 RHEL MIT KDC에 대해 PKINIT 사전 인증을 완료합니다.
FIPS 모드에서 IdM은 NTLMSSP 프로토콜 사용을 지원하지 않습니다.
NTLMSSP(New Technology LAN Manager Security Support Provider) 인증이 FIPS와 호환되지 않기 때문에 FIPS(Active Directory)와 FIPS 모드가 활성화된 IdM(Identity Management) 간 양방향 교차 포리스트 트러스트를 설정할 수 없습니다. FIPS 모드의 IdM은 AD 도메인 컨트롤러에서 인증을 시도할 때 사용하는 RC4 NTLM 해시를 허용하지 않습니다.
Jira:RHEL-12154[1]
SID가 없는 사용자는 업그레이드 후 IdM에 로그인할 수 없습니다.
IdM 복제본을 RHEL 9.2로 업그레이드한 후 IdM Kerberos Distribution Center(KDC)는 계정에 할당된 SID(보안 식별자)가 없는 사용자에게 TGT( ticket-granting ticket)를 발행하지 못할 수 있습니다. 결과적으로 사용자는 계정에 로그인할 수 없습니다.
이 문제를 해결하려면 토폴로지의 다른 IdM 복제본에서 IdM 관리자로 다음 명령을 실행하여 SID를 생성합니다.
# ipa config-mod --enable-sid --add-sids
이후에도 사용자가 계속 로그인할 수 없는 경우 Directory Server 오류 로그를 검사합니다. 사용자 POSIX ID를 포함하도록 ID 범위를 조정해야 할 수도 있습니다.
자세한 내용은 RHEL9로 업그레이드할 때 IDM 사용자가 더 이상 지식베이스 솔루션에 로그인할 수 없습니다.
Jira:RHELPLAN-157939[1]
마이그레이션된 IdM 사용자는 일치하지 않는 도메인 SID로 인해 로그인할 수 없을 수 있습니다.
ipa migrate-ds 스크립트를 사용하여 IdM 배포에서 사용자를 다른 IdM 배포로 마이그레이션한 경우 이전 SID(보안 식별자)에 현재 IdM 환경의 도메인 SID가 없기 때문에 IdM 서비스를 사용하는 데 문제가 있을 수 있습니다. 예를 들어 해당 사용자는 kinit 유틸리티를 사용하여 Kerberos 티켓을 검색할 수 있지만 로그인할 수 없습니다. 이 문제를 해결하려면 다음 지식 베이스 문서를 참조하십시오. 마이그레이션된 IdM 사용자는 일치하지 않는 도메인 SID로 인해 로그인할 수 없습니다.
Jira:RHELPLAN-109613[1]
MIT krb5 사용자가 사용자 PAC를 생성하는 호환되지 않는 암호화 유형으로 인해 AD TGT를 얻지 못했습니다.
MIT krb5 1.20 이상 패키지에서는 기본적으로 모든 Kerberos 티켓에 PAC(Privilege Attribute Certificate)가 포함되어 있습니다. MIT Kerberos Distribution Center(KDC)는 현재 RFC8009에 정의된 AES HMAC-SHA2 암호화 유형인 PAC에서 KDC 체크섬을 생성하는 데 사용할 수 있는 가장 강력한 암호화 유형을 선택합니다. 그러나 AD(Active Directory)는 이 RFC를 지원하지 않습니다. 결과적으로, AD-MIT 교차 영역 설정에서 MIT krb5 사용자는 MIT KDC에서 생성한 교차 영역 TGT에 의해 생성된 교차 영역 TGT에 PAC의 호환되지 않는 KDC 체크섬 유형이 포함되어 있기 때문에 MIT krb5 사용자가 AD 티켓 부여 티켓(TGT)을 얻지 못합니다.
이 문제를 해결하려면 /var/kerberos/krb5kdc/kdc.conf 구성 파일의 [realms] 섹션에서 MIT 영역에 대해 disable_pac 매개변수를 true 로 설정합니다. 결과적으로 MIT KDC는 PAC 없이 티켓을 생성합니다. 즉, AD는 실패한 체크섬 확인을 건너뛰고 MIT krb5 사용자는 AD TGT를 받을 수 있습니다.
ldap_id_use_start_tls 옵션에 기본값을 사용할 때 발생할 위험이 있습니다.
ID 조회에 TLS 없이 ldap:// 를 사용하는 경우 공격 벡터가 발생할 수 있습니다. 특히 MITTM(man-in-the-middle) 공격으로 공격자가 LDAP 검색에서 반환된 오브젝트의 UID 또는 GID를 변경하여 사용자를 가장할 수 있습니다.
현재 TLS, ldap_id_use_start_tls 를 적용하는 SSSD 구성 옵션은 기본값은 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[1]
RHEL 8.6 또는 이전 버전으로 초기화된 FIPS 모드의 IdM 배포에 FIPS 모드에서 RHEL 9 복제본을 추가하는 데 실패합니다.
FIPS 140-3을 준수하기 위한 기본 RHEL 9 FIPS 암호화 정책은 AES HMAC-SHA1 암호화 유형의 키 파생 기능을 RFC3961, 섹션 5.1에 정의된 대로 사용할 수 없습니다.
이 제약 조건은 첫 번째 서버가 RHEL 8.6 시스템 또는 이전 버전에 설치된 FIPS 모드의 RHEL 8 IdM 환경에 FIPS 모드의 RHEL 9 IdM(Identity Management) 복제본을 추가할 때 차단 프로그램입니다. 이는 RHEL 9과 이전 RHEL 버전 간에 일반적인 암호화 유형이 없으며 일반적으로 AES HMAC-SHA1 암호화 유형을 사용하지만 AES HMAC-SHA2 암호화 유형을 사용하지 않기 때문입니다.
서버에 다음 명령을 입력하여 IdM 마스터 키의 암호화 유형을 볼 수 있습니다.
# kadmin.local getprinc K/M | grep -E '^Key:'
자세한 내용은 AD 도메인 사용자가 FIPS 호환 환경 KCS 솔루션에 로그인할 수 없는 것을 참조하십시오.
SSSD에서 DNS 이름을 올바르게 등록합니다.
이전 버전에서는 DNS가 잘못 설정된 경우 SSSD가 항상 DNS 이름을 등록하려는 첫 번째 시도에 실패했습니다. 문제를 해결하기 위해 이번 업데이트에서는 새 매개변수 dns_resolver_use_search_list 를 제공합니다. DNS 검색 목록을 사용하지 않도록 dns_resolver_use_search_list = false 를 설정합니다.
Bugzilla:1608496[1]
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 클라이언트 설치에 성공합니다.
온라인 백업 및 온라인 자기 구성원 다시 작성 작업은 교착 상태를 유발하는 두 가지 잠금을 얻을 수 있습니다.
온라인 백업 및 온라인 자기 구성원 다시 작성 작업이 반대 순서로 동일한 두 잠금을 가져오려고 하면 서버를 중지하고 다시 시작해야 하는 복구 불가능한 교착 상태가 발생할 수 있습니다. 이 문제를 해결하려면 온라인 백업 및 온라인 자기 구성원 다시 작성 작업을 병렬로 시작하지 마십시오.
Jira:RHELDOCS-18065[1]
