시나리오 1

상황

당신은 회사의 Windows 관리자입니다.

Windows 시스템 외에도 관리할 수 있는 여러 Linux 시스템도 있습니다.

일부 환경의 제어를 Linux 관리자에게 위임할 수 없으므로 AD(Active Directory)의 모든 보안 제어를 처리해야 합니다.

해결책

Linux 호스트를 AD에 직접 통합.

sudo 규칙을 LDAP 서버에 중앙에서 정의하려면 AD 도메인 컨트롤러(DC)에서 스키마 확장을 구현해야 합니다. 이 확장을 구현할 수 없는 경우 IdM(Identity Management) 설치를 고려하십시오. 아래 Scenario 3을 참조하십시오. IdM에 스키마 확장이 이미 포함되어 있으므로 IdM 에서 sudo 규칙을 직접 관리할 수 있습니다.

향후 더 많은 Linux 기술이 필요할 것으로 예상되는 경우 추가 조언

Linux 커뮤니티와 연결하여 다른 사용자가 ID를 관리하는 방법(사용자, 호스트 및 서비스)을 확인합니다.

모범 사례 조사.

Linux에 대해 보다 잘 알고 있어야 합니다.

• 가능한 경우 RHEL 웹 콘솔 을 사용합니다.
• 가능한 경우 명령줄에서 간편한 명령을 사용합니다.
• Red Hat 시스템 관리 과정에 참여하십시오.

시나리오 2

상황

귀사의 Linux 관리자입니다.

Linux 사용자는 회사 리소스에 대한 다양한 액세스 권한이 필요합니다.

Linux 시스템에 대한 중앙 집중식 액세스 제어가 필요합니다.

해결책

IdM을 설치하고 사용자를 마이그레이션합니다.

귀하의 회사가 향후 규모를 확장할 것으로 예상되는 경우 더 많은 조언을 제공합니다.

IdM을 설치한 후 호스트 기반 액세스 제어 및 sudo 규칙 을 구성합니다. 이는 제한된 액세스 및 최소 권한의 보안 모범 사례를 유지하기 위해 필요합니다.

보안 목표를 달성하기 위해 프로토콜과 인프라 계층 모두를 보호하는 통합 ID 및 액세스 관리(IAM) 전략을 개발하십시오.

시나리오 3

상황

회사의 Linux 관리자이며 Linux 시스템을 회사 Windows 서버와 통합해야합니다. Linux 시스템에 대한 액세스 제어의 유일한 유지를 유지하고자 합니다.

다른 사용자는 Linux 시스템에 대한 다른 수준의 액세스 권한이 필요하지만 모두 AD에 있습니다.

해결책

AD 컨트롤은 충분히 강력하지 않으므로 Linux 측의 Linux 시스템에 대한 액세스 제어를 구성해야 합니다. IdM 을 설치하고 IdM-AD 신뢰를 설정합니다.

환경 보안을 강화하기 위한 조언을 더해 주십시오.

IdM을 설치한 후 호스트 기반 액세스 제어 및 sudo 규칙 을 구성합니다. 이는 제한된 액세스 및 최소 권한의 보안 모범 사례를 유지하기 위해 필요합니다.

보안 목표를 달성하기 위해 프로토콜과 인프라 계층 모두를 보호하는 통합 ID 및 액세스 관리(IAM) 전략을 개발하십시오.

시나리오 4

상황

보안 관리자는 모든 Red Hat 제품을 포함하여 모든 환경에서 ID 및 액세스를 관리해야 합니다. 한 곳에서 모든 ID를 관리하고 모든 플랫폼, 클라우드 및 제품에 대한 액세스 제어를 유지해야 합니다.

해결책

IdM 통합,Red Hat Single Sign-On,Red Hat Satellite,Red Hat Ansible Tower 및 기타 Red Hat 제품.

시나리오 5

상황

DoD(Department of def) 또는 Intelligence Community(IC) 환경의 보안 및 시스템 관리자로 스마트 카드 또는 RSA 인증을 사용해야 합니다. PIV 인증서 또는 RSA 토큰을 사용해야 합니다.

해결책

1. IdM에서 인증서 매핑을 구성합니다.
2. IdM-AD 신뢰가 있는 경우 GSSAPI 위임이 활성화되었는지 확인합니다.
3. RSA 토큰에 대해 IdM에서 방사 설정을 사용하도록 설정합니다.
4. 스마트 카드 인증을 위해 IdM 서버 및 IdM 클라이언트 를 구성합니다.

IdM 클라이언트

IdM 클라이언트는 서버에 등록된 Red Hat Enterprise Linux 시스템이며 이러한 서버에서 IdM 서비스를 사용하도록 구성되어 있습니다.

클라이언트는 IdM 서버와 상호 작용하여 해당 서버에서 제공하는 서비스에 액세스합니다. 예를 들어 클라이언트는 Kerberos 프로토콜을 사용하여 인증을 수행하고 SSO(Enterprise Single Sign-On) 티켓을 획득하고 LDAP를 사용하여 ID 및 정책 정보를 가져오고 DNS를 사용하여 서버 및 서비스가 있는 위치와 연결 방법을 감지합니다.

IdM 서버

IdM 서버는 IdM 도메인 내의 ID, 인증 및 권한 부여 요청에 응답하는 Red Hat Enterprise Linux 시스템입니다. 대부분의 배포에서는 IdM 서버와 함께 통합 CA(인증 기관)도 설치됩니다.

IdM 서버는 ID 및 정책 정보를 위한 중앙 리포지토리입니다. IdM 서버는 도메인 멤버가 사용하는 선택적 서비스를 호스팅할 수도 있습니다.

• 인증 기관 (CA)
• KRA(키 복구 기관)
• DNS
• AD(Active Directory) 신뢰 컨트롤러
• AD(Active Directory) 신뢰 에이전트

IdM 서버는 포함된 IdM 클라이언트이기도 합니다. 클라이언트가 자체적으로 등록하면 서버는 다른 클라이언트와 동일한 기능을 제공합니다.

참고

다른 클라이언트 시스템(예: Ubuntu)은 IdM 8 서버에서 작동할 수 있지만 Red Hat은 이러한 클라이언트에 대한 지원을 제공하지 않습니다.

중요

IdM 배포 FIPS를 준수하려는 경우 Red Hat은 환경을 RHEL 9로 마이그레이션하는 것이 좋습니다. RHEL 9는 FIPS 140-3과 호환되는 첫 번째 주요 RHEL 버전입니다.

Active Directory forest

