Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

39장. LDAP 디렉토리에서 IdM으로 마이그레이션

관리자는 이전에 인증 및 ID 조회를 위해 LDAP 서버를 배포했으며 이제 백엔드를 Identity Management로 마이그레이션하려고 했습니다. IdM 마이그레이션 도구를 사용하여 데이터 손실 없이 암호 및 그룹 등 사용자 계정을 전송하려고 합니다. 또한 클라이언트의 값비싼 구성 업데이트를 피하고자 합니다.
여기에 설명된 마이그레이션 프로세스에서는 LDAP에 하나의 네임 공간이 있고 IdM에 하나의 네임 공간이 있는 간단한 배포 시나리오를 가정합니다. 여러 네임 스페이스 또는 사용자 지정 스키마와 같은 복잡한 환경의 경우 Red Hat 지원 서비스에 문의하십시오.

39.1. IdM 마이그레이션으로의 LDAP 개요

LDAP 서버에서 Identity Management로 이동하는 실제 마이그레이션 부분 - 한 서버에서 다른 서버로 데이터를 이동하는 프로세스는 매우 간단합니다. 이 프로세스는 간단하게 데이터를 이동하고, 암호를 이동하고, 클라이언트를 이동합니다.
마이그레이션 중 가장 비용이 많이 드는 부분은 ID 관리를 사용하도록 클라이언트를 구성하는 방법을 결정하는 것입니다. 인프라의 각 클라이언트에 대해 사용 중인 서비스(예: Kerberos 및 SSSD)와 최종 IdM 배포에서 사용할 수 있는 서비스를 결정해야 합니다.
2차이지만 중요한 고려 사항은 암호를 마이그레이션하는 방법을 계획하는 것입니다. ID 관리에는 암호 외에도 모든 사용자 계정에 대한 Kerberos 해시가 필요합니다. 암호에 대한 일부 고려 사항 및 마이그레이션 경로는 39.1.2절. “암호 마이그레이션 플래닝” 에서 다룹니다.

39.1.1. 클라이언트 구성 계획

ID 관리는 기능, 유연성 및 보안의 다양한 수준을 통해 다양한 클라이언트 구성을 지원할 수 있습니다. 운영 체제, 기능 영역(예: 개발 시스템, 프로덕션 서버 또는 사용자 노트북) 및 IT 유지 관리 우선 순위에 따라 개별 클라이언트에 가장 적합한 구성을 결정합니다.
중요
다른 클라이언트 구성은 함께 사용할 수 없습니다. 대부분의 환경에는 클라이언트가 IdM 도메인에 연결하는 데 사용하는 다양한 방법이 혼합되어 있습니다. 관리자는 개별 클라이언트에 가장 적합한 시나리오를 결정해야 합니다.

39.1.1.1. 초기 클라이언트 구성(Pre-Migration)

Identity Management에서 클라이언트 구성을 사용할 위치를 결정하기 전에 먼저 마이그레이션 전 위치를 설정합니다.
마이그레이션할 거의 모든 LDAP 배포의 초기 상태는 ID 및 인증 서비스를 제공하는 LDAP 서비스가 있다는 것입니다.

그림 39.1. 기본 LDAP 디렉토리 및 클라이언트 설정

기본 LDAP 디렉토리 및 클라이언트 설정
Linux 및 Unix 클라이언트는 PAM_LDAP 및 NSS_LDAP 라이브러리를 사용하여 LDAP 서비스에 직접 연결합니다. 이러한 라이브러리를 통해 클라이언트는 데이터가 /etc/passwd 또는 /etc/shadow 에 저장된 것처럼 LDAP 디렉터리에서 사용자 정보를 검색할 수 있습니다. (실제로는 클라이언트가 LDAP를 ID 조회에 사용하고 인증 또는 기타 구성에 Kerberos를 사용하는 경우 인프라가 더 복잡할 수 있습니다.)
LDAP 디렉토리와 IdM 서버, 특히 스키마 지원 및 디렉터리 트리 구조 간에는 구조적인 차이점이 있습니다. (이러한 차이점에 대한 자세한 내용은 1.1.2절. “표준 LDAP 디렉터리와 ID 관리 비교” 을 참조하십시오.) 이러한 차이가 데이터 (특히 항목 이름에 영향을 미치는 디렉터리 트리의 경우)에는 영향을 미치지 않지만 클라이언트 구성에 거의 영향을 미치지 않으므로 클라이언트를 Identity Management로 마이그레이션하는 데 거의 영향을 미치지 않습니다.

