11.13. IdM (Identity Management)
MIT Kerberos는 PKINIT에 대한ECDHE 인증서를 지원하지 않습니다.
MIT Kerberos는 PKINIT(Public Key Cryptography for initial authentication)에서 ECC(elliptic-curve 암호화) 지원 설계를 설명하는 주석 문서에 대한 RFC5349 요청을 구현하지 않습니다. 결과적으로 RHEL에서 사용하는 MITECDHE5-pkinit 패키지는ECDHE 인증서를 지원하지 않습니다. 자세한 내용은 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 클라이언트는 AD KDC에 대해 PKINIT를 사용하여 사용자를 인증하지 못합니다.
문제를 해결하려면 다음 명령을 사용하여 RHEL 9 시스템에서 SHA-1 알고리즘을 지원합니다.
# update-crypto-policies --set DEFAULT:SHA1
RHEL 9 Kerberos 에이전트가 RHEL-9 이외의 Kerberos 에이전트와 통신하면 사용자의 PKINIT 인증이 실패합니다.
클라이언트 또는 Kerberos 배포 센터(KDC) 중 하나인 RHEL 9 Kerberos 에이전트가 AD(Active Directory) 에이전트가 아닌 RHEL-9 Kerberos 에이전트와 상호 작용하는 경우 사용자의 PKINIT 인증이 실패합니다. 문제를 해결하려면 다음 작업 중 하나를 수행하십시오.
SHA-1 서명을 확인할 수 있도록 RHEL 9 에이전트의 crypto-policy를
DEFAULT:SHA1로 설정합니다.# update-crypto-polices --set DEFAULT:SHA1
비 RHEL-9 및 비 AD 에이전트를 업데이트하여 SHA-1 알고리즘을 사용하여 CMS 데이터에 서명하지 않도록 합니다. 이를 위해 Kerberos 클라이언트 또는 KDC 패키지를 SHA-1 대신 SHA-256을 사용하는 버전으로 업데이트합니다.
- CentOS 9 Stream:ECDHE5-1.19.1-15
- RHEL 8.7:ECDHE5-1.18.2-17
- RHEL 7.9:ECDHE5-1.15.1-53
- Fedora Rawhide/36:ECDHE5-1.19.2-7
- Fedora 35/34: krb5-1.19.2-3
결과적으로 사용자의 PKINIT 인증이 올바르게 작동합니다.
다른 운영 체제의 경우 에이전트가 SHA-1 대신 SHA-256으로 CMS 데이터에 서명할 수 있도록 하는 이 릴리스입니다.
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 하위 정책을 활성화하기 전에 FIPS 감사기를 참조하여 기술 조치가 AES SHA-1 HMAC 암호화 유형을 지원하도록 허용한 다음 RHEL IdM을 설치합니다.
# update-crypto-policies --set FIPS:AD-SUPPORT
RHEL 9 KDC에 대해 PKINIT를 사용하여 사용자를 인증하지 못했습니다.
기본적으로 Heimdal Kerberos 클라이언트는 IKE(Internet Key Exchange)용 Modular Exponential(MODP) Diffie-Hellman Group 2를 사용하여 IdM 사용자의 PKINIT 인증을 시작합니다. 그러나 RHEL 9의 MIT Kerberos Distribution Center(KDC)는 MODP 그룹 14 및 16만 지원합니다.
그 결과 RHEL MIT KDC에서 서명되지 않은 클라이언트 및 키 매개 변수 의 PREAUTH_FAILED 오류와 함께 사전 준비 요청이 실패합니다.
이 문제를 해결하려면 Heimdal 클라이언트에서 MODP 그룹 14를 사용하는지 확인합니다. 클라이언트 구성 파일의 libdefaults 섹션에서 pkinit_dh_min_bits 매개변수를 1759로 설정합니다.
[libdefaults] pkinit_dh_min_bits = 1759
결과적으로 Heimdal 클라이언트는 RHEL MIT KDC에 대한 PKINIT 사전 인증을 완료합니다.
FIPS 모드에서 IdM은 양방향 간 신뢰를 구축하기 위해ECDHESSP 프로토콜 사용을 지원하지 않습니다.
새 Technology LAN Manager Security Support Provider(NTLMSSP) 인증은 FIPS와 FIPS와 호환되는 Active Directory(AD)와 IdM(Identity Management) 간에 두 가지 방식 간 트러스트를 설정하는 데 실패합니다. FIPS 모드의 IdM은 AD 도메인 컨트롤러에서 인증을 시도할 때 사용하는 RC4ECDHE 해시를 허용하지 않습니다.
AD cross-realm TGS 요청에 대한 IdM
IdM Kerberos 티켓의 PAC(권한 속성 인증서) 정보는 AD(Active Directory)에서 지원되지 않는 AES SHA-2 HMAC 암호화로 서명됩니다.
결과적으로 IdM에서 AD cross-realm TGS 요청(즉, 양방향 신뢰 설정)이 다음 오류로 인해 실패합니다.
"Generic error (see e-text) while getting credentials for <service principal>"
FIPS 모드에서 IdM Vault 암호화 및 암호 해독 실패
FIPS 모드가 활성화되면 OpenSSL RSA-PKCS1v15 패딩 암호화가 차단됩니다. 결과적으로 IdM(Identity Management) Vault가 현재 PKCS1v15 패딩을 사용하여 세션 키를 전송 인증서로 래핑하므로 제대로 작동하지 않습니다.
도메인 SID 불일치로 인해 마이그레이션된 IdM 사용자가 로그인하지 못할 수 있습니다.
ipa migrate-ds 스크립트를 사용하여 한 IdM 배포에서 사용자를 다른 배포로 마이그레이션하는 경우 기존 SID(Security Identifiers)에 현재 IdM 환경의 도메인 SID가 없기 때문에 IdM 서비스 사용에 문제가 있을 수 있습니다. 예를 들어, 해당 사용자는 kinit 유틸리티로 Kerberos 티켓을 검색할 수 있지만 로그인할 수 없습니다. 이 문제를 해결하려면 Knowledgebase 문서: Migrated IdM users unable to log in due to mismatching domain SIDs 를 참조하십시오.
(JIRA:RHELPLAN-109613)
Directory Server가 모드로 시작되면 예기치 않게 종료됩니다.
버그로 인해 전역 모드가 Directory Server에서 작동하지 않습니다. 참조 옵션을 dirsrv 사용자로 사용하여 ns-slapd 프로세스를 시작하는 경우 Directory Server는 포트 설정을 무시하고 예기치 않게 종료됩니다. 루트 사용자가 프로세스를 실행할 때 SELinux 레이블을 변경하고 서비스가 나중에 일반 모드에서 시작되지 않도록 합니다. 사용할 수 있는 해결방법이 없습니다.
Directory Server에서 접미사가 실패하는 경우 구성
Directory Server에서 백엔드를 설정하는 경우 dsconf <instance_name> 백엔드 접미사 세트를 사용하여 백엔드 상태를 설정하면 다음 오류와 함께 --state conjunction 명령이 실패합니다.
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 유틸리티에는 entryUUID 플러그인에 대한 수정 작업 생성 옵션이 없습니다.
dsconf 유틸리티는 entryUUID 플러그인에 대한 수정 작업을 생성하는 옵션을 제공하지 않습니다. 따라서 관리자는 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 속성이 있는 항목을 수정합니다.
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)