AD(Active Directory) 포리스트는 공통 글로벌 카탈로그, 디렉터리 스키마, 논리적 구조 및 디렉터리 구성을 공유하는 하나 이상의 도메인 트리 집합입니다. 포리스트는 사용자, 컴퓨터, 그룹 및 기타 개체에 액세스할 수 있는 보안 경계를 나타냅니다. 자세한 내용은 Microsoft 문서를 참조하십시오.

Active Directory 글로벌 카탈로그

글로벌 카탈로그는 Active Directory(AD)의 기능으로, 개체가 도메인 컨트롤러 도메인의 멤버인지 여부에 관계없이 도메인 컨트롤러에서 포리스트의 모든 개체에 대한 정보를 제공할 수 있습니다. 글로벌 카탈로그 기능이 활성화된 도메인 컨트롤러를 글로벌 카탈로그 서버라고 합니다. 글로벌 카탈로그는 다중 도메인 AD DS(Active Directory Domain Services)의 모든 도메인에 있는 모든 오브젝트의 검색 가능한 카탈로그를 제공합니다.

Active Directory 보안 식별자

SID(보안 식별자)는 사용자, 그룹 또는 호스트와 같이 Active Directory의 개체에 할당된 고유 ID 번호입니다. Linux의 UID 및 GID와 기능이 같습니다.

Ansible 플레이

Ansible 플레이는 Ansible 플레이북 의 구성 요소입니다. 플레이의 목표는 호스트 그룹을 Ansible 작업으로 표시되는 잘 정의된 역할에 매핑하는 것입니다.

Ansible 플레이북

Ansible 플레이북은 하나 이상의 Ansible 플레이를 포함하는 파일입니다. 자세한 내용은 플레이북에 대한 공식 Ansible 설명서를 참조하십시오.

Ansible 작업

Ansible 작업은 Ansible의 작업 단위입니다. Ansible 플레이에는 여러 작업이 포함될 수 있습니다. 각 작업의 목표는 매우 구체적인 인수를 사용하여 모듈을 실행하는 것입니다. Ansible 작업은 정의된 상태를 달성하는 일련의 지침으로, 광범위한 용어, 특정 Ansible 역할 또는 모듈에 의해 정의되고 해당 역할 또는 모듈의 변수로 미세 조정됩니다. 자세한 내용은 공식 Ansible 작업 설명서를 참조하십시오.

Apache 웹 서버

Apache HTTP Server는 Apache License 2.0의 조건에 따라 릴리스되는 무료 오픈 소스 플랫폼 간 웹 서버 애플리케이션입니다. Apache는 World Wide Web의 초기 성장에 핵심적인 역할을 했으며, 현재 업계를 선도하는 HTTP 서버입니다. 해당 프로세스 이름은 HTTP 데몬 에 대해 짧은 httpd 입니다. Red Hat IdM(Identity Management)은 Apache 웹 서버를 사용하여 IdM 웹 UI를 표시하고 Directory Server 및 인증 기관과 같은 구성 요소 간 통신을 조정합니다.

인증서

인증서는 개인, 서버, 회사 또는 기타 엔터티를 식별하고 해당 ID를 공개 키와 연결하는 데 사용되는 전자 문서입니다. 드라이버의 라이센스 또는 설비와 같이 인증서는 일반적으로 개인 신원을 인정하는 증명(proof of the personal)을 제공합니다. 공개 키 암호화는 인증서를 사용하여 가장 문제를 해결합니다.

IdM의 CA(인증 기관)

디지털 인증서를 발급하는 엔터티입니다. Red Hat Identity Management에서 기본 CA는 IdM CA인 ipa 입니다. ipa CA 인증서는 다음 유형 중 하나입니다.

• 자체 서명. 이 경우 ipa CA는 루트 CA입니다.
• 외부 서명. 이 경우 ipa CA는 외부 CA에 종속됩니다.

IdM에서는 여러 하위 CA를 생성할 수도 있습니다. 하위 CA는 인증서가 다음 유형 중 하나인 IdM CA입니다.

• ipa CA에서 서명합니다.
• 자체와 ipa CA 사이의 중간 CA에서 서명합니다. 하위 CA의 인증서는 자체 서명할 수 없습니다.

CA 서비스 계획을 참조하십시오.

교차 포레스트 신뢰

신뢰는 두 Kerberos 영역 간에 액세스 관계를 설정하므로 한 도메인의 사용자와 서비스가 다른 도메인의 리소스에 액세스할 수 있습니다.

AD(Active Directory) 포리스트 루트 도메인과 IdM 도메인 간의 교차 포리스트 신뢰로 AD 포레스트 도메인의 사용자는 IdM 도메인에서 Linux 시스템 및 서비스와 상호 작용할 수 있습니다. ID 관리는 AD 관점에서 하나의 AD 도메인이 있는 별도의 AD 포리스트를 나타냅니다. 자세한 내용은 신뢰의 작동 방식을 참조하십시오.

디렉터리 서버

Directory Server는 사용자 ID 및 애플리케이션 정보를 중앙 집중화합니다. 애플리케이션 설정, 사용자 프로필, 그룹 데이터, 정책 및 액세스 제어 정보를 저장하기 위한 운영 체제 독립적인 네트워크 기반 레지스트리를 제공합니다. 네트워크의 각 리소스는 Directory Server에 의해 개체로 간주됩니다. 특정 리소스에 대한 정보는 해당 리소스 또는 오브젝트에 연결된 특성 컬렉션으로 저장됩니다. Red Hat Directory Server는 LDAP 표준을 준수합니다.

DNS PTR 레코드

PTR(DNS 포인터) 레코드는 호스트의 IP 주소를 도메인 또는 호스트 이름으로 확인합니다. PTR 레코드는 호스트 이름을 IP 주소로 확인하는 DNS A 및 AAAA 레코드와 반대입니다. DNS PTR 레코드를 사용하면 역방향 DNS 조회가 가능합니다. PTR 레코드는 DNS 서버에 저장됩니다.

DNS SRV 레코드

SRV(DNS 서비스) 레코드는 도메인에서 사용할 수 있는 서비스의 호스트 이름, 포트 번호, 전송 프로토콜, 우선 순위 및 가중치를 정의합니다. SRV 레코드를 사용하여 IdM 서버 및 복제본을 찾을 수 있습니다.

DC(Domain Controller)

DC(도메인 컨트롤러)는 도메인 내의 보안 인증 요청에 응답하고 해당 도메인의 리소스에 대한 액세스를 제어하는 호스트입니다. IdM 서버는 IdM 도메인의 DC로 작동합니다. DC는 사용자를 인증하고, 사용자 계정 정보를 저장하고, 도메인의 보안 정책을 적용합니다. 사용자가 도메인에 로그인하면 DC는 자격 증명을 인증하고 유효성을 검사하며 액세스를 허용하거나 거부합니다.