39.1.1.2. Red Hat Enterprise Linux 클라이언트에 권장되는 구성

Red Hat Enterprise Linux에는 SSSD( System Security Services Daemon )라는 서비스가 있습니다. SSSD는 특수 PAM 및 NSS 라이브러리(여기서는 및 nss_s ss )를 사용하여 SSSD를 ID 관리와 매우 밀접하게 통합하고 ID 관리의 완전한 인증 및 ID 기능을 활용할 수 있습니다. SSSD에는 캐싱 ID 정보와 같이 많은 유용한 기능이 있으므로 사용자가 중앙 서버에 분실되어도 로그인할 수 있습니다. 이러한 기능은 시스템 수준 인증 가이드에 설명되어 있습니다.
일반 LDAP 디렉터리 서비스(Ns _ldap 및 nss_ldap사용)와 달리 SSSD는 도메인을 정의하여 ID와 인증 정보 간의 관계를 설정합니다. SSSD의 도메인은 인증, ID 조회, 액세스 및 암호 변경의 네 가지 백엔드 기능을 정의합니다. 그런 다음 SSSD 도메인은 프로바이더 를 사용하여 이러한 네 가지 기능 중 하나(또는 모두)에 대한 정보를 제공하도록 구성됩니다. 도메인 구성에 항상 ID 프로바이더가 필요합니다. 다른 세 가지 프로바이더는 선택 사항입니다. 인증, 액세스 또는 암호 공급자가 정의되지 않은 경우 ID 프로바이더가 해당 기능에 사용됩니다.
SSSD는 모든 백엔드 기능에 Identity Management를 사용할 수 있습니다. 이는 일반 LDAP ID 공급자 또는 Kerberos 인증과 달리 전체 ID 관리 기능을 제공하므로 이상적인 구성입니다. 예를 들어, 일일 작업 중에 SSSD는 호스트 기반 액세스 제어 규칙과 ID 관리의 보안 기능을 적용합니다.
참고
LDAP 디렉터리에서 Identity Management로의 마이그레이션 프로세스 중에 SSSD는 추가 사용자 개입 없이 사용자 암호를 원활하게 마이그레이션할 수 있습니다.

그림 39.2. IdM 백엔드를 사용하는 클라이언트 및 SSSD

IdM 백엔드를 사용하는 클라이언트 및 SSSD
ipa-client-install 스크립트는 4개의 백엔드 서비스 모두에 IdM을 사용하도록 SSSD를 자동으로 구성하므로 Red Hat Enterprise Linux 클라이언트는 기본적으로 권장 구성으로 설정됩니다.
참고
이 클라이언트 구성은 최신 SSSD 및 ipa-client 버전을 지원하는 Red Hat Enterprise Linux 6.1 이상 및 Red Hat Enterprise Linux 5.7 이상에서만 지원됩니다. 이전 버전의 Red Hat Enterprise Linux는 39.1.1.3절. “대체 지원 설정” 에 설명된 대로 구성할 수 있습니다.

39.1.1.3. 대체 지원 설정

Mac, Solaris, HP-ECDHE, AIX, Linux와 같은 UNIX 및 Linux 시스템은 IdM이 관리하지만 SSSD를 사용하지 않는 모든 서비스를 지원합니다. 마찬가지로 이전 Red Hat Enterprise Linux 버전 (6.1 및 5.6)은 SSSD를 지원하지만 ID 공급자로 IdM을 지원하지 않는 이전 버전이 있습니다.
시스템에서 최신 버전의 SSSD를 사용할 수 없는 경우 클라이언트는 ID 조회를 위한 LDAP 디렉터리 서비스(Nss _ldap 사용) 및 IdM에 일반 Kerberos ScanSetting(GHM _krb5사용)인 것처럼 IdM에 연결하도록 구성할 수 있습니다.

그림 39.3. LDAP 및 Kerberos를 사용하는 클라이언트 및 IdM

