11.12. IdM (Identity Management)
cert-fix 유틸리티를 --agent-uid pkidbuser 옵션과 함께 사용하면 인증서 시스템이 중단됩니다.
cert-fix 유틸리티를 --agent-uid pkidbuser 옵션과 함께 사용하면 인증서 시스템의 LDAP 구성이 손상되었습니다. 결과적으로 인증서 시스템이 불안정해질 수 있으며 시스템을 복구하려면 수동 단계가 필요합니다.
IdM 호스트의 /var/log/lastlog 스파스 파일은 성능 문제를 일으킬 수 있습니다.
IdM 설치 중에 총 10,000개의 가능한 범위의 200,000개의 UID 범위가 임의로 선택되어 할당됩니다. 이러한 방식으로 임의의 범위를 선택하면 향후 두 개의 개별 IdM 도메인을 병합할 경우 ID가 충돌할 가능성이 크게 줄어듭니다.
그러나 UID가 많은 경우 /var/log/lastlog 파일에 문제가 발생할 수 있습니다. 예를 들어 UID가 1280000008인 사용자가 IdM 클라이언트에 로그인하면 로컬 /var/log/lastlog 파일 크기가 거의 400GB로 증가합니다. 실제 파일은 스파스 파일이며 해당 공간을 모두 사용하지는 않지만 특정 애플리케이션은 기본적으로 스파스 파일을 식별하도록 설계되지 않았으며 이를 처리하기 위해 특정 옵션이 필요할 수 있습니다. 예를 들어 설정이 복잡하고 백업 애플리케이션이 스파스 파일을 올바르게 처리하지 않으면 크기가 400GB인 것처럼 파일이 복사됩니다. 이러한 동작으로 인해 성능 문제가 발생할 수 있습니다.
이 문제를 해결하려면 다음을 수행합니다.
- 표준 패키지의 경우 설명서를 참조하여 스파스 파일을 처리하는 옵션을 식별합니다.
-
사용자 지정 애플리케이션의 경우
/var/log/lastlog와 같은 스파스 파일을 올바르게 관리할 수 있는지 확인합니다.
(JIRA:RHELPLAN-59111)
FIPS 모드는 공유 시크릿을 사용하여 cross-forest 신뢰를 설정하는 것을 지원하지 않습니다.
FIPS 모드에서 공유 보안을 사용하여 가장 간 트러스트를 설정하는 것은 FIPS와 호환되지 않기 때문에 FIPS 모드에서 실패합니다. 이 문제를 해결하려면 FIPS 모드가 활성화된 IdM 도메인과 AD 도메인 간에 신뢰를 설정할 때 AD(Active Directory) 관리 계정으로 인증합니다.
freeradius 서버가 FIPS 모드에서 실행되지 않음
기본적으로 FIPS 모드에서 OpenSSL은 MD5 다이제스트 알고리즘의 사용을 비활성화합니다. RADIUS 프로토콜에서 RADIUS 클라이언트와 RADIUS 서버 간의 시크릿을 암호화해야 하므로 FreeRADIUS 서버가 FIPS 모드에서 실패합니다.
이 문제를 해결하려면 다음 단계를 따르십시오.
절차
이름이 지정된 서비스에 대한 환경 변수인
RADIUS_MD5_FIPS_OVER생성합니다.RIDE를systemctl edit radiusd [Service] Environment=RADIUS_MD5_FIPS_OVERRIDE=1
변경 사항을 적용하려면
systemd구성을 다시 로드하고d서비스를 시작합니다.# systemctl daemon-reload # systemctl start radiusd
디버그 모드에서 FreeRADIUS를 실행하려면 다음을 수행합니다.
# RADIUS_MD5_FIPS_OVERRIDE=1 radiusd -X
FreeRADIUS는 FIPS 모드에서 실행할 수 있지만 FIPS 모드에서 약한 암호 및 기능을 사용하므로 FIPS와 호환되는 것은 아닙니다.
FIPS 모드에서 FreeRADIUS 인증을 구성하는 방법에 대한 자세한 내용은 FIPS 모드에서 FreeRADIUS 인증을 구성하는 방법을 참조하십시오.
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>"
도메인 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)
FIPS 모드에서 IdM은 양방향 간 신뢰를 구축하기 위해ECDHESSP 프로토콜 사용을 지원하지 않습니다.
새 Technology LAN Manager Security Support Provider(NTLMSSP) 인증은 FIPS와 FIPS와 호환되는 Active Directory(AD)와 IdM(Identity Management) 간에 두 가지 방식 간 트러스트를 설정하는 데 실패합니다. FIPS 모드의 IdM은 AD 도메인 컨트롤러에서 인증을 시도할 때 사용하는 RC4ECDHE 해시를 허용하지 않습니다.
FIPS 모드에서 IdM Vault 암호화 및 암호 해독 실패
FIPS 모드가 활성화되면 OpenSSL RSA-PKCS1v15 패딩 암호화가 차단됩니다. 결과적으로 IdM(Identity Management) Vault가 현재 PKCS1v15 패딩을 사용하여 세션 키를 전송 인증서로 래핑하므로 제대로 작동하지 않습니다.
Samba를 인쇄 서버로 실행하고 RHEL 8.4 및 이전 버전에서 업데이트할 때 필요한 작업
이번 업데이트를 통해 samba 패키지가 더 이상 /var/spool/ECDHE/ 디렉터리를 생성하지 않습니다. Samba를 출력 서버로 사용하고 [ECDHEs] 공유에서 /var/spool/ ECDHE/를 사용하여 해당 작업을 스풀링하도록 하면 SELinux에서 Samba 사용자가 이 디렉토리에 파일을 생성하지 못하도록 합니다. 결과적으로 출력 작업이 실패하고 auditd 서비스는 /var/log/audit/audit.log 에 거부 된 메시지를 기록합니다. 8.4 및 이전 버전에서 시스템을 업데이트한 후 이 문제를 방지하려면 다음을 수행합니다.
-
/etc/공유를 검색합니다.ECDHE/smb.conf 파일에서 [ECDHEs] -
공유 정의에
path = /var/spool/ECDHE/가 포함된 경우 설정을 업데이트하고path매개 변수를/var/tmp/로 설정합니다. 이름이 지정된
서비스를다시 시작합니다.# systemctl restart smbd
RHEL 8.5 이상에 Samba를 새로 설치한 경우 작업이 필요하지 않습니다. 이 경우 파일은 이미 samba-common 패키지에서 제공하는 기본 /etc/ECDHE/smb.conf/var/tmp/ 디렉토리를 스풀 인쇄 작업에 사용합니다.
(BZ#2009213)
버전 1.2.2로 다시 설정한 후 authselect 다운그레이드
authselect 패키지가 최신 업스트림 버전 1.2.2 로 다시 빌드되었습니다. authselect 다운그레이드가 지원되지 않으며 root 를 포함한 모든 사용자에 대해 시스템 인증이 중단됩니다.
authselect 패키지를 1.2.1 이하로 다운그레이드한 경우 다음 단계를 수행하여 이 문제를 해결합니다.
-
GRUB 부팅 화면에서 부팅하려는 커널 버전이 있는
Red Hat Enterprise Linux를 선택하고e를 눌러 항목을 편집합니다. -
linux로 시작하는 행의 마지막에 별도의 단어로single를 입력하고Ctrl+X를 눌러 부팅 프로세스를 시작합니다. - 단일 사용자 모드로 부팅하면 root 암호를 입력합니다.
다음 명령을 사용하여 authselect 구성을 복원합니다.
# authselect select sssd --force
NSS에서 활성화된 암호의 기본 키워드가 다른 암호와 함께 작동하지 않습니다.
Directory Server에서 default 키워드를 사용하여 NSS(네트워크 보안 서비스)에서 활성화된 기본 암호를 참조할 수 있습니다. 그러나 기본 암호와 명령줄 또는 웹 콘솔을 사용하여 추가 암호를 활성화하려면 Directory Server가 default 키워드를 확인하지 못합니다. 결과적으로 서버는 추가로 지정된 암호만 활성화하고 다음과 유사한 오류를 기록합니다.
Security Initialization - SSL alert: Failed to set SSL cipher preference information: invalid ciphers <default,+cipher_name>: format is +cipher1,-cipher2... (Netscape Portable Runtime error 0 - no error)
이 문제를 해결하려면 추가로 활성화하려는 암호를 포함하여 NSS에서 기본적으로 활성화된 암호를 모두 지정합니다.
RHEL 8.6에서 RHEL 8.7로의 PKI -core-debuginfo 업데이트 실패
RHEL 8.6에서 RHEL 8.7로 pki-core-debuginfo 패키지를 업데이트하는 데 실패합니다. 이 문제를 해결하려면 다음 명령을 실행합니다.
-
yum remove pki-core-debuginfo -
yum update -y -
yum install pki-core-debuginfo -
yum install idm-pki-symkey-debuginfo idm-pki-tools-debuginfo
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)