정규화된 도메인 이름

FQDN(정규화된 도메인 이름)은 DNS(Domain Name System) 계층 구조 내에서 호스트의 정확한 위치를 지정하는 도메인 이름입니다. 상위 도메인 example.com 에 호스트 이름이 myhost 인 장치에는 FQDN myhost.example.com 이 있습니다. FQDN은 다른 도메인에서 myhost 라는 다른 호스트와 장치를 고유하게 구별합니다.

DNS 자동 검색을 사용하여 호스트 machine1 에 IdM 클라이언트를 설치하고 DNS 레코드가 올바르게 구성된 경우 machine1 의 FQDN만 있으면 됩니다. 자세한 내용은 IdM에 대한 호스트 이름 및 DNS 요구 사항을 참조하십시오.

GSSAPI

GSSAPI 또는 GSS-API(Generic Security Service Application Program Interface)를 통해 개발자는 애플리케이션에서 피어 애플리케이션으로 전송되는 데이터를 보호하는 방법을 추상화할 수 있습니다. 보안 서비스 공급업체는 라이브러리와 보안 소프트웨어를 사용하여 일반적인 프로시저 호출의 GSSAPI 구현을 제공할 수 있습니다. 이러한 라이브러리는 공급업체 독립적인 GSSAPI만 사용하도록 애플리케이션을 작성할 수 있는 애플리케이션 작성자에게 GSSAPI 호환 인터페이스를 제공합니다. 이러한 유연성으로 개발자는 특정 플랫폼, 보안 메커니즘, 보호 유형 또는 전송 프로토콜에 보안 구현을 조정할 필요가 없습니다.

Kerberos는 Red Hat Enterprise Linux 및 Microsoft Windows Active Directory Kerberos 구현을 API와 호환되는 대표적인 GSSAPI 메커니즘 구현입니다.

숨겨진 복제본

숨겨진 복제본은 모든 서비스가 실행 중이고 사용 가능한 IdM 복제본이지만 해당 서버 역할이 비활성화되며 DNS에 SRV 레코드가 없으므로 클라이언트는 복제본을 검색할 수 없습니다.

숨겨진 복제본은 주로 백업, 대량 가져오기 및 내보내기 또는 IdM 서비스 종료가 필요한 작업 등의 서비스를 위해 설계되었습니다. 숨겨진 복제본을 사용하지 않으므로 관리자는 클라이언트에 영향을 주지 않고 이 호스트의 서비스를 일시적으로 종료할 수 있습니다. 자세한 내용은 숨겨진 복제본 모드를 참조하십시오.

HTTP 서버

웹 서버를 참조하십시오.

ID 매핑

SSSD는 AD 사용자의 SID를 사용하여 ID 매핑 이라는 프로세스에서 POSIX ID를 알고리즘적으로 생성할 수 있습니다. ID 매핑은 AD의 SID와 Linux의 ID 간에 맵을 생성합니다.

• SSSD가 새 AD 도메인을 감지하면 사용 가능한 ID 범위를 새 도메인에 할당합니다. 따라서 각 AD 도메인은 모든 SSSD 클라이언트 시스템에서 동일한 ID 범위를 갖습니다.
• AD 사용자가 SSSD 클라이언트 시스템에 처음 로그인하면 SSSD는 사용자의 SID 및 해당 도메인의 ID 범위를 포함하여 SSSD 캐시에 사용자에 대한 항목을 생성합니다.
• AD 사용자의 ID는 동일한 SID에서 일관된 방식으로 생성되므로 사용자는 Red Hat Enterprise Linux 시스템에 로그인할 때 동일한 UID와 GID를 갖습니다.

ID 범위

ID 범위는 IdM 토폴로지 또는 특정 복제본에 할당된 ID 번호 범위입니다. ID 범위를 사용하여 새 사용자, 호스트 및 그룹에 유효한 UID 및 GID 범위를 지정할 수 있습니다. ID 범위는 ID 번호 충돌을 방지하는 데 사용됩니다. IdM에는 두 가지 유형의 ID 범위가 있습니다.

• IdM ID 범위

  이 ID 범위를 사용하여 전체 IdM 토폴로지에 있는 사용자와 그룹에 대한 UID 및 GID를 정의합니다. 첫 번째 IdM 서버를 설치하면 IdM ID 범위가 생성됩니다. IdM ID 범위를 생성한 후에는 수정할 수 없습니다. 그러나 IdM ID 범위를 추가로 생성할 수 있습니다(예: 원래 주소에 접근하는 경우).

• DNA(Distributed Numeric Assignment) ID 범위

  이 ID 범위를 사용하여 복제본에서 새 사용자를 만들 때 사용하는 UID 및 GID를 정의합니다. 새 사용자 또는 호스트 항목을 IdM 복제본에 처음 추가하면 해당 복제본에 DNA ID 범위가 할당됩니다. 관리자는 DNA ID 범위를 수정할 수 있지만 새 정의는 기존 IdM ID 범위 내에 있어야 합니다.

  IdM 범위 및 DNA 범위가 일치하지만 상호 연결되지 않습니다. 한 범위를 변경하는 경우 다른 범위가 일치하도록 변경해야 합니다.

자세한 내용은 ID 범위를 참조하십시오.

ID 보기

ID 뷰를 사용하면 POSIX 사용자 또는 그룹 속성의 새 값을 지정하고 새 값이 적용할 클라이언트 호스트 또는 호스트를 정의할 수 있습니다. 예를 들어 ID 보기를 사용하여 다음을 수행할 수 있습니다.

• 다양한 환경에 대한 다른 특성 값을 정의합니다.
• 이전에 생성한 특성 값을 다른 값으로 교체합니다.

IdM-AD 신뢰 설정에서 Default Trust View 는 AD 사용자 및 그룹에 적용되는 ID 뷰입니다. 기본 신뢰 보기를 사용하여 AD 사용자 및 그룹에 대한 사용자 정의 POSIX 속성을 정의하여 AD에 정의된 값을 재정의할 수 있습니다.

자세한 내용은 ID 보기를 사용하여 IdM 클라이언트의 사용자 속성 값 재정의를 참조하십시오.

IdM CA 서버

IdM CA(인증 기관) 서비스가 설치되고 실행되는 IdM 서버입니다.

대체 이름: CA 서버

IdM 배포