LDAP 및 Kerberos를 사용하는 클라이언트 및 IdM
Red Hat Enterprise Linux 클라이언트가 이전 버전의 SSSD를 사용하는 경우에도 SSSD는 IdM 서버를 ID 공급자 및 해당 Kerberos 인증 도메인으로 사용하도록 구성할 수 있습니다. 이는 System-Level Authentication Guide 의 SSSD 구성 섹션에 설명되어 있습니다.
모든 IdM 도메인 클라이언트는 nss_ldap 및 InstallPlan _krb5를 사용하여 IdM 서버에 연결하도록 구성할 수 있습니다. 일부 유지 관리 상황 및 IT 구조의 경우 ID 및 인증(ns_ldap 및ovn_ldap ) 모두에 LDAP를 사용하여 가장 낮은 공통의 유예에 맞는 시나리오가 필요할 수 있습니다. 그러나 일반적으로 클라이언트에 가능한 가장 안전한 구성을 사용하는 것이 좋습니다. 즉, 인증을 위해 SSSD 또는 LDAP ID 및 Kerberos가 필요합니다.

39.1.2. 암호 마이그레이션 플래닝

LDAP-to-Identity Management 마이그레이션에 영향을 줄 수 있는 가장 눈에 띄는 문제는 사용자 암호를 마이그레이션하는 것입니다.
ID 관리(기본적으로)는 인증을 위해 Kerberos를 사용하며, 표준 사용자 암호 외에도 각 사용자에게 Identity Management Directory Server에 저장된 Kerberos 해시가 있어야 합니다. 이러한 해시를 생성하려면 IdM 서버에서 일반 텍스트로 사용자 암호를 사용할 수 있어야 합니다. 사용자를 생성하면 해시되어 ID 관리에 저장되기 전에 암호를 일반 텍스트로 사용할 수 있습니다. 그러나 사용자가 LDAP 디렉토리에서 마이그레이션되면 연결된 사용자 암호가 이미 해시되어 해당 Kerberos 키를 생성할 수 없습니다.
중요
사용자는 Kerberos 해시가 있어야 IdM 도메인에 인증하거나 IdM 리소스에 액세스할 수 없습니다.
사용자에게 Kerberos 해시가 없는 경우[6]. 해당 사용자는 사용자 계정이 있더라도 IdM 도메인에 로그인할 수 없습니다. 암호 마이그레이션에는 세 가지 옵션이 있습니다. 암호 변경 강제 적용, 웹 페이지 사용, SSSD 사용.
기존 시스템에서 사용자를 마이그레이션하면 보다 원활하게 전환할 수 있지만 마이그레이션 및 전환 프로세스 중에 LDAP 디렉터리 및 IdM을 병렬 관리해야 합니다. 암호를 보존하지 않는 경우 마이그레이션은 더 빨리 수행할 수 있지만 관리자와 사용자가 더 많은 수동 작업이 필요합니다.

39.1.2.1. 방법 1: 임시 암호 사용 및 변경 요청

ID 관리에서 암호가 변경되면 적절한 Kerberos 해시로 생성됩니다. 따라서 관리자의 한 가지 대안은 사용자 계정이 마이그레이션될 때 모든 사용자 암호를 재설정하여 사용자가 암호를 변경하도록 하는 것입니다. 새 사용자에게는 첫 번째 로그인 시 변경되는 임시 암호가 할당됩니다. 암호가 마이그레이션되지 않습니다.
자세한 내용은 22.1.1절. “사용자 암호 변경 및 재설정” 의 내용을 참조하십시오.

39.1.2.2. 방법 2: 마이그레이션 웹 페이지 사용

마이그레이션 모드에서 실행 중인 경우 Identity Management에는 일반 텍스트 암호를 캡처하고 적절한 Kerberos 해시를 생성하는 웹 UI에 특수 웹 페이지가 있습니다. 
https://ipaserver.example.com/ipa/migration
관리자는 사용자에게 암호를 변경하지 않고 사용자 계정과 해당 Kerberos 해시를 적절하게 업데이트하는 이 웹 페이지에 한 번 인증하도록 지시할 수 있습니다.

39.1.2.3. 방법 3: SSSD 사용 (권장 사항)