전체 IdM 설치를 참조하는 용어입니다. 다음 질문에 대답하여 IdM 배포를 설명할 수 있습니다.

• IdM 배포는 테스트 배포 또는 프로덕션 배포입니까?

  • 몇 개의 IdM 서버가 있습니까?

• IdM 배포에 통합 CA가 포함되어 있습니까?

  • 이 경우 통합 CA 자체 서명 또는 외부 서명이 됩니까?
  • 이 경우 어떤 서버에서 사용할 수 있는 CA 역할 입니까? KRA 역할을 사용할 수 있는 서버는 무엇입니까?

• IdM 배포에 통합 DNS가 포함되어 있습니까?

  • 이 경우 DNS 역할을 사용할 수 있는 서버는 무엇입니까?

• AD 포리스트 와 신뢰 계약을 체결한 IdM 배포입니까?

  • 해당 서버가 있는 경우 AD 신뢰 컨트롤러 또는 AD 신뢰 에이전트 역할을 사용할 수 있는 서버는 무엇입니까?

IdM 서버 및 복제본

IdM 배포에 첫 번째 서버를 설치하려면 ipa-server-install 명령을 사용해야 합니다.

그러면 관리자가 ipa-replica-install 명령을 사용하여 설치된 첫 번째 서버 외에도 복제본을 설치할 수 있습니다. 기본적으로 복제본을 설치하면 생성된 IdM 서버와의 복제 계약이 생성되어 나머지 IdM에 업데이트를 수신 및 전송할 수 있습니다.

설치된 첫 번째 서버와 복제본은 기능적인 차이가 없습니다. 두 서버 모두 완전히 읽기/쓰기 IdM 서버입니다.

사용되지 않는 이름: 마스터 서버

IdM CA 갱신 서버

IdM 토폴로지에 통합 CA(인증 기관)가 포함된 경우 한 서버에 CA 갱신 서버의 고유한 역할이 있습니다. 이 서버는 IdM 시스템 인증서를 유지 관리하고 갱신합니다.

기본적으로 설치하는 첫 번째 CA 서버는 이 역할을 수행하지만 모든 CA 서버를 CA 갱신 서버로 구성할 수 있습니다. 통합 CA가 없는 배포에는 CA 갱신 서버가 없습니다.

사용되지 않는 이름: master CA

IdM CRL 게시자 서버

IdM 토폴로지에 통합 인증 기관(CA)이 포함된 경우 한 서버에 CRL(인증서 취소 목록) 게시자 서버의 고유한 역할이 있습니다. 이 서버는 CRL 유지 관리를 담당합니다.

기본적으로 CA 갱신 서버 역할을 수행하는 서버는 이 역할을 수행하지만 모든 CA 서버를 CRL 게시자 서버로 구성할 수 있습니다. 통합 CA가 없는 배포에는 CRL Publisher 서버가 없습니다.

IdM 토폴로지

IdM 솔루션의 구조, 특히 개별 데이터 센터와 클러스터 간의 복제 계약을 참조하는 용어입니다.

Kerberos 인증 표시기

인증 지표는 Kerberos 티켓에 연결되어 있으며 티켓을 획득하는 데 사용되는 초기 인증 방법을 나타냅니다.

• 이중 인증을 위한 OTP (암호 + 1 회 암호)
• RD IUS(Remote Authentication Dial-In User Service) 인증(일반적으로 802.1x 인증의 경우)
• Kerberos(PKINIT)의 초기 인증을 위한 공개 키 암호화, 스마트 카드 또는 인증서 인증용 pkinit
• 무차별 시도에 대해 강화된 암호 강화

자세한 내용은 Kerberos 인증 표시기 를 참조하십시오.

Kerberos 키탭

password는 사용자의 기본 인증 방법이지만 keytab은 호스트 및 서비스의 기본 인증 방법입니다. Kerberos keytab은 Kerberos 주체 목록 및 관련 암호화 키가 포함된 파일이므로 서비스에서 고유한 Kerberos 키를 검색하고 사용자의 ID를 확인할 수 있습니다.

예를 들어 모든 IdM 클라이언트에는 Kerberos 영역에 클라이언트 시스템을 나타내는 호스트 주체에 대한 정보를 저장하는 /etc/krb5.keytab 파일이 있습니다.

Kerberos 주체

고유한 Kerberos 사용자가 Kerberos 영역에서 각 사용자, 서비스 및 호스트를 식별합니다.

엔터티	이름 지정 규칙	예제
사용자	identifier@REALM	admin@EXAMPLE.COM
서비스	service/fully-qualified-hostname@REALM	http/server.example.com@EXAMPLE.COM
호스트	host/fully-qualified-hostname@REALM	host/client.example.com@EXAMPLE.COM

Kerberos 프로토콜

Kerberos는 시크릿 키 암호화를 사용하여 클라이언트 및 서버 애플리케이션에 대한 강력한 인증을 제공하는 네트워크 인증 프로토콜입니다. IdM 및 Active Directory는 Kerberos를 사용하여 사용자, 호스트 및 서비스를 인증합니다.

Kerberos 영역

Kerberos 영역은 Kerberos KDC(키 배포 센터)에서 관리하는 모든 주체를 포함합니다. IdM 배포에서 Kerberos 영역에는 모든 IdM 사용자, 호스트 및 서비스가 포함됩니다.

Kerberos 티켓 정책

Kerberos KDC(키 배포 센터)는 연결 정책을 통해 티켓 액세스 제어를 시행하고 티켓 라이프사이클 정책을 통해 Kerberos 티켓 기간을 관리합니다. 예를 들어 기본 글로벌 티켓 수명은 1일이며 기본 글로벌 최대 갱신 기간은 1주입니다.

자세한 내용은 IdM Kerberos 티켓 정책 유형을 참조하십시오.

KDC(키 배포 센터)

Kerberos KDC(키 배포 센터)는 Kerberos 자격 증명 정보를 관리하는 중앙의 신뢰할 수 있는 권한 역할을 하는 서비스입니다. KDC는 Kerberos 티켓을 발행하고 IdM 네트워크 내의 엔터티에서 발생하는 데이터의 신뢰성을 확인합니다.

자세한 내용은 IdM KDC의 역할을 참조하십시오.

LDAP

LDAP(Lightweight Directory Access Protocol)는 네트워크를 통해 분산 디렉터리 정보 서비스에 액세스하고 유지 관리하기 위한 오픈 벤더 중립적 애플리케이션 프로토콜입니다. 이 사양의 일부는 DIT(디렉터리 정보 트리)로, 디렉터리 서비스 항목의 Distinguished Names(DN)로 구성된 계층형 트리와 유사한 구조의 데이터를 나타냅니다. LDAP는 네트워크의 디렉터리 서비스에 대한 ISO X.500 표준으로 설명되는 DAP(Directory Access Protocol)의 "경량형" 버전입니다.

경량 하위 CA

IdM에서 경량 하위 CA는 인증서가 IdM 루트 CA 또는 하위 CA에서 서명한 CA(인증 기관)입니다. 경량 하위 CA는 특정 목적으로만 인증서를 발행합니다(예: VPN 또는 HTTP 연결 보안).

자세한 내용은 인증서 서브 세트만 신뢰하도록 애플리케이션 제한을 참조하십시오.

암호 정책

암호 정책은 특정 IdM 사용자 그룹의 암호가 충족해야 하는 일련의 조건입니다. 조건에 다음 매개변수를 포함할 수 있습니다.

• 암호 길이
• 사용된 문자 클래스 수
• 암호의 최대 수명.

자세한 내용은 What is a password policy 를 참조하십시오.

POSIX 속성

POSIX 속성은 운영 체제 간의 호환성을 유지하기 위한 사용자 속성입니다.

Red Hat Identity Management 환경에서 사용자의 POSIX 특성은 다음과 같습니다.

• cn, 사용자 이름
• UID: 계정 이름(로그인)
• uidNumber, 사용자 번호(UID)
• gidNumber, 기본 그룹 번호(GID)
• homeDirectory - 사용자의 홈 디렉토리

Red Hat Identity Management 환경에서 그룹의 POSIX 특성은 다음과 같습니다.

• cn, 그룹 이름
• gidNumber, 그룹 번호(GID)

이러한 속성은 사용자와 그룹을 별도의 엔터티로 식별합니다.

복제 계약

복제 계약은 동일한 IdM 배포에 있는 두 IdM 서버 간의 계약입니다. 복제 계약을 통해 두 서버 간에 데이터와 구성이 지속적으로 복제됩니다.

IdM은 ID 정보를 복제하는 도메인 복제 계약과 인증서 정보를 복제하는 인증서 복제 계약의 두 가지 유형의 복제 계약을 사용합니다.

자세한 내용은 다음을 참조하십시오.

• 복제 계약
• 적절한 복제본 수 확인
• 토폴로지의 복제본 연결
• 복제본 토폴로지 예

스마트 카드

스마트 카드는 리소스에 대한 액세스를 제어하는 데 사용되는 이동식 장치 또는 카드입니다. 이 카드는 내장형 회로(IC) 칩, 유비키와 같은 작은 USB 장치 또는 기타 유사한 장치가 있는 휴대폰 신용 카드 크기 카드일 수 있습니다. 스마트 카드는 사용자가 스마트 카드를 호스트 컴퓨터에 연결할 수 있도록 허용하고 해당 호스트 컴퓨터의 소프트웨어는 스마트 카드에 저장된 주요 자료와 사용자를 인증하여 인증을 제공할 수 있습니다.

SSSD

SSSD(시스템 보안 서비스 데몬)는 RHEL 호스트에서 사용자 인증 및 사용자 권한 부여를 관리하는 시스템 서비스입니다. SSSD는 선택적으로 오프라인 인증을 위해 원격 프로바이더에서 검색한 사용자 ID 및 자격 증명의 캐시를 유지합니다. 자세한 내용은 SSSD 및 이점 이해를 참조하십시오.

SSSD 백엔드

데이터 프로바이더라고도 하는 SSSD 백엔드는 SSSD 캐시를 관리하고 생성하는 SSSD 하위 프로세스입니다. 이 프로세스는 LDAP 서버와 통신하고, 다른 조회 쿼리를 수행하며, 결과를 캐시에 저장합니다. LDAP 또는 Kerberos에 대해 온라인 인증을 수행하고 로그인하는 사용자에게 액세스 및 암호 정책을 적용합니다.

티켓 예매(TGT)

KDC(Kerberos Key Distribution Center)에 인증한 후 사용자는 TGT( 티켓 제공 티켓)를 받습니다. 이 티켓은 임시 자격 증명 집합으로, 웹 사이트 및 이메일과 같은 다른 서비스에 대한 액세스 티켓을 요청하는 데 사용할 수 있습니다.

TGT를 사용하여 추가 액세스를 요청하면 사용자가 여러 서비스에 액세스하기 위해 한 번만 인증해야 하므로 SSO(Single Sign-On) 환경을 사용자에게 제공합니다. TGT는 갱신되며 Kerberos 티켓 정책은 티켓 갱신 제한 및 액세스 제어를 결정합니다.

자세한 내용은 Kerberos 티켓 정책 관리를 참조하십시오.

웹 서버

웹 서버는 페이지, 이미지 또는 애플리케이션과 같은 웹 콘텐츠에 대한 요청을 수락하는 컴퓨터 소프트웨어 및 기본 하드웨어입니다. 웹 브라우저와 같은 사용자 에이전트는 HTTP, 웹 콘텐츠를 배포하는 데 사용되는 네트워크 프로토콜 또는 보안 변형 HTTPS를 사용하여 특정 리소스를 요청합니다. 웹 서버는 해당 리소스의 콘텐츠 또는 오류 메시지로 응답합니다. 웹 서버는 사용자 에이전트에서 보낸 리소스를 수락하고 저장할 수도 있습니다. Red Hat IdM(Identity Management)은 Apache 웹 서버를 사용하여 IdM 웹 UI를 표시하고 Directory Server 및 CA(인증 기관)와 같은 구성 요소 간 통신을 조정합니다. Apache 웹 서버.

IdM 클라이언트

IdM 클라이언트는 서버에 등록된 Red Hat Enterprise Linux 시스템이며 이러한 서버에서 IdM 서비스를 사용하도록 구성되어 있습니다.

클라이언트는 IdM 서버와 상호 작용하여 해당 서버에서 제공하는 서비스에 액세스합니다. 예를 들어 클라이언트는 Kerberos 프로토콜을 사용하여 인증을 수행하고 SSO(Enterprise Single Sign-On) 티켓을 획득하고 LDAP를 사용하여 ID 및 정책 정보를 가져오고 DNS를 사용하여 서버 및 서비스가 있는 위치와 연결 방법을 감지합니다.

IdM 서버

IdM 서버는 IdM 도메인 내의 ID, 인증 및 권한 부여 요청에 응답하는 Red Hat Enterprise Linux 시스템입니다. 대부분의 배포에서는 IdM 서버와 함께 통합 CA(인증 기관)도 설치됩니다.