SSSD는 IdM과 협력하여 필요한 사용자 키를 생성하여 마이그레이션에 대한 사용자 영향을 완화할 수 있습니다. 많은 사용자와 함께 배포하거나 사용자가 암호 변경에 부담을 주지 않아야 하는 경우 이 시나리오가 최상의 시나리오입니다.
  1. 사용자가 SSSD를 사용하여 시스템에 로그인하려고 합니다.
  2. SSSD는 IdM 서버에 대해 Kerberos 인증을 수행하려고 합니다.
  3. 사용자가 시스템에 있지만 Kerberos 해시가 아직 없으므로 error 키 유형을 사용하여 인증이 지원되지 않습니다.
  4. 그런 다음 SSSD는 보안 연결을 통해 일반 텍스트 LDAP 바인드를 수행합니다.
  5. IdM은 이 바인딩 요청을 가로채기합니다. 사용자에게 Kerberos 사용자만 있지만 Kerberos 해시가 없는 경우 IdM ID 공급자는 해시를 생성하여 사용자 항목에 저장합니다.
  6. 인증에 성공하면 SSSD가 IdM에서 연결을 끊고 Kerberos 인증을 다시 시도합니다. 이번에는 해시가 항목에 있으므로 요청이 성공합니다.
이 전체 프로세스는 사용자에게 완전히 투명합니다. 사용자가 알고 있는 한, 클라이언트 서비스에 로그인하면 정상적으로 작동합니다.

39.1.2.4. 일반 텍스트 LDAP 암호 마이그레이션

대부분의 배포에서 LDAP 암호는 암호화되어 있지만 일부 사용자 또는 사용자 항목에 일반 텍스트 암호를 사용하는 환경이 있을 수 있습니다.
사용자가 LDAP 서버에서 IdM 서버로 마이그레이션되면 일반 텍스트 암호가 마이그레이션되지 않습니다. Identity Management에서는 일반 텍스트 암호를 허용하지 않습니다. 대신 사용자에 대해 Kerberos 주체가 생성되고 keytab이 true로 설정되고 암호가 만료된 것으로 설정됩니다. 즉, Identity Management에서 사용자가 다음 로그인 시 암호를 재설정해야 합니다.
참고
암호를 해시하면 39.1.2.2절. “방법 2: 마이그레이션 웹 페이지 사용” 및 39.1.2.3절. “방법 3: SSSD 사용 (권장 사항)” 에서와 같이 SSSD 및 마이그레이션 웹 페이지를 통해 암호가 성공적으로 마이그레이션됩니다.

39.1.2.5. 요구 사항이 아닌 암호 자동 재설정

원래 디렉터리의 사용자 암호가 Identity Management에 정의된 암호 정책을 충족하지 않는 경우 마이그레이션 후 암호를 재설정해야 합니다.
사용자가 IdM 도메인에 kinit 를 시도할 때 암호 재설정은 자동으로 수행됩니다. 
[jsmith@server ~]$ kinit
Password for jsmith@EXAMPLE.COM:
Password expired.  You must change it now.
Enter new password:
Enter it again:

39.1.3. 마이그레이션 고려 사항 및 요구 사항

LDAP 서버에서 Identity Management로의 마이그레이션을 계획할 때 LDAP 환경이 Identity Management 마이그레이션 스크립트로 작업할 수 있는지 확인합니다.

39.1.3.1. 마이그레이션이 지원되는 LDAP 서버

LDAP 서버에서 Identity Management로의 마이그레이션 프로세스에서 특수 스크립트 ipa migrate-ds 를 사용하여 마이그레이션을 수행합니다. 이 스크립트는 작동하기 위해 LDAP 디렉토리 및 LDAP 항목의 구조에 대해 특정 기대치를 갖습니다. 마이그레이션은 LDAPv3 호환 디렉터리 서비스에 대해서만 지원되며 다음과 같은 몇 가지 공통 디렉터리가 포함됩니다.
  • Sun ONE Directory Server
  • Apache Directory Server
  • OpenLDAP
LDAP 서버에서 Identity Management로의 마이그레이션은 Red Hat Directory Server 및 OpenLDAP에서 테스트되었습니다.
참고
마이그레이션 스크립트를 사용한 마이그레이션은 LDAPv3 호환 디렉터리가 아니므로 Microsoft Active Directory에서 지원되지 않습니다. Active Directory에서 마이그레이션하는 데 도움이 필요하면 Red Hat Professional Services에 문의하십시오.