IdM 서버는 ID 및 정책 정보를 위한 중앙 리포지토리입니다. IdM 서버는 도메인 멤버가 사용하는 선택적 서비스를 호스팅할 수도 있습니다.

• 인증 기관 (CA)
• KRA(키 복구 기관)
• DNS
• AD(Active Directory) 신뢰 컨트롤러
• AD(Active Directory) 신뢰 에이전트

IdM 서버는 포함된 IdM 클라이언트이기도 합니다. 클라이언트가 자체적으로 등록하면 서버는 다른 클라이언트와 동일한 기능을 제공합니다.

도메인 복제 계약

이러한 계약은 ID 정보를 복제합니다.

인증서 복제 계약

이러한 계약은 인증서 정보를 복제합니다.

서비스 레코드의 별도의 DNS 도메인

IdM에 사용되는 기본 DNS 도메인이 다른 시스템과 공유되지 않는지 확인합니다. 이렇게 하면 DNS 수준에서 충돌을 방지할 수 있습니다.

적절한 DNS 도메인 이름 위임

DNS 도메인의 퍼블릭 DNS 트리에 유효한 위임이 있는지 확인합니다. 사설 네트워크가 아니라 사용자에게 위임되지 않은 도메인 이름을 사용하지 마십시오.

다중 레이블 DNS 도메인

단일 레이블 도메인 이름(예: .company )을 사용하지 마십시오. IdM 도메인은 하나 이상의 하위 도메인과 최상위 도메인(예: example.com 또는 company.example.com )으로 구성되어야 합니다.

고유한 Kerberos 영역 이름

영역 이름이 AD(Active Directory)에서 사용하는 이름과 같이 다른 기존 Kerberos 영역 이름과 충돌하지 않는지 확인합니다.

기본 DNS 이름의 대문자 버전인 Kerberos 영역 이름

영역 이름을 기본 DNS 도메인 이름(example.com)의 대문자( EXAMPLE.COM) 버전으로 설정하는 것이 좋습니다.

주의

Kerberos 영역 이름을 기본 DNS 이름의 대문자 버전으로 설정하지 않으면 AD 트러스트를 사용할 수 없습니다.

SSSD(System Security Services Daemon)와의 통합

SSSD는 다양한 ID 및 인증 저장소와 Linux 시스템을 연결할 수 있습니다. IdM(AD, Identity Management) 또는 일반 LDAP 또는 Kerberos 서버.

SSSD와의 통합을 위한 주요 요구 사항:

• AD와 통합할 때 SSSD는 기본적으로 단일 AD 포리스트 내에서만 작동합니다. 다중 Pod 설정을 위해 수동 도메인 열거를 구성합니다.
• idmap_ad 플러그인이 원격 포레스트 사용자를 올바르게 처리할 수 있도록 원격 ADforest가 로컬 포리스트를 신뢰해야 합니다.

SSSD는 직접 및 간접 통합을 모두 지원합니다. 또한 마이그레이션 비용 없이 한 통합 접근 방식에서 다른 통합 방식으로 전환할 수도 있습니다.

Samba Winbind와의 통합

Samba 제품군의 Winbind 구성 요소는 Linux 시스템에서 Windows 클라이언트를 에뮬레이트하고 AD 서버와 통신합니다.

Samba Winbind와의 통합을 위한 주요 요구 사항:

• 멀티 포레스트 AD 설정에서 Winbind와 직접 통합하려면 양방향 신뢰가 필요합니다.
• 원격 AD 도메인의 사용자에 대한 전체 정보를 idmap_ad 플러그인에서 사용할 수 있도록 Linux 시스템의 로컬 도메인에서 양방향 경로가 원격 AD 포리스트에 있는 사용자의 도메인에 있어야 합니다.

AD와의 교차 포리스트 신뢰성을 기반으로 하는 통합

IdM(Identity Management) 서버는 Linux 시스템을 제어하는 중앙 서버 역할을 합니다. AD의 사용자가 Linux 시스템 및 리소스에 액세스할 수 있도록 AD의 교차 영역 Kerberos 신뢰가 설정됩니다. IdM은 별도의 포리스트로 AD에 자체적으로 표시되며 AD에서 지원하는 포리스트 수준의 신뢰성을 활용합니다.

신뢰할 수 있는 경우:

• AD 사용자는 IdM 리소스에 액세스할 수 있습니다.
• IdM 서버 및 클라이언트는 AD 사용자 및 그룹의 ID를 확인할 수 있습니다.
• AD 사용자 및 그룹은 호스트 기반 액세스 제어와 같이 IdM에서 정의한 조건에 따라 IdM에 액세스합니다.
• AD 사용자 및 그룹은 AD 측에서 계속 관리됩니다.

동기화를 기반으로 한 통합

이 접근 방식은 WinSync 도구를 기반으로 합니다. WinSync 복제 계약은 AD의 사용자 계정을 IdM에 동기화합니다.

주의

WinSync는 Red Hat Enterprise Linux 8에서 더 이상 활발하게 개발되지 않습니다. 간접 통합을 위한 선호되는 솔루션은 신뢰할 수 없는 토대입니다.

동기화를 기반으로 하는 통합의 제한 사항은 다음과 같습니다.

• 그룹은 IdM에서 AD로 동기화되지 않습니다.
• 사용자는 AD 및 IdM에서 중복됩니다.
• WinSync는 하나의 AD 도메인만 지원합니다.
• AD에 하나의 도메인 컨트롤러만 사용하여 데이터를 IdM 인스턴스 1개에 동기화할 수 있습니다.
• AD 도메인의 모든 도메인 컨트롤러에 PassSync 구성 요소를 설치해야 하는 사용자 암호를 동기화해야 합니다.
• 동기화를 구성한 후 모든 AD 사용자는 PassSync가 동기화되기 전에 암호를 수동으로 변경해야 합니다.

30-50개 미만 시스템 연결(하드 제한이 아님)

30-50대 미만의 시스템을 연결하는 경우 직접 통합을 고려하십시오. 간접 통합으로 인해 불필요한 오버헤드가 발생할 수 있습니다.

30-50개 이상의 시스템 연결(하드 제한이 아님)

30-50개 이상의 시스템을 연결하는 경우 ID 관리와의 간접 통합을 고려합니다. 이러한 접근 방식을 통해 Linux 시스템 중앙 집중식 관리의 이점을 누릴 수 있습니다.

적은 수의 Linux 시스템을 관리하지만 그 수가 빠르게 증가할 것으로 예상됩니다.

이 시나리오에서는 나중에 환경을 마이그레이션할 필요가 없도록 간접 통합을 고려합니다.

불규칙 기준으로 베어 메탈 시스템 배포

새 시스템을 거의 배포하지 않고 일반적으로 베어 메탈 시스템인 경우 직접 통합을 고려하십시오. 이러한 경우 직접 통합은 일반적으로 단순하고 쉽습니다.

가상 시스템 자주 배포

새 시스템을 자주 배포하고 일반적으로 필요에 따라 프로비저닝된 가상 시스템인 경우 간접 통합을 고려하십시오. 간접 통합을 통해 중앙 서버를 사용하여 새 시스템을 동적으로 관리하고 Red Hat Satellite와 같은 오케스트레이션 툴과 통합할 수 있습니다.

내부 정책은 모든 사용자가 Active Directory에 대해 인증해야 한다고 명시합니까?

직접 또는 간접 통합을 선택할 수 있습니다. Identity Management와 Active Directory 간의 신뢰와 간접 통합을 사용하는 경우 Linux 시스템에 액세스하는 사용자는 Active Directory에 대해 인증합니다. Active Directory에 있는 정책은 인증 중에 실행 및 시행됩니다.

신뢰 컨트롤러

AD 도메인 컨트롤러에 대해 ID 조회를 수행할 수 있는 IdM 서버. 또한 AD로 신뢰를 설정할 수 있도록 Samba 제품군을 실행합니다. AD 도메인 컨트롤러는 AD에 대한 신뢰성을 설정하고 확인할 때 신뢰 컨트롤러에 연결합니다. AD-Enrolled 시스템은 Kerberos 인증 요청에 대한 IdM 신뢰 컨트롤러와 통신합니다.

신뢰를 구성할 때 첫 번째 신뢰 컨트롤러가 생성됩니다. 다양한 지리적 위치에 여러 도메인 컨트롤러가 있는 경우 ipa-adtrust-install 명령을 사용하여 해당 위치에서 RHEL IdM 서버를 신뢰 컨트롤러로 지정합니다.

신뢰 컨트롤러는 신뢰 에이전트보다 더 많은 네트워크 방향 서비스를 실행하므로 잠재적인 침입자에게 더 큰 공격 면적을 제공합니다.

신뢰 에이전트

RHEL IdM 클라이언트의 ID 조회를 AD 도메인 컨트롤러와 비교하여 확인할 수 있는 IdM 서버. 신뢰 컨트롤러와 달리 신뢰 에이전트는 Kerberos 인증 요청을 처리할 수 없습니다.

auto_private_groups = false

SSSD는 사용자 UID에 uidNumber 값을 할당하고 사용자 GID에 the gidNumber 를 할당합니다. 해당 GID가 있는 그룹이 AD에 있어야 합니다. 그렇지 않으면 해당 사용자를 확인할 수 없습니다. 다음 표에서는 다른 AD 구성에 따라 AD 사용자를 확인할 수 있는지 여부를 보여줍니다.

표 7.2. POSIX ID 범위에 대해 auto_private_groups 변수가 false 로 설정된 경우 SSSD 동작

AD에서 사용자 설정	ID 사용자 이름출력
AD 사용자 항목은 다음과 같습니다. uidNumber = 4000 gidNumber 가 정의되지 않음 AD with gidNumber = 4000의 그룹이 없습니다.	SSSD에서 사용자를 해결할 수 없습니다.
AD 사용자 항목은 다음과 같습니다. uidNumber = 4000 gidNumber = 4000 AD with gidNumber = 4000의 그룹이 없습니다.	SSSD에서 사용자를 해결할 수 없습니다.
AD 사용자 항목은 다음과 같습니다. uidNumber = 4000 gidNumber = 4000 AD에는 with gidNumber = 4000 그룹이 있습니다.	# ID aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(adgroup@ad-domain.com) groups=4000(adgroup@ad-domain.com), …​

auto_private_groups = true

SSSD는 AD 사용자 항목의 uidNumber 와 일치하도록 설정된 개인 그룹을 항상 매핑합니다.

표 7.3. POSIX ID 범위에 대해 auto_private_groups 변수가 true로 설정된 경우 SSSD 동작

AD에서 사용자 설정	ID 사용자 이름출력
AD 사용자 항목은 다음과 같습니다. uidNumber = 4000 gidNumber 가 정의되지 않음 AD에는 GID=4000이 있는 그룹이 없습니다.	# ID aduser@AD-DOMAIN.COMaduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​
AD 사용자 항목은 다음과 같습니다. uidNumber = 4000 gidNumber = 5000 AD에는 with gidNumber = 5000 그룹이 없습니다.	# ID aduser@AD-DOMAIN.COMaduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​
AD 사용자 항목은 다음과 같습니다. uidNumber = 4000 gidNumber = 4000 AD에는 with gidNumber = 4000 그룹이 없습니다.	# ID aduser@AD-DOMAIN.COMaduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​
AD 사용자 항목은 다음과 같습니다. uidNumber = 4000 gidNumber = 5000 AD에는 with gidNumber = 5000 그룹이 있습니다.	# ID aduser@AD-DOMAIN.COMaduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​

auto_private_groups = hybrid

uidNumber 값이 matches gidNumber 이지만 이 gidNumber 가 있는 그룹이 없는 경우 SSSD는 개인 그룹을 사용자의 기본 사용자 그룹과 매핑 합니다 . uidNumber 및 gidNumber 값이 다르고 이gidNumber가 있는 그룹이 있는 경우 SSSD는 from gidNumber 값을 사용합니다.

표 7.4. POSIX ID 범위에 대해 auto_private_groups 변수가 하이브리드 로 설정된 경우 SSSD 동작

AD에서 사용자 설정	ID 사용자 이름출력
다음을 사용하여 AD 사용자 항목: uidNumber = 4000 gidNumber 가 정의되지 않음 AD에는 with gidNumber = 4000 그룹이 없습니다.	SSSD에서 사용자를 해결할 수 없습니다.
다음을 사용하여 AD 사용자 항목: uidNumber = 4000 gidNumber = 5000 AD에는 with gidNumber = 5000 그룹이 없습니다.	SSSD에서 사용자를 해결할 수 없습니다.
다음을 사용하여 AD 사용자 항목: uidNumber = 4000 gidNumber = 4000 AD에는 with gidNumber = 4000 그룹이 없습니다.	# ID aduser@AD-DOMAIN.COMaduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​
다음을 사용하여 AD 사용자 항목: uidNumber = 4000 gidNumber = 5000 AD에는 with gidNumber = 5000 그룹이 있습니다.	# ID aduser@AD-DOMAIN.COMaduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=5000(aduser@ad-domain.com) groups=5000(adgroup@ad-domain.com), …​