39.1.3.2. 마이그레이션 환경 요구 사항

Red Hat Directory Server 및 Identity Management 둘 다에 대해 다양한 구성 시나리오가 있으며 이러한 시나리오 중 하나가 마이그레이션 프로세스에 영향을 줄 수 있습니다. 이 장의 마이그레이션 절차 예에서는 환경에 대한 가정입니다.
  • 단일 LDAP 디렉터리 도메인이 하나의 IdM 영역으로 마이그레이션되고 있습니다. 통합은 포함되지 않습니다.
  • 사용자 암호는 LDAP 디렉터리에 해시로 저장됩니다. 지원되는 해시 목록은 Table 19.2의 passwordStorageScheme 특성을 참조하십시오. Red Hat Directory Server 10 관리 가이드에서 암호 정책 관련 속성
  • LDAP 디렉터리 인스턴스는 ID 저장소 및 인증 방법입니다. 클라이언트 시스템은 CloudEvent _ldap 또는 nss_ldap 를 사용하여 LDAP 서버에 연결하도록 구성됩니다.
  • 항목은 표준 LDAP 스키마만 사용합니다. 사용자 지정 개체 클래스 또는 속성이 포함된 항목은 Identity Management로 마이그레이션되지 않습니다.

39.1.3.3. 마이그레이션 - IdM 시스템 요구 사항

보통의 크기의 디렉토리(약 10,000명의 사용자 및 10개 그룹)를 사용하는 경우 마이그레이션을 진행할 수 있도록 충분히 강력한 대상 시스템( IdM 시스템)이 있어야 합니다. 마이그레이션의 최소 요구 사항은 다음과 같습니다.
  • 4개 코어
  • 4GB RAM
  • 30GB의 디스크 공간
  • SASL 버퍼 크기 2MB(기본값: IdM 서버의 기본값)
    마이그레이션 오류의 경우 버퍼 크기를 늘립니다. 
    [root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -w password -h ipaserver.example.com -p 389

dn: cn=config
changetype: modify
replace: nsslapd-sasl-max-buffer-size
nsslapd-sasl-max-buffer-size: 4194304

modifying entry "cn=config"
    nsslapd-sasl-max-buffer-size 값을 바이트 단위로 설정합니다.

39.1.3.4. Sudo Rules에 대한 고려 사항

sudo 를 LDAP와 함께 사용하는 경우 LDAP에 저장된 sudo 규칙을 수동으로 마이그레이션해야 합니다. Red Hat은 IdM에서 호스트 그룹으로 네트워크 그룹을 다시 생성하는 것이 좋습니다. IdM은 SSSD sudo 공급자를 사용하지 않는 sudo 구성의 기존 네트워크 그룹으로 호스트 그룹을 자동으로 제공합니다.

39.1.3.5. 마이그레이션 툴

ID 관리에서는 특정 명령인 ipa migrate-ds 를 사용하여 LDAP 디렉터리 데이터를 적절하게 포맷하고 IdM 서버로 완전히 가져올 수 있도록 마이그레이션 프로세스를 구동합니다. ipa migrate-ds 를 사용하는 경우 --bind-dn 옵션으로 지정된 원격 시스템 사용자는 userPassword 속성에 대한 읽기 액세스 권한이 있어야 합니다. 그렇지 않으면 암호가 마이그레이션되지 않습니다.
Identity Management 서버는 마이그레이션 모드에서 실행되도록 구성해야 하며 마이그레이션 스크립트를 사용할 수 있습니다. 자세한 내용은 39.3절. “LDAP 서버를 Identity Management로 마이그레이션” 의 내용을 참조하십시오.

39.1.3.6. 마이그레이션 성능 개선

LDAP 마이그레이션은 기본적으로 IdM 서버 내의 389 Directory Server 인스턴스에 대한 특수 가져오기 작업입니다. 가져오기 작업 성능을 높이기 위해 389 Directory Server 인스턴스를 튜닝하면 전체 마이그레이션 성능이 향상될 수 있습니다.
가져오기 성능에 직접 영향을 주는 매개변수는 다음 두 가지가 있습니다.
  • 항목 캐시에 허용되는 크기를 정의하는 nsslapd-cachememsize 속성입니다. 이는 버퍼로, 총 캐시 메모리 크기의 80%로 자동 설정됩니다. 대규모 가져오기 작업의 경우 이 매개 변수(및 메모리 캐시 자체)를 더 효율적으로 확장할 수 있으며, 더 큰 특성이 있는 항목 또는 항목을 더 효율적으로 처리할 수 있습니다.
    ldapmodify 를 사용하여 특성을 수정하는 방법에 대한 자세한 내용은 Red Hat Directory Server 10 성능 튜닝 가이드의 Entry Cache Size 설정을 참조하십시오.
  • system ulimit 구성 옵션은 시스템 사용자에게 허용되는 최대 프로세스 수를 설정합니다. 대용량 데이터베이스를 처리하는 작업은 제한을 초과할 수 있습니다. 이 경우 값을 늘립니다. 
    [root@server ~]# ulimit -u 4096
자세한 내용은 에서 Red Hat Directory Server Performance Tuning Guide 를 참조하십시오 https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html-single/performance_tuning_guide/index.

39.1.3.7. Migration Sequence

ID 관리로 마이그레이션할 때 네 가지 주요 단계가 있지만 먼저 서버를 마이그레이션할지 아니면 클라이언트를 마이그레이션할지 여부에 따라 순서가 약간 달라집니다.
클라이언트 기반 마이그레이션에서는 IdM 서버가 구성된 동안 SSSD를 사용하여 클라이언트 구성을 변경합니다.
  1. SSSD 배포.
  2. 현재 LDAP 서버에 연결하도록 클라이언트를 재구성한 다음 IdM으로 장애 조치합니다.
  3. IdM 서버를 설치합니다.
  4. IdM ipa migrate-ds 스크립트를 사용하여 사용자 데이터를 마이그레이션합니다. 이렇게 하면 LDAP 디렉터리에서 데이터를 내보내고 IdM 스키마 형식으로 데이터를 가져온 다음 IdM으로 가져옵니다.
  5. LDAP 서버를 오프라인 상태로 만들고 클라이언트가 Identity Management를 투명하게 장애 조치할 수 있도록 허용합니다.
서버 마이그레이션을 사용하면 LDAP에서 Identity Management로의 마이그레이션이 먼저 제공됩니다.
  1. IdM 서버를 설치합니다.
  2. IdM ipa migrate-ds 스크립트를 사용하여 사용자 데이터를 마이그레이션합니다. 이렇게 하면 LDAP 디렉터리에서 데이터를 내보내 IdM 스키마로 포맷한 다음 IdM로 가져옵니다.
  3. 선택 사항입니다. SSSD 배포.
  4. IdM에 연결하도록 클라이언트를 재구성합니다. 단순히 LDAP 서버를 대체할 수 없습니다. IdM 디렉터리 트리(따라서 사용자 항목 DNs)는 이전 디렉터리 트리와 다릅니다.
    클라이언트를 재구성해야 하지만 클라이언트를 즉시 재구성할 필요가 없습니다. 업데이트된 클라이언트는 다른 클라이언트가 이전 LDAP 디렉터리를 가리키는 반면 업데이트된 클라이언트는 IdM 서버를 가리키므로 데이터를 마이그레이션한 후 적절한 테스트 및 전환 단계를 수행할 수 있습니다.
    참고
    LDAP 디렉터리 서비스와 IdM 서버를 매우 길게 실행하지 마십시오. 이로 인해 두 서비스 간에 사용자 데이터가 일치하지 않을 위험이 있습니다.
두 프로세스 모두 일반적인 마이그레이션 절차를 제공하지만 일부 환경에서는 작동하지 않을 수 있습니다. 테스트 LDAP 환경을 설정하고 실제 LDAP 환경을 마이그레이션하려고 시도하기 전에 마이그레이션 프로세스를 테스트합니다.

[6] Kerberos 인증 대신 ID 관리에서 LDAP 인증을 사용할 수 있습니다. 즉, Kerberos 해시는 사용자에게 필요하지 않습니다. 그러나 이 경우 ID 관리 기능이 제한되며 권장되지 않습니다.