auto_private_groups = true

SSSD는 AD 사용자의ECDHE를 기반으로 하는 UID와 일치하도록 GID로 설정된 개인 그룹을 항상 매핑합니다.

표 7.5. ID 매핑 ID 범위에 대해 auto_private_groups 변수가 true 로 설정된 경우 SSSD 동작

AD에서 사용자 설정	ID 사용자 이름출력
다음과 같은 경우 AD 사용자 입력: ECDHE가 7000에 매핑 primaryGroupID maps to 8000	# ID aduser@AD-DOMAIN.COMaduser@AD-DOMAIN.COMuid=7000(aduser@ad-domain.com) gid=7000(aduser@ad-domain.com) groups=7000(aduser@ad-domain.com), 8000(adgroup@ad-domain.com), …​

auto_private_groups = false

auto_private_groups 옵션을 false 로 설정하면 SSSD는 AD 항목에 설정된 primaryGroupID 를 GID 번호로 사용합니다. primaryGroupID 의 기본값은 AD의 Domain Users 그룹에 해당합니다.

표 7.6. ID 매핑 ID 범위에 대해 auto_private_groups 변수가 false 로 설정된 경우 SSSD 동작

AD에서 사용자 설정	ID 사용자 이름출력
다음과 같은 경우 AD 사용자 입력: ECDHE가 7000에 매핑 primaryGroupID maps to 8000	# ID aduser@AD-DOMAIN.COMuid=7000(aduser@ad-domain.com) gid=8000(adgroup@ad-domain.com) groups=8000(adgroup@ad-domain.com), …​

고유한 기본 DNS 도메인

AD 및 IdM에 고유한 기본 DNS 도메인이 구성되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

• IdM의 AD 및 idm .example.com용 ad.example.com
• example.com for AD and idm.example.com for IdM

가장 편리한 관리 솔루션은 각 DNS 도메인이 통합된 DNS 서버에서 관리하는 환경이지만 다른 표준 규격 DNS 서버를 사용할 수도 있습니다.

IdM 및 AD DNS 도메인

IdM에 연결된 시스템은 여러 DNS 도메인에서 배포할 수 있습니다. Red Hat은 Active Directory가 소유한 클라이언트와 다른 DNS 영역에 IdM 클라이언트를 배포하는 것이 좋습니다. 기본 IdM DNS 도메인에는 AD 트러스트를 지원할 적절한 SRV 레코드가 있어야 합니다.

적절한 SRV 레코드

기본 IdM DNS 도메인에 AD 트러스트를 지원하는 적절한 SRV 레코드가 있는지 확인합니다.

동일한 IdM 영역에 속하는 다른 DNS 도메인의 경우 AD에 대한 신뢰가 설정된 경우 SRV 레코드를 구성할 필요가 없습니다. 이유는 AD 도메인 컨트롤러가 Kerberos KDC(키 배포 센터)를 검색하는 데 SRV 레코드를 사용하지 않고 신뢰에 대한 이름 접미사 라우팅 정보에 대한 KDC 검색을 기반으로 하기 때문입니다.

신뢰하는 모든 DNS 도메인에서 확인할 수 있는 DNS 레코드

모든 머신이 신뢰 관계와 관련된 모든 DNS 도메인의 DNS 레코드를 확인할 수 있는지 확인합니다.

• IdM DNS를 구성할 때 외부 CA를 사용하여 IdM 서버 설치에 설명된 지침을 따르십시오.
• 통합 DNS 없이 IdM을 사용하는 경우 통합 DNS 없이 IdM 서버 설치에 설명된 지침을 따르십시오.

Kerberos 영역 이름을 기본 DNS 도메인 이름의 대문자 버전으로

Kerberos 영역 이름이 모든 대문자가 있는 기본 DNS 도메인 이름과 같은지 확인합니다. 예를 들어 도메인 이름이 IdM용 AD 및 idm .example.com의 ad.example.com 인 경우 Kerberos 영역 이름은 AD.EXAMPLE.COM 및 IDM. EXAMPLE.COM 이어야 합니다.

통합 DNS와 함께 IdM을 사용할 때

기본적으로 클라이언트는 DNS 레코드에 따라 자동 서비스 조회를 사용합니다. 이 설정에서는 DNS 위치 기능을 사용하여 DNS 기반 서비스 검색을 구성할 수도 있습니다.

자동 조회를 재정의하려면 다음 방법 중 하나로 DNS 검색을 비활성화할 수 있습니다.

• 명령줄에서 장애 조치 매개변수를 제공하여 IdM 클라이언트 설치 중
• SSSD(System Security Services Daemon) 구성을 수정하여 클라이언트 설치 후

통합된 DNS없이 IdM을 사용하는 경우

다음 방법 중 하나로 클라이언트를 명시적으로 구성해야 합니다.

• 명령줄에서 장애 조치 매개변수를 제공하여 IdM 클라이언트 설치 중
• SSSD 설정을 수정하여 클라이언트 설치 후

전체 서버 백업

• IdM과 관련된 모든 서버 구성 파일과 LDAP 데이터 교환 형식(LDIF) 파일을 포함합니다.
• IdM 서비스는 오프라인 이어야 합니다.
• 처음부터 IdM 배포를 다시 빌드하는 데 적합합니다.

데이터 전용 백업

• LDIF 파일에 LDAP 데이터 포함 및 복제 변경 로그
• IdM 서비스는 온라인 또는 오프라인 이 될 수 있습니다.
• IdM 데이터를 과거의 상태로 복원하는 데 적합합니다.

전체 서버 백업

ipa-full- <YEAR-MM-DD-HH-MM-SS>라는 디렉터리에 있는 ipa-full.tar 이라는 아카이브로, time을 time로 지정합니다.

[root@server ~]# ll /var/lib/ipa/backup/ipa-full-2021-01-29-12-11-46
total 3056
-rw-r--r--. 1 root root     158 Jan 29 12:11 header
-rw-r--r--. 1 root root 3121511 Jan 29 12:11 ipa-full.tar

데이터 전용 백업

ipa-data- <YEAR-MM-DD-HH-MM-SS>라는 디렉터리에 있는 ipa-data.tar 이라는 아카이브로, time을 time로 지정합니다.

[root@server ~]# ll /var/lib/ipa/backup/ipa-data-2021-01-29-12-14-23
total 1072
-rw-r--r--. 1 root root     158 Jan 29 12:14 header
-rw-r--r--. 1 root root 1090388 Jan 29 12:14 ipa-data.tar