Red Hat Training

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

Linux 도메인 ID, 인증 및 정책 가이드

Red Hat Enterprise Linux 7

Linux 환경에서 Red Hat Identity Management 사용

Florian Delehaye

Red Hat Customer Content Services

Marc Muehlfeld

Red Hat Customer Content Services

Filip Hanzelka

Red Hat Customer Content Services

Lucie Maňásková

Red Hat Customer Content Services

Aneta Šteflová Petrová

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Ella Deon Ballard

Red Hat Customer Content Services

초록

사용자와 시스템 모두의 ID 및 정책 관리는 대부분의 엔터프라이즈 환경에서 핵심 기능입니다. Identity Management는 시스템이 도메인에 등록하고 SSO(Single Sign-On) 및 인증 서비스에 필요한 ID 정보에 즉시 액세스할 수 있는 ID 도메인을 생성하는 방법과 권한 부여 및 액세스를 관리하는 정책 설정을 생성하는 방법을 제공합니다.
본 가이드 외에도 다음 가이드에서 Red Hat Enterprise Linux Identity Management와 관련된 다른 기능 및 서비스에 대한 설명서를 확인할 수 있습니다.

시스템 수준 인증 가이드

System-Level Authentication Guideauthconfig 유틸리티, SSSD(System Security Services Daemon) 서비스,PAM(Plugable Authentication Module) 프레임워크, Kerberos, certmon 유틸리티, SSO(Single Sign-On) 등의 로컬 시스템에서 인증을 구성하는 데 사용할 수 있는 다양한 애플리케이션과 서비스를 문서화합니다.

Windows 통합 가이드

Windows 통합 가이드 에서는 ID 관리를 사용하여 Linux 도메인을 Microsoft Windows AD(Active Directory)와 통합하는 방법을 설명합니다. 다른 주제 중에서도 이 가이드에서는 SSSD를 사용하여 CIFS(Common Internet File System) 및 영역 시스템에 액세스할 수 있는 직접 및 간접 AD 통합의 다양한 측면을 다룹니다.


I 부. Red Hat Identity Management 개요

이 부분에서는 Red Hat Identity Management 의 목적에 대해 설명합니다. 또한 도메인에 포함된 클라이언트 및 서버 시스템을 포함하여 ID 관리 도메인에 대한 기본 정보를 제공합니다.

1장. Red Hat Identity Management 소개

1.1. Red Hat Identity Management의 목표

Red Hat IdM(Identity Management)은 Linux 기반 도메인에서 ID 저장소, 인증, 정책 및 권한 부여 정책을 관리하는 중앙 집중식 통합 방법을 제공합니다. IdM은 다양한 서비스를 개별적으로 관리하고 여러 시스템에서 다른 툴을 사용하는 관리 오버헤드를 크게 줄입니다.
IdM은 다음을 지원하는 몇 가지 중앙 집중식 ID, 정책 및 권한 부여 소프트웨어 솔루션 중 하나입니다.
  • Linux 운영 체제 환경의 고급 기능
  • 대규모 Linux 머신 그룹 통합
  • Active Directory와의 기본 통합
IdM은 Linux 기반 및 Linux 제어 도메인을 생성합니다.
  • IdM은 기존의 기본 Linux 툴과 프로토콜을 기반으로 합니다. 자체 프로세스와 구성이 있지만 기본 기술은 Linux 시스템에 잘 정립되고 Linux 관리자가 신뢰합니다.
  • IdM 서버 및 클라이언트는 Red Hat Enterprise Linux 시스템입니다. 그러나 IdM은 Windows 클라이언트를 직접 지원하지 않지만 Active Directory 환경과 통합할 수 있습니다.
    참고
    이 가이드에서는 Linux 환경에서의 IdM 사용에 대해서만 설명합니다. Active Directory와의 통합에 대한 자세한 내용은 Windows 통합 가이드 를 참조하십시오.
    Linux 시스템을 Active Directory 환경에 통합할 수 있는 Samba 제품군에 대한 자세한 내용은 Windows 통합 가이드의 Samba 사용 장을 참조하십시오. Samba를 서버로 사용하는 경우 서버를 IdM 도메인에 통합하고 IdM 또는 신뢰할 수 있는 Active Directory 도메인에 대해 Samba 서버에 연결하는 사용자를 인증하는 것은 지원되지 않습니다.

1.1.1. IdM에 의한 이점의 예

여러 Linux 서버로 ID 및 정책 관리
IdM이 없는 경우: 각 서버는 별도로 관리됩니다. 모든 암호는 로컬 시스템에 저장됩니다. IT 관리자는 모든 시스템에서 사용자를 관리하고 인증 및 권한 부여 정책을 별도로 설정하며 로컬 암호를 유지 관리합니다.
With IdM: IT 관리자는 다음을 수행할 수 있습니다:
  • 하나의 중앙 위치에서 ID 관리: IdM 서버
  • 동시에 여러 장치에 정책을 균일하게 적용
  • 호스트 기반 액세스 제어, 위임 및 기타 규칙을 사용하여 사용자에 대해 다양한 액세스 수준을 설정합니다.
  • 권한 에스컬레이션 규칙을 중앙에서 관리
  • 홈 디렉터리 마운트 방법 정의
엔터프라이즈 SSO(Single-Sign-On)
IdM이 없는 경우: 사용자는 시스템에 로그인하여 서비스 또는 애플리케이션에 액세스할 때마다 암호를 입력하라는 메시지가 표시됩니다. 이러한 암호는 다를 수 있으며 사용자는 어떤 애플리케이션에 사용할 자격 증명을 기억해야 합니다.
With IdM: 사용자가 시스템에 로그인한 후 반복적으로 자격 증명을 요청하지 않고 여러 서비스와 애플리케이션에 액세스할 수 있습니다. 이 기능은 다음과 같습니다.
  • 사용성 개선
  • 암호가 기록되거나 안전하지 않은 상태로 저장할 수 있는 보안 위험 감소
  • 사용자 생산성 향상
혼합 Linux 및 Windows 환경 관리
IdM이 없는 경우: Windows 시스템은 Active Directory 포리스트에서 관리되지만 개발, 프로덕션 및 기타 팀에는 많은 Linux 시스템이 있습니다. Linux 시스템은 Active Directory 환경에서 제외됩니다.
With IdM: IT 관리자는 다음을 수행할 수 있습니다:
  • 기본 Linux 도구를 사용하여 Linux 시스템 관리
  • Linux 시스템을 Windows 시스템과 통합하여 중앙 집중식 사용자 저장소를 보존합니다.
  • Linux 기반을 쉽게 확장할 수 있습니다.
  • Linux와 Active Directory 시스템의 별도 관리 및 Linux 및 Windows 관리자가 직접 환경을 제어할 수 있도록 지원

1.1.2. 표준 LDAP 디렉터리와 ID 관리 비교

Red Hat Directory Server와 같은 표준 LDAP 디렉토리는 범용 디렉터리입니다. 광범위한 사용 사례에 맞게 사용자 지정할 수 있습니다.
  • 스키마: 사용자, 시스템, 네트워크 엔터티, 물리적 장비 또는 구매자와 같은 다양한 항목에 맞게 사용자 지정할 수 있는 유연한 스키마입니다.
  • 일반적으로 으로 사용되는 백엔드 디렉터리: 인터넷에서 서비스를 제공하는 비즈니스 애플리케이션과 같은 다른 애플리케이션에 대한 데이터를 저장합니다.
IdM(Identity Management)에는 ID 관리와 이러한 ID와 관련된 인증 및 권한 부여 정책이라는 특정 용도가 있습니다.
  • 스키마: 사용자 또는 시스템 ID 항목과 같이 용도와 관련된 특정 항목 집합을 정의하는 특정 스키마입니다.
  • 일반적으로 엔터프라이즈 또는 프로젝트의 경계 내에서 ID를 관리하는 ID 및 인증 서버로 사용됩니다.
기본 디렉터리 서버 기술은 Red Hat Directory Server와 IdM에서 동일합니다. 그러나 IdM은 ID 관리를 위해 최적화되었습니다. 이는 일반적인 확장성을 제한하지만 단순한 구성, 리소스 관리의 향상된 자동화, ID 관리의 효율성 향상과 같은 몇 가지 이점도 제공합니다.

추가 리소스

1.2. ID 관리 도메인

IdM(Identity Management) 도메인은 동일한 구성, 정책 및 ID 저장소를 공유하는 시스템 그룹으로 구성됩니다. 공유 속성을 사용하면 도메인 내의 시스템이 서로 인식하고 함께 작동할 수 있습니다.
IdM 관점에서 도메인에는 다음 유형의 시스템이 포함됩니다.
  • 도메인 컨트롤러로 작동하는 IdM 서버
  • IdM 클라이언트 - 서버에 등록됨
또한 IdM 서버는 자체적으로 등록된 IdM 클라이언트입니다. 서버 시스템은 클라이언트와 동일한 기능을 제공합니다.
IdM은 Red Hat Enterprise Linux 시스템을 IdM 서버 및 클라이언트로 지원합니다.
참고
이 가이드에서는 Linux 환경에서 IdM 사용에 대해 설명합니다. Active Directory와의 통합에 대한 자세한 내용은 Windows 통합 가이드 를 참조하십시오.

1.2.1. ID 관리 서버

IdM 서버는 ID 및 정책 정보를 위한 중앙 리포지토리 역할을 합니다. 또한 도메인 구성원이 사용하는 서비스를 호스팅합니다. IdM은 IdM 웹 UI 및 명령줄 유틸리티 등 IdM 연결 서비스를 모두 중앙에서 관리할 수 있는 관리 툴 세트를 제공합니다.
IdM 서버 설치에 대한 자세한 내용은 2장. ID 관리 서버 설치 및 제거 을 참조하십시오.
중복성과 부하 분산을 지원하기 위해 데이터 및 구성을 IdM 서버에서 다른 IdM 서버인 초기 서버의 복제본 으로 복제할 수 있습니다. 클라이언트에 다양한 서비스를 제공하도록 서버와 해당 복제본을 구성할 수 있습니다. IdM 복제본에 대한 자세한 내용은 4장. ID 관리 복제본 설치 및 제거 을 참조하십시오.

1.2.1.1. IdM 서버에서 호스팅되는 서비스

다음 서비스 대부분은 IdM 서버에 엄격하게 설치할 필요가 없습니다. 예를 들어 CA(인증 기관), DNS 서버 또는 NTP(Network Time Protocol) 서버와 같은 서비스는 IdM 도메인 외부의 외부 서버에 설치할 수 있습니다.
Kerberos:&gt ;-<5kdckadmin
IdM은 Kerberos 프로토콜을 사용하여 SSO(Single Sign-On)를 지원합니다. Kerberos를 사용하면 사용자가 올바른 사용자 이름과 암호만 제공하면 되며 시스템에서 자격 증명을 다시 요청하지 않고 IdM 서비스에 액세스할 수 있습니다.
  • Kerberos 는 다음 두 부분으로 나뉩니다.
    • ScanSetting 5kdc 서비스는 Kerberos 인증 서비스 및 KMS(Key Distribution Center) 데몬입니다.
    • kadmin 서비스는 Kerberos 데이터베이스 관리 프로그램입니다.
    Kerberos 작동 방식에 대한 자세한 내용은 시스템 수준 인증 가이드에서 Kerberos 사용을 참조하십시오.
  • IdM의 Kerberos로 인증하는 방법에 대한 자세한 내용은 5.2절. “Kerberos를 사용하여 IdM에 로그인” 을 참조하십시오.
  • IdM에서 Kerberos 관리에 대한 자세한 내용은 29장. Kerberos 도메인 관리 을 참조하십시오.
LDAP 디렉터리 서버: dirsrv
IdM 내부 LDAP 디렉터리 서버 인스턴스는 Kerberos, 사용자 계정, 호스트 항목, 서비스, 정책, DNS 등과 같은 모든 IdM 정보를 저장합니다.
LDAP 디렉터리 서버 인스턴스는 Red Hat Directory Server 와 동일한 기술을 기반으로 합니다. 그러나 IdM별 작업에 맞게 조정됩니다.
참고
이 가이드에서는 이 구성 요소를 Directory Server로 설명합니다.
인증 기관: pki-tomcatd
통합 인증 기관(CA)Red Hat Certificate System 과 동일한 기술을 기반으로 합니다.pki 는 인증서 시스템 서비스에 액세스하기 위한 명령줄 인터페이스입니다.
참고
이 가이드에서는 구현 시 이 구성 요소를 인증서 시스템으로, 구현에서 제공하는 서비스를 처리할 때 인증 기관으로 참조합니다.
독립 실행형 Red Hat 제품인 Red Hat Certificate System에 대한 자세한 내용은 Red Hat Certificate System 제품 설명서를 참조하십시오.
DNS(Domain Name System): 이름이 지정
IdM은 동적 서비스 검색에 DNS 를 사용합니다. IdM 클라이언트 설치 유틸리티는 DNS의 정보를 사용하여 클라이언트 시스템을 자동으로 구성할 수 있습니다. 클라이언트가 IdM 도메인에 등록된 후에는 DNS를 사용하여 도메인 내에서 IdM 서버 및 서비스를 찾습니다.
Red Hat Enterprise Linux의 DNS(Domain Name System) 프로토콜의 BIND(Berkeley Internet Name Domain) 구현에는 이름이 지정된 DNS 서버가 포함되어 있습니다. named -pkcs11 은 PKCS#11 암호화 표준을 기본적으로 지원하는 BIND DNS 서버 버전입니다.
네트워크 시간 프로토콜: ntpd
많은 서비스에서 서버와 클라이언트는 특정 변동 내에서 동일한 시스템 시간을 보유해야 합니다. 예를 들어 Kerberos 티켓은 타임스탬프를 사용하여 유효성을 확인하고 재생 공격을 방지합니다. 서버와 클라이언트 스큐 사이의 시간이 허용된 범위를 벗어나면 Kerberos 티켓이 무효화됩니다.
기본적으로 IdM은 NTP(Network Time Protocol) 를 사용하여 ntpd 서비스를 통해 네트워크를 통해 클럭을 동기화합니다. NTP를 사용하면 중앙 서버가 권한 있는 클록 역할을 하며 클라이언트는 서버 클록과 일치하도록 시간을 동기화합니다. IdM 서버는 서버 설치 프로세스 중 IdM 도메인의 NTP 서버로 구성됩니다.
참고
가상 시스템에 설치된 IdM 서버에서 NTP 서버를 실행하면 일부 환경에서 부정확한 시간 동기화가 발생할 수 있습니다. 잠재적인 문제를 방지하려면 가상 시스템에 설치된 IdM 서버에서 NTP를 실행하지 마십시오. 가상 머신의 NTP 서버 안정성에 대한 자세한 내용은 이 지식베이스 솔루션을 참조하십시오.
Apache HTTP Server: httpd
Apache HTTP 웹 서버는 IdM 웹 UI를 제공하며 인증 기관과 기타 IdM 서비스 간의 통신도 관리합니다.
Samba / Winbind:>-& lt; ,winbind
Samba 는 Red Hat Enterprise Linux에서 CIFS(Common Internet File System) 프로토콜이라고도 하는 SMB(Server Message Block) 프로토콜을 구현합니다. CloudEvent 서비스를 통해 CloudEvent 프로토콜을 통해 파일 공유 및 공유 프린터와 같은 서버의 리소스에 액세스할 수 있습니다. AD(Active Directory) 환경을 사용하여 트러스트를 구성한 경우 Winbind 서비스는 IdM 서버와 AD 서버 간의 통신을 관리합니다.
  • 자세한 내용은 시스템 관리자 가이드의 Samba 를 참조하십시오.
  • 자세한 내용은 시스템 수준 인증 가이드Winbind 를 참조하십시오.
일회성 암호(OTP) 인증: ipa-otpd
일회성 암호(OTP) 는 이중 인증의 일환으로 한 세션에 대해서만 인증 토큰으로 생성된 암호입니다. OTP 인증은 ipa-otpd 서비스를 통해 Red Hat Enterprise Linux에서 구현됩니다.
custodia: ipa-custodia
cus todia는 Secrets 서비스 공급자이며 암호, 키, 토큰, 인증서와 같은 비밀 자료에 대한 액세스를 저장하고 공유합니다.
OpenDNSSEC: ipa-dnskeysyncd
OpenDNSSEC는 DNSSEC (DNS 보안 확장) 키와 영역의 서명을 추적하는 프로세스를 자동화하는 DNS 관리자입니다. ipa-dnskeysyncd servuce는 IdM Directory Server와 OpenDNSSEC 간의 동기화를 관리합니다.

그림 1.1. ID 관리 서버: 서비스 통합

ID 관리 서버: 서비스 통합

1.2.2. Identity Management 클라이언트

IdM 클라이언트는 IdM 도메인 내에서 작동하도록 구성된 시스템입니다. IdM 서버와 상호 작용하여 도메인 리소스에 액세스합니다. 예를 들어 서버에 구성된 Kerberos 도메인에 속하고 서버에서 발급한 인증서 및 티켓을 수신하며 인증 및 권한 부여를 위해 다른 중앙 집중식 서비스를 사용합니다.
IdM 클라이언트에는 도메인의 일부로 상호 작용하는 전용 클라이언트 소프트웨어가 필요하지 않습니다. Kerberos 또는 DNS와 같은 특정 서비스 및 라이브러리에 대한 적절한 시스템 구성만 있으면 됩니다. 이 구성은 클라이언트 시스템에 IdM 서비스를 사용하도록 지시합니다.
IdM 클라이언트 설치에 대한 자세한 내용은 3장. ID 관리 클라이언트 설치 및 제거 을 참조하십시오.

1.2.2.1. IdM 클라이언트가 호스팅하는 서비스

System Security Services Daemon: sssd
SSSD (System Security Services Daemon) 는 사용자 인증 및 캐싱 자격 증명을 관리하는 클라이언트 측 애플리케이션입니다.
캐싱을 사용하면 IdM 서버를 사용할 수 없거나 클라이언트가 오프라인 상태가 되는 경우 로컬 시스템에서 일반 인증 작업을 계속할 수 있습니다.
자세한 내용은 시스템 수준 인증 가이드의 SSSD 구성 을 참조하십시오. SSSD는 Windows Active Directory(AD)도 지원합니다. AD와 함께 SSSD를 사용하는 방법에 대한 자세한 내용은 Windows 통합 가이드의 SSSD에 Active Directory를 ID 공급자로 사용하기 를 참조하십시오.
certmonger
certmonger 서비스는 클라이언트의 인증서를 모니터링 및 갱신합니다. 시스템의 서비스에 대한 새 인증서를 요청할 수 있습니다.
자세한 내용은 시스템 수준 인증 가이드의 certmonger 작업을 참조하십시오.

그림 1.2. IdM 서비스 간 상호 작용

IdM 서비스 간 상호 작용

II 부. Identity Management 설치

이 부분에서는 Identity Management 배포를 계획하는 방법과 Identity Management 서버, 클라이언트 및 복제본을 설치하는 방법을 설명합니다.

2장. ID 관리 서버 설치 및 제거

IdM( Identity Management ) 서버는 도메인 컨트롤러로, IdM 도메인을 정의하고 관리합니다. IdM 서버를 설정하려면 다음을 수행해야 합니다.
  1. 필요한 패키지 설치
  2. 설정 스크립트를 사용하여 시스템 구성
부하 분산 및 중복을 위해 도메인에 여러 도메인 컨트롤러를 설정하는 것이 좋습니다. 이러한 추가 서버는 초기 마스터 IdM 서버의 복제본 입니다.
이 장에서는 첫 번째 초기 IdM 서버 설치에 대해 설명합니다. 초기 서버에서 복제본 설치에 대한 자세한 내용은 4장. ID 관리 복제본 설치 및 제거 을 참조하십시오.

2.1. 서버 설치 사전 요구 사항

2.1.1. 최소 하드웨어 요구 사항

IdM(Identity Management)을 실행하려면 서버에 최소한 다음 하드웨어 구성이 필요합니다.
  • 1 (가상) CPU 코어
  • 2GB RAM
    RAM이 적은 IdM을 설치할 수 있지만 IdM 업데이트와 같은 특정 작업에는 4GB 이상의 RAM이 필요합니다.
  • 10GB 하드 디스크
중요
데이터베이스에 저장된 데이터의 양에 따라 IdM에는 더 많은 리소스, 특히 더 많은 RAM이 필요합니다. 자세한 내용은 2.1.2절. “하드웨어 권장 사항” 의 내용을 참조하십시오. 필요한 하드웨어 리소스는 서버의 프로덕션 워크로드 또는 Active Directory에 대한 신뢰와 같은 다른 요인에 따라 달라집니다.

2.1.2. 하드웨어 권장 사항

RAM은 적절하게 크기를 조정하는 가장 중요한 하드웨어 기능입니다. 필요한 RAM 양을 확인하려면 다음 권장 사항을 고려하십시오.
  • 10,000명의 사용자와 100개 그룹의 경우: 최소 3GB의 RAM 및 1GB 스왑 공간
  • 사용자 100,000명 및 50,000개 그룹의 경우: 최소 16GB의 RAM 및 4GB의 스왑 공간
참고
인증서가 있는 기본 사용자 항목 또는 간단한 호스트 항목은 크기가 약 5~10KiB입니다.
대규모 배포의 경우 대부분의 데이터가 캐시에 저장되므로 디스크 공간을 늘리는 것보다 RAM을 늘리는 것이 더 효과적입니다.
성능을 높이기 위해 기본 Directory Server를 조정하여 성능을 향상시킬 수 있습니다. 자세한 내용은 Red Hat Directory Server Performance Tuning Guide 를 참조하십시오.

2.1.3. 시스템 요구 사항

Identity Management는 Red Hat Enterprise Linux 7에서 지원됩니다. DNS, Kerberos 또는 디렉터리 서버와 같은 서비스에 대한 사용자 지정 구성 없이 클린 시스템에 IdM 서버를 설치합니다.
중요
성능 및 안정성을 위해 Red Hat은 IdM 서버에 다른 애플리케이션 또는 서비스를 설치하지 않는 것이 좋습니다. 예를 들어 IdM 서버는 특히 LDAP 오브젝트 수가 높은 경우 시스템에 전체적으로 지정할 수 있습니다. 또한 IdM은 시스템에 통합되어 타사 애플리케이션이 IdM에 따라 구성 파일을 변경하는 경우 IdM이 중단될 수 있습니다.
IdM 서버 설치는 시스템 파일을 덮어쓰므로 IdM 도메인을 설정합니다. IdM은 원본 시스템 파일을 /var/lib/ipa/sysrestore/에 백업합니다.
NSCD(Name Service Cache Daemon) 요구사항
Red Hat은 ID 관리 시스템에서 NSCD를 비활성화할 것을 권장합니다. 또는 NSCD를 비활성화할 수 없는 경우 SSSD에서 캐시하지 않는 맵에 대해 NSCD만 활성화합니다.
NSCD 및 SSSD 서비스는 둘 다 캐싱을 수행하며 두 서비스를 동시에 사용할 때 문제가 발생할 수 있습니다. NSCD와 SSSD 간 충돌을 방지하는 방법에 대한 자세한 내용은 시스템 수준 인증 가이드 를 참조하십시오.
시스템에서 IPv6를 활성화해야 합니다
IdM 서버에는 커널에서 IPv6 프로토콜이 활성화되어 있어야 합니다. IPv6는 Red Hat Enterprise Linux 7 시스템에서 기본적으로 활성화되어 있습니다.
이전에 IPv6를 비활성화한 경우 Red Hat Knowledgebase에서 어떻게 Red Hat Enterprise Linux에서 IPv6 프로토콜을 비활성화하거나 활성화합니까? 에 설명된 대로 다시 활성화하십시오.
참고
IdM은 클라이언트로 등록하려는 호스트의 커널에서 IPv6 프로토콜을 활성화할 필요가 없습니다. 예를 들어 내부 네트워크에서 IPv4 프로토콜만 사용하는 경우 IPv4만 사용하여 IdM 서버와 통신하도록 SSSD(System Security Services Daemon)를 구성할 수 있습니다. /etc/sssd/sssd.conf 파일의 [domain/_NAME_] 섹션에 다음 행을 삽입하면 됩니다.
lookup_family_order = ipv4_only
lookup_family_order 에 대한 자세한 내용은 sssd.conf(5) 매뉴얼 페이지를 참조하십시오.

2.1.4. FIPS 환경에서 서버 설치 사전 요구 사항

Red Hat Enterprise Linux 7.4 이상을 사용하여 설정된 환경에서 다음을 수행합니다.
  • FIPS(Federal Information Processing Standard) 모드를 활성화한 시스템에서 새 IdM 서버 또는 복제본을 구성할 수 있습니다. 설치 스크립트는 FIPS가 활성화된 시스템을 자동으로 감지하고 관리자의 개입없이 IdM을 구성합니다.
    운영 체제에서 FIPS를 활성화하려면 보안 가이드에서 FIPS 모드 활성화 를 참조하십시오.
    중요
    다음을 수행할 수 없습니다.
    • FIPS 모드가 비활성화된 상태로 이전에 설치된 기존 IdM 서버에서 FIPS 모드를 활성화합니다.
    • FIPS 모드가 비활성화된 기존 IdM 서버를 사용하는 경우 FIPS 모드에서 복제본을 설치합니다.
Red Hat Enterprise Linux 7.3 또는 이전 버전을 사용하여 설정된 환경에서 다음을 수행합니다.
  • IdM은 FIPS 모드를 지원하지 않습니다. IdM 서버 또는 복제본을 설치하기 전에 시스템에서 FIPS를 비활성화하고 설치 후 활성화하지 마십시오.
FIPS 모드에 대한 자세한 내용은 보안 가이드의 연방 정보 처리 표준(FIPS) 을 참조하십시오.

2.1.5. 호스트 이름 및 DNS 구성

주의
매우 주의해서 다음 사항을 확인하십시오:
  • 테스트되고 기능적인 DNS 서비스를 사용할 수 있습니다.
  • 서비스가 올바르게 구성되어 있습니다.
이 요구 사항은 통합된 DNS 서비스가 있는 IdM 서버와 DNS 없이 설치된 IdM 서버에 적용됩니다. LDAP 디렉토리 서비스, Kerberos 및 Active Directory 통합 실행을 비롯한 거의 모든 IdM 도메인 기능에 DNS 레코드가 필수적입니다.
기본 DNS 도메인과 Kerberos 영역은 설치 후 변경할 수 없습니다.
단일 레이블 도메인 이름(예: .company ): IdM 도메인은 하나 이상의 하위 도메인과 최상위 도메인(예: example.com 또는 company.example.com )으로 구성되어야 합니다.
서버 호스트에는 DNS 서버가 IdM 내에 통합되었는지 아니면 외부적으로 호스팅되었는지에 관계없이 DNS를 올바르게 구성해야 합니다.
ID 관리를 위해서는 서비스 레코드에 사용할 하나의 개별 DNS 도메인이 필요합니다. DNS 수준에서 충돌을 피하기 위해 이름이 IdM Kerberos 이름의 소문자 버전인 DNS 도메인인 기본 IdM DNS 도메인은 다른 IdM 또는 AD 도메인과 같은 다른 시스템과 공유할 수 없습니다.
기본 IdM DNS 도메인에는 표준 IdM 서비스에 대한 자체 SRV 레코드가 포함되어야 합니다. 필수 레코드는 다음과 같습니다.
  • _kerberos._tcp의 SRV 레코드.domain_name 및 _kerberos._udp.domain_name
  • _ldap._tcp.domain_name의 SRV 레코드
  • _kerberos의 TXT 레코드.domain_name
ipa 명령줄 툴을 통해 등록된 클라이언트가 IdM에서 제공하거나 중재된 서비스를 찾고 있는 경우 /etc/ipa/default.conf 파일에서 xmlrpc_uri 매개변수로 지정한 서버를 찾습니다. 필요한 경우 동일한 파일의 domain 매개 변수에 지정된 IdM DNS 도메인 이름을 조회하고 해당 도메인에 대해 _ldap._tcp.domain_name SRV 레코드를 참조하여 찾고 있는 서버를 확인합니다. /etc/ipa/default.conf 파일에 지정된 도메인이 없는 경우 클라이언트는 파일의 xmlrpc_uri 매개변수에 설정된 서버에만 연결합니다.
IdM 클라이언트 및 서버의 호스트 이름은 기본 DNS 도메인의 일부일 필요는 없습니다. 그러나 AD(Active Directory)를 사용하는 신뢰 환경에서는 IdM 서버의 호스트 이름이 IdM 소유 도메인, IdM 영역과 연결된 도메인, 신뢰할 수 있는 AD 영역과 연결된 도메인이 아닌 IdM 소유 도메인의 일부여야 합니다. 신뢰의 관점에서, 이 연관은 Realm 도메인을 사용하여 관리됩니다.
Active Directory DNS 도메인의 호스트 이름을 사용하여 IdM 클라이언트에 액세스하도록 사용자를 구성하는 데 대한 자세한 내용은 클라이언트 자체가 IdM에 가입되는 동안 Windows 통합 가이드의 Active Directory DNS 도메인에서 IdM 클라이언트를 참조하십시오.

서버 호스트 이름 확인

호스트 이름은 server.example.com 과 같은 정규화된 도메인 이름이어야 합니다.
중요
단일 레이블 도메인 이름(예: .company)을 사용하지 마십시오. IdM 도메인은 하나 이상의 하위 도메인과 최상위 도메인(예: example.com 또는 company.example.com)으로 구성되어야 합니다.
정규화된 도메인 이름은 다음 조건을 충족해야 합니다.
  • 유효한 DNS 이름이므로 숫자, 영문자 및 하이픈(-)만 사용할 수 있습니다. 밑줄(_)과 같은 기타 문자는 호스트 이름에서 DNS 오류가 발생합니다.
  • 이 모든 것이 더 낮은 사례입니다. 대문자는 허용되지 않습니다.
  • 정규화된 도메인 이름은 루프백 주소로 해석해서는 안 됩니다. 127.0.0.1 이 아닌 머신의 공용 IP 주소로 확인되어야 합니다.
다른 권장 이름 지정 사례는 Red Hat Enterprise Linux 보안 가이드의 권장 이름 지정 사례를 참조하십시오.
시스템의 호스트 이름을 확인하려면 hostname 유틸리티를 사용합니다.
[root@server ~]# hostname
server.example.com
hostname의 출력은 localhost 또는 localhost6이 아니어야 합니다.

정방향 및 역방향 DNS 구성 확인

  1. 서버의 IP 주소를 가져옵니다. ip addr show 명령은 IPv4 및 IPv6 주소를 모두 표시합니다.
    • IPv4 주소는 inet 로 시작하는 행에 표시됩니다. 다음 예에서 구성된 IPv4 주소는 192.0.2.1 입니다.
    • IPv6 주소는 inet6 으로 시작하는 행에 표시됩니다. 전역 범위가 있는 IPv6 주소만 이 절차와 관련이 있습니다. 다음 예에서 반환된 IPv6 주소는 2001:DB8::1111 입니다.
    [root@server ~]# ip addr show
    ...
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    	link/ether 00:1a:4a:10:4e:33 brd ff:ff:ff:ff:ff:ff
    	inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic eth0
    		valid_lft 106694sec preferred_lft 106694sec
    	inet6 2001:DB8::1111/32 scope global dynamic
     		valid_lft 2591521sec preferred_lft 604321sec
    	inet6 fe80::56ee:75ff:fe2b:def6/64 scope link
    	       valid_lft forever preferred_lft forever
    
  2. dig 유틸리티를 사용하고 호스트 이름을 추가하여 정방향 DNS 구성을 확인합니다.
    1. dig +short server.example.com A 명령을 실행합니다. 반환된 IPv4 주소는 ip addr show 에서 반환된 IP 주소와 일치해야 합니다.
      [root@server ~]# dig +short server.example.com A
      192.0.2.1
      
    2. dig +short server.example.com AAAA 명령을 실행합니다. 명령에서 주소를 반환하는 경우 ip addr show 에서 반환하는 IPv6 주소와 일치해야 합니다.
      [root@server ~]# dig +short server.example.com AAAA
      2001:DB8::1111
      
      참고
      AAAA 레코드에 대한 출력이 반환되지 않으면 잘못된 구성이 아닙니다. 출력은 서버 시스템의 DNS에 IPv6 주소가 구성되지 않음을 의미합니다. 네트워크에서 IPv6 프로토콜을 사용하지 않으려면 이 상황에서 설치를 진행할 수 있습니다.
  3. dig 유틸리티를 사용하고 IP 주소를 추가하여 역방향 DNS 구성(PTR 레코드)을 확인합니다.
    1. dig +short -x IPv4 address 명령을 실행합니다. 서버 호스트 이름이 명령 출력에 표시되어야 합니다. 예를 들어 다음과 같습니다.
      [root@server ~]# dig +short -x 192.0.2.1
      server.example.com
      
    2. 이전 단계의 dig +short -x server.example.com AAAA 명령에서 IPv6 주소를 반환한 경우 dig를 사용하여 IPv6 주소를 쿼리합니다. 다시 서버 호스트 이름이 명령 출력에 표시되어야 합니다. 예를 들어 다음과 같습니다.
      [root@server ~]# dig +short -x 2001:DB8::1111
      server.example.com
      
      참고
      이전 단계에서 dig +short server.example.com AAAA 가 IPv6 주소를 표시하지 않은 경우 AAAA 레코드를 쿼리해도 아무 것도 출력하지 않습니다. 이 경우 이는 정상적인 동작이며 잘못된 구성이 아닙니다.
    이전 단계에서 dig +short server.example.com 이 IP 주소를 반환하더라도 다른 호스트 이름 또는 호스트 이름이 표시되지 않으면 역방향 DNS 구성이 올바르지 않음을 나타냅니다.

DNS 전달자의 Standards-comliance 확인

통합된 DNS를 사용하여 IdM을 구성할 때 DNSSEC(DNS 보안 확장 ) 레코드 유효성 검사를 사용하는 것이 좋습니다. 다른 서버에서 서명된 DNS 레코드를 검증하면 스푸핑된 주소로부터 IdM 설치를 보호합니다. 그러나 DNSSEC 검증은 성공적인 IdM 설치를 위한 어려운 요구 사항이 아닙니다.
IdM 설치 프로그램은 기본적으로 DNSSEC 레코드 검증을 활성화합니다. DNSSEC 검증을 성공적으로 수행하려면 DNSSEC가 올바르게 구성된 전달자가 있어야 합니다. 설치하는 동안 IdM은 글로벌 전달자를 확인하고 전달자가 DNSSEC를 지원하지 않으면 전달자에서 DNSSEC 검증이 비활성화됩니다.
IdM DNS 서버와 함께 사용하려는 모든 DNS 전달자가 DNS (EDNS0) 및 DNSSEC 표준에 대한 확장 메커니즘 을 준수하는지 확인하려면 다음을 수행하십시오.
$ dig +dnssec @IP_address_of_the_DNS_forwarder . SOA
명령에 의해 표시되는 예상 출력에는 다음 정보가 포함됩니다.
  • 상태: NOERROR
  • 플래그: ra
  • EDNS 플래그: do
  • RRSIG 레코드가 ANSWER 섹션에 있어야 합니다.
출력에서 이러한 항목이 없는 경우 DNS 전달자의 문서를 검사하고 EDNS0 및 DNSSEC가 지원되고 활성화되었는지 확인합니다. 최신 버전의 BIND 서버에서 dnssec-enable yes; 옵션을 /etc/named.conf 파일에 설정해야 합니다.
예를 들어 예상되는 출력은 다음과 같을 수 있습니다.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48655
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

;; ANSWER SECTION:
. 31679 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015100701 1800 900 604800 86400
. 31679 IN RRSIG SOA 8 0 86400 20151017170000 20151007160000 62530 . GNVz7SQs [...]

/etc/hosts 파일

중요
/etc/hosts 파일을 수동으로 수정하지 마십시오. /etc/hosts 가 수정된 경우 해당 내용이 다음 규칙을 준수하는지 확인합니다.
다음은 올바르게 구성된 /etc/hosts 파일의 예입니다. 호스트의 IPv4 및 IPv6 localhost 항목과 함께 IdM 서버 IP 주소와 호스트 이름이 첫 번째 항목으로 올바르게 나열됩니다. IdM 서버 호스트 이름은 localhost 항목의 일부가 될 수 없습니다.
127.0.0.1	localhost.localdomain	localhost
::1		localhost6.localdomain6	localhost6
192.0.2.1	server.example.com	server
2001:DB8::1111	server.example.com	server

2.1.6. 포트 요구 사항

IdM은 여러 포트를 사용하여 해당 서비스와 통신합니다. IdM이 작동하려면 이러한 포트가 열리고 사용할 수 있어야 합니다. 다른 서비스에서 사용하거나 방화벽에서 차단할 수 없습니다.

필요한 포트 목록

표 2.1. ID 관리 포트

Service 포트 프로토콜
HTTP/HTTPS 80, 443 TCP
LDAP/LDAPS 389, 636 TCP
Kerberos 88, 464 TCP 및 UDP
DNS 53 TCP 및 UDP
NTP 123 UDP
참고
IdM은 포트 80 및 389를 사용합니다.
  • 포트 80(HTTP)은 온라인 인증서 상태 프로토콜(OCSP) 응답 및 CRL(인증서 폐기 목록)을 제공하는 데 사용됩니다. 둘 다 디지털 서명되므로 중간자(man-in-the-middle) 공격으로부터 보호됩니다.
  • 포트 389(LDAP)는 암호화에 STARTTLS 및 GSSAPI를 사용합니다.
또한 IdM은 포트 8080에서 수신 대기하고 일부 설치에서도 포트 8443 및 749에 수신 대기할 수 있습니다. 그러나 이러한 세 포트는 내부적으로만 사용됩니다. IdM은 열린 상태로 유지해도 외부에서 액세스할 필요가 없습니다. 포트 8080, 8443 및 749를 열지 않고 방화벽에서 차단한 상태로 두는 것이 좋습니다.

firewalld 서비스 목록

표 2.2. firewalld 서비스

서비스 이름 자세한 내용은 다음을 참조하십시오.
freeipa-ldap /usr/lib/firewalld/services/freeipa-ldap.xml
freeipa-ldaps /usr/lib/firewalld/services/freeipa-ldaps.xml
dns /usr/lib/firewalld/services/dns.xml

필요한 포트 열기

  1. firewalld 서비스가 실행 중인지 확인합니다.
    • firewalld 가 현재 실행되고 있는지 확인하려면 다음을 수행합니다.
      # systemctl status firewalld.service
    • firewalld 를 시작하고 시스템이 부팅될 때 자동으로 시작하도록 구성하려면 다음을 수행합니다.
      # systemctl start firewalld.service
      # systemctl enable firewalld.service
  2. firewall-cmd 유틸리티를 사용하여 필요한 포트를 엽니다. 다음 옵션 중 하나를 선택하십시오.
    1. firewall-cmd --add-port 명령을 사용하여 방화벽에 개별 포트를 추가합니다. 예를 들어 기본 영역에서 포트를 열려면 다음을 수행합니다.
      # firewall-cmd --permanent --add-port={80/tcp,443/tcp,list_of_ports}
    2. firewall-cmd --add-service 명령을 사용하여 방화벽에 firewalld 서비스를 추가합니다. 예를 들어 기본 영역에서 포트를 열려면 다음을 수행합니다.
      # firewall-cmd --permanent --add-service={freeipa-ldap,list_of_services}
    firewall-cmd 를 사용하여 시스템의 포트를 여는 방법에 대한 자세한 내용은 보안 가이드 또는 firewall-cmd(1) 매뉴얼 페이지에서 CLI를 사용하여 런타임 및 영구 구성의 설정 수정을 참조하십시오.
  3. firewall-cmd 구성을 다시 로드하여 변경 사항이 즉시 수행되었는지 확인합니다.
    # firewall-cmd --reload
    프로덕션 환경에서 시스템에서 firewalld 를 다시 로드하면 DNS 연결이 시간 초과될 수 있습니다. 보안 가이드CLI를 사용하여 런타임의 설정 수정 및 영구 구성 도 참조하십시오. 필요한 경우 시간 초과를 방지하고 실행 중인 시스템에서 변경 사항을 영구적으로 만들려면 firewall-cmd 명령의 --runtime-to-permanent 옵션을 사용합니다. 예를 들면 다음과 같습니다.
    # firewall-cmd --runtime-to-permanent --add-port={80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,88/udp,464/tcp,464/udp,53/tcp,53/udp,123/udp}
  4. 선택 사항입니다. 포트를 사용할 수 있는지 확인하려면 nc,telnet 또는 nmap 유틸리티를 사용하여 포트에 연결하거나 포트 스캔을 실행합니다.
참고
또한 들어오고 나가는 트래픽 모두에 대해 네트워크 기반 방화벽을 열어야 합니다.

2.2. IdM 서버 설치에 필요한 패키지

통합 DNS 서비스 없이 서버에 필요한 패키지를 설치하려면 다음을 수행합니다.
# yum install ipa-server
통합 DNS 서비스를 사용하여 서버에 필요한 패키지를 설치하려면 다음을 수행합니다.
# yum install ipa-server ipa-server-dns
참고
사용 사례에 DNS가 적합한지 확인하려면 2.3.1절. “통합 DNS 사용 여부 결정” 을 참조하십시오.
ipa-server 패키지는 다음과 같은 종속성으로 기타 필수 패키지를 자동으로 설치합니다.
  • Directory 서버 LDAP 서비스용 389-DS-base
  • Kerberos 서비스용 krb5-server 패키지
  • 다양한 IdM 관련 툴

2.3. IdM 서버 설치: 소개

참고
다음 섹션의 설치 절차와 예제는 함께 사용할 수 없습니다. 필요한 결과를 얻기 위해 결합할 수 있습니다. 예를 들어, 통합된 DNS와 외부 호스트 루트 CA로 서버를 설치할 수 있습니다.
ipa-server-install 유틸리티는 IdM 서버를 설치 및 구성합니다.
서버를 설치하기 전에 다음 섹션을 참조하십시오.
ipa-server-install 유틸리티는 자동화된 서버 설정을 허용하는 비대화형 설치 모드를 제공합니다. 자세한 내용은 를 참조하십시오. 2.3.7절. “비활성 서버 설치”
ipa-server-install 설치 스크립트는 /var/log/ipaserver-install.log에 로그 파일을 생성합니다. 설치에 실패하면 로그가 문제를 식별하는 데 도움이 될 수 있습니다.

2.3.1. 통합 DNS 사용 여부 결정

IdM은 통합된 DNS를 통해 또는 통합된 DNS 없이 서버를 설치할 수 있도록 지원합니다.
통합 DNS 서비스가 포함된 IdM 서버
IdM에서 제공하는 통합 DNS 서버는 범용 DNS 서버로 사용하도록 설계되지 않았습니다. IdM 배포 및 유지 관리와 관련된 기능만 지원합니다. 일부 고급 DNS 기능은 지원하지 않습니다.
Red Hat은 IdM 배포 내의 기본 사용에 대해 IdM 통합 DNS를 강력하게 권장합니다. IdM 서버가 DNS도 관리하는 경우 DNS와 기본 IdM 툴이 긴밀하게 통합되어 일부 DNS 레코드 관리를 자동화할 수 있습니다.
IdM 서버를 마스터 DNS 서버로 사용하는 경우에도 다른 외부 DNS 서버를 슬레이브 서버로 사용할 수 있습니다.
예를 들어, 사용 환경에서 Active Directory 통합 DNS 서버와 같은 다른 DNS 서버를 이미 사용하고 있는 경우 IdM 기본 도메인만 IdM 통합 DNS에 위임할 수 있습니다. IdM 통합 DNS로 DNS 영역을 마이그레이션할 필요가 없습니다.
참고
SAN(Subject Alternative Name) 확장에 IP 주소가 있는 IdM 클라이언트의 인증서를 발행해야 하는 경우 IdM 통합 DNS 서비스를 사용해야 합니다.
통합 DNS가 포함된 서버를 설치하려면 다음을 참조하십시오. 2.3.3절. “통합 DNS로 서버 설치”
통합 DNS 서비스가 없는 IdM 서버
외부 DNS 서버는 DNS 서비스를 제공하는 데 사용됩니다. 다음 상황에서 DNS 없이 IdM 서버를 설치하는 것이 좋습니다.
  • IdM DNS 범위를 벗어난 고급 DNS 기능이 필요한 경우
  • 외부 DNS 서버를 사용할 수 있도록 구성된 DNS 인프라가 있는 환경에서
통합 DNS 없이 서버를 설치하려면 를 참조하십시오. 2.3.4절. “통합 DNS가 없는 서버 설치”
중요
시스템이 2.1.5절. “호스트 이름 및 DNS 구성” 에 설명된 DNS 요구 사항을 충족하는지 확인합니다.

통합 또는 외부 DNS에 대한 유지 관리 요구 사항

통합 DNS 서버를 사용하는 경우 대부분의 DNS 레코드 유지 관리가 자동화됩니다. 필수 항목만 있으면 됩니다.
  • 상위 도메인에서 IdM 서버로 올바른 위임 설정
    예를 들어 IdM 도메인 이름이 ipa.example.com 인 경우 example.com 도메인에서 올바르게 위임해야 합니다.
    참고
    다음 명령을 사용하여 위임을 확인할 수 있습니다.
    # dig @IP_address +norecurse +short ipa.example.com. NS
    ip_addressexample.com DNS 도메인을 관리하는 서버의 IP 주소입니다. 위임이 올바르면 명령에서 DNS 서버가 설치된 IdM 서버를 나열합니다.
외부 DNS 서버를 사용하는 경우 다음을 수행해야 합니다.
  • DNS 서버에서 수동으로 새 도메인 생성
  • IdM 설치 프로그램에서 생성된 영역 파일의 레코드를 사용하여 새 도메인을 수동으로 입력합니다.
  • 복제본을 설치하거나 제거한 후 및 Active Directory 신뢰가 구성된 후와 같이 서비스 구성을 변경한 후에 수동으로 레코드를 업데이트합니다.

DNS 분할 공격 방지

IdM 통합 DNS 서버의 기본 구성을 사용하면 모든 클라이언트가 DNS 서버에 재귀적 쿼리를 실행할 수 있습니다. 서버가 신뢰할 수 없는 클라이언트가 있는 네트워크에 배포된 경우 서버의 구성을 변경하여 권한 있는 클라이언트로만 재귀를 제한합니다. [1]
권한이 부여된 클라이언트만 재귀 쿼리를 실행할 수 있도록 하려면 서버의 /etc/named.conf 파일에 적절한 ACL(액세스 제어 목록) 문을 추가합니다. 예를 들어 다음과 같습니다.
acl authorized { 192.0.2.0/24; 198.51.100.0/24; };
options {
  allow-query { any; };
  allow-recursion { authorized; };
};

2.3.2. 사용할 CA 구성 결정

IdM은 통합된 IdM 인증 기관(CA)을 사용하거나 CA가 없는 서버를 설치할 수 있도록 지원합니다.
통합 IdM CA가 있는 서버
대부분의 배포에 적합한 기본 구성입니다. Certificate System은 CA 서명 인증서를 사용하여 IdM 도메인에서 인증서를 생성하고 서명합니다.
주의
두 개 이상의 서버에 CA 서비스를 설치하는 것이 좋습니다. CA 서비스를 포함한 초기 서버 복제 설치에 대한 자세한 내용은 4.5.4절. “CA를 사용하여 복제본 설치” 을 참조하십시오.
CA를 하나의 서버에만 설치하는 경우 CA 서버가 실패할 경우 복구 가능성 없이 CA 구성을 손실할 수 있습니다. 자세한 내용은 B.2.6절. “손실된 CA 서버 복구” 을 참조하십시오.
IdM CA 서명 인증서는 자체 서명 라고도 하는 루트 CA 또는 외부 CA에서 서명할 수 있습니다.
IdM CA는 루트 CA입니다.
기본 구성입니다.
이 구성으로 서버를 설치하려면 2.3.3절. “통합 DNS로 서버 설치”2.3.4절. “통합 DNS가 없는 서버 설치” 을 참조하십시오.
외부 CA는 루트 CA입니다.
IdM CA는 외부 CA에 종속되어 있습니다. 그러나 IdM 도메인의 모든 인증서는 인증서 시스템 인스턴스에서 계속 발급됩니다.
외부 CA는 corporate CA 또는 Thawte와 같은 타사 CA일 수 있습니다. 외부 CA는 루트 CA 또는 하위 CA일 수 있습니다. IdM 도메인 내에서 발행된 인증서는 유효 기간 또는 인증서를 발급할 수 있는 도메인과 같이 외부 루트 CA 또는 중간 CA 인증서에서 설정한 제한 사항을 적용할 수 있습니다.
외부 호스트 루트 CA를 사용하여 서버를 설치하려면 다음을 참조하십시오. 2.3.5절. “외부 CA를 루트 CA로 사용하여 서버 설치”
CA가 없는 서버
이 구성 옵션은 인프라 내 제한이 서버에 인증서 서비스를 설치할 수 없는 경우 매우 드문 경우에 적합합니다.
설치하기 전에 타사 기관에서 이러한 인증서를 요청해야 합니다.
  • LDAP 서버 인증서 및 개인 키
  • Apache 서버 인증서 및 개인 키
  • LDAP 및 Apache 서버 인증서를 발급한 CA의 전체 CA 인증서 체인
주의
통합 IdM CA 없이 인증서를 관리하는 것은 상당한 유지 관리 부담입니다. 예를 들어, IdM 서버의 Apache 웹 서버 및 LDAP 서버 인증서를 수동으로 관리해야 합니다. 여기에는 다음이 포함됩니다.
  • 인증서 생성 및 업로드.
  • 인증서 만료 날짜 모니터링. certmonger 서비스는 통합 CA 없이 IdM을 설치한 경우 인증서를 추적하지 않습니다.
  • 중단을 방지하기 위해 만료되기 전에 인증서를 갱신합니다.
통합된 CA 없이 서버를 설치하려면 다음을 참조하십시오. 2.3.6절. “CA 없는 상태에서 설치”
참고
CA 없이 IdM 도메인을 설치하는 경우 나중에 CA 서비스를 설치할 수 있습니다. 기존 IdM 도메인에 CA를 설치하려면 26.8절. “기존 IdM 도메인에 CA 설치” 을 참조하십시오.

2.3.3. 통합 DNS로 서버 설치

참고
어떤 DNS 또는 CA 구성이 적합한지 모르는 경우 2.3.1절. “통합 DNS 사용 여부 결정”2.3.2절. “사용할 CA 구성 결정” 을 참조하십시오.
통합 DNS를 사용하여 서버를 설치하려면 설치 프로세스 중에 다음 정보를 입력합니다.
DNS 전달자
다음 DNS 전달자 설정이 지원됩니다.
  • 하나 이상의 전달자(대화식 설치의 --forwarder 옵션)
  • 전달자 없음(대화식 설치의 --no-forwarders 옵션)
DNS 전달을 사용할지 여부를 모르는 경우 33.6절. “DNS 전달 관리” 을 참조하십시오.
역방향 DNS 영역
다음과 같은 역방향 DNS 영역 설정이 지원됩니다.
  • IdM DNS에서 생성해야 하는 역방향 영역의 자동 감지(상호식 설치의 기본 설정, 비대화형 설치의 --auto-reverse 옵션)
  • 역방향 영역 자동 감지(상호 설치의 --no-reverse 옵션)가 없습니다.
-- auto-reverse 옵션이 설정된 경우 --allow-zone- overlap 옵션이 무시됩니다. 옵션 조합 사용:
$ ipa-server-install --auto-reverse --allow-zone-overlap
따라서 다른 DNS 서버 등의 기존 DNS 영역과 겹치는 역방향 영역을 생성하지 않습니다.
비대화형 설치의 경우 --setup-dns 옵션도 추가합니다.

예 2.1. 통합 DNS로 서버 설치

이 절차에서는 서버를 설치합니다.
  • 통합 DNS 사용
  • 기본 CA 구성인 루트 CA로 통합 IdM CA 사용
  1. ipa-server-install 유틸리티를 실행합니다.
    # ipa-server-install
  2. 스크립트는 통합 DNS 서비스를 구성하라는 메시지를 표시합니다. yes 를 입력합니다.
    Do you want to configure integrated DNS (BIND)? [no]: yes
  3. 스크립트에서 몇 가지 필수 설정에 대한 메시지를 표시합니다.
    • 대괄호로 기본값을 허용하려면 Enter 를 누릅니다.
    • 제안된 기본값과 다른 값을 제공하려면 필수 값을 입력합니다.
    Server host name [server.example.com]:
    Please confirm the domain name [example.com]:
    Please provide a realm name [EXAMPLE.COM]:
    주의
    Red Hat은 Kerberos 영역 이름이 기본 DNS 도메인 이름과 동일하며 모든 문자를 대문자로 표시하는 것이 좋습니다. 예를 들어 기본 DNS 도메인이 ipa.example.com 인 경우 Kerberos 영역 이름에 IPA.EXAMPLE.COM 을 사용합니다.
    이름 지정 방법이 다르면 Active Directory 트러스트를 사용하지 않으며 다른 부정적인 결과가 발생할 수 있습니다.
  4. Directory Server superuser의 암호, cn=Directory Manager, admin IdM 시스템 사용자 계정에 암호를 입력합니다.
    Directory Manager password:
    IPA admin password:
  5. 스크립트에서 DNS 전달자를 묻는 메시지를 표시합니다.
    Do you want to configure DNS forwarders? [yes]:
    • DNS 전달자를 구성하려면 yes 를 입력한 다음 명령줄의 지침을 따릅니다.
      설치 프로세스는 설치된 IdM 서버의 /etc/named.conf 파일에 전달자 IP 주소를 추가합니다.
      • 전달 정책 기본 설정은 ipa-dns-install(1) 도움말 페이지의 --forward-policy 설명을 참조하십시오.
      • 자세한 내용은 “전달 정책” 을 참조하십시오.
    • DNS 전달을 사용하지 않으려면 no 를 입력합니다.
  6. 스크립트에서는 서버와 연결된 IP 주소에 대한 DNS 역방향(PTR) 레코드를 구성해야 하는지 확인하라는 메시지를 표시합니다.
    Do you want to search for missing reverse zones? [yes]:
    검색 및 누락된 역방향 영역을 실행하면 스크립트에서 PTR 레코드와 함께 역방향 영역을 만들지 여부를 묻습니다.
    Do you want to create reverse zone for IP 192.0.2.1 [yes]:
    Please specify the reverse zone name [2.0.192.in-addr.arpa.]:
    Using reverse zone(s) 2.0.192.in-addr.arpa.
    참고
    IdM을 사용하여 역방향 영역을 관리하는 것은 선택 사항입니다. 대신 외부 DNS 서비스를 이 용도로 사용할 수 있습니다.
  7. yes 를 입력하여 서버 구성을 확인합니다.
    Continue to configure the system with these values? [no]: yes
  8. 이제 설치 스크립트에서 서버를 구성합니다. 작업이 완료될 때까지 기다립니다.
  9. 상위 도메인에서 IdM DNS 도메인에 DNS 위임을 추가합니다. 예를 들어 IdM DNS 도메인이 ipa.example.com 인 경우 example.com 상위 도메인에 이름 서버(NS) 레코드를 추가합니다.
    중요
    IdM DNS 서버가 설치될 때마다 이 단계를 반복해야 합니다.
이 스크립트는 CA 인증서를 백업하고 필요한 네트워크 포트가 열려 있는지 확인하는 것이 좋습니다. IdM 포트 요구 사항 및 이러한 포트를 여는 방법에 대한 지침은 2.1.6절. “포트 요구 사항” 을 참조하십시오.
새 서버를 테스트하려면 다음을 수행합니다.
  1. admin 자격 증명을 사용하여 Kerberos 영역에 인증합니다. 이렇게 하면 admin 이 올바르게 구성되어 Kerberos 영역에 액세스할 수 있는지 확인합니다.
    # kinit admin
  2. ipa user-find 와 같은 명령을 실행합니다. 새 서버에서 명령은 구성된 유일한 사용자인 admin 을 출력합니다.
    # ipa user-find admin
    --------------
    1 user matched
    --------------
    User login: admin 
    Last name: Administrator 
    Home directory: /home/admin 
    Login shell: /bin/bash 
    UID: 939000000 
    GID: 939000000 
    Account disabled: False 
    Password: True 
    Kerberos keys available: True 
    ----------------------------
    Number of entries returned 1
    ----------------------------

2.3.4. 통합 DNS가 없는 서버 설치

참고
어떤 DNS 또는 CA 구성이 적합한지 모르는 경우 2.3.1절. “통합 DNS 사용 여부 결정”2.3.2절. “사용할 CA 구성 결정” 을 참조하십시오.
통합된 DNS 없이 서버를 설치하려면 DNS 관련 옵션 없이 ipa-server-install 유틸리티를 실행합니다.

예 2.2. 통합 DNS가 없는 서버 설치

이 절차에서는 서버를 설치합니다.
  • 통합 DNS가 없는 경우
  • 기본 CA 구성인 루트 CA로 통합 IdM CA 사용
  1. ipa-server-install 유틸리티를 실행합니다.
    # ipa-server-install
  2. 스크립트는 통합 DNS 서비스를 구성하라는 메시지를 표시합니다. Enter 를 눌러 기본 no 옵션을 선택합니다.
    Do you want to configure integrated DNS (BIND)? [no]:
  3. 스크립트에서 몇 가지 필수 설정에 대한 메시지를 표시합니다.
    • 대괄호로 기본값을 허용하려면 Enter 를 누릅니다.
    • 제안된 기본값과 다른 값을 제공하려면 필수 값을 입력합니다.
    Server host name [server.example.com]:
    Please confirm the domain name [example.com]:
    Please provide a realm name [EXAMPLE.COM]:
    주의
    Red Hat은 Kerberos 영역 이름이 기본 DNS 도메인 이름과 동일하며 모든 문자를 대문자로 표시하는 것이 좋습니다. 예를 들어 기본 DNS 도메인이 ipa.example.com 인 경우 Kerberos 영역 이름에 IPA.EXAMPLE.COM 을 사용합니다.
    이름 지정 방법이 다르면 Active Directory 트러스트를 사용하지 않으며 다른 부정적인 결과가 발생할 수 있습니다.
  4. Directory Server superuser의 암호, cn=Directory Manager, admin IdM 시스템 사용자 계정에 암호를 입력합니다.
    Directory Manager password:
    IPA admin password:
  5. yes 를 입력하여 서버 구성을 확인합니다.
    Continue to configure the system with these values? [no]: yes
  6. 이제 설치 스크립트에서 서버를 구성합니다. 작업이 완료될 때까지 기다립니다.
  7. 설치 스크립트는 DNS 리소스 레코드가 있는 파일인 /tmp/ipa.system. recordss.UFRPto.db 파일을 아래 예제 출력에 생성합니다. 이러한 레코드를 기존 외부 DNS 서버에 추가합니다. DNS 레코드를 업데이트하는 프로세스는 특정 DNS 솔루션에 따라 다릅니다.
    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
    중요
    기존 DNS 서버에 DNS 레코드를 추가할 때까지 서버 설치가 완료되지 않습니다.
이 스크립트는 CA 인증서를 백업하고 필요한 네트워크 포트가 열려 있는지 확인하는 것이 좋습니다. IdM 포트 요구 사항 및 이러한 포트를 여는 방법에 대한 지침은 2.1.6절. “포트 요구 사항” 을 참조하십시오.
새 서버를 테스트하려면 다음을 수행합니다.
  1. admin 자격 증명을 사용하여 Kerberos 영역에 인증합니다. 이렇게 하면 admin 이 올바르게 구성되어 Kerberos 영역에 액세스할 수 있는지 확인합니다.
    # kinit admin
  2. ipa user-find 와 같은 명령을 실행합니다. 새 서버에서 명령은 구성된 유일한 사용자인 admin 을 출력합니다.
    # ipa user-find admin
    --------------
    1 user matched
    --------------
    User login: admin 
    Last name: Administrator 
    Home directory: /home/admin 
    Login shell: /bin/bash 
    UID: 939000000 
    GID: 939000000 
    Account disabled: False 
    Password: True 
    Kerberos keys available: True 
    ----------------------------
    Number of entries returned 1
    ----------------------------

2.3.5. 외부 CA를 루트 CA로 사용하여 서버 설치

참고
어떤 DNS 또는 CA 구성이 적합한지 모르는 경우 2.3.1절. “통합 DNS 사용 여부 결정”2.3.2절. “사용할 CA 구성 결정” 을 참조하십시오.
서버를 설치하고 루트 CA로 외부 CA를 사용하여 연결하려면 ipa-server-install 유틸리티를 사용하여 다음 옵션을 전달합니다.
  • --external-ca 는 외부 CA를 사용하도록 지정합니다.
  • --external-ca-type 은 외부 CA의 유형을 지정합니다. 자세한 내용은 ipa-server-install(1) 매뉴얼 페이지를 참조하십시오.
그렇지 않으면 대부분의 설치 절차는 2.3.3절. “통합 DNS로 서버 설치” 또는 2.3.4절. “통합 DNS가 없는 서버 설치” 과 동일합니다.
인증서 시스템 인스턴스를 구성하는 동안 유틸리티는 CSR(인증서 서명 요청): /root/ipa.csr 의 위치를 출력합니다.
...

Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
  [1/8]: creating certificate server user
  [2/8]: configuring certificate server instance
The next step is to get /root/ipa.csr signed by your CA and re-run /sbin/ipa-server-install as: /sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
이 경우 다음을 수행합니다.
  1. /root/ipa.csr에 있는 CSR을 외부 CA에 제출합니다. 프로세스는 외부 CA로 사용할 서비스에 따라 다릅니다.
    중요
    인증서에 적절한 확장 기능을 요청해야 할 수 있습니다. Identity Management용으로 생성된 CA 서명 인증서는 유효한 CA 인증서여야 합니다. 이를 위해 기본 제약 조건 확장 true 에서 CA 매개변수를 설정해야 합니다. 자세한 내용은 RFC 5280기본 제약 조건 섹션을 참조하십시오.
  2. 64로 인코딩된 기본 Blob에서 발행된 CA의 발행 인증서 및 CA 인증서 체인을 검색합니다(Gecl 파일 또는 Windows CA의 Base_64 인증서). 이 프로세스는 모든 인증서 서비스에 따라 다릅니다. 일반적으로 웹 페이지 또는 알림 이메일에 있는 다운로드 링크를 통해 관리자는 필요한 모든 인증서를 다운로드할 수 있습니다.
    중요
    CA 인증서가 아닌 CA의 전체 인증서 체인을 가져와야 합니다.
  3. ipa-server-install을 다시 실행합니다. 이번에는 새로 발급한 CA 인증서와 CA 체인 파일의 위치 및 이름을 지정합니다. 예를 들어 다음과 같습니다.
    # ipa-server-install --external-cert-file=/tmp/servercert20110601.pem --external-cert-file=/tmp/cacert.pem
참고
ipa-server-install --external-ca 명령은 다음 오류로 인해 실패하는 경우가 있습니다.
ipa         : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/configuration_file' returned non-zero exit status 1
Configuration of CA failed
이 오류는 *_proxy 환경 변수가 설정될 때 발생합니다. 이 문제를 해결하는 방법에 대한 해결 방법은 다음을 참조하십시오. B.1.1절. “외부 CA 설치 실패”

2.3.6. CA 없는 상태에서 설치

참고
어떤 DNS 또는 CA 구성이 적합한지 모르는 경우 2.3.1절. “통합 DNS 사용 여부 결정”2.3.2절. “사용할 CA 구성 결정” 을 참조하십시오.
CA 없이 서버를 설치하려면 ipa-server-install 유틸리티에 옵션을 추가하여 필요한 인증서를 수동으로 제공해야 합니다. 그 외에도 대부분의 설치 절차는 2.3.3절. “통합 DNS로 서버 설치” 또는 2.3.4절. “통합 DNS가 없는 서버 설치” 과 동일합니다.
중요
자체 서명된 타사 서버 인증서를 사용하여 서버 또는 복제본을 설치할 수 없습니다.

CA 없이 IdM 서버 설치에 필요한 인증서

CA가 없는 IdM 서버 설치의 경우 다음 인증서를 제공해야 합니다.
  • 다음 옵션을 사용하여 제공되는 LDAP 서버 인증서 및 개인 키:
    • --dirsrv-cert-file: LDAP 서버 인증서에 대한 인증서 및 개인 키 파일
    • --dirsrv- cert-file에 지정된 파일의 개인 키에 액세스하는 암호가 --dirsrv-pin
  • 다음 옵션을 사용하여 제공되는 Apache 서버 인증서 및 개인 키:
    • 인증서 용 --HTTP-cert-file 및 Apache 서버 인증서에 대한 개인 키 파일
    • --http- cert-file에 지정된 파일의 개인 키에 액세스하는 암호의 --HTTP-pin
  • 다음 옵션을 사용하여 제공된 LDAP 및 Apache 서버 인증서를 발급한 CA의 전체 CA 인증서 체인입니다.
    • 전체 CA 인증서 체인 또는 일부 인증서 파일의 --dirsrv-cert-file 및 --http -cert-file
      다음 형식으로 --dirsrv-cert-file 및 --http- cert-file 옵션에 지정된 파일을 제공할 수 있습니다.
      • PEM(개인 정보 보호 이메일) 인코딩 인증서(RFC 7468). IdM 설치 프로그램에서는 연결된 PEM 인코딩 오브젝트를 사용할 수 있습니다.
      • 고유 인코딩 규칙(DER)
      • PKCS #7 인증서 체인 오브젝트
      • PKCS #8 개인 키 오브젝트
      • PKCS #12 아카이브
      --dirsrv-cert-file 및 --http- cert-file 옵션을 여러 번 지정하여 여러 파일을 지정할 수 있습니다.
  • 필요한 경우 다음 옵션을 사용하여 제공된 전체 CA 인증서 체인을 완료하는 인증서 파일입니다.
    • --CA-cert-file 은 이 옵션을 여러 번 추가할 수 있습니다.
  • 선택적으로, 다음 옵션을 사용하여 제공된 외부 KDC(Kerberos 키 배포 센터) PKINIT 인증서를 제공하는 인증서 파일:
    • Kerberos KDC SSL 인증서 및 개인 키의 --PKINIT-cert-file
    • Kerberos KDC 개인 키 잠금을 해제하는 암호가 --PKINIT-pin
    PKINIT 인증서를 제공하지 않으면 ipa-server-install 은 자체 서명된 인증서가 있는 로컬ECDHE로 IdM 서버를 구성합니다. 자세한 내용은 27장. IdM의 Kerberos PKINIT 인증 의 내용을 참조하십시오.
-- ca-cert- file 및 -- http-cert-file을 사용하여 제공된 파일과 함께 --dirsrv - cert-file 및 --http-cert-file 을 사용하여 제공된 파일에는 LDAP 및 Apache 서버 인증서를 발급한 CA의 전체 CA 인증서 체인이 있어야 합니다.
이러한 옵션에서 허용하는 인증서 파일 형식에 대한 자세한 내용은 ipa-server-install(1) 도움말 페이지를 참조하십시오.
참고
나열된 명령줄 옵션은 --external-ca 옵션과 호환되지 않습니다.
참고
이전 버전의 Identity Management에서는 --root-ca-file 옵션을 사용하여 루트 CA 인증서의 PEM 파일을 지정했습니다. 신뢰할 수 있는 CA가 항상 DS 및 HTTP 서버 인증서의 발급자이므로 이 작업은 더 이상 필요하지 않습니다. IdM은 이제 --dirsrv-cert-file, --http-cert-file--ca-cert-file 에 지정된 인증서에서 루트 CA 인증서를 자동으로 인식합니다.

예 2.3. CA 없이 IdM 서버 설치 명령 예

[root@server ~]# ipa-server-install \
    --http-cert-file /tmp/server.crt \
    --http-cert-file /tmp/server.key \
    --http-pin secret \
    --dirsrv-cert-file /tmp/server.crt \
    --dirsrv-cert-file /tmp/server.key \
    --dirsrv-pin secret \
    --ca-cert-file ca.crt

2.3.7. 비활성 서버 설치

참고
어떤 DNS 또는 CA 구성이 적합한지 모르는 경우 2.3.1절. “통합 DNS 사용 여부 결정”2.3.2절. “사용할 CA 구성 결정” 을 참조하십시오.
비대화식 설치에 필요한 최소 옵션은 다음과 같습니다.
  • Directory Server 슈퍼 사용자의 암호를 제공하는 --DS-password
  • --admin-password: IdM 관리자인 admin의 암호를 제공합니다.
  • Kerberos 영역 이름 제공 --realm
  • 설치 프로세스에서 호스트 이름 및 도메인 이름에 대한 기본 옵션을 선택하도록 하려면 --u nattended
선택적으로 다음 설정에 대한 사용자 정의 값을 제공할 수 있습니다.
  • 서버 호스트 이름에 --hostname
  • 도메인 이름의 --domain
사용자 지정 값으로 LDIF 파일의 경로를 지정하여 --dirsrv-config-file 매개변수를 사용하여 기본 Directory Server 설정을 변경할 수도 있습니다. 자세한 내용은 Red Hat Enterprise Linux 7.3 릴리스 노트에서 서버 또는 복제본 설치 중에 개별 디렉터리 서버 옵션 설정을 지원하는 IdM 을 참조하십시오.
주의
Red Hat은 Kerberos 영역 이름이 기본 DNS 도메인 이름과 동일하며 모든 문자를 대문자로 표시하는 것이 좋습니다. 예를 들어 기본 DNS 도메인이 ipa.example.com 인 경우 Kerberos 영역 이름에 IPA.EXAMPLE.COM 을 사용합니다.
이름 지정 방법이 다르면 Active Directory 트러스트를 사용하지 않으며 다른 부정적인 결과가 발생할 수 있습니다.
ipa-server-install 에서 허용하는 전체 옵션 목록은 ipa-server-install --help 명령을 실행하십시오.

예 2.4. 상호 작용이 없는 기본 설치

  1. 필요한 설정을 제공하여 ipa-server-install 유틸리티를 실행합니다. 예를 들어, 다음은 통합된 DNS 및 통합된 CA에 서버를 설치합니다.
    # ipa-server-install --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended
  2. 이제 설정 스크립트에서 서버를 구성합니다. 작업이 완료될 때까지 기다립니다.
  3. 설치 스크립트는 DNS 리소스 레코드가 있는 파일인 /tmp/ipa.system. recordss.UFRPto.db 파일을 아래 예제 출력에 생성합니다. 이러한 레코드를 기존 외부 DNS 서버에 추가합니다. DNS 레코드를 업데이트하는 프로세스는 특정 DNS 솔루션에 따라 다릅니다.
    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
    중요
    기존 DNS 서버에 DNS 레코드를 추가할 때까지 서버 설치가 완료되지 않습니다.
이 스크립트는 CA 인증서를 백업하고 필요한 네트워크 포트가 열려 있는지 확인하는 것이 좋습니다. IdM 포트 요구 사항 및 이러한 포트를 여는 방법에 대한 지침은 2.1.6절. “포트 요구 사항” 을 참조하십시오.
새 서버를 테스트하려면 다음을 수행합니다.
  1. admin 자격 증명을 사용하여 Kerberos 영역에 인증합니다. 이렇게 하면 admin 이 올바르게 구성되어 Kerberos 영역에 액세스할 수 있는지 확인합니다.
    # kinit admin
  2. ipa user-find 와 같은 명령을 실행합니다. 새 서버에서 명령은 구성된 유일한 사용자인 admin 을 출력합니다.
    # ipa user-find admin
    --------------
    1 user matched
    --------------
    User login: admin 
    Last name: Administrator 
    Home directory: /home/admin 
    Login shell: /bin/bash 
    UID: 939000000 
    GID: 939000000 
    Account disabled: False 
    Password: True 
    Kerberos keys available: True 
    ----------------------------
    Number of entries returned 1
    ----------------------------


[1] 자세한 내용은 DNS Amplification Attacks 페이지를 참조하십시오.

2.4. IdM 서버 설치 제거

참고
도메인 레벨 0 에서, 절차는 다릅니다. D.3.6절. “복제 제거” 참조하십시오.

사전 요구 사항

  • CA(인증 기관), KRA(키 복구 기관) 또는 DNSSEC(DNS Security Extensions) 서버 역할을 하는 서버를 설치 제거하기 전에 이러한 서비스가 도메인의 다른 서버에서 실행되고 있는지 확인합니다.
    주의
    CA, KRA 또는 DNSSEC 서버 역할을 하는 마지막 복제본을 제거하면 ID 관리 기능이 심각하게 중단될 수 있습니다.

절차

server.example.com 을 설치 제거하려면 다음을 수행합니다.
  1. 다른 서버에서 ipa server-del 명령을 사용하여 토폴로지에서 server.example.com 을 삭제합니다.
    [root@another_server ~]# ipa server-del server.example.com
  2. server.example.com 에서 ipa-server-install --uninstall 명령을 사용합니다.
    [root@server ~]# ipa-server-install --uninstall
  3. server.example.com 을 가리키는 모든 네임 서버(NS) DNS 레코드가 DNS 영역에서 삭제되었는지 확인합니다. 이는 IdM 또는 외부 DNS에서 관리하는 통합 DNS를 사용하든 상관없이 적용됩니다.

2.5. 서버 이름 변경

IdM 서버의 호스트 이름을 설정한 후에는 변경할 수 없습니다. 그러나 서버를 다른 이름으로 교체할 수 있습니다.
  1. CA 및 새 필수 호스트 이름 또는 IP 주소를 사용하여 서버의 새 복제본을 만듭니다. 자세한 내용은 4장. ID 관리 복제본 설치 및 제거 에서 참조하십시오.
  2. 초기 IdM 서버 인스턴스를 중지합니다.
    [root@old_server ~]# ipactl stop
  3. 다른 모든 복제본 및 클라이언트가 이전처럼 작동하는지 확인합니다.
  4. 에 설명된 대로 초기 IdM 서버를 설치 제거합니다 2.4절. “IdM 서버 설치 제거”

3장. ID 관리 클라이언트 설치 및 제거

이 장에서는 IdM(Identity Management) 도메인을 서버에 등록된 클라이언트 시스템으로 연결하도록 시스템을 구성하는 방법을 설명합니다.
참고
IdM 도메인의 클라이언트 및 서버에 대한 자세한 내용은 1.2절. “ID 관리 도메인” 을 참조하십시오.

3.1. 클라이언트 설치 사전 요구 사항

DNS 요구 사항
적절한 DNS 위임을 사용합니다. IdM의 DNS 요구 사항에 대한 자세한 내용은 2.1.5절. “호스트 이름 및 DNS 구성” 을 참조하십시오.
클라이언트의 resolv.conf 파일을 변경하지 마십시오.
포트 요구사항
IdM 클라이언트는 IdM 서버의 여러 포트에 연결하여 서비스와 통신합니다. 이러한 포트는 IdM 서버에서 들어오는 방향으로 열어야 합니다. IdM 포트에 대한 자세한 내용은 2.1.6절. “포트 요구 사항” 을 참조하십시오.
클라이언트에서 이러한 포트를 나가는 방향으로 엽니다. firewalld 와 같이 나가는 패킷을 필터링하지 않는 방화벽을 사용하는 경우 포트는 이미 발신 방향으로 사용할 수 있습니다.
NSCD(Name Service Cache Daemon) 요구사항
Red Hat은 ID 관리 시스템에서 NSCD를 비활성화할 것을 권장합니다. 또는 NSCD를 비활성화할 수 없는 경우 SSSD에서 캐시하지 않는 맵에 대해 NSCD만 활성화합니다.
NSCD 및 SSSD 서비스는 둘 다 캐싱을 수행하며 두 서비스를 동시에 사용할 때 문제가 발생할 수 있습니다. NSCD와 SSSD 간 충돌을 방지하는 방법에 대한 자세한 내용은 시스템 수준 인증 가이드 를 참조하십시오.

3.1.1. IdM 클라이언트 설치를 위해 지원되는 RHEL 버전

RHEL 7의 최신 마이너 버전에서 IdM 서버가 실행 중인 IdM(Identity Management) 배포는 최신 마이너 버전에서 실행되는 클라이언트를 지원합니다.
  • RHEL 7
    RHEL 8
    RHEL 9
참고
IdM 배포 FIPS를 준수하도록 하려는 경우 {RH}는 환경을 RHEL 9로 마이그레이션하는 것이 좋습니다. RHEL 9는 FIPS 140-3에 대해 인증된 첫 번째 주요 RHEL 버전입니다.

3.1.2. FIPS 환경에서 클라이언트 설치 사전 요구 사항

Red Hat Enterprise Linux 7.4 이상을 사용하여 설정된 환경에서 다음을 수행합니다.
  • FIPS(Federal Information Processing Standard) 모드를 사용하여 시스템에서 새 클라이언트를 구성할 수 있습니다. 설치 스크립트는 FIPS가 활성화된 시스템을 자동으로 감지하고 관리자의 개입없이 IdM을 구성합니다.
    운영 체제에서 FIPS를 활성화하려면 보안 가이드에서 FIPS 모드 활성화 를 참조하십시오.
Red Hat Enterprise Linux 7.3 또는 이전 버전을 사용하여 설정된 환경에서 다음을 수행합니다.
  • IdM은 FIPS 모드를 지원하지 않습니다. IdM 클라이언트를 설치하기 전에 시스템에서 FIPS를 비활성화하고 설치 후 활성화하지 마십시오.
FIPS 모드에 대한 자세한 내용은 보안 가이드의 연방 정보 처리 표준(FIPS) 을 참조하십시오.

3.2. 클라이언트 설치에 필요한 패키지

ipa-client 패키지를 설치합니다.
# yum install ipa-client
ipa-client 패키지는 SSSD(System Security Services Daemon) 패키지와 같은 종속성으로 기타 필수 패키지를 자동으로 설치합니다.

3.3. 클라이언트 설치

ipa-client-install 유틸리티는 IdM 클라이언트를 설치 및 구성합니다. 설치 프로세스에서는 클라이언트를 등록하는 데 사용할 수 있는 자격 증명을 제공해야 합니다. 다음과 같은 인증 방법이 지원됩니다.
admin과 같은 클라이언트를 등록할 권한이 있는 사용자의 자격 증명
기본적으로 ipa-client-install 에는 이 옵션이 필요합니다. 예를 보려면 3.3.1절. “클라이언트 대화형 설치” 을 참조하십시오.
ipa-client-install 에 사용자 자격 증명을 직접 제공하려면 --principal--password 옵션을 사용합니다.
서버에 미리 생성된 임의의 일회성 암호
이 인증 방법을 사용하려면 ipa-client-install 옵션에 --random 옵션을 추가합니다. 예 3.1. “임의 암호를 사용하여 비대화형 클라이언트 설치” 참조하십시오.
이전 등록의 주요 내용
이 인증 방법을 사용하려면 --keytab 옵션을 ipa-client-install 에 추가합니다. 자세한 내용은 3.8절. “IdM 도메인에 클라이언트를 다시 등록” 을 참조하십시오.
자세한 내용은 ipa-client-install(1) 매뉴얼 페이지를 참조하십시오.
다음 섹션에서는 기본 설치 시나리오를 문서화합니다. ipa-client-install 및 허용되는 옵션의 전체 목록을 사용하는 방법에 대한 자세한 내용은 ipa-client-install(1) 매뉴얼 페이지를 참조하십시오.

3.3.1. 클라이언트 대화형 설치

다음 절차에서는 필요한 경우 사용자에게 입력하라는 메시지를 표시하는 동안 클라이언트를 설치합니다. 사용자는 admin 사용자와 같은 도메인에 클라이언트를 등록할 수 있는 권한이 부여된 사용자의 자격 증명을 제공합니다.
  1. ipa-client-install 유틸리티를 실행합니다.
    다음 중 하나가 적용되는 경우 --enable-dns-updates 옵션을 추가하여 클라이언트 시스템의 IP 주소로 DNS 레코드를 업데이트합니다.
    • 클라이언트가 통합 DNS와 함께 설치되는 IdM 서버
    • 네트워크의 DNS 서버는 GSS-TSIG 프로토콜을 사용하여 DNS 항목 업데이트를 허용합니다.
    SSSD 캐시에 Kerberos 암호 저장을 비활성화하려면 --no-krb5-offline-passwords 옵션을 추가합니다.
  2. 설치 스크립트는 필요한 모든 설정을 자동으로 가져오려고 시도합니다.
    1. DNS 영역과 SRV 레코드가 시스템에 올바르게 설정된 경우 스크립트는 필요한 모든 값을 자동으로 검색하고 출력합니다. yes 를 입력하여 확인합니다.
      Client hostname: client.example.com
      Realm: EXAMPLE.COM
      DNS Domain: example.com
      IPA Server: server.example.com
      BaseDN: dc=example,dc=com
      
      Continue to configure the system with these values? [no]: yes
      다른 값으로 시스템을 설치하려면 현재 설치를 취소합니다. 그런 다음 ipa-client-install 을 다시 실행하고 명령줄 옵션을 사용하여 필요한 값을 지정합니다.
      자세한 내용은 ipa-client-install(1) 도움말 페이지의 DNS 자동 검색 섹션을 참조하십시오.
    2. 스크립트에서 일부 설정을 자동으로 가져오지 못하면 값을 묻는 메시지가 표시됩니다.
      중요
      단일 레이블 도메인 이름(예: .company)을 사용하지 마십시오. IdM 도메인은 하나 이상의 하위 도메인과 최상위 도메인(예: example.com 또는 company.example.com)으로 구성되어야 합니다.
      정규화된 도메인 이름은 다음 조건을 충족해야 합니다.
      • 유효한 DNS 이름이므로 숫자, 영문자 및 하이픈(-)만 사용할 수 있습니다. 밑줄(_)과 같은 기타 문자는 호스트 이름에서 DNS 오류가 발생합니다.
      • 이 모든 것이 더 낮은 사례입니다. 대문자는 허용되지 않습니다.
      • 정규화된 도메인 이름은 루프백 주소로 해석해서는 안 됩니다. 127.0.0.1 이 아닌 머신의 공용 IP 주소로 확인되어야 합니다.
      다른 권장 이름 지정 사례는 Red Hat Enterprise Linux 보안 가이드의 권장 이름 지정 사례를 참조하십시오.
  3. 이 스크립트에서는 클라이언트를 등록하는 데 ID를 사용할 사용자를 묻는 메시지를 표시합니다. 기본적으로 admin 사용자는 다음과 같습니다.
    User authorized to enroll computers: admin
    Password for admin@EXAMPLE.COM
  4. 이제 설치 스크립트에서 클라이언트를 구성합니다. 작업이 완료될 때까지 기다립니다.
    Client configuration complete.
  5. ipa-client-automount 유틸리티를 실행하여 IdM에 대해 NFS를 자동으로 구성합니다. 자세한 내용은 34.2.1절. “자동으로 NFS 설정” 을 참조하십시오.

3.3.2. 비대화형 클라이언트 설치

비대화형 설치의 경우 명령줄 옵션을 사용하여 ipa-client-install 유틸리티에 필요한 모든 정보를 제공합니다. 비대화식 설치에 필요한 최소 옵션은 다음과 같습니다.
  • 클라이언트 등록에 사용할 인증 정보를 지정하는 옵션은 3.3절. “클라이언트 설치” 을 참조하십시오. 자세한 내용은 을 참조하십시오.
  • 사용자 확인 없이 설치를 실행할 수 있도록 --u nattended
DNS 영역 및 SRV 레코드가 시스템에 올바르게 설정된 경우 스크립트에서 기타 필요한 모든 값을 자동으로 검색합니다. 스크립트에서 값을 자동으로 검색할 수 없는 경우 명령줄 옵션을 사용하여 제공합니다.
  • 클라이언트 머신의 정적 호스트 이름을 지정하는 --hostname
    중요
    단일 레이블 도메인 이름(예: .company)을 사용하지 마십시오. IdM 도메인은 하나 이상의 하위 도메인과 최상위 도메인(예: example.com 또는 company.example.com)으로 구성되어야 합니다.
    정규화된 도메인 이름은 다음 조건을 충족해야 합니다.
    • 유효한 DNS 이름이므로 숫자, 영문자 및 하이픈(-)만 사용할 수 있습니다. 밑줄(_)과 같은 기타 문자는 호스트 이름에서 DNS 오류가 발생합니다.
    • 이 모든 것이 더 낮은 사례입니다. 대문자는 허용되지 않습니다.
    • 정규화된 도메인 이름은 루프백 주소로 해석해서는 안 됩니다. 127.0.0.1 이 아닌 머신의 공용 IP 주소로 확인되어야 합니다.
    다른 권장 이름 지정 사례는 Red Hat Enterprise Linux 보안 가이드의 권장 이름 지정 사례를 참조하십시오.
  • 클라이언트가 등록할 IdM 서버의 호스트 이름을 지정하는 --server
  • 클라이언트가 등록할 IdM 서버의 DNS 도메인 이름을 지정하는 --domain
  • Kerberos 영역 이름을 지정하는 --realm
다음 중 하나가 적용되는 경우 --enable-dns-updates 옵션을 추가하여 클라이언트 시스템의 IP 주소로 DNS 레코드를 업데이트합니다.
  • 클라이언트가 통합 DNS와 함께 설치되는 IdM 서버
  • 네트워크의 DNS 서버는 GSS-TSIG 프로토콜을 사용하여 DNS 항목 업데이트를 허용합니다.
SSSD 캐시에 Kerberos 암호 저장을 비활성화하려면 --no-krb5-offline-passwords 옵션을 추가합니다.
ipa-client-install 에서 허용하는 전체 옵션 목록은 ipa-client-install(1) 매뉴얼 페이지를 참조하십시오.

예 3.1. 임의 암호를 사용하여 비대화형 클라이언트 설치

이 절차에서는 사용자에게 입력 메시지를 표시하지 않고 클라이언트를 설치합니다. 이 프로세스에는 등록을 승인하는 데 사용되는 서버에서 임의의 1회 암호를 미리 생성하는 작업이 포함됩니다.
  1. 기존 서버에서 다음을 수행합니다.
    1. 관리자로 로그인합니다.
      $ kinit admin
    2. 새 시스템을 IdM 호스트로 추가합니다. ipa host-add 명령과 함께 --random 옵션을 사용하여 임의의 암호를 생성합니다.
      $ ipa host-add client.example.com --random
      --------------------------------------------------
      Added host "client.example.com"
      --------------------------------------------------
        Host name: client.example.com
        Random password: W5YpARl=7M.n
        Password: True
        Keytab: False
        Managed by: server.example.com
      시스템을 IdM 도메인에 등록하는 데 사용한 후 생성된 암호가 유효하지 않습니다. 등록이 완료되면 적절한 호스트 키탭으로 바뀝니다.
  2. 클라이언트를 설치할 시스템에서 ipa-client-install 을 실행하고 다음 옵션을 사용합니다.
    • ipa host-add 출력에서 임의의 암호의 --password
      참고
      암호에는 종종 특수 문자가 포함되어 있습니다. 따라서 작은따옴표(')로 묶어야 합니다.
    • 사용자 확인 없이 설치를 실행할 수 있도록 --u nattended
    DNS 영역 및 SRV 레코드가 시스템에 올바르게 설정된 경우 스크립트에서 기타 필요한 모든 값을 자동으로 검색합니다. 스크립트에서 값을 자동으로 검색할 수 없는 경우 명령줄 옵션을 사용하여 제공합니다.
    예를 들어 다음과 같습니다.
    # ipa-client-install --password 'W5YpARl=7M.n' --domain example.com --server server.example.com --unattended
  3. ipa-client-automount 유틸리티를 실행하여 IdM에 대해 NFS를 자동으로 구성합니다. 자세한 내용은 34.2.1절. “자동으로 NFS 설정” 을 참조하십시오.

3.4. Kickstart를 통해 IdM 클라이언트 설정

Kickstart 등록은 Red Hat Enterprise Linux를 설치할 때 IdM 도메인에 새 시스템을 자동으로 추가합니다. Kickstart에 대한 자세한 내용은 설치 가이드의 Kickstart 설치를 참조하십시오.
Kickstart 클라이언트 설치 준비에는 다음 단계가 포함됩니다.

3.4.1. IdM 서버에서 클라이언트 호스트 항목 사전 작성

  1. admin으로 로그인합니다.
    $ kinit admin
  2. IdM 서버에 호스트 항목을 생성하고 항목의 임시 암호를 설정합니다.
    $ ipa host-add client.example.com --password=secret
    암호는 Kickstart에서 클라이언트 설치 중에 인증하는 데 사용되며 첫 번째 인증 시도 후 만료됩니다. 클라이언트가 성공적으로 설치되면 해당 키탭을 사용하여 인증됩니다.

3.4.2. 클라이언트에 대한 Kickstart 파일 만들기

IdM 클라이언트를 설정하는 데 사용되는 Kickstart 파일은 다음을 포함해야 합니다.
  • 설치할 패키지 목록의 ipa-client 패키지:
    %packages
    @ X Window System
    @ Desktop
    @ Sound and Video
    ipa-client
    ...
    자세한 내용은 설치 가이드 의 패키지 선택을 참조하십시오.
  • 설치 후 명령:
    • 등록하기 전에 SSH 키가 생성되었는지 확인합니다.
    • ipa-client-install 유틸리티를 실행하여 다음을 지정합니다.
      예를 들어 다음과 같습니다.
      %post --log=/root/ks-post.log
      
      # Generate SSH keys to ensure that ipa-client-install uploads them to the IdM server
      /usr/sbin/sshd-keygen
      
      # Run the client install script
      /usr/sbin/ipa-client-install --hostname=client.example.com --domain=EXAMPLE.COM --enable-dns-updates --mkhomedir -w secret --realm=EXAMPLE.COM --server=server.example.com
    비대화형 설치의 경우 --unattended 옵션도 추가합니다.
    클라이언트 설치 스크립트에서 머신 인증서를 요청하도록 하려면 다음을 수행합니다.
    • ipa-client-install--request-cert 옵션을 추가합니다.
    • kickstart chroot 환경에서 getcertipa-client-install 유틸리티의 시스템 버스 주소를 /dev/null 로 설정합니다. 이렇게 하려면 ipa-client-install 명령 앞에 설치 후 명령 파일에 다음 행을 추가합니다.
      # env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null getcert list
      # env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null ipa-client-install
    참고
    Kickstart를 등록하기 전에 sshd 서비스를 시작하지 않는 것이 좋습니다. 클라이언트를 등록하기 전에 sshd 를 시작하면 SSH 키가 자동으로 생성되는 반면 위의 스크립트를 사용하는 것이 좋습니다.
    자세한 내용은 설치 가이드의 설치 후 스크립트를 참조하십시오.
Kickstart 사용에 대한 자세한 내용은 설치 가이드에서 Kickstart 설치 방법을 참조하십시오 . Kickstart 파일의 예는 샘플 Kickstart 구성 을 참조하십시오.

3.5. 설치 후 고려 사항

3.5.1. 사전 ID 관리 구성 제거

ipa-client-install 스크립트는 이전 LDAP 및 SSSD 구성을 /etc/openldap/ldap.conf/etc/sssd/sssd.conf 파일에서 제거하지 않습니다. 클라이언트를 설치하기 전에 이러한 파일에서 구성을 수정한 경우 스크립트는 새 클라이언트 값을 추가하지만 주석 처리합니다. 예를 들어 다음과 같습니다.
BASE   dc=example,dc=com
URI    ldap://ldap.example.com

#URI ldaps://server.example.com # modified by IPA
#BASE dc=ipa,dc=example,dc=com # modified by IPA
새 ID 관리 구성 값을 적용하려면 다음을 수행합니다.
  1. /etc/openldap/ldap.conf/etc/sssd/sssd.conf 를 엽니다.
  2. 이전 구성을 삭제합니다.
  3. 새 ID 관리 구성의 주석 처리를 해제합니다.
  4. 변경 사항을 적용하려면 시스템 전체 LDAP 구성을 사용하는 서버 프로세스를 다시 시작해야 할 수 있습니다. openldap 라이브러리를 사용하는 애플리케이션은 일반적으로 시작될 때 구성을 가져옵니다.

3.6. 새 클라이언트 테스트

클라이언트가 서버에 정의된 사용자에 대한 정보를 얻을 수 있는지 확인합니다. 예를 들어 기본 admin 사용자를 확인하려면 다음을 실행합니다.
[user@client ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

3.7. 클라이언트 설치 제거

클라이언트를 설치 제거해도 IdM 도메인에서 클라이언트 및 시스템 서비스 IdM별 구성(예: SSSD)이 제거됩니다. 이렇게 하면 클라이언트 시스템의 이전 구성이 복원됩니다.
  1. ipa-client-install --uninstall 명령을 실행합니다.
    # ipa-client-install --uninstall
  2. 서버에서 클라이언트 호스트의 DNS 항목을 수동으로 제거합니다. 33.4.6절. “DNS 영역에서 레코드 삭제” 참조하십시오.

3.8. IdM 도메인에 클라이언트를 다시 등록

클라이언트 가상 머신이 삭제되고 여전히 키탭이 있는 경우 클라이언트를 다시 나열할 수 있습니다.
참고
도메인 항목이 아직 활성 상태인 클라이언트만 다시 등록할 수 있습니다. 클라이언트 설치 제거 ( ipa-client-install --uninstall) 또는 호스트 항목 ( ipa host-disable을 사용)을 비활성화한 경우 다시 등록할 수 없습니다.
다시 등록하는 동안 IdM은 다음을 수행합니다.
  • 원래 호스트 인증서 취소
  • 새 호스트 인증서 생성
  • 새 SSH 키 만들기
  • 새 키탭 생성

3.8.1. 관리자 계정을 사용하여 클라이언트 다시 등록

  1. 동일한 호스트 이름으로 클라이언트 시스템을 다시 생성합니다.
  2. 클라이언트 시스템에서 ipa-client-install --force-join 명령을 실행합니다.
    # ipa-client-install --force-join
  3. 이 스크립트에서는 클라이언트를 등록하는 데 ID를 사용할 사용자를 묻는 메시지를 표시합니다. 기본적으로 admin 사용자는 다음과 같습니다.
    User authorized to enroll computers: admin
    Password for admin@EXAMPLE.COM

3.8.2. 클라이언트 키탭을 사용하여 비대화식 클라이언트 다시 등록

클라이언트 키탭을 사용한 재등록은 자동 설치에 적합하거나 관리자 암호를 사용할 때 다른 경우에 적합하지 않습니다.
  1. 원래 클라이언트의 keytab 파일을 백업합니다(예: /tmp 또는 /root 디렉토리).
  2. 동일한 호스트 이름으로 클라이언트 시스템을 다시 생성합니다.
  3. 클라이언트를 다시 등록하고 --keytab 옵션을 사용하여 키탭 위치를 지정합니다.
    # ipa-client-install --keytab /tmp/krb5.keytab
    참고
    key tab 옵션에 지정된 키 탭은 등록을 시작하도록 인증할 때만 사용됩니다. IdM은 재등록 과정에서 클라이언트의 새 키탭을 생성합니다.

3.9. 클라이언트 시스템 이름 변경

이 섹션에서는 IdM 클라이언트의 이름을 변경하는 방법을 설명합니다. 프로세스에는 다음이 포함됩니다.
주의
클라이언트 이름 변경은 수동 절차입니다. 호스트 이름을 완전히 변경해야 하는 경우가 아니면 Red Hat은 사용하지 않는 것이 좋습니다.

현재 서비스 및 키탭 설정 확인

현재 클라이언트를 설치 제거하기 전에 클라이언트의 특정 설정을 기록해 둡니다. 새 호스트 이름으로 시스템을 다시 등록한 후 이 설정을 적용합니다.
  1. 시스템에서 실행 중인 서비스를 확인합니다.
    1. ipa service-find 명령을 사용하고 출력에서 인증서로 서비스를 식별합니다.
      $ ipa service-find client.example.com
    2. 또한 각 호스트에는 ipa service-find 출력에 표시되지 않는 기본 호스트 서비스가 있습니다. 호스트 주체라고도 하는 호스트 서비스의 서비스 주체는 host /client.example.com 입니다.
  2. 시스템이 속해 있는 모든 호스트 그룹을 식별합니다.
    # ipa hostgroup-find client.example.com
  3. ipa service-find client.example.com 에서 표시되는 모든 서비스 주체의 경우 client.example.com 에서 해당 키탭의 위치를 확인합니다.
    클라이언트 시스템의 각 서비스에는 service_name/hostname@REALM 형식의 Kerberos 사용자(예: ldap/client.example.com@EXAMPLE.COM )가 있습니다.

IdM 도메인에서 클라이언트 시스템 제거

  1. IdM 도메인에서 클라이언트 시스템을 등록 해제합니다. 3.7절. “클라이언트 설치 제거” 참조하십시오.
  2. /etc/krb5.keytab 이외의 식별된 각 키 탭에서 이전 주체를 제거합니다.
    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
    29.4절. “키 탭 제거” 참조하십시오.
  3. IdM 서버에서 호스트 항목을 제거합니다. 그러면 모든 서비스가 제거되고 해당 호스트에 대해 발행된 모든 인증서가 취소됩니다.
    [root@server ~]# ipa host-del client.example.com
이때 호스트는 IdM에서 완전히 제거됩니다.

새 호스트 이름으로 클라이언트 다시 등록

  1. 필요에 따라 머신의 이름을 변경합니다.
  2. 시스템을 IdM 클라이언트로 다시 등록하십시오. 3.8절. “IdM 도메인에 클라이언트를 다시 등록” 참조하십시오.
  3. IdM 서버에서 “현재 서비스 및 키탭 설정 확인” 로 식별되는 모든 서비스에 새 키탭을 추가합니다.
    [root@server ~]# ipa service-add service_name/new_host_name
  4. “현재 서비스 및 키탭 설정 확인” 에 할당된 인증서가 있는 서비스에 대한 인증서를 생성합니다. 다음을 수행할 수 있습니다.
  5. “현재 서비스 및 키탭 설정 확인” 에서 식별된 호스트 그룹에 클라이언트를 다시 추가합니다. 13.3절. “사용자 또는 호스트 그룹 멤버 추가 및 제거” 참조하십시오.

4장. ID 관리 복제본 설치 및 제거

복제본은 기존 ID 관리 서버의 구성을 복제하여 생성합니다. 따라서 서버와 복제본은 동일한 코어 구성을 공유합니다. 복제본 설치 프로세스는 기존 서버 구성을 복사하고 해당 구성을 기반으로 복제본을 설치합니다.
참고
복제본에서 IdM 배포를 다시 빌드할 때 주로 권장되는 또 다른 백업 솔루션은 9장. ID 관리 백업 및 복원 에 설명된 대로 ipa-backup 유틸리티입니다.

4.1. IdM 복제 설명

대량 클라이언트의 서비스 가용성 및 중복성을 제공하기 위해 단일 도메인에 복제 라는 여러 IdM 서버를 배포할 수 있습니다. 복제본은 기능적으로 동일한 초기 IdM 서버의 복제본입니다. 사용자, 시스템, 인증서 및 구성된 정책에 대한 동일한 내부 정보를 공유합니다.
그러나 환경의 한 서버만 충족할 수 있는 두 개의 고유한 서버 역할이 있습니다.
  • CA 갱신 서버: 이 서버는 CA(인증 기관) 하위 시스템 인증서 갱신을 관리합니다.
  • CRL Generation Server: 이 서버는 CRL(인증서 폐기 목록)을 생성합니다.
기본적으로 설치된 첫 번째 CA 서버는 CA 갱신 서버 및 CRL Generation Server 역할을 모두 수행합니다. 이러한 역할을 토폴로지의 다른 CA 서버로 전환할 수 있습니다(예: 처음 설치된 서버를 해제해야 하는 경우). 두 역할 모두 동일한 서버에서 수행할 필요가 없습니다.
참고
IdM 토폴로지의 시스템 유형에 대한 자세한 내용은 1.2절. “ID 관리 도메인” 을 참조하십시오.
복제 는 복제본 간에 데이터를 복사하는 프로세스입니다. 복제본 간 정보는 다중 마스터 복제를 사용하여 공유됩니다. 복제 계약을 통해 연결된 모든 복제본은 업데이트를 수신하므로 데이터 마스터로 간주됩니다.

그림 4.1. 서버 및 복제 계약

서버 및 복제 계약

4.2. 복제본에 대한 배포 고려 사항

4.2.1. 토폴로지에서 서버 서비스 배포

IdM 서버는 CA(인증 기관) 또는 DNS와 같은 다양한 서비스를 실행할 수 있습니다. 복제본은 에서 만든 서버와 동일한 서비스를 실행할 수 있지만 필수는 아닙니다.
예를 들어 초기 서버가 DNS를 실행하는 경우에도 DNS 서비스 없이 복제본을 설치할 수 있습니다. 마찬가지로 초기 서버가 DNS 없이 설치된 경우에도 복제본을 DNS 서버로 설정할 수 있습니다.

그림 4.2. 다른 서비스의 복제

다른 서비스의 복제

복제의 CA 서비스

CA 없이 복제본을 설정하면 인증서 작업에 대한 모든 요청을 토폴로지의 CA 서버로 전달합니다.
주의
두 개 이상의 서버에 CA 서비스를 설치하는 것이 좋습니다. CA 서비스를 포함한 초기 서버 복제 설치에 대한 자세한 내용은 4.5.4절. “CA를 사용하여 복제본 설치” 을 참조하십시오.
CA를 하나의 서버에만 설치하는 경우 CA 서버가 실패할 경우 복구 가능성 없이 CA 구성을 손실할 수 있습니다. 자세한 내용은 B.2.6절. “손실된 CA 서버 복구” 을 참조하십시오.
복제본에서 CA를 설정하는 경우 구성은 초기 서버의 CA 구성을 미러링해야 합니다.
  • 예를 들어 서버에 루트 CA로 통합된 IdM CA가 포함된 경우, 루트 CA로 통합 CA를 사용하여 복제본도 설치해야 합니다.
  • 지원되는 CA 구성 옵션은 2.3.2절. “사용할 CA 구성 결정” 를 참조하십시오.

4.2.2. 복제 토폴로지 권장 사항

Red Hat은 다음 지침을 준수할 것을 권장합니다.
단일 IdM 도메인에 60개 이상의 복제본을 구성
Red Hat은 60개 이하의 복제본이 포함된 환경 지원을 보장합니다.
각 복제본당 최소 2 개의 복제 계약 구성
추가 복제 계약을 구성하면 초기 복제본과 마스터 서버 간에뿐만 아니라 다른 복제본 간에도 정보가 복제됩니다.
  • 서버 A에서 복제본 B를 생성한 다음 서버 A에서 복제 C를 복제하는 경우 복제본 A와 C의 복제본은 직접 참여하지 않으므로 복제본 B의 데이터를 복제 C로 전파하기 전에 먼저 서버 A로 복제해야 합니다.

    그림 4.3. 복제 계약(복제 계약)에 참여하지 않는 복제 B 및 C 복제

    복제 계약(복제 계약)에 참여하지 않는 복제 B 및 C 복제
    복제본 B와 복제본 C 간에 추가 복제 연결을 설정하면 데이터가 직접 복제되므로 데이터 가용성, 일관성, 페일오버 허용 오차 및 성능이 향상됩니다.

    그림 4.4. 복제 계약(복제 계약)에 가입한 복제 B 및 C 복제

    복제 계약(복제 계약)에 가입한 복제 B 및 C 복제
    복제 계약 관리에 대한 자세한 내용은 6장. 복제 토폴로지 관리 을 참조하십시오.
복제본당 4개 이상의 복제 계약을 구성하는 것은 불필요합니다. 서버당 다수의 복제 계약에 따라 한 번에 한 명의 마스터만 업데이트할 수 있기 때문에 특정 소비자 서버는 한 번에 하나의 마스터만 업데이트할 수 있으므로 다른 계약에는 유휴 상태가 되고 대기 중입니다. 또한 복제 계약 수가 너무 많으면 전체 성능에 부정적인 영향을 미칠 수 있습니다.
참고
ipa topologysuffix-verify 명령은 토폴로지가 가장 중요한 권장 사항을 충족하는지 확인합니다. 자세한 내용은 ipa topologysuffix-verify --help 를 실행합니다.
명령을 사용하려면 토폴로지 접미사를 지정해야 합니다. 자세한 내용은 6.1절. “복제 계약, 토폴로지 번들 및 토폴로지 세그먼트 설명” 을 참조하십시오.

그림 4.5. 토폴로지 예

토폴로지 예

4.2.2.1. 끊김 토폴로지

가장 복원력이 높은 토폴로지 중 하나는 셀에서 적은 수의 서버를 사용하여 서버와 복제본에 대한 셀 구성을 만드는 것입니다.
  • 셀은 엄격한 셀로, 모든 서버는 서로 복제 계약을 맺고 있습니다.
  • 각 서버에는 셀 외부에 있는 다른 서버와 하나의 복제 연결이 있습니다. 이렇게 하면 모든 셀이 도메인의 다른 모든 셀에 느슨하게 연결됩니다.
탄탄한 셀 토폴로지를 수행하려면 다음을 수행합니다.
  • 각 주 사무소, 데이터 센터 또는 지역에 IdM 서버가 하나 이상 있어야 합니다. IdM 서버가 두 개 있는 것이 좋습니다.
  • 데이터 센터당 네 개 이상의 서버가 없습니다.
  • 소규모 사무소의 경우 복제본을 사용하는 대신 SSSD를 사용하여 자격 증명을 캐시하고 오프사이트 IdM 서버를 데이터 백엔드로 캐시합니다.

4.2.3. 숨겨진 복제 모드

기본적으로 새 복제본을 설정하면 설치 프로그램이 DNS에 서비스(SRV) 리소스 레코드를 자동으로 생성합니다. 이러한 레코드를 통해 클라이언트는 복제본 및 해당 서비스를 자동으로 검색할 수 있습니다. 숨겨진 복제본은 모든 서비스가 실행 중이고 사용 가능한 IdM 서버입니다. 그러나 DNS에는 SRV 레코드가 없으며 LDAP 서버 역할이 활성화되어 있지 않습니다. 따라서 클라이언트는 서비스 검색을 사용하여 이러한 숨겨진 복제본을 탐지할 수 없습니다.
참고
숨겨진 복제본 기능은 Red Hat Enterprise Linux 7.7 이상에서 기술 프리뷰로 제공되므로 지원되지 않습니다.
숨겨진 복제본은 주로 클라이언트를 중단할 수 있는 전용 서비스용으로 설계되었습니다. 예를 들어 IdM의 전체 백업은 마스터 또는 복제본에서 모든 IdM 서비스를 종료해야 합니다. 숨겨진 복제본을 사용하지 않으므로 관리자는 클라이언트에 영향을 주지 않고 이 호스트의 서비스를 일시적으로 종료할 수 있습니다. 기타 사용 사례에는 IdM API에 대한 고로드 작업 또는 LDAP 서버(예: 대량 가져오기 또는 광범위한 쿼리)가 포함됩니다.
복제본을 숨겨진 대로 설치하려면 --hidden-replica 매개변수를 ipa-replica-install 명령에 전달합니다. 복제본 설치에 대한 자세한 내용은 4.5절. “복제 생성: 소개” 을 참조하십시오.
또는 기존 복제본의 상태를 변경할 수 있습니다. 자세한 내용은 6.5.4절. “Hidden Replicas의 데모 및 프로모션” 의 내용을 참조하십시오.

4.3. 복제본 설치 사전 요구 사항

복제본에 대한 설치 요구 사항은 IdM 서버와 동일합니다. 복제 시스템이 2.1절. “서버 설치 사전 요구 사항” 에 나열된 모든 사전 요구 사항을 충족하는지 확인합니다.
일반 서버 요구 사항 외에도 다음 조건을 충족해야 합니다.
복제본은 동일한 또는 이후 버전의 IdM을 실행해야 합니다.
예를 들어 마스터 서버가 Red Hat Enterprise Linux 7에서 실행 중이고 IdM 4.4 패키지를 사용하는 경우 복제본도 Red Hat Enterprise Linux 7 이상에서 실행되고 IdM 버전 4.4 이상을 사용해야 합니다. 이렇게 하면 서버에서 복제본으로 구성이 올바르게 복사될 수 있습니다.
중요
IdM은 이전 버전의 마스터 복제본 생성을 지원하지 않습니다. 이전 버전을 사용하여 복제본을 생성하려고 하면 설치에 실패합니다.
복제본에 추가 포트가 열려 있어야 합니다.
2.1.6절. “포트 요구 사항” 에 설명된 표준 IdM 서버 포트 요구 사항 외에 다음 사항도 충족해야 합니다.
  • 도메인 수준 0에서 TCP 포트 22 를 복제 설정 프로세스 중 마스터 서버에 열린 상태로 유지합니다. SSH를 사용하여 마스터 서버에 연결하려면 이 포트가 필요합니다.
    참고
    도메인 수준에 대한 자세한 내용은 7장. 도메인 수준 표시 및 승격 을 참조하십시오.
  • 서버 중 하나가 Red Hat Enterprise Linux 6를 실행하고 CA가 설치되어 있는 경우 복제 구성 중과 후에 TCP 포트 7389 를 계속 엽니다. 순전히 Red Hat Enterprise Linux 7 환경에서는 포트 7389가 필요하지 않습니다.
firewall-cmd 유틸리티를 사용하여 포트를 여는 방법에 대한 자세한 내용은 2.1.6절. “포트 요구 사항” 을 참조하십시오.

4.4. 복제 설치에 필요한 패키지

복제 패키지 요구 사항은 서버 패키지 요구 사항과 동일합니다. 2.2절. “IdM 서버 설치에 필요한 패키지” 참조하십시오.

4.5. 복제 생성: 소개

ipa-replica-install 유틸리티는 기존 IdM 서버에서 새 복제본을 설치하는 데 사용됩니다. Identity Management 복제본을 한 번에 하나씩 설치합니다. 동시에 여러 복제본의 설치는 지원되지 않습니다.
참고
이 장에서는 Red Hat Enterprise Linux 7.3에 도입된 단순화된 복제 설치에 대해 설명합니다. 절차에는 도메인 수준 1이 필요합니다( 7장. 도메인 수준 표시 및 승격참조).
도메인 수준 0에 복제본을 설치하는 방법에 대한 문서는 ??? 를 참조하십시오.
새 복제본을 설치할 수 있습니다.
이러한 두 경우 모두 ipa-replica-install 에 옵션을 추가하여 복제본을 사용자 지정할 수 있습니다. “ipa-replica-install을 사용하여 사용 사례에 맞게 복제 구성” 을 참조하십시오.
복제본을 숨겨진 대로 설치하려면 --hidden-replica 매개 변수를 ipa-replica-install 에 전달합니다. 숨겨진 복제본에 대한 자세한 내용은 4.2.3절. “숨겨진 복제 모드” 을 참조하십시오.
중요
복제 중인 IdM 서버가 Active Directory에 대한 신뢰가 있는 경우 ipa-replica-install 을 실행한 후 복제본을 신뢰 에이전트로 설정합니다. Windows 통합 가이드에서 신뢰 컨트롤러 및 신뢰 에이전트 를 참조하십시오.

복제본으로 기존 클라이언트 승격

기존 클라이언트에 복제본을 설치하려면 클라이언트가 승격할 권한이 있는지 확인해야 합니다. 이를 수행하려면 다음 중 하나를 선택하십시오.
권한 있는 사용자의 자격 증명 제공
기본 권한 있는 사용자는 admin 입니다. 사용자의 자격 증명을 제공하는 방법에는 여러 가지가 있습니다. 다음을 수행할 수 있습니다.
  • IdM에 자격 증명을 대화형으로 가져오도록 요청합니다.
    참고
    이는 권한 있는 사용자의 자격 증명을 제공하는 기본 방법입니다. ipa-replica-install 을 실행할 때 자격 증명을 사용할 수 없는 경우 설치에 자동으로 메시지가 표시됩니다.
  • 클라이언트에서 ipa-replica-install 을 실행하기 전에 사용자로 로그인합니다.
    $ kinit admin
  • 사용자의 주체 이름과 암호를 ipa-replica-install 에 직접 추가합니다.
    # ipa-replica-install --principal admin --admin-password admin_password
ipaservers 호스트 그룹에 클라이언트 추가
ipaservers 의 멤버십은 시스템에 권한 있는 사용자 자격 증명과 유사한 권한을 부여합니다. 사용자의 자격 증명을 제공할 필요가 없습니다.

클라이언트가 아닌 시스템에 복제 설치

IdM 도메인에 아직 등록되지 않은 시스템에서 실행하는 경우 ipa-replica-install 은 먼저 시스템을 클라이언트로 등록한 다음 복제본 구성 요소를 설치합니다.
이 상황에서 복제본을 설치하려면 다음 중 하나를 선택합니다.
권한 있는 사용자의 자격 증명 제공
기본 권한 있는 사용자는 admin 입니다. 인증 정보를 제공하려면 주 이름과 암호를 ipa-replica-install 에 직접 추가합니다.
# ipa-replica-install --principal admin --admin-password admin_password
클라이언트에 임의의 암호를 제공
복제본을 설치하기 전에 서버에서 임의의 암호를 생성해야 합니다. 설치하는 동안 사용자의 자격 증명을 제공하지 않아도 됩니다.
기본적으로 복제본은 클라이언트 설치 프로그램에서 검색한 첫 번째 IdM 서버에 대해 설치됩니다. 특정 서버에 대해 복제본을 설치하려면 ipa-replica-install 에 다음 옵션을 추가합니다.
  • 서버의 정규화된 도메인 이름(FQDN)에 대한 --server
  • IdM DNS 도메인의 --domain

ipa-replica-install을 사용하여 사용 사례에 맞게 복제 구성

옵션 없이 실행하는 경우 ipa-replica-install 은 기본 서버 서비스만 설정합니다. DNS 또는 CA(인증 기관)와 같은 추가 서비스를 설치하려면 ipa-replica-install 에 옵션을 추가합니다.
주의
두 개 이상의 서버에 CA 서비스를 설치하는 것이 좋습니다. CA 서비스를 포함한 초기 서버 복제 설치에 대한 자세한 내용은 4.5.4절. “CA를 사용하여 복제본 설치” 을 참조하십시오.
CA를 하나의 서버에만 설치하는 경우 CA 서버가 실패할 경우 복구 가능성 없이 CA 구성을 손실할 수 있습니다. 자세한 내용은 B.2.6절. “손실된 CA 서버 복구” 을 참조하십시오.
주요 옵션을 사용하여 복제본을 설치하는 시나리오의 예는 다음을 참조하십시오.
사용자 지정 값으로 LDIF 파일의 경로를 지정하여 --dirsrv-config-file 매개변수를 사용하여 기본 Directory Server 설정을 변경할 수도 있습니다. 자세한 내용은 Red Hat Enterprise Linux 7.3 릴리스 노트에서 서버 또는 복제본 설치 중에 개별 디렉터리 서버 옵션 설정을 지원하는 IdM 을 참조하십시오.
복제본을 구성하는 데 사용되는 옵션의 전체 목록은 ipa-replica-install(1) 도움말 페이지를 참조하십시오.

4.5.1. 호스트 키 탭을 사용하여 클라이언트 승격

이 프로세스에서 기존 IdM 클라이언트는 고유한 호스트 키탭을 사용하여 승격을 승인하도록 복제로 승격됩니다.
이 절차에서는 관리자 또는 DM(Directory Manager) 자격 증명을 제공하지 않아도 됩니다. 따라서 중요한 정보가 명령줄에 노출되지 않으므로 더 안전합니다.
  1. 기존 서버에서 다음을 수행합니다.
    1. 관리자로 로그인합니다.
      $ kinit admin
    2. ipaservers 호스트 그룹에 클라이언트 시스템을 추가합니다.
      $ ipa hostgroup-add-member ipaservers --hosts client.example.com
        Host-group: ipaservers
        Description: IPA server hosts
        Member hosts: server.example.com, client.example.com
      -------------------------
      Number of members added 1
      -------------------------
      ipaservers 의 멤버십은 관리자의 자격 증명과 유사한 권한을 시스템에 부여합니다.
  2. 클라이언트에서 ipa-replica-install 유틸리티를 실행합니다.
    # ipa-replica-install
  3. 복제 중인 IdM 서버에 Active Directory 신뢰가 있는 경우 선택적으로 복제본을 신뢰 에이전트 또는 신뢰 컨트롤러로 설정합니다. 자세한 내용은 Windows 통합 가이드 의 신뢰 컨트롤러 및 신뢰 에이전트 를 참조하십시오.

4.5.2. 임의 암호를 사용하여 복제본 설치

이 절차에서는 IdM 클라이언트가 아닌 시스템에 처음부터 복제본이 설치됩니다. 등록을 승인하기 위해 하나의 클라이언트 등록에만 유효한 클라이언트별 임의 암호를 사용합니다.
이 절차에서는 관리자 또는 DM(Directory Manager) 자격 증명을 제공하지 않아도 됩니다. 따라서 중요한 정보가 명령줄에 노출되지 않으므로 더 안전합니다.
  1. 기존 서버에서 다음을 수행합니다.
    1. 관리자로 로그인합니다.
      $ kinit admin
    2. 새 시스템을 IdM 호스트로 추가합니다. ipa host-add 명령과 함께 --random 옵션을 사용하여 복제본 설치에 사용할 임의의 일회성 암호를 생성합니다.
      $ ipa host-add client.example.com --random
      --------------------------------------------------
      Added host "client.example.com"
      --------------------------------------------------
        Host name: client.example.com
        Random password: W5YpARl=7M.n
        Password: True
        Keytab: False
        Managed by: server.example.com
      시스템을 IdM 도메인에 등록하는 데 사용한 후 생성된 암호가 유효하지 않습니다. 등록이 완료되면 적절한 호스트 키탭으로 바뀝니다.
    3. ipaservers 호스트 그룹에 시스템을 추가합니다.
      $ ipa hostgroup-add-member ipaservers --hosts client.example.com
        Host-group: ipaservers
        Description: IPA server hosts
        Member hosts: server.example.com, client.example.com
      -------------------------
      Number of members added 1
      -------------------------
      ipaservers 의 멤버십은 필요한 서버 서비스를 설정하는 데 필요한 시스템에 높은 권한을 부여합니다.
  2. 복제본을 설치할 시스템에서 ipa-replica-install 을 실행하고 --password 옵션을 사용하여 임의의 암호를 제공합니다. 종종 특수 문자가 포함되어 있으므로 암호를 작은따옴표(')로 묶습니다.
    # ipa-replica-install --password 'W5YpARl=7M.n'
  3. 복제 중인 IdM 서버에 Active Directory 신뢰가 있는 경우 선택적으로 복제본을 신뢰 에이전트 또는 신뢰 컨트롤러로 설정합니다. 자세한 내용은 Windows 통합 가이드 의 신뢰 컨트롤러 및 신뢰 에이전트 를 참조하십시오.

4.5.3. DNS를 사용하여 복제본 설치

이 절차는 아직 IdM 도메인에 포함되지 않은 시스템과 클라이언트에 복제본을 설치하는 데 효과적입니다. 자세한 내용은 4.5절. “복제 생성: 소개” 을 참조하십시오.
  1. 다음 옵션을 사용하여 ipa-replica-install 을 실행합니다.
    • DNS 영역이 없는 경우 --setup-dns 를 사용하여 DNS 영역을 생성하고 복제를 DNS 서버로 구성합니다.
    • 전달자 사용하지 않으려면 전달자를 지정하거나 --no-forwarder 를 지정합니다.
      페일오버를 위해 여러 전달자를 지정하려면 --forwarder 를 여러 번 사용합니다.
    예를 들어 다음과 같습니다.
    # ipa-replica-install --setup-dns --forwarder 192.0.2.1
    참고
    ipa-replica-install 유틸리티는 --no-reverse 또는 --no-host-dns 와 같은 여러 DNS 설정과 관련된 여러 옵션을 허용합니다. 이에 대한 자세한 내용은 ipa-replica-install(1) 매뉴얼 페이지를 참조하십시오.
  2. DNS가 활성화된 초기 서버를 사용하여 만든 경우 올바른 DNS 항목을 사용하여 복제본이 자동으로 생성됩니다. 항목을 통해 IdM 클라이언트에서 새 서버를 검색할 수 있습니다.
    초기 서버에 DNS를 활성화하지 않은 경우 DNS 레코드를 수동으로 추가합니다. 다음 DNS 레코드는 도메인 서비스에 필요합니다.
    • _ldap._tcp
    • _kerberos._tcp
    • _kerberos._udp
    • _kerberos-master._tcp
    • _kerberos-master._udp
    • _ntp._udp
    • _kpasswd._tcp
    • _kpasswd._udp
    이 예제에서는 항목이 있는지 확인하는 방법을 보여줍니다.
    1. DOMAIN 및 NAMESERVER 변수에 적절한 값을 설정합니다.
      # DOMAIN=example.com
      # NAMESERVER=replica
    2. 다음 명령을 사용하여 DNS 항목을 확인합니다.
      # for i in _ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp ; do
      dig @${NAMESERVER} ${i}.${DOMAIN} srv +nocmd +noquestion +nocomments +nostats +noaa +noadditional +noauthority
      done | egrep "^_"
      
      _ldap._tcp.example.com. 86400     IN    SRV     0 100 389 server1.example.com.
      _ldap._tcp.example.com. 86400     IN    SRV     0 100 389 server2.example.com.
      _kerberos._tcp.example.com. 86400 IN    SRV     0 100 88  server1.example.com.
      ...
  3. 상위 도메인에서 IdM DNS 도메인에 DNS 위임을 추가합니다. 예를 들어 IdM DNS 도메인이 ipa.example.com 인 경우 example.com 상위 도메인에 이름 서버(NS) 레코드를 추가합니다.
    중요
    IdM DNS 서버가 설치될 때마다 이 단계를 반복해야 합니다.
  4. 선택 사항이지만 권장 사항입니다. 복제본을 사용할 수 없는 경우 수동으로 다른 DNS 서버를 백업 서버로 추가합니다. 33.11.1절. “추가 이름 서버 설정” 참조하십시오. 이 방법은 새 복제본이 IdM 도메인의 첫 번째 DNS 서버인 경우 특히 권장됩니다.
  5. 복제 중인 IdM 서버에 Active Directory 신뢰가 있는 경우 선택적으로 복제본을 신뢰 에이전트 또는 신뢰 컨트롤러로 설정합니다. 자세한 내용은 Windows 통합 가이드 의 신뢰 컨트롤러 및 신뢰 에이전트 를 참조하십시오.

4.5.4. CA를 사용하여 복제본 설치

이 절차는 아직 IdM 도메인에 포함되지 않은 시스템과 클라이언트에 복제본을 설치하는 데 효과적입니다. 자세한 내용은 4.5절. “복제 생성: 소개” 을 참조하십시오.
  1. --setup-ca 옵션을 사용하여 ipa-replica-install 을 실행합니다.
    [root@replica ~]# ipa-replica-install --setup-ca
  2. setup -ca 옵션은 서버의 IdM CA가 루트 CA인지 아니면 외부 CA로 종속되었는지 여부에 관계없이 초기 서버의 구성에서 CA 구성을 복사합니다.
    참고
    지원되는 CA 구성에 대한 자세한 내용은 2.3.2절. “사용할 CA 구성 결정” 을 참조하십시오.
  3. 복제 중인 IdM 서버에 Active Directory 신뢰가 있는 경우 선택적으로 복제본을 신뢰 에이전트 또는 신뢰 컨트롤러로 설정합니다. 자세한 내용은 Windows 통합 가이드 의 신뢰 컨트롤러 및 신뢰 에이전트 를 참조하십시오.

4.5.5. CA 없이 서버에서 복제본 설치

이 절차는 아직 IdM 도메인에 포함되지 않은 시스템과 클라이언트에 복제본을 설치하는 데 효과적입니다. 자세한 내용은 4.5절. “복제 생성: 소개” 을 참조하십시오.
중요
자체 서명된 타사 서버 인증서를 사용하여 서버 또는 복제본을 설치할 수 없습니다.
  1. ipa-replica-install 을 실행하고 다음 옵션을 추가하여 필요한 인증서 파일을 제공합니다.
    • --dirsrv-cert-file
    • --dirsrv-pin
    • --http-cert-file
    • --http-pin
    이러한 옵션을 사용하여 제공되는 파일에 대한 자세한 내용은 2.3.6절. “CA 없는 상태에서 설치” 을 참조하십시오.
    예를 들어 다음과 같습니다.
    [root@replica ~]# ipa-replica-install \
        --dirsrv-cert-file /tmp/server.crt \
        --dirsrv-cert-file /tmp/server.key \
        --dirsrv-pin secret \
        --http-cert-file /tmp/server.crt \
        --http-cert-file /tmp/server.key \
        --http-pin secret
    참고
    ca -cert-file 옵션을 추가하지 마십시오. ipa-replica-install 유틸리티는 마스터 서버에서 인증서 정보의 이 부분을 자동으로 가져옵니다.
  2. 복제 중인 IdM 서버에 Active Directory 신뢰가 있는 경우 선택적으로 복제본을 신뢰 에이전트 또는 신뢰 컨트롤러로 설정합니다. 자세한 내용은 Windows 통합 가이드 의 신뢰 컨트롤러 및 신뢰 에이전트 를 참조하십시오.

4.6. 새 복제 테스트

복제본을 생성한 후 복제가 예상대로 작동하는지 확인하려면 다음을 수행하십시오.
  1. 서버 중 하나에서 사용자를 생성합니다.
    [admin@server1 ~]$ ipa user-add test_user --first=Test --last=User
  2. 사용자가 다른 서버에 표시되는지 확인합니다.
    [admin@server2 ~]$ ipa user-show test_user

4.7. 복제 설치 제거

III 부. 관리: 서버 관리

이 부분에서는 Identity Management 도메인의 서버 및 서버 간 복제 관리와 같은 관리 관련 주제를 다룹니다. Identity Management 토폴로지에 대한 세부 정보를 제공하며 시스템의 Identity Management 패키지를 업데이트하는 방법에 대한 지침을 제공합니다. 또한 이 부분에서는 Identity Management 배포에 영향을 미치는 재해가 발생할 경우 ID 관리 시스템을 수동으로 백업 및 복원하는 방법을 설명합니다. 마지막 장은 다양한 내부 액세스 제어 메커니즘에 대해 자세히 설명합니다.

5장. IdM 서버 및 서비스 관리의 기본 사항

이 장에서는 IdM 서버 및 서비스를 관리하는 데 사용할 수 있는 ID 관리 명령줄 및 UI 툴에 대해 설명합니다. 여기에는 IdM 인증 방법이 포함됩니다.

5.1. IdM 서버 시작 및 중지

Directory Server, CA(인증 기관), DNS, Kerberos 등을 비롯한 IdM 서버와 함께 다양한 서비스가 설치됩니다. ipactl 유틸리티를 사용하여 설치된 모든 서비스와 함께 전체 IdM 서버를 중지, 시작 또는 다시 시작합니다.
전체 IdM 서버를 시작하려면 다음을 수행합니다.
# ipactl start
전체 IdM 서버를 중지하려면 다음을 수행합니다.
# ipactl stop
전체 IdM 서버를 다시 시작하려면 다음을 수행합니다.
# ipactl restart
개별 서비스만 중지, 시작 또는 다시 시작하려면 시스템 관리자 가이드에 설명된 systemctl 유틸리티를 사용합니다. 예를 들어 systemctl 을 사용하여 개별 서비스를 관리하는 것은 Directory Server 동작을 사용자 정의할 때 유용합니다. 구성 변경에는 Directory Server 인스턴스를 다시 시작해야 하지만 모든 IdM 서비스를 다시 시작할 필요는 없습니다.
중요
여러 IdM 도메인 서비스를 다시 시작하려면 항상 ipactl 를 사용할 것을 권장합니다. IdM 서버와 함께 설치된 서비스 간 종속성 때문에 해당 서비스가 시작되고 중지된 순서가 중요합니다. ipactl 유틸리티를 사용하면 서비스가 적절한 순서로 시작되고 중지됩니다.

5.2. Kerberos를 사용하여 IdM에 로그인

IdM은 Kerberos 프로토콜을 사용하여 SSO(Single Sign-On)를 지원합니다. Kerberos를 사용하면 사용자가 올바른 사용자 이름과 암호만 제공하면 되며 시스템에서 자격 증명을 다시 요청하지 않고 IdM 서비스에 액세스할 수 있습니다.
기본적으로 IdM 도메인의 멤버인 시스템만 Kerberos를 사용하여 IdM에 인증할 수 있습니다. 그러나 Kerberos 인증을 위해 외부 시스템을 구성할 수도 있습니다. 자세한 내용은 5.4.4절. “웹 UI로 Kerberos 인증을 위한 외부 시스템 구성” 을 참조하십시오.

kinit사용

명령줄에서 IdM에 로그인하려면 kinit 유틸리티를 사용합니다.
참고
kinit 를 사용하려면>- <5-workstation 패키지가 설치되어 있어야 합니다.
사용자 이름을 지정하지 않고 실행하면 kinit 가 로컬 시스템에 현재 로그인한 사용자의 사용자 이름으로 IdM에 로그인합니다. 예를 들어 로컬 시스템에서 local_user 로 로그인한 경우 kinit 를 실행하면 local_user IdM 사용자로 인증합니다.
[local_user@server ~]$ kinit
Password for local_user@EXAMPLE.COM:
참고
로컬 사용자의 사용자 이름이 IdM의 사용자 항목과 일치하지 않으면 인증 시도가 실패합니다.
다른 IdM 사용자로 로그인하려면 필요한 사용자 이름을 매개 변수로 kinit 유틸리티에 전달합니다. 예를 들어 admin 사용자로 로그인하려면 다음을 수행합니다.
[local_user@server ~]$ kinit admin
Password for admin@EXAMPLE.COM:

자동으로 Kerberos 티켓 얻기

IdM 클라이언트 시스템의 데스크탑 환경에 성공적으로 로그인한 후 PAM(pluggable authentication module) 및 SSSD는 사용자의 TGT를 자동으로 가져오도록 구성할 수 있습니다. 이렇게 하면 로그인 후 사용자가 kinit 를 실행할 필요가 없습니다.
SSSD에 ID 및 인증 공급자로 IdM이 구성된 IdM 시스템에서는 사용자가 해당 Kerberos 주체 이름으로 로그인한 후 SSSD가 TGT를 자동으로 가져옵니다.
iPXE _krb5 구성에 대한 자세한 내용은 pam_krb5(8) 매뉴얼 페이지를 참조하십시오. PAM에 대한 일반 정보는 시스템 수준 인증 가이드 를 참조하십시오.

여러 Kerberos 티켓 저장

기본적으로 Kerberos는 로그인된 사용자당 하나의 티켓만 인증 정보 캐시에 저장합니다. 사용자가 kinit 를 실행할 때마다 Kerberos는 현재 저장된 티켓을 새 티켓으로 덮어씁니다. 예를 들어 kinit 를 사용하여 user_A 로 인증하는 경우, user_B 로 다시 인증한 후 user_A 의 티켓이 손실됩니다.
사용자에 대한 다른 TGT를 가져와 저장하려면 이전 캐시의 콘텐츠를 덮어쓰지 않도록 다른 자격 증명 캐시를 설정합니다. 다음 두 가지 방법 중 하나로 이 작업을 수행할 수 있습니다.
  • 내보내기 KRB5CCNAME=path_to_different_cache 명령을 실행한 다음 kinit 를 사용하여 티켓을 가져옵니다.
  • kinit -c path_to_different_cache 명령을 실행한 다음 KRB5CCNAME 변수를 재설정합니다.
기본 인증 정보 캐시에 저장된 원래 TGT를 복원하려면 다음을 수행합니다.
  1. kdestroy 명령을 실행합니다.
  2. unset $KRB5CCNAME 명령을 사용하여 기본 인증 정보 캐시 위치를 복원합니다.

현재 로그인 사용자 확인 중

현재 저장 및 인증에 사용되는 TGT를 확인하려면 klist 유틸리티를 사용하여 캐시된 티켓을 나열합니다. 다음 예에서 캐시에는 user_A 의 티켓이 포함되어 있습니다. 즉, 현재 user_A 만 IdM 서비스에 액세스할 수 있습니다.
$ klist
Ticket cache: KEYRING:persistent:0:0
Default principal: user_A@EXAMPLE.COM

Valid starting     	Expires            	Service principal
11/10/2015 08:35:45  	11/10/2015 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

5.3. IdM 명령줄 유틸리티

IdM의 기본 명령줄 스크립트는 ipa 라고 합니다. ipa 스크립트는 여러 하위 명령을 위한 상위 스크립트입니다. 그런 다음 이러한 하위 명령을 사용하여 IdM을 관리합니다. 예를 들어 ipa user-add 명령은 새 사용자를 추가합니다.
$ ipa user-add user_name
명령줄 관리는 UI의 관리에 비해 특정 이점이 있습니다. 예를 들어 명령줄 유틸리티를 사용하면 수동 조작 없이 일관된 방식으로 관리 작업을 자동화하고 수행할 수 있습니다. 또한 대부분의 관리 작업은 명령줄과 웹 UI에서 모두 사용할 수 있지만 일부 작업은 명령줄에서만 수행할 수 있습니다.
참고
이 섹션은 ipa 하위 명령에 대한 일반적인 개요만 제공합니다. 자세한 내용은 IdM 관리 특정 영역을 전담하는 다른 섹션에서 확인할 수 있습니다. 예를 들어 ipa 하위 명령을 사용하여 사용자 항목을 관리하는 방법에 대한 자세한 내용은 11장. 사용자 계정 관리 을 참조하십시오.

5.3.1. ipa 명령에 대한 도움말 가져오기

ipa 스크립트는 특정 하위 명령 집합: 주제 와 관련된 도움말을 표시할 수 있습니다. 사용 가능한 주제 목록을 표시하려면 ipa help topics 명령을 사용합니다.
$ ipa help topics

automember         Auto Membership Rule.
automount          Automount
caacl              Manage CA ACL rules.
...
특정 항목에 대한 도움말을 표시하려면 ipa help topic_name 명령을 사용합니다. 예를 들어, automember 항목에 대한 정보를 표시하려면 다음을 수행합니다.
$ ipa help automember

Auto Membership Rule.

Bring clarity to the membership of hosts and users by configuring inclusive
or exclusive regex patterns, you can automatically assign a new entries into
a group or hostgroup based upon attribute information.

...

EXAMPLES:

 Add the initial group or hostgroup:
   ipa hostgroup-add --desc="Web Servers" webservers
   ipa group-add --desc="Developers" devel
...
ipa 스크립트는 사용 가능한 ipa 명령 목록을 표시할 수도 있습니다. 이 작업을 수행하려면 ipa help 명령을 사용하십시오.
$ ipa help commands
automember-add                         Add an automember rule.
automember-add-condition               Add conditions to an automember rule.
...
개별 ipa 명령에 대한 자세한 도움말을 보려면 명령에 --help 옵션을 추가합니다. 예를 들어 다음과 같습니다.
$ ipa automember-add --help

Usage: ipa [global-options] automember-add AUTOMEMBER-RULE [options]

Add an automember rule.
Options:
  -h, --help            show this help message and exit
  --desc=STR            A description of this auto member rule
...
ipa 유틸리티에 대한 자세한 내용은 ipa(1) 도움말 페이지를 참조하십시오.

5.3.2. 값 목록 설정

IdM은 항목 속성을 목록에 저장합니다. 예를 들어 다음과 같습니다.
ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
속성 목록을 업데이트할 때마다 이전 목록을 덮어씁니다. 예를 들어 이 특성만 지정하여 단일 특성을 추가하려는 시도는 이전에 정의한 전체 목록을 단일 새 속성으로 대체합니다. 따라서 속성 목록을 변경할 때 전체 업데이트 목록을 지정해야 합니다.
IdM은 다음과 같은 속성 목록을 제공하는 방법을 지원합니다.
  • 동일한 명령 호출 내에서 동일한 명령줄 인수를 여러 번 사용합니다. 예를 들어 다음과 같습니다.
    $ ipa permission-add --permissions=read --permissions=write --permissions=delete
  • 목록을 중괄호로 묶어 쉘에서 확장을 수행할 수 있습니다. 예를 들어 다음과 같습니다.
    $ ipa permission-add --permissions={read,write,delete}

5.3.3. 특수 문자 사용

대각 대괄호(< 및 >), plusersand(&), 별표(*) 또는 수직 표시줄(|)과 같은 특수 문자가 포함된 ipa 명령에서 명령줄 인수를 전달할 때 백슬래시(\)를 사용하여 이러한 문자를 이스케이프해야 합니다. 예를 들어 별표(*)를 이스케이프하려면 다음을 수행합니다.
$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg
이스케이프 처리되지 않은 특수 문자가 포함된 명령은 쉘에서 이러한 문자를 올바르게 구문 분석할 수 없기 때문에 예상대로 작동하지 않습니다.

5.3.4. IdM 항목 검색

IdM 항목 나열

ipa *-find 명령을 사용하여 특정 유형의 IdM 항목을 검색합니다. 예를 들어 다음과 같습니다.
  • 모든 사용자를 나열하려면 다음을 수행하십시오.
    $ ipa user-find
    ---------------
    4 users matched
    ---------------
      ...
  • 지정된 속성에 키워드가 포함된 사용자 그룹을 나열하려면 다음을 수행합니다.
    $ ipa group-find keyword
    ----------------
    2 groups matched
    ----------------
      ...
    사용자 및 사용자 그룹에 대한 IdM 검색 속성을 구성하려면 13.5절. “사용자 및 사용자 그룹에 대한 검색 속성 설정” 을 참조하십시오.
사용자 그룹을 검색할 때 검색 결과를 특정 사용자를 포함하는 그룹으로 제한할 수도 있습니다.
$ ipa group-find --user=user_name
특정 사용자가 포함되지 않은 그룹을 검색할 수도 있습니다.
$ ipa group-find --no-user=user_name

Particular Entry에 대한 세부 정보 표시

ipa *-show 명령을 사용하여 특정 IdM 항목에 대한 세부 정보를 표시합니다. 예를 들어 다음과 같습니다.
$ ipa host-show server.example.com
 Host name: server.example.com
 Principal name: host/server.example.com@EXAMPLE.COM
 ...

5.3.4.1. 검색 크기 및 시간 제한 조정

사용자 목록을 보는 등의 일부 검색 결과는 매우 많은 항목을 반환할 수 있습니다. 이러한 검색 작업을 조정하여 ipa *-find 명령을 실행할 때 ipa user-find 명령을 실행하고 웹 UI에 해당 목록을 표시할 때 전체 서버 성능을 향상시킬 수 있습니다.
검색 크기 제한:
  • 클라이언트, IdM 명령줄 툴 또는 IdM 웹 UI에서 서버로 전송된 요청에 대해 반환된 최대 항목 수를 정의합니다.
  • 기본값: 100개 항목.
검색 시간 제한:
  • 서버가 검색 실행을 기다리는 최대 시간을 정의합니다. 검색이 이 제한에 도달하면 서버에서 검색을 중지하고 해당 시점에서 검색한 항목을 반환합니다.
  • 기본값: 2초.
값을 -1 로 설정하면 IdM이 검색할 때 제한을 적용하지 않습니다.
중요
검색 크기 또는 시간 제한을 너무 높게 설정하면 서버 성능에 부정적인 영향을 줄 수 있습니다.

웹 UI: 검색 크기 및 시간 제한 조정

모든 쿼리에 대해 제한을 전역적으로 조정하려면 다음을 수행합니다.
  1. IPA 서버 구성을선택합니다.
  2. Search Options (검색 옵션) 영역에서 필요한 값을 설정합니다.
  3. 페이지 상단에서 저장 을 클릭합니다.

명령줄: 검색 크기 및 시간 제한 조정

모든 쿼리에 대해 전역적으로 제한을 조정하려면 ipa config-mod 명령을 사용하고 --search recordsslimit--searchtimelimit 옵션을 추가합니다. 예를 들어 다음과 같습니다.
$ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
명령줄에서 특정 쿼리의 제한만 조정할 수도 있습니다. 이렇게 하려면 명령에 --sizelimit 또는 --timelimit 옵션을 추가합니다. 예를 들어 다음과 같습니다.
$ ipa user-find --sizelimit=200 --timelimit=120
중요
search records slimit 또는 --searchtimelimit 옵션과 함께 ipa config-mod 명령을 사용하여 크기 또는 시간 제한을 조정하면 ipa user-find 와 같은 ipa명령에서 반환한 항목 수에 영향을 미칩니다.
이러한 제한 외에도 Directory Server 수준에서 구성된 설정도 고려되며 더 엄격한 제한을 적용할 수 있습니다. Directory Server 제한에 대한 자세한 내용은 Red Hat Directory Server 관리 가이드를 참조하십시오.

5.4. IdM 웹 UI

ID 관리 웹 UI는 IdM 관리를 위한 웹 애플리케이션입니다. ipa 명령줄 유틸리티의 대부분의 기능이 있습니다. 따라서 사용자는 UI 또는 명령줄에서 IdM을 관리할지 여부를 선택할 수 있습니다.
참고
로그인한 사용자가 사용할 수 있는 관리 작업은 사용자의 액세스 권한에 따라 달라집니다. 관리자 및 관리 권한이 있는 다른 사용자에게는 모든 관리 작업을 사용할 수 있습니다. 일반 사용자의 경우 자체 사용자 계정과 관련된 제한된 작업 집합만 사용할 수 있습니다.

5.4.1. 지원되는 웹 브라우저

Identity Management는 웹 UI 연결에 대해 다음과 같은 브라우저를 지원합니다.
  • Mozilla Firefox 38 이상
  • Google Chrome 46 이상

5.4.2. 웹 UI 액세스 및 인증

웹 UI는 IdM 서버 및 클라이언트 시스템에서 물론 IdM 도메인 외부의 시스템에서도 액세스할 수 있습니다. 그러나 도메인이 아닌 시스템에서 UI에 액세스하려면 IdM Kerberos 도메인에 연결할 수 있도록 non-IdM 시스템을 구성해야 합니다. 자세한 내용은 5.4.4절. “웹 UI로 Kerberos 인증을 위한 외부 시스템 구성” 을 참조하십시오.

5.4.2.1. 웹 UI 액세스

웹 UI에 액세스하려면 IdM 서버 URL을 브라우저 주소 표시줄에 입력합니다.
https://server.example.com
브라우저에서 IdM 웹 UI 로그인 화면이 열립니다.

그림 5.1. 웹 UI 로그인 화면

웹 UI 로그인 화면

5.4.2.2. 사용 가능한 로그인 방법

사용자는 다음과 같은 방법으로 웹 UI에 인증할 수 있습니다.
활성 Kerberos 티켓 사용
kinit 유틸리티를 사용하여 가져온 유효한 TGT가 있는 경우 로그인을 클릭하면 사용자를 자동으로 인증합니다. Kerberos 인증을 지원하려면 브라우저를 올바르게 구성해야 합니다.
Kerberos TGT 가져오기에 대한 자세한 내용은 5.2절. “Kerberos를 사용하여 IdM에 로그인” 을 참조하십시오. 브라우저 구성에 대한 자세한 내용은 5.4.3절. “Kerberos 인증을 위한 브라우저 구성” 을 참조하십시오.
사용자 이름 및 암호 지정
사용자 이름과 암호를 사용하여 인증하려면 웹 UI 로그인 화면에서 사용자 이름과 암호를 입력합니다.
IdM은 또한 일회성 암호(OTP) 인증을 지원합니다. 자세한 내용은 22.3절. “1회용 암호” 의 내용을 참조하십시오.
스마트 카드 사용
자세한 내용은 23.6절. “스마트 카드를 사용하여 ID 관리 웹 UI 인증” 의 내용을 참조하십시오.
사용자가 성공적으로 인증되면 IdM 관리 창이 열립니다.

그림 5.2. IdM 웹 UI 레이아웃

IdM 웹 UI 레이아웃

5.4.2.3. 웹 UI 세션 길이

사용자가 사용자 이름과 암호를 사용하여 IdM 웹 UI에 로그인하면 세션 길이는 로그인 작업 중에 가져온 Kerberos 티켓의 만료 기간과 동일합니다.

5.4.2.4. AD 사용자로 IdM 웹 UI에 인증

AD(Active Directory) 사용자는 사용자 이름과 암호를 사용하여 IdM 웹 UI에 로그인할 수 있습니다. 웹 UI에서 AD 사용자는 관리 권한과 관련된 관리 작업을 수행할 수 있는 IdM 사용자와 달리 자신의 사용자 계정과 관련된 제한된 작업 집합만 수행할 수 있습니다.
AD 사용자에 대한 웹 UI 로그인을 활성화하려면 IdM 관리자가 Default Trust View에서 각 AD 사용자에 대한 ID 재정의를 정의해야 합니다. 예를 들어 다음과 같습니다.
[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com
AD의 ID 뷰에 대한 자세한 내용은 Windows 통합 가이드 의 Active Directory 환경에서 ID 보기 사용을 참조하십시오.

5.4.3. Kerberos 인증을 위한 브라우저 구성

Kerberos 자격 증명을 사용하여 인증을 활성화하려면 IdM 도메인에 액세스하기 위한 Kerberos 협상을 지원하도록 브라우저를 구성해야 합니다. Kerberos 인증을 위해 브라우저가 올바르게 구성되지 않은 경우 IdM 웹 UI 로그인 화면에서 로그인을 클릭하면 오류 메시지가 표시됩니다.

그림 5.3. Kerberos 인증 오류

Kerberos 인증 오류
Kerberos 인증용 브라우저를 다음 세 가지 방법으로 구성할 수 있습니다.
  • IdM 웹 UI에서 자동으로 실행. 이 옵션은 Firefox에서만 사용할 수 있습니다. 자세한 내용은 “웹 UI에서 자동 Firefox 구성” 을 참조하십시오.
  • IdM 클라이언트 설치 중에 명령줄에서 자동으로 수행됩니다. 이 옵션은 Firefox에서만 사용할 수 있습니다. 자세한 내용은 “명령줄에서 Firefox 설정 자동” 을 참조하십시오.
  • Firefox 구성 설정에서 수동으로 다음을 수행합니다. 이 옵션은 지원되는 모든 브라우저에 사용할 수 있습니다. 자세한 내용은 “수동 브라우저 설정” 을 참조하십시오.
참고
시스템 수준 인증 가이드 에는 Firefox Kerberos 구성 문제 해결이 포함되어 있습니다. Kerberos 인증이 예상대로 작동하지 않는 경우 이 문제 해결 가이드에서 자세한 정보를 참조하십시오.

웹 UI에서 자동 Firefox 구성

IdM 웹 UI에서 Firefox를 자동으로 구성하려면 다음을 수행합니다.
  1. 웹 UI 로그인 화면에서 브라우저 구성에 대한 링크를 클릭합니다.
  2. Firefox 구성 링크를 선택하여 Firefox 구성 페이지를 엽니다.
  3. Firefox 구성 페이지의 단계를 따릅니다.

명령줄에서 Firefox 설정 자동

Firefox는 IdM 클라이언트 설치 중에 명령줄에서 구성할 수 있습니다. 이렇게 하려면 ipa-client-install 유틸리티를 사용하여 IdM 클라이언트를 설치할 때 --configure-firefox 옵션을 사용합니다.
# ipa-client-install --configure-firefox
configure -firefox 옵션은 SSO(Single Sign-On)에 대해 Kerberos를 활성화하는 기본 Firefox 설정을 사용하여 글로벌 구성 파일을 생성합니다.

수동 브라우저 설정

브라우저를 수동으로 구성하려면 다음을 수행합니다.
  1. 웹 UI 로그인 화면에서 브라우저 구성에 대한 링크를 클릭합니다.
  2. 수동 브라우저 구성에 사용할 링크를 선택합니다.
  3. 브라우저를 구성하는 지침을 찾고 단계를 따르십시오.

5.4.4. 웹 UI로 Kerberos 인증을 위한 외부 시스템 구성

IdM 도메인의 멤버가 아닌 시스템에서 웹 UI에 대한 Kerberos 인증을 활성화하려면 외부 시스템에서 IdM 관련 Kerberos 구성 파일을 정의해야 합니다. 외부 시스템에서 Kerberos 인증을 활성화하는 것은 인프라에 여러 영역 또는 겹치는 도메인이 포함된 경우 특히 유용합니다.
Kerberos 설정 파일을 생성하려면 다음을 수행합니다.
  1. IdM 서버에서 외부 시스템으로 /etc/krb5.conf 파일을 복사합니다. 예를 들어 다음과 같습니다.
    # scp /etc/krb5.conf root@externalmachine.example.com:/etc/krb5_ipa.conf
    주의
    외부 시스템의 기존> -<5.conf 파일을 덮어쓰지 마십시오.
  2. 외부 시스템에서 복사된 IdM Kerberos 구성 파일을 사용하도록 터미널 세션을 설정합니다.
    $ export KRB5_CONFIG=/etc/krb5_ipa.conf
  3. 5.4.3절. “Kerberos 인증을 위한 브라우저 구성” 에 설명된 대로 외부 시스템에서 브라우저를 구성합니다.
외부 시스템의 사용자는 kinit 유틸리티를 사용하여 IdM 서버 도메인에 대해 인증할 수 있습니다.

5.4.5. 웹 UI에서 프록시 서버 및 포트 전달

프록시 서버를 사용하여 웹 UI에 액세스하는 경우 IdM의 추가 구성이 필요하지 않습니다.
IdM 서버를 통해 포트 전달이 지원되지 않습니다. 그러나 프록시 서버를 사용할 수 있기 때문에 OpenSSH 및 uuidKS 옵션을 통해 프록시 전달을 사용하여 포트 전달과 유사한 작업을 구성할 수 있습니다. ssh 유틸리티의 -D 옵션을 사용하여 구성할 수 있습니다. -D 를 사용하는 방법에 대한 자세한 내용은 ssh(1) 도움말 페이지를 참조하십시오.

6장. 복제 토폴로지 관리

이 장에서는 IdM(Identity Management) 도메인에서 서버 간 복제를 관리하는 방법을 설명합니다.
참고
이 장에서는 Red Hat Enterprise Linux 7.3에 도입된 간단한 토폴로지 관리에 대해 설명합니다. 절차에는 도메인 수준 1이 필요합니다( 7장. 도메인 수준 표시 및 승격참조).
도메인 수준 0에서 토폴로지 관리에 대한 설명서는 D.3절. “복제 및 복제 계약 관리” 을 참조하십시오.
초기 복제 및 복제에 대한 기본 정보를 설치하는 방법에 대한 자세한 내용은 4장. ID 관리 복제본 설치 및 제거 을 참조하십시오.

6.1. 복제 계약, 토폴로지 번들 및 토폴로지 세그먼트 설명

복제 계약

IdM 서버에 저장된 데이터는 복제 계약에 따라 복제됩니다. 두 서버에 복제 계약이 구성되어 있으면 해당 데이터를 공유합니다.
복제 계약은 항상 최신 상태가 됩니다. 데이터는 첫 번째 복제본에서 다른 복제본에서 첫 번째 복제본에서 첫 번째 복제본으로 복제됩니다.
참고
자세한 내용은 4.1절. “IdM 복제 설명” 의 내용을 참조하십시오.

토폴로지 Suffixes

토폴로지 접미사 는 복제된 데이터를 저장합니다. IdM은 domainca의 두 가지 유형의 토폴로지 접미사를 지원합니다. 각 접미사는 별도의 백엔드인 별도의 복제 토폴로지를 나타냅니다.
복제 계약이 구성되면 두 개의 다른 서버에서 동일한 유형의 두 토폴로지 접미사가 결합합니다.
domain suffix: dc=example,dc=com
domain suffix에는 모든 도메인 관련 데이터가 포함되어 있습니다.
두 복제본의 domain 접미사 간 복제 계약이 있는 경우 사용자, 그룹 및 정책과 같은 디렉터리 데이터를 공유합니다.
ca suffix: o=ipaca
ca 접미사에는 인증서 시스템 구성 요소에 대한 데이터가 포함되어 있습니다. CA(인증 기관)가 설치된 서버에만 존재합니다.
두 복제본의 ca 접미사 간에 복제 계약이 있는 경우 인증서 데이터를 공유합니다.

그림 6.1. 토폴로지 Suffixes

토폴로지 Suffixes
초기 토폴로지 세그먼트는 새 복제본을 설치할 때 ipa-replica-install 스크립트를 통해 두 서버 간에 설정됩니다.

예 6.1. Topology Suffixes 보기

ipa topologysuffix-find 명령은 토폴로지 접미사 목록을 표시합니다.
$ ipa topologysuffix-find
---------------------------
2 topology suffixes matched
---------------------------
  Suffix name: ca
  Managed LDAP suffix DN: o=ipaca

  Suffix name: domain
  Managed LDAP suffix DN: dc=example,dc=com
----------------------------
Number of entries returned 2
----------------------------

토폴로지 세그먼트

두 복제본에 접미사 간 복제 계약이 있는 경우 접미사가 토폴로지 세그먼트 를 형성합니다. 각 토폴로지 세그먼트는 왼쪽 노드오른쪽 노드로 구성됩니다. 노드는 복제 계약에 포함된 서버를 나타냅니다.
IdM의 토폴로지 세그먼트는 항상 양방향입니다. 각 세그먼트는 서버 A에서 서버 B, 서버 A에 이르는 두 개의 복제 계약을 나타냅니다. 따라서 데이터는 두 방향으로 복제됩니다.

그림 6.2. 토폴로지 세그먼트

토폴로지 세그먼트

예 6.2. 토폴로지 세그먼트 보기

ipa topologysegment-find 명령은 도메인 또는 CA 접미사에 대해 구성된 현재 토폴로지 세그먼트를 표시합니다. 예를 들어 도메인 접미사의 경우 다음을 수행합니다.
$ ipa topologysegment-find
Suffix name: domain
-----------------
1 segment matched
-----------------
  Segment name: server1.example.com-to-server2.example.com
  Left node: server1.example.com
  Right node: server2.example.com
  Connectivity: both
----------------------------
Number of entries returned 1
----------------------------
이 예에서 도메인 관련 데이터는 server1.example.comserver1.example.com 의 두 서버 간에만 복제됩니다.
특정 세그먼트에 대한 세부 정보만 표시하려면 ipa topologysegment-show 명령을 사용합니다.
$ ipa topologysegment-show
Suffix name: domain
Segment name: server1.example.com-to-server2.example.com
  Segment name: server1.example.com-to-server2.example.com
  Left node: server1.example.com
  Right node: server2.example.com
  Connectivity: both

6.2. 웹 UI: 토폴로지 그래프를 사용하여 복제 토폴로지 관리

토폴로지 그래프 액세스

웹 UI의 토폴로지 그래프는 도메인의 서버 간 관계를 보여줍니다.
  1. IPA 서버토폴로지토폴로지그래프 를 선택합니다.
  2. 그래프에 즉시 반영되지 않는 토폴로지를 변경하는 경우 새로 고침을 클릭합니다.

토폴로지 보기 사용자 지정

마우스를 드래그하여 개별 토폴로지 노드를 이동할 수 있습니다.

그림 6.3. 토폴로지 그래프 노드 이동

토폴로지 그래프 노드 이동
마우스 wheel을 사용하여 토폴로지 그래프를 확대하고 축소할 수 있습니다.

그림 6.4. 토폴로지 그래프 확대

토폴로지 그래프 확대
왼쪽 마우스 버튼을 눌러 토폴로지 그래프의 캔버스를 이동할 수 있습니다.

그림 6.5. 토폴로지 그래프 캔버스 이동

토폴로지 그래프 캔버스 이동

토폴로지 그래프 해석

도메인 복제 계약에 조인된 서버는 주황색 화살표로 연결됩니다. CA 복제 계약에 조인된 서버는 파란색 화살표로 연결됩니다.
토폴로지 그래프 예: 권장 토폴로지
그림 6.6. “권장 토폴로지 예” 4개의 서버에 대해 권장되는 토폴로지 중 하나를 보여줍니다. 각 서버는 두 개 이상의 다른 서버에 연결되어 있으며 둘 이상의 서버는 CA 마스터입니다.

그림 6.6. 권장 토폴로지 예

권장 토폴로지 예
토폴로지 그래프 예: 권장되지 않는 토폴로지
그림 6.7. “권장되지 않는 토폴로지 예: 단일 장애 지점” 에서 server1 은 단일 장애 지점입니다. 다른 모든 서버에는 이 서버와의 복제 계약이 있지만 다른 서버와는 적용되지 않습니다. 따라서 server1 이 실패하면 다른 모든 서버가 격리됩니다.
이와 같은 토폴로지를 만들지 마십시오.

그림 6.7. 권장되지 않는 토폴로지 예: 단일 장애 지점

권장되지 않는 토폴로지 예: 단일 장애 지점
토폴로지 권장 사항에 대한 자세한 내용은 4.2절. “복제본에 대한 배포 고려 사항” 을 참조하십시오.

6.2.1. 두 서버 간에 복제 설정

  1. 토폴로지 그래프에서 서버 노드 중 하나에 마우스를 가져갑니다.

    그림 6.8. 도메인 또는 CA 옵션

    도메인 또는 CA 옵션
  2. 생성할 토폴로지 세그먼트 유형에 따라 도메인 또는 원의 ca 부분을 클릭합니다.
  3. 새 복제 계약을 나타내는 새로운 화살표가 마우스 포인터 아래에 표시됩니다. 마우스를 다른 서버 노드로 이동하고 클릭합니다.

    그림 6.9. 새 세그먼트 생성

    새 세그먼트 생성
  4. 토폴로지 세그먼트 추가 창에서 추가 를 클릭하여 새 세그먼트의 속성을 확인합니다.
IdM은 두 서버 사이에 새 토폴로지 세그먼트를 생성하여 복제 계약에 참여합니다. 토폴로지 그래프에 업데이트된 복제 토폴로지가 표시됩니다.

그림 6.10. 새로 생성된 세그먼트

새로 생성된 세그먼트

6.2.2. 두 서버 간 복제 중지

  1. 제거하려는 복제 계약을 나타내는 화살표를 클릭합니다. 이는 화살표를 강조 표시합니다.

    그림 6.11. 토폴로지 강조 표시

    토폴로지 강조 표시
  2. 삭제를 클릭합니다.
  3. 확인 창에서 확인을 클릭합니다.
IdM은 두 서버 간의 토폴로지 세그먼트를 제거하여 복제 연결을 삭제합니다. 토폴로지 그래프에 업데이트된 복제 토폴로지가 표시됩니다.

그림 6.12. 토폴로지 세그먼트 삭제

토폴로지 세그먼트 삭제

6.3. 명령줄: ipa 토폴로지* 명령을 사용하여 토폴로지 관리

6.3.1. 토폴로지 관리 명령에 대한 도움말 가져오기

복제 토폴로지를 관리하는 데 사용되는 모든 명령을 표시하려면 다음을 수행합니다.
$ ipa help topology
특정 명령에 대한 자세한 도움말을 표시하려면 --help 옵션을 사용하여 실행합니다.
$ ipa topologysuffix-show --help

6.3.2. 두 서버 간에 복제 설정

  1. ipa topologysegment-add 명령을 사용하여 두 서버의 토폴로지 세그먼트를 생성합니다. 메시지가 표시되면 다음을 입력합니다.
    • 필요한 토폴로지 접미사: domain 또는 ca
      참고
      ca 접미사 사이에서 세그먼트를 생성하려면 두 서버에 CA가 설치되어 있어야 합니다. 26.8절. “기존 IdM 도메인에 CA 설치” 참조하십시오.
    • 두 서버를 나타내는 왼쪽 노드와 올바른 노드
    • 선택적으로 세그먼트에 대한 사용자 정의 이름
    예를 들어 다음과 같습니다.
    $ ipa topologysegment-add
    Suffix name: domain
    Left node: server1.example.com
    Right node: server2.example.com
    Segment name [server1.example.com-to-server2.example.com]: new_segment
    ---------------------------
    Added segment "new_segment"
    ---------------------------
      Segment name: new_segment
      Left node: server1.example.com
      Right node: server2.example.com
      Connectivity: both
    새 세그먼트를 추가하면 복제 연결의 서버에 참여합니다.
  2. 선택 사항입니다. ipa topologysegment-show 명령을 사용하여 새 세그먼트가 구성되어 있는지 확인합니다.
    $ ipa topologysegment-show
    Suffix name: domain
    Segment name: new_segment
      Segment name: new_segment
      Left node: server1.example.com
      Right node: server2.example.com
      Connectivity: both

6.3.3. 두 서버 간 복제 중지

  1. 복제를 중지하려면 서버 간에 해당 복제 세그먼트를 삭제해야 합니다. 이를 위해서는 세그먼트 이름을 알아야 합니다.
    이름을 모르는 경우 ipa topologysegment-find 명령을 사용하여 모든 세그먼트를 표시하고 출력에서 필요한 세그먼트를 찾습니다. 메시지가 표시되면 필요한 토폴로지 접미사( domain 또는 ca )를 입력합니다. 예를 들어 다음과 같습니다.
    $ ipa topologysegment-find
    Suffix name: domain
    ------------------
    8 segments matched
    ------------------
      Segment name: new_segment
      Left node: server1.example.com
      Right node: server2.example.com
      Connectivity: both
    
    ...
    
    ----------------------------
    Number of entries returned 8
    ----------------------------
  2. ipa topologysegment-del 명령을 사용하여 두 서버에 가입하는 토폴로지 세그먼트를 제거합니다.
    $ ipa topologysegment-del
    Suffix name: domain
    Segment name: new_segment
    -----------------------------
    Deleted segment "new_segment"
    -----------------------------
    세그먼트를 삭제하면 복제 연결이 제거됩니다.
  3. 선택 사항입니다. ipa topologysegment-find 명령을 사용하여 세그먼트가 더 이상 나열되지 않는지 확인합니다.
    $ ipa topologysegment-find
    Suffix name: domain
    ------------------
    7 segments matched
    ------------------
      Segment name: server2.example.com-to-server3.example.com
      Left node: server2.example.com
      Right node: server3.example.com
      Connectivity: both
    
    ...
    
    ----------------------------
    Number of entries returned 7
    ----------------------------

6.4. 토폴로지에서 서버 제거

다음 중 하나가 적용되는 경우 IdM에서 토폴로지에서 서버를 제거하는 것을 허용하지 않습니다.
  • 제거 중인 서버는 다른 서버를 나머지 토폴로지와 연결하는 유일한 서버입니다. 이로 인해 다른 서버가 격리되어 허용되지 않습니다.
  • 제거 중인 서버는 마지막 CA 또는 DNS 서버입니다.
이러한 상황에서 시도는 오류와 함께 실패합니다. 예를 들어 명령줄에서 다음을 수행합니다.
$ ipa server-del
Server name: server1.example.com
Removing server1.example.com from replication topology, please wait...
ipa: ERROR: Server removal aborted:

Removal of 'server1.example.com' leads to disconnected topology in suffix 'domain':
Topology does not allow server server2.example.com to replicate with servers:
  server3.example.com
  server4.example.com
...

6.4.1. 웹 UI: 토폴로지에서 서버 제거

머신에서 서버 구성 요소를 제거하지 않고 토폴로지에서 서버를 제거하려면 다음을 수행합니다.
  1. IPA 서버토폴로지IPA 서버를 선택합니다.
  2. 삭제할 서버 이름을 클릭합니다.

    그림 6.13. 서버 선택

    서버 선택
  3. 서버 삭제를 클릭합니다.

6.4.2. 명령줄: 토폴로지에서 서버 제거

중요
서버를 제거하는 것은 되돌릴 수 없는 작업입니다. 서버를 제거하면 토폴로지에 다시 도입하는 유일한 방법은 시스템에 새 복제본을 설치하는 것입니다.
server1.example.com 을 제거하려면 다음을 수행합니다.
  1. 다른 서버에서 ipa server-del 명령을 실행하여 server1.example.com 을 제거합니다. 명령은 서버를 가리키는 모든 토폴로지 세그먼트를 제거합니다.
    [user@server2 ~]$ ipa server-del
    Server name: server1.example.com
    Removing server1.example.com from replication topology, please wait...
    ----------------------------------------------------------
    Deleted IPA server "server1.example.com"
    ----------------------------------------------------------
  2. server1.example.com 에서 ipa server-install --uninstall 명령을 실행하여 시스템에서 서버 구성 요소를 제거합니다.
    [root@server1 ~]# ipa server-install --uninstall

6.5. 서버 역할 관리

IdM 서버에 설치된 서비스를 기반으로 다양한 서버 역할을 수행할 수 있습니다. 예를 들어 다음과 같습니다. CA 서버, DNS 서버 또는 KRA(키 복구 기관) 서버.

6.5.1. 서버 역할 보기

웹 UI: 서버 역할 보기

지원되는 서버 역할의 전체 목록은 IPA 서버토폴로지서버역할을 참조하십시오.
  • role status absent 는 토폴로지의 서버가 역할을 수행하지 않음을 의미합니다.
  • 역할 상태가 활성화됨 은 토폴로지에서 하나 이상의 서버가 역할을 수행함을 의미합니다.

그림 6.14. 웹 UI의 서버 역할

웹 UI의 서버 역할

명령줄: 서버 역할 보기

ipa config-show 명령은 모든 CA 서버, NTP 서버 및 현재 CA 갱신 마스터를 표시합니다.
$ ipa config-show
  ...
  IPA masters: server1.example.com, server2.example.com, server3.example.com
  IPA CA servers: server1.example.com, server2.example.com
  IPA NTP servers: server1.example.com, server2.example.com, server3.example.com
  IPA CA renewal master: server1.example.com
ipa server-show 명령은 특정 서버에서 활성화된 역할 목록을 표시합니다. 예를 들어 server.example.com에서 활성화된 역할 목록은 다음과 같습니다.
$ ipa server-show
Server name: server.example.com
  ...
  Enabled server roles: CA server, DNS server, NTP server, KRA server
ipa server-find --servrole 은 특정 서버 역할이 활성화된 모든 서버를 검색합니다. 예를 들어 모든 CA 서버를 검색하려면 다음을 수행합니다.
$ ipa server-find --servrole "CA server"
---------------------
2 IPA servers matched
---------------------
  Server name: server1.example.com
  ...

  Server name: server2.example.com
  ...
----------------------------
Number of entries returned 2
----------------------------

6.5.2. 마스터 CA 서버로 복제 승격

참고
이 섹션에서는 도메인 수준 1에서 CA 갱신 마스터 변경에 대해 설명합니다( 7장. 도메인 수준 표시 및 승격참조). 도메인 수준 0에서 CA 갱신 마스터 변경에 대한 자세한 내용은 D.4절. “마스터 CA 서버로 복제 승격” 을 참조하십시오.
IdM 배포에서 임베디드 CA(인증 기관)를 사용하는 경우 IdM CA 서버 중 하나가 마스터 CA 역할을 합니다. CA 하위 시스템의 인증서 갱신을 관리하고 CRL(인증서 폐기 목록)을 생성합니다. 기본적으로 마스터 CA는 시스템 관리자가 ipa-server-install 또는 ipa-ca-install 명령을 사용하여 CA 역할을 설치한 첫 번째 서버입니다.
마스터 CA 서버를 오프라인으로 사용하거나 해제하려는 경우 다른 CA 서버를 새 CA 갱신 마스터로 대체하도록 승격합니다.
  1. CA 하위 시스템 인증서 갱신을 처리하도록 복제본을 구성합니다.
  2. CRL을 생성하도록 복제본을 구성합니다. 6.5.2.2절. “CRL을 생성하는 서버 변경” 참조하십시오.
  3. 이전 마스터 CA 서버를 해제하기 전에 새 마스터가 제대로 작동하는지 확인합니다. 6.5.2.3절. “새 마스터 CA 서버가 올바르게 구성되었는지 확인” 참조하십시오.

6.5.2.1. 현재 CA 갱신 마스터 변경

웹 UI: 현재 CA 갱신 마스터 변경

  1. IPA 서버 구성을선택합니다.
  2. IPA CA 갱신 마스터 필드에서 새 CA 갱신 마스터를 선택합니다.

명령줄: 현재 CA 갱신 마스터 변경

ipa config-mod --ca-renewal-master-server 명령을 사용합니다.
$ ipa config-mod --ca-renewal-master-server new_ca_renewal_master.example.com
  ...
  IPA masters: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
  IPA CA servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
  IPA NTP servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
  IPA CA renewal master: new_ca_renewal_master.example.com
출력에서 업데이트가 성공했음을 확인합니다.

6.5.2.2. CRL을 생성하는 서버 변경

CRL(인증서 폐기 목록)을 생성하는 서버를 변경하려면 다음을 수행합니다.
  1. 현재 CRL 생성 마스터를 모르는 경우 각 IdM 인증 기관(CA)에서 ipa-crlgen-manage status 명령을 사용하여 CRL 생성이 활성화되어 있는지 여부를 확인합니다.
    # ipa-crlgen-manage status
    CRL generation: enabled
  2. 현재 CRL 생성 마스터에서 기능을 비활성화합니다.
    # ipa-crlgen-manage disable
  3. 새 CRL 생성 마스터로 구성하려는 다른 CA 호스트에서 기능을 활성화합니다.
    # ipa-crlgen-manage enable

6.5.2.3. 새 마스터 CA 서버가 올바르게 구성되었는지 확인

새 마스터 CA 서버에 /var/lib/ipa/pki-ca/publish/MasterCRL.bin 파일이 있는지 확인합니다.
파일은 ca.crl.MasterCRL.autoUpdateInterval 매개변수를 사용하여 /etc/pki/pki-tomcat/ca/CS.cfg 파일에 정의된 시간 간격을 기반으로 생성됩니다. 기본값은 240분(4시간)입니다.
참고
ca.crl.MasterCRL.autoUpdateInterval 매개변수를 업데이트하면 다음 이미 예약된 CRL 업데이트 후에 변경 사항이 적용됩니다.
파일이 있는 경우 새 마스터 CA 서버가 올바르게 구성되고 이전 CA 마스터 시스템을 안전하게 거부할 수 있습니다.

6.5.3. IdM 서버에서 IdM CA 서비스 설치 제거

Red Hat은 토폴로지에서 CA 역할이 있는 최대 4개의 IdM(Identity Management) 복제본을 사용하는 것이 좋습니다. 따라서 중복 인증서 복제로 인해 이러한 복제본 및 성능 문제가 4개 이상 있는 경우 IdM 복제본에서 중복 CA 서비스 인스턴스를 제거합니다. 이렇게 하려면 CA 서비스 없이 IdM을 다시 설치하기 전에 먼저 영향을 받는 IdM 복제본을 완전히 해제해야 합니다.
중요
IdM 복제본에 CA 역할을 추가할 수 있지만 IdM은 IdM 복제본에서 CA 역할만 제거하는 방법을 제공하지 않습니다. ipa-ca-install 명령에 --uninstall 옵션이 없습니다.
  1. 중복 CA 서비스를 식별하고 이 서비스를 호스팅하는 IdM 복제본의 2.4절. “IdM 서버 설치 제거” 의 절차를 따릅니다.
  2. 동일한 호스트에서 사용 사례에 따라 2.3.5절. “외부 CA를 루트 CA로 사용하여 서버 설치” 또는 2.3.6절. “CA 없는 상태에서 설치” 의 절차를 따르십시오.

6.5.4. Hidden Replicas의 데모 및 프로모션

복제본이 설치되면 복제본이 숨겨진지 표시되었는지 여부를 변경할 수 있습니다.
  • 표시되는 복제본을 숨겨진 복제본에 인증하려면 다음을 수행합니다.
    1. 복제본이 CA 갱신 마스터인 경우 서비스를 다른 복제본으로 이동합니다. 자세한 내용은 6.5.2.1절. “현재 CA 갱신 마스터 변경” 의 내용을 참조하십시오.
    2. 복제본 상태를 숨겨진 상태로 변경합니다.
      # ipa server-state replica.idm.example.com --state=hidden
  • 숨겨진 복제본을 표시되는 복제본으로 승격하려면 다음을 입력합니다.
    # ipa server-state replica.idm.example.com --state=enabled
참고
숨겨진 복제본 기능은 Red Hat Enterprise Linux 7.7 이상에서 기술 프리뷰로 제공되므로 지원되지 않습니다.

7장. 도메인 수준 표시 및 승격

도메인 수준은 IdM 토폴로지에서 사용할 수 있는 작업 및 기능을 나타냅니다.
도메인 수준 1
사용 가능한 기능의 예:
중요
도메인 수준 1은 Red Hat Enterprise Linux 7.3 및 IdM 버전 4.4에서 도입되었습니다. 도메인 수준 1 기능을 사용하려면 모든 복제본이 Red Hat Enterprise Linux 7.3 이상을 실행해야 합니다.
첫 번째 서버가 Red Hat Enterprise Linux 7.3과 함께 설치된 경우 도메인의 도메인 수준이 자동으로 1로 설정됩니다.
모든 서버를 이전 버전에서 IdM 버전 4.4로 업그레이드하는 경우 도메인 수준이 자동으로 표시되지 않습니다. 도메인 수준 1 기능을 사용하려면 7.2절. “도메인 수준 향상” 에 설명된 대로 도메인 수준을 수동으로 높입니다.
도메인 수준 0
사용 가능한 기능의 예:
  • ipa-replica-install 을 사용하려면 초기 서버에서 복제본 정보 파일을 생성하여 복제에 복사하는 복잡한 프로세스가 필요합니다( D.2절. “복제 생성”참조).
  • ipa-replica-manageipa-csreplica-manage 를 사용하여 보다 복잡하고 error-prone 토폴로지 관리 ( D.3절. “복제 및 복제 계약 관리”참조)

7.1. 현재 도메인 수준 표시

명령줄: 현재 도메인 수준 표시

  1. 관리자로 로그인합니다.
    $ kinit admin
  2. ipa domainlevel-get 명령을 실행합니다.
    $ ipa domainlevel-get
    -----------------------
    Current domain level: 0
    -----------------------

웹 UI: 현재 도메인 수준 표시

IPA 서버토폴로지도메인 수준을 선택합니다.

7.2. 도메인 수준 향상

중요
되돌릴 수 없는 작업입니다. 도메인 수준을 0 에서 1 로 올리면 다시 1 에서 0 으로 다운그레이드할 수 없습니다.

명령줄: 도메인 수준 향상

  1. 관리자로 로그인합니다.
    $ kinit admin
  2. ipa domainlevel-set 명령을 실행하고 필요한 수준을 제공합니다.
    $ ipa domainlevel-set 1
    -----------------------
    Current domain level: 1
    -----------------------

웹 UI: 도메인 수준 향상

  1. IPA 서버토폴로지도메인 수준을 선택합니다.
  2. Set Domain Level 을 클릭합니다.

8장. Identity Management 업데이트 및 마이그레이션

8.1. Identity Management 업데이트

yum 유틸리티를 사용하여 시스템의 Identity Management 패키지를 업데이트할 수 있습니다.
주의
업데이트를 설치하기 전에 RHEL 시스템과 관련된 이전에 릴리스된 모든 에라타를 적용해야 합니다. 자세한 내용은 How do I apply package updates to my RHEL system에서 참조하십시오. KCS 문서.
또한 7.3과 같은 새로운 마이너 Red Hat Enterprise Linux 버전을 사용할 수 있는 경우 yum 은 Identity Management 서버 또는 클라이언트를 이 버전으로 업그레이드합니다.
참고
이 섹션에서는 Red Hat Enterprise Linux 6에서 Red Hat Enterprise Linux 7로 ID 관리 마이그레이션에 대해 설명하지 않습니다. 마이그레이션하려면 8.2절. “Red Hat Enterprise Linux 6에서 버전 7으로 ID 관리 마이그레이션” 을 참조하십시오.

8.1.1. ID 관리 업데이트 고려 사항

  • 하나 이상의 서버에서 ID 관리 패키지를 업데이트한 후 토폴로지의 다른 모든 서버는 패키지를 업데이트하지 않아도 업데이트된 스키마를 받습니다. 이렇게 하면 새 스키마를 사용하는 새 항목을 다른 서버에 복제할 수 있습니다.
  • Identity Management 패키지 다운그레이드는 지원되지 않습니다.
    중요
    ipa-* 패키지에서 yum downgrade 명령을 실행하지 마십시오.
  • Red Hat은 다음 버전으로만 업그레이드할 것을 권장합니다. 예를 들어 Red Hat Enterprise Linux 7.4의 ID 관리로 업그레이드하려면 Red Hat Enterprise Linux 7.3용 Identity Management에서 업그레이드할 것을 권장합니다. 이전 버전에서 업그레이드하면 문제가 발생할 수 있습니다.

8.1.2. yum 을 사용하여 ID 관리 패키지 업데이트

서버 또는 클라이언트의 모든 ID 관리 패키지를 업데이트하려면 다음을 수행합니다.
# yum update ipa-*
주의
Identity Management 서버를 여러 개 업그레이드하는 경우 각 업그레이드 사이에 10분 이상 기다립니다.
두 개 이상의 서버가 동시에 업그레이드되거나 업그레이드 간에 짧은 간격으로 업그레이드되면 토폴로지 전체에서 사후 업그레이드 데이터 변경 사항을 복제할 시간이 없으므로 복제 이벤트가 충돌할 수 있습니다.

관련 정보

중요
CVE-2014-3566 으로 인해 mod_nss 모듈에서 SSLv3(Secure Socket Layer 버전 3) 프로토콜을 비활성화해야 합니다. 다음 단계를 수행하여 확인할 수 있습니다.
  1. /etc/httpd/conf.d/nss.conf 파일을 편집하고 NSSProtocol 매개변수를 TLSv1.0 (이전 버전 호환성을 위해), TLSv1.1TLSv1.2 로 설정합니다.
    NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
  2. httpd 서비스를 다시 시작합니다.
    # systemctl restart httpd.service
Red Hat Enterprise Linux 7의 Identity Management는 기본 패키지를 업그레이드하기 위해 yum update ipa-* 명령을 시작할 때 위의 단계를 자동으로 수행합니다.

8.2. Red Hat Enterprise Linux 6에서 버전 7으로 ID 관리 마이그레이션

다음 절차에서는 Red Hat Enterprise Linux 6 Identity Management에서 Red Hat Enterprise Linux 7 서버로 모든 데이터 및 구성을 마이그레이션하는 방법을 설명합니다. 마이그레이션 절차에는 다음이 포함됩니다.
  • Red Hat Enterprise Linux 6 기반 인증 기관(CA) 마스터 서버를 Red Hat Enterprise Linux 7로 마이그레이션.
  • 모든 서비스를 새로운 Red Hat Enterprise Linux 7 서버로 전환. 이러한 서비스에는 CRL 및 인증서 생성, DNS 관리 또는 Kerberos KDC 관리가 포함됩니다.
  • 원래 Red Hat Enterprise Linux 6 CA 마스터 폐기.
다음 절차에서는 다음을 수행합니다.
  • rhel7.example.com 은 새 CA 마스터가 될 Red Hat Enterprise Linux 7 시스템입니다.
    중요
    현재 지원되는 유일한 마이너 버전은 RHEL 7.9입니다. 시스템에 RHEL 7.9가 설치되어 있는지 확인합니다.
  • rhel6.example.com 은 원래 Red Hat Enterprise Linux 6 CA 마스터입니다.
    참고
    마스터 CA 서버인 Red Hat Enterprise Linux 6 서버를 식별하려면 certmonger 서비스가 renew_ca_cert 명령을 추적하는 서버를 결정합니다. 모든 Red Hat Enterprise Linux 6 서버에서 다음 명령을 실행하십시오.
    [root@rhel6 ~]# getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" | grep post-save
    post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"
    renew_ca_cert 를 실행하는 후 저장 작업은 CA 마스터에 대해서만 정의됩니다.

8.2.1. Red Hat Enterprise Linux 6에서 7로 ID 관리를 마이그레이션하기 위한 필수 조건

  • rhel6.example.com 시스템을 최신 Red Hat Enterprise Linux 6 버전으로 업데이트합니다.
  • rhel6.example.com 시스템에서 ipa-* 패키지를 업그레이드합니다.
    [root@rhel6 ~]# yum update ipa-*
    또한 이 단계에서는 bind-dyndb-ldap 패키지의 2.3-6.el6_6 버전을 제공하는 RHBA-2015:0231-2 권고를 적용했으며 Red Hat Enterprise Linux 6.6 Extended Update Support (EUS)에서 사용할 수 있습니다.
    주의
    이전 버전의 bind-dyndb-ldap 를 사용하면 Red Hat Enterprise Linux 6.6 DNS 서버와 Red Hat Enterprise Linux 7 DNS 서버 간에 제공되는 DNS 전달 영역에서 일관되지 않은 동작이 발생합니다.
  • rhel7.example.com 시스템이 2.1절. “서버 설치 사전 요구 사항”4.3절. “복제본 설치 사전 요구 사항” 의 요구 사항을 충족하는지 확인합니다.
  • rhel7.example.com 시스템에서 필요한 패키지를 설치합니다. 2.2절. “IdM 서버 설치에 필요한 패키지” 참조하십시오.

8.2.2. Red Hat Enterprise Linux 6에서 ID 관리 스키마 업데이트

copy-schema-to-ca.py 스키마 업데이트 스크립트는 rhel7.example.com 복제본 설치를 위해 rhel6.example.com 을 준비합니다. ID 관리 버전 3.1 이상 버전 간의 스키마 변경으로 인해 스키마를 업데이트해야 합니다.
  1. rhel7.example.com 시스템에서 rhel6.example.com 시스템으로 copy-schema-to-ca.py 스키마 업데이트 스크립트를 복사합니다. 예를 들어 다음과 같습니다.
    [root@rhel7 ~]# scp /usr/share/ipa/copy-schema-to-ca.py root@rhel6:/root/
  2. rhel6.example.com 에서 업데이트된 copy-schema-to-ca.py 스크립트를 실행합니다.
    [root@rhel6 ~]# python copy-schema-to-ca.py
    ipa         : INFO     Installed /etc/dirsrv/slapd-PKI-IPA//schema/60kerberos.ldif
    [... output truncated ...]
    ipa         : INFO     Schema updated successfully
  3. Red Hat Enterprise Linux 7 복제본에 연결하기 전에 인증 기관을 실행하는 모든 Red Hat Enterprise Linux 6 IdM 복제본에서 단계를 반복합니다.

8.2.3. Red Hat Enterprise Linux 7 Replica 설치

  1. rhel6.example.com 시스템에서 rhel7.example.com 복제본을 설치하는 데 사용할 복제본 파일을 생성합니다. 예를 들어 IP 주소가 192.0.2.1rhel7.example.com 의 복제본 파일을 생성하려면 다음을 수행합니다.
    [root@rhel6 ~]# ipa-replica-prepare rhel7.example.com --ip-address 192.0.2.1
    
    Directory Manager (existing master) password:
    Preparing replica for rhel7.example.com from rhel6.example.com
    [... output truncated ...]
    The ipa-replica-prepare command was successful
  2. rhel6.example.com 의 복제본 정보 파일을 rhel7.example.com 에 복사합니다.
    [root@rhel6 ~]# scp /var/lib/ipa/replica-info-replica.example.com.gpg root@rhel7:/var/lib/ipa/
  3. Red Hat Enterprise Linux 7.6 이상에 통합 CA를 사용하여 새 복제본을 설치하는 경우 /etc/httpd/conf.d/nss.conf 파일의 NSSCipherSuite 매개변수 끝에 다음 항목을 추가합니다.
    +ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha
    Red Hat Enterprise Linux 7.6 이상에서는 IdM CA에서 특정 암호가 더 이상 기본적으로 활성화되어 있지 않습니다. 이 항목을 구성에 추가하지 않고 Red Hat Enterprise Linux 7.6에서 통합된 CA가 있는 IdM 서버를 Red Hat Enterprise Linux 6에서 실행되는 마스터 복제본으로 설정하면 CRITICAL에 CA 인스턴스 오류를 설정하지 못했습니다.
  4. 복제본 파일을 사용하여 rhel7.example.com 복제본을 설치합니다. 예를 들어 다음 명령은 이러한 옵션을 사용합니다.
    • 인증서 시스템 구성 요소를 설정하려면 --setup-ca
    • 통합 DNS 서버를 구성하고 forwarder를 설정하려면 --setup-dns 및 --forwarder
    • --IP-address: rhel7.example.com 시스템의 IP 주소를 지정
    [root@rhel7 ~]# ipa-replica-install /var/lib/ipa/replica-info-rhel7.example.com.gpg --setup-ca --ip-address 192.0.2.1 --setup-dns --forwarder 192.0.2.20
    Directory Manager (existing master) password:
    
    Checking DNS forwarders, please wait ...
    Run connection check to master
    [... output truncated ...]
    Client configuration complete.
    또한 다음을 참조하십시오.
  5. Identity Management 서비스가 rhel7.example.com 에서 실행 중인지 확인합니다.
    [root@rhel7 ~]# ipactl status
    Directory Service: RUNNING
    [... output truncated ...]
    ipa: INFO: The ipactl command was successful

8.2.4. Red Hat Enterprise Linux 7 서버로 CA 서비스 전환

시작하기 전에:
  • rhel6.example.comrhel7.example.com CA가 모두 마스터 서버로 구성되어 있는지 확인합니다.
    [root@rhel7 ~]$ kinit admin
    [root@rhel7 ~]$ ipa-csreplica-manage list
    rhel6.example.com: master
    rhel7.example.com: master
    복제 연결에 대한 세부 정보를 표시하려면 다음을 수행합니다.
    [root@rhel7 ~]# ipa-csreplica-manage list --verbose rhel7.example.com
    rhel7.example.com
    last init status: None
    last init ended: 1970-01-01 00:00:00+00:00
    last update status: Error (0) Replica acquired successfully: Incremental update succeeded
    last update ended: 2017-02-13 13:55:13+00:00
rhel6.example.com 원래 마스터 CA에서 CA 하위 시스템 인증서 갱신을 중지합니다.
  1. 원래 CA 인증서에 대한 추적을 비활성화합니다.
    [root@rhel6 ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "auditSigningCert cert-pki-ca"
    Request "20201127184547" removed.
    [root@rhel6 ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "ocspSigningCert cert-pki-ca"
    Request "20201127184548" removed.
    [root@rhel6 ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca"
    Request "20201127184549" removed.
    [root@rhel6 ~]# getcert stop-tracking -d /etc/httpd/alias -n ipaCert
    Request "20201127184550" removed.
  2. 새 마스터 CA에서 갱신된 인증서를 검색하도록 rhel6.example.com 을 재구성하십시오.
    1. 갱신 도우미 스크립트를 certmonger 서비스 디렉터리에 복사하고 적절한 권한을 설정합니다.
      [root@rhel6 ~]# cp /usr/share/ipa/ca_renewal /var/lib/certmonger/cas/
      [root@rhel6 ~]# chmod 0600 /var/lib/certmonger/cas/ca_renewal
    2. SELinux 구성을 업데이트합니다.
      [root@rhel6 ~]# restorecon /var/lib/certmonger/cas/ca_renewal
    3. certmonger 를 다시 시작합니다.
      [root@rhel6 ~]# service certmonger restart
    4. 인증서를 검색하도록 CA가 나열되었는지 확인합니다.
      [root@rhel6 ~]# getcert list-cas
      ...
      CA 'dogtag-ipa-retrieve-agent-submit':
              is-default: no
              ca-type: EXTERNAL
      	helper-location: /usr/libexec/certmonger/dogtag-ipa-retrieve-agent-submit
    5. CA 인증서 데이터베이스 PIN을 가져옵니다.
      [root@rhel6 ~]# grep internal= /var/lib/pki-ca/conf/password.conf
    6. 외부 갱신을 위한 인증서를 추적하도록 certmonger 를 구성합니다. 이를 위해서는 데이터베이스 PIN이 필요합니다.
      [root@rhel6 ~]# getcert start-tracking \
          -c dogtag-ipa-retrieve-agent-submit \
          -d /var/lib/pki-ca/alias \
          -n "auditSigningCert cert-pki-ca" \
          -B /usr/lib64/ipa/certmonger/stop_pkicad \
          -C '/usr/lib64/ipa/certmonger/restart_pkicad \
          "auditSigningCert cert-pki-ca"' \
          -T "auditSigningCert cert-pki-ca" \
          -P database_pin
      New tracking request "20201127184743" added.
      [root@rhel6 ~]# getcert start-tracking \
          -c dogtag-ipa-retrieve-agent-submit \
          -d /var/lib/pki-ca/alias \
          -n "ocspSigningCert cert-pki-ca" \
          -B /usr/lib64/ipa/certmonger/stop_pkicad \
          -C '/usr/lib64/ipa/certmonger/restart_pkicad \
          "ocspSigningCert cert-pki-ca"' \
          -T "ocspSigningCert cert-pki-ca" \
          -P database_pin
      New tracking request "20201127184744" added.
      [root@rhel6 ~]# getcert start-tracking \
          -c dogtag-ipa-retrieve-agent-submit \
          -d /var/lib/pki-ca/alias \
          -n "subsystemCert cert-pki-ca" \
          -B /usr/lib64/ipa/certmonger/stop_pkicad \
          -C '/usr/lib64/ipa/certmonger/restart_pkicad \
          "subsystemCert cert-pki-ca"' \
          -T "subsystemCert cert-pki-ca" \
          -P database_pin
      New tracking request "20201127184745" added.
      [root@rhel6 ~]# getcert start-tracking \
          -c dogtag-ipa-retrieve-agent-submit \
          -d /etc/httpd/alias \
          -n ipaCert \
          -C /usr/lib64/ipa/certmonger/restart_httpd \
          -T ipaCert \
          -p /etc/httpd/alias/pwdfile.txt
      New tracking request "20201127184746" added.
원래 rhel6.example.com CA 마스터에서 rhel7.example.com 으로 CRL 생성을 이동합니다.
  1. rhel6.example.com 에서 CRL 생성을 중지합니다.
    1. CA 서비스를 중지합니다.
      [root@rhel6 ~]# service pki-cad stop
    2. rhel6.example.com 에서 CRL 생성을 비활성화합니다. /var/lib/pki-ca/CS.cfg 파일을 열고 ca.crl.MasterCRL.enableCRL.enableCRL .enableCRL.enableCRLUpdates 매개변수 값을 false 로 설정합니다.
      ca.crl.MasterCRL.enableCRLCache=false
      ca.crl.MasterCRL.enableCRLUpdates=false
    3. CA 서비스를 시작합니다.
      [root@rhel6 ~]# service pki-cad start
  2. rhel6.example.com 에서 CRL 요청을 리디렉션하도록 Apache를 구성합니다.
    1. /etc/httpd/conf.d/ipa-pki-proxy.conf 파일을 열고 RewriteRule 항목의 주석을 삭제합니다.
      RewriteRule ^/ipa/crl/MasterCRL.bin https://rhel6.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
      참고
      URL에서 서버 호스트 이름을 대체하지 마십시오. URL은 로컬 호스트 이름을 참조해야 합니다.
    2. Apache를 다시 시작합니다.
      [root@rhel6 ~]# service httpd restart
    IdM은 로컬 파일 대신 로컬 CA에서 인증서 해지 목록(CRL)을 가져옵니다.
  3. rhel7.example.com 에서 rhel7.example.com 을 새 CA 마스터로 구성합니다.
    1. D.4.1절. “Which Server가 인증서 갱신을 처리하는 변경” 에 설명된 대로 CA 하위 시스템 인증서 갱신을 처리하도록 rhel7.example.com 을 구성합니다.
    2. 6.5.2.2절. “CRL을 생성하는 서버 변경” 에 설명된 대로 rhel7.example.com 을 일반 인증서 취소 목록(CRL)으로 구성합니다.

관련 정보

8.2.5. Red Hat Enterprise Linux 6 Server 중지

rhel6.example.com 에서 모든 서비스를 중지하여 새 rhel7.example.com 서버에 도메인 검색을 강제 수행합니다.
[root@rhel6 ~]# ipactl stop
Stopping CA Service
Stopping pki-ca:                                           [  OK  ]
Stopping HTTP Service
Stopping httpd:                                            [  OK  ]
Stopping MEMCACHE Service
Stopping ipa_memcached:                                    [  OK  ]
Stopping DNS Service
Stopping named: .                                          [  OK  ]
Stopping KPASSWD Service
Stopping Kerberos 5 Admin Server:                          [  OK  ]
Stopping KDC Service
Stopping Kerberos 5 KDC:                                   [  OK  ]
Stopping Directory Service
Shutting down dirsrv:
    EXAMPLE-COM...                                         [  OK  ]
    PKI-IPA...                                             [  OK  ]
이 후 ipa 유틸리티를 사용하면 원격 프로시저 호출(RPC)을 통해 새 서버에 연결합니다.

8.2.6. 마스터 CA 서버를 마이그레이션한 후 다음 단계

토폴로지의 각 Red Hat Enterprise Linux 6 서버에 대해 다음을 수행합니다.
  1. rhel7.example.com 에서 복제본 파일을 생성합니다.
    참고
    Red Hat Enterprise Linux 6 서버에서 Red Hat Enterprise Linux 7 복제본을 설치한 후 Identity Management 도메인의 도메인 수준은 자동으로 0으로 설정됩니다.
    Red Hat Enterprise Linux 7.3은 복제본을 더 쉽게 설치 및 관리할 수 있는 방법을 도입했습니다. 이러한 기능을 사용하려면 토폴로지가 도메인 수준 1에 있어야 합니다. 7장. 도메인 수준 표시 및 승격 참조하십시오.
  2. 복제본 파일을 사용하여 다른 Red Hat Enterprise Linux 7 시스템에 새 복제본을 설치합니다.
Red Hat Enterprise Linux 6 서버를 해제하려면 다음을 수행합니다.
  • Red Hat Enterprise Linux 7 서버에서 제거 명령을 실행하여 토폴로지에서 서버를 제거합니다.
중요
클라이언트 구성은 자동으로 업데이트되지 않습니다. IDM 서버를 해제하고 다른 이름으로 새 서버를 구성한 경우 전체 클라이언트 구성을 검토해야 합니다. 특히 다음 파일을 수동으로 업데이트해야 합니다.
  • /etc/openldap/ldap.conf
  • /etc/ipa/default.conf
  • /etc/sssd/sssd.conf

9장. ID 관리 백업 및 복원

Red Hat Enterprise Linux Identity Management는 서버가 올바르게 수행하지 않거나 데이터 손실이 발생하는 경우와 같이 IdM 시스템을 수동으로 백업 및 복원하는 솔루션을 제공합니다. 백업 중에 시스템은 IdM 설정에 대한 정보가 포함된 디렉터리를 생성하고 저장합니다. 복원 중에 이 백업 디렉터리를 사용하여 원래 IdM 설정을 다시 가져올 수 있습니다.
중요
이 장에서 설명하는 백업 및 복원 프로시저는 나머지 복제본의 복제본으로 다시 설치하여 배포에 있는 나머지 서버에서 IdM 서버 그룹의 손실 부분을 다시 빌드할 수 없는 경우에만 사용합니다.
"Id/IPA의 백업 및 복원" 기술 자료 솔루션은 여러 서버 복제본을 유지 관리하여 손실을 방지하는 방법을 설명합니다. 백업 버전에는 일반적으로 오래되고 잠재적으로 오래된 정보가 포함되어 있으므로 동일한 데이터로 기존 복제본을 다시 빌드하는 것이 좋습니다.
백업 및 복원이 방지할 수 있는 잠재적 위협 시나리오는 다음과 같습니다.
  • 시스템에서 치명적인 하드웨어 장애가 발생하여 시스템이 추가로 작동할 수 없게 됩니다. 이 경우 다음을 수행합니다.
    1. 운영 체제를 처음부터 다시 설치합니다.
    2. 동일한 호스트 이름, FQDN(정규화된 도메인 이름) 및 IP 주소로 시스템을 구성합니다.
    3. IdM 패키지 및 원래 시스템에 있는 IdM과 관련된 기타 모든 선택적 패키지를 설치합니다.
    4. IdM 서버의 전체 백업을 복원합니다.
  • 격리된 시스템의 업그레이드가 실패합니다. 운영 체제는 계속 작동하지만 IdM 데이터가 손상되어 IdM 시스템을 알려진 양호한 상태로 복원해야 합니다.
    중요
    위에서 언급한 두 가지와 같은 하드웨어 또는 업그레이드 실패의 경우, 유일한 CA(인증 기관)와 같은 특별한 역할의 복제본 또는 복제본이 손실된 경우에만 백업에서 복원됩니다. 동일한 데이터가 있는 복제본이 계속 존재하는 경우 손실된 복제본을 삭제한 다음 나머지 복제본에서 다시 빌드하는 것이 좋습니다.
  • 예를 들어 항목과 같이 LDAP 콘텐츠에 적절하지 않은 변경이 수행되었으며 되돌리려는 경우입니다. 백업된 LDAP 데이터를 복원하면 IdM 시스템 자체에 영향을 주지 않고 LDAP 항목을 이전 상태로 반환합니다.
복원된 서버는 IdM에 대한 정보의 유일한 소스가 됩니다. 다른 마스터 서버는 복원된 서버에서 다시 초기화됩니다. 마지막 백업 후에 생성된 모든 데이터는 손실됩니다. 따라서 정상적인 시스템 유지 관리를 위해 백업 및 복원 솔루션을 사용해서는 안 됩니다. 가능한 경우 항상 복제본으로 다시 설치하여 손실된 서버를 다시 빌드합니다.
백업 및 복원 기능은 명령줄에서만 관리할 수 있으며 IdM 웹 UI에서 사용할 수 없습니다.

9.1. 전체 서버 백업 및 데이터 전용 백업

IdM은 다음 두 가지 백업 옵션을 제공합니다.
Full-IdM 서버 백업
전체 서버 백업은 모든 IdM 서버 파일과 LDAP 데이터의 백업 사본을 생성하여 독립 실행형 백업으로 만듭니다. IdM은 수백 개의 파일에 영향을 미칩니다. 백업 프로세스 사본이 구성 파일 또는 로그 파일과 같은 전체 디렉토리와 특정 파일이 혼합되어 있으며 IdM 또는 IdM이 의존하는 다양한 서비스와 직접 연결됩니다. 전체 서버 백업은 원시 파일 백업이므로 오프라인으로 수행됩니다. 전체 서버 백업을 수행하는 스크립트는 모든 IdM 서비스를 중지하여 안전한 백업 프로세스를 보장합니다.
전체 서버 백업이 복사하는 파일 및 디렉터리의 전체 목록은 9.1.3절. “백업 중에 복사된 디렉토리 및 파일 목록” 를 참조하십시오.
데이터 전용 백업
데이터 전용 백업은 LDAP 데이터 및 변경 로그의 백업 사본만 생성합니다. 프로세스는 IPA-REALM 인스턴스를 백업하고 여러 백엔드 또는 단일 백엔드만 백업할 수 있습니다. 백엔드에는 IPA 백엔드와 CA Dogtag 백엔드가 포함됩니다. 이 유형의 백업은 LDIF(LDAP 데이터 교환 형식)에 저장된 LDAP 콘텐츠 레코드도 백업합니다. 데이터 전용 백업은 온라인과 오프라인으로 모두 수행할 수 있습니다.
기본적으로 IdM은 생성된 백업을 /var/lib/ipa/backup/ 디렉터리에 저장합니다. 백업이 포함된 하위 디렉터리의 명명 규칙은 다음과 같습니다.
  • ipa-full-Yovn-MM-DD-HH-MM-SS (전체 서버 백업의 GMT 시간대의 HH-MM-SS)
  • ipa-data-Yovn-MM-DD-HH-MM-SS (데이터 전용 백업의 GMT 표준시)

9.1.1. 백업 생성

전체 서버 및 데이터 전용 백업은 항상 root로 실행해야 하는 ipa-backup 유틸리티를 사용하여 생성됩니다.
전체 서버 백업을 생성하려면 ipa-backup 을 실행합니다.
중요
프로세스가 오프라인으로 실행되어야 하므로 전체 서버 백업을 수행하면 모든 IdM 서비스가 중지됩니다. 백업이 완료되면 IdM 서비스가 다시 시작됩니다.
데이터 전용 백업을 생성하려면 ipa-backup --data 명령을 실행합니다.
ipa-backup 에 몇 가지 추가 옵션을 추가할 수 있습니다.
  • --online 은 온라인 백업을 수행합니다. 이 옵션은 데이터 전용 백업에서만 사용할 수 있습니다.
  • --logs 에는 백업에 IdM 서비스 로그 파일이 포함되어 있습니다.
ipa-backup 사용에 대한 자세한 내용은 ipa-backup(1) 매뉴얼 페이지를 참조하십시오.

9.1.1.1. 백업 중 볼륨 Insufficient Space onvolved During Backup

이 섹션에서는 IdM 백업 프로세스와 관련된 디렉터리가 사용 가능한 공간이 충분하지 않은 볼륨에 저장된 경우 문제를 해결하는 방법을 설명합니다.

/var/lib/ipa/backup/을 포함하는 볼륨의 공간이 충분하지 않습니다.

사용 가능한 공간이 충분하지 않은 볼륨에 /var/lib/ipa/backup/ 디렉터리가 저장된 경우 백업을 생성할 수 없습니다. 이 문제를 해결하려면 다음 해결 방법 중 하나를 사용하십시오.
  • 다른 볼륨에 디렉터리를 만들고 /var/lib/ipa/backup/ 에 연결합니다. 예를 들어 /home 이 충분한 여유 공간이 있는 다른 볼륨에 저장된 경우:
    1. /home/idm/backup/ 와 같은 디렉토리를 만듭니다.
      # mkdir -p /home/idm/backup/
    2. 다음 권한을 디렉터리로 설정합니다.
      # chown root:root /home/idm/backup/
      # chmod 700 /home/idm/backup/
    3. /var/lib/ipa/backup/ 에 기존 백업이 포함된 경우 새 디렉터리로 이동합니다.
      # mv /var/lib/ipa/backup/* /home/idm/backup/
    4. /var/lib/ipa/backup/ 디렉토리를 삭제합니다.
      # rm -rf /var/lib/ipa/backup/
    5. /home/idm/backup/ 디렉토리에 대한 /var/lib/ipa/backup/ 링크를 만듭니다.
      # ln -s /home/idm/backup/ /var/lib/ipa/backup/
  • 다른 볼륨에 저장된 디렉터리를 /var/lib/ipa/backup/ 에 마운트합니다. 예를 들어 /home 이 충분한 여유 공간이 있는 다른 볼륨에 저장된 경우 /home/idm/backup/ 을 생성하고 /var/lib/ipa/backup/ 에 마운트합니다.
    1. /home/idm/backup/ 디렉토리를 만듭니다.
      # mkdir -p /home/idm/backup/
    2. 다음 권한을 디렉터리로 설정합니다.
      # chown root:root /home/idm/backup/
      # chmod 700 /home/idm/backup/
    3. /var/lib/ipa/backup/ 에 기존 백업이 포함된 경우 새 디렉터리로 이동합니다.
      # mv /var/lib/ipa/backup/* /home/idm/backup/
    4. /home/idm/backup//var/lib/ipa/backup/ 에 마운트합니다.
      # mount -o bind /home/idm/backup/ /var/lib/ipa/backup/
    5. 시스템이 부팅될 때 /home/idm/backup//var/lib/ipa/backup/ 에 자동으로 마운트하려면 /etc/fstab 파일에 다음을 추가합니다.
      /home/idm/backup/     /var/lib/ipa/backup/     none     bind     0 0

/tmp를 포함하는 볼륨의 공간이 충분하지 않음

/tmp 디렉토리에서 사용 가능한 공간이 부족하여 백업이 실패하는 경우 TMPDIR 환경 변수를 사용하여 백업 중에 생성할 준비 파일의 위치를 변경합니다.
# TMPDIR=/path/to/backup ipa-backup

9.1.2. 백업 암호화

GPG(GNU Privacy Guard) 암호화를 사용하여 IdM 백업을 암호화할 수 있습니다.
GPG 키를 생성하려면 다음을 수행합니다.
  1. 키 세부 정보가 포함된 keygen 파일을 만듭니다(예: cat >keygen="EOF )을 실행하고 명령줄에서 필요한 암호화 세부 정보를 파일에 제공합니다.
    [root@server ~]# cat >keygen <<EOF
    > %echo Generating a standard key
    > Key-Type: RSA
    > Key-Length:2048
    > Name-Real: IPA Backup
    > Name-Comment: IPA Backup
    > Name-Email: root@example.com
    > Expire-Date: 0
    > %pubring /root/backup.pub
    > %secring /root/backup.sec
    > %commit
    > %echo done
    > EOF
    [root@server ~]#
  2. backup 이라는 새 키 쌍을 생성하고 keygen 의 내용을 명령에 제공합니다. 다음 예제에서는 경로 이름이 /root/backup.sec/root/backup.pub 인 키 쌍을 생성합니다.
    [root@server ~]# gpg --batch --gen-key keygen
    [root@server ~]# gpg --no-default-keyring --secret-keyring /root/backup.sec \
    		     --keyring /root/backup.pub --list-secret-keys
GPG 암호화 백업을 만들려면 다음 옵션을 제공하여 생성된 백업 키를 ipa-backup 에 전달합니다.
  • --GP G , 암호화된 백업을 수행하기 위해 ipa-backup 에 지시합니다.
  • --GPG-keyring=GPG_KEYRING 은 파일 확장자 없이 GPG 키링에 대한 전체 경로를 제공합니다.
예를 들어 다음과 같습니다.
[root@server ~]# ipa-backup --gpg --gpg-keyring=/root/backup
참고
gpg2 유틸리티를 사용하여 GPG 키를 생성하는 경우 시스템에 외부 프로그램이 작동해야 하므로 문제가 발생할 수 있습니다. 이 경우 콘솔에서 키를 순전히 생성하려면 키를 생성하기 전에 pinentry-program /usr/bin/pinentry-curses 행을 .gnupg/gpg-agent.conf 파일에 추가하십시오.

9.1.3. 백업 중에 복사된 디렉토리 및 파일 목록

디렉터리:
/usr/share/ipa/html
/root/.pki
/etc/pki-ca
/etc/pki/pki-tomcat
/etc/sysconfig/pki
/etc/httpd/alias
/var/lib/pki
/var/lib/pki-ca
/var/lib/ipa/sysrestore
/var/lib/ipa-client/sysrestore
/var/lib/ipa/dnssec
/var/lib/sss/pubconf/krb5.include.d/
/var/lib/authconfig/last
/var/lib/certmonger
/var/lib/ipa
/var/run/dirsrv
/var/lock/dirsrv
파일:
/etc/named.conf
/etc/named.keytab
/etc/resolv.conf
/etc/sysconfig/pki-ca
/etc/sysconfig/pki-tomcat
/etc/sysconfig/dirsrv
/etc/sysconfig/ntpd
/etc/sysconfig/krb5kdc
/etc/sysconfig/pki/ca/pki-ca
/etc/sysconfig/ipa-dnskeysyncd
/etc/sysconfig/ipa-ods-exporter
/etc/sysconfig/named
/etc/sysconfig/ods
/etc/sysconfig/authconfig
/etc/ipa/nssdb/pwdfile.txt
/etc/pki/ca-trust/source/ipa.p11-kit
/etc/pki/ca-trust/source/anchors/ipa-ca.crt
/etc/nsswitch.conf
/etc/krb5.keytab
/etc/sssd/sssd.conf
/etc/openldap/ldap.conf
/etc/security/limits.conf
/etc/httpd/conf/password.conf
/etc/httpd/conf/ipa.keytab
/etc/httpd/conf.d/ipa-pki-proxy.conf
/etc/httpd/conf.d/ipa-rewrite.conf
/etc/httpd/conf.d/nss.conf
/etc/httpd/conf.d/ipa.conf
/etc/ssh/sshd_config
/etc/ssh/ssh_config
/etc/krb5.conf
/etc/ipa/ca.crt
/etc/ipa/default.conf
/etc/dirsrv/ds.keytab
/etc/ntp.conf
/etc/samba/smb.conf
/etc/samba/samba.keytab
/root/ca-agent.p12
/root/cacert.p12
/var/kerberos/krb5kdc/kdc.conf
/etc/systemd/system/multi-user.target.wants/ipa.service
/etc/systemd/system/multi-user.target.wants/sssd.service
/etc/systemd/system/multi-user.target.wants/certmonger.service
/etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.service
/var/run/ipa/services.list
/etc/opendnssec/conf.xml
/etc/opendnssec/kasp.xml
/etc/ipa/dnssec/softhsm2.conf
/etc/ipa/dnssec/softhsm_pin_so
/etc/ipa/dnssec/ipa-ods-exporter.keytab
/etc/ipa/dnssec/ipa-dnskeysyncd.keytab
/etc/idm/nssdb/cert8.db
/etc/idm/nssdb/key3.db
/etc/idm/nssdb/secmod.db
/etc/ipa/nssdb/cert8.db
/etc/ipa/nssdb/key3.db
/etc/ipa/nssdb/secmod.db
로그 파일 및 디렉토리:
/var/log/pki-ca
/var/log/pki/
/var/log/dirsrv/slapd-PKI-IPA
/var/log/httpd
/var/log/ipaserver-install.log
/var/log/kadmind.log
/var/log/pki-ca-install.log
/var/log/messages
/var/log/ipaclient-install.log
/var/log/secure
/var/log/ipaserver-uninstall.log
/var/log/pki-ca-uninstall.log
/var/log/ipaclient-uninstall.log
/var/named/data/named.run

9.2. 백업 복원

ipa-backup 을 사용하여 생성된 백업이 있는 디렉터리가 있는 경우 IdM 서버 또는 LDAP 콘텐츠를 백업을 수행한 상태로 복원할 수 있습니다. 백업이 원래 생성된 호스트와 다른 호스트에서 백업을 복원할 수 없습니다.
참고
IdM 서버를 설치 제거해도 이 서버의 백업이 자동으로 제거되지는 않습니다.

9.2.1. 전체 서버 또는 데이터 전용 백업에서 복원

중요
전체 서버 복원을 수행하기 전에 서버를 제거하는 것이 좋습니다.
전체 서버 및 데이터 전용 백업은 항상 root로 실행해야 하는 ipa-restore 유틸리티를 사용하여 복원됩니다. 백업을 명령에 전달합니다.
  • 기본 /var/lib/ipa/backup/ 디렉토리에 있는 경우 백업이 포함된 디렉터리 이름만 전달합니다.
  • 백업이 포함된 디렉터리가 기본 디렉터리에 없는 경우 백업에 전체 경로를 전달합니다. 예를 들어 다음과 같습니다.
    [root@server ~]# ipa-restore /path/to/backup
ipa-restore 유틸리티는 백업 디렉터리에 포함된 백업 유형을 자동으로 감지하고 기본적으로 동일한 유형의 복원을 수행합니다.
ipa-restore 에 다음 옵션을 추가할 수 있습니다.
  • --data 는 전체 서버 백업에서 데이터 전용 복원(즉, 전체 서버 백업이 포함된 백업 디렉터리에서 LDAP 데이터 구성 요소만 복원함)을 수행합니다.
  • --online 은 데이터 전용 복원 온라인에서 LDAP 데이터를 복원
  • --instance 는 복원되는 389 DS 인스턴스를 지정합니다. Red Hat Enterprise Linux 7의 IdM은 IPA-REALM 인스턴스만 사용하지만, 예를 들어 별도의 인스턴스가 있는 시스템에 백업을 생성할 수 있습니다. 이 경우 --instance 를 사용하면 IPA-REALM 만 복원할 수 있습니다. 예를 들어 다음과 같습니다.
    [root@server ~]# ipa-restore --instance=IPA-REALM /path/to/backup
    이 옵션은 데이터 전용 복원을 수행하는 경우에만 사용할 수 있습니다.
  • --backend 는 복원되는 백엔드를 지정합니다. 이 옵션 없이 ipa-restore 는 검색한 모든 백엔드를 복원합니다. 가능한 백엔드를 정의하는 인수는 userRoot 입니다. 이 인수는 IPA 데이터 백엔드를 복원하고 CA 백엔드를 복원하는 ipaca 입니다.
    이 옵션은 데이터 전용 복원을 수행하는 경우에만 사용할 수 있습니다.
  • --no-logs 는 로그 파일을 복원하지 않고 백업을 복원합니다.
IdM 마스터에서 인증 문제를 방지하려면 복원 후 SSSD 캐시를 지웁니다.
  1. SSSD 서비스를 중지합니다.
    [root@server ~]# systemctl stop sssd
  2. SSSD에서 캐시된 컨텐츠를 모두 제거합니다.
    [root@server ~]# find /var/lib/sss/ ! -type d | xargs rm -f
  3. SSSD 서비스를 시작합니다.
    [root@server ~]# systemctl start sssd
참고
백업에서 복원한 후 시스템을 재부팅하는 것이 좋습니다.
ipa-restore 사용에 대한 자세한 내용은 ipa-restore(1) 매뉴얼 페이지를 참조하십시오.

9.2.2. 여러 마스터 서버로 복원

다중 마스터 복제 환경에서 IdM을 복원하는 방법에 대한 자세한 내용은 “IdM의 백업 및 복원” 을 참조하십시오.

9.2.3. 암호화된 백업에서 복원

GPG로 암호화된 백업에서 복원하려면 --gpg-keyring 옵션을 사용하여 개인 키 및 공개 키에 대한 전체 경로를 제공하십시오. 예를 들어 다음과 같습니다.
[root@server ~]# ipa-restore --gpg-keyring=/root/backup /path/to/backup

10장. IdM 사용자를 위한 액세스 제어 정의

액세스 제어는 머신, 서비스 또는 항목과 같은 특정 리소스에 액세스할 수 있는 사용자와 수행할 수 있는 작업 종류를 정의하는 일련의 보안 기능입니다. Identity Management는 여러 액세스 제어 영역을 제공하여 어떤 종류의 액세스 권한이 부여되고 누구에게 부여되었는지 명확하게 이해할 수 있도록 합니다. 이 과정의 일환으로 Identity Management는 도메인 내의 리소스에 대한 액세스 제어와 IdM 구성 자체에 대한 액세스 제어를 구분하는 역할을 합니다.
이 장에서는 IdM 내에 있는 사용자가 IdM 서버 및 기타 IdM 사용자에게 사용할 수 있는 다양한 내부 액세스 제어 메커니즘에 대해 자세히 설명합니다.

10.1. IdM 항목 액세스 제어

액세스 제어는 다른 사용자 또는 오브젝트에 대한 작업을 수행하도록 사용자에게 부여된 권한 또는 권한을 정의합니다.
Identity Management 액세스 제어 구조는 표준 LDAP 액세스 제어를 기반으로 합니다. IdM 서버 내의 액세스는 다른 IdM 엔티티에 액세스할 수 있는 백엔드 디렉터리 서버 인스턴스에 저장된 IdM 사용자를 기반으로 하며, 디렉터리 서버 인스턴스의 LDAP 항목으로 저장됩니다.
ACI(액세스 제어 명령)에는 다음 세 부분이 있습니다.
행위자
이 엔터티는 특정 작업을 수행할 수 있는 권한이 부여된 엔터티입니다. LDAP 액세스 제어 모델에서는 사용자가 인 사용자를 정의하고 특정 시간 또는 특정 시스템으로 시도를 제한하는 등 선택적으로 바인딩 시도에 대한 다른 제한이 필요할 수 있기 때문에 바인딩 규칙 이라고 합니다.
대상
이는 행위자가 작업을 수행할 수 있는 항목을 정의합니다.
작업 유형
작업 유형 - 마지막 부분에서는 사용자가 수행할 수 있는 작업 종류를 결정합니다. 가장 일반적인 작업은 add, delete, write, read, search입니다. Identity Management에서 모든 사용자에게 IdM 도메인의 모든 항목에 대한 읽기 및 검색 권한이 암시적으로 부여되며 암호 및 Kerberos 키와 같은 중요한 속성에 대해서만 제한이 있습니다. 익명 사용자는 sudo 규칙 및 호스트 기반 액세스 제어와 같은 보안 관련 구성이 표시되지 않도록 제한됩니다.
작업을 시도하면 IdM 클라이언트가 가장 먼저 수행하는 작업은 바인딩 작업의 일부로 사용자 자격 증명을 보내는 것입니다. 백엔드 Directory Server는 해당 사용자 자격 증명을 확인한 다음 사용자 계정을 확인하여 사용자가 요청한 작업을 수행할 수 있는 권한이 있는지 확인합니다.

10.1.1. Identity Management에서 액세스 제어 방법

액세스 제어 규칙을 간단하고 명확하게 구현하기 위해 Identity Management는 액세스 제어 정의를 세 가지 범주로 나눕니다.
셀프 서비스 규칙
셀프 서비스 규칙: 사용자가 자신의 개인 항목에 수행할 수 있는 작업을 정의합니다. 액세스 제어 유형은 항목 내의 속성에 대한 쓰기 권한만 허용합니다. 항목 자체에 대한 추가 또는 삭제 작업은 허용하지 않습니다.
위임 규칙
위임 규칙 - 특정 사용자 그룹이 다른 사용자 그룹의 사용자에 대해 특정 속성에 대해 쓰기(편집) 작업을 수행할 수 있도록 합니다. 셀프 서비스 규칙과 마찬가지로 이 형태의 액세스 제어 규칙은 특정 특성의 값 편집으로 제한됩니다. 전체 항목을 추가 또는 제거하거나 지정되지 않은 속성에 대한 제어 권한을 부여할 수 없습니다.
역할 기반 액세스 제어
역할 기반 액세스 제어 - 특수 액세스 제어 그룹을 생성하면 IdM 도메인의 모든 유형의 엔티티에 대해 훨씬 광범위한 권한이 부여됩니다. 역할을 편집, 추가 및 삭제 권한을 부여할 수 있습니다. 즉, 선택한 특성이 아닌 전체 항목에 대한 전체 제어 권한을 부여할 수 있습니다.
일부 역할은 ID 관리 내에서 이미 생성 및 사용할 수 있습니다. 호스트, 자동 마운트 구성, 넷 그룹, DNS 설정, IdM 구성과 같은 특정 방식으로 모든 유형의 항목을 관리하기 위해 특수 역할을 생성할 수 있습니다.

10.2. 셀프 서비스 설정 정의

셀프 서비스 액세스 제어 규칙은 엔터티에서 자체적으로 수행할 수 있는 작업을 정의합니다. 이러한 규칙은 사용자(또는 기타 IdM 엔티티)가 개인 항목에서 편집할 수 있는 속성만 정의합니다.

10.2.1. 웹 UI에서 셀프 서비스 규칙 생성

  1. 상단 메뉴의 IPA Server 탭에서 역할 기반 액세스 제어셀프 서비스 권한 을 선택합니다.
  2. 셀프 서비스 액세스 제어 지침 목록의 맨 위에서 추가 를 클릭합니다.

    그림 10.1. 현재 셀프 서비스 규칙 추가

    현재 셀프 서비스 규칙 추가
  3. 팝업 창에 규칙의 이름을 입력합니다. 스페이스는 허용됩니다.

    그림 10.2. 셀프 서비스 규칙 추가 양식

    셀프 서비스 규칙 추가 양식
  4. ACI에서 사용자를 편집하도록 허용하는 속성별로 확인란을 선택합니다.
  5. Add 버튼을 클릭하여 새 셀프 서비스 ACI를 저장합니다.

10.2.2. 명령줄에서 셀프 서비스 규칙 생성

selfservice-add 명령을 사용하여 새 셀프 서비스 규칙을 추가할 수 있습니다. 다음 두 가지 옵션이 필요합니다.
  • ACI 권한 부여 - 쓰기, 추가 또는 삭제와 같은 권한을 설정하는 --permissions
  • 이 ACI에서 권한을 부여하는 속성의 전체 목록을 제공하는 --attrs.
[jsmith@server ~]$ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname --attrs=displayname --attrs=title --attrs=initials
-----------------------------------------------------------
Added selfservice "Users can manage their own name details"
-----------------------------------------------------------
    Self-service name: Users can manage their own name details
    Permissions: write
    Attributes: givenname, displayname, title, initials

10.2.3. 셀프 서비스 규칙 편집

웹 UI의 셀프 서비스 항목에서 편집할 수 있는 유일한 요소는 ACI에 포함된 속성 목록입니다. 확인란을 선택하거나 선택 해제할 수 있습니다.

그림 10.3. 셀프 서비스 편집 페이지

셀프 서비스 편집 페이지
명령행을 사용하면 ipa selfservice-mod 명령을 사용하여 셀프 서비스 규칙을 편집합니다. at trs 옵션은 지원되는 속성의 이전 목록이 무엇이든 덮어 쓰므로 항상 새 속성과 함께 전체 속성 목록을 포함합니다.
[jsmith@server ~]$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=surname
--------------------------------------------------------------
Modified selfservice "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials
중요
기존 항목을 포함하여 셀프 서비스 규칙을 수정할 때 모든 속성을 포함합니다.

10.3. 사용자 권한 위임

위임은 한 그룹의 사용자가 다른 사용자 그룹의 항목을 관리할 수 있는 권한이 할당된다는 점에서 역할과 매우 유사합니다. 그러나 위임된 권한은 전체 액세스의 셀프 서비스 규칙과 훨씬 더 유사하지만 전체 항목이 아닌 특정 사용자 속성에만 적용됩니다. 또한 위임된 권한의 그룹은 액세스 제어를 위해 특별히 생성된 역할 대신 기존 IdM 사용자 그룹입니다.

10.3.1. 웹 UI에서 사용자 그룹에 대한 액세스 위임

  1. 상단 메뉴의 IPA Server 탭에서 역할 기반 액세스 제어위임을 선택합니다.
  2. 위임 액세스 제어 지침 목록의 맨 위에 있는 추가 링크를 클릭합니다.

    그림 10.4. 새 위임 추가

    새 위임 추가
  3. 새 위임 ACI의 이름을 지정합니다.
  4. 지정된 속성(읽기)을 볼 수 있는 권한이 있는지 여부를 확인란을 선택하여 사용 권한을 설정하고 주어진 속성을 추가 또는 변경합니다(쓰기).
    일부 사용자는 정보를 볼 필요가 있지만 편집할 수는 없어야 합니다.
  5. 사용자 그룹 드롭다운 메뉴에서 사용자 그룹의 사용자 항목에 대한 권한이 부여된 그룹을 선택합니다.

    그림 10.5. 위임 추가 양식

    위임 추가 양식
  6. Member 사용자 그룹 드롭다운 메뉴에서 위임 그룹 멤버에서 항목을 편집할 수 있는 그룹을 선택합니다.
  7. 특성 상자에서 member 사용자 그룹이 권한이 부여되는 특성별로 확인란을 선택합니다.
  8. Add 버튼을 클릭하여 새 위임 ACI를 저장합니다.

10.3.2. 명령줄에서 사용자 그룹에 대한 액세스 위임

새로운 위임 액세스 제어 규칙이 delegation-add 명령을 사용하여 추가됩니다. 다음과 같은 세 가지 필수 인수가 있습니다.
  • --group - 사용자 그룹에 있는 사용자 항목에 대한 권한을 부여받고 있는 그룹입니다.
  • --membergroup, group w those 항목은 위임 그룹의 구성원이 편집할 수 있습니다.
  • --attrs: 멤버 그룹의 사용자가 보거나 편집할 수 있는 속성입니다.
예를 들어 다음과 같습니다.
$ ipa delegation-add "basic manager attrs" --attrs=manager --attrs=title --attrs=employeetype --attrs=employeenumber --group=engineering_managers --membergroup=engineering
--------------------------------------
Added delegation "basic manager attrs"
--------------------------------------
  Delegation name: basic manager attrs
  Permissions: write
  Attributes: manager, title, employeetype, employeenumber
  Member user group: engineering
  User group: engineering_managers
위임 규칙은 delegation-mod 명령을 사용하여 편집합니다. at trs 옵션은 지원되는 속성의 이전 목록이 무엇이든 덮어 쓰므로 항상 새 속성과 함께 전체 속성 목록을 포함합니다.
[jsmith@server ~]$ ipa delegation-mod "basic manager attrs" --attrs=manager --attrs=title --attrs=employeetype --attrs=employeenumber --attrs=displayname
-----------------------------------------
Modified delegation "basic manager attrs"
-----------------------------------------
  Delegation name: basic manager attrs
  Permissions: write
  Attributes: manager, title, employeetype, employeenumber, displayname
  Member user group: engineering
  User group: engineering_managers
중요
기존 항목을 포함하여 위임 규칙을 수정할 때 모든 특성을 포함합니다.

10.4. 역할 기반 액세스 제어 정의

역할 기반 액세스 제어는 셀프 서비스 및 위임 액세스 제어에 비해 사용자에게 매우 다른 종류의 권한을 부여합니다. 역할 기반 액세스 제어는 기본적으로 관리되므로 항목을 수정할 수 있습니다.
역할 기반 액세스 제어에는 권한, 권한 , 역할 의 세 가지 부분이 있습니다. 권한은 하나 이상의 권한으로 구성되며 역할은 하나 이상의 권한으로 구성됩니다.
  • 권한은 특정 작업 또는 작업 세트(예: 읽기, 쓰기, 추가 또는 삭제)와 해당 작업이 적용되는 IdM LDAP 디렉터리 내의 대상 항목을 정의합니다. 권한은 블록을 구성합니다. 필요에 따라 여러 권한에 할당할 수 있습니다.
    IdM 권한을 사용하면 어떤 사용자가 어떤 오브젝트에 어떤 오브젝트에 액세스할 수 있는지와 해당 오브젝트의 속성을 제어할 수 있습니다. IdM을 사용하면 개별 속성을 허용 목록화하거나 블랙리스트로 지정하거나 사용자, 그룹 또는 sudo와 같은 특정 IdM 기능의 전체 가시성을 모든 익명 사용자, 인증된 사용자 또는 특정 권한 있는 사용자에게 변경할 수 있습니다. 권한에 대한 이 유연한 접근 방식은 예를 들어 관리자가 특정 섹션으로만 사용자 또는 그룹 액세스를 제한하려는 경우, 이러한 사용자나 그룹에만 액세스하고 다른 섹션을 완전히 숨기도록 하려는 시나리오에서 유용합니다.
  • 권한 은 역할에 적용할 수 있는 권한 그룹입니다. 예를 들어 자동 마운트 위치를 추가, 편집, 삭제할 수 있는 권한을 생성할 수 있습니다. 그런 다음 해당 권한을 FTP 서비스 관리와 관련된 다른 권한과 결합할 수 있으며, 파일 시스템 관리와 관련된 단일 권한을 만드는 데 사용할 수 있습니다.
    참고
    Red Hat Identity Management의 컨텍스트에서 권한이 있으면 어떤 권한과 역할이 생성되는지에 대한 원자적 액세스 제어 단위가 매우 특수한 의미를 갖습니다. Red Hat Identity Management에는 일시적으로 추가 권한을 얻는 일반 사용자의 개념으로 권한 에스컬레이션 이 존재하지 않습니다. RBAC(역할 기반 액세스 제어)를 사용하여 사용자에게 권한이 할당됩니다. 사용자는 액세스 권한을 부여하는 역할을 갖고 있거나 그렇지 않습니다.
    사용자 이외에 권한은 사용자 그룹, 호스트, 호스트 그룹 및 네트워크 서비스에도 할당됩니다. 이 방법을 사용하면 특정 네트워크 서비스를 통해 호스트 집합에서 일련의 사용자에 의한 작업을 세부적으로 제어할 수 있습니다.
  • 역할은 역할에 지정된 사용자가 소유한 권한 목록입니다.
    중요
    역할은 허용된 작업을 분류하는 데 사용됩니다. 권한 분리를 구현하거나 권한 에스컬레이션으로부터 보호하는 도구로 사용되지 않습니다.
완전히 새로운 권한을 생성하고 기존 권한 또는 새 권한을 기반으로 새 권한을 만들 수 있습니다. Red Hat Identity Management는 다음과 같은 다양한 사전 정의 역할을 제공합니다.

표 10.1. Red Hat Identity Management에서 사전 정의된 역할

Role 권한 Description
헬프데스크
사용자 수정 및 암호 재설정, 그룹 구성원 수정 간단한 사용자 관리 작업 수행을 담당합니다.
IT 보안 전문가
Netgroups 관리자, HBAC 관리자, Sudo 관리자 호스트 기반 액세스 제어, sudo 규칙 등의 보안 정책을 관리합니다.
IT 전문가
호스트 관리자, 호스트 그룹 관리자, 서비스 관리자, 자동 마운트 관리자 호스트 관리 담당
보안 설계자
위임 관리자, 복제 관리자, IPA 작성 구성, 암호 정책 관리자 ID 관리 환경 관리, 신뢰 생성, 복제 계약 생성 담당
사용자 관리자
사용자 관리자, 그룹 관리자, 사용자 관리자 단계 사용자 및 그룹 생성 담당

10.4.1. 역할

10.4.1.1. 웹 UI에서 역할 생성

  1. 상단 메뉴에서 IPA Server 탭을 열고 역할 기반 액세스 제어를 선택합니다.
  2. 역할 기반 액세스 제어 지침 목록의 맨 위에 있는 Add 링크를 클릭합니다.

    그림 10.6. 새 역할 추가

    새 역할 추가
  3. 역할 이름과 설명을 입력합니다.

    그림 10.7. 역할 추가 양식

    역할 추가 양식
  4. 추가 및 편집 버튼을 클릭하여 새 역할을 저장하고 구성 페이지로 이동합니다.
  5. Users 탭 상단에서 또는 그룹을 추가할 때 사용자 그룹 탭에서 추가를 클릭합니다.

    그림 10.8. 사용자 추가

    사용자 추가
  6. 왼쪽에서 사용자를 선택하고 > 버튼 을 사용하여 Prospective 열로 이동합니다.

    그림 10.9. 사용자 선택

    사용자 선택
  7. Privileges (권한) 탭 상단에서 Add 를 클릭합니다.

    그림 10.10. 권한 추가

    권한 추가
  8. 왼쪽에서 권한을 선택하고 &gt ; 버튼을 사용하여 Prospective 열로 이동합니다.

    그림 10.11. 권한 선택

    권한 선택
  9. Add 버튼을 클릭하여 저장합니다.

10.4.1.2. 명령줄에서 역할 생성

  1. 새 역할을 추가합니다.
    [root@server ~]# kinit admin
    [root@server ~]# ipa role-add --desc="User Administrator" useradmin
      ------------------------
      Added role "useradmin"
      ------------------------
      Role name: useradmin
      Description: User Administrator
  2. 필요한 권한을 역할에 추가합니다.
    [root@server ~]# ipa role-add-privilege --privileges="User Administrators" useradmin
      Role name: useradmin
      Description: User Administrator
      Privileges: user administrators
      ----------------------------
      Number of privileges added 1
    ----------------------------
    
  3. 필요한 그룹을 역할에 추가합니다. 이 경우 이미 존재하는 단일 그룹 useradmins 만 추가하고 있습니다.
    [root@server ~]# ipa role-add-member --groups=useradmins useradmin
      Role name: useradmin
      Description: User Administrator
      Member groups: useradmins
      Privileges: user administrators
      -------------------------
      Number of members added 1
    -------------------------
    

10.4.2. 권한

10.4.2.1. 웹 UI에서 새 권한 생성

  1. 상단 메뉴에서 IPA Server 탭을 열고 역할 기반 액세스 제어를 선택합니다.
  2. Permissions 작업 링크를 선택합니다.

    그림 10.12. 권한 작업

    권한 작업
  3. 권한 목록 상단에 있는 Add (추가) 버튼을 클릭합니다.

    그림 10.13. 새 권한 추가

    새 권한 추가
  4. 표시되는 양식에 새 권한의 속성을 정의합니다.

    그림 10.14. 권한 추가 양식

    권한 추가 양식
  5. 양식 아래의 추가 버튼을 클릭하여 권한을 저장합니다.
다음 권한 속성을 지정할 수 있습니다.
  1. 새 권한의 이름을 입력합니다.
  2. 적절한 바인딩 규칙 유형을 선택합니다.
    • 권한은 기본 권한 유형이며 권한 및 역할을 통해 액세스 권한을 부여합니다.
    • 모두 인증된 모든 사용자에게 권한이 적용되도록 지정합니다.
    • 익명 은 인증되지 않은 사용자를 포함하여 모든 사용자에게 권한이 적용되도록 지정합니다.
    참고
    기본이 아닌 바인딩 규칙 유형의 권한을 권한에 추가할 수 없습니다. 또한 권한에 이미 있는 권한이 기본이 아닌 바인딩 규칙 유형으로 설정할 수 없습니다.
  3. 권한 부여 권한에 부여된 권한을 선택합니다.
  4. 권한의 대상 항목을 식별하는 방법을 정의합니다.
    • type은 사용자, 호스트 또는 서비스와 같은 항목 유형을 지정합니다. Type 설정 값을 선택하는 경우 해당 항목 유형에 대해 이 ACI를 통해 액세스할 수 있는 모든 가능한 속성 목록이 효과 속성 아래에 표시됩니다.
      Type 정의에서는 SubtreeTarget DN 을 사전 정의된 값 중 하나로 설정합니다.
    • sub tree 는 하위 트리를 지정합니다. 이 하위 트리 항목 아래의 모든 항목이 대상입니다. Subtree 에서 와일드카드 또는 존재하지 않는 도메인 이름(DN)을 허용하지 않으므로 기존 하위 트리 항목을 제공합니다. 예를 들어 다음과 같습니다.
      cn=automount,dc=example,dc=com
    • 추가 대상 필터는 LDAP 필터를 사용하여 권한이 적용되는 항목을 식별합니다. 필터는 유효한 LDAP 필터일 수 있습니다. 예를 들면 다음과 같습니다.
      (!(objectclass=posixgroup))
      IdM은 지정된 필터의 유효성을 자동으로 검사합니다. 잘못된 필터를 입력하면 IdM에서 권한을 저장하려고 시도한 후 이에 대해 경고합니다.
    • 대상 DN 은 도메인 이름(DN)을 지정하고 와일드카드를 수락합니다. 예를 들어 다음과 같습니다.
      uid=*,cn=users,cn=accounts,dc=com
    • 그룹 멤버 는 대상 필터를 지정된 그룹의 구성원으로 설정합니다.
    필터 설정을 작성하고 추가 를 클릭하면 IdM에서 필터를 검증합니다. 모든 권한 설정이 올바르면 IdM에서 검색을 수행합니다. 일부 권한 설정이 올바르지 않으면 IdM에서 잘못 설정된 설정을 알려주는 메시지를 표시합니다.
  5. Type 을 설정하는 경우 사용 가능한 ACI 특성 목록에서 효과 특성을 선택합니다. Type 을 사용하지 않은 경우 Effective attributes 필드에 작성하여 속성을 수동으로 추가합니다. 한 번에 단일 속성을 추가합니다. 속성을 여러 개 추가하려면 추가를 클릭하여 다른 입력 필드를 추가합니다.
    중요
    권한의 속성을 설정하지 않으면 기본적으로 모든 속성이 포함됩니다.

10.4.2.2. 명령줄에서 새 권한 생성

새 권한을 추가하려면 ipa permission-add 명령을 실행합니다. 해당 옵션을 제공하여 권한의 속성을 지정합니다.
  • 권한의 이름을 제공합니다. 예를 들어 다음과 같습니다.
    [root@server ~]# ipa permission-add "dns admin permission"
  • --bindtype 은 바인딩 규칙 유형을 지정합니다. 이 옵션은 모든,익명, 권한 인수를 허용합니다. 예를 들어 다음과 같습니다.
    --bindtype=all
    --bindtype 을 사용하지 않으면 유형이 자동으로 기본 권한 값으로 설정됩니다.
    참고
    기본이 아닌 바인딩 규칙 유형의 권한을 권한에 추가할 수 없습니다. 또한 권한에 이미 있는 권한이 기본이 아닌 바인딩 규칙 유형으로 설정할 수 없습니다.
  • --permissions 는 권한에서 부여한 권한을 나열합니다. 여러 --permissions 옵션을 사용하거나 중괄호 내부의 쉼표로 구분된 목록에 옵션을 나열하여 여러 속성을 설정할 수 있습니다. 예를 들어 다음과 같습니다.
    --permissions=read --permissions=write
    --permissions={read,write}
  • --attrs 는 권한이 부여된 속성 목록을 제공합니다. 여러 --attrs 옵션을 사용하거나 중괄호의 쉼표로 구분된 목록에 옵션을 나열하여 여러 속성을 설정할 수 있습니다. 예를 들어 다음과 같습니다.
    --attrs=description --attrs=automountKey
    --attrs={description,automountKey}
    --attrs 와 함께 제공되는 속성은 존재해야 하며 지정된 오브젝트 유형에 대해 속성이 허용되어야 합니다. 그렇지 않으면 명령이 스키마 구문 오류로 인해 실패합니다.
  • --type 은 사용자, 호스트 또는 서비스와 같은 항목 오브젝트 유형을 정의합니다. 각 유형에는 허용된 속성 세트가 있습니다. 예를 들어 다음과 같습니다.
    [root@server ~]# ipa permission-add "manage service" --permissions=all --type=service --attrs=krbprincipalkey --attrs=krbprincipalname --attrs=managedby
  • --subtree 는 하위 트리 항목을 제공합니다. 그러면 filter는 이 하위 트리 항목 아래의 모든 항목을 대상으로 합니다. 기존 하위 트리 항목을 제공합니다. --subtree 는 와일드카드 또는 존재하지 않는 도메인 이름(DN)을 허용하지 않습니다. 디렉터리에 DN을 포함합니다.
    IdM은 단순화된 플랫 디렉터리 트리 구조를 사용하므로 --subtree 를 사용하여 다른 구성의 컨테이너 또는 상위 항목인 autoscale location과 같은 일부 유형의 항목을 대상으로 할 수 있습니다. 예를 들어 다음과 같습니다.
    [root@server ~]# ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com" --permissions=write --attrs=automountmapname --attrs=automountkey --attrs=automountInformation
    --type--subtree 옵션은 함께 사용할 수 없습니다.
  • --filter 는 LDAP 필터를 사용하여 권한이 적용되는 항목을 식별합니다. IdM은 지정된 필터의 유효성을 자동으로 검사합니다. 필터는 유효한 LDAP 필터일 수 있습니다. 예를 들면 다음과 같습니다.
    [root@server ~]# ipa permission-add "manage Windows groups" --filter="(!(objectclass=posixgroup))" --permissions=write --attrs=description
  • --memberOf 는 그룹이 존재하는지 확인한 후 대상 필터를 지정된 그룹의 멤버로 설정합니다. 예를 들어 다음과 같습니다.
    [root@server ~]# ipa permission-add ManageHost --permissions="write" --subtree=cn=computers,cn=accounts,dc=testrelm,dc=com --attr=nshostlocation --memberof=admins
  • --TargetGroup은 그룹이 존재하는지 확인한 후 target을 지정된 사용자 그룹으로 설정합니다.
웹 UI에서 사용할 수 있는 대상 DN 설정은 명령줄에서 사용할 수 없습니다.
참고
권한 수정 및 삭제에 대한 자세한 내용은 ipa permission-mod --helpipa permission-del --help 명령을 실행합니다.

10.4.2.3. 기본 관리 권한

관리 권한은 ID 관리와 함께 사전 설치되어 있는 권한입니다. 사용자가 생성한 다른 권한처럼 동작하며 다음과 같은 차이점이 있습니다.
  • 이름, 위치 및 대상 속성을 수정할 수 없습니다.
  • 이를 삭제할 수 없습니다.
  • 다음과 같은 세 가지 특성 집합이 있습니다.
    • IdM에서 관리하며 사용자가 수정할 수 없는 기본 속성
    • 사용자가 추가한 추가 속성입니다. 관리 권한에 포함된 속성을 추가하려면 ipa permission-mod 명령으로 -- included attrs 옵션을 제공하여 속성을 지정합니다.
    • 사용자가 삭제한 속성 제외. 관리 권한에 제외된 속성을 추가하려면 ipa permission-mod 명령으로 --excludedattrs 옵션을 제공하여 속성을 지정합니다.
관리 권한은 기본 및 포함된 속성 세트에 표시되지만 제외된 세트에는 표시되지 않는 모든 속성에 적용됩니다.
관리 권한을 수정할 때 --attrs 옵션을 사용하면 포함된 속성 및 제외된 속성이 --attrs 와 함께 제공된 속성만 활성화되도록 자동으로 조정됩니다.
참고
관리 권한을 삭제할 수는 없지만 바인딩 유형을 권한으로 설정하고 모든 권한 에서 관리 권한을 제거하면 효과적으로 비활성화됩니다.
모든 관리 권한의 이름은 시스템(예 : System )으로 시작합니다. Sudo 규칙 또는 System을 추가합니다: 서비스 수정.
이전 버전의 IdM에서는 기본 권한에 대해 다른 스키마를 사용했습니다. 예를 들어 사용자가 기본 권한을 수정하지 못하고 사용자는 권한에만 할당할 수 있습니다. 이러한 기본 권한 대부분은 관리 권한으로 변경되었지만 다음 권한은 여전히 이전 체계를 사용합니다.
  • Automember Rebuild Membership 작업 추가
  • 복제 계약 추가
  • 인증서 제거 저장
  • CA에서 인증서 상태 가져오기
  • DNA 범위 수정
  • 복제 계약 수정
  • 복제 계약 제거
  • 인증서 요청
  • 다른 호스트에서 인증서 요청
  • CA에서 인증서 검색
  • 인증서 취소
  • IPA 설정 쓰기
웹 UI에서 관리 권한을 수정하려고 하면 수정할 수 없는 속성이 비활성화됩니다.

그림 10.15. 비활성화된 속성

비활성화된 속성
명령줄에서 관리 권한을 수정하려고 하면 시스템에서 수정할 수 없는 속성을 변경할 수 없습니다. 예를 들어 기본 시스템을 변경하려고 합니다. Users 권한을 수정하는데 실패합니다.
$ ipa permission-mod 'System: Modify Users' --type=group
ipa: ERROR: invalid 'ipapermlocation': not modifiable on managed permissions
그러나 시스템을 수행할 수 있습니다. GECOS 속성에 적용되지 않도록 사용자 권한을 수정합니다.
$ ipa permission-mod 'System: Modify Users' --excludedattrs=gecos
------------------------------------------
Modified permission "System: Modify Users"

10.4.2.4. 이전 버전의 ID 관리 권한

이전 버전의 Identity Management에서는 사용 권한이 다르게 처리되었습니다. 예를 들면 다음과 같습니다.
  • 글로벌 IdM ACI는 서버의 모든 사용자에게 읽기 액세스 권한을 부여했습니다. 이 경우에도 익명의 사용자도 인증되지 않았습니다 - 사용자가 인증되지 않았습니다.
  • 쓰기, 추가 및 삭제 권한 유형만 사용할 수 있습니다. 읽기 권한도 사용할 수 있었지만 인증되지 않은 사용자를 포함한 모든 사용자가 기본적으로 읽기 액세스 권한을 가지기 때문에 실질적인 가치가 없었습니다.
현재 버전의 Identity Management에는 훨씬 더 세분화된 권한 설정 옵션이 포함되어 있습니다.
  • 글로벌 IdM ACI는 인증되지 않은 사용자에 대한 읽기 액세스 권한을 부여하지 않습니다.
  • 예를 들어 동일한 권한에 필터와 하위 트리를 모두 추가할 수 있습니다.
  • 검색 및 비교 권한을 추가할 수 있습니다.
새로운 사용 권한 처리 방식은 이전 버전과의 호환성을 유지하면서 사용자 또는 그룹 액세스를 제어하기 위한 IdM 기능을 대폭 개선했습니다. 이전 버전의 IdM에서 업그레이드하면 모든 서버에서 글로벌 IdM ACI가 삭제되고 관리 권한으로 대체됩니다.
이전 방식으로 만든 권한은 수정할 때마다 자동으로 현재 스타일로 변환됩니다. 이러한 항목을 변경하지 않으면 이전 유형의 사용 권한은 의도치 않은 상태로 유지됩니다. 권한이 현재 스타일을 사용하는 경우 이전 스타일로 다운그레이드할 수 없습니다.
참고
이전 버전의 IdM을 실행하는 서버에서 권한을 부여할 수 있습니다.
ipa 권한 표시ipa permission-find 명령은 현재 권한과 이전 스타일의 권한을 모두 인식합니다. 이러한 명령의 출력에는 현재 스타일의 권한이 표시되지만 권한 자체는 변경되지 않습니다. 명령은 LDAP에 대한 변경 사항을 커밋하지 않고 메모리에만 데이터를 출력하기 전에 권한 항목을 업그레이드합니다.
이전 버전과 현재 특성이 모두 포함된 권한은 이전 버전의 IdM을 실행하는 모든 서버와 현재 IdM 버전을 실행하는 모든 서버에 영향을 미칩니다. 그러나 이전 버전의 IdM을 실행하는 서버에서 현재 권한을 사용하여 권한을 생성하거나 수정할 수 없습니다.

10.4.3. 권한

10.4.3.1. 웹 UI에서 새 권한 생성

  1. 상단 메뉴에서 IPA Server 탭을 열고 역할 기반 액세스 제어를 선택합니다.
  2. Privileges (권한) 작업 링크를 선택합니다.
  3. 권한 목록 상단에 있는 Add 링크를 클릭합니다.

    그림 10.17. 새 권한 추가

    새 권한 추가
  4. 권한의 이름 및 설명을 입력합니다.

    그림 10.18. 권한 추가 양식

    권한 추가 양식
  5. 추가 및 편집 버튼을 클릭하여 권한 구성 페이지로 이동하여 권한을 추가합니다.
  6. 권한 탭을 선택합니다.
  7. 권한 목록 맨 위에 있는 추가를 클릭하여 권한을 추가합니다.

    그림 10.19. 권한 추가

    권한 추가
  8. 추가할 권한의 이름으로 확인란을 클릭하고 > 버튼 사용하여 권한을 Prospective 열로 이동합니다.

    그림 10.20. 권한 선택

    권한 선택
  9. Add 버튼을 클릭하여 저장합니다.

10.4.3.2. 명령줄에서 새 권한 생성

권한 항목은 privilege-add 명령을 사용하여 생성된 다음, privilege-add-permission 명령을 사용하여 권한 그룹에 권한이 추가됩니다.
  1. 권한 항목을 생성합니다.
    [jsmith@server ~]$ ipa privilege-add "managing filesystems" --desc="for filesystems"
  2. 필요한 권한을 할당합니다. 예를 들어 다음과 같습니다.
    [jsmith@server ~]$ ipa privilege-add-permission "managing filesystems" --permissions="managing automount" --permissions="managing ftp services"

IV 부. 관리: ID 관리

이 부분에서는 사용자 계정, 호스트 및 사용자 그룹 및 호스트 그룹을 관리하는 방법을 자세히 설명합니다. 또한 고유한 UID 및 GID 번호와 사용자 및 그룹 스키마 작동 방식을 할당하고 보는 방법을 자세히 설명합니다. 다음 장에서는 서비스 관리 및 호스트 및 서비스에 대한 액세스 위임을 다룹니다. 마지막 장에서는 ID 관리를 위한 액세스 제어 정의 방법, Kerberos 플래그 및 주체 별칭 관리 방법, NIS 도메인 및 Netgroups 과의 통합 방법에 대한 지침을 제공합니다.

11장. 사용자 계정 관리

이 장에서는 사용자 계정의 일반적인 관리 및 구성에 대해 설명합니다.

11.1. 사용자 홈 디렉터리 설정

모든 사용자에게 홈 디렉터리가 구성되어 있는 것이 좋습니다. 사용자 홈 디렉토리의 기본 예상 위치는 /home/ 디렉터리에 있습니다. 예를 들어, IdM에서는 user_login 로그인이 있는 사용자가 /home/user_login 에 홈 디렉토리를 설정할 것으로 예상합니다.
참고
ipa config-mod 명령을 사용하여 사용자 홈 디렉토리의 기본 예상 위치를 변경할 수 있습니다.
IdM은 사용자의 홈 디렉토리를 자동으로 생성하지 않습니다. 그러나 사용자가 로그인할 때 자동으로 홈 디렉터리를 생성하도록 PAM 홈 디렉터리 모듈을 구성할 수 있습니다. 또는 NFS 공유 및 autoscale 유틸리티를 사용하여 홈 디렉토리를 수동으로 추가할 수 있습니다.

11.1.1. PAM 홈 디렉터리 모듈을 사용하여 자동으로 홈 디렉터리 마운트

지원되는 PAM 홈 디렉터리 모듈

IdM 도메인에 로그인할 때 사용자의 홈 디렉터리를 자동으로 생성하도록 PAM 홈 디렉터리 모듈을 구성하려면 다음 PAM 모듈 중 하나를 사용합니다.
  • pam_oddjob_mkhomedir
  • pam_mkhomedir
IdM은 first attempt to use five_oddjob_mkhomedir. 이 모듈이 설치되어 있지 않은 경우 IdM은 tutorial _mkhomedir 을 대신 사용합니다.
참고
NFS 공유의 새 사용자에 대한 홈 디렉터리 자동 생성은 지원되지 않습니다.

PAM 홈 디렉터리 모듈 구성

PAM 홈 디렉터리 모듈을 활성화하면 로컬 효과가 있습니다. 따라서 필요한 각 클라이언트 및 서버에서 모듈을 개별적으로 활성화해야 합니다.
서버 또는 클라이언트를 설치하는 동안 모듈을 구성하려면 시스템을 설치할 때 ipa-server-install 또는 ipa-client-install 유틸리티와 함께 --mkhomedir 옵션을 사용합니다.
이미 설치된 서버 또는 클라이언트에서 모듈을 구성하려면 authconfig 유틸리티를 사용합니다. 예를 들어 다음과 같습니다.
# authconfig --enablemkhomedir --update
authconfig 를 사용하여 홈 디렉터리를 만드는 방법에 대한 자세한 내용은 시스템 수준 인증 가이드를 참조하십시오.

11.1.2. 홈 디렉토리 수동 마운트

NFS 파일 서버를 사용하여 IdM 도메인의 모든 시스템에서 사용할 수 있는 /home/ 디렉터리를 제공한 다음 autoscale 유틸리티를 사용하여 IdM 시스템에 디렉터리를 마운트할 있습니다.

NFS 사용 시 문제 발생

NFS를 사용하면 성능 및 보안에 부정적인 영향을 줄 수 있습니다. 예를 들어 NFS를 사용하면 NFS 사용자에게 root 액세스 권한을 부여하여 발생하는 보안 취약점, 전체 /home/ 디렉터리 트리를 로드하는 성능 문제 또는 홈 디렉터리에 원격 서버를 사용하기 위한 네트워크 성능 문제가 발생할 수 있습니다.
이러한 문제의 영향을 줄이려면 다음 지침을 따르는 것이 좋습니다.
  • 사용자가 로그인할 때만 사용자의 홈 디렉터리를 마운트하려면 자동 마운트를 사용합니다. 전체 /home/ tree를 로드하는 데 사용하지 마십시오.
  • 홈 디렉터리를 생성하는 권한이 제한된 원격 사용자를 사용하고 이 사용자로 IdM 서버에 공유를 마운트합니다. IdM 서버는 httpd 프로세스로 실행되므로 sudo 또는 유사한 프로그램을 사용하여 IdM 서버에 대한 제한된 액세스 권한을 부여하여 NFS 서버에 홈 디렉터리를 생성할 수 있습니다.

NFS 및 mount를 사용하여 홈 디렉터리 설정

NFS 공유 및 마운팅을 사용하여 별도의 위치에서 IdM 서버에 홈 디렉토리를 수동으로 추가하려면 다음을 수행합니다.
  1. 사용자 디렉터리 맵의 새 위치를 만듭니다.
    $ ipa automountlocation-add userdirs
    Location: userdirs
  2. 새 위치의 auto.direct 파일에 직접 매핑을 추가합니다. auto.direct 파일은 ipa-server-install 유틸리티에 의해 자동으로 생성된 이전 맵입니다. 다음 예에서 마운트 지점은 /share:입니다.
    $ ipa automountkey-add userdirs auto.direct --key=/share --info="-ro,soft, server.example.com:/home/share"
    
    Key: /share
    Mount information: -ro,soft, server.example.com:/home/share
IdM과 함께 자동 마운트 를 사용하는 방법에 대한 자세한 내용은 34장. 자동 마운트 사용 을 참조하십시오.

11.2. 사용자 라이프 사이클

Identity Management는 stage,active, preserved 등 세 가지 사용자 계정 상태를 지원합니다.
  • 단계 사용자는 인증할 수 없습니다. 이는 초기 상태입니다. 활성 사용자에게 필요한 일부 사용자 계정 속성은 아직 설정되지 않을 수 있습니다.
  • 활성 사용자는 인증할 수 있습니다. 필요한 모든 사용자 계정 속성을 이 상태로 설정해야 합니다.
  • 보존된 사용자는 이전 활성 사용자입니다. 비활성 것으로 간주되며 IdM에 인증할 수 없습니다. 보존된 사용자는 활성 사용자로 보유한 계정 속성을 대부분 유지하지만 사용자 그룹의 일부가 아닙니다.
    참고
    보존 상태의 사용자 목록은 과거 사용자 계정의 기록을 제공할 수 있습니다.
사용자 항목도 IdM 데이터베이스에서 영구적으로 삭제할 수 있습니다. 사용자 항목을 삭제하면 그룹 멤버십 및 암호를 포함하여 IdM에서 항목 자체 및 모든 정보가 영구적으로 제거됩니다. 시스템 계정 및 홈 디렉터리와 같은 사용자의 외부 구성은 삭제되지 않지만 더 이상 IdM을 통해 액세스할 수 없습니다.
중요
삭제된 사용자 계정은 복원할 수 없습니다. 사용자 계정을 삭제하면 해당 계정과 연결된 모든 정보가 영구적으로 손실됩니다.
새 관리자는 기본 admin 사용자와 같은 다른 관리자만 만들 수 있습니다. 모든 관리자 계정을 실수로 삭제하는 경우 Directory Manager는 Directory Server에서 수동으로 새 관리자를 만들어야 합니다.
주의
admin 사용자를 삭제하지 마십시오. admin 은 IdM에 필요한 사전 정의된 사용자이므로 이 작업으로 인해 특정 명령에 문제가 발생합니다. 대체 admin 사용자를 정의하고 사용하려면 하나 이상의 다른 사용자에게 admin 권한을 부여한 후 ipa user-disable admin 을 사용하여 사전 정의된 admin 사용자를 비활성화합니다.

사용자 라이프사이클 관리 작업

관리자는 사용자 프로비저닝을 관리하기 위해 사용자 계정을 한 상태에서 다른 상태로 이동할 수 있습니다. 새 사용자 계정은 활성 또는 단계로 추가할 수 있지만 보존 되지는 않습니다.
IdM은 사용자 라이프사이클 관리에 대해 다음 작업을 지원합니다.
단계 → 활성
단계 상태의 계정을 적절하게 활성화할 준비가 되면 관리자가 활성 상태로 이동합니다.
활성 → 유지됨
사용자가 퇴사한 후 관리자는 계정을 보존 상태로 이동합니다.
유지 관리 → 활성
이전 사용자가 다시 회사에 가입합니다. 관리자는 보존된 상태에서 활성 상태로 다시 이동하여 사용자 계정을 복원합니다.
유지됨 → 단계
이전 사용자가 다시 회사에 참여할 계획입니다. 관리자는 나중에 반응할 수 있도록 보존된 상태에서 stage 상태로 계정을 이동합니다.
또한 IdM에서 활성, 스테이징 및 보존 사용자를 영구적으로 삭제할 수 있습니다. 단계 사용자를 보존 상태로 이동할 수는 없으며 영구적으로 삭제할 수 있습니다.

그림 11.1. 사용자 라이프 사이클 작업

사용자 라이프 사이클 작업

11.2.1. 단계 또는 활성 사용자 추가

웹 UI에서 사용자 추가

  1. IdentityUsers 탭을 선택합니다.
  2. 활성 사용자 또는 단계 상태에 사용자를 추가할지 여부에 따라 활성 사용자 또는 단계 사용자 범주를 선택합니다.

    그림 11.2. 사용자 카테고리 선택

    사용자 카테고리 선택
    활성 또는 단계 사용자 라이프 사이클 상태에 대한 자세한 내용은 11.2절. “사용자 라이프 사이클” 을 참조하십시오.
  3. 사용자 목록 맨 위에서 추가 를 클릭합니다.

    그림 11.3. 사용자 추가

    사용자 추가
  4. 사용자 추가 양식을 작성합니다.
    사용자 로그인을 수동으로 설정하지 않으면 IdM은 지정된 이름 및 성에 따라 자동으로 로그인을 생성합니다.
  5. 추가를 클릭합니다.
    또는 추가 를 클릭하고 다른 사용자 추가 또는 추가 및 편집 을 클릭하여 새 사용자 항목 편집을 시작합니다. 사용자 항목 편집에 대한 자세한 내용은 11.3절. “사용자 편집” 을 참조하십시오.

명령줄에서 사용자 추가

활성 상태에서 새 사용자를 추가하려면 ipa user-add 명령을 사용합니다. stage 상태에서 새 사용자를 추가하려면 ipa stageuser-add 명령을 사용합니다.
참고
활성 또는 단계 사용자 라이프 사이클 상태에 대한 자세한 내용은 11.2절. “사용자 라이프 사이클” 을 참조하십시오.
옵션 없이 실행하는 경우, ipa user-addipa stageuser-add 프롬프트가 필요한 최소 사용자 속성을 선택하고 다른 속성에 기본값을 사용합니다. 또는 다양한 특성을 명령에 직접 지정하는 옵션을 추가할 수 있습니다.
대화형 세션에서 옵션 없이 명령을 실행한 후 IdM은 제공된 이름 및 성에 따라 자동으로 생성된 사용자 로그인을 제안하고 대괄호([ ])에 표시합니다. 기본 로그인을 허용하려면 Enter 를 눌러 확인합니다. 사용자 정의 로그인을 지정하려면 기본값을 확인하지 않고 대신 사용자 정의 로그인을 지정합니다.
$ ipa user-add
First name: first_name
Last name: last_name
User login [default_login]: custom_login
ipa user-addipa stageuser-add 에 옵션을 추가하면 여러 사용자 속성에 대한 사용자 지정 값을 정의할 수 있습니다. 즉, 대화형 세션에 비해 더 많은 정보를 지정할 수 있습니다. 예를 들어 스테이징 사용자를 추가하려면 다음을 수행합니다.
$ ipa stageuser-add stage_user_login --first=first_name --last=last_name --email=email_address
ipa user-addipa stageuser-add 에서 허용하는 전체 옵션 목록을 보려면 --help 옵션이 추가된 명령을 실행합니다.

11.2.1.1. 사용자 이름 요구 사항

IdM은 다음 정규 표현식으로 설명할 수 있는 사용자 이름을 지원합니다.
'(?!^[0-9]+$)^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$'
사용자 이름에는 문자, 숫자, _, ., $만 포함할 수 있으며 최소 하나의 문자만 포함해야 합니다.
참고
Samba 3.x 시스템 지원을 사용하도록 후행 달러 기호($)로 끝나는 사용자 이름이 지원됩니다.
사용자 이름에 대문자가 포함된 사용자를 추가하면 IdM에서 자동으로 이름을 저장할 때 이름을 소문자로 변환합니다. 따라서 IdM에서는 사용자가 로그인할 때 항상 사용자 이름을 소문자로 입력해야 합니다. 또한 사용자 이름은 사용자 이름(예: 사용자 및 사용자)과 같은 문자 대/소문자만 다른 사용자를 추가할 수 없습니다.
사용자 이름의 기본 최대 길이는 32자입니다. 이를 변경하려면 ipa config-mod --maxusername 명령을 사용합니다. 예를 들어 최대 사용자 이름 길이를 64자로 늘리려면 다음을 수행합니다.
$ ipa config-mod --maxusername=64
  Maximum username length: 64
  ...

11.2.1.2. 사용자 정의 UID 또는 GID 번호 정의

사용자 지정 UID 또는 GID 번호를 지정하지 않고 새 사용자 항목을 추가하면 IdM에서 ID 범위에서 다음에 사용할 수 있는 ID 번호를 자동으로 할당합니다. 즉, 사용자의 ID 번호는 항상 고유합니다. ID 범위에 대한 자세한 내용은 14장. 고유한 UID 및 GID 번호 할당 을 참조하십시오.
사용자 정의 ID 번호를 지정하면 서버에서 사용자 정의 ID 번호가 고유했는지 여부를 확인하지 않습니다. 이로 인해 여러 사용자 항목에 동일한 ID 번호가 할당될 수 있습니다. 동일한 ID 번호를 가진 여러 항목이 없도록 하는 것이 좋습니다.

11.2.2. 사용자 나열 및 사용자 검색

웹 UI에서 사용자 나열

  1. IdentityUsers 탭을 선택합니다.
  2. 활성 사용자,단계 사용자 또는 Preserved 사용자 범주를 선택합니다.

    그림 11.4. 사용자 나열

    사용자 나열

웹 UI에서 사용자 정보 표시

사용자에 대한 자세한 정보를 표시하려면 사용자 목록에서 사용자 이름을 클릭합니다.

그림 11.5. 사용자 정보 표시

사용자 정보 표시

명령줄에서 사용자 나열

모든 활성 사용자를 나열하려면 ipa user-find 명령을 실행합니다. 모든 단계 사용자를 나열하려면 ipa stageuser-find 명령을 사용합니다. 보존된 사용자를 나열하려면 ipa user-find --preserved=true 명령을 실행합니다.
예를 들어 다음과 같습니다.
$ ipa user-find
---------------
23 users matched
---------------
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 1453200000
  GID: 1453200000
  Account disabled: False
  Password: True
  Kerberos keys available: True

  User login: user
...
ipa user-findipa stageuser-find 에 옵션과 인수를 추가하면 검색 기준을 정의하고 검색 결과를 필터링할 수 있습니다. 예를 들어 특정 제목으로 활성 사용자를 모두 표시하려면 다음을 수행합니다.
$ ipa user-find --title=user_title
---------------
2 users matched
---------------
  User login: user
...
  Job Title: Title
...

  User login: user2
...
  Job Title: Title
...
마찬가지로 로그인에 사용자가 포함된 모든 단계 사용자를 표시하려면 다음을 수행하십시오.
$ ipa user-find user
---------------
3 users matched
---------------
User login: user
...

User login: user2
...

User login: user3
...
ipa user-findipa stageuser-find 에서 허용하는 전체 옵션 목록을 보려면 --help 옵션이 추가된 명령을 실행합니다.

명령줄에서 사용자 정보 표시

활성 또는 보존된 사용자에 대한 정보를 표시하려면 ipa user-show 명령을 사용합니다.
$ ipa user-show user_login
  User login: user_login
  First name: first_name
  Last name: last_name
...
스테이지 사용자에 대한 정보를 표시하려면 ipa stageuser-show 명령을 사용합니다.

11.2.3. 사용자 활성화, 사전 예약, 삭제 및 복원

이 섹션에서는 다양한 사용자 라이프사이클 상태 간 사용자 계정 이동에 대해 설명합니다. IdM의 라이프사이클 상태에 대한 자세한 내용은 11.2절. “사용자 라이프 사이클” 을 참조하십시오.

웹 UI에서 사용자 라이프사이클 관리

스테이징 사용자를 활성화하려면 다음을 수행합니다.
  • 단계 사용자 목록에서 활성화할 사용자를 선택하고 활성화를 클릭합니다.

    그림 11.6. 사용자 활성화

    사용자 활성화
사용자를 유지하거나 삭제하려면 다음을 수행합니다.
  1. Active users 또는 Stage users 목록에서 사용자를 선택합니다. 삭제를 클릭합니다.

    그림 11.7. 사용자 삭제

    사용자 삭제
  2. 활성 사용자를 선택한 경우 삭제 또는 보존을 선택합니다. stage 사용자를 선택한 경우 사용자만 삭제할 수 있습니다. 기본 UI 옵션은 delete 입니다.
    예를 들어 활성 사용자를 보존하려면 다음을 수행합니다.

    그림 11.8. 웹 UI에서 삭제 모드 선택

    웹 UI에서 삭제 모드 선택
    확인하려면 Delete (삭제) 버튼을 클릭합니다.
보존된 사용자를 복원하려면 다음을 수행합니다.
  • Preserved users 목록에서 복원할 사용자를 선택하고 복원을 클릭합니다.

    그림 11.9. 사용자 복원

    사용자 복원
참고
사용자를 복원해도 계정의 이전 속성은 모두 복원되지 않습니다. 예를 들어 사용자 암호는 복원되지 않으며 다시 정의해야 합니다.
웹 UI에서는 사용자를 보존된 상태에서 stage 상태로 이동할 수 없습니다.

명령줄에서 사용자 라이프사이클 관리

단계에서 활성 상태로 이동하여 사용자 계정을 활성화하려면 ipa stageuser-activate 명령을 사용합니다.
$ ipa stageuser-activate user_login
-------------------------
Stage user user_login activated
-------------------------
...
사용자 계정을 보존하거나 삭제하려면 ipa user-del 또는 ipa stageuser-del 명령을 사용합니다.
  • IdM 데이터베이스에서 활성 사용자를 영구적으로 제거하려면 옵션 없이 ipa user-del 을 실행합니다.
    $ ipa user-del user_login
    --------------------
    Deleted user "user3"
    --------------------
    
  • 활성 사용자 계정을 유지하려면 --preserve 옵션을 사용하여 ipa user-del 을 실행합니다.
    $ ipa user-del --preserve user_login
    --------------------
    Deleted user "user_login"
    --------------------
    
  • IdM 데이터베이스에서 stage 사용자를 영구적으로 제거하려면 ipa stageuser-del 를 실행합니다.
    $ ipa stageuser-del user_login
    --------------------------
    Deleted stage user "user_login"
    --------------------------
    
참고
여러 사용자를 삭제하는 경우 오류와 관계없이 명령을 강제 적용하려면 --continue 옵션을 사용합니다. 명령이 완료되면 성공 및 실패한 작업에 대한 요약이 stdout 표준 출력 스트림에 출력됩니다.
$ ipa user-del --continue user1 user2 user3
--continue 를 사용하지 않으면 명령이 오류가 발생할 때까지 사용자를 삭제하는 과정을 진행합니다. 그러면 중지되고 종료됩니다.
보존된 사용자 계정을 보존에서 활성 상태로 이동하여 보존된 사용자 계정을 복원하려면 ipa user-undel 명령을 사용합니다.
$ ipa user-undel user_login
------------------------------
Undeleted user account "user_login"
------------------------------
보존된 사용자 계정을 stage 로 이동하여 보존된 사용자 계정을 복원하려면 ipa user-stage 명령을 사용합니다.
$ ipa user-stage user_login
------------------------------
Staged user account "user_login"
------------------------------
참고
사용자 계정을 복원해도 계정의 이전 속성이 모두 복원되지는 않습니다. 예를 들어 사용자 암호는 복원되지 않으며 다시 정의해야 합니다.
이러한 명령과 허용되는 옵션에 대한 자세한 내용은 --help 옵션과 함께 실행합니다.

11.3. 사용자 편집

웹 UI에서 사용자 편집

  1. IdentityUsers 탭을 선택합니다.
  2. Active users,Stage users, Preserved 사용자 카테고리를 검색하여 편집할 사용자를 찾습니다.
  3. 편집할 사용자 이름을 클릭합니다.

    그림 11.10. 편집할 사용자 선택

    편집할 사용자 선택
  4. 필요에 따라 사용자 속성 필드를 편집합니다.
  5. 페이지 상단에서 저장 을 클릭합니다.

    그림 11.11. 수정된 사용자 속성 저장

    수정된 사용자 속성 저장
웹 UI에서 사용자 세부 정보를 업데이트하면 새 값이 즉시 동기화되지 않습니다. 새 값이 클라이언트 시스템에 반영되는 데 최대 5분이 걸릴 수 있습니다.

명령줄에서 사용자 편집

활성 상태 또는 보존 상태의 사용자를 수정하려면 ipa user-mod 명령을 사용합니다. 스테이징 상태의 사용자를 수정하려면 ipa stage user-mod 명령을 사용합니다.
ipa user-modipa stageuser-mod 명령은 다음 옵션을 허용합니다.
  • 수정할 사용자 계정을 식별하는 사용자 로그인
  • 새 특성 값을 지정하는 옵션
명령줄에서 수정할 수 있는 사용자 항목 속성의 전체 목록은 ipa user-modipa stageuser-mod 에서 허용하는 옵션 목록을 참조하십시오. 옵션 목록을 표시하려면 --help 옵션이 추가된 명령을 실행합니다.
ipa user-mod 또는 ipa stageuser-mod 에 속성 옵션을 추가하면 현재 속성 값을 덮어씁니다. 예를 들어 다음에서는 사용자의 제목을 변경하거나 사용자가 아직 제목이 지정되지 않은 경우 새 제목을 추가합니다.
$ ipa user-mod user_login --title=new_title
여러 값을 가질 수 있는 LDAP 속성의 경우 IdM은 여러 값도 허용합니다. 예를 들어 사용자는 사용자 계정에 두 개의 이메일 주소를 저장할 수 있습니다. 기존 값을 덮어쓰지 않고 추가 특성 값을 추가하려면 --addattr 옵션을 옵션과 함께 사용하여 새 특성 값을 지정합니다. 예를 들어 이미 지정된 이메일 주소가 있는 사용자 계정에 새 이메일 주소를 추가하려면 다음을 수행합니다.
$ ipa user-mod user --addattr=mobile=new_mobile_number
--------------------
Modified user "user"
--------------------
  User login: user
...
  Mobile Telephone Number: mobile_number, new_mobile_number
...
두 개의 특성 값을 동시에 설정하려면 --addattr 옵션을 두 번 사용합니다.
$ ipa user-mod user --addattr=mobile=mobile_number_1 --addattr=mobile=mobile_number_2
또한 ipa user-mod 명령은 속성 값을 설정하기 위해 --setattr 옵션과 속성 값을 삭제하는 --delattr 옵션을 허용합니다. 이러한 옵션은 --addattr 사용과 유사한 방식으로 사용됩니다. 자세한 내용은 ipa user-mod --help 명령의 출력을 참조하십시오.
참고
사용자의 현재 이메일 주소를 덮어쓰려면 --email 옵션을 사용합니다. 그러나 추가 이메일 주소를 추가하려면 --addattr 옵션과 함께 mail 옵션을 사용합니다.
$ ipa user-mod user --email=email@example.com

$ ipa user-mod user --addattr=mail=another_email@example.com

11.4. 사용자 계정 활성화 및 비활성화

관리자는 활성 사용자 계정을 비활성화하고 활성화할 수 있습니다. 사용자 계정을 비활성화하면 계정이 비활성화됩니다. 비활성화된 사용자 계정은 인증에 사용할 수 없습니다. 계정이 비활성화된 사용자는 IdM에 로그인할 수 없으며 Kerberos와 같은 IdM 서비스를 사용하거나 작업을 수행할 수 없습니다.
비활성화된 사용자 계정은 IdM 내에 계속 존재하며 모든 관련 정보는 변경되지 않습니다. 보존된 사용자 계정과 달리 비활성화된 사용자 계정은 활성 상태로 유지됩니다. 따라서 ipa user-find 명령의 출력에 표시됩니다. 예를 들어 다음과 같습니다.
$ ipa user-find
...
  User login: user
  First name: User
  Last name: User
  Home directory: /home/user
  Login shell: /bin/sh
  UID: 1453200009
  GID: 1453200009
  Account disabled: True
  Password: False
  Kerberos keys available: False
...
비활성화된 사용자 계정은 다시 활성화할 수 있습니다.
참고
사용자 계정을 비활성화한 후 사용자의 Kerberos TGT 및 기타 티켓이 만료될 때까지 기존 연결은 유효한 상태로 유지됩니다. 티켓이 만료되면 사용자는 이를 갱신할 수 없습니다.

웹 UI에서 사용자 계정 활성화 및 비활성화

  1. IdentityUsers 탭을 선택합니다.
  2. 활성 사용자 목록에서 필요한 사용자 또는 사용자를 선택한 다음 비활성화 또는 사용을 클릭합니다.

    그림 11.12. 사용자 계정 비활성화 또는 활성화

    사용자 계정 비활성화 또는 활성화

명령줄에서 사용자 계정 비활성화 및 활성화

사용자 계정을 비활성화하려면 ipa user-disable 명령을 사용합니다.
$ ipa user-disable user_login
----------------------------
Disabled user account "user_login"
----------------------------
사용자 계정을 활성화하려면 ipa user-enable 명령을 사용합니다.
$ ipa user-enable user_login
----------------------------
Enabled user account "user_login"
----------------------------

11.5. 관리자가 아닌 사용자가 사용자 항목을 관리하도록 허용

기본적으로 admin 사용자만 사용자 라이프사이클을 관리하고 사용자 계정을 비활성화 또는 활성화할 수 있습니다. 관리자가 아닌 다른 사용자가 이 작업을 수행할 수 있도록 하려면 새 역할을 생성하고, 관련 권한을 이 역할에 추가하고, 관리자가 아닌 사용자를 역할에 할당합니다.
기본적으로 IdM에는 사용자 계정 관리와 관련된 다음 권한이 포함됩니다.
사용자 수정 및 암호 재설정
이 권한에는 다양한 사용자 속성을 수정할 수 있는 권한이 포함됩니다.
사용자 관리자
이 권한에는 활성 사용자를 추가하고, 비활성 사용자를 활성화하며, 사용자를 제거하고, 사용자 속성 및 기타 권한을 수정하는 권한이 포함됩니다.
사용자 프로비저닝 단계
이 권한에는 스테이징 사용자를 추가할 수 있는 권한이 포함됩니다.
사용자 관리자 단계
이 권한에는 스테이징 사용자 추가 또는 라이프사이클 상태 간 사용자 이동 등의 다양한 라이프사이클 작업을 수행할 수 있는 권한이 포함됩니다. 그러나 사용자를 active 상태로 이동할 수 있는 권한은 포함되지 않습니다.
역할, 권한 및 권한 정의에 대한 자세한 내용은 10.4절. “역할 기반 액세스 제어 정의” 을 참조하십시오.

다른 사용자가 다른 사용자 관리 작업을 수행할 수 있도록 허용

사용자 계정 관리와 관련된 다양한 권한을 다른 사용자에게 추가할 수 있습니다. 예를 들어 다음을 통해 직원 계정 항목 및 활성화에 대한 권한을 분리할 수 있습니다.
  • 1명의 사용자를 스테이징 사용자 관리자로 구성합니다. 이 관리자는 향후 직원을 IdM에 스테이징 사용자로 추가할 수 있지만 활성화할 수는 없습니다.
  • 다른 사용자를 보안 관리자로 구성합니다. 이 관리자는 고용 첫 날 직원 자격 증명을 확인한 후 스테이징 사용자를 활성화할 수 있습니다.
사용자가 특정 사용자 관리 작업을 수행할 수 있도록 하려면 필요한 권한 또는 권한으로 새 역할을 생성하고 해당 역할에 사용자를 할당합니다.

예 11.1. 관리자 권한이 없는 사용자 추가 허용

이 예에서는 새 스테이징 사용자만 추가할 수 있지만 다른 단계의 사용자 관리 작업을 수행하지 않는 사용자를 생성하는 방법을 보여줍니다.
  1. 역할 기반 액세스 제어를 관리할 수 있는 관리자 또는 다른 사용자로 로그인합니다.
    $ kinit admin
    
  2. 새 사용자 지정 역할을 만들어 스테이징 사용자 추가를 관리합니다.
    1. 시스템 프로비저닝 역할을 생성합니다.
      $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      --------------------------------
      Added role "System Provisioning"
      --------------------------------
      Role name: System Provisioning
      Description: Responsible for provisioning stage users
      
    2. 역할에 Stage User Provisioning 권한을 추가합니다. 이 권한은 스테이징 사용자를 추가할 수 있는 기능을 제공합니다.
      $ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
      Role name: System Provisioning
      Description: Responsible for provisioning stage users
      Privileges: Stage User Provisioning
      ----------------------------
      Number of privileges added 1
      ----------------------------
      
  3. 관리자가 아닌 사용자에게 스테이징 사용자를 추가할 권한을 부여합니다.
    1. 관리자가 아닌 사용자가 아직 없으면 새 사용자를 만듭니다. 이 예제에서 사용자 이름은 stage_user_admin 입니다.
      $ ipa user-add stage_user_admin --password
      First name: first_name
      Last name: last_name
      Password:
      Enter password again to verify:
      ...
      
    2. stage_user_admin 사용자를 System Provisioning 역할에 할당합니다.
      $ ipa role-add-member "System Provisioning" --users=stage_user_admin
      Role name: System Provisioning
      Description: Responsible for provisioning stage users
      Member users: stage_user_admin
      Privileges: Stage User Provisioning
      -------------------------
      Number of members added 1
      -------------------------
      
    3. System Provisioning 역할이 올바르게 구성되었는지 확인하려면 ipa role-show 명령을 사용하여 역할 설정을 표시할 수 있습니다.
      $ ipa role-show "System Provisioning"
      --------------
      1 role matched
      --------------
      Role name: System provisioning
      Description: Responsible for provisioning stage users
      Member users: stage_user_admin
      Privileges: Stage User Provisioning
      ----------------------------
      Number of entries returned 1
      ----------------------------
      
  4. 새 stage 사용자를 stage_user_admin 사용자로 추가하는 것을 테스트합니다.
    1. stage_user_admin 으로 로그인합니다. 이전 단계 중 하나에서 stage_user_admin 을 새 사용자로 생성한 경우 IdM은 admin 이 설정한 초기 암호를 변경하도록 요청합니다.
      $ kinit stage_user_admin
      Password for stage_user_admin@EXAMPLE.COM:
      Password expired.  You must change it now.
      Enter new password:
      Enter it again:
      
    2. admin의 Kerberos 티켓이 stage_user_ admin 의 Kerberos 티켓으로 교체되었는지 확인하려면 klist 유틸리티를 사용할 수 있습니다.
      $ klist
      Ticket cache: KEYRING:persistent:0:krb_ccache_xIlCQDW
      Default principal: stage_user_admin@EXAMPLE.COM
      
      Valid starting       Expires              Service principal
      02/25/2016 11:42:20  02/26/2016 11:42:20  krbtgt/EXAMPLE.COM
      
    3. 새 stage 사용자를 추가합니다.
      $ ipa stageuser-add stage_user
      First name: first_name
      Last name: last_name
      ipa: ERROR: stage_user: stage user not found
      
      참고
      스테이징 사용자를 추가한 후 IdM이 보고하는 오류입니다. stage_user_admin 은 단계 사용자만 추가할 수 있으며 이에 대한 정보는 표시하지 않습니다. 따라서 새로 추가된 stage_user 설정 요약을 표시하는 대신 IdM에서 오류를 표시합니다.
stage_user_admin 사용자는 스테이지 사용자에 대한 정보를 표시할 수 없습니다. 따라서 stage_user_admin 으로 로그인하는 동안 새 stage_user 사용자에 대한 정보를 표시하려고 하면 실패합니다.
$ ipa stageuser-show stage_user
ipa: ERROR: stage_user: stage user not found
stage_user 에 대한 정보를 표시하려면 admin 으로 로그인합니다.
$ kinit admin
Password for admin@EXAMPLE.COM:
$ ipa stageuser-show stage_user
  User login: stage_user
  First name: Stage
  Last name: User
...

11.6. 사용자 및 그룹에 외부 프로비저닝 시스템 사용

Identity Management는 사용자 환경 구성을 지원하므로 ID 관리를 위한 외부 솔루션을 사용하여 IdM에서 사용자 및 그룹 ID를 프로비저닝할 수 있습니다. 이 섹션에서는 이러한 구성의 예를 설명합니다. 예제에는 다음이 포함됩니다.

11.6.1. 외부 프로비저닝 시스템에서 사용하도록 사용자 계정 구성

다음 절차에서는 외부 프로비저닝 시스템에서 사용할 두 개의 IdM 사용자 계정을 구성하는 방법을 보여줍니다. 적절한 암호 정책을 사용하여 계정을 그룹에 추가하면 외부 프로비저닝 시스템을 사용하여 IdM에서 사용자 프로비저닝을 관리할 수 있습니다.
  1. 스테이지 사용자를 추가할 수 있는 권한이 있는 사용자, provisionator 를 생성합니다. 사용자 계정은 외부 프로비저닝 시스템에서 새 스테이징 사용자를 추가하기 위해 사용합니다.
    1. provisionator 사용자 계정을 추가합니다.
      $ ipa user-add provisionator --first=provisioning --last=account --password
    2. Provision ator 사용자에게 필요한 권한을 부여합니다.
      사용자 지정 역할 시스템 프로비저닝 을 생성하여 스테이지 사용자 추가를 관리합니다.
      $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      역할에 Stage User Provisioning 권한을 추가합니다. 이 권한은 스테이징 사용자를 추가할 수 있는 기능을 제공합니다.
      $ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
      Provision ator 사용자를 역할에 추가합니다.
      $ ipa role-add-member --users=provisionator "System Provisioning"
  2. 사용자 계정을 관리할 수 있는 권한이 있는 사용자, 활성화기를 만듭니다. 사용자 계정은 외부 프로비저닝 시스템에서 추가한 스테이징 사용자를 자동으로 활성화하는 데 사용됩니다.
    1. activator 사용자 계정을 추가합니다.
      $ ipa user-add activator --first=activation --last=account --password
    2. 활성화 기 사용자에게 필요한 권한을 부여합니다.
      기본 사용자 관리자 역할에 사용자를 추가합니다.
      $ ipa role-add-member --users=activator "User Administrator"
  3. 서비스 및 애플리케이션 계정에 대한 사용자 그룹을 생성합니다.
    $ ipa group-add service-accounts
  4. 그룹의 암호 정책을 업데이트합니다. 다음 정책은 계정의 암호 만료 및 잠금을 금지하지만 복잡한 암호를 요구하여 잠재적인 위험을 보상합니다.
    $ ipa pwpolicy-add service-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=20 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
  5. 서비스 및 애플리케이션 계정의 그룹에 프로비저닝 및 활성화 계정을 추가합니다.
    $ ipa group-add-member service-accounts --users={provisionator,activator}
  6. 사용자 계정의 암호를 변경합니다.
    $ kpasswd provisionator
    $ kpasswd activator
    새 IdM 사용자의 암호가 즉시 만료되므로 암호를 변경해야 합니다.
추가 리소스:

11.6.2. 자동으로 사용자 계정을 활성화하도록 IdM 구성

다음 절차에서는 단계 사용자를 활성화하기 위한 스크립트를 생성하는 방법을 설명합니다. 시스템은 지정된 시간 간격으로 자동으로 스크립트를 실행합니다. 이렇게 하면 새 사용자 계정이 자동으로 활성화되고 생성된 직후 사용할 수 있습니다.
중요
이 절차에서는 스크립트에서 IdM에 추가하기 전에 새 사용자 계정을 검증할 필요가 없다고 가정합니다. 예를 들어, 사용자가 외부 프로비저닝 시스템의 소유자에서 이미 유효성을 검사한 경우 검증이 필요하지 않습니다.
IdM 서버 중 하나에서만 활성화 프로세스를 활성화하는 것으로 충분합니다.
  1. 활성 계정의 키탭 파일을 생성합니다.
    # ipa-getkeytab -s example.com -p "activator" -k /etc/krb5.ipa-activation.keytab
    둘 이상의 IdM 서버에서 활성화 프로세스를 활성화하려면 한 서버에만 키탭 파일을 생성합니다. 그런 다음 키탭 파일을 다른 서버에 복사합니다.
  2. 모든 사용자를 활성화하려면 다음 내용과 함께 /usr/local/sbin/ipa-activate-all 스크립트를 만듭니다.
    #!/bin/bash
    
    kinit -k -i activator
    
    ipa stageuser-find --all --raw | grep "  uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done
  3. ipa-activate-all 스크립트의 권한 및 소유권을 편집하여 실행 가능하게 합니다.
    # chmod 755 /usr/local/sbin/ipa-activate-all
    # chown root:root /usr/local/sbin/ipa-activate-all
  4. 다음 콘텐츠를 사용하여 systemd 장치 파일 /etc/systemd/system/ipa-activate-all.service 를 만듭니다.
    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Service]
    Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab
    Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all
    ExecStart=/usr/local/sbin/ipa-activate-all
  5. 다음 콘텐츠와 함께 systemd 타이머 /etc/systemd/system/ipa-activate-all.timer 를 만듭니다.
    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Timer]
    OnBootSec=15min
    OnUnitActiveSec=1min
    
    [Install]
    WantedBy=multi-user.target
  6. ipa-activate-all.timer 활성화 :
    # systemctl enable ipa-activate-all.timer
추가 리소스:

11.6.3. IdM ID 관리를 위해 외부 프로비저닝 시스템의 LDAP 공급자 구성

이 섹션에서는 다양한 사용자 및 그룹 관리 작업에 대한 템플릿을 보여줍니다. 이러한 템플릿을 사용하여 IdM 사용자 계정을 관리하도록 프로비저닝 시스템의 LDAP 프로바이더를 구성할 수 있습니다. 예를 들어 직원이 퇴사한 후 사용자 계정을 활성화하도록 시스템을 구성할 수 있습니다.

LDAP를 사용하여 사용자 계정 관리

새 사용자 항목을 추가하거나, 기존 항목을 수정하거나, 기존 항목을 수정하거나, 다른 라이프사이클 상태 간에 사용자를 이동하거나, 기본 Directory Server 데이터베이스를 편집하여 사용자를 삭제할 수 있습니다. 데이터베이스를 편집하려면 ldapmodify 유틸리티를 사용합니다.
다음 LDIF 형식의 템플릿은 ldapmodify 를 사용하여 수정할 속성에 대한 정보를 제공합니다. 자세한 예제 프로시저는 예 11.2. “ldapmodify를 사용하여 단계 사용자 추가”예 11.3. “ldapmodify를 사용하여 사용자 유지” 을 참조하십시오.
새 단계 사용자 추가
UID 및 GID가 자동으로 할당된 사용자를 추가합니다.
dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
changetype: add
objectClass: top
objectClass: inetorgperson
uid: user_login
sn: surname
givenName: first_name
cn: full_name
UID 및 GID가 정적으로 할당된 사용자 추가:
dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: posixaccount
uid: user_login
uidNumber: UID_number
gidNumber: GID_number
sn: surname
givenName: first_name
cn: full_name
homeDirectory: /home/user_login
스테이징 사용자를 추가할 때 IdM 오브젝트 클래스를 지정할 필요는 없습니다. IdM은 사용자가 활성화되면 이러한 클래스를 자동으로 추가합니다.
생성된 항목의 고유 이름(DN)은 uid=user_login 으로 시작해야 합니다.
기존 사용자 수정
사용자를 수정하기 전에 사용자 로그인으로 검색하여 사용자의 고유 이름(DN)을 가져옵니다. 다음 예제에서 user_allowed_to_read 사용자는 사용자와 그룹 정보를 읽을 수 있는 사용자이며 암호 는 이 사용자의 암호입니다.
# ldapsearch -LLL -x -D "uid=user_allowed_to_read,cn=users,cn=accounts,dc=example, dc=com" -w "password" -H ldap://server.example.com -b "cn=users, cn=accounts, dc=example, dc=com" uid=user_login
사용자의 특성을 수정하려면 다음을 수행합니다.
dn: distinguished_name
changetype: modify
replace: attribute_to_modify
attribute_to_modify: new_value
사용자를 비활성화하려면 다음을 수행합니다.
dn: distinguished_name
changetype: modify
replace: nsAccountLock
nsAccountLock: TRUE
사용자를 활성화하려면 다음을 수행합니다.
dn: distinguished_name
changetype: modify
replace: nsAccountLock
nsAccountLock: FALSE
사용자를 보존하려면 다음을 수행합니다.
dn: distinguished_name
changetype: modrdn
newrdn: uid=user_login
deleteoldrdn: 0
newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example
nssAccountLock 특성을 업데이트해도 스테이지 및 보존된 사용자에게는 영향을 미치지 않습니다. 업데이트 작업이 성공적으로 완료되었지만 속성 값은 nssAccountLock로 유지됩니다. TRUE.
새 그룹 만들기
새 그룹을 생성하려면 다음을 수행합니다.
dn: cn=group_distinguished_name,cn=groups,cn=accounts,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaobject
objectClass: ipausergroup
objectClass: groupofnames
objectClass: nestedgroup
objectClass: posixgroup
cn: group_name
gidNumber: GID_number
그룹 수정
그룹을 수정하기 전에 그룹 이름으로 검색하여 그룹의 고유 이름(DN)을 가져옵니다.
# ldapsearch -YGSSAPI  -H ldap://server.example.com -b "cn=groups,cn=accounts,dc=example,dc=com" "cn=group_name"
기존 그룹을 삭제하려면 다음을 수행합니다.
dn: group_distinguished_name
changetype: delete
그룹에 멤버를 추가하려면 다음을 수행합니다.
dn: group_distinguished_name
changetype: modify
add: member
member: uid=user_login,cn=users,cn=accounts,dc=example,dc=com
그룹에서 멤버를 제거하려면 다음을 수행합니다.
dn: distinguished_name
changetype: modify
delete: member
member: uid=user_login,cn=users,cn=accounts,dc=example,dc=com
스테이징 또는 보존된 사용자를 그룹에 추가하지 마십시오. 업데이트 작업이 성공적으로 완료되지만 사용자는 그룹의 멤버로 업데이트되지 않습니다. 활성 사용자만 그룹에 속할 수 있습니다.

예 11.2. ldapmodify를 사용하여 단계 사용자 추가

표준 interorgperson 오브젝트 클래스를 사용하여 새 stageuser 사용자를 추가하려면 다음을 수행합니다.
  1. ldapmodify 를 사용하여 사용자를 추가합니다.
    # ldapmodify -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: admin@EXAMPLE
    SASL SSF: 56
    SASL data security layer installed.
    dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    cn: Stage
    sn: User
    
    adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example"
    
  2. 스테이징 항목의 콘텐츠의 유효성을 검사하여 프로비저닝 시스템이 필요한 모든 POSIX 속성을 추가하고 stage 항목을 활성화할 준비가 되었는지 확인합니다. ipa stageuser-show --all --raw 명령을 사용하여 새 단계 사용자의 LDAP 속성을 표시합니다. 사용자는 nsaccountlock 특성을 통해 명시적으로 비활성화되어 있습니다.
    $ ipa stageuser-show stageuser --all --raw
      dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example
      uid: stageuser
      sn: User
      cn: Stage
      has_password: FALSE
      has_keytab: FALSE
      nsaccountlock: TRUE
      objectClass: top
      objectClass: inetorgperson
      objectClass: organizationalPerson
      objectClass: person
    

예 11.3. ldapmodify를 사용하여 사용자 유지

LDAP modrdn 작업을 사용하여 사용자를 보존하려면 다음을 수행합니다.
  1. ldapmodify 유틸리티를 사용하여 사용자 항목을 수정합니다.
    $ ldapmodify -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: admin@EXAMPLE
    SASL SSF: 56
    SASL data security layer installed.
    dn: uid=user1,cn=users,cn=accounts,dc=example
    changetype: modrdn
    newrdn: uid=user1
    deleteoldrdn: 0
    newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example
    
    modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=example"
    
  2. 필요한 경우, 보존된 사용자를 모두 나열하여 사용자가 보존되었는지 확인합니다.
    $ ipa user-find --preserved=true
    ---------------
    1 user matched
    ---------------
      User login: user1
      First name: first_name
      Last name: last_name
    ...
    ----------------------------
    Number of entries returned 1
    ----------------------------
    

12장. 호스트 관리

DNS와 Kerberos 모두 초기 클라이언트 구성의 일부로 구성됩니다. 이 두 서비스는 IdM 도메인에 시스템을 가져와 연결할 IdM 서버를 식별할 수 있도록 하기 때문에 필요합니다. 초기 구성 후 IdM에는 도메인 서비스 변경, IT 환경 변경 또는 Kerberos, 인증서 및 DNS 서비스에 영향을 미치는 시스템 자체 변경에 대한 응답으로 이러한 서비스를 모두 관리하는 툴이 있습니다.
이 장에서는 클라이언트 시스템과 직접 관련된 ID 서비스를 관리하는 방법을 설명합니다.
  • DNS 항목 및 설정
  • 머신 인증
  • 호스트 이름 변경(도메인 서비스에 영향을 미치는)

12.1. 호스트, 서비스 및 시스템 ID 및 인증 정보

등록 프로세스의 기본 기능은 IdM 디렉터리에 클라이언트 시스템에 대한 호스트 항목을 생성하는 것입니다. 이 호스트 항목은 도메인 내의 다른 호스트와 서비스( 1장. Red Hat Identity Management 소개에 설명된 대로) 간의 관계를 설정하는 데 사용됩니다. 이러한 관계는 도메인 내 호스트에 대한 권한 및 제어를 위임하는 데 사용됩니다.
호스트 항목에는 IdM 내의 클라이언트에 대한 모든 정보가 포함되어 있습니다.
  • 호스트와 관련된 서비스 항목
  • 호스트 및 서비스 주체
  • 액세스 제어 규칙
  • 물리적 위치 및 운영 체제와 같은 머신 정보
호스트에서 실행되는 일부 서비스도 IdM 도메인에 속할 수 있습니다. Kerberos 사용자 또는 SSL 인증서(또는 둘 다)를 저장할 수 있는 모든 서비스를 IdM 서비스로 구성할 수 있습니다. IdM 도메인에 서비스를 추가하면 서비스에서 도메인에서 SSL 인증서 또는 keytab을 요청할 수 있습니다. (인증서의 공개 키만 서비스 레코드에 저장됩니다. 개인 키는 서비스의 로컬입니다.)
IdM 도메인은 일반적인 ID 정보, 공통 정책 및 공유 서비스를 사용하여 시스템 간 공통성을 설정합니다. 도메인 기능에 속하는 모든 머신은 도메인의 클라이언트로, 도메인에서 제공하는 서비스를 사용합니다. IdM 도메인은 특히 시스템용 세 가지 주요 서비스를 제공합니다.
  • DNS
  • Kerberos
  • 인증서 관리
사용자와 마찬가지로 시스템은 IdM에서 관리하는 ID입니다. 클라이언트 시스템은 DNS를 사용하여 IdM 서버, 서비스 및 도메인 멤버를 식별합니다. 이러한 ID는 IdM 서버의 389 Directory Server 인스턴스에 저장됩니다. 사용자와 마찬가지로 시스템은 Kerberos 또는 인증서를 사용하여 도메인에 인증할 수 있습니다.
시스템 관점에서 이러한 도메인 서비스에 액세스하는 몇 가지 작업을 수행할 수 있습니다.
  • DNS 도메인 가입 (시스템 등록)
  • DNS 항목 및 영역 관리
  • 머신 인증 관리
IdM의 인증에는 시스템 및 사용자도 포함됩니다. IdM 서버가 시스템을 신뢰하고 해당 시스템에 설치된 클라이언트 소프트웨어의 IdM 연결을 수락하려면 시스템 인증이 필요합니다. 클라이언트를 인증한 후 IdM 서버는 요청에 응답할 수 있습니다. IdM은 시스템 인증에 대한 세 가지 접근 방식을 지원합니다.
  • SSH 키. 호스트의 SSH 공개 키는 생성되어 호스트 항목에 업로드됩니다. 여기에서 SSSD(System Security Services Daemon)는 IdM을 ID 공급자로 사용하며 OpenSSH 및 기타 서비스와 협력하여 ID 관리에 중앙에 있는 공개 키를 참조할 수 있습니다. 자세한 내용은 12.5절. “호스트의 공개 SSH 키 관리” 에서 참조하십시오.
  • 키 테이블(또는 키탭, 사용자 암호의 일부 범위로 결합되는 대칭 키) 및 시스템 인증서입니다. Kerberos 티켓은 서버에서 정의한 Kerberos 서비스 및 정책의 일부로 생성됩니다. 처음에는 Kerberos 티켓을 부여하고 Kerberos 자격 증명을 갱신하며 Kerberos 세션을 제거하더라도 IdM 서비스에서 처리합니다. Kerberos 관리에 대해서는 29장. Kerberos 도메인 관리 에서 다룹니다.
  • 시스템 인증서. 이 경우 시스템은 IdM 서버의 인증 기관에서 발급한 다음 IdM의 디렉터리 서버에 저장된 SSL 인증서를 사용합니다. 그런 다음 서버에 인증할 때 인증서를 표시하도록 시스템으로 전송됩니다. 클라이언트에서 인증서는 certmonger 라는 서비스에 의해 관리됩니다.

12.2. 호스트 항목 구성 속성 정보

호스트 항목에는 시스템 구성 외부에 있는 호스트(예: 물리적 위치, MAC 주소, 키 및 인증서)에 대한 정보가 포함될 수 있습니다.
이 정보는 수동으로 만드는 경우 설정할 수 있습니다. 그렇지 않으면 대부분의 정보를 도메인에 등록한 후 호스트 항목에 추가해야 합니다.

표 12.1. 호스트 구성 속성

UI 필드 명령줄 옵션 Description
Description --desc=description 호스트에 대한 설명입니다.
지역 --locality=locality 호스트의 지리적 위치입니다.
위치 --location=location 호스트의 물리적 위치(예: 데이터 센터 랙).
platform --platform=string 호스트 하드웨어 또는 아키텍처.
운영 체제 --os=string 호스트의 운영 체제 및 버전입니다.
MAC 주소 --macaddress=address 호스트의 MAC 주소입니다. 이것은 다중 값 속성입니다. MAC 주소는 NIS 플러그인에서 호스트에 대한 NIS ethers 맵을 생성하는 데 사용됩니다.
SSH 공개 키 --sshpubkey=string 호스트에 대한 전체 SSH 공개 키입니다. 이것은 다중 값 특성이므로 여러 개의 키를 설정할 수 있습니다.
기본 이름 (편집할 수 없음) --principalname=principal 호스트의 Kerberos 주체 이름입니다. 이는 클라이언트 설치 중에 기본적으로 다른 주체가 -p 에 명시적으로 설정되지 않은 한 호스트 이름입니다. 명령줄 툴을 사용하여 변경할 수 있지만 UI에서는 변경할 수 없습니다.
일회성 암호 설정 --password=string 대규모 등록에 사용할 수 있는 호스트의 암호를 설정합니다.
- --random 대규모 등록에 사용할 임의 암호를 생성합니다.
- --certificate=string 호스트의 인증서 Blob.
- --updatedns 이는 IP 주소가 변경되는 경우 호스트에서 DNS 항목을 동적으로 업데이트할 수 있는지 여부를 설정합니다.

12.3. 호스트 항목 추가

12.3.1. 웹 UI에서 호스트 항목 추가

  1. Identity (ID) 탭을 열고 Hosts (호스트)를 선택합니다.
  2. 호스트 목록 상단에 있는 추가 를 클릭합니다.

    그림 12.1. 호스트 항목 추가

    호스트 항목 추가
  3. 시스템 이름을 입력하고 드롭다운 목록에 구성된 영역에서 도메인을 선택합니다. 호스트에 이미 정적 IP 주소가 할당되어 DNS 항목이 완전히 생성되도록 호스트 항목에 포함합니다.
    필요한 경우 경우에 따라 일부 사용 사례에 대해 호스트에 추가 값을 추가하려면 Class 필드를 사용합니다. 이 속성에 배치 된 의미가 로컬 해석을 위한 것입니다.

    그림 12.2. 호스트 마법사 추가

    호스트 마법사 추가
    DNS 영역은 33.4.1절. “마스터 DNS 영역 추가 및 제거” 에 설명된 IdM에서 생성할 수 있습니다. IdM 서버가 DNS 서버를 관리하지 않는 경우 일반 텍스트 필드와 같이 메뉴 영역에 영역을 수동으로 입력할 수 있습니다.
    참고
    호스트를 DNS를 통해 확인할 수 있는지 여부를 건너뛰려면 Force 확인란을 선택합니다.
  4. 추가 및 편집 버튼을 클릭하여 확장된 항목 페이지로 직접 이동하여 더 많은 속성 정보를 입력합니다. 호스트 하드웨어 및 물리적 위치에 대한 정보는 호스트 항목에 포함될 수 있습니다.

    그림 12.3. 확장된 엔트리 페이지

    확장된 엔트리 페이지

12.3.2. 명령줄에서 호스트 항목 추가

호스트 항목은 host-add 명령을 사용하여 생성합니다. 이 명령은 IdM Directory Server에 호스트 항목을 추가합니다. host-add 를 사용하여 전체 옵션 목록은 ipa 호스트 manpage에 나열되어 있습니다. 가장 기본적인 추가 작업에는 클라이언트 호스트 이름만 Kerberos 영역에 추가하고 IdM LDAP 서버에서 항목을 생성하는 데만 있으면 됩니다.
$ ipa host-add client1.example.com
IdM 서버가 DNS를 관리하도록 구성된 경우 --ip-address--force 옵션을 사용하여 DNS 리소스 레코드에 호스트를 추가할 수도 있습니다.

예 12.1. 정적 IP 주소를 사용하여 호스트 항목 생성

$ ipa host-add --force --ip-address=192.168.166.31 client1.example.com
일반적으로 호스트에는 정적 IP 주소가 없을 수도 있고 클라이언트가 구성된 시점에 IP 주소를 알 수 없을 수도 있습니다. 예를 들어, 랩북은 Identity Management 클라이언트로 미리 구성될 수 있지만, 구성되는 시점에는 IP 주소가 없습니다. DHCP를 사용하는 호스트는 --force 를 사용하여 DNS 항목으로 구성할 수 있습니다. 기본적으로 IdM DNS 서비스에 자리 표시자 항목을 생성합니다. DNS 서비스가 레코드를 동적으로 업데이트하면 호스트의 현재 IP 주소가 탐지되고 해당 DNS 레코드가 업데이트됩니다.

예 12.2. DHCP를 사용하여 호스트 항목 생성

$ ipa host-add --force client1.example.com
호스트 레코드는 host-del 명령을 사용하여 삭제됩니다. IdM 도메인에서 DNS를 사용하는 경우 --updatedns 옵션은 DNS에서 호스트의 관련 레코드도 제거합니다.
$ ipa host-del --updatedns client1.example.com

12.4. 호스트 항목 비활성화 및 재활성화

활성 호스트는 도메인 내의 다른 서비스, 호스트 및 사용자가 액세스할 수 있습니다. 활동에서 호스트를 제거해야 하는 경우가 있을 수 있습니다. 그러나 호스트를 삭제하면 항목 및 연결된 모든 구성이 제거되며 영구적으로 제거됩니다.

12.4.1. 호스트 항목 비활성화

호스트를 비활성화하면 도메인 사용자가 도메인에서 영구히 제거하지 않고 액세스할 수 없습니다. host-disable 명령을 사용하여 이 작업을 수행할 수 있습니다.
예를 들어 다음과 같습니다.
[jsmith@ipaserver ~]$ kinit admin
[jsmith@ipaserver ~]$ ipa host-disable server.example.com
중요
호스트 항목을 비활성화하면 해당 호스트를 비활성화할 뿐만 아니라. 해당 호스트에서 구성된 모든 서비스도 비활성화합니다.

12.4.2. 호스트 재활성화

이 섹션에서는 비활성화된 IdM 호스트를 다시 활성화하는 방법을 설명합니다.
호스트를 비활성화하면 활성 키탭이 제거되어 구성 항목을 변경하지 않고 IdM 도메인에서 호스트를 제거했습니다.
호스트를 다시 활성화하려면 ipa-getkeytab 명령을 사용하여 다음을 추가합니다.
  • 키탭을 요청할 IdM 서버를 지정하는 -s 옵션
  • 주 이름을 지정하는 -p 옵션
  • 키탭을 저장할 파일을 지정하는 -k 옵션.
예를 들어 client.example.com 용으로 server.example.com 에서 새 호스트 키 탭을 요청하고 해당 keytab을 /etc/krb5.keytab 파일에 저장하려면 다음을 수행합니다.
$ ipa-getkeytab -s server.example.com -p host/client.example.com -k /etc/krb5.keytab -D "cn=directory manager" -w password
참고
관리자의 자격 증명을 사용하여 -D "uid=admin,cn=users,cn=accounts,dc=example,dc=com" 을 지정할 수도 있습니다. 자격 증명이 호스트에 대한 키탭을 만들 수 있는 사용자에 해당하는 것이 중요합니다.
활성 IdM 클라이언트 또는 서버에서 ipa-getkeytab 명령을 실행하는 경우 사용자에게 kinit admin 과 같은 방법으로 TGT를 얻은 경우 LDAP 자격 증명(-D-w) 없이 실행할 수 있습니다. 비활성화된 호스트에서 직접 명령을 실행하려면 LDAP 자격 증명을 제공하여 IdM 서버에 인증합니다.

12.5. 호스트의 공개 SSH 키 관리

OpenSSH는 공개 키를 사용하여 호스트를 인증합니다. 한 시스템에서 다른 시스템에 액세스를 시도하고 해당 키 쌍을 표시합니다. 호스트가 처음 인증될 때 대상 시스템의 관리자는 요청을 수동으로 승인해야 합니다. 그런 다음 시스템은 known_hosts 파일에 호스트의 공개 키를 저장합니다. 원격 시스템이 대상 시스템에 다시 액세스하려고 할 때마다 대상 시스템은 known_hosts 파일을 확인한 다음 승인된 호스트에 대한 액세스 권한을 자동으로 부여합니다.
이 시스템에는 몇 가지 문제가 있습니다.
  • known_hosts 파일은 호스트 IP 주소, 호스트 이름 및 키의 중단에 호스트 항목을 저장합니다. 이 파일은 IP 주소가 변경되거나(가상 환경 및 데이터 센터에서 일반적으로) 키가 업데이트되는 경우 최신 상태가 될 수 있습니다.
  • SSH 키는 환경의 모든 시스템에 수동 및 별도로 배포해야 합니다.
  • 관리자는 호스트 키를 승인하여 구성에 추가할 수 있지만, 호스트 또는 키 발행자를 올바르게 확인하여 보안 문제를 생성할 수 있습니다.
Red Hat Enterprise Linux에서 SSSD(System Security Services Daemon)는 호스트 SSH 키를 캐시 및 검색하여 애플리케이션 및 서비스가 호스트 키의 한 위치만 찾도록 구성할 수 있습니다. SSSD는 ID 정보 공급자 중 하나로 Identity Management를 사용할 수 있으므로 Identity Management는 키의 범용이고 중앙 집중식 리포지토리를 제공합니다. 관리자는 호스트 SSH 키 배포, 업데이트 또는 확인에 대해 걱정할 필요가 없습니다.

12.5.1. SSH 키 형식 정보

키가 IdM 항목에 업로드되면 키 형식은 OpenSSH 스타일 키 또는 원시 RFC 4253 스타일 Blob 일 수 있습니다. 모든 RFC 4253 스타일 키는 IdM LDAP 서버에 가져와 저장하기 전에 자동으로 OpenSSH 스타일 키로 변환됩니다.
IdM 서버는 업로드된 키 Blob에서 RSA 또는 DSA 키와 같은 키 유형을 식별할 수 있습니다. 그러나 ~/.ssh/known_hosts 와 같은 키 파일에서 키 항목은 서버의 호스트 이름 및 IP 주소, 해당 유형, 키 자체로 식별됩니다. 예를 들어 다음과 같습니다.
host.example.com,1.2.3.4 ssh-rsa AAA...ZZZ==
이 키 항목은 순서 유형 key== 주석에 요소가 있는 사용자 공개 키 항목과 약간 다릅니다.
"ssh-rsa ABCD1234...== ipaclient.example.com"
키 파일에서 세 부분 모두 에 업로드하고 호스트 항목에 대해 볼 수 있습니다. 이 경우 ~/.ssh/known_hosts 파일의 호스트 공개 키 항목을 사용자 키의 형식과 일치하도록 다시 정렬해야 합니다. key= comment:
ssh-rsa AAA...ZZZ== host.example.com,1.2.3.4
키 유형은 공개 키의 콘텐츠에서 자동으로 결정할 수 있으며, 주석은 개별 키를 쉽게 식별할 수 있도록 선택 사항입니다. 유일한 필수 요소는 공개 키 Blob 자체입니다.

12.5.2. ipa-client-install 및 OpenSSH 정보

기본적으로 ipa-client-install 스크립트는 IdM 클라이언트 시스템에 OpenSSH 서버 및 클라이언트를 구성합니다. 또한 호스트 및 사용자 키 캐싱을 수행하도록 SSSD를 구성합니다. 기본적으로 클라이언트 구성은 호스트에서 키 캐싱 및 검색에 SSSD, OpenSSH 및 Identity Management를 사용하는 데 필요한 모든 구성을 수행합니다.
클라이언트 설치(기본값)를 사용하여 SSH 서비스를 활성화하면 ssh 서비스가 처음 시작될 때 RSA 키가 생성됩니다.
참고
ipa-client-install 을 사용하여 시스템을 IdM 클라이언트로 추가하면 클라이언트가 RSA 및ECDHE의 두 개의 SSH 키를 사용하여 생성됩니다.
추가 클라이언트 구성 옵션인 --ssh-trust-dns 가 있습니다. 이 옵션은 ipa-client-install 을 사용하여 실행할 수 있으며 키 지문이 저장된 IdM DNS 레코드를 신뢰하도록 OpenSSH를 자동으로 구성합니다.
또는 --no-sshd 옵션을 사용하여 클라이언트를 설치할 때 OpenSSH를 비활성화할 수 있습니다. 이렇게 하면 설치 스크립트가 OpenSSH 서버를 구성하지 못합니다.
또 다른 옵션인 --no-dns-sshfp 를 사용하면 호스트가 자체 DNS 항목을 사용하여 DNS SSHFP 레코드를 생성하지 못합니다. 이 옵션은 --no-sshd 옵션과 함께 사용하거나 사용하지 않고 사용할 수 있습니다.

12.5.3. 웹 UI를 통해 호스트 SSH 키 업로드

  1. 호스트의 키는 ~/.ssh/known_hosts 에서 검색할 수 있습니다. 예를 들어 다음과 같습니다.
    server.example.com,1.2.3.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApvjBvSFSkTU0WQW4eOweeo0DZZ08F9Ud21xlLy6FOhzwpXFGIyxvXZ52+siHBHbbqGL5+14N7UvElruyslIHx9LYUR/pPKSMXCGyboLy5aTNl5OQ5EHwrhVnFDIKXkvp45945R7SKYCUtRumm0Iw6wq0XD4o+ILeVbV3wmcB1bXs36ZvC/M6riefn9PcJmh6vNCvIsbMY6S+FhkWUTTiOXJjUDYRLlwM273FfWhzHK+SSQXeBp/zIn1gFvJhSZMRi9HZpDoqxLbBB9QIdIw6U4MIjNmKsSI/ASpkFm2GuQ7ZK9KuMItY2AoCuIRmRAdF8iYNHBTXNfFurGogXwRDjQ==
    필요한 경우 호스트 키를 생성합니다. OpenSSH 툴을 사용하는 경우 빈 암호를 사용하고 사용자 ~/.ssh/ 디렉터리가 아닌 다른 위치에 키를 저장하려면 기존 키를 덮어쓰지 않도록 해야 합니다.
    [jsmith@server ~]$ ssh-keygen -t rsa -C "server.example.com,1.2.3.4"
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/jsmith/.ssh/id_rsa): /home/jsmith/.ssh/host_keys
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/jsmith/.ssh/host_keys.
    Your public key has been saved in /home/jsmith/.ssh/host_keys.pub.
    The key fingerprint is:
    SHA256:GAUIDVVEgly7rs1lTWP6oguHz8BKvyZkpqCqVSsmi7c server.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |              .. |
    |               .+|
    |          o   .* |
    |         o . .. *|
    |        S + .  o+|
    |         E . .. .|
    |        . = .  o |
    |         o .  ..o|
    |            .....|
    +-----------------+
  2. 키 파일에서 공개 키를 복사합니다. 전체 키 항목의 형식은 호스트 이름,IP 유형 key== 입니다. key== 만 필요하지만 전체 항목을 저장할 수 있습니다. 항목의 모든 요소를 사용하려면 주문 유형 key= [host name,IP]가 있도록 항목을 다시 정렬합니다.
    [jsmith@server ~]$ cat /home/jsmith/.ssh/host_keys.pub
    
    ssh-rsa AAAAB3NzaC1yc2E...tJG1PK2Mq++wQ== server.example.com,1.2.3.4
  3. Identity (ID) 탭을 열고 Hosts (호스트)를 선택합니다.
  4. 편집할 호스트 이름을 클릭합니다.

    그림 12.4. 호스트 목록

    호스트 목록
  5. Settings 탭의 Host Settings 영역에서 SSH 공개 키 옆에 있는 추가 를 클릭합니다.

    그림 12.5. SSH 키 추가

    SSH 키 추가
  6. 호스트의 공개 키에 붙여넣고 설정을 클릭합니다.

    그림 12.6. SSH 키 설정

    SSH 키 설정
    이제 SSH 공개 키 영역에 새 키가 표시됩니다. Show/Set 키를 클릭하면 제출된 키가 열립니다.
  7. 여러 키를 업로드하려면 공개 키 목록 아래의 추가 링크를 클릭하고 다른 키를 업로드합니다.
  8. 모든 키가 제출되면 호스트 페이지 상단에서 저장 을 클릭하여 변경 사항을 저장합니다.
공개 키가 저장되면 항목이 키 지문으로 표시되고, 주석(포함된 경우), 키 유형[2].
호스트 키를 업로드한 후 Identity Management를 ID 도메인 중 하나로 사용하도록 SSSD를 구성하고 22.6절. “OpenSSH 서비스에 캐시를 제공하도록 SSSD 구성” 에서 다루는 호스트 키 관리에 SSSD 툴링을 사용하도록 OpenSSH를 설정합니다.

12.5.4. 명령줄에서 호스트 키 추가

호스트 SSH 키는 호스트 추가를 사용하여 호스트를 생성할 때 또는 나중에 항목을 수정하여 IdM의 호스트 항목에 추가됩니다.
참고
RSA 및ECDHE 호스트 키는 설치 스크립트에서 SSH 서비스가 명시적으로 비활성화되지 않는 한 ipa-client-install 명령으로 생성됩니다.
  1. --sshpubkey 옵션과 함께 host-mod 명령을 실행하여 base64로 인코딩된 공개 키를 호스트 항목에 업로드합니다.
    호스트 키를 추가하면 호스트의 DNS SSHFP 항목도 변경되므로 --updatedns 옵션을 사용하여 호스트의 DNS 항목을 업데이트합니다.
    예를 들어 다음과 같습니다.
    [jsmith@server ~]$ ipa host-mod --sshpubkey="ssh-rsa RjlzYQo==" --updatedns host1.example.com
    실제 키는 일반적으로 등호(=)로 종료되지만 더 길어집니다.
    두 개 이상의 키를 업로드하려면 --sshpubkey 명령줄 매개변수를 여러 개 입력하십시오.
    --sshpubkey="RjlzYQo==" --sshpubkey="ZEt0TAo=="
    참고
    호스트에는 공개 키가 여러 개 있을 수 있습니다.
  2. 호스트 키를 업로드한 후 Identity Management를 ID 도메인 중 하나로 사용하도록 SSSD를 구성하고 22.6절. “OpenSSH 서비스에 캐시를 제공하도록 SSSD 구성” 에서 다루는 호스트 키 관리에 SSSD 툴링을 사용하도록 OpenSSH를 설정합니다.

12.5.5. 호스트 키 제거

호스트 키는 만료되면 제거할 수 있거나 더 이상 유효하지 않습니다.
개별 호스트 키를 제거하려면 웹 UI를 통해 키를 제거하는 것이 가장 쉽습니다.
  1. Identity (ID) 탭을 열고 Hosts (호스트)를 선택합니다.
  2. 편집할 호스트 이름을 클릭합니다.

    그림 12.7. 호스트 목록

    호스트 목록
  3. SSH 공개 키 영역에서 키 지문으로 삭제 를 클릭하여 제거합니다.

    그림 12.8. 공개 키 삭제

    공개 키 삭제
  4. 호스트 페이지 상단에서 저장 을 클릭하여 변경 사항을 저장합니다.
명령줄 툴을 사용하여 모든 키를 제거할 수 있습니다. 이 작업은 --sshpubkey= 가 빈 값으로 설정된 ipa host-mod 를 실행하여 수행됩니다. 그러면 호스트의 모든 공개 키가 제거됩니다. 또한 --updatedns 옵션을 사용하여 호스트의 DNS 항목을 업데이트합니다. 예를 들어 다음과 같습니다.
[jsmith@server ~]$ kinit admin
[jsmith@server ~]$ ipa host-mod --sshpubkey= --updatedns host1.example.com


[2] 키 유형이 업로드된 키에 포함되지 않은 경우 키 자체에서 자동으로 결정됩니다.

12.6. 호스트에 대한 ethers 정보 설정

NIS는 플랫폼, 운영 체제, DNS 도메인, MAC 주소에 따라 시스템의 DHCP 구성 파일을 관리하는 데 사용할 수 있는 ethers 테이블을 호스팅할 수 있습니다. IdM의 호스트 항목에 저장된 모든 정보입니다.
Identity Management에서 각 시스템은 ou= ethers 하위 트리의 디렉터리에 해당 ethers 항목을 사용하여 생성됩니다.
cn=server,ou=ethers,dc=example,dc=com
이 항목은 IdM에서 NIS 호환성 플러그인에서 관리할 수 있는 ethers 서비스에 대한 NIS 맵을 생성하는 데 사용됩니다.
ethers 항목에 대한 NIS 맵을 구성하려면 다음을 수행합니다.
  1. MAC address 속성을 호스트 항목에 추가합니다. 예를 들어 다음과 같습니다.
    [jsmith@server ~]$ kinit admin
    [jsmith@server ~]$ ipa host-mod --macaddress=12:34:56:78:9A:BC server.example.com
  2. nsswitch.conf 파일을 엽니다.
  3. ethers 서비스에 대한 행을 추가하고 조회에 LDAP를 사용하도록 설정합니다.
    ethers: ldap
  4. 클라이언트에서 ethers 정보를 사용할 수 있는지 확인합니다.
    [root@server ~]# getent ethers server.example.com

13장. 사용자 및 호스트 그룹 관리

13.1. IdM에서 사용자 및 호스트 그룹 작업 방식

13.1.1. 사용자 및 호스트 그룹의 정의

사용자 그룹은 공통 권한, 암호 정책 및 기타 특성을 가진 사용자 집합입니다.
호스트 그룹은 일반적인 액세스 제어 규칙과 기타 특성을 가진 IdM 호스트 집합입니다.
예를 들어 회사 부서, 물리적 위치 또는 액세스 제어 요구 사항에 대한 그룹을 정의할 수 있습니다.

13.1.2. 지원되는 그룹 멤버

IdM의 사용자 그룹은 다음을 포함할 수 있습니다.
  • IdM 사용자
  • 기타 IdM 사용자 그룹
  • IdM 외부에 존재하는 외부 사용자
IdM의 호스트 그룹은 다음을 포함할 수 있습니다.
  • IdM 서버 및 클라이언트
  • 기타 IdM 호스트 그룹

13.1.3. 직접 및 간접 그룹 멤버

IdM의 사용자 및 호스트 그룹 속성은 직접 및 간접 멤버 모두에 적용됩니다. B 그룹이 A 그룹의 멤버인 경우 B 그룹의 모든 사용자는 A 그룹의 멤버로 간주됩니다.
예를 들면 그림 13.1. “직접 및 간접 그룹 멤버쉽” 에서 다음을 수행합니다.
  • 사용자 1 및 사용자 2는 A 그룹의 직접 구성원 입니다.
  • 사용자 3, 사용자 4 및 사용자 5는 A 그룹의 간접 구성원 입니다.

그림 13.1. 직접 및 간접 그룹 멤버쉽

직접 및 간접 그룹 멤버쉽
사용자 그룹 A에 대한 암호 정책을 설정한 경우 정책은 사용자 그룹 B의 모든 사용자에게도 적용됩니다.

예 13.1. 직접 및 간접 그룹 멤버 보기

  1. group_Agroup_B 그룹 두 그룹을 생성합니다. 13.2절. “사용자 또는 호스트 그룹 추가 및 제거” 참조하십시오.
  2. 추가:
    • group_A의 멤버인 한 사용자
    • group_B의 멤버인 또 다른 사용자
    • group_Bgroup_A의 멤버로
  3. 웹 UI에서 다음을 수행합니다. IdentityGroups 를 선택합니다. 왼쪽의 사이드 표시줄에 나열된 개별 그룹 유형에서 User Groups 를 선택하고 group_A 의 이름을 클릭합니다. 직접 멤버십과 Indirect Membership 간에 전환하십시오.

    그림 13.2. 간접 및 직접 멤버

    간접 및 직접 멤버
  4. 명령줄에서 다음을 수행합니다. ipa group-show 명령을 사용합니다.
    $ ipa group-show group_A
      ...
      Member users: user_1
      Member groups: group_B
      Indirect Member users: user_2
간접 멤버 목록에는 신뢰할 수 있는 Active Directory 도메인의 외부 사용자가 포함되지 않습니다. Active Directory 신뢰 사용자 오브젝트는 IdM 내에 LDAP 오브젝트로 존재하지 않기 때문에 IdM 인터페이스에 표시되지 않습니다.

13.1.4. IdM의 사용자 그룹 유형

POSIX 그룹 (기본값)
POSIX 그룹은 해당 멤버에 대해 POSIX 속성을 지원합니다. Active Directory와 상호 작용하는 그룹은 POSIX 속성을 사용할 수 없습니다.
non-POSIX 그룹
이 유형의 모든 그룹 멤버는 IdM 도메인에 속해야 합니다.
외부 그룹
외부 그룹을 사용하면 IdM 도메인 외부의 ID 저장소에 존재하는 그룹 멤버를 추가할 수 있습니다. 외부 저장소는 로컬 시스템, Active Directory 도메인 또는 디렉터리 서비스일 수 있습니다.
비POSIX 및 외부 그룹은 POSIX 특성을 지원하지 않습니다. 예를 들어 이러한 그룹에는 GID가 정의되어 있지 않습니다.

예 13.2. 다양한 유형의 사용자 그룹 검색

  1. ipa group-find 명령을 실행하여 모든 사용자 그룹을 표시합니다.
  2. ipa group-find --posix 명령을 실행하여 모든 POSIX 그룹을 표시합니다.
  3. ipa group-find --nonposix 명령을 실행하여 모든 비POSIX 그룹을 표시합니다.
  4. ipa group-find --external 명령을 실행하여 모든 외부 그룹을 표시합니다.

13.1.5. 기본값으로 생성된 사용자 및 호스트 그룹

표 13.1. 기본값으로 생성된 사용자 및 호스트 그룹

그룹 이름 사용자 또는 호스트 기본 그룹 멤버
ipausers 사용자 그룹 모든 IdM 사용자
admins 사용자 그룹 처음 기본 admin 사용자인 관리자 권한이 있는 사용자
editors 사용자 그룹 관리 사용자의 모든 권한 없이 웹 UI에서 다른 IdM 사용자를 편집할 수 있는 사용자
신뢰 관리자 사용자 그룹 Active Directory 트러스트를 관리할 수 있는 권한이 있는 사용자
ipaservers 호스트 그룹 모든 IdM 서버 호스트
사용자 그룹에 사용자를 추가하면 그룹과 연결된 권한 및 정책을 적용합니다. 예를 들어 admins 그룹에 사용자를 추가하면 사용자에게 관리 권한이 부여됩니다.
주의
admins 그룹을 삭제하지 마십시오. admins 는 IdM에 필요한 사전 정의된 그룹이므로 이 작업으로 인해 특정 명령에 문제가 발생합니다.
주의
ipaservers 호스트 그룹에 호스트를 추가할 때는 주의하십시오. ipaservers 의 모든 호스트에서는 IdM 서버로 승격할 수 있습니다.
또한 IdM에서 새 사용자가 생성될 때마다 기본적으로 사용자 개인 그룹을 생성합니다.
  • 사용자 개인 그룹의 이름은 해당 그룹이 생성된 사용자와 동일합니다.
  • 사용자는 사용자 개인 그룹의 유일한 멤버입니다.
  • 개인 그룹의 GID는 사용자의 UID와 일치합니다.

예 13.3. 사용자 개인 그룹 보기

ipa group-find --private 명령을 실행하여 모든 사용자 개인 그룹을 표시합니다.
$ ipa group-find --private
----------------
2 groups matched
----------------
  Group name: user1
  Description: User private group for user1
  GID: 830400006

  Group name: user2
  Description: User private group for user2
  GID: 830400004
----------------------------
Number of entries returned 2
----------------------------
경우에 따라 NIS 그룹 또는 다른 시스템 그룹이 사용자 개인 그룹에 할당될 GID를 이미 사용하는 경우와 같이 사용자 개인 그룹을 생성하지 않는 것이 좋습니다. 13.4절. “사용자 개인 그룹 비활성화” 참조하십시오.

13.2. 사용자 또는 호스트 그룹 추가 및 제거

그룹을 추가하려면 다음을 사용합니다.
IdM을 사용하면 사용자 그룹을 생성할 때 사용자 지정 GID를 지정할 수 있습니다. 이 경우 ID 충돌을 방지하려면 주의하십시오. 14.6절. “해당 ID 값이 고유하도록 확인” 참조하십시오. 사용자 지정 GID를 지정하지 않으면 IdM에서 사용 가능한 ID 범위에서 GID를 자동으로 할당합니다.
그룹을 제거하려면 다음을 사용합니다.
그룹을 제거해도 IdM에서 그룹 멤버가 삭제되지 않습니다.

웹 UI: 사용자 또는 호스트 그룹 추가

  1. IdentityGroups (ID 그룹)를 클릭하고 왼쪽 사이드바에서 사용자 그룹 또는 호스트 그룹을 선택합니다.
  2. 추가 를 클릭하여 그룹 추가를 시작합니다.
  3. 그룹에 대한 정보를 입력합니다.
    사용자 그룹 유형에 대한 자세한 내용은 13.1.4절. “IdM의 사용자 그룹 유형” 을 참조하십시오.
  4. 추가를 클릭하여 확인합니다.

명령줄: 사용자 또는 호스트 그룹 추가

  1. 관리자로 로그인합니다.
    $ kinit admin
  2. 사용자 그룹을 추가하려면 ipa group-add 명령을 사용합니다. 호스트 그룹을 추가하려면 ipa hostgroup-add 명령을 사용합니다.
    $ ipa group-add group_name
    -----------------------
    Added group "group_name"
    ------------------------
기본적으로 ipa group-add 는 POSIX 사용자 그룹을 추가합니다. 다른 그룹 유형을 지정하려면 ipa group-add 에 옵션을 추가합니다.
  • --nonposix: 비POSIX 그룹 생성
  • 외부 그룹을 만들 --external
그룹 유형에 대한 자세한 내용은 13.1.4절. “IdM의 사용자 그룹 유형” 을 참조하십시오.

웹 UI: 사용자 또는 호스트 그룹 제거

  1. IdentityGroups (ID 그룹)를 클릭하고 왼쪽 사이드바에서 사용자 그룹 또는 호스트 그룹을 선택합니다.
  2. 제거할 그룹을 선택하고 삭제 를 클릭합니다.

명령줄: 사용자 또는 호스트 그룹 제거

  1. 관리자로 로그인합니다.
    $ kinit admin
  2. 사용자 그룹을 삭제하려면 ipa group-del group_name 명령을 사용합니다. 호스트 그룹을 삭제하려면 ipa hostgroup-del group_name 명령을 사용합니다.
    $ ipa group-del group_name
    --------------------------
    Deleted group "group_name"
    --------------------------

13.3. 사용자 또는 호스트 그룹 멤버 추가 및 제거

사용자 그룹에 멤버를 추가하려면 다음을 사용할 수 있습니다.
중요
다른 사용자 그룹을 멤버로 추가할 때 재귀적 그룹을 만들지 마십시오. 예를 들어 그룹 A가 그룹 B의 멤버인 경우 그룹 B를 그룹 A의 멤버로 추가하지 마십시오. 재귀 그룹은 예측할 수 없는 동작을 일으킬 수 있습니다.
사용자 그룹에서 멤버를 제거하려면 다음을 사용할 수 있습니다.
참고
사용자 또는 호스트 그룹에 멤버를 추가한 후 ID 관리 환경의 모든 클라이언트에 배포하는 데 약간의 시간이 걸릴 수 있습니다. 이는 지정된 호스트가 사용자, 그룹 또는 넷 그룹을 확인하면 SSSD( System Security Services Daemon )가 먼저 캐시를 살펴보고 누락되거나 만료된 레코드에서만 서버 조회를 수행하기 때문입니다.
호스트 그룹에 즉시 적용되는 변경 사항을 확인하려면 캐시 제거 유틸리티인 sss_cache 를 사용하여 호스트에서 SSSD 캐시를 업데이트합니다. sss_cache 를 사용하여 호스트 그룹의 SSSD 캐시에 있는 현재 레코드를 무효화하면 SSSD 캐시에서 ID 공급자에서 업데이트된 레코드를 검색해야 하므로 변경 사항을 신속하게 실현할 수 있습니다.
SSSD 캐시에서 호스트 그룹 항목을 지우려면 다음을 수행합니다.
# sss_cache -n host_group_name

웹 UI: 사용자 또는 호스트 그룹에 멤버 추가

  1. IdentityGroups (ID 그룹)를 클릭하고 왼쪽 사이드바에서 사용자 그룹 또는 호스트 그룹을 선택합니다.
  2. 그룹 이름을 클릭합니다.
  3. 추가할 그룹 멤버 유형을 선택합니다. 예를 들어 사용자 그룹의 경우사용자, 사용자 그룹 또는 외부 입니다.

    그림 13.3. 사용자 그룹 멤버 추가

    사용자 그룹 멤버 추가
  4. 추가를 클릭합니다.
  5. 추가할 멤버를 선택하고 추가 를 클릭하여 확인합니다.

명령줄: 사용자 그룹에 멤버 추가

  1. 선택 사항입니다. ipa group-find 또는 ipa hostgroup-find 명령을 사용하여 그룹을 찾습니다.
  2. 사용자 그룹에 멤버를 추가하려면 ipa group-add-member 명령을 사용합니다. 호스트 그룹에 멤버를 추가하려면 ipa hostgroup-add-member 명령을 사용합니다.
    사용자 그룹 멤버를 추가할 때 다음 옵션을 사용하여 멤버를 지정합니다.
    • --users 는 IdM 사용자 추가
    • --external 은 IdM 도메인 외부에 있는 사용자를 DOMAIN\user_name 또는 user_name@domain형식으로 추가합니다.
    • --groups 는 IdM 사용자 그룹 추가
    호스트 그룹 멤버를 추가할 때 다음 옵션을 사용하여 멤버를 지정합니다.
    • --hosts 에서 IdM 호스트 추가
    • --groups 는 IdM 호스트 그룹 추가

    예 13.4. 사용자 그룹에 멤버를 추가하는 명령 예

    user1, user 2group1을 group _name이라는 그룹에 추가하려면 다음을 수행합니다.
    $ ipa group-add-member group_name --users=user1 --users=user2 --groups=group1
    ad_ domain 도메인에서 group_ name이라는 그룹에 ad _ user 를 추가하려면 외부 사용자를 지정하는 방법을 선택할 수 있습니다. 예를 들어 다음과 같습니다.
    $ ipa group-add-member group_name --external='AD_DOMAIN\ad_user'
    $ ipa group-add-member group_name --external='ad_user@AD_DOMAIN'
    $ ipa group-add-member group_name --external='ad_user@AD_DOMAIN.EXAMPLE.COM'
    

웹 UI: 사용자 그룹에서 멤버 제거

  1. IdentityGroups (ID 그룹)를 클릭하고 왼쪽 사이드바에서 사용자 그룹 또는 호스트 그룹을 선택합니다.
  2. 그룹 이름을 클릭합니다.
  3. 제거할 그룹 멤버 유형을 선택합니다. 예를 들어 사용자 그룹의 경우사용자, 사용자 그룹 또는 외부 입니다.

    그림 13.4. 사용자 그룹 멤버 제거

    사용자 그룹 멤버 제거
  4. 필요한 멤버 옆에 있는 확인란을 선택합니다.
  5. 삭제를 클릭합니다.

명령줄: 사용자 그룹에서 멤버 제거

  1. 선택 사항입니다. ipa group-show 또는 ipa hostgroup-show 명령을 사용하여 그룹에 삭제하려는 멤버가 포함되어 있는지 확인합니다.
  2. 사용자 그룹 멤버를 제거하려면 ipa group-remove-member 명령을 사용합니다. 호스트 그룹 멤버를 제거하려면 ipa hostgroup-remove-member 명령을 사용합니다.
    사용자 그룹 멤버를 제거할 때 다음 옵션을 사용하여 멤버를 지정합니다.
    • --users 에서 IdM 사용자 제거
    • --external 은 IdM 도메인 외부에 있는 사용자를 DOMAIN\user_name 또는 user_name@domain형식으로 제거합니다.
    • --groups 는 IdM 사용자 그룹을 제거
    호스트 그룹 멤버를 제거할 때 다음 옵션을 사용하여 멤버를 지정합니다.
    • --hosts 에서 IdM 호스트 제거
    • --groups 는 IdM 호스트 그룹을 제거
    예를 들어 user1, user 2group1을 group _name이라는 그룹에서 제거하려면 :
    $ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1

13.4. 사용자 개인 그룹 비활성화

IdM이 새 사용자의 기본 사용자 개인 그룹을 생성하지 않도록 하려면 다음 중 하나를 선택하십시오.
기본 사용자 개인 그룹 생성을 비활성화한 후에도 새 사용자를 추가할 때 IdM은 GID가 필요합니다. 사용자 추가가 성공했는지 확인하려면 13.4.3절. “사용자 개인 그룹을 사용하여 사용자 추가 비활성화” 을 참조하십시오.
참고
GID 충돌로 인해 기본 사용자 개인 그룹 생성을 비활성화하려면 기본 UID 및 GID 할당 범위를 변경하는 것이 좋습니다. 14장. 고유한 UID 및 GID 번호 할당 참조하십시오.

13.4.1. 사용자 개인 그룹이 없는 사용자 만들기

ipa user-add 명령에 --noprivate 옵션을 추가합니다. 명령이 성공하려면 사용자 지정 개인 그룹을 지정해야 합니다. 13.4.3절. “사용자 개인 그룹을 사용하여 사용자 추가 비활성화” 참조하십시오.

13.4.2. 모든 사용자에 대해 전역적으로 사용자 개인 그룹 비활성화

  1. 관리자로 로그인합니다.
    $ kinit admin
  2. IdM은 Directory Server Managed Entries 플러그인을 사용하여 사용자 개인 그룹을 관리합니다. 플러그인의 인스턴스를 나열합니다.
    $ ipa-managed-entries --list
  3. IdM에서 사용자 개인 그룹을 생성하지 않도록 하려면 사용자 개인 그룹 관리를 담당하는 플러그인 인스턴스를 비활성화합니다.
    $ ipa-managed-entries -e "UPG Definition" disable
    Disabling Plugin
    참고
    나중에 UPG 정의 인스턴스를 다시 활성화하려면 ipa-managed-entries -e "UPG Definition" enable 명령을 사용하십시오.
  4. Directory Server를 다시 시작하여 새 구성을 로드합니다.
    # systemctl restart dirsrv.target

13.4.3. 사용자 개인 그룹을 사용하여 사용자 추가 비활성화

기본 사용자 개인 그룹을 생성할 때 새 사용자를 추가하는 것이 성공했는지 확인하려면 다음 중 하나를 선택하십시오.
  • 새 사용자를 추가할 때 사용자 지정 GID를 지정합니다. GID는 이미 존재하는 사용자 그룹에 해당하지 않아도 됩니다.
    예를 들어 명령줄에서 사용자를 추가할 때 ipa user-add 명령에 --gid 옵션을 추가합니다.
  • automember 규칙을 사용하여 사용자를 GID가 있는 기존 그룹에 추가합니다. 13.6절. “사용자 및 호스트에 대한 자동 그룹 멤버십 정의” 참조하십시오.

13.5. 사용자 및 사용자 그룹에 대한 검색 속성 설정

ipa user-find keywordipa group-find keyword 명령을 사용하여 지정된 키워드에 대한 항목을 검색하는 경우 IdM은 특정 특성만 검색합니다. 가장 중요한 것은 다음과 같습니다.
  • 사용자 검색: 이름, 성, 사용자 이름(로그인 ID), 작업 제목, 조직 단위, 전화 번호, UID, 이메일 주소.
  • 그룹 검색에서 그룹 이름, 설명.
다음 절차에서는 다른 특성을 검색하도록 IdM을 구성하는 방법을 보여줍니다. IdM은 항상 기본 속성을 검색합니다. 예를 들어, 작업 제목 속성을 사용자 검색 속성 목록에서 제거하더라도 IdM은 계속 사용자 제목을 검색합니다.

사전 요구 사항

새 특성을 추가하기 전에 이 속성의 LDAP 디렉터리에 해당 인덱스가 있는지 확인합니다. 대부분의 표준 LDAP 속성에는 LDAP의 인덱스가 있지만 사용자 지정 속성을 추가하려면 수동으로 인덱스를 생성해야 합니다. Red Hat Directory Server 10 관리 가이드표준 인덱스 생성을 참조하십시오.

웹 UI: 검색 속성 설정

  1. IPA 서버 구성을선택합니다.
  2. 사용자 옵션 영역에서 사용자 검색 필드의 사용자 검색 속성을 설정합니다.
  3. 그룹 옵션 영역에서 그룹 검색 필드에 그룹 검색 특성을 설정합니다.
  4. 페이지 상단에서 저장 을 클릭합니다.

명령줄: 검색 속성 설정

다음 옵션과 함께 ipa config-mod 명령을 사용합니다.
  • --usersearch 는 사용자의 새로운 검색 속성 목록을 정의합니다.
  • --groupsearch 는 그룹 검색 속성의 새 목록을 정의합니다.
예를 들어 다음과 같습니다.
$ ipa config-mod --usersearch="uid,givenname,sn,telephonenumber,ou,title"
$ ipa config-mod --groupsearch="cn,description"

13.6. 사용자 및 호스트에 대한 자동 그룹 멤버십 정의

13.6.1. IdM에서 자동 그룹 멤버십이 작동하는 방식

13.6.1.1. 자동 그룹 멤버쉽(Automatic Group Membership)이란 무엇입니까.

자동 그룹 멤버십을 사용하여 사용자 및 호스트를 해당 특성에 따라 그룹에 자동으로 할당할 수 있습니다. 예를 들어 다음을 수행할 수 있습니다.
  • 직원의 사용자 항목을 직원 관리자, 위치 또는 기타 속성에 따라 그룹으로 나눕니다.
  • 클래스, 위치 또는 기타 특성을 기반으로 호스트를 나눕니다.
  • 모든 사용자 또는 모든 호스트를 단일 글로벌 그룹에 추가합니다.

13.6.1.2. 자동 그룹 멤버쉽의 이점

그룹 멤버십을 수동으로 관리하는 오버헤드 감소
자동 그룹 멤버십을 사용하면 관리자가 더 이상 그룹에 사용자와 호스트를 수동으로 할당하지 않습니다.
사용자 및 호스트 관리의 일관성 개선
자동 그룹 멤버십을 사용하면 사용자와 호스트가 엄격하게 정의되고 자동으로 평가되는 기준에 따라 그룹에 할당됩니다.
그룹 기반 설정을 쉽게 관리
그룹에 대해 다양한 설정이 정의되고 개별 그룹 구성원(예: sudo 규칙, autoscale , access control)에 적용됩니다. 자동 그룹 멤버십을 사용하는 경우 사용자 및 호스트가 지정된 그룹에 자동으로 추가되므로 그룹 기반 설정을 쉽게 관리할 수 있습니다.

13.6.1.3. 자동 메모리 규칙

자동 그룹 멤버십을 구성할 때 관리자는 automember 규칙을 정의합니다. 자동 관리 규칙은 특정 사용자 또는 호스트 그룹에 적용됩니다. 여기에는 사용자 또는 호스트가 그룹에서 포함되거나 제외되기 위해 충족해야 하는 조건이 포함됩니다.
조건 포함
사용자 또는 호스트 항목이 포함 조건을 충족하면 그룹에 포함됩니다.
배타적 조건
사용자 또는 host 항목이 배타적 조건을 충족하는 경우 그룹에 포함되지 않습니다.
조건은 Perl 호환 정규식(PCRE) 형식에서 정규 표현식으로 지정됩니다. PCRE에 대한 자세한 내용은 pcresyntax(3) 매뉴얼 페이지를 참조하십시오.
IdM은 포함 조건을 포함하기 전에 독점 조건을 평가합니다. 충돌이 발생할 경우 독점 조건이 포함 조건보다 우선합니다.

13.6.2. 자동 메모리 규칙 추가

다음을 사용하여 automember 규칙을 추가하려면 다음을 수행합니다.
automember 규칙을 추가한 후 다음을 수행합니다.

웹 UI: 자동 메모리 규칙 추가

  1. IdentityAutomemberUser group rules 또는 Host group rules 을 선택합니다.
  2. 추가를 클릭합니다.
  3. Automember rule 필드에서 규칙이 적용될 그룹을 선택합니다. 추가 및 편집을 클릭합니다.
  4. 하나 이상의 포괄적 조건과 배타적 조건을 정의합니다. 자세한 내용은 13.6.1.3절. “자동 메모리 규칙” 을 참조하십시오.
    1. 포함 또는 제외 섹션에서 추가 를 클릭합니다.
    2. 특성 필드에서 필수 특성을 선택합니다.
    3. Expression 필드에 정규식을 정의합니다.
    4. 추가를 클릭합니다.
    예를 들어 다음 조건은 사용자 로그인 속성(uid)에서 값(.*)을 사용하여 모든 사용자를 대상으로 합니다.

    그림 13.5. 자동 메모리 규칙 조건 추가

    자동 메모리 규칙 조건 추가

명령줄: 자동 메모리 규칙 추가

  1. ipa automember-add 명령을 사용하여 automember 규칙을 추가합니다. 메시지가 표시되면 다음을 지정합니다.
    • 대상 그룹 이름과 일치하는 auto member 규칙.
    • 그룹화 유형: 규칙이 사용자 그룹 또는 호스트 그룹을 대상으로 하는지 여부를 지정합니다. 사용자 그룹을 대상으로 지정하려면 group 을 입력합니다. 호스트 그룹을 대상으로 지정하려면 호스트 그룹을 입력합니다.
    예를 들어 user_group 이라는 사용자 그룹에 대한 automember 규칙을 추가하려면 다음을 수행합니다.
    $ ipa automember-add
    Automember Rule: user_group
    Grouping Type: group
    --------------------------------
    Added automember rule "user_group"
    --------------------------------
      Automember Rule: user_group
  2. 하나 이상의 포괄적 조건과 배타적 조건을 정의합니다. 자세한 내용은 13.6.1.3절. “자동 메모리 규칙” 을 참조하십시오.
    1. 조건을 추가하려면 ipa automember-add-condition 명령을 사용합니다. 메시지가 표시되면 다음을 지정합니다.
      • 대상 그룹 이름과 일치하는 auto member 규칙.
      • attribute Key: 필터가 적용할 항목 특성을 지정합니다. 예를 들어, 사용자용 manager 입니다.
      • 그룹화 유형: 규칙이 사용자 그룹 또는 호스트 그룹을 대상으로 하는지 여부를 지정합니다. 사용자 그룹을 대상으로 지정하려면 group 을 입력합니다. 호스트 그룹을 대상으로 지정하려면 호스트 그룹을 입력합니다.
      • 포함 regexExclusive regex - 하나 이상의 조건을 정규식으로 지정합니다. 하나의 조건만 지정하려면 다른 조건을 입력하라는 메시지가 표시되면 Enter 를 누릅니다.
      예를 들어 다음 조건은 사용자 로그인 속성(uid)에서 값(.*)을 사용하여 모든 사용자를 대상으로 합니다.
      $ ipa automember-add-condition
      Automember Rule: user_group
      Attribute Key: uid
      Grouping Type: group
      [Inclusive Regex]: .*
      [Exclusive Regex]:
      ----------------------------------
      Added condition(s) to "user_group"
      ----------------------------------
        Automember Rule: user_group
        Inclusive Regex: uid=.*
      ----------------------------
      Number of conditions added 1
      ----------------------------
    2. 조건을 제거하려면 ipa automember-remove-condition 명령을 사용합니다.

예 13.5. 명령줄: 단일 그룹에 모든 항목을 추가하기 위한 Automember Rule 만들기

모든 사용자 또는 호스트 항목에 포함된 속성(예: cn 또는 fqdn )에 대한 포함 조건을 생성하면 나중에 생성된 모든 사용자 또는 호스트가 단일 그룹에 추가되도록 할 수 있습니다.
  1. all_hosts 라는 호스트 그룹과 같은 그룹을 만듭니다. 13.2절. “사용자 또는 호스트 그룹 추가 및 제거” 참조하십시오.
  2. 새 호스트 그룹에 대한 automember 규칙을 추가합니다. 예를 들어 다음과 같습니다.
    $ ipa automember-add
    Automember Rule: all_hosts
    Grouping Type: hostgroup
    -------------------------------------
    Added automember rule "all_hosts"
    -------------------------------------
      Automember Rule: all_hosts
  3. 모든 호스트를 대상으로 하는 포함 조건을 추가합니다. 다음 예에서 포함 조건은 fqdn 속성에 값(.*)이 있는 호스트를 대상으로 합니다.
    $ ipa automember-add-condition
    Automember Rule: all_hosts
    Attribute Key: fqdn
    Grouping Type: hostgroup
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    ---------------------------------
    Added condition(s) to "all_hosts"
    ---------------------------------
      Automember Rule: all_hosts
      Inclusive Regex: fqdn=.*
    ----------------------------
    Number of conditions added 1
    ----------------------------
향후 추가된 모든 호스트는 자동으로 all_hosts 그룹의 멤버가 됩니다.

예 13.6. 명령줄: 동기화된 AD 사용자를 위한 자동 메모리 규칙 생성

Active Directory(AD)에서 동기화된 Windows 사용자는 ntUser 개체 클래스를 공유합니다. 해당 objectclass 속성에 ntUser 를 사용하여 모든 사용자를 대상으로 하는 automember 조건을 생성하면 나중에 생성한 모든 동기화된 AD 사용자가 AD 사용자의 공통 그룹에 포함되도록 할 수 있습니다.
  1. AD 사용자에 대한 사용자 그룹 (예: ad_users )을 만듭니다. 13.2절. “사용자 또는 호스트 그룹 추가 및 제거” 참조하십시오.
  2. 새 사용자 그룹에 대한 automember 규칙을 추가합니다. 예를 들어 다음과 같습니다.
    $ ipa automember-add
    Automember Rule: ad_users
    Grouping Type: group
    -------------------------------------
    Added automember rule "ad_users"
    -------------------------------------
      Automember Rule: ad_users
  3. 포함 조건을 추가하여 AD 사용자를 필터링합니다. 다음 예에서 포함 조건은 objectclass 속성에 ntUser 값이 있는 모든 사용자를 대상으로 합니다.
    $ ipa automember-add-condition
    Automember Rule: ad_users
    Attribute Key: objectclass
    Grouping Type: group
    [Inclusive Regex]: ntUser
    [Exclusive Regex]:
    -------------------------------------
    Added condition(s) to "ad_users"
    -------------------------------------
      Automember Rule: ad_users
      Inclusive Regex: objectclass=ntUser
    ----------------------------
    Number of conditions added 1
    ----------------------------
앞으로 추가된 모든 AD 사용자는 자동으로 ad_users 사용자 그룹의 멤버가 됩니다.

13.6.3. 기존 사용자 및 호스트에 자동 메모리 규칙 적용

자동 메모리 규칙은 규칙이 추가된 후 생성된 사용자 및 호스트 항목에 자동으로 적용됩니다. 규칙이 추가되기 전에 존재했던 항목에 소급 적용되지 않습니다.
규칙을 추가하기 전에 존재했던 항목에 자동 메모리 규칙을 적용하려면 자동 멤버십을 수동으로 다시 빌드해야 합니다. 자동 멤버십을 다시 빌드하면 기존의 모든 자동 관리 규칙을 모든 항목 또는 특정 항목에 다시 적용합니다.

웹 UI: 기존 참가 신청에 대한 자동 멤버 자격 재구축

모든 사용자 또는 모든 호스트의 자동 멤버십을 다시 빌드하려면 다음을 수행합니다.
  1. IdentityUsers 또는 Hosts 를 선택합니다.
  2. ActionsRebuild auto membership (자동 멤버십 다시 빌드)를 클릭합니다.

    그림 13.6. 모든 사용자 또는 호스트에 대한 자동 멤버쉽 다시 빌드

    모든 사용자 또는 호스트에 대한 자동 멤버쉽 다시 빌드
단일 사용자 또는 호스트의 자동 멤버십을 다시 빌드하려면 다음을 수행합니다.
  1. IdentityUsers 또는 Hosts 를 선택하고 필요한 사용자 로그인 또는 호스트 이름을 클릭합니다.
  2. ActionsRebuild auto membership (자동 멤버십 다시 빌드)를 클릭합니다.

    그림 13.7. 단일 사용자 또는 호스트에 대한 자동 멤버쉽 다시 빌드

    단일 사용자 또는 호스트에 대한 자동 멤버쉽 다시 빌드

명령줄: 기존 참가 신청에 대한 자동 멤버셔닝

모든 사용자의 자동 멤버십을 다시 빌드하려면 ipa automember-rebuild --type=group 명령을 사용합니다.
$ ipa automember-rebuild --type=group
--------------------------------------------------------
Automember rebuild task finished. Processed (9) entries.
--------------------------------------------------------
모든 사용자의 자동 멤버십을 다시 빌드하려면 ipa automember-rebuild --type=hostgroup 명령을 사용합니다.
지정된 사용자 또는 사용자의 자동 멤버십을 다시 빌드하려면 ipa automember-rebuild --users=user 명령을 사용합니다.
$ ipa automember-rebuild --users=user1 --users=user2
--------------------------------------------------------
Automember rebuild task finished. Processed (2) entries.
--------------------------------------------------------
지정된 호스트 또는 호스트의 자동 멤버십을 다시 빌드하려면 ipa automember-rebuild --hosts=example.com 명령을 사용합니다.

13.6.4. 기본 자동 구성원 그룹 구성

기본 automember 그룹이 구성되면 automember 규칙과 일치하지 않는 사용자 또는 호스트 항목이 기본 그룹에 자동으로 추가됩니다.
  1. ipa automember-default-group-set 명령을 사용하여 기본 automember 그룹을 구성합니다. 메시지가 표시되면 다음을 지정합니다.
    • 대상 그룹 이름을 지정하는 기본 그룹 그룹입니다.
    • 그룹화 유형: 대상이 사용자 그룹인지 호스트 그룹인지 여부를 지정합니다. 사용자 그룹을 대상으로 지정하려면 group 을 입력합니다. 호스트 그룹을 대상으로 지정하려면 호스트 그룹을 입력합니다.
    예를 들어 다음과 같습니다.
    $ ipa automember-default-group-set
    Default (fallback) Group: default_user_group
    Grouping Type: group
    ---------------------------------------------------
    Set default (fallback) group for automember "default_user_group"
    ---------------------------------------------------
      Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
  2. 그룹이 올바르게 설정되었는지 확인하려면 ipa automember-default-group-show 명령을 사용합니다. 명령은 현재 기본 automember 그룹을 표시합니다. 예를 들어 다음과 같습니다.
    $ ipa automember-default-group-show
    Grouping Type: group
      Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
현재 기본 automember 그룹을 제거하려면 ipa automember-default-group-remove 명령을 사용합니다.

14장. 고유한 UID 및 GID 번호 할당

IdM 서버는 사용자 ID(UID) 및 그룹 ID(GID) 값을 생성하고 동시에 복제본에서 동일한 ID를 생성하지 않도록 합니다. 단일 조직에서 여러 개의 개별 도메인을 사용하는 경우 고유한 UID 및 GID가 IdM 도메인에 있을 수도 있습니다.

14.1. ID 범위

UID 및 GID 번호는 ID 범위로 나뉩니다. 개별 서버 및 복제본에 대해 별도의 숫자 범위를 유지함으로써 항목에 대해 발행된 ID 값이 다른 서버 또는 복제본의 다른 항목에서 이미 사용되었을 가능성이 최소화됩니다.
도메인의 백엔드 389 Directory Server 인스턴스의 일부인 DCN(Distributed Numeric Assignment) 플러그인은 서버와 복제본 간에 범위가 업데이트되고 공유되도록 합니다. 플러그인은 모든 마스터 및 복제본의 ID 범위를 관리합니다. 모든 서버 또는 복제본에는 현재 ID 범위와 현재 범위가 고갈된 후 서버 또는 복제본에서 사용하는 추가 다음 ID 범위가 있습니다. DNA 디렉터리 서버 플러그인에 대한 자세한 내용은 Red Hat Directory Server Deployment Guide 를 참조하십시오.

14.2. 설치 중 ID 범위 할당

서버를 설치하는 동안 기본적으로 ipa-server-install 명령은 설치된 서버에 임의의 현재 ID 범위를 자동으로 할당합니다. 설정 스크립트는 총 10,000개의 가능한 범위에서 200,000개의 ID 범위를 무작위로 선택합니다. 이러한 방식으로 임의의 범위를 선택하면 향후 두 개의 별도의 IdM 도메인을 병합하기로 결정하는 경우 ID 충돌 가능성이 크게 감소합니다.
그러나 ipa-server-install 에서 다음 두 옵션을 사용하여 서버 설치 중에 현재 ID 범위를 수동으로 정의할 수 있습니다.
  • --idstart 는 UID 및 GID 번호의 시작 값을 제공합니다. 기본적으로 값은 임의로 선택됩니다.
  • --idmax 는 최대 UID 및 GID 번호를 제공합니다. 기본적으로 값은 --idstart 시작 값과 199,999를 더합니다.
단일 IdM 서버가 설치된 경우 새 사용자 또는 그룹 항목은 전체 범위의 임의의 ID를 수신합니다. 새 복제본을 설치하고 복제본에서 고유한 ID 범위를 요청하면 서버 분할 및 서버 및 복제본 간에 초기 ID 범위가 배포됩니다. 복제본은 초기 마스터에서 사용할 수 있는 나머지 ID 범위의 절반을 수신합니다. 그런 다음 서버 및 복제본은 새 항목에 대해 원래 ID 범위의 해당 부분을 사용합니다. 또한 복제본에 할당된 ID 범위에서 100개 미만의 ID가 남아 있으면 복제본이 할당된 ID 범위를 비우는 데 근접한 경우 복제본은 새 ID 범위에 대한 요청을 사용하여 사용 가능한 다른 서버에 접속합니다.
서버는 DNA 플러그인을 처음 사용할 때 ID 범위를 수신합니다. 이 때까지 서버에는 ID 범위가 정의되어 있지 않습니다. 예를 들어 마스터 서버에서 복제본을 만들면 복제본에서 ID 범위를 즉시 받지 않습니다. 복제본은 첫 번째 ID가 복제본에 할당될 때만 초기 마스터에서 ID 범위를 요청합니다.
참고
복제본에서 ID 범위를 요청하기 전에 초기 마스터가 작동을 중지하는 경우 복제본은 ID 범위에 대한 요청을 사용하여 마스터에 연결할 수 없습니다. 복제본에서 새 사용자를 추가하려는 시도가 실패합니다. 이러한 상황에서는 비활성화된 마스터에 할당된 ID 범위를 확인하고 14.5절. “수동 ID 범위 확장 및 새 ID 범위 할당” 설명된 복제본에 ID 범위를 수동으로 할당할 수 있습니다.

14.3. 현재 할당된 ID 범위 표시

서버에 대해 구성된 ID 범위를 표시하려면 다음 명령을 사용합니다.
  • ipa-replica-manage dnarange-show 는 모든 서버에서 설정되거나 서버를 지정하는 경우 지정된 서버에서만 설정된 현재 ID 범위를 표시합니다. 예를 들면 다음과 같습니다.
    # ipa-replica-manage dnarange-show
    masterA.example.com: 1001-1500
    masterB.example.com: 1501-2000
    masterC.example.com: No range set
    
    # ipa-replica-manage dnarange-show masterA.example.com
    masterA.example.com: 1001-1500
  • ipa-replica-manage dnanextrange-show 는 현재 모든 서버에 설정된 다음 ID 범위를 표시하거나 서버를 지정하는 경우 지정된 서버에만 표시됩니다. 예를 들면 다음과 같습니다.
    # ipa-replica-manage dnanextrange-show
    masterA.example.com: 1001-1500
    masterB.example.com: No on-deck range set
    masterC.example.com: No on-deck range set
    
    # ipa-replica-manage dnanextrange-show masterA.example.com
     masterA.example.com: 1001-1500
이러한 두 명령에 대한 자세한 내용은 ipa-replica-manage(1) 매뉴얼 페이지를 참조하십시오.

14.4. 복제를 삭제한 후 자동 ID 범위 확장

작동 중인 복제본을 삭제하면 ipa-replica-manage del 명령은 복제본에 할당된 ID 범위를 검색하고 사용 가능한 다른 IdM 복제본에 다음 범위로 추가합니다. 이렇게 하면 다른 복제본에서 ID 범위를 계속 사용할 수 있습니다.
복제본을 삭제한 후 14.3절. “현재 할당된 ID 범위 표시” 에 설명된 ipa-replica-manage dnarange-showipa-replica-manage dnanextrange-show 명령을 사용하여 다른 서버에 대해 구성된 ID 범위를 확인할 수 있습니다.

14.5. 수동 ID 범위 확장 및 새 ID 범위 할당

특정 상황에서는 ID 범위를 수동으로 조정해야 합니다.
할당된 ID 범위가 고갈되었습니다
복제본에서 할당한 ID 범위가 고갈되었으며 다른 복제본의 ID 범위에서 사용 가능한 ID를 더 이상 사용할 수 없기 때문에 추가 ID를 요청하지 못했습니다. 복제본에 할당된 ID 범위를 확장하려고 합니다. 이 작업에는 기존 ID 범위를 분할하거나 서버에 대해 초기 구성된 ID 범위를 넘어서는 확장 작업이 포함될 수 있습니다. 또는 새 ID 범위를 할당할 수도 있습니다.
참고
새 ID 범위를 할당하면 서버 또는 복제본의 기존 항목 UID가 그대로 유지됩니다. 현재 ID 범위를 변경해도 IdM은 과거에 할당한 범위를 기록하므로 문제가 발생하지 않습니다.
복제본 작동이 중지되었습니다
복제본이 종료되고 삭제가 필요한 경우 ID 범위가 자동으로 검색되지 않으므로 이전에 복제에 할당된 ID 범위를 사용할 수 없게 됩니다. ID 범위를 복구하고 다른 복제본에서 사용할 수 있도록 설정하려고 합니다.
작동을 중지하고 다른 서버에 속하는 ID 범위를 복구하려면 먼저 14.3절. “현재 할당된 ID 범위 표시” 에 설명된 ipa-replica-manage dnarange-show 명령을 사용하여 ID 범위 값을 확인하고 해당 ID 범위를 서버에 수동으로 할당합니다. 또한 중복된 UID 또는 GID를 방지하려면 복구된 범위의 ID 값이 이전에 사용자 또는 그룹에 할당되지 않았는지 확인합니다. 기존 사용자 및 그룹의 UID 및 GID를 검사하여 이 작업을 수행할 수 있습니다.
ID 범위를 수동으로 정의하려면 다음 두 명령을 사용합니다.
  • ipa-replica-manage dnarange-set 를 사용하면 지정된 서버의 현재 ID 범위를 정의할 수 있습니다.
    # ipa-replica-manage dnarange-set masterA.example.com 1250-1499
  • ipa-replica-manage dnanextrange-set 를 사용하면 지정된 서버에 대한 다음 ID 범위를 정의할 수 있습니다.
    # ipa-replica-manage dnanextrange-set masterB.example.com 1001-5000
이러한 명령에 대한 자세한 내용은 ipa-replica-manage(1) 도움말 페이지를 참조하십시오.
중요
겹치는 ID 범위를 만들지 않도록 주의하십시오. 서버 또는 복제본에 할당하는 ID 범위가 겹치는 경우 두 개의 다른 서버에서 동일한 ID 값을 다른 항목에 할당할 수 있습니다.
UID 값이 1000 이하인 ID 범위를 설정하지 마십시오. 이러한 값은 시스템 사용을 위해 예약됩니다. 또한 0 값을 포함하는 ID 범위를 설정하지 마십시오. SSSD 서비스는 0 ID 값을 처리하지 않습니다.
ID 범위를 수동으로 확장하는 경우 IdM ID 범위에 새로 확장된 범위가 포함되어 있는지 확인합니다. ipa idrange-find 명령을 사용하여 이 범위를 확인할 수 있습니다. ipa idrange-find -h 명령을 실행하여 ipa idrange-find 사용 방법에 대한 도움말을 표시합니다.

14.6. 해당 ID 값이 고유하도록 확인

UID 또는 GID와 충돌하지 않도록 하는 것이 좋습니다. UID 및 GID는 항상 고유해야 합니다. 두 사용자는 동일한 UID를 갖지 않아야 하며 두 그룹에 동일한 GID가 없어야 합니다.
자동 ID 할당
사용자 또는 그룹이 대화형 또는 수동으로 지정된 ID 번호 없이 생성되면 서버에서 ID 범위의 다음에 사용 가능한 ID 번호를 사용자 계정에 할당합니다. 이렇게 하면 UID 또는 GID가 항상 고유합니다.
수동 ID 할당
사용자 또는 그룹 항목에 ID를 수동으로 할당하면 서버는 지정된 UID 또는 GID가 고유함을 확인하지 않습니다. 다른 항목에서 이미 사용하는 값을 선택하는 경우 충돌을 경고하지 않습니다.
14.7절. “변경된 UID 및 GID 번호 복구” 에서 설명한 대로 SSSD 서비스는 동일한 ID가 있는 항목을 처리하지 않습니다. 두 항목이 동일한 ID 번호를 공유하는 경우 이 ID를 검색하면 첫 번째 항목만 반환됩니다. 그러나 다른 속성을 검색하거나 ipa user-find --all 명령을 실행하면 두 항목이 모두 반환됩니다.
UID 및 GID는 동일한 ID 범위에서 선택합니다. 사용자와 그룹은 동일한 ID를 가질 수 있습니다. UID와 GID가 uidNumbergidNumber 등 두 가지 속성으로 설정되어 있기 때문에 이러한 상황에서 충돌이 발생하지 않습니다.
참고
사용자와 그룹에 대해 동일한 ID를 설정하면 사용자 개인 그룹을 구성할 수 있습니다. 이러한 방식으로 사용자에 대한 고유한 시스템 그룹을 만들려면 사용자와 그룹에 대해 동일한 ID 값을 설정합니다.

14.7. 변경된 UID 및 GID 번호 복구

사용자가 IdM 시스템 또는 서비스에 로그인하는 경우 해당 시스템의 SSSD는 사용자의 UID 및 GID와 함께 사용자 이름을 캐시합니다. 그런 다음 SSSD는 UID를 사용자의 식별 키로 사용합니다. 동일한 사용자 이름을 가진 사용자가 시스템에 로그인하려고 하지만 다른 UID가 다른 경우 SSSD는 두 개의 다른 UID를 등록하고 두 개의 다른 사용자가 사용자 이름을 충돌하는 것으로 가정합니다. 이 문제는 사용자의 UID가 변경되면 문제가 발생할 수 있습니다. 이러한 상황에서 SSSD는 다른 UID를 가진 동일한 사용자로 인식하지 않고 수정된 UID를 새 사용자로 잘못 해석합니다. 기존 사용자의 UID가 변경되면 사용자는 SSSD 및 관련 서비스 및 도메인에 로그인할 수 없습니다. ID 정보를 위해 SSSD를 사용하는 클라이언트 애플리케이션에도 영향을 줍니다.
이 문제를 해결하려면 UID 또는 GID가 변경되면 SSSD 캐시를 지워 사용자가 다시 로그인할 수 있습니다. 예를 들어 지정된 사용자의 SSSD 캐시를 지우려면 다음과 같이 sss_cache 유틸리티를 사용합니다.
[root@server ~]# sss_cache -u user

15장. 사용자 및 그룹 스키마

사용자 항목이 생성되면 특정 LDAP 오브젝트 클래스가 자동으로 할당되며, 이로 인해 특정 속성을 사용할 수 있습니다. LDAP 속성은 정보가 디렉터리에 저장되는 방식입니다. (이 내용은 Directory Server Deployment GuideDirectory Server Schema Reference 에서 자세히 설명합니다.)

표 15.1. 기본 Identity Management 사용자 오브젝트 클래스

개체 클래스 Description
ipaobject
ipasshuser
IdM 오브젝트 클래스
person
조직
inetorgperson
inetuser
posixAccount
person 객체 클래스
krbprincipalaux
krbticketpolicyaux
Kerberos 오브젝트 클래스
mepOriginEntry 관리된 항목(템플릿) 오브젝트 클래스
사용자 항목에 다양한 특성을 사용할 수 있습니다. 일부는 수동으로 설정되며, 특정 값이 설정되지 않은 경우 기본값을 기반으로 설정됩니다. 해당 속성에 대한 UI 또는 명령줄 인수가 없는 경우에도 표 15.1. “기본 Identity Management 사용자 오브젝트 클래스” 의 오브젝트 클래스에서 사용 가능한 속성을 추가하는 옵션도 있습니다. 또한 기본 속성에서 생성하거나 사용하는 값은 15.4절. “기본 사용자 및 그룹 속성 지정” 에서와 같이 구성할 수 있습니다.

표 15.2. 기본 Identity Management 사용자 속성

UI 필드 명령줄 옵션 필수, 선택 사항 또는 기본값[a]
사용자 로그인 username 필수 항목
이름 --first 필수 항목
--last 필수 항목
성명 --cn 선택 사항
표시 이름 --displayname 선택 사항
초기 --initials 기본값
홈 디렉토리 --homedir 기본값
GECOS 필드 --gecos 기본값
--shell 기본값
Kerberos 주체 --principal 기본값
이메일 주소 --email 선택 사항
암호 --password [b] 선택 사항
사용자 ID 번호 --uid 기본값
그룹 ID 번호 --gidnumber 기본값
스트리드 주소 --street 선택 사항
도시 --city 선택 사항
시/도 --state 선택 사항
zip 코드 --postalcode 선택 사항
전화 번호 --phone 선택 사항
휴대폰 번호 --mobile 선택 사항
호출자 번호 --pager 선택 사항
팩스 번호 --fax 선택 사항
조직 단위 --OrgUnit 선택 사항
직책 --title 선택 사항
관리자 --manager 선택 사항
Car 라이센스 --carlicense 선택 사항
--noprivate 선택 사항
SSH 키 --sshpubkey 선택 사항
추가 속성 --addattr 선택 사항
부서 번호 --departmentnumber 선택 사항
직원 번호 --employeenumber 선택 사항
직원 유형 --employeetype 선택 사항
선호하는 언어 --preferredlanguage 선택 사항
[a] 모든 항목에 필수 특성을 설정해야 합니다. 선택적 속성을 설정할 수 있지만, 특정 값을 지정하지 않는 한 기본 속성이 자동으로 사전 정의된 값으로 추가됩니다.
[b] 스크립트에서 인수와 함께 값을 수락하지 않고 새 암호를 묻는 메시지를 표시합니다.

15.1. 기본 사용자 및 그룹 스키마 변경 정보

사용자 및 그룹 항목(15장. 사용자 및 그룹 스키마)에 사용되는 오브젝트 클래스 및 속성을 추가하거나 변경할 수 있습니다.
오브젝트 클래스가 변경될 때 IdM 구성은 몇 가지 검증을 제공합니다.
  • 모든 오브젝트 클래스와 지정된 속성은 LDAP 서버에 알려져 있어야 합니다.
  • 항목에 대해 구성된 모든 기본 속성은 구성된 오브젝트 클래스에서 지원해야 합니다.
그러나 IdM 스키마 검증에는 제한이 있습니다. 가장 중요한 것은 IdM 서버에 정의된 사용자 또는 그룹 오브젝트 클래스에 IdM 항목에 필요한 모든 오브젝트 클래스가 포함되어 있는지 확인하지 않습니다. 예를 들어 모든 IdM 항목에는 ipaobject 오브젝트 클래스가 필요합니다. 그러나 사용자 또는 그룹 스키마가 변경되면 서버에서 이 개체 클래스가 포함되어 있는지 확인하지 않습니다. 개체 클래스가 실수로 삭제되면 이후 항목 추가 작업이 실패합니다.
또한 모든 개체 클래스 변경 사항은 증분식이 아니라 원자적입니다. 기본 오브젝트 클래스의 전체 목록은 변경될 때마다 정의해야 합니다. 예를 들어 회사에서는 연상 및 고용 시작일과 같은 직원 정보를 저장하기 위한 맞춤형 객체 클래스를 만들 수 있습니다. 관리자는 단순히 사용자 지정 개체 클래스를 목록에 추가할 수 없습니다. 현재 기본 개체 클래스 새 개체 클래스의 전체 목록을 설정해야 합니다. 구성을 업데이트할 때 기존 기본 오브젝트 클래스를 항상 포함해야 합니다. 그렇지 않으면 현재 설정을 덮어쓸 것이며 심각한 성능 문제가 발생합니다.

15.2. 새 사용자 항목에 사용자 지정 오브젝트 클래스 적용

사용자 및 그룹 계정은 항목에 적용되는 사전 정의된 LDAP 오브젝트 클래스 세트로 생성됩니다. 오브젝트 클래스에 속하는 속성을 사용자 항목에 추가할 수 있습니다.
표준 및 IdM별 LDAP 오브젝트 클래스에는 대부분의 배포 시나리오를 다루지만 관리자는 사용자 지정 속성을 사용하여 사용자 지정 오브젝트 클래스를 생성할 수 있습니다. 관리자가 기본 개체 클래스 목록을 수정한 후에는 새 항목에 사용자 지정 개체 클래스가 포함되지만 이전 항목은 자동으로 수정되지 않습니다.

15.2.1. 웹 UI에서

  1. Identity Management에서 사용하는 389 Directory Server 인스턴스에 모든 사용자 정의 스키마 요소를 추가합니다. 스키마 요소 추가는 Directory Server 관리자 가이드의 스키마 장에 설명되어 있습니다.
  2. IPA 서버 탭을 엽니다.
  3. Configuration (구성)을 선택합니다.
  4. 사용자 옵션 영역으로 스크롤합니다.

    그림 15.1. 서버 설정의 사용자 옵션

    서버 설정의 사용자 옵션
  5. 사용자 영역 하단에서 추가 를 클릭하여 다른 개체 클래스에 대한 새 필드를 포함합니다.
    중요
    구성이 업데이트될 때 항상 기존 기본 오브젝트 클래스를 포함합니다. 그렇지 않으면 현재 설정을 덮어씁니다. Identity Management에 필요한 개체 클래스가 포함되어 있지 않으면 항목 추가 시도가 개체 클래스 위반으로 실패합니다.

    그림 15.2. 기본 사용자 오브젝트 클래스 변경

    기본 사용자 오브젝트 클래스 변경
  6. 변경 사항이 완료되면 Configuration (구성) 페이지 상단에 있는 저장 을 클릭합니다.

15.2.2. 명령줄에서

  1. Identity Management에서 사용하는 389 Directory Server 인스턴스에 모든 사용자 정의 스키마 요소를 추가합니다. 스키마 요소 추가는 Directory Server 관리자 가이드의 스키마 장에 설명되어 있습니다.
  2. 항목에 추가된 오브젝트 클래스 목록에 새 오브젝트 클래스를 추가합니다. 사용자 오브젝트 클래스의 옵션은 --userobjectclasses 입니다.
    중요
    구성이 업데이트될 때 항상 기존 기본 오브젝트 클래스를 포함합니다. 그렇지 않으면 현재 설정을 덮어씁니다. Identity Management에 필요한 개체 클래스가 포함되어 있지 않으면 항목 추가 시도가 개체 클래스 위반으로 실패합니다.
    모든 객체 클래스는 객체 클래스 목록에 포함되어야 합니다. config-mod 명령과 함께 전달된 정보는 이전 값을 덮어씁니다. 이 작업은 --userobjectclasses 인수를 사용하여 각 오브젝트 클래스를 지정하거나 중괄호 안에 쉼표로 구분된 목록(예: {attr1,attr2,attr3} )으로 모든 오브젝트 클래스를 나열하여 수행할 수 있습니다. 특히 긴 목록의 경우 여러 옵션보다 중괄호를 사용하는 것이 더 쉬울 수 있습니다. 예를 들어 다음과 같습니다.
    [bjensen@server ~]$ ipa config-mod --userobjectclasses={top,person,organizationalperson,inetorgperson,inetuser,posixaccount,krbprincipalaux,krbticketpolicyaux,ipaobject,ipasshuser,employeeinfo}
참고
중괄호 옵션을 사용하려면 중괄호 확장 기능을 켜야 합니다. 기능을 활성화하려면 set 명령을 사용합니다.
# set -o braceexpand

15.3. 새 그룹 항목에 사용자 지정 오브젝트 클래스 적용

사용자 항목과 마찬가지로 관리자는 사용자 지정 특성을 사용하여 사용자 지정 개체 클래스를 만들 수 있습니다. 이러한 항목은 IdM 서버 구성에 오브젝트 클래스를 추가하여 자동으로 추가할 수 있습니다. 관리자가 기본 개체 클래스 목록을 수정한 후에는 새 항목에 사용자 지정 개체 클래스가 포함되지만 이전 항목은 자동으로 수정되지 않습니다.

15.3.1. 웹 UI에서

  1. Identity Management에서 사용하는 389 Directory Server 인스턴스에 모든 사용자 정의 스키마 요소를 추가합니다. 스키마 요소 추가는 Directory Server 관리자 가이드의 스키마 장에 설명되어 있습니다.
  2. IPA 서버 탭을 엽니다.
  3. Configuration (구성)을 선택합니다.
  4. 그룹 옵션 영역으로 스크롤합니다.

    그림 15.3. 서버 설정의 그룹 옵션

    서버 설정의 그룹 옵션
  5. 추가 를 클릭하여 다른 개체 클래스에 대한 새 필드를 포함합니다.
    중요
    구성이 업데이트될 때 항상 기존 기본 오브젝트 클래스를 포함합니다. 그렇지 않으면 현재 설정을 덮어씁니다. Identity Management에 필요한 개체 클래스가 포함되어 있지 않으면 항목 추가 시도가 개체 클래스 위반으로 실패합니다.
  6. 변경 사항이 완료되면 Configuration (구성) 페이지 상단에 있는 저장 을 클릭합니다.

15.3.2. 명령줄에서

  1. Identity Management에서 사용하는 389 Directory Server 인스턴스에 모든 사용자 정의 스키마 요소를 추가합니다. 스키마 요소 추가는 Directory Server 관리자 가이드의 스키마 장에 설명되어 있습니다.
  2. 항목에 추가된 오브젝트 클래스 목록에 새 오브젝트 클래스를 추가합니다. 그룹 오브젝트 클래스에 대한 옵션은 --groupobjectclasses 입니다.
    중요
    구성이 업데이트될 때 항상 기존 기본 오브젝트 클래스를 포함합니다. 그렇지 않으면 현재 설정을 덮어씁니다. Identity Management에 필요한 개체 클래스가 포함되어 있지 않으면 항목 추가 시도가 개체 클래스 위반으로 실패합니다.
    모든 객체 클래스는 객체 클래스 목록에 포함되어야 합니다. config-mod 명령과 함께 전달된 정보는 이전 값을 덮어씁니다. 이 작업은 --groupobjectclasses 인수를 사용하여 각 오브젝트 클래스를 지정하거나 중괄호 안에 쉼표로 구분된 목록(예: {attr1,attr2,attr3} )으로 모든 오브젝트 클래스를 나열하여 수행할 수 있습니다. 특히 긴 목록의 경우 여러 옵션보다 중괄호를 사용하는 것이 더 쉬울 수 있습니다. 예를 들어 다음과 같습니다.
    [bjensen@server ~]$ ipa config-mod --groupobjectclasses={top,groupofnames,nestedgroup,ipausergroup,ipaobject,ipasshuser,employeegroup}

15.4. 기본 사용자 및 그룹 속성 지정

Identity Management는 새 항목을 생성할 때 템플릿을 사용합니다.
사용자의 경우 템플릿은 매우 구체적입니다. ID 관리는 IdM 사용자 계정에 대한 여러 핵심 속성에 기본값을 사용합니다. 이러한 기본값은 사용자 계정 속성(예: 홈 디렉터리 위치)에 대한 실제 값을 정의하거나 사용자 이름 길이와 같은 특성 값 형식을 정의할 수 있습니다. 이러한 설정은 사용자에게 할당된 개체 클래스도 정의합니다.
그룹의 경우 템플릿은 할당된 개체 클래스만 정의합니다.
이러한 기본 정의는 모두 IdM 서버의 단일 구성 항목인 cn=ipaconfig,cn=etc,dc=example,dc=com 에 포함됩니다.
ipa config-mod 명령을 사용하여 설정을 변경할 수 있습니다.

표 15.3. 기본 사용자 매개변수

필드 명령줄 옵션 설명
최대 사용자 이름 길이 --maxusername 사용자 이름에 대한 최대 문자 수를 설정합니다. 기본값은 32입니다.
홈 디렉토리의 루트 --homedirectory 사용자 홈 디렉터리에 사용할 기본 디렉터리를 설정합니다. 기본값은 /home 입니다.
기본 쉘 --defaultshell 사용자에게 사용할 기본 쉘을 설정합니다. 기본값은 /bin/sh 입니다.
기본 사용자 그룹 --defaultgroup 새로 생성된 모든 계정이 추가된 기본 그룹을 으로 설정합니다. 기본값은 ipausers 이며, IdM 서버 설치 프로세스 중에 자동으로 생성됩니다.
기본 전자 메일 도메인 --emaildomain 새 계정을 기반으로 이메일 주소를 생성하는 데 사용할 이메일 도메인을 설정합니다. 기본값은 IdM 서버 도메인입니다.
검색 시간 제한 --searchtimelimit 서버에서 결과를 반환하기 전에 검색에 사용할 최대 시간(초)을 설정합니다.
검색 크기 제한 --searchrecordslimit 검색에 반환할 최대 레코드 수를 설정합니다.
사용자 검색 필드 --usersearch 검색 문자열로 사용할 수 있는 사용자 항목의 필드를 설정합니다. 나열된 속성에는 해당 속성에 대한 인덱스가 보관되어 있으므로 너무 많은 속성을 설정하면 서버 성능에 영향을 줄 수 있습니다.
그룹 검색 필드 --groupsearch 검색 문자열로 사용할 수 있는 그룹 항목의 필드를 설정합니다.
인증서 제목 기반 클라이언트 인증서에 대한 주체 DN을 생성할 때 사용할 기본 DN을 설정합니다. 이는 서버가 설정될 때 구성됩니다.
기본 사용자 개체 클래스 --userobjectclasses IdM 사용자 계정을 생성하는 데 사용되는 오브젝트 클래스를 정의합니다. 여러 번 호출할 수 있습니다. 명령이 실행될 때 목록을 덮어쓰므로 오브젝트 클래스의 전체 목록을 제공해야 합니다.
기본 그룹 오브젝트 클래스 --groupobjectclasses IdM 그룹 계정을 생성하는 데 사용되는 오브젝트 클래스를 정의합니다. 여러 번 호출할 수 있습니다. 명령이 실행될 때 목록을 덮어쓰므로 오브젝트 클래스의 전체 목록을 제공해야 합니다.
암호 만료 알림 --pwdexpnotify 서버가 알림을 보낼 수 있도록 암호가 만료되기 전 일 단위로 기간(일)을 설정합니다.
암호 플러그인 기능 사용자에게 허용되는 암호 형식을 설정합니다.

15.4.1. 웹 UI에서 속성 보기

  1. IPA 서버 탭을 엽니다.
  2. Configuration (구성)을 선택합니다.
  3. 전체 구성 항목은 세 개의 섹션에 표시되며, 하나는 모든 검색 한도(사용자 템플릿용, 그룹 템플릿용)입니다.

    그림 15.4. 검색 제한 설정

    검색 제한 설정

    그림 15.5. 사용자 속성

    사용자 속성

    그림 15.6. 그룹 속성

    그룹 속성

15.4.2. 명령줄에서 속성 보기

config-show 명령은 모든 새 사용자 계정에 적용되는 현재 구성을 표시합니다. 기본적으로 가장 일반적인 속성만 표시됩니다. all 옵션을 사용하여 전체 구성을 표시합니다.
[bjensen@server ~]$ kinit admin
[bjensen@server ~]$ ipa config-show --all
dn: cn=ipaConfig,cn=etc,dc=example,dc=com
Maximum username length: 32
Home directory base: /home
Default shell: /bin/sh
Default users group: ipausers
Default e-mail domain: example.com
Search time limit: 2
Search size limit: 100
User search fields: uid,givenname,sn,telephonenumber,ou,title
Group search fields: cn,description
Enable migration mode: FALSE
Certificate Subject base: O=EXAMPLE.COM
Default group objectclasses: top, groupofnames, nestedgroup, ipausergroup, ipaobject
Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser
Password Expiration Notification (days): 4
Password plugin features: AllowNThash
SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023
Default PAC types: MS-PAC, nfs:NONE
cn: ipaConfig
objectclass: nsContainer, top, ipaGuiConfig, ipaConfigObject

16장. 서비스 관리

호스트에서 실행되는 일부 서비스도 IdM 도메인에 속할 수 있습니다. Kerberos 사용자 또는 SSL 인증서(또는 둘 다)를 저장할 수 있는 모든 서비스를 IdM 서비스로 구성할 수 있습니다. IdM 도메인에 서비스를 추가하면 서비스에서 도메인에서 SSL 인증서 또는 keytab을 요청할 수 있습니다. (인증서의 공개 키만 서비스 레코드에 저장됩니다. 개인 키는 서비스의 로컬입니다.)
IdM 도메인은 일반적인 ID 정보, 공통 정책 및 공유 서비스를 사용하여 시스템 간 공통성을 설정합니다. 도메인 기능에 속하는 모든 머신은 도메인의 클라이언트로, 도메인에서 제공하는 서비스를 사용합니다. IdM 도메인( 1장. Red Hat Identity Management 소개에 설명된 대로)은 특히 머신을 위한 세 가지 주요 서비스를 제공합니다.
  • DNS
  • Kerberos
  • 인증서 관리

16.1. 서비스 항목 및 키 탭 추가 및 편집

호스트 항목과 마찬가지로 호스트의 서비스 항목(및 도메인에 속할 해당 호스트의 다른 서비스)은 IdM 도메인에 수동으로 추가해야 합니다. 이는 두 단계의 프로세스입니다. 먼저 서비스 항목을 생성한 다음 도메인에 액세스하는 데 사용할 해당 서비스에 대해 키탭을 만들어야 합니다.
기본적으로 Identity Management는 HTTP keytab을 /etc/httpd/conf/ipa.keytab 에 저장합니다.
참고
이 키탭은 웹 UI에 사용됩니다. 키가 ipa.keytab 에 저장되고 해당 keytab 파일이 삭제되면 원래 키도 삭제되므로 IdM 웹 UI의 작동이 중지됩니다.
Kerberos를 인식해야 하는 각 서비스에 대해 유사한 위치를 지정할 수 있습니다. 사용해야 하는 특정 위치는 없지만 ipa-getkeytab 을 사용할 때는 /etc/krb5.keytab 사용을 피해야 합니다. 이 파일에는 서비스별 키탭이 포함되어 있지 않아야 합니다. 각 서비스에는 특정 위치에 저장된 키탭과 액세스 권한(및 SELinux 규칙)만 keytab에 액세스할 수 있도록 구성해야 합니다.

16.1.1. 웹 UI에서 서비스 및 키 탭 추가

  1. Identity 탭을 열고 Services (서비스)를 선택합니다.
  2. 서비스 목록 상단에 있는 Add 버튼을 클릭합니다.
  3. 드롭다운 메뉴에서 서비스 유형을 선택하고 이름을 지정합니다.
  4. 서비스가 실행 중인 IdM 호스트의 호스트 이름을 선택합니다. 호스트 이름은 전체 서비스 주체 이름을 구성하는 데 사용됩니다.
  5. Add 버튼을 클릭하여 새 서비스 주체를 저장합니다.
  6. ipa-getkeytab 명령을 사용하여 서비스 주체에 대한 새 키탭을 생성하고 할당합니다.
    [root@ipaserver ~]# # ipa-getkeytab -s ipaserver.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
    • 영역 이름은 선택 사항입니다. IdM 서버는 구성된 Kerberos 영역을 자동으로 추가합니다. 다른 영역을 지정할 수 없습니다.
    • 호스트 이름이 Kerberos와 함께 작동하려면 DNS A 레코드로 변환해야 합니다. --force 플래그를 사용하여 필요한 경우 보안 주체 생성을 강제 적용할 수 있습니다.
    • e 인수 는 키 탭에 포함할 암호화 유형 목록을 포함할 수 있습니다. 이는 모든 기본 암호화 유형을 대체합니다. 동일한 명령 호출과 함께 옵션을 여러 번 사용하거나, 옵션 목록을 중괄호 안에 쉼표로 구분된 목록으로 나열(예: --option={val1,val2,val3} )하여 설정할 수 있습니다.
    주의
    새 키를 만들면 지정된 주체에 대한 시크릿이 재설정됩니다. 즉, 해당 주체의 다른 모든 키탭이 잘못 렌더링됩니다.

16.1.2. 명령줄에서 서비스 및 키 탭 추가

  1. 서비스 주체를 생성합니다. 서비스는 서비스/FQDN 과 같은 이름을 통해 인식됩니다:
    # ipa service-add serviceName/hostname
    예를 들어 다음과 같습니다.
    $ ipa service-add HTTP/server.example.com
    -------------------------------------------------------
    Added service "HTTP/server.example.com@EXAMPLE.COM"
    -------------------------------------------------------
      Principal: HTTP/server.example.com@EXAMPLE.COM
      Managed by: ipaserver.example.com
    
  2. ipa-getkeytab 명령을 사용하여 서비스 키탭 파일을 만듭니다. 이 명령은 IdM 도메인의 클라이언트에서 실행됩니다. (실제로, IdM 서버 또는 클라이언트에서 실행 한 다음 적절한 시스템으로 복사되는 키를 실행할 수 있습니다. 그러나 생성되는 서비스가 있는 시스템에서 명령을 실행하는 것이 가장 간단합니다.)
    명령에는 Kerberos 서비스 주체(-p), IdM 서버 이름(-s), 작성할 파일(-k) 및 암호화 방법이 필요합니다. 키탭을 서비스의 적절한 디렉터리에 복사해야 합니다.
    예를 들어 다음과 같습니다.
    # ipa-getkeytab -s server.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
    • 영역 이름은 선택 사항입니다. IdM 서버는 구성된 Kerberos 영역을 자동으로 추가합니다. 다른 영역을 지정할 수 없습니다.
    • 호스트 이름이 Kerberos와 함께 작동하려면 DNS A 레코드로 변환해야 합니다. --force 플래그를 사용하여 필요한 경우 보안 주체 생성을 강제 적용할 수 있습니다.
    • e 인수 는 keytab에 포함할 암호화 유형의 쉼표로 구분된 목록을 포함할 수 있습니다. 이는 모든 기본 암호화 유형을 대체합니다. 동일한 명령 호출과 함께 옵션을 여러 번 사용하거나, 옵션 목록을 중괄호 안에 쉼표로 구분된 목록으로 나열(예: --option={val1,val2,val3} )하여 설정할 수 있습니다.
    주의
    ipa-getkeytab 명령은 지정된 보안 주체의 시크릿을 재설정합니다. 즉, 해당 주체의 다른 모든 키탭이 잘못 렌더링됩니다.

16.2. 클러스터된 서비스 구성

IdM 서버는 클러스터를 인식하지 못합니다. 그러나 참여하는 모든 호스트에서 Kerberos 키를 동기화하고 호스트에서 실행되는 서비스를 클라이언트가 사용하는 모든 이름에 응답하도록 클러스터형 서비스를 IdM의 일부로 구성할 수 있습니다.
  1. 클러스터의 모든 호스트를 IdM 도메인에 등록합니다.
  2. 서비스 주체를 생성하고 필수 키탭을 생성합니다.
  3. /etc/krb5.keytab 의 호스트 keytab을 포함하여 호스트의 서비스에 대해 설정된 키탭을 수집합니다.
  4. ktutil 명령을 사용하여 모든 keytab 파일의 내용이 포함된 단일 keytab 파일을 생성합니다.
    1. 각 파일에 대해 rkt 명령을 사용하여 해당 파일의 키를 읽습니다.
    2. wkt 명령을 사용하여 새 키탭 파일에 읽은 모든 키를 작성합니다.
  5. 각 호스트의 키탭 파일을 새로 생성된 결합된 키탭 파일로 바꿉니다.
  6. 이때 이 클러스터의 각 호스트에서 다른 호스트를 가장할 수 있습니다.
  7. 일부 서비스에서는 실패한 서비스를 인수할 때 호스트 이름을 재설정하지 않는 클러스터 구성원을 수용하려면 추가 구성이 필요합니다.
    • sshd 의 경우 /etc/ssh/sshd_config 에서 GSSAPIStrictAcceptorCheck no 를 설정합니다.
    • mod_auth_kerb 의 경우 KrbServiceName을 /etc/httpd/conf.d/auth_kerb.conf 에 Any 로 설정합니다.
참고
SSL 서버의 경우 클라이언트가 클러스터형 호스트에 연결하면 서버 인증서에 대한 주체 이름 또는 제목 대체 이름이 올바르게 표시되어야 합니다. 가능한 경우 모든 호스트 간에 개인 키를 공유하십시오.
각 클러스터 멤버에 다른 모든 클러스터 구성원의 이름이 포함된 제목 대체 이름이 있는 경우 클라이언트 연결 요구 사항을 충족합니다.

16.3. 여러 서비스에 동일한 서비스 주체 사용

클러스터 내에서 동일한 서비스 주체를 여러 시스템에 분산하여 여러 서비스에 사용할 수 있습니다.
  1. ipa-getkeytab 명령을 사용하여 서비스 주체를 검색합니다.
    # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
  2. 여러 서버 또는 서비스에 동일한 파일을 사용하도록 지시하거나 필요에 따라 파일을 개별 서버에 복사합니다.

16.4. 여러 서버에 대한 기존 키 탭 검색

클러스터 환경에서와 같이 일부 시나리오에서는 서로 다른 시스템의 일반적인 호스트 이름에 표시되는 서비스에 동일한 keytab 파일이 필요합니다. IdM 명령을 사용하여 각 호스트에서 동일한 keytab을 검색할 수 있습니다.
공통 호스트 이름과 서비스 주체를 준비하려면 IdM 서버에서 다음 명령을 실행합니다.
  1. admin 사용자로 인증합니다.
    [root@ipaserver ~]# kinit admin
  2. 이 호스트 이름을 공유하는 모든 IP 주소에 대한 공통 정방향 DNS 레코드를 추가합니다.
    [root@ipaserver ~]# ipa dnsrecord-add idm.example.com cluster --a-rec={192.0.2.40,192.0.2.41}
      Record name: cluster
        A record: 192.0.2.40, 192.0.2.41
  3. 일반 DNS 이름에 대한 새 호스트 항목 오브젝트를 생성합니다.
    [root@ipaserver ~]# ipa host-add cluster.idm.example.com
    ------------------------------------
    Added host "cluster.idm.example.com"
    ------------------------------------
      Host name: cluster.idm.example.com
      Principal name: host/cluster.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: cluster.idm.example.com
  4. 호스트의 서비스 주체를 추가합니다.
    [root@ipaserver ~]# ipa service-add HTTP/cluster.idm.example.com
    ------------------------------------------------------------
    Added service "HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM"
    ------------------------------------------------------------
      Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM
      Managed by: cluster.idm.example.com
  5. IdM에서 keytab을 검색할 수 있어야 하는 서비스를 서비스에 추가합니다.
    [root@ipaserver ~]# ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com}
      Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM
      Managed by: cluster.idm.example.com
      Hosts allowed to retrieve keytab: node01.idm.example.com, node02.idm.example.com
    -------------------------
    Number of members added 2
    -------------------------
  6. 하나의 호스트에 새 키탭을 생성할 수 있는 권한을 부여합니다.
    [root@ipaserver ~]# ipa service-allow-create-keytab HTTP/cluster.idm.example.com --hosts=node01.idm.example.com
    Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM
    Managed by: cluster.idm.example.com
    Hosts allowed to retrieve keytab: node01.idm.example.com, node02.idm.example.com
    Hosts allowed to create keytab: node01.idm.example.com
    -------------------------
    Number of members added 1
    -------------------------
클라이언트에서 다음 단계를 수행합니다.
  1. hosts Kerberos keytab으로 인증합니다.
    # kinit -kt /etc/krb5.keytab
    1. 클라이언트에 각 권한이 부여된 경우 새 키탭을 생성하여 파일에 저장합니다.
      [root@node01 ~]# ipa-getkeytab -s ipaserver.idm.example.com -p HTTP/cluster.idm.example.com -k /tmp/client.keytab
    2. 다른 모든 클라이언트에서 명령에 -r 옵션을 추가하여 IdM 서버에서 기존 keytab을 검색합니다.
      [root@node02 ~]# ipa-getkeytab -r -s ipaserver.idm.example.com -p HTTP/cluster.idm.example.com -k /tmp/client.keytab
      주의
      r 옵션을 생략하면 새 키 탭이 생성됩니다. 이렇게 하면 이전에 검색된 모든 키탭이 이 서비스 주체에 대해 무효화됩니다.

16.5. 서비스 항목 비활성화 및 재활성화

활성 서비스는 도메인 내의 다른 서비스, 호스트 및 사용자가 액세스할 수 있습니다. 호스트 또는 서비스를 활동에서 제거해야 하는 경우가 있을 수 있습니다. 그러나 서비스 또는 호스트를 삭제하면 항목과 관련된 모든 구성이 제거되며 영구적으로 제거됩니다.

16.5.1. 서비스 항목 비활성화

서비스를 비활성화하면 도메인 사용자가 도메인에서 영구히 제거하지 않고 액세스할 수 없습니다. service-disable 명령을 사용하여 수행할 수 있습니다.
서비스의 경우 서비스의 주체를 지정합니다. 예를 들어 다음과 같습니다.
[jsmith@ipaserver ~]$ kinit admin
[jsmith@ipaserver ~]$ ipa service-disable HTTP/server.example.com
중요
호스트 항목을 비활성화하면 해당 호스트를 비활성화할 뿐만 아니라. 해당 호스트에서 구성된 모든 서비스도 비활성화합니다.

16.5.2. 서비스 재활성화

기본적으로 서비스를 비활성화하면 현재 활성 키탭이 강제 종료됩니다. 키 탭을 제거하면 구성 항목에 영향을 주지 않고 IdM 도메인에서 서비스가 효과적으로 제거됩니다.
서비스를 다시 활성화하려면 ipa-getkeytab 명령을 사용하십시오. -s 옵션은 keytab을 요청할 IdM 서버를 설정하고 -p 는 주요 이름을 제공하고, -k 는 keytab을 저장할 파일을 제공합니다.
예를 들어 새 HTTP 키탭 요청:
[root@ipaserver ~]# ipa-getkeytab -s ipaserver.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts

17장. 호스트 및 서비스에 대한 액세스 위임

이 장의 컨텍스트에서 관리하려면 다른 호스트 또는 서비스의 키 탭과 인증서를 검색할 수 있습니다. 모든 호스트 및 서비스에는 관리할 수 있는 호스트 또는 서비스가 나열되는 managedby 항목이 있습니다. 기본적으로 호스트는 자체 및 모든 서비스를 관리할 수 있습니다. 또한 호스트는 적절한 위임을 업데이트하거나 적절한 관리 항목을 제공하여 다른 호스트의 다른 호스트 또는 서비스를 관리할 수 있습니다.
IdM 서비스는 해당 호스트가 부여되거나 서비스에 액세스할 수 있는 권한을 위임 한 경우 모든 IdM 호스트에서 관리할 수 있습니다. 마찬가지로, 호스트는 도메인 내의 다른 호스트에 권한을 위임할 수 있습니다.

그림 17.1. 호스트 및 서비스 위임

호스트 및 서비스 위임
참고
호스트가 managedBy 항목을 통해 다른 호스트에 위임된 권한이 있는 경우 호스트가 해당 호스트의 모든 서비스에 대해 위임된 관리였습니다. 각 위임은 독립적으로 수행해야 합니다.

17.1. 서비스 관리 위임

호스트는 service-add-host 유틸리티를 사용하여 서비스에 대한 제어를 위임합니다.
# ipa service-add-host principal --hosts=hostname
서비스를 위임하는 두 가지 부분이 있습니다.
  • 주 인수를 사용하여 주체 지정.
  • hosts 옵션을 사용하여 제어로 호스트 식별.
예를 들어 다음과 같습니다.
[root@server ~]# ipa service-add HTTP/web.example.com
[root@server ~]# ipa service-add-host HTTP/web.example.com --hosts=client1.example.com
호스트가 위임된 권한이 되면 호스트 주체를 사용하여 서비스를 관리할 수 있습니다.
[root@client1 ~]# kinit -kt /etc/krb5.keytab host/client1.example.com
[root@client1 ~]# ipa-getkeytab -s server.example.com -k /tmp/test.keytab -p HTTP/web.example.com
Keytab successfully retrieved and stored in: /tmp/test.keytab
이 서비스에 대한 티켓을 생성하려면 위임된 권한이 있는 호스트에 인증서 요청을 생성합니다.
[root@client1]# kinit -kt /etc/krb5.keytab host/client1.example.com
[root@client1]# openssl req -newkey rsa:2048 -subj '/CN=web.example.com/O=EXAMPLE.COM' -keyout /etc/pki/tls/web.key -out /tmp/web.csr -nodes
Generating a 2048 bit RSA private key
.............................................................+++
............................................................................................+++
Writing new private key to '/etc/pki/tls/private/web.key'
cert-request 유틸리티를 사용하여 서비스 항목을 생성하고 인증 정보를 로드합니다.
[root@client1]# ipa cert-request --principal=HTTP/web.example.com web.csr
Certificate: MIICETCCAXqgA...[snip]
Subject: CN=web.example.com,O=EXAMPLE.COM
Issuer: CN=EXAMPLE.COM Certificate Authority
Not Before: Tue Feb 08 18:51:51 2011 UTC
Not After: Mon Feb 08 18:51:51 2016 UTC
Serial number: 1005
인증서 요청 생성 및 ipa cert-request 사용에 대한 자세한 내용은 24.1.1절. “사용자, 호스트 또는 서비스에 대한 새 인증서 요청” 을 참조하십시오.

17.2. 호스트 관리 위임

호스트는 host-add-managedby 유틸리티를 통해 다른 호스트에 대해 위임된 권한을 갖습니다. 그러면 Managedby 항목이 생성됩니다. Managedby 항목이 생성되면 호스트는 권한을 위임한 호스트의 keytab을 검색할 수 있습니다.
  1. admin 사용자로 로그인합니다.
    [root@server ~]# kinit admin
  2. managedby 항목을 추가합니다. 예를 들어, client2 대한 권한을 client 1 위임합니다.
    [root@server ~]# ipa host-add-managedby client2.example.com --hosts=client1.example.com
  3. 호스트 client1 로 티켓을 받으십시오.
    [root@client1 ~]# kinit -kt /etc/krb5.keytab host/client1.example.com
    
  4. client2 의 키 탭을 검색합니다.
    [root@client1 ~]# ipa-getkeytab -s server.example.com -k /tmp/client2.keytab -p host/client2.example.com
    Keytab successfully retrieved and stored in: /tmp/client2.keytab
    

17.3. 웹 UI에서 호스트 또는 서비스 관리 위임

IdM 웹 UI의 각 호스트 및 서비스 항목에는 해당 호스트 또는 서비스에 대한 위임된 관리 제어 호스트를 나타내는 구성 탭이 있습니다.
  1. Identity 탭을 열고 Hosts or Services (호스트 또는 서비스)를 선택합니다.
  2. 위임된 관리 권한을 부여할 호스트 또는 서비스의 이름을 클릭합니다.
  3. 호스트 또는 서비스 항목의 맨 오른쪽에 있는 Hosts (호스트)를 클릭합니다. 이 탭은 선택한 호스트 또는 서비스를 관리할 수 있는 호스트를 나열합니다.

    그림 17.2. 호스트 서브탭

    호스트 서브탭
  4. 목록 상단에 있는 Add 링크를 클릭합니다.
  5. 호스트 또는 서비스에 대한 관리를 위임할 호스트 이름별 확인란을 클릭합니다. 오른쪽 화살표 버튼 > & gt; 를 클릭하여 호스트를 선택 상자로 이동합니다.

    그림 17.3. 호스트/서비스 위임 관리

    호스트/서비스 위임 관리
  6. 추가 버튼을 클릭하여 선택 상자를 닫고 위임 설정을 저장합니다.

17.4. 잘못된 서비스 액세스

서비스 및 호스트 모두에 대해 클라이언트의 권한이 위임된 경우 로컬 시스템에서 해당 주체의 키탭을 가져올 수 있습니다. 서비스의 경우 이 형식은 service/hostname@REALM 입니다. 호스트의 경우 서비스는 host 입니다.
kinit 를 사용하는 경우 -k 옵션을 사용하여 키 탭을 로드하고 -t 옵션을 사용하여 keytab을 지정합니다. 예를 들어 다음과 같습니다.
호스트에 액세스하려면 다음을 수행합니다.
[root@server ~]# kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM
서비스에 액세스하려면 다음을 수행합니다.
[root@server ~]# kinit -kt /etc/httpd/conf/krb5.keytab HTTP/ipa.example.com@EXAMPLE.COM

18장. ID 보기

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

SSSD 성능에 대한 잠재적인 부정적인 영향

ID 보기를 적용하면 특정 최적화 및 ID 보기를 동시에 실행할 수 없기 때문에 SSSD 성능에 부정적인 영향을 미칠 수 있습니다. 예를 들어 ID 보기로 인해 SSSD에서 서버에서 그룹을 검색하는 프로세스를 최적화하지 못합니다.
  • ID 보기를 사용하는 경우 SSSD는 그룹 이름이 재정의되는 경우 반환된 그룹 멤버 이름 목록에 있는 모든 멤버를 확인해야 합니다.
  • ID 뷰가 없으면 SSSD는 group 오브젝트의 member 속성에서만 사용자 이름을 수집할 수 있습니다.
이러한 부정적인 효과는 대부분 SSSD 캐시가 비어 있거나 캐시를 지우고 캐시를 지우면 모든 항목이 유효하지 않은 경우 확인됩니다.

추가 리소스

Active Directory와 관련된 환경에서 ID 뷰도 여러 가지 사용 사례가 있습니다. 자세한 내용은 Windows 통합 가이드의 ID 보기를 사용하여 수동으로 신뢰로 마이그레이션 장을 참조하십시오.

18.1. ID 보기 특성을 재정의할 수 있음

ID 보기는 사용자 및 그룹 ID 재정의로 구성됩니다. 덮어쓰기에서는 새 특성 값을 정의합니다.
사용자 및 그룹 ID 재정의는 다음 속성에 대한 새 값을 정의할 수 있습니다.
사용자 속성
  • 로그인 이름(uid)
  • GECOS 항목 (gecos)
  • UID 번호 (uidNumber)
  • GID 번호 (gidNumber)
  • 로그인 쉘 (loginShell)
  • 홈 디렉터리 (homeDirectory)
  • SSH public keys (ipaSshPubkey)
  • 인증서(사용자 인증서)
그룹 속성
  • 그룹 이름(cn)
  • 그룹 GID 번호 (gidNumber)

18.2. ID 보기 명령에 대한 도움말 가져오기

ID 보기 및 재정의를 관리하는 데 사용되는 모든 명령을 표시하려면 다음을 수행합니다.
$ ipa help idviews
특정 명령에 대한 자세한 도움말을 표시하려면 명령에 --help 옵션을 추가합니다.
$ ipa idview-add --help

18.3. 다른 호스트에서 사용자 계정에 대한 다른 속성 값 정의

관리자는 사용자 계정에서 사용하는 특성 값을 재정의하고 이러한 ID 뷰를 다른 클라이언트 호스트에 적용하는 ID 뷰를 여러 개 생성할 수 있습니다. 예: 서비스 계정은 다른 호스트에서 인증할 때 다양한 SSH 공개 키를 사용하도록 구성됩니다.
이 섹션에는 다음과 같은 절차가 포함되어 있습니다.
이 절차에서는 host1.example.com 이라는 클라이언트 호스트에 대한 ID 보기를 생성하는 방법을 보여줍니다. 다른 호스트에서 속성 값을 재정의하려면 절차를 사용하여 각 호스트에 대해 하나씩 여러 ID 뷰를 생성합니다.
다음 절차에서는 다음을 수행합니다.
  • user 는 특성을 재정의해야 하는 사용자 계정입니다.
  • host1.example.com 은 ID 보기를 적용할 호스트입니다.
중요
새 ID 보기를 만든 후 ID 보기가 적용된 모든 클라이언트에서 SSSD를 다시 시작합니다.
새 ID 보기에서 UID 또는 GID를 변경하는 경우 이러한 클라이언트에서도 SSSD 캐시를 지웁니다.

18.3.1. 웹 UI: 특정 호스트에 대한 속성 값 덮어쓰기

ID 뷰를 관리하려면 먼저 IdM 웹 UI에 IdM 관리자로 로그인합니다.

새 ID 보기 생성

  1. Identity (ID) 탭에서 ID Views (ID 뷰)를 선택합니다.
  2. 추가를 클릭하고 ID 보기의 이름을 입력합니다.

    그림 18.1. ID 보기 추가

    ID 보기 추가
  3. 추가를 클릭하여 확인합니다.
이제 새 ID 보기가 ID 보기 목록에 표시됩니다.

그림 18.2. ID 보기 목록

ID 보기 목록

ID 보기에 사용자 덮어쓰기 추가

  1. ID 보기 목록에서 ID 보기의 이름을 클릭합니다.

    그림 18.3. ID 보기 편집

    ID 보기 편집
  2. Users 탭에서 추가 를 클릭하여 사용자 재정의를 추가합니다.
  3. 재정의할 특성 값이 있는 사용자 계정을 선택하고 추가 를 클릭합니다.
이제 사용자 덮어쓰기가 example_for_host1 ID 보기 페이지에 표시됩니다.

그림 18.4. 오버라이드 목록

오버라이드 목록

재정의할 속성 지정

  1. 특성 값을 변경하는 데 사용할 재정의를 클릭합니다.

    그림 18.5. 덮어쓰기 편집

    덮어쓰기 편집
  2. 특성의 새 값을 정의합니다.
    예를 들어 사용자 계정에서 사용하는 SSH 공개 키를 재정의하려면 다음을 수행합니다.
    1. SSH 공개 키를 클릭합니다. 추가.

      그림 18.6. SSH 공개 키 추가

      SSH 공개 키 추가
    2. 공개 키에 붙여넣기.
    참고
    IdM에 SSH 키를 추가하는 방법에 대한 자세한 내용은 22.5절. “사용자를 위한 SSH 공개 키 관리” 을 참조하십시오.
  3. 저장 을 클릭하여 재정의를 업데이트합니다.

특정 호스트에 ID 보기 적용

  1. ID 보기 목록에서 ID 보기의 이름을 클릭합니다.

    그림 18.7. ID 보기 편집

    ID 보기 편집
  2. Hosts 탭에서 호스트에 적용을 클릭합니다.
  3. host1.example.com 호스트를 선택하고 Prospective 열로 이동합니다.
  4. 적용을 클릭합니다.
이제 호스트는 ID 보기가 적용되는 호스트 목록에 표시됩니다.

그림 18.8. ID 보기에 호스트 나열

ID 보기에 호스트 나열

18.3.2. 명령줄: 특정 호스트에 대한 속성 값 덮어쓰기

ID 보기를 관리하기 전에 IdM 관리자로 티켓을 요청합니다. 예를 들어 다음과 같습니다.
$ kinit admin
  1. 새 ID 보기를 만듭니다. 예를 들어 example_for_host1 이라는 ID 보기를 생성합니다.
    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  2. 사용자 덮어쓰기를 example_for_host1 ID 뷰에 추가합니다. ipa idoverrideuser-add 명령에는 ID 보기의 이름과 재정의할 사용자가 필요합니다.
    • 새 특성 값을 지정하려면 해당 명령줄 옵션도 추가합니다. 사용 가능한 옵션 목록은 ipa idoverrideuser-add --help 를 실행합니다. 예를 들어 --sshpubkey 옵션을 사용하여 SSH 공개 키 값을 재정의합니다.
      $ ipa idoverrideuser-add example_for_host1 user --sshpubkey="ssh-rsa AAAAB3NzaC1yrRqFE...gWRL71/miPIZ user@example.com"
      -----------------------------
      Added User ID override "user"
      -----------------------------
        Anchor to override: user
        SSH public key: ssh-rsa
                        AAAB3NzaC1yrRqFE...gWRL71/miPIZ
      		  user@example.com
      참고
      IdM에 SSH 키를 추가하는 방법에 대한 자세한 내용은 22.5절. “사용자를 위한 SSH 공개 키 관리” 을 참조하십시오.
    • ipa idoverrideuser-add --certificate 명령은 지정된 ID 보기의 계정의 기존 인증서를 모두 대체합니다. 추가 인증서를 추가하려면 ipa idoverrideuser-add-cert 명령을 사용합니다.
      $ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
    • ipa idoverrideuser-mod 명령을 사용하면 기존 사용자 재정의에 대한 새 특성 값을 지정할 수도 있습니다.
    • ipa idoverrideuser-del 명령을 사용하여 사용자 재정의를 삭제합니다.
      참고
      이 명령을 사용하여 SSH 키를 삭제하면 캐시에서 SSH 키를 즉시 삭제하지 않습니다. 기본 캐시 시간 초과 값(entry_cache_timeout = 5400)을 사용하면 키가 1시간 반 동안 캐시에 남아 있습니다.
  3. host1.example.com 호스트에 example_for_host1 을 적용합니다.
    $ ipa idview-apply example_for_host1 --hosts=host1.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------
    참고
    ipa idview-apply 명령은 --hostgroups 옵션도 허용합니다. 옵션은 지정된 호스트 그룹에 속하는 호스트에 ID 보기를 적용하지만 ID 보기는 호스트 그룹 자체와 연결하지 않습니다. 대신, hostgroups 옵션은 지정된 호스트 그룹의 멤버를 확장하고 --hosts 옵션을 개별적으로 적용합니다.

19장. IdM 사용자를 위한 액세스 제어 정의

액세스 제어는 머신, 서비스 또는 항목과 같은 특정 리소스에 액세스할 수 있는 사용자와 수행할 수 있는 작업 종류를 정의하는 일련의 보안 기능입니다. Identity Management는 여러 액세스 제어 영역을 제공하여 어떤 종류의 액세스 권한이 부여되고 누구에게 부여되었는지 명확하게 이해할 수 있도록 합니다. 이 과정의 일환으로 Identity Management는 도메인 내의 리소스에 대한 액세스 제어와 IdM 구성 자체에 대한 액세스 제어를 구분하는 역할을 합니다.
IdM 서버 및 기타 IdM 사용자에게 IdM 내에서 사용자가 사용할 수 있는 다양한 내부 액세스 제어 메커니즘에 대한 자세한 내용은 10장. IdM 사용자를 위한 액세스 제어 정의 을 참조하십시오.

20장. Kerberos Flags 및 주요 별칭 관리

20.1. 서비스 및 호스트용 Kerberos 플래그

다양한 Kerberos 플래그를 사용하여 Kerberos 티켓 동작의 특정 측면을 정의할 수 있습니다. 이 플래그를 service 및 host Kerberos principals에 추가할 수 있습니다.
IdM(Identity Management)의 주체는 다음 Kerberos 플래그를 허용합니다.
OK_AS_DELEGATE
이 플래그를 사용하여 위임을 위해 신뢰할 수 있는 Kerberos 티켓을 지정합니다.
AD(활성 디렉터리) 클라이언트는 Kerberos 티켓에서 OK_AS_DELEGATE 플래그를 확인하여 사용자 자격 증명을 특정 서버에 전달하거나 위임할 수 있는지 확인합니다. AD는 TGT( ticket-granting ticket)를 OK_AS_DELEGATE 가 설정된 서비스 또는 호스트에만 전달합니다. 이 플래그를 사용하면 SSSD(시스템 보안 서비스 데몬)에서 IdM 클라이언트 시스템의 기본 Kerberos 자격 증명 캐시에 AD 사용자 TGT를 추가할 수 있습니다.
REQUIRES_PRE_AUTH
이 플래그를 사용하여 사전 인증 티켓만 보안 주체에 인증할 수 있도록 지정합니다.
REQUIRES_PRE_AUTH 플래그를 설정하면 KDC(키 배포 센터)에 추가 인증이 필요합니다. TGT가 TGT가 사전 인증되지 않은 경우에만 REQUIRES_PRE_AUTH 의 보안 주체에 대해 TGT를 발행합니다.
REQUIRES_PRE_AUTH 를 지우면 선택한 서비스 또는 호스트에 대해 사전 인증을 비활성화하면 CloudEvent의 부하가 줄어들지만 장기 키에서 무차별 공격 가능성이 약간 높아집니다.
OK_TO_AUTH_AS_DELEGATE
OK_TO_AUTH_AS_DELEGATE 플래그를 사용하여 서비스가 사용자를 대신하여 kerberos 티켓을 받을 수 있도록 지정합니다. 이는 프로토콜 전환을 수행하기에 충분하지만, 사용자를 대신하여 다른 티켓을 얻으려면 서비스에 OK_AS_DELEGATE 플래그와 키 분배 센터 측에서 허용되는 해당 정책 결정이 필요합니다.

20.1.1. 웹 UI에서 Kerberos 플래그 설정

OK_AS_DELEGATE,REQUIRES_PRE_AUTH, OK_TO_AUTH_AS_DELEGATE 를 주체에 추가하려면 다음을 수행하십시오.
  1. ID 기본 탭을 통해 액세스할 수 있는 Services (서비스)를 선택합니다.

    그림 20.1. 서비스 목록

    서비스 목록
  2. 플래그를 추가할 서비스를 클릭합니다.
  3. 설정할 옵션을 확인합니다. 예를 들어 REQUIRES_PRE_AUTH 플래그를 설정하려면 Requires pre-authentication 옵션을 확인합니다.

    그림 20.2. REQUIRES_PRE_AUTH 플래그 추가

    REQUIRES_PRE_AUTH 플래그 추가
    다음 표에는 Kerberos 플래그의 이름과 웹 UI의 해당 이름이 나열되어 있습니다.

    표 20.1. WebUI에서의 Kerberos 플래그 매핑

    Kerberos 플래그 이름 웹 UI 옵션
    OK_AS_DELEGATE 신뢰할 수 있는 위임
    REQUIRES_PRE_AUTH 사전 인증 필요
    OK_TO_AUTH_AS_DELEGATE 사용자로 인증할 수 있는 신뢰할 수 있음

20.1.2. 명령줄에서 Kerberos 플래그 설정 및 제거

명령행의 주체에 플래그를 추가하거나 플래그를 제거하려면 ipa service-mod 명령에 다음 옵션 중 하나를 추가합니다.
  • --ok-as-delegate for OK_AS_DELEGATE
  • --requires-pre-auth for REQUIRES_PRE_AUTH
  • --OK-to-auth-as-delegate for OK_TO_AUTH_AS_DELEGATE
플래그를 추가하려면 해당 옵션을 1 로 설정합니다. 예를 들어 서비스/ipa.example.com@EXAMPLE.COM 주체에 OK_AS_DELEGATE 플래그를 추가하려면 다음을 수행합니다.
$ ipa service-mod service/ipa.example.com@EXAMPLE.COM --ok-as-delegate=1
플래그를 제거하거나 비활성화하려면 해당 옵션을 0 으로 설정합니다. 예를 들어 test/ipa.example.com@EXAMPLE.COM 주체에 대해 REQUIRES_PRE_AUTH 플래그를 비활성화하려면 다음을 수행합니다.
$ ipa service-mod test/ipa.example.com@EXAMPLE.COM --requires-pre-auth=0

20.1.3. 명령줄에서 Kerberos 플래그 표시

현재 보안 주체에 대해 OK_AS_DELEGATE 가 설정되어 있는지 확인하려면 다음을 수행하십시오.
  1. kvno 유틸리티를 실행합니다.
  2. klist -f 명령을 실행합니다.
OK_AS_DELEGATEklist -f 출력의 O 문자로 표시됩니다.
$ kvno test/ipa.example.com@EXAMPLE.COM
$ klist -f
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@EXAMPLE.COM

Valid starting		Expires			Service principal
02/19/2014 09:59:02	02/20/2014 08:21:33	test/ipa/example.com@EXAMPLE.COM
    Flags: FATO

표 20.2. kerberos 플래그의 약어

Kerberos 플래그 이름 약어
OK_AS_DELEGATE O
REQUIRES_PRE_AUTH A
OK_TO_AUTH_AS_DELEGATE F
현재 보안 주체에 설정된 플래그를 찾으려면 kadmin.local 유틸리티를 사용합니다. 현재 플래그는 kadmin.local 출력의 Attributes 행에 표시됩니다. 예를 들면 다음과 같습니다.
# kadmin.local
kadmin.local: getprinc test/ipa.example.com
Principal: test/ipa.example.com@EXAMPLE.COM
Expiration date: [never]
...
Attributes: REQUIRES_PRE_AUTH OK_AS_DELEGATE OK_TO_AUTH_AS_DELEGATE
Policy: [none]

20.2. 사용자, 호스트 및 서비스에 대한 Kerberos 기본 별칭 관리

새 사용자, 호스트 또는 서비스를 생성하면 다음 형식의 Kerberos 사용자가 자동으로 추가됩니다.
  • user_name@REALM
  • host/host_name@REALM
  • service_name/host_name@REALM
일부 시나리오에서는 관리자가 별칭을 사용하여 Kerberos 애플리케이션에 대해 인증할 수 있도록 사용자, 호스트 또는 서비스를 활성화하는 것이 좋습니다. 예를 들면 다음과 같습니다.
  • 사용자 이름이 변경되었지만 사용자가 이전 사용자 이름과 새 사용자 이름을 모두 사용하여 로그인할 수 있어야 합니다.
  • IdM Kerberos 영역이 이메일 도메인과 다른 경우에도 사용자는 이메일 주소를 사용하여 로그인해야 합니다.
사용자 이름을 변경할 경우 오브젝트가 별칭과 이전의 표준 주체 이름을 유지합니다.

20.2.1. Kerberos 기본 별칭

Kerberos 기본 별칭 추가

별칭 이름 useralias 를 계정 사용자에게 추가하려면 다음을 입력합니다.
[root@ipaserver ~]# ipa user-add-principal user useralias
--------------------------------
Added new aliases to user "user"
--------------------------------
         User login: user
    Principal alias: user@IDM.EXAMPLE.COM, useralias@IDM.EXAMPLE.COM
호스트 또는 서비스에 별칭을 추가하려면 ipa host-add-principal 또는 ipa service-add-principal 명령을 사용합니다.
별칭 이름을 사용하여 인증하는 경우 kinit 명령에 -C 옵션을 전달합니다.
[root@ipaserver ~]# kinit -C useralias
Password for user@IDM.EXAMPLE.COM:

Kerberos 기본 별칭 제거

계정 사용자가 별칭 useralias 를 제거하려면 다음을 입력합니다.
[root@ipaserver ~]# ipa user-remove-principal user useralias
--------------------------------
Removed aliases from user "user"
--------------------------------
  User login: user
  Principal alias: user@IDM.EXAMPLE.COM
호스트 또는 서비스에서 별칭을 제거하려면 ipa host-remove-principal 또는 ipa service-remove-principal 명령을 사용합니다.
정식 주체 이름은 제거할 수 없습니다.
[root@ipaserver ~]# ipa user-show user
  User login: user
  ...
  Principal name: user@IDM.EXAMPLE.COM
  ...

[root@ipaserver ~]# ipa user-remove-principal user user
ipa: ERROR: invalid 'krbprincipalname': at least one value equal to the canonical principal name must be present

20.2.2. Kerberos Enterprise 보안 주체 별칭

엔터프라이즈 기본 별칭은 UN(사용자 주체 이름) 접미사, NetBIOS 이름 또는 신뢰할 수 있는 Active Directory 포리스트 도메인의 도메인 이름을 제외한 모든 도메인 접미사를 사용할 수 있습니다.
참고
엔터프라이즈 주요 별칭을 추가하거나 제거하는 경우 두 백슬래시(\\)를 사용하여 @ 기호를 이스케이프합니다. 그렇지 않으면 쉘은 @ 기호를 Kerberos 영역 이름의 일부로 해석하고 다음 오류가 발생합니다.
ipa: ERROR: The realm for the principal does not match the realm for this IPA server

Kerberos Enterprise 보안 주체 별칭 추가

사용자 계정에 엔터프라이즈 주체 별칭 user@example.com 을 추가하려면 다음을 수행합니다.
[root@ipaserver ~]# ipa user-add-principal user user\\@example.com
--------------------------------
Added new aliases to user "user"
--------------------------------
         User login: user
    Principal alias: user@IDM.EXAMPLE.COM, user\@example.com@IDM.EXAMPLE.COM
호스트 또는 서비스에 엔터프라이즈 별칭을 추가하려면 ipa host-add-principal 또는 ipa service-add-principal 명령을 사용합니다.
엔터프라이즈 사용자 이름을 사용하여 인증하는 경우 kinit 명령에 -E 옵션을 전달합니다.
[root@ipaserver ~]# kinit -E user@example.com
Password for user\@example.com@IDM.EXAMPLE.COM:

Kerberos Enterprise 보안 주체 별칭 제거

계정 사용자 에서 엔터프라이즈 주체 별칭 user@example.com 을 제거하려면 다음을 입력합니다.
[root@ipaserver ~]# ipa user-remove-principal user user\\@example.com
--------------------------------
Removed aliases from user "user"
--------------------------------
  User login: user
  Principal alias: user@IDM.EXAMPLE.COM
호스트 또는 서비스에서 별칭을 제거하려면 ipa host-remove-principal 또는 ipa service-remove-principal 명령을 사용합니다.

21장. NIS 도메인 및 Netgroups와 통합

21.1. NIS 및 ID 관리 정보

UNIX 환경에서 NIS(네트워크 정보 서비스)는 ID와 인증을 중앙에서 관리하는 일반적인 방법입니다. 원래 Yellow Pages (YP)라는 이름의 NIS는 다음과 같은 인증 및 ID 정보를 중앙에서 관리합니다.
  • 사용자 및 암호
  • 호스트 이름 및 IP 주소
  • POSIX 그룹.
최신 네트워크 인프라의 경우 예를 들어 호스트 인증을 제공하지 않으며 네트워크를 통해 암호화된 데이터를 제공하지 않기 때문에 NIS는 너무 안전하지 않은 것으로 간주됩니다. 이 문제를 해결하기 위해 NIS는 보안을 강화하기 위해 종종 다른 프로토콜과 통합됩니다.
IdM(Identity Management)을 사용하는 경우 NIS 서버 플러그인을 사용하여 IdM으로 완전히 마이그레이션할 수 없는 클라이언트를 연결할 수 있습니다. IdM은 넷 그룹 및 기타 NIS 데이터를 IdM 도메인에 통합합니다. 또한 사용자 및 호스트 ID를 NIS 도메인에서 IdM으로 쉽게 마이그레이션할 수 있습니다.

Identity Management의 NIS

NIS 객체는 RFC 2307 을 준수하여 Directory Server 백엔드에 통합 및 저장됩니다. IdM은 LDAP 디렉터리에 NIS 오브젝트를 생성하고 클라이언트는 암호화된 LDAP 연결을 사용하여 SSSD(System Security Services Daemon) 또는 nss_ldap 와 같이 이를 검색합니다.
IdM은 네트워크 그룹, 계정, 그룹, 호스트 및 기타 데이터를 관리합니다. IdM은 NIS 리스너를 사용하여 암호, 그룹 및 넷그룹을 IdM 항목에 매핑합니다.

Identity Management의 NIS 플러그인

NIS 지원의 경우 IdM은 slapi-nis 패키지에 제공된 다음 플러그인을 사용합니다.
NIS 서버 플러그인
NIS 서버 플러그인을 사용하면 IdM 통합 LDAP 서버가 클라이언트의 NIS 서버로 작동할 수 있습니다. 이 역할에서 Directory Server는 구성에 따라 NIS 맵을 동적으로 생성하고 업데이트합니다. IdM은 플러그인을 사용하여 NIS 프로토콜을 NIS 서버로 사용하는 클라이언트에 서비스를 제공합니다.
자세한 내용은 21.2절. “ID 관리에서 NIS 활성화” 의 내용을 참조하십시오.
스키마 호환성 플러그인
스키마 호환성 플러그인을 사용하면 Directory Server 백엔드에서 DIT(디렉터리 정보 트리)의 부분에 저장된 항목의 대체 보기를 제공할 수 있습니다. 여기에는 특성 값 추가, 삭제 또는 이름 변경 및 선택적으로 트리의 여러 항목에서 속성에 대한 값을 검색하는 작업이 포함됩니다.
자세한 내용은 /usr/share/doc/slapi-nis-version/sch-getting-started.txt 파일을 참조하십시오.

21.1.1. Identity Management의 NIS Netgroups

NIS 엔터티는 네트그룹에 저장할 수 있습니다. 넷그룹은 UNIX 그룹과 비교했을 때 다음을 지원합니다.
  • 중첩 그룹(다른 그룹의 구성원으로서 그룹).
  • 호스트 그룹화.
netgroup은 host, user 및 domain 정보 집합을 정의합니다. 이 세트를 삼중 이라고 합니다. 다음 세 필드에는 다음을 포함할 수 있습니다.
  • 값.
  • "유효한 값"을 지정하는 대시(-)
  • 값이 없습니다. 빈 필드는 와일드카드를 지정합니다.
(host.example.com,,nisdomain.example.com)
(-,user,nisdomain.example.com)
클라이언트가 NIS netgroup을 요청하면 IdM이 LDAP 항목을 변환합니다.
  • 기존 NIS 맵으로 전송하여 NIS 프로토콜을 통해 클라이언트로 전송합니다. NIS 플러그인을 사용합니다.
  • RFC 2307 또는 RFC 2307 bis와 호환되는 LDAP 형식입니다.

21.1.1.1. NIS Netgroup Entries 표시

IdM은 사용자 및 그룹을 memberUser 속성에 저장하고 호스트 및 호스트 그룹을 memberHost 에 저장합니다. 다음 예제는 IdM의 Directory Server 구성 요소에 있는 netgroup 항목을 보여줍니다.

예 21.1. 디렉터리 서버 내 NIS 항목

dn: ipaUniqueID=d4453480-cc53-11dd-ad8b-0800200c9a66,cn=ng,cn=alt,...
...
cn: netgroup1
memberHost: fqdn=host1.example.com,cn=computers,cn=accounts,...
memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,...
memberUser: cn=demo,cn=users,cn=accounts,...
memberUser: cn=Engineering,cn=groups,cn=accounts,...
nisDomainName: nisdomain.example.com
IdM에서는 ipa netgroup-* 명령을 사용하여 netgroup 항목을 관리할 수 있습니다. 예를 들어 netgroup 항목을 표시하려면 다음을 수행합니다.

예 21.2. Netgroup Entry 표시

[root@server ~]# ipa netgroup-show netgroup1
Netgroup name: netgroup1
Description: my netgroup
NIS domain name: nisdomain.example.com
Member Host: VirtGuests
Member Host: host1.example.com
Member User: demo
Member User: Engineering

21.2. ID 관리에서 NIS 활성화

ID 관리에서 NIS를 활성화하려면 다음을 수행합니다.
  1. NIS 리스너 및 호환성 플러그인을 활성화합니다.
    [root@ipaserver ~]# ipa-nis-manage enable
    [root@ipaserver ~]# ipa-compat-manage enable
  2. 선택 사항: NIS 원격 프로시저 호출(RPC)의 고정 포트를 설정합니다.
    NIS를 사용하는 경우 클라이언트는 IdM 서버에서 연결을 설정하는 데 사용할 포트를 알아야 합니다. 기본 설정을 사용하면 서버가 시작될 때 IdM이 사용되지 않은 임의의 포트에 바인딩됩니다. 이 포트는 클라이언트가 포트 번호를 요청하는 데 사용하는 포트 매퍼 서비스로 전송됩니다.
    좀 더 엄격한 방화벽 구성의 경우 고정 포트를 설정할 수 있습니다. 예를 들어 포트를 514 로 설정하려면 다음을 실행합니다.
    [root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -W
    dn: cn=NIS Server,cn=plugins,cn=config
    changetype: modify
    add: nsslapd-pluginarg0
    nsslapd-pluginarg0: 514
    참고
    설정에 대해 미사용 포트 번호를 1024 미만으로 설정할 수 있습니다.
  3. 포트 매퍼 서비스를 활성화하고 시작합니다.
    [root@ipaserver ~]# systemctl enable rpcbind.service
    [root@ipaserver ~]# systemctl start rpcbind.service
  4. Directory Server를 다시 시작하십시오.
    [root@ipaserver ~]# systemctl restart dirsrv.target

21.3. Netgroups 생성

21.3.1. Netgroup 추가

Netgroup을 추가하려면 다음을 사용합니다.

웹 UI: Netgroup 추가

  1. IdentityGroupsNetgroups선택
  2. 추가를 클릭합니다.
  3. 고유한 이름 및 설명을 선택적으로 입력합니다. 그룹 이름은 IdM 도메인의 netgroup에 사용되는 식별자입니다. 나중에 변경할 수 없습니다.
  4. 추가 및 편집 을 클릭하여 변경 사항을 저장하고 항목을 편집하기 시작합니다.
  5. 기본 NIS 도메인은 IdM 도메인 이름으로 설정됩니다. 선택적으로 NIS 도메인 이름 필드에 대체 NIS 도메인의 이름을 입력할 수 있습니다.

    그림 21.1. netgroup 탭

    netgroup 탭
    NIS 도메인 이름 필드는 netgroupation에 표시되는 도메인을 설정합니다. ID 관리 NIS 리스너가 응답하는 NIS 도메인에는 영향을 미치지 않습니다.
  6. “웹 UI: Netgroup에 멤버 추가” 에 설명된 대로 멤버를 추가합니다.
  7. 저장을 클릭합니다.

명령줄: Netgroup 추가

ipa netgroup-add 명령을 사용하여 새 netgroup을 추가할 수 있습니다. 다음을 지정합니다.
  • 그룹 이름입니다.
  • 선택적으로 설명.
  • IdM 도메인 이름과 다른 경우 NIS 도메인 이름입니다.
    참고
    ni sdomain 옵션은 netgroup 3에 표시되는 도메인을 설정합니다. ID 관리 리스너가 응답하는 NIS 도메인에는 영향을 미치지 않습니다.
예를 들어 다음과 같습니다.
[root@server ~]# ipa netgroup-add --desc="Netgroup description" --nisdomain="example.com" example-netgroup
netgroup에 멤버를 추가하려면 “명령줄: Netgroup에 멤버 추가” 을 참조하십시오.

21.3.2. Netgroup에 멤버 추가

사용자 및 호스트 옆에 있는 네트그룹은 사용자 그룹, 호스트 그룹 및 기타 네트그룹(네트그룹)을 멤버로 포함할 수 있습니다. 그룹 크기에 따라 하위 그룹의 구성원에 대해 중첩 그룹을 만들어 상위 그룹의 멤버로 표시될 때까지 최대 몇 분이 걸릴 수 있습니다.
Netgroup에 멤버를 추가하려면 다음을 사용합니다.
주의
재귀적 중첩 그룹을 만들지 마십시오. 예를 들어 GroupA 가 Group B의 멤버인 경우 Group A 의 멤버로 GroupB 를 추가하지 마십시오. 재귀적 그룹은 지원되지 않으며 예기치 않은 동작을 초래할 수 있습니다.

웹 UI: Netgroup에 멤버 추가

웹 UI를 사용하여 netgroup에 멤버를 추가하려면 다음을 수행합니다.
  1. IdentityGroupsNetgroups선택
  2. 멤버를 추가할 netgroup의 이름을 클릭합니다.
  3. 필요한 멤버 유형 옆에 있는 추가 를 클릭합니다.

    그림 21.2. Netgroup 탭의 사용자 메뉴

    Netgroup 탭의 사용자 메뉴
  4. 추가할 멤버를 선택하고 >를 클릭하여 확인합니다.

    그림 21.3. Netgroup 탭에서 사용자 메뉴 추가

    Netgroup 탭에서 사용자 메뉴 추가
  5. 추가를 클릭합니다.

명령줄: Netgroup에 멤버 추가

netgroup을 생성한 후에는 ipa netgroup-add-member 명령을 사용하여 멤버를 추가할 수 있습니다.
# ipa netgroup-add-member --users=user_name --groups=group_name --hosts=host_name \
     --hostgroups=host_group_name --netgroups=netgroup_name group_nameame
둘 이상의 멤버를 설정하려면 중괄호 집합 내에 쉼표로 구분된 목록을 사용합니다. 예를 들어 다음과 같습니다.
[root@server ~]# ipa netgroup-add-member --users={user1;user2,user3} \
     --groups={group1,group2} example-group

21.4. NIS 클라이언트에 자동 마운트 맵 노출

자동 마운트 맵이 이미 정의된 경우 IdM의 NIS 설정에 수동으로 추가해야 합니다. 이렇게 하면 매핑이 NIS 클라이언트에 노출됩니다.
NIS 서버는 IdM LDAP 디렉터리의 특수 플러그인 항목으로 관리합니다. NIS 서버에서 사용하는 각 NIS 도메인 및 맵은 이 컨테이너에 하위 항목으로 추가됩니다. NIS 도메인 항목에는 다음이 포함됩니다.
  • NIS 도메인의 이름입니다.
  • NIS 맵의 이름입니다.
  • NIS 맵의 콘텐츠로 사용할 디렉토리 항목을 찾는 방법에 대한 정보
  • NIS 맵의 키와 값으로 사용할 속성에 대한 정보
이러한 설정은 모든 맵에 대해 대부분 동일합니다.

21.4.1. 자동 마운트 맵 추가

IdM은 IdM 디렉터리 트리의 cn=automount 브랜치를 통해 mount 위치에 그룹화된 자동 마운트 맵을 저장합니다. LDAP 프로토콜을 사용하여 NIS 도메인 및 맵을 추가할 수 있습니다.
예를 들어 example.com 도메인의 기본 위치에 auto.example 이라는 mount 맵을 추가하려면 다음을 수행합니다.
[root@server ~]# ldapadd -h server.example.com -x -D "cn=Directory Manager" -W

dn: nis-domain=example.com+nis-map=auto.example,cn=NIS Server,cn=plugins,cn=config
objectClass: extensibleObject
nis-domain: example.com
nis-map: auto.example
nis-filter: (objectclass=automount)
nis-key-format: %{automountKey}
nis-value-format: %{automountInformation}
nis-base: automountmapname=auto.example,cn=default,cn=automount,dc=example,dc=com
참고
nis-domain 특성을 NIS 도메인 이름으로 설정합니다.
nis-base 특성에 설정된 값은 다음과 같아야 합니다.
  • ipa engagementmap-* 명령을 사용하여 설정된 기존의 autoscale Map입니다.
  • ipaParamlocation-* 명령을 사용하여 설정한 기존의 autoscale location 입니다.
항목을 설정한 후 자동 마운트 맵을 확인할 수 있습니다.
[root@server ~]# ypcat -k -d example.com -h server.example.com auto.example

21.5. NIS에서 IdM으로 마이그레이션

기존 NIS 서버에서 IdM(Identity Management)으로 마이그레이션하려면 다음 단계를 수행해야 합니다.

21.5.1. IdM에서 Netgroup Entries 준비

마이그레이션하기 전에 현재 NIS 서버에서 관리 중인 ID를 확인합니다.
사용자 항목
NIS에서 제공하는 사용자 정보를 사용하고 있는 애플리케이션 확인. sudo 와 같은 일부 유틸리티에는 NIS netgroups가 필요하지만 다른 일부 유틸리티에서는 일반 UNIX 그룹을 사용할 수 있습니다.
마이그레이션하려면 다음을 수행합니다.
  1. IdM에 해당 사용자 계정을 생성합니다. 21.5.3.1절. “사용자 항목 마이그레이션” 참조하십시오.
  2. 또한 netgroups가 필요한 경우:
    1. 네트그룹을 추가합니다. 21.3.1절. “Netgroup 추가” 참조하십시오.
    2. 사용자를 netgroup에 추가합니다. 21.5.3.4절. “Netgroup Entries 마이그레이션” 참조하십시오.
호스트 항목
IdM에서 호스트 그룹을 생성하면 해당 shadow NIS 그룹이 자동으로 생성됩니다. 이 shadow NIS 그룹에서 ipa netgroup-* 명령을 사용하지 마십시오. ipa netgroup-* 명령을 사용하여 netgroup-add 명령을 통해 생성된 기본 netgroups만 관리합니다.
직접 변환의 경우
모든 사용자 및 호스트 항목에 동일한 이름을 사용해야 하는 경우 IdM에서 동일한 이름을 사용하여 항목을 생성할 수 있습니다.
  1. netgroup에서 참조한 모든 사용자에 대한 항목을 만듭니다.
  2. netgroup에서 참조되는 모든 호스트에 대한 항목을 만듭니다.
  3. 원래 netgroup과 동일한 이름으로 netgroup을 만듭니다.
  4. 사용자 및 호스트를 netgroup의 직접 구성원으로 추가합니다. 사용자와 호스트가 그룹 또는 호스트 그룹의 구성원인 경우 이러한 그룹을 netgroup에 추가할 수도 있습니다.

21.5.2. ID 관리에서 NIS Listener 활성화

21.5.3. 기존 NIS 데이터 내보내기 및 가져오기

NIS 서버에는 사용자, 그룹, 호스트, 네트그룹 및 자동 마운트 맵에 대한 정보가 포함될 수 있습니다. 이러한 항목 유형을 IdM로 마이그레이션할 수 있습니다.
다음 섹션에서는 ypcat 명령을 사용하여 현재 NIS 서버의 데이터를 내보내고 해당 ipa *-add 명령을 사용하여 출력을 IdM으로 가져옵니다.
  • 마이그레이션 스크립트에서 사용된 ypcat 명령을 제공하므로 yp-tools 패키지를 설치해야 합니다.
    [root@nis-server ~]# yum install yp-tools -y

21.5.3.1. 사용자 항목 마이그레이션

NIS passwd 맵에는 이름, UID, 기본 그룹, GECOS, 쉘 및 홈 디렉터리와 같은 사용자에 대한 정보가 포함되어 있습니다. 이 데이터를 사용하여 NIS 사용자 계정을 IdM으로 마이그레이션합니다.
  1. 선택 사항: 취약한 암호 지원이 필요한 경우 21.5.4절. “NIS 사용자 인증을 위한 Weak Password Hashing 활성화” 을 참조하십시오.
  2. 다음 콘텐츠를 사용하여 /root/nis-users.sh 스크립트를 만듭니다.
    #!/bin/sh
    # $1 is the NIS domain, $2 is the NIS master server
    ypcat -d $1 -h $2 passwd > /dev/shm/nis-map.passwd 2>&1
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.passwd) ; do
    	IFS=' '
    	username=$(echo $line | cut -f1 -d:)
    	# Not collecting encrypted password because we need cleartext password
    	# to create kerberos key
    	uid=$(echo $line | cut -f3 -d:)
    	gid=$(echo $line | cut -f4 -d:)
    	gecos=$(echo $line | cut -f5 -d:)
    	homedir=$(echo $line | cut -f6 -d:)
    	shell=$(echo $line | cut -f7 -d:)
    
    	# Now create this entry
    	echo passw0rd1 | ipa user-add $username --first=NIS --last=USER \
    	     --password --gidnumber=$gid --uid=$uid --gecos="$gecos" --homedir=$homedir \
    	     --shell=$shell
    	ipa user-show $username
    done
  3. IdM admin 사용자로 인증합니다.
    [root@nis-server ~]# kinit admin
  4. 스크립트를 실행합니다. 예를 들어 다음과 같습니다.
    [root@nis-server ~]# sh /root/nis-users.sh nisdomain nis-master.example.com
    참고
    이 스크립트는 이름, 성에 하드 코딩된 값을 사용하고 암호를 passw0rd1 로 설정합니다. 사용자는 다음 로그인 시 임시 암호를 변경해야 합니다.

21.5.3.2. 그룹 항목 마이그레이션

NIS 그룹 맵에 는 그룹 이름, GID 또는 그룹 멤버와 같은 그룹에 대한 정보가 포함되어 있습니다. 이 데이터를 사용하여 NIS 그룹을 IdM으로 마이그레이션합니다.
  1. 다음 콘텐츠를 사용하여 /root/nis-groups.sh 스크립트를 생성합니다.
    #!/bin/sh
    # $1 is the NIS domain, $2 is the NIS master server
    ypcat -d $1 -h $2 group > /dev/shm/nis-map.group 2>&1
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.group); do
    	IFS=' '
    	groupname=$(echo $line | cut -f1 -d:)
    	# Not collecting encrypted password because we need cleartext password
    	# to create kerberos key
    	gid=$(echo $line | cut -f3 -d:)
    	members=$(echo $line | cut -f4 -d:)
    
    	# Now create this entry
    	ipa group-add $groupname --desc=NIS_GROUP_$groupname --gid=$gid
    	if [ -n "$members" ]; then
    		ipa group-add-member $groupname --users={$members}
    	fi
    	ipa group-show $groupname
    done
  2. IdM admin 사용자로 인증합니다.
    [root@nis-server ~]# kinit admin
  3. 스크립트를 실행합니다. 예를 들어 다음과 같습니다.
    [root@nis-server ~]# sh /root/nis-groups.sh nisdomain nis-master.example.com

21.5.3.3. 호스트 항목 마이그레이션

NIS 호스트 맵에 는 호스트 이름 및 IP 주소와 같은 호스트에 대한 정보가 포함되어 있습니다. 이 데이터를 사용하여 NIS 호스트 항목을 IdM으로 마이그레이션합니다.
  1. 다음 콘텐츠를 사용하여 /root/nis-hosts.sh 스크립트를 만듭니다.
    #!/bin/sh
    # $1 is the NIS domain, $2 is the NIS master server
    ypcat -d $1 -h $2 hosts | egrep -v "localhost|127.0.0.1" > /dev/shm/nis-map.hosts 2>&1
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.hosts); do
    	IFS=' '
    	ipaddress=$(echo $line | awk '{print $1}')
    	hostname=$(echo $line | awk '{print $2}')
    	master=$(ipa env xmlrpc_uri | tr -d '[:space:]' | cut -f3 -d: | cut -f3 -d/)
    	domain=$(ipa env domain | tr -d '[:space:]' | cut -f2 -d:)
    	if [ $(echo $hostname | grep "\." |wc -l) -eq 0 ] ; then
    		hostname=$(echo $hostname.$domain)
    	fi
    	zone=$(echo $hostname | cut -f2- -d.)
    	if [ $(ipa dnszone-show $zone 2>/dev/null | wc -l) -eq 0 ] ; then
    		ipa dnszone-add --name-server=$master --admin-email=root.$master
    	fi
    	ptrzone=$(echo $ipaddress | awk -F. '{print $3 "." $2 "." $1 ".in-addr.arpa."}')
    	if [ $(ipa dnszone-show $ptrzone 2>/dev/null | wc -l) -eq 0 ] ; then
    		ipa dnszone-add  $ptrzone --name-server=$master --admin-email=root.$master
    	fi
    	# Now create this entry
    	ipa host-add $hostname --ip-address=$ipaddress
    	ipa host-show $hostname
    done
  2. IdM admin 사용자로 인증합니다.
    [root@nis-server ~]# kinit admin
  3. 스크립트를 실행합니다. 예를 들어 다음과 같습니다.
    [root@nis-server ~]# sh /root/nis-hosts.sh nisdomain nis-master.example.com
    참고
    이 스크립트는 별칭과 같은 특수 호스트 구성을 마이그레이션하지 않습니다.

21.5.3.4. Netgroup Entries 마이그레이션

NIS netgroup 맵에는 netgroups에 대한 정보가 포함되어 있습니다. 이 데이터를 사용하여 NIS netgroups를 IdM으로 마이그레이션합니다.
  1. 다음 콘텐츠를 사용하여 /root/nis-netgroups.sh 스크립트를 생성합니다.
    #!/bin/sh
    # $1 is the NIS domain, $2 is the NIS master server
    ypcat -k -d $1 -h $2 netgroup > /dev/shm/nis-map.netgroup 2>&1
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.netgroup); do
    	IFS=' '
    	netgroupname=$(echo $line | awk '{print $1}')
    	triples=$(echo $line | sed "s/^$netgroupname //")
    	echo "ipa netgroup-add $netgroupname --desc=NIS_NG_$netgroupname"
    	if [ $(echo $line | grep "(," | wc -l) -gt 0 ]; then
    		echo "ipa netgroup-mod $netgroupname --hostcat=all"
    	fi
    	if [ $(echo $line | grep ",," | wc -l) -gt 0 ]; then
    		echo "ipa netgroup-mod $netgroupname --usercat=all"
    	fi
    
    	for triple in $triples; do
    		triple=$(echo $triple | sed -e 's/-//g' -e 's/(//' -e 's/)//')
    		if [ $(echo $triple | grep ",.*," | wc -l) -gt 0 ]; then
    			hostname=$(echo $triple | cut -f1 -d,)
    			username=$(echo $triple | cut -f2 -d,)
    			domain=$(echo $triple | cut -f3 -d,)
    			hosts=""; users=""; doms="";
    			[ -n "$hostname" ] && hosts="--hosts=$hostname"
    			[ -n "$username" ] && users="--users=$username"
    			[ -n "$domain"   ] && doms="--nisdomain=$domain"
    			echo "ipa netgroup-add-member $netgroup $hosts $users $doms"
    		else
    			netgroup=$triple
    			echo "ipa netgroup-add $netgroup --desc=NIS_NG_$netgroup"
    		fi
    	done
    done
  2. IdM admin 사용자로 인증합니다.
    [root@nis-server ~]# kinit admin
  3. 스크립트를 실행합니다. 예를 들어 다음과 같습니다.
    [root@nis-server ~]# sh /root/nis-netgroups.sh nisdomain nis-master.example.com

21.5.3.5. 자동 마운트 맵 마이그레이션

자동 마운트 맵은 위치(상위 항목), 관련 키 및 맵을 정의하는 일련의 중첩 및 상호 관련된 항목입니다. NIS의 마운트 해제 맵을 IdM으로 마이그레이션하려면 다음을 수행합니다.
  1. 다음 콘텐츠를 사용하여 /root/nis-automounts.sh 스크립트를 만듭니다.
    #!/bin/sh
    # $1 is for the automount entry in ipa
    
    ipa automountlocation-add $1
    
    # $2 is the NIS domain, $3 is the NIS master server, $4 is the map name
    ypcat -k -d $2 -h $3 $4 > /dev/shm/nis-map.$4 2>&1
    
    ipa automountmap-add $1 $4
    
    basedn=$(ipa env basedn | tr -d '[:space:]' | cut -f2 -d:)
    cat > /tmp/amap.ldif <<EOF
    dn: nis-domain=$2+nis-map=$4,cn=NIS Server,cn=plugins,cn=config
    objectClass: extensibleObject
    nis-domain: $2
    nis-map: $4
    nis-base: automountmapname=$4,cn=$1,cn=automount,$basedn
    nis-filter: (objectclass=*)
    nis-key-format: %{automountKey}
    nis-value-format: %{automountInformation}
    EOF
    ldapadd -x -h $3 -D "cn=Directory Manager" -W -f /tmp/amap.ldif
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.$4); do
    	IFS=" "
    	key=$(echo "$line" | awk '{print $1}')
    	info=$(echo "$line" | sed -e "s#^$key[ \t]*##")
    	ipa automountkey-add nis $4 --key="$key" --info="$info"
    done
    이 스크립트는 NIS의 정보를 내보내고, 이전 위치 및 관련 맵을 위한 LDAP LDIF(Data Interchange Format)를 생성하고, LDIF 파일을 IdM 디렉터리 서버로 가져옵니다. 자세한 내용은 21.4절. “NIS 클라이언트에 자동 마운트 맵 노출” 의 내용을 참조하십시오.
  2. IdM admin 사용자로 인증합니다.
    [root@nis-server ~]# kinit admin
  3. 스크립트를 실행합니다. 예를 들어 다음과 같습니다.
    [root@nis-server ~]# sh /root/nis-automounts.sh location nisdomain \
         nis-master.example.com map_name

21.5.4. NIS 사용자 인증을 위한 Weak Password Hashing 활성화

Directory Server 구성 요소의 기본 설정을 사용하여 userPassword 속성에 저장된 암호는 SSHA(Secure hash algorithm)를 사용하여 해시됩니다. NIS 클라이언트에 암호에 대한 약한 해싱 알고리즘이 필요한 경우 암호 스토리지 스키마 설정을 업데이트합니다.
약한 암호 해시 스키마를 활성화하면 userPassword 속성에 저장된 암호에만 영향을 미칩니다. Kerberos는 이 특성을 사용하지 않으므로 Kerberos 암호화는 이 설정의 영향을 받지 않습니다.
예를 들어 CRYPT 해시 암호를 활성화하려면 다음을 수행합니다.
[root@server ~]# ldapmodify -D "cn=Directory Manager" -W -p 389 -h ipaserver.example.com -x
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: crypt
참고
암호 해시를 해독할 수 없으므로 Directory Server는 기존 암호 해시를 변환하지 않습니다. 서버는 새 암호 스토리지를 스토리지 구성표를 변경한 후에 설정된 암호에만 적용합니다.

V 부. 관리: 인증 관리

이 부분에서는 스마트 카드 인증을 설정하고 관리하는 방법에 대한 지침을 제공합니다. 또한 인증서 발행, 인증서 기반 인증 구성, Identity Management 의 인증서 유효성 제어와 같은 인증서 관련 주제를 다룹니다.

22장. 사용자 인증

이 장에서는 사용자의 암호, SSH 키, 인증서 또는 일회성 암호(OTP) 및 스마트 카드 인증을 구성하는 방법에 대한 정보를 포함하여 사용자 인증 메커니즘 관리에 대해 설명합니다.
참고
Kerberos를 사용하여 IdM(Identity Management)에 로그인하는 방법에 대한 설명서는 5장. IdM 서버 및 서비스 관리의 기본 사항 을 참조하십시오.

22.1. 사용자 암호

22.1.1. 사용자 암호 변경 및 재설정

다른 사용자의 암호를 변경할 수 있는 권한이 없는 일반 사용자는 자신의 개인 암호만 변경할 수 있습니다. 개인 암호는 다음과 같이 변경되었습니다.
  • IdM 암호 정책을 충족해야 합니다. 암호 정책 구성에 대한 자세한 내용은 28장. 암호 정책 정의 을 참조하십시오.
관리자와 암호 변경 권한이 있는 사용자는 새 사용자의 초기 암호를 설정하고 기존 사용자의 암호를 재설정할 수 있습니다. 암호가 다음과 같이 변경되었습니다.
참고
LDAP Directory Manager(DM) 사용자는 LDAP 도구를 사용하여 사용자 암호를 변경할 수 있습니다. 새 암호는 IdM 암호 정책을 재정의할 수 있습니다. DM에 의해 설정된 암호는 처음 로그인한 후에는 만료되지 않습니다.

22.1.1.1. 웹 UI: 자신의 개인 암호 변경

  1. 오른쪽 상단에서 User nameChange password 클릭합니다.

    그림 22.1. 암호 재설정

    암호 재설정
  2. 새 암호를 입력합니다.

22.1.1.2. 웹 UI: 다른 사용자의 암호 재설정

  1. IdentityUsers 를 선택합니다.
  2. 편집할 사용자 이름을 클릭합니다.
  3. ActionsReset password (암호 재설정)를 클릭합니다.

    그림 22.2. 암호 재설정

    암호 재설정
  4. 새 암호를 입력하고 암호 재설정 을 클릭합니다.

    그림 22.3. 새 암호 확인

    새 암호 확인

22.1.1.3. 명령줄: 다른 사용자의 암호 변경 또는 재설정

개인 암호를 변경하거나 다른 사용자의 암호를 변경하거나 재설정하려면 ipa user-mod 명령에 --password 옵션을 추가합니다. 이 명령은 새 암호를 입력하라는 메시지를 표시합니다.
$ ipa user-mod user --password
Password:
Enter Password again to verify:
--------------------
Modified user "user"
--------------------
...

22.1.2. 다음 로그인 시 암호 변경 메시지를 표시하지 않고 암호 재설정 활성화

기본적으로 관리자가 다른 사용자의 암호를 재설정하면 처음 로그인에 성공한 후에 암호가 만료됩니다. 자세한 내용은 22.1.1절. “사용자 암호 변경 및 재설정” 을 참조하십시오.
관리자가 설정한 암호가 처음 사용할 때 만료되지 않도록 하려면 도메인의 모든 ID 관리 서버에서 이러한 변경을 수행합니다.
  • 암호 동기화 항목 cn=ipa_pwd_extop,cn=plugins,cn=config 를 편집합니다.
  • passSyncManagersDNs 속성에서 관리 사용자 계정을 지정합니다. 특성은 다중값입니다.
예를 들어 ldapmodify 유틸리티를 사용하여 admin 사용자를 지정하려면 다음을 수행합니다.
$ ldapmodify -x -D "cn=Directory Manager" -W -h ldap.example.com -p 389

dn: cn=ipa_pwd_extop,cn=plugins,cn=config
changetype: modify
add: passSyncManagersDNs
passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=example,dc=com
주의
이러한 추가 권한이 필요한 사용자만 지정합니다. passSyncManagerDNs 아래에 나열된 모든 사용자는 다음을 수행할 수 있습니다.
  • 후속 암호 재설정 없이도 암호 변경 작업을 수행합니다.
  • 강도나 기록 적용이 적용되지 않도록 암호 정책을 무시합니다

22.1.3. 암호 실패 후 사용자 계정 잠금 해제

사용자가 잘못된 암호를 사용하여 특정 횟수를 사용하여 로그인하려고 하면 IdM에서 사용자 계정을 잠그므로 사용자가 로그인할 수 없습니다. IdM은 사용자 계정이 잠겨 있다는 경고 메시지를 표시하지 않습니다.
참고
허용되는 실패한 시도 수와 잠금 해제 기간을 설정하는 방법에 대한 자세한 내용은 28장. 암호 정책 정의 을 참조하십시오.
IdM은 지정된 시간이 경과하면 사용자 계정의 잠금을 자동으로 해제합니다. 또는 관리자가 사용자 계정의 잠금을 수동으로 해제할 수 있습니다.

수동으로 사용자 계정 잠금 해제

사용자 계정의 잠금을 해제하려면 ipa user-unlock 명령을 사용합니다.
$ ipa user-unlock user
-----------------------
Unlocked account "user"
-----------------------
그런 다음 사용자는 다시 로그인할 수 있습니다.

22.1.3.1. 사용자 계정 상태 확인

사용자에게 실패한 로그인 시도 횟수를 표시하려면 ipa user-status 명령을 사용합니다. 표시된 번호가 실패한 로그인 시도 횟수를 초과하면 사용자 계정이 잠깁니다.
$ ipa user-status user
-----------------------
Account disabled: False
-----------------------
  Server: example.com
  Failed logins: 8
  Last successful authentication: 20160229080309Z
  Last failed authentication: 20160229080317Z
  Time now: 2016-02-29T08:04:46Z
----------------------------
Number of entries returned 1
----------------------------
기본적으로 Red Hat Enterprise Linux 7.4 이상에서 시작 해제한 IdM은 사용자의 마지막 성공적인 Kerberos 인증의 타임스탬프를 저장하지 않습니다. 이 기능을 활성화하려면 22.2절. “마지막으로 성공한 Kerberos 인증 추적 활성화” 을 참조하십시오.

22.2. 마지막으로 성공한 Kerberos 인증 추적 활성화

성능상의 이유로 Red Hat Enterprise Linux 7.4 이상에서 실행되는 IdM은 사용자의 마지막 성공적인 Kerberos 인증의 타임스탬프를 저장하지 않습니다. 결과적으로 ipa user-status 와 같은 특정 명령이 타임 스탬프를 표시하지 않습니다.
사용자의 마지막으로 성공한 Kerberos 인증을 추적하려면 다음을 수행합니다.
  1. 현재 활성화된 암호 플러그인 기능을 표시합니다.
    # ipa config-show | grep "Password plugin features"
      Password plugin features: AllowNThash, KDC:Disable Last Success
    다음 단계에서ECDHE :Disable Last Success 를 제외한 기능의 이름이 필요합니다.
  2. 모든 기능에 대한 --ipaconfigstring=feature 매개변수를 현재 활성화되어 있는 ipa config-mod 명령에 전달합니다. 단, Last Success 는 제외합니다.
    # ipa config-mod --ipaconfigstring='AllowNThash'
    이 명령은 AllowNThash 플러그인만 활성화합니다. 여러 기능을 활성화하려면 --ipaconfigstring=feature 매개변수를 여러 번 지정합니다. 예를 들어 AllowNThash 및ECDHE :Disable Lockout 기능을 활성화하려면 다음을 수행합니다.
    # ipa config-mod --ipaconfigstring='AllowNThash' --ipaconfigstring='KDC:Disable Lockout'
  3. IdM을 다시 시작합니다.
    # ipactl restart

22.3. 1회용 암호

중요
OTP 인증에 대한 IdM 솔루션은 Red Hat Enterprise Linux 7.1 이상을 실행하는 클라이언트에만 지원됩니다.
일회성 암호(OTP)는 하나의 인증 세션에만 유효하며 사용 후 유효하지 않게 됩니다. 기존의 정적 암호와는 달리 인증 토큰에 의해 생성된 OTP는 계속 변경됩니다. OTP는 2 단계 인증의 일부로 사용됩니다.
  1. 사용자는 기존 암호를 사용하여 인증합니다.
  2. 사용자는 인식된 OTP 토큰으로 생성된 OTP 코드를 제공합니다.
이중 인증은 기존 암호만으로 인증하는 것보다 안전한 것으로 간주됩니다. 로그인 중에 잠재적인 침입자가 OTP를 가로채는 경우에도, 성공적으로 인증에만 사용할 수 있기 때문에 인터셉트된 OTP는 이미 유효하지 않습니다.
주의
다음 보안 및 기타 제한 사항은 현재 IdM의 OTP 지원과 관련이 있습니다.
  • 가장 중요한 보안 제한은 시스템에서 공격을 재개하는 잠재적 취약성입니다. 복제는 비동기식이므로 복제 기간에 OTP 코드를 재사용할 수 있습니다. 한 사용자가 동시에 두 개의 서버에 로그온할 수 있습니다. 그러나 이 취약점은 일반적으로 포괄적인 암호화로 인해 악용하기 어렵습니다.
  • OTP 인증을 지원하지 않는 클라이언트를 사용하여 TGT(권장 티켓)를 받을 수 없습니다. 이는 mod_auth_kerb 모듈 또는 GSSAPI(Generic Security Services API)를 사용한 인증과 같은 특정 사용 사례에 영향을 줄 수 있습니다.
  • FIPS 모드가 활성화된 경우 IdM 솔루션에서는 password + OTP를 사용할 수 없습니다.

22.3.1. IdM에서 OTP 인증이 작동하는 방식

22.3.1.1. IdM에서 지원되는 OTP 토큰

소프트웨어 및 하드웨어 토큰

IdM은 소프트웨어 및 하드웨어 토큰을 모두 지원합니다.

사용자 관리 및 관리자 관리 토큰

사용자는 자체 토큰을 관리하거나 관리자가 토큰을 관리할 수 있습니다.
사용자 관리 토큰
사용자는 Identity Management에서 사용자 관리 토큰을 완전히 제어할 수 있습니다. 토큰을 생성, 편집 또는 삭제할 수 있습니다.
관리자 관리 토큰
관리자는 관리자 관리 토큰을 사용자 계정에 추가합니다. 사용자는 이러한 토큰에 대한 읽기 전용 액세스 권한이 있습니다. 토큰을 관리하거나 수정할 수 있는 권한이 없으며 어떠한 방식으로든 구성할 필요가 없습니다.
현재 유일한 활성 토큰인 경우 사용자는 토큰을 삭제하거나 비활성화할 수 없습니다. 관리자는 마지막 활성 토큰을 삭제하거나 비활성화할 수 없지만 다른 사용자의 마지막 활성 토큰을 삭제하거나 비활성화할 수 있습니다.

지원되는 OTP 알고리즘

Identity Management는 다음과 같은 두 가지 표준 OTP 메커니즘을 지원합니다.
  • 대상 HOTP(one-Based One-Time Password) 알고리즘은 카운터를 기반으로 합니다. Hashed Message Authentication Code의 약어입니다.
  • TOTP(Time-Based One-Time Password) 알고리즘은 시간 기반 이동 요소를 지원하기 위한 HOTP의 확장입니다.

22.3.1.2. 사용 가능한 OTP 인증 방법

OTP 인증을 활성화하는 경우 다음 인증 방법 중에서 선택할 수 있습니다.
이중 인증 (암호 + OTP)
이 방법을 사용하면 사용자는 항상 표준 암호와 OTP 코드를 입력해야 합니다.
암호
이 방법을 사용하면 사용자에게 표준 암호만 사용하여 인증할 수 있는 옵션이 있습니다.
RADIUS 프록시 서버 인증
OTP 검증을 위한 RADIUS 서버 구성에 대한 자세한 내용은 22.3.7절. “독점형 OTP 솔루션에서 마이그레이션” 을 참조하십시오.

글로벌 및 사용자별 인증 방법

전역 또는 개별 사용자에 대해 이러한 인증 방법을 구성할 수 있습니다.
  • 기본적으로 사용자별 인증 방법 설정은 전역 설정보다 우선합니다. 사용자에 대해 인증 방법을 설정하지 않으면 전역적으로 정의된 메서드가 적용됩니다.
  • 사용자의 사용자별 인증 방법 설정을 비활성화할 수 있습니다. 이렇게 하면 IdM에서 사용자별 설정을 무시하고 항상 사용자의 전역 설정을 적용합니다.

다중 인증 방법 결합

한 번에 여러 개의 메서드를 설정하면 둘 중 하나로 인증에 충분합니다. 예를 들어 다음과 같습니다.
  • 이중 인증과 암호 인증을 모두 구성하는 경우 사용자는 암호(first factor)를 제공해야 하지만, 명령줄을 사용할 때 OTP(second factor)를 제공하는 것은 선택 사항입니다.
    First Factor:
    Second Factor (optional):
  • 웹 UI에서 사용자는 두 요소를 모두 제공해야 합니다.
참고
개별 호스트 또는 서비스는 특정 인증 방법(예: OTP)을 요구하도록 구성할 수 있습니다. 첫 번째 요소만 사용하여 이러한 호스트 또는 서비스에 대한 인증을 시도하는 경우 액세스가 거부됩니다. 22.4절. “사용자 인증 방법에 따라 서비스 및 호스트에 대한 액세스 제한” 참조하십시오.
그러나 RADIUS 및 다른 인증 방법이 구성된 경우 마이너 예외가 존재합니다.
  • Kerberos는 항상 RADIUS를 사용하지만 LDAP는 그렇지 않습니다. LDAP는 암호와 이중 인증 방법만 인식합니다.
  • 외부 이중 인증 공급자를 사용하는 경우 애플리케이션에서 Kerberos를 사용합니다. 사용자가 암호로만 인증할 수 있도록 하려면 LDAP를 사용합니다. 애플리케이션이 Kerberos 또는 LDAP를 구성할 수 있는 Apache 모듈과 SSSD를 활용하는 것이 좋습니다.

22.3.1.3. GNOME 키링 서비스 지원

IdM은 OTP 인증을 GNOME Keyring 서비스와 통합합니다. GNOME 키링 통합에는 사용자가 첫 번째 및 두 번째 요소를 별도로 입력해야 합니다.
First factor: static_password
Second factor: one-time_password

22.3.1.4. OTP를 통한 오프라인 인증

IdM은 오프라인 OTP 인증을 지원합니다. 그러나 오프라인으로 로그인할 수 있으려면 사용자가 정적 암호와 OTP를 별도로 입력하여 시스템이 온라인 상태일 때 먼저 인증해야 합니다.
First factor: static_password
Second factor: one-time_password
온라인으로 로그인할 때와 같이 두 암호를 별도로 입력하면 중앙 인증 서버를 사용할 수 없는 경우에도 사용자가 인증할 수 있습니다. IdM은 사용자가 오프라인에서 인증할 때 첫 번째 단계의 기존 정적 암호만 표시합니다.
또한 IdM은 첫 번째 인수 프롬프트에서 하나의 문자열에 정적 암호와 OTP를 함께 입력할 수 있도록 지원합니다. 그러나 이는 오프라인 OTP 인증과 호환되지 않습니다. 사용자가 단일 프롬프트에 두 요소를 모두 입력하면 시스템이 온라인 상태가 되어야 하는 인증 시 IdM은 항상 중앙 인증 서버에 연결해야 합니다.
중요
노트북과 같이 오프라인으로 작동하는 장치에서 OTP 인증을 사용하는 경우, 오프라인 인증을 사용할 수 있도록 Red Hat은 정적 암호와 OTP를 별도로 입력하는 것이 좋습니다. 그렇지 않으면 시스템이 오프라인된 후 IdM에서 로그인할 수 없습니다.
OTP 오프라인 인증의 혜택을 받으려면 정적 및 OTP 암호를 별도로 입력하는 것 외에도 다음 조건을 충족해야 합니다.
  • /etc/sssd/sssd.conf 파일의 cache_credentials 옵션이 True 로 설정되어 첫 번째 인수 암호를 캐싱할 수 있습니다.
  • 첫 번째 단계의 정적 암호는 /etc/sssd/sssd.conf 에 설정된 cache_credentials_minimal_first_factor_length 옵션에 정의된 암호 길이 요구 사항을 충족합니다. 기본 최소 길이는 8자입니다. 옵션에 대한 자세한 내용은 sssd.conf(5) 도움말 페이지를 참조하십시오.
/etc/sssd/sssd.conf 에서 iPXE 5_store_password_if_offline 옵션이 true 로 설정되어 있더라도, OTP가 이미 유효하지 않을 수 있기 때문에 SSSD는 Kerberos 티켓-granting 티켓(TGT)을 새로 고치지 않습니다. 이 상황에서 TGT를 얻으려면 사용자는 두 요소를 모두 사용하여 다시 인증해야 합니다.

22.3.2. FIPS 모드에서 실행되는 IdM 서버에서 RADIUS 프록시를 구성하는 데 필요한 설정

FIPS(Federal Information Processing Standard) 모드에서 OpenSSL은 기본적으로 MD5 다이제스트 알고리즘 사용을 비활성화합니다. 결과적으로 RADIUS 프로토콜에는 RADIUS 클라이언트와 RADIUS 서버 간의 비밀을 암호화하기 위해 MD5가 필요하므로 FIPS 모드에서 MD5를 사용할 수 없으므로 IdM RADIUS 프록시 서버가 실패합니다.
RADIUS 서버가 IdM 마스터와 동일한 호스트에서 실행 중인 경우 다음 단계를 수행하여 문제를 해결하고 보안 경계 내에서 MD5를 활성화할 수 있습니다.
  1. 다음 콘텐츠를 사용하여 /etc/systemd/system/radiusd.service.d/ipa-otp.conf 파일을 만듭니다.
    [Service] 
    Environment=OPENSSL_FIPS_NON_APPROVED_MD5_ALLOW=1
  2. systemd 구성을 다시 로드합니다.
    # systemctl daemon-reload
  3. radio usd 서비스를 시작합니다.
    # systemctl start radiusd

22.3.3. Two Factor Authentication 활성화

OTP와 관련된 사용 가능한 인증 방법에 대한 자세한 내용은 22.3.1.2절. “사용 가능한 OTP 인증 방법” 을 참조하십시오.
다음을 사용하여 두 개의 요소 인증을 활성화하려면 다음을 수행합니다.

웹 UI: Two Factor Authentication 활성화

모든 사용자에 대해 인증 방법을 전역적으로 설정하려면 다음을 수행합니다.
  1. IPA 서버 구성을선택합니다.
  2. 사용자 옵션 영역에서 필요한 기본 사용자 인증 유형을 선택합니다.

    그림 22.4. 사용자 인증 방법

    사용자 인증 방법
사용자별 설정으로 글로벌 설정이 재정의되지 않도록 하려면 Disable per-user override 를 선택합니다. 사용자별 재정의 비활성화를 선택하지 않으면 사용자 별로 구성된 인증 메서드가 전역 설정보다 우선합니다.
사용자별로 인증 방법을 개별적으로 설정하려면 다음을 수행합니다.
  1. IdentityUsers 를 선택하고 편집할 사용자 이름을 클릭합니다.
  2. 계정 설정 영역에서 필요한 사용자 인증 유형을 선택합니다.

    그림 22.5. 사용자 인증 방법

    사용자 인증 방법

명령줄: Two Factor Authentication 활성화

모든 사용자에 대해 인증 방법을 전역적으로 설정하려면 다음을 수행합니다.
  1. ipa config-mod --user-auth-type 명령을 실행합니다. 예를 들어 글로벌 인증 방법을 이중 인증으로 설정하려면 다음을 수행합니다.
    $ ipa config-mod --user-auth-type=otp
    --user-auth-type 에서 허용하는 값 목록을 보려면 ipa config-mod --help 명령을 실행합니다.
  2. 사용자별 재정의를 비활성화하려면 글로벌 설정이 사용자별 설정으로 재정의되지 않도록 하려면 --user-auth-type=disabled 옵션도 추가합니다. 예를 들어 글로벌 인증 방법을 이중 인증으로 설정하고 사용자별 재정의를 비활성화하려면 다음을 수행합니다.
    $ ipa config-mod --user-auth-type=otp --user-auth-type=disabled
    --user-auth-type=disabled 를 설정하지 않으면 사용자별로 구성된 인증 방법이 글로벌 설정보다 우선합니다.
지정된 사용자에 대해 인증 방법을 개별적으로 설정하려면 다음을 수행합니다.
  • ipa user-mod --user-auth-type 명령을 실행합니다. 예를 들어, 2 단계 인증을 사용하려면 해당 사용자를 설정해야 합니다.
    $ ipa user-mod user --user-auth-type=otp
여러 인증 방법을 설정하려면 --user-auth-type 을 여러 번 추가합니다. 예를 들어 모든 사용자에 대해 암호 및 이중 인증을 전역적으로 구성하려면 다음을 수행합니다.
$ ipa config-mod --user-auth-type=otp --user-auth-type=password

22.3.4. 사용자 관리 소프트웨어 토큰 추가

  1. 표준 암호로 로그인합니다.
  2. FreeOTP Authenticator 애플리케이션이 모바일 장치에 설치되어 있는지 확인합니다. FreeOTP Authenticator 를 다운로드하려면 FreeOTP 소스 페이지를 참조하십시오.
  3. IdM 웹 UI 또는 명령줄에서 소프트웨어 토큰을 생성합니다.
    • 웹 UI에 토큰을 생성하려면 OTP 토큰 탭에서 Add 를 클릭합니다. 관리자로 로그인한 경우 인증 탭을 통해 OTP 토큰 탭에 액세스할 수 있습니다.

      그림 22.6. 사용자의 OTP 토큰 추가

      사용자의 OTP 토큰 추가
    • 명령줄에서 토큰을 생성하려면 ipa otptoken-add 명령을 실행합니다.
      $ ipa otptoken-add
      ------------------
      Added OTP token ""
      ------------------
        Unique ID: 7060091b-4e40-47fd-8354-cb32fecd548a
        Type: TOTP
      ...
      
      ipa otptoken-add 에 대한 자세한 내용은 --help 옵션이 추가된 명령을 실행합니다.
  4. website 코드는 웹 UI 또는 명령줄에 표시됩니다. FreeOTP Authenticator 로 QR 코드를 스캔하여 모바일 장치에 토큰을 프로비저닝합니다.

22.3.5. 사용자 관리 YubiKey 하드웨어 토큰 추가

YubiKey 토큰과 같은 프로그래밍 가능한 하드웨어 토큰은 명령줄에서만 추가할 수 있습니다. YubiKey 하드웨어 토큰을 토큰을 소유하는 사용자로 추가하려면 다음을 수행합니다.
  1. 표준 암호로 로그인합니다.
  2. YubiKey 토큰을 삽입합니다.
  3. ipa otptoken-add-yubikey 명령을 실행합니다.
    • YubiKey에 사용 가능한 빈 슬롯이 있으면 명령에서 빈 슬롯을 자동으로 선택합니다.
    • 빈 슬롯을 사용할 수 없는 경우 --slot 옵션을 사용하여 슬롯을 수동으로 선택해야 합니다. 예를 들면 다음과 같습니다.
      $ ipa otptoken-add-yubikey --slot=2
      이렇게 하면 선택한 슬롯을 덮어씁니다.

22.3.6. 관리자로 사용자의 토큰 추가

관리자로 소프트웨어 토큰을 추가하려면 다음을 수행합니다.
  1. 관리자로 로그인했는지 확인합니다.
  2. FreeOTP Authenticator 애플리케이션이 모바일 장치에 설치되어 있는지 확인합니다. FreeOTP Authenticator 를 다운로드하려면 FreeOTP 소스 페이지를 참조하십시오.
  3. IdM 웹 UI 또는 명령줄에서 소프트웨어 토큰을 생성합니다.
    • 웹 UI에 토큰을 생성하려면 인증OTP 토큰 을 선택하고 OTP 토큰 목록 상단에 있는 추가 를 클릭합니다. OTP 토큰 추가 양식에서 토큰 의 소유자를 선택합니다.

      그림 22.7. 관리자 관리 소프트웨어 토큰 추가

      관리자 관리 소프트웨어 토큰 추가
    • 명령줄에서 토큰을 생성하려면 --owner 옵션으로 ipa otptoken-add 명령을 실행합니다. 예를 들어 다음과 같습니다.
      $ ipa otptoken-add --owner=user
      ------------------
      Added OTP token ""
      ------------------
        Unique ID: 5303baa8-08f9-464e-a74d-3b38de1c041d
        Type: TOTP
      ...
      
  4. website 코드는 웹 UI 또는 명령줄에 표시됩니다. FreeOTP Authenticator 로 QR 코드를 스캔하여 모바일 장치에 토큰을 프로비저닝합니다.
관리자로서 YubiKey 토큰과 같이 프로그래밍 가능한 하드웨어 토큰을 추가하려면 다음을 수행합니다.
  1. 관리자로 로그인했는지 확인합니다.
  2. YubiKey 토큰을 삽입합니다.
  3. --owner 옵션을 사용하여 ipa otptoken-add-yubikey 명령을 실행합니다. 예를 들어 다음과 같습니다.
    $ ipa otptoken-add-yubikey --owner=user

22.3.7. 독점형 OTP 솔루션에서 마이그레이션

전용 OTP 솔루션에서 IdM 네이티브 OTP 솔루션으로 대규모 배포를 마이그레이션할 수 있도록 IdM은 OTP 검증을 사용자의 하위 집합에 대한 타사 RADIUS 서버로 오프로드할 수 있는 방법을 제공합니다. 관리자는 각 프록시가 단일 RADIUS 서버만 참조할 수 있는 RADIUS 프록시 세트를 생성합니다. 둘 이상의 서버를 처리해야 하는 경우 여러 RADIUS 서버를 가리키는 가상 IP 솔루션을 생성하는 것이 좋습니다. 이러한 솔루션은 keepalived 데몬을 사용하여 RHEL IdM 외부에서 빌드해야 합니다. 그런 다음 관리자는 이러한 프록시 세트 중 하나를 사용자에게 할당합니다. 사용자에게 RADIUS 프록시 세트가 할당된 한 IdM은 다른 모든 인증 메커니즘을 무시합니다.
참고
IdM은 타사 시스템에서 토큰 관리 또는 동기화를 지원하지 않습니다.
OTP 검증을 위해 RADIUS 서버를 구성하고 프록시 서버에 사용자를 추가하려면 다음을 수행합니다.
  1. radious 사용자 인증 방법이 활성화되어 있는지 확인합니다. 자세한 내용은 22.3.3절. “Two Factor Authentication 활성화” 을 참조하십시오.
  2. ipabl usproxy-add proxy_name --secret secret 명령을 실행하여 RADIUS 프록시를 추가합니다. 명령을 실행하면 필요한 정보를 삽입하라는 메시지가 표시됩니다.
    RADIUS 프록시를 구성하려면 클라이언트와 서버 간의 공통 시크릿을 사용하여 자격 증명을 종료해야 합니다. --secret 매개변수에 이 보안을 지정합니다.
  3. ipa user-modradususer --radius=proxy_name 명령을 실행하여 사용자를 추가된 프록시에 할당합니다.
  4. 필요한 경우 ipa user-mod rerunususer --radius-username=ubius_user 명령을 실행하여 사용자 이름을 RADIUS로 전송합니다.
결과적으로 사용자 OTP 인증은 RADIUS 프록시 서버를 통해 처리되기 시작합니다.
참고
FIPS 모드가 활성화된 IdM 마스터에서 RADIUS 서버를 실행하려면 22.3.2절. “FIPS 모드에서 실행되는 IdM 서버에서 RADIUS 프록시를 구성하는 데 필요한 설정” 에 설명된 단계를 수행하십시오.
사용자가 IdM 기본 OTP 시스템으로 마이그레이션할 준비가 되면 사용자의 RADIUS 프록시 할당을 간단히 제거할 수 있습니다.

22.3.7.1. 더 낮은 네트워크에서 RADIUS 서버를 실행할 때 KDC의 시간 제한 값 변경

느린 네트워크에서 RADIUS 프록시를 실행하는 것과 같은 특정 상황에서는 IdM이 RADIUS 서버가 응답하기 전에 연결을 닫습니다. 사용자가 토큰 입력을 기다리는 동안 시간이 초과되어 있기 때문입니다.
KDC의 시간 제한 설정을 변경하려면 다음을 수행합니다.
  1. /var/kerberos/krb5kdc/kdc.conf 파일의 [otp] 섹션에서 timeout 매개변수 값을 변경합니다. 예를 들어 시간 제한을 120 초로 설정하려면 다음을 수행합니다.
    [otp]
    DEFAULT = {
      timeout = 120
      ...
    }
  2. ScanSetting 5kdc 서비스를 다시 시작합니다.
    # systemctl restart krb5kdc

22.3.8. 현재 인증 정보를 Two-Factor Authentication으로 승격

암호와 이중 인증이 모두 구성되어 있지만 암호를 사용하여 인증받은 경우 특정 서비스 또는 호스트에 대한 액세스가 거부될 수 있습니다( 22.4절. “사용자 인증 방법에 따라 서비스 및 호스트에 대한 액세스 제한”참조). 이 경우 인증을 다시 인증하여 자격 증명을 1 단계 인증에서 2 단계 인증으로 승격합니다.
  1. 화면을 잠급니다. 화면을 잠그는 기본 키보드 바로 가기는 Super 키+L 입니다.
  2. 화면 잠금 해제. 자격 증명을 요청하는 경우 암호와 OTP를 둘 다 사용합니다.

22.3.9. OTP 토큰 재동기화

22.3.10. 손실된 OTP 토큰 교체

다음 절차에서는 OTP 토큰을 분실한 사용자가 토큰을 교체하는 방법을 설명합니다.
  1. 관리자로 사용자에 대해 암호 및 OTP 인증을 활성화합니다.
    [admin@server]# ipa user-mod --user-auth-type=password --user-auth-type=otp user_name
  2. 이제 사용자가 새 토큰을 추가할 수 있습니다. 예를 들어 설명에 새 토큰이 설정된 새 토큰 을 추가하려면 다음을 수행합니다.
    [user@server]# ipa otptoken-add --desc="New Token"
    자세한 내용은 ipa otptoken-add --help 매개변수 추가 명령을 입력합니다.
  3. 사용자는 이제 이전 토큰을 삭제할 수 있습니다.
    1. 선택적으로 계정과 연결된 토큰을 나열합니다.
      [user@server]# ipa otptoken-find
      --------------------
      2 OTP tokens matched
      --------------------
        Unique ID: 4ce8ec29-0bf7-4100-ab6d-5d26697f0d8f
        Type: TOTP
        Description: New Token
        Owner: user
      
        Unique ID: e1e9e1ef-172c-4fa9-b637-6b017ce79315
        Type: TOTP
        Description: Old Token
        Owner: user
      ----------------------------
      Number of entries returned 2
      ----------------------------
    2. 이전 토큰을 삭제합니다. 예를 들어, e1e9e1ef-172c-4fa9-b637-6b017ce79315 ID를 사용하여 토큰을 삭제하려면 다음을 수행합니다.
      [user@server]# # ipa otptoken-del e1e9e1ef-172c-4fa9-b637-6b017ce79315
      --------------------------------------------------------
      Deleted OTP token "e1e9e1ef-172c-4fa9-b637-6b017ce79315"
      --------------------------------------------------------
  4. 관리자는 사용자에 대해 OTP 인증만 활성화합니다.
    [admin@server]# ipa user-mod --user-auth-type=otp user_name

22.4. 사용자 인증 방법에 따라 서비스 및 호스트에 대한 액세스 제한

IdM에서 지원하는 인증 메커니즘은 인증 강도에 따라 다릅니다. 예를 들어 표준 암호와 함께 일회용 암호(OTP)를 사용한 인증은 표준 암호만 사용하는 인증보다 안전한 것으로 간주됩니다. 이 섹션에서는 사용자 인증 방법에 따라 서비스 및 호스트에 대한 액세스를 제한하는 방법을 보여줍니다.
예를 들어 다음을 구성할 수 있습니다.
  • 강력한 인증 방법 필요 시 VPN과 같은 보안에 중요한 서비스
  • 로컬 로그인과 같은 중요하지 않은 서비스는 더 약하지만 더 편리한 인증 방법을 사용하여 인증을 허용합니다.

그림 22.8. 다른 메서드 사용 인증 예

다른 메서드 사용 인증 예

인증 지표

서비스 및 호스트에 대한 액세스는 인증 지표에 의해 정의됩니다.
  • 서비스 또는 호스트 항목에 포함된 표시기는 사용자가 해당 서비스 또는 호스트에 액세스하는 데 사용할 수 있는 인증 방법을 정의합니다.
  • 사용자의 TGT( 티켓 부여 티켓)에 포함된 표시기는 티켓을 받는 데 사용된 인증 방법을 보여줍니다.
주체의 표시기가 TGT의 표시기와 일치하지 않으면 사용자는 액세스가 거부됩니다.

22.4.1. 특정 인증 방법 필요 시 호스트 또는 서비스 구성

다음을 사용하여 호스트 또는 서비스를 구성하려면 다음을 수행합니다.

웹 UI: 특정 인증 방법 필요 시 호스트 또는 서비스 구성

  1. IdentityHosts 또는 IdentityServices 를 선택합니다.
  2. 필요한 호스트 또는 서비스의 이름을 클릭합니다.
  3. 인증 표시기 에서 필요한 인증 방법을 선택합니다.
    • 예를 들어 OTP 를 선택하면 암호로 유효한 OTP 코드를 사용한 사용자만 호스트 또는 서비스에 액세스할 수 있습니다.
    • OTPRADIUS 를 모두 선택하는 경우 OTP 또는 RADIUS 중 하나를 선택하여 액세스를 허용할 수 있습니다.
  4. 페이지 상단에서 저장 을 클릭합니다.

명령줄: 특정 인증 방법 필요 시 호스트 또는 서비스 구성

  1. 선택 사항입니다. ipa host-find 또는 ipa service-find 명령을 사용하여 호스트 또는 서비스를 식별합니다.
  2. 필요한 인증 표시기를 추가하려면 ipa host-mod 또는 ipa service-mod 명령을 --auth-ind 옵션과 함께 사용합니다. --auth-ind 에서 허용하는 값 목록은 ipa host-mod --help 또는 ipa service-mod --help 명령의 출력을 참조하십시오.
    예를 들어, --auth-ind=otp 를 사용하면 유효한 OTP 코드를 사용하는 사용자만 호스트 또는 서비스에 액세스할 수 있습니다.
    $ ipa host-mod server.example.com --auth-ind=otp
    ---------------------------------------------------------
    Modified host "server.example.com"
    ---------------------------------------------------------
      Host name: server.example.com
      ...
      Authentication Indicators: otp
      ...
    OTP 및 RADIUS 둘 다에 대한 지표를 추가하는 경우 OTP 또는 RADIUS를 모두 허용하기에 충분합니다.

22.4.2. Kerberos 인증 ID 변경

기본적으로 IdM(Identity Management)은 PKINIT 사전 인증 플러그인을 사용하여 Kerberos 인증의 인증서 매핑에 pkinit 표시기를 사용합니다. KDC(Kerberos Distribution Center)에서 TGT( ticket-granting ticket)에 삽입한 인증 공급자를 변경해야 하는 경우 PKINIT 기능을 제공하는 모든 IdM 마스터에서 구성을 수정합니다.
  1. /var/kerberos/krb5kdc/kdc.conf 파일에서 pkinit_ ECDHE 매개변수를 [kdcdefaults] 섹션에 추가합니다.
    # pkinit_indicator = indicator
    다음 값을 표시기를 설정할 수 있습니다.
    • 두 가지 요인 인증의 경우 OTP
    • RADIUS 기반 인증
    • 스마트 카드 인증을 위한 PKINIT
  2. ScanSetting 5kdc 서비스를 다시 시작합니다.
    # systemctl restart krb5kdc

22.5. 사용자를 위한 SSH 공개 키 관리

ID 관리를 사용하면 공용 SSH 키를 사용자 항목에 업로드할 수 있습니다. 해당 개인 SSH 키에 액세스할 수 있는 사용자는 ssh 를 사용하여 Kerberos 자격 증명을 사용하지 않고 IdM 시스템에 로그인할 수 있습니다. gRPC _krb5 가 올바르게 구성되거나 SSSD가 IdM 서버의 ID 공급자로 사용되는 경우 사용자는 로그인 후 Kerberos 티켓 부여 티켓(TGT)도 수신합니다. 자세한 내용은 “자동으로 Kerberos 티켓 얻기” 을 참조하십시오.
개인 SSH 키 파일을 사용할 수 없는 시스템에서 로그인하는 경우 Kerberos 자격 증명을 제공하여 사용자를 인증할 수 있습니다.

자동으로 SSH 키 캐싱 및 복구

IdM 서버 또는 클라이언트 설치 중에 사용자 및 호스트 SSH 키를 캐시하고 검색하도록 시스템에 SSSD가 자동으로 구성됩니다. 이를 통해 IdM은 SSH 키의 범용 중앙 집중식 리포지토리 역할을 할 수 있습니다.
설치 중에 서버 또는 클라이언트가 구성되지 않은 경우 시스템에서 수동으로 SSSD를 구성할 수 있습니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 22.6절. “OpenSSH 서비스에 캐시를 제공하도록 SSSD 구성” 을 참조하십시오. SSSD를 통해 SSH 키를 캐싱하려면 로컬 시스템에 대한 관리 권한이 필요합니다.

SSH 키 형식 요구 사항

IdM은 다음 두 가지 SSH 키 형식을 허용합니다.
OpenSSH 스타일 키
이 형식에 대한 자세한 내용은 RFC 4716 에서 참조하십시오.
Raw RFC 4253 스타일 키
이 형식에 대한 자세한 내용은 RFC 4253 에서 참조하십시오.
IdM은 IdM LDAP 서버에 저장하기 전에 RFC 4253 스타일 키를 OpenSSH 스타일 키로 자동 변환합니다.
id_rsa.pub 와 같은 키 파일은 키 유형, 키 자체, 추가 주석 또는 식별자의 세 부분으로 구성됩니다. 다음 예에서 키 유형은 RSA이고 주석은 해당 키를 client.example.com 호스트 이름과 연결합니다.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDMM4xPu54Kf2dx7C4Ta2F7vnIzuL1i6P21TTKniSkjFuA+r
qW06588e7v14Im4VejwnNk352gp49A62qSVOzp8IKA9xdtyRmHYCTUvmkcyspZvFRI713zfRKQVFyJOqHmW/m
dCmak7QBxYou2ELSPhH3pe8MYTQIulKDSu5Zbsrqedg1VGkSJxf7mDnCSPNWWzAY9AFB9Lmd2m2xZmNgVAQEQ
nZXNMaIlroLD/51rmMSkJGHGb1O68kEq9Z client.example.com
IdM에 키를 업로드할 때 세 가지 주요 부분 또는 키 자체만 업로드할 수 있습니다. 키 자체만 업로드하면 IdM은 업로드된 키 키에서 RSA 또는 DSA와 같은 키 유형을 자동으로 식별합니다.

22.5.1. SSH 키 생성

OpenSSH ssh-keygen 유틸리티를 사용하여 SSH 키를 생성할 수 있습니다. 유틸리티는 공개 키의 위치에 대한 정보를 표시합니다. 예를 들어 다음과 같습니다.
$ ssh-keygen -t rsa -C user@example.com
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:GAUIDVVEgly7rs1lTWP6oguHz8BKvyZkpqCqVSsmi7c user@example.com
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|     + .         |
|    + =   .      |
|     =   +       |
|    . E S..      |
|   .    . .o     |
|    . .  . oo.   |
|   . o .  +.+o   |
|    o  .o..o+o   |
+-----------------+
사용자의 SSH 키를 업로드하려면 표시된 파일에 저장된 공개 키 문자열을 사용합니다.

22.5.2. 사용자 SSH 키 업로드

22.5.2.1. 웹 UI: 사용자 SSH 키 업로드

  1. IdentityUsers 를 선택합니다.
  2. 편집할 사용자 이름을 클릭합니다.
  3. 계정 설정 영역의 설정 탭에서 SSH 공개 키를 클릭합니다. 추가.

    그림 22.9. 계정 설정의 SSH 공개 키

    계정 설정의 SSH 공개 키
  4. Base 64로 인코딩된 공개 키 문자열에 붙여넣고 설정을 클릭합니다.

    그림 22.10. 공개 키에 붙여넣기

    공개 키에 붙여넣기
  5. 페이지 상단에서 저장 을 클릭합니다.

22.5.2.2. 명령줄: 사용자 SSH 키 업로드

ipa user-mod 명령을 사용하고 --sshpubkey 옵션을 사용하여 Base 64 인코딩 공개 키 문자열을 전달합니다.
예를 들어 키 유형, 키 자체 및 호스트 이름 식별자를 업로드하려면 다음을 수행합니다.
$ ipa user-mod user --sshpubkey="ssh-rsa AAAAB3Nza...SNc5dv== client.example.com"
여러 개의 키를 업로드하려면 --sshpubkey 를 여러 번 사용합니다. 예를 들어 두 개의 SSH 키를 업로드하려면 다음을 수행합니다.
--sshpubkey="AAAAB3Nza...SNc5dv==" --sshpubkey="RjlzYQo...ZEt0TAo="
참고
키 문자열을 명령줄에 수동으로 붙여넣는 대신 명령 리디렉션을 사용하여 키가 포함된 파일을 가리킬 수 있습니다. 예를 들어 다음과 같습니다.
$ ipa user-mod user --sshpubkey="$(cat ~/.ssh/id_rsa.pub)" --sshpubkey="$(cat ~/.ssh/id_rsa2.pub)"

22.5.3. 사용자 키 삭제

SSH 키를 삭제하려면 다음을 수행합니다.

22.5.3.1. 웹 UI: 사용자 SSH 키 삭제

  1. IdentityUsers 를 선택합니다.
  2. 편집할 사용자 이름을 클릭합니다.
  3. 계정 설정 영역의 설정 탭에서 제거할 키 옆에 있는 삭제 를 클릭합니다.

    그림 22.11. 사용자 SSH 공개 키 삭제

    사용자 SSH 공개 키 삭제
  4. 페이지 상단에서 저장 을 클릭합니다.

22.5.3.2. 명령줄: 사용자 SSH 키 삭제

사용자 계정에 할당된 모든 SSH 키를 삭제하려면 키를 지정하지 않고 ipa user-mod 명령에 --sshpubkey 옵션을 추가합니다.
$ ipa user-mod user --sshpubkey=
특정 SSH 키 또는 키만 삭제하려면 --sshpubkey 옵션을 사용하여 보관할 키 또는 키를 지정합니다.
참고
이 명령은 캐시에서 SSH 키를 즉시 삭제하지 않습니다. 기본 캐시 시간 초과 값(entry_cache_timeout = 5400)을 사용하면 키가 1시간 반 동안 캐시에 남아 있습니다.

22.6. OpenSSH 서비스에 캐시를 제공하도록 SSSD 구성

SSSD(System Security Services Daemon)는 OpenSSH를 포함한 여러 시스템 서비스에 대한 인터페이스를 제공합니다.
이 섹션에서는 시스템과 사용자의 SSH 키를 캐시하도록 SSSD를 구성하는 방법에 대해 설명합니다.

22.6.1. OpenSSH를 사용한 SSSD의 작동 방식

OpenSSH는 SSH 프로토콜 구현입니다. OpenSSH는 인증 엔터티를 식별하는 공개-개인 키 쌍을 기반으로 두 시스템 간에 안전하고 암호화된 연결을 만듭니다. 자세한 내용은 System Administrator Guide의 OpenSSH 를 참조하십시오.
SSSD는 시스템과 사용자의 SSH 공개 키에 대한 자격 증명 캐시 역할을 할 수 있습니다. 이 설정에서 다음을 수행합니다.
  1. OpenSSH는 캐시된 키를 확인하기 위해 SSSD를 참조하도록 구성되었습니다.
  2. SSSD는 IdM(Identity Management) 도메인을 사용하며 IdM은 공개 키와 호스트 정보를 저장합니다.
참고
IdM 도메인의 Linux 시스템만 OpenSSH의 키 캐시로 SSSD를 사용할 수 있습니다. Windows 시스템을 포함한 다른 머신은 할 수 없습니다.

SSSD에서 호스트 키를 관리하는 방법

호스트 키를 관리하기 위해 SSSD는 다음을 수행합니다.
  1. 호스트 시스템에서 공개 호스트 키를 검색합니다.
  2. 호스트 키를 /var/lib/sss/pubconf/known_hosts 파일에 저장합니다.
  3. 호스트 시스템과의 연결을 설정합니다.
필요한 설정 단계에 대한 자세한 내용은 22.6.2절. “호스트 키에 SSSD를 사용하도록 OpenSSH 구성” 을 참조하십시오.

SSSD에서 사용자 키를 관리하는 방법

사용자 키를 관리하기 위해 SSSD는 다음을 수행합니다.
  1. IdM 도메인의 사용자 항목에서 사용자의 공개 키를 검색합니다.
  2. 사용자 키를 표준 인증 키 형식의 .ssh/sss_authorized_keys 파일에 저장합니다.
필요한 설정 단계에 대한 자세한 내용은 22.6.3절. “사용자 키에 SSSD를 사용하도록 OpenSSH 구성” 을 참조하십시오.

22.6.2. 호스트 키에 SSSD를 사용하도록 OpenSSH 구성

사용자별 또는 전체 시스템에 대해 구성을 변경할 수 있습니다.
  1. 필요한 구성 파일을 엽니다.
    1. 사용자별 구성을 변경하려면 ~/.ssh/config 파일을 엽니다.
    2. 시스템 전체 구성을 변경하려면 /etc/ssh/sshd_config 파일을 엽니다.
  2. ProxyCommand 옵션을 사용하여 SSH 클라이언트에 연결하는 데 사용할 명령을 지정합니다(필수 인수 및 호스트 이름으로 sss_ssh_knownhostsproxy 유틸리티).
    sss_ssh_knownhostsproxy 에 대한 자세한 내용은 sss_ssh_knownhostsproxy(1) 매뉴얼 페이지를 참조하십시오.
  3. GlobalKnownHostsFile 옵션을 사용하여 SSSD 호스트 파일 /var/lib/sss/pubconf/known_hosts 의 위치를 지정합니다. 이 파일은 기본 OpenSSH known_hosts 파일 대신 사용됩니다.
다음 예제에서는 SSSD 도메인에서 공개 키를 찾고 제공된 포트와 호스트를 통해 연결하도록 SSH를 구성합니다.
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
SSH 구성 및 구성 파일에 대한 자세한 내용은 ssh_config(5) 도움말 페이지를 참조하십시오.

22.6.3. 사용자 키에 SSSD를 사용하도록 OpenSSH 구성

전체 시스템의 구성을 변경할 수 있습니다.
  1. /etc/ssh/sshd_config 파일을 엽니다.
  2. AuthorizedKeysCommand 옵션을 사용하여 사용자 키를 검색하기 위해 실행될 명령을 지정합니다.
  3. AuthorizedKeysCommandUser 옵션을 사용하여 명령을 실행할 계정 아래에 사용자를 지정합니다.
다음 예제는 사용자 계정에서 ss s_ssh_authorizedkeys 유틸리티를 실행하도록 SSH를 구성합니다.
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser user
sss_ssh_authorizedkeys 에 대한 자세한 내용은 sss_ssh_authorizedkeys(1) 매뉴얼 페이지를 참조하십시오.
SSH 구성 및 구성 파일에 대한 자세한 내용은 ssh_config(5) 도움말 페이지를 참조하십시오.

22.7. ID 관리의 스마트 카드 인증

ID 관리의 스마트 카드 인증에 대한 자세한 내용은 23장. ID 관리의 스마트 카드 인증 을 참조하십시오.

22.8. 사용자 인증서

사용자 인증서에 대한 자세한 내용은 24장. 사용자, 호스트 및 서비스를 위한 인증서 관리 을 참조하십시오.

23장. ID 관리의 스마트 카드 인증

스마트 카드를 기반으로 하는 인증은 암호에 대한 대안입니다. 사용자 자격 증명은 스마트 카드에 저장되며 특수 소프트웨어와 하드웨어를 사용하여 액세스합니다. 사용자는 스마트 카드를 리더에 배치하고 스마트 카드의 PIN 코드를 제공합니다.
이 장에서는 관리자가 ID 관리에서 스마트 카드 기반 인증을 구성하는 방법과 스마트 카드를 사용하여 ID 관리에 인증하는 방법에 대해 설명합니다.

23.1. 스마트 카드에서 인증서 내보내기

인증서를 내보내려면 다음을 수행합니다.
  1. 스마트 카드를 리더에 넣으십시오.
  2. 다음 명령을 사용하여 스마트 카드의 인증서를 나열합니다. 출력에서 인증에 사용할 인증서를 찾고 해당 닉네임을 확인합니다.
    $ certutil -L -d /etc/pki/nssdb/ -h all
    Certificate Nickname         Trust Attributes
                                 SSL,S/MIME,JAR/XPI
    
    my_certificate               CT,C,C
  3. 인증서 닉네임을 사용하여 인증서를 파일로 추출합니다. 예를 들어 Base64 형식의 인증서를 user.crt:라는 파일에 추출하려면 다음을 수행합니다.
    $ certutil -L -d /etc/pki/nssdb/ -n 'my_certificate' -r | base64 -w 0 > user.crt
    base64 유틸리티는 coreutils 패키지의 일부입니다.

23.2. ID 관리에서 인증서 매핑 규칙 구성

23.2.1. 스마트 카드에서 인증 구성을 위한 인증서 맵핑 규칙

인증서 매핑 규칙은 IdM(Identity Management) 관리자에게 특정 사용자의 인증서에 액세스할 수 없는 시나리오에서 인증서를 사용하여 인증할 수 있는 편리한 방법입니다. 이러한 액세스 부족은 일반적으로 외부 인증 기관에서 인증서를 발급했기 때문에 발생합니다. 특별한 사용 사례는 IdM 도메인이 신뢰 관계에 있는 AD(인증 기관)에서 발급한 인증서로 표시됩니다.
또한 인증서 매핑 규칙은 IdM 환경이 스마트 카드를 사용하는 많은 사용자와 함께 사용하는 경우에도 편리합니다. 이 경우 전체 인증서를 추가하는 것이 복잡할 수 있습니다. 주제와 발급자는 대부분의 시나리오에서 예측 가능하므로 전체 인증서보다 미리 추가하기가 더 쉽습니다. 시스템 관리자는 인증서 매핑 규칙을 생성하고 인증서를 특정 사용자에게 발급하기 전에도 사용자 항목에 인증서 매핑 데이터를 추가할 수 있습니다. 인증서가 발급되면 사용자는 전체 인증서가 항목에 업로드되지 않은 경우에도 인증서를 사용하여 로그인할 수 있습니다.
또한 인증서를 정기적으로 갱신해야 하므로 인증서 매핑 규칙은 관리 오버헤드를 줄입니다. 사용자의 인증서가 갱신되면 관리자가 사용자 항목을 업데이트할 필요가 없습니다. 예를 들어 매핑이 SubjectIssuer 값을 기반으로 하고 새 인증서의 주체 및 발급자가 이전 인증서와 동일한 경우 매핑이 계속 적용됩니다. 반대로 전체 인증서가 사용된 경우 관리자는 새 인증서를 사용자 항목에 업로드하여 이전 인증서를 교체해야 합니다.
인증서 매핑을 설정하려면 다음을 수행합니다.
  1. 관리자는 인증서 매핑 데이터(일반적으로 발급자 및 주체) 또는 전체 인증서를 사용자 계정으로 로드해야 합니다.
  2. 관리자는 사용자의 IdM에 성공적으로 로그인할 수 있는 인증서 매핑 규칙을 생성해야 합니다.
    • 해당 계정에 인증서 매핑 데이터 항목이 포함되어 있습니다.
    • 인증서 매핑 데이터 항목이 인증서의 정보와 일치하는 경우
    매핑 규칙을 구성하고 이를 얻는 방법에 대한 자세한 내용은 IdM의 ID 매핑 규칙 구성 요소 및 일치하는 규칙에 사용하기 위해 인증서에서 발급자 가져오기를 참조하십시오.

23.2.1.1. Active Directory 도메인을 사용한 신뢰에 대한 인증서 매핑 규칙

이 섹션에서는 IdM 배포가 AD(Active Directory) 도메인과 신뢰 관계에 있는 경우 가능한 다양한 인증서 매핑 사용 사례에 대해 간단히 설명합니다.
인증서 매핑 규칙은 신뢰할 수 있는 AD 인증서 시스템이 발급한 스마트 카드 인증서를 보유한 사용자에 대해 IdM 리소스에 액세스할 수 있는 편리한 방법입니다. AD 구성에 따라 다음 시나리오가 가능합니다.

23.2.1.2. IdM의 ID 매핑 규칙의 구성 요소

이 섹션에서는 IdM의 ID 매핑 규칙의 구성 요소와 구성 방법을 설명합니다. 각 구성 요소에는 재정의할 수 있는 기본값이 있습니다. 웹 UI 또는 명령줄에 구성 요소를 정의할 수 있습니다. 명령줄에서 ipa certmaprule-add 명령을 사용하여 ID 매핑 규칙이 생성됩니다.
매핑 규칙
매핑 규칙 구성 요소는 하나 이상의 사용자 계정이 있는 인증서를 연결(또는 매핑)합니다. 규칙은 인증서를 원하는 사용자 계정과 연결하는 LDAP 검색 필터를 정의합니다.
다른 CA(인증 기관)에서 발급한 인증서는 다른 속성을 가질 수 있으며 다른 도메인에서 사용할 수 있습니다. 따라서 IdM은 무조건 매핑 규칙을 적용하지 않고 적절한 인증서에만 적용합니다. 적절한 인증서는 일치하는 규칙을 사용하여 정의합니다.
매핑 규칙 옵션을 비워 두면 인증서가 userCertificate 속성에서 DER 인코딩 바이너리 파일로 검색됩니다.
map rule 옵션을 사용하여 명령줄에서 매핑 규칙을 정의합니다.
일치하는 규칙
domain 목록은 IdM에서 ID 매핑 규칙을 처리할 때 사용자를 검색하려는 ID 도메인을 지정합니다. 옵션을 지정하지 않으면 IdM 클라이언트가 속한 로컬 도메인의 사용자만 검색합니다.
domain 옵션을 사용하여 명령줄에서 도메인을 정의합니다.
우선순위
여러 규칙을 인증서에 적용할 수 있는 경우 우선 순위가 가장 높은 규칙이 우선합니다. 다른 모든 규칙은 무시됩니다.
  • 숫자 값이 낮을수록 ID 매핑 규칙의 우선 순위가 높습니다. 예를 들어 우선 순위 1이 있는 규칙은 우선 순위가 2인 규칙보다 우선 순위가 높습니다.
  • 규칙의 우선 순위 값이 정의되지 않은 경우 우선 순위가 가장 낮습니다.
우선 순위 옵션을 사용하여 명령줄에서 매핑 규칙 우선 순위를 정의합니다.

예 23.1. 인증서 맵핑 규칙 예

명령줄을 사용하여 해당 인증서의 주체 가 IdM의 사용자 계정의 certmapdata 항목과 일치하는 한, EXAMPLE.ORG 조직의 스마트 카드 CA에서 발급한 인증서에 대한 인증을 허용하는 simple_rule 이라는 인증서 매핑 규칙을 정의합니다.
# ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

23.2.1.3. 일치 규칙에 사용할 인증서에서 발급자 얻기

다음 절차에서는 인증서 매핑 규칙의 일치 규칙에 복사하여 붙여넣을 수 있도록 인증서에서 발급자 정보를 가져오는 방법을 설명합니다. 일치하는 규칙에 필요한 발급자 형식을 가져오려면 openssl x509 명령을 사용합니다.

사전 요구 사항

  • 사용자 인증서가 .pem 또는 .crt 형식으로 되어 있습니다.

절차

  1. 인증서에서 사용자 정보를 가져옵니다. 다음과 같이 openssl 인증서 표시 및 서명 유틸리티를 사용합니다.
    • 인코딩된 버전의 요청을 방지하는 no out 옵션
    • 발급자 이름을 출력하는 -issuer 옵션
    • 인증서를 읽을 입력 파일 이름을 지정하는 -in 옵션
    • 가장 구체적인 상대 고유 이름(RDN)을 먼저 표시하는 RFC2253 값과 함께 -nameopt 옵션
    입력 파일에 ID 관리 인증서가 포함된 경우 명령 출력에 Issuer가 사용 중 정보를 사용하여 정의되어 있음을 보여줍니다.
    # openssl x509 -noout -issuer -in idm_user.crt -nameopt RFC2253
    issuer=CN=Certificate Authority,O=REALM.EXAMPLE.COM
    입력 파일에 Active Directory 인증서가 포함된 경우 명령 출력에 Issuer가 도메인 구성 요소 정보를 사용하여 정의되어 있음을 보여줍니다.
    # # openssl x509 -noout -issuer -in ad_user.crt -nameopt RFC2253
    issuer=CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM
  2. 필요한 경우 일치하는 규칙에 따라 명령줄에 새 매핑 규칙을 생성하려면 인증서 발행자가 ad.example.com 도메인의 추출된 AD-knative2012R2-CA 여야 하며 인증서의 주체가 IdM의 사용자 계정의 certmapdata 항목과 일치해야 합니다.
    # ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

추가 정보

일치하는 규칙 및 매핑 규칙에 대해 지원되는 형식에 대한 정보 및 우선 순위 및 도메인 필드에 대한 설명을 포함하여 certmap 명령에 대한 자세한 내용은 sss-certmap(5) 매뉴얼 페이지를 참조하십시오.

23.2.2. IdM에 저장된 사용자의 인증서 매핑 구성

이 섹션에서는 인증 인증을 구성하는 사용자가 IdM에 저장된 경우 IdM에서 인증서 매핑을 활성화하기 위해 수행해야 하는 단계에 대해 설명합니다.

사전 요구 사항

  • 사용자가 IdM에 계정이 있습니다.
  • 관리자에게는 사용자 항목에 추가할 전체 인증서 또는 인증서 매핑 데이터가 있습니다.

23.2.2.1. IdM에 인증서 맵핑 규칙 추가

이 섹션에서는 매핑 규칙에 지정된 조건과 일치하는 인증서를 사용하여 IdM 사용자가 IdM에 인증할 수 있도록 인증서 매핑 규칙을 설정하는 방법을 설명합니다.
23.2.2.1.1. IdM 웹 UI에 인증서 매핑 규칙 추가
  1. 관리자로 IdM 웹 UI에 로그인합니다.
  2. AuthenticationCertificate Identity Mapping Rules 이동합니다.
  3. 추가를 클릭합니다.

    그림 23.1. IdM 웹 UI에 새 인증서 매핑 규칙 추가

    IdM 웹 UI에 새 인증서 매핑 규칙 추가
  4. 규칙 이름을 입력합니다.
  5. 매핑 규칙을 입력합니다. 예를 들어, IdM에서 제공된 인증서의 발급자주체 항목을 검색하고, 제공된 인증서의 두 항목에 있는 정보를 인증하거나 사용하지 않도록 결정하는 내용을 입력하십시오.
    (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
  6. 일치하는 규칙을 입력합니다. 예를 들어 EXAMPLE.ORG 조직의 Smart Card CA 에서 발행한 인증서만 허용하여 사용자를 IdM에 인증하려면 다음을 입력합니다.
    <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG

    그림 23.2. IdM 웹 UI에서 인증서 매핑 규칙의 세부 정보 입력

    IdM 웹 UI에서 인증서 매핑 규칙의 세부 정보 입력
  7. 대화 상자 하단에서 추가 를 클릭하여 규칙을 추가하고 상자를 닫습니다.
  8. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하려면 SSSD를 다시 시작하십시오.
    # systemctl restart sssd
이제 IdM 사용자 항목의 인증서 매핑 데이터와 스마트 카드 인증서에서 찾을 수 있는 매핑 규칙에 지정된 데이터 유형을 비교하는 인증서 매핑 규칙을 설정해야 합니다. 일치하는 항목을 찾으면 일치하는 사용자를 인증합니다.
23.2.2.1.2. 명령줄을 사용하여 인증서 매핑 규칙 추가
  1. 관리자의 인증 정보를 가져옵니다.
    # kinit admin
  2. 매핑 규칙이 기반으로 하는 매핑 규칙과 일치 규칙을 입력합니다. 예를 들어, 제공된 인증서의 IssuerSubject 항목을 검색하고 제시된 인증서의 이 두 항목에 있는 정보를 인증하라는 결정을 내리기 위해 EXAMPLE.ORG 조직의 스마트 카드 CA 에서 발급한 인증서만 인식합니다.
    # ipa certmaprule-add rule_name --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "rule_name"
    -------------------------------------------------------
      Rule name: rule_name
      Mapping rule: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
      Matching rule: <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG
      Enabled: TRUE
  3. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하려면 SSSD를 다시 시작하십시오.
    # systemctl restart sssd
이제 IdM 사용자 항목의 인증서 매핑 데이터와 스마트 카드 인증서에서 찾을 수 있는 매핑 규칙에 지정된 데이터 유형을 비교하는 인증서 매핑 규칙을 설정해야 합니다. 일치하는 항목을 찾으면 일치하는 사용자를 인증합니다.

23.2.2.2. IdM의 사용자 항목에 인증서 매핑 데이터 추가

이 섹션에서는 모두 인증서 매핑 데이터 항목에 지정된 값이 포함된 한 사용자가 여러 인증서를 사용하여 인증할 수 있도록 인증서 매핑 데이터를 IdM 사용자 항목에 입력하는 방법을 설명합니다.
23.2.2.2.1. IdM 웹 UI에서 사용자 항목에 인증서 매핑 데이터 추가
  1. 관리자로 IdM 웹 UI에 로그인합니다.
  2. Users(사용자) ActiveUsers(활성 사용자 ) 로 이동하여 사용자 항목을 클릭합니다.
  3. 인증서 매핑 데이터 옵션을 찾아 추가 를 클릭합니다.
  4. 사용 중인 사용자의 인증서가 있는 경우:
    1. 명령줄 인터페이스에서 cat 유틸리티 또는 텍스트 편집기를 사용하여 인증서를 표시합니다.
      # [root@server ~]# cat idm_user_certificate.pem
      -----BEGIN CERTIFICATE-----
      MIIFFTCCA/2gAwIBAgIBEjANBgkqhkiG9w0BAQsFADA6MRgwFgYDVQQKDA9JRE0u RVhBTVBMRS5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0x ODA5MDIxODE1MzlaFw0yMDA5MDIxODE1MzlaMCwxGDAWBgNVBAoMD0lETS5FWEFN
      [...output truncated...]
    2. 인증서를 복사합니다.
    3. IdM 웹 UI에서 인증서 옆에 있는 추가 를 클릭하고 표시되는 창에 인증서를 붙여넣습니다.

      그림 23.3. 사용자의 인증서 맵핑 데이터 추가: certificate

      사용자의 인증서 맵핑 데이터 추가: certificate
      다른 방법으로는 사용자 인증서가 없지만 발급자 및 인증서 주체 를 알고 있는 경우 Issuer 및 subject 의 라디오 버튼을 확인하고 두 개의 각 상자에 값을 입력합니다.

      그림 23.4. 사용자의 인증서 맵핑 데이터 추가: 발행자 및 주체

      사용자의 인증서 맵핑 데이터 추가: 발행자 및 주체
  5. 추가를 클릭합니다.
  6. 필요한 경우 .pem 형식의 전체 인증서에 액세스할 수 있는 경우 사용자 및 인증서가 연결되어 있는지 확인합니다.
    1. sss_cache 유틸리티를 사용하여 SSSD 캐시에 있는 사용자 레코드를 무효화하고 사용자 정보를 강제로 다시 로드합니다.
      # sss_cache -u user_name
    2. IdM 사용자의 인증서가 포함된 파일 이름으로 ipa certmap-match 명령을 실행합니다.
      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------
    출력은 이제 사용자에게 인증서 매핑 데이터가 추가되었음을 확인하고 23.2.2.1절. “IdM에 인증서 맵핑 규칙 추가” 에 정의된 해당 매핑 규칙이 있는지 확인합니다. 즉, 정의된 인증서 매핑 데이터와 일치하는 인증서를 사용하여 사용자로 인증할 수 있습니다.
23.2.2.2.2. 명령줄을 사용하여 사용자 항목에 인증서 매핑 데이터 추가
  1. 관리자의 인증 정보를 가져옵니다.
    # kinit admin
  2. 사용자 인증서가 있는 경우 ipa user-add-cert 명령을 사용하여 사용자 계정에 인증서를 추가하십시오.
    # CERT=`cat idm_user_cert.pem | tail -n +2 | head -n -1 | tr -d '\r\n'\`
    # ipa user-add-certmapdata idm_user --certificate $CERT
    또는 사용자 인증서에 사용자 인증서가 없지만 사용자 인증서의 발급자주체 를 알고 있는 경우:
    # ipa user-add-certmapdata idm_user --subject "O=EXAMPLE.ORG,CN=test" --issuer "CN=Smart Card CA,O=EXAMPLE.ORG"
    --------------------------------------------
    Added certificate mappings to user "idm_user"
    --------------------------------------------
      User login: idm_user
      Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG
  3. 필요한 경우 .pem 형식의 전체 인증서에 액세스할 수 있는 경우 사용자 및 인증서가 연결되어 있는지 확인합니다.
    1. sss_cache 유틸리티를 사용하여 SSSD 캐시에 있는 사용자 레코드를 무효화하고 사용자 정보를 강제로 다시 로드합니다.
      # sss_cache -u user_name
    2. IdM 사용자의 인증서가 포함된 파일 이름으로 ipa certmap-match 명령을 실행합니다.
      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

23.2.3. 전체 인증서가 포함된 AD 사용자 항목 사용자에 대한 인증서 매핑 구성

이 섹션에서는 IdM 배포가 AD(Active Directory)와 신뢰되고 AD의 사용자 항목에 전체 인증서가 포함된 경우 IdM에서 인증서 매핑을 활성화하는 데 필요한 단계를 설명합니다.

사전 요구 사항

  • 사용자에게 IdM에 계정이 없습니다.
  • 사용자에게 인증서가 포함된 AD 계정이 있습니다.
  • IdM 관리자는 IdM 인증서 매핑 규칙을 기반으로 할 수 있는 데이터에 액세스할 수 있습니다.

23.2.3.1. IdM 웹 UI를 사용하여 전체 인증서가 포함된 사용자를 위한 인증서 매핑 규칙 추가

IdM 웹 UI에 인증서 매핑 규칙을 추가하려면 다음을 수행합니다.
  1. 관리자로 IdM 웹 UI에 로그인합니다.
  2. AuthenticationCertificate Identity Mapping Rules 이동합니다.
  3. 추가를 클릭합니다.

    그림 23.5. IdM 웹 UI에 새 인증서 매핑 규칙 추가

    IdM 웹 UI에 새 인증서 매핑 규칙 추가
  4. 규칙 이름을 입력합니다.
  5. 매핑 규칙을 입력합니다. AD에서 사용할 수 있는 항목에 비해 인증을 위해 IdM에 제공되는 전체 인증서를 사용하려면 다음을 수행합니다.
    (userCertificate;binary={cert!bin})
  6. 일치하는 규칙을 입력합니다. 예를 들어 AD.EXAMPLE.COM 도메인의 AD-ROOT-CA 에서 발급한 인증서만 인증하려면 다음을 수행합니다.
    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com

    그림 23.6. 인증서가 AD에 저장된 사용자의 인증서 맵핑 규칙

    인증서가 AD에 저장된 사용자의 인증서 맵핑 규칙
  7. 추가를 클릭합니다.
  8. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하려면 SSSD를 다시 시작하십시오.
    # systemctl restart sssd

23.2.3.2. 명령줄을 사용하여 전체 인증서가 포함된 사용자용 인증서 매핑 규칙 추가

명령줄을 사용하여 인증서 매핑 규칙을 추가하려면 다음을 수행합니다.
  1. 관리자의 인증 정보를 가져옵니다.
    # kinit admin
  2. 매핑 규칙이 기반으로 하는 매핑 규칙과 일치 규칙을 입력합니다. AD에서 사용할 수 있는 것과 비교하여 인증에 제공되는 전체 인증서를 얻으려면 AD.EXAMPLE.COM 도메인의 AD-ROOT-CA 에서 발급한 인증서만 인증할 수 있습니다.
    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하려면 SSSD를 다시 시작하십시오.
    # systemctl restart sssd

23.2.4. 사용자 인증서를 사용자 계정에 매핑하도록 AD가 구성된 경우 인증서 맵핑 구성

이 섹션에서는 IdM 배포가 AD(Active Directory)를 신뢰하고 AD의 사용자 항목에 인증서 매핑 데이터가 포함된 경우 IdM에서 인증서 매핑을 활성화하는 데 필요한 단계를 설명합니다.

사전 요구 사항

  • 사용자에게 IdM에 계정이 없습니다.
  • 사용자는 IdM certmapdata 속성과 동등한 altSecurityIdentities 속성을 포함하는 AD 계정이 있습니다.
  • IdM 관리자는 IdM 인증서 매핑 규칙을 기반으로 할 수 있는 데이터에 액세스할 수 있습니다.

23.2.4.1. 신뢰할 수 있는 AD 도메인이 사용자 인증서를 매핑하도록 구성된 경우 웹 UI를 사용하여 인증서 매핑 규칙 추가

신뢰할 수 있는 AD 도메인이 사용자 인증서를 매핑하도록 구성된 경우 인증서 매핑 규칙을 추가하려면 다음을 수행합니다.
  1. 관리자로 IdM 웹 UI에 로그인합니다.
  2. AuthenticationCertificate Identity Mapping Rules 이동합니다.
  3. 추가를 클릭합니다.

    그림 23.7. IdM 웹 UI에 새 인증서 매핑 규칙 추가

    IdM 웹 UI에 새 인증서 매핑 규칙 추가
  4. 규칙 이름을 입력합니다.
  5. 매핑 규칙을 입력합니다. 예를 들어 AD DC가 제공된 인증서의 IssuerSubject 항목을 검색하고 제시된 인증서의 이 두 항목에 있는 정보를 인증하거나 찾지 않기로 결정하도록 하려면 다음을 수행합니다.
    (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
  6. 일치하는 규칙을 입력합니다. 예를 들어 AD.EXAMPLE.COM 도메인의 AD-ROOT-CA 에서 발급한 인증서만 허용하여 사용자를 IdM에 인증합니다.
    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. 도메인을 입력합니다.
    ad.example.com

    그림 23.8. 매핑을 위해 AD가 구성된 경우 인증서 맵핑 규칙

    매핑을 위해 AD가 구성된 경우 인증서 맵핑 규칙
  8. 추가를 클릭합니다.
  9. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하려면 SSSD를 다시 시작하십시오.
    # systemctl restart sssd

23.2.4.2. 신뢰할 수 있는 AD 도메인이 사용자 인증서를 매핑하도록 구성된 경우 명령줄을 사용하여 인증서 매핑 규칙 추가

명령줄을 사용하여 인증서 매핑 규칙을 추가하려면 다음을 수행합니다.
  1. 관리자의 인증 정보를 가져옵니다.
    # kinit admin
  2. 매핑 규칙이 기반으로 하는 매핑 규칙과 일치 규칙을 입력합니다. 예를 들어 AD에서 제공된 인증서의 IssuerSubject 항목을 검색하고 AD.EXAMPLE.COM 도메인의 AD-ROOT-CA 에서 발급한 인증서만 허용하려면 다음을 수행합니다.
    # ipa certmaprule-add ad_configured_for_mapping_rule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})' --domain=ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "ad_configured_for_mapping_rule"
    -------------------------------------------------------
      Rule name: ad_configured_for_mapping_rule
      Mapping rule: (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하려면 SSSD를 다시 시작하십시오.
    # systemctl restart sssd

23.2.4.3. AD Side에서 인증서 맵핑 데이터 확인

altSecurityIdentities 속성은 IdM의 certmapdata 사용자 속성과 동등한 AD(Active Directory)입니다. 사용자 인증서를 사용자 계정에 매핑하도록 신뢰할 수 있는 AD 도메인이 구성된 경우 IdM 시스템 관리자가 AD의 사용자 항목에 altSecurityIdentities 속성이 올바르게 설정되었는지 확인해야 합니다.
AD에 AD에 저장된 사용자에 대한 올바른 정보가 포함되어 있는지 확인하려면 ldapsearch 명령을 사용합니다.
예를 들어 altSecurityIdentities 속성이 ad_user 의 사용자 항목에 설정된 adserver.ad.example.com 서버를 사용하려면 ad.example.com 도메인의 AD-ROOT-CA에서 AD-ROOT-CA 에서 발행한 인증서가 ad.example.com 도메인의 AD-ROOT-CA에서 발행한 인증서가 있음을 규정합니다. DC=example,DC=ad,CN=Users,CN=ad_user:
$ ldapsearch -o ldif-wrap=no -LLL -h adserver.ad.example.com \
-p 389 -D cn=Administrator,cn=users,dc=ad,dc=example,dc=com \
-W -b cn=users,dc=ad,dc=example,dc=com "(cn=ad_user)" \
altSecurityIdentities
Enter LDAP Password:
dn: CN=ad_user,CN=Users,DC=ad,DC=example,DC=com
altSecurityIdentities: X509:<I>DC=com,DC=example,DC=ad,CN=AD-ROOT-CA<S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user

23.2.5. AD User Entry에 인증서 또는 매핑 데이터가 없는 경우 인증서 맵핑 구성

이 섹션에서는 IdM 배포가 AD(Active Directory)를 신뢰하고 AD의 사용자 항목에 전체 인증서 및 인증서 매핑 데이터를 모두 포함하는 경우 IdM에서 인증서 매핑을 활성화하는 데 필요한 단계를 설명합니다.

사전 요구 사항

  • 사용자에게 IdM에 계정이 없습니다.
  • 사용자에게는 IdM certmapdata 속성과 동등한 전체 인증서 또는 altSecurityIdentities 속성이 모두 포함되지 않은 AD에 계정이 있습니다.
  • IdM 관리자에게는 IdM의 AD 사용자의 사용자 ID 재정의에 추가할 전체 AD 사용자 인증서가 있습니다.

23.2.5.1. AD 사용자가 인증서 또는 맵핑 데이터를 포함하지 않는 경우 웹 UI를 사용하여 인증서 맵핑 규칙 추가

AD 사용자 항목에 인증서 또는 매핑 데이터가 없는 경우 웹 UI를 사용하여 인증서 매핑 규칙을 추가하려면 다음을 수행합니다.
  1. 관리자로 IdM 웹 UI에 로그인합니다.
  2. AuthenticationCertificate Identity Mapping Rules 이동합니다.
  3. 추가를 클릭합니다.

    그림 23.9. IdM 웹 UI에 새 인증서 매핑 규칙 추가

    IdM 웹 UI에 새 인증서 매핑 규칙 추가
  4. 규칙 이름을 입력합니다.
  5. 매핑 규칙을 입력합니다. IdM에서 AD 사용자 항목의 사용자 ID 재정의 항목에 저장된 인증서에 비해 인증을 위해 IdM에 제공된 전체 인증서를 확인하려면 다음을 수행합니다.
    (userCertificate;binary={cert!bin})
  6. 일치하는 규칙을 입력합니다. 예를 들어 AD.EXAMPLE.COM 도메인의 AD-ROOT-CA 에서 발급한 인증서만 인증하려면 다음을 수행합니다.
    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. 도메인 이름을 입력합니다. 예를 들어 ad.example.com 도메인에서 사용자를 검색하려면 다음을 수행합니다.

    그림 23.10. 인증서가 없거나 AD에 저장된 데이터 맵핑이 없는 사용자의 인증서 맵핑 규칙

    인증서가 없거나 AD에 저장된 데이터 맵핑이 없는 사용자의 인증서 맵핑 규칙
  8. 추가를 클릭합니다.
  9. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하려면 SSSD를 다시 시작하십시오.
    # systemctl restart sssd

23.2.5.2. AD 사용자가 인증서 또는 매핑 데이터를 포함하지 않는 경우 명령줄을 사용하여 인증서 맵핑 규칙 추가

AD 사용자 항목에 인증서 또는 매핑 데이터가 없는 경우 명령줄을 사용하여 인증서 매핑 규칙을 추가하려면 다음을 수행합니다.
  1. 관리자의 인증 정보를 가져옵니다.
    # kinit admin
  2. 매핑 규칙이 기반으로 하는 매핑 규칙과 일치 규칙을 입력합니다. IdM의 AD 사용자 항목의 AD 사용자 항목에 저장된 인증서에 비해 인증에 제공되는 전체 인증서를 사용하려면 AD.EXAMPLE.COM 도메인의 AD-ROOT-CA 에서 발급한 인증서만 인증할 수 있습니다.
    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하려면 SSSD를 다시 시작하십시오.
    # systemctl restart sssd

23.2.5.3. 웹 UI를 사용하여 AD 사용자의 ID 재정의에 인증서 추가

AD의 사용자 항목에 인증서 또는 매핑 데이터가 없는 경우 AD 사용자 ID에 인증서를 추가하려면 웹 UI를 사용하여 인증서를 재정의합니다.
  1. 관리자로 IdM 웹 UI에 로그인합니다.
  2. IdentityID ViewsDefault Trust View 로 이동합니다.
  3. 추가를 클릭합니다.

    그림 23.11. IdM 웹 UI에서 새 사용자 ID 재정의 추가

    IdM 웹 UI에서 새 사용자 ID 재정의 추가
  4. User to override ( 재정의할 사용자) 필드에 다음 형식으로 사용자 이름을 입력합니다. user_name@domain_name
  5. 사용자 인증서를 복사하여 인증서 필드에 붙여넣습니다.

    그림 23.12. AD 사용자의 사용자 ID 재정의 구성

    AD 사용자의 사용자 ID 재정의 구성
  6. 선택적으로 사용자 및 인증서가 연결되었는지 확인합니다.
    1. sss_cache 유틸리티를 사용하여 SSSD 캐시에 있는 사용자 레코드를 무효화하고 사용자 정보를 강제로 다시 로드합니다.
      # sss_cache -u ad_user@ad.example.com
    2. AD 사용자의 인증서가 포함된 파일 이름으로 ipa certmap-match 명령을 입력합니다.
      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------
      출력에 ad_user@ad.example.com 에 인증서 매핑 데이터가 추가되고 해당 매핑 규칙이 있는지 확인합니다. 즉, 정의된 인증서 매핑 데이터와 일치하는 모든 인증서를 사용하여 ad_user@ad.example.com 로 인증할 수 있습니다.

23.2.5.4. 명령줄을 사용하여 AD 사용자의 ID 재정의에 인증서 추가

AD의 사용자 항목에 인증서 또는 매핑 데이터가 없는 경우 명령줄을 사용하여 AD 사용자 ID에 인증서를 추가하려면 다음을 수행합니다.
  1. 관리자의 인증 정보를 가져옵니다.
    # kinit admin
  2. ipa idoverrideuser-add-cert 명령을 사용하여 사용자 계정에 사용자 인증서를 추가합니다.
    # CERT=`cat ad_user_cert.pem | tail -n +2 | head -n -1 | tr -d '\r\n'\`
    # ipa idoverrideuser-add-cert ad_user@ad.example.com --certificate $CERT
  3. 선택적으로 사용자 및 인증서가 연결되었는지 확인합니다.
    1. sss_cache 유틸리티를 사용하여 SSSD 캐시에 있는 사용자 레코드를 무효화하고 사용자 정보를 강제로 다시 로드합니다.
      # sss_cache -u ad_user@ad.example.com
    2. AD 사용자의 인증서가 포함된 파일 이름으로 ipa certmap-match 명령을 입력합니다.
      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------
      출력에 ad_user@ad.example.com 에 인증서 매핑 데이터가 추가되고 해당 매핑 규칙이 있는지 확인합니다. 즉, 정의된 인증서 매핑 데이터와 일치하는 모든 인증서를 사용하여 ad_user@ad.example.com 로 인증할 수 있습니다.

23.2.6. Several Identity Mapping Rules Into One의 결합

여러 ID 매핑 규칙을 하나의 결합된 규칙으로 결합하려면 | (또는) 문자를 사용하여 개별 매핑 규칙 앞에 배치하고 () 대괄호를 사용하여 분리합니다. 예를 들면 다음과 같습니다.
$ ipa certmaprule-add ad_cert_for_ipa_and_ad_users \ --maprule='(|(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \ --matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \ --domain=ad.example.com
위 예제에서 --maprule 옵션의 필터 정의에는 다음 기준이 포함됩니다.
--maprule 옵션의 필터 정의는 여러 조건을 지정할 수 있도록 논리 연산자 | (또는)를 허용합니다. 이 경우 규칙은 기준 중 하나 이상을 충족하는 모든 사용자 계정을 매핑합니다.
$ ipa certmaprule-add ipa_cert_for_ad_users \
  --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
  --matchrule='<ISSUER>CN=Certificate Authority,O=REALM.EXAMPLE.COM' \
  --domain=idm.example.com --domain=ad.example.com
위 예제에서 --maprule 옵션의 필터 정의에는 다음 기준이 포함됩니다.
map rule 옵션의 필터 정의는 논리 연산자 |(또는)를 수락하므로 여러 기준을 지정할 수 있습니다. 이 경우 규칙은 기준 중 하나 이상을 충족하는 모든 사용자 계정을 매핑합니다.

23.3. 스마트 카드를 사용하여 ID 관리 클라이언트에 인증

ID 관리 서버에서 여러 역할 계정이 있는 Identity Management 사용자는 Identity Management 도메인에 연결된 데스크탑 클라이언트 시스템에 스마트 카드로 인증할 수 있습니다. 이를 통해 클라이언트 시스템을 선택한 역할로 사용할 수 있습니다.
지원되는 옵션에 대한 기본 개요는 다음을 참조하십시오.
인증을 사용하도록 환경을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
인증 방법에 대한 자세한 내용은 다음을 참조하십시오.

23.3.1. ID 관리 클라이언트에서 지원되는 스마트 카드 기반 인증 옵션

ID 관리 클라이언트의 사용자는 ID 관리 클라이언트에서 스마트 카드를 사용하여 인증할 때 다음 옵션을 사용할 수 있습니다.
로컬 인증
로컬 인증에는 다음을 사용한 인증이 포함됩니다.
  • 텍스트 콘솔
  • GDM(Gnome Display Manager)과 같은 그래픽 콘솔
  • 로컬 인증 서비스 (예: su 또는 sudo)
ssh를 사용한 원격 인증
스마트 카드의 인증서는 PIN 보호 SSH 개인 키와 함께 저장됩니다.
FTP와 같은 다른 서비스를 사용한 스마트 카드 기반 인증은 지원되지 않습니다.

23.3.2. 스마트 카드 인증을 위해 ID 관리 클라이언트 준비

Identity Management 관리자로서 다음 단계를 수행하십시오.
  1. 서버에서 클라이언트를 구성할 쉘 스크립트를 만듭니다.
    1. ipa-advise config-client-for-smart-card-auth 명령을 사용하여 출력을 파일에 저장합니다.
      # ipa-advise config-client-for-smart-card-auth > client_smart_card_script.sh
    2. 스크립트 파일을 열고 해당 콘텐츠를 검토합니다.
    3. 10.0.0.1 유틸리티를 사용하여 파일에 실행 권한 추가합니다.
      # chmod +x client_smart_card_script.sh
  2. 스크립트를 클라이언트에 복사하고 실행합니다. 스마트 카드 인증서에 서명한 CA(인증 기관)를 사용하여 PEM 파일의 경로를 추가합니다.
    # ./client_smart_card_script.sh CA_cert.pem
또한 외부 CA(인증 기관)가 스마트 카드의 인증서에 서명한 경우 스마트 카드 CA를 신뢰할 수 있는 CA로 추가합니다.
  1. Identity Management 서버에서 CA 인증서를 설치합니다.
    # ipa-cacert-manage -n "SmartCard CA" -t CT,C,C install ca.pem
    # ipa-certupdate
    모든 복제본 및 클라이언트에서도 ipa-certupdate 를 반복합니다.
  2. HTTP 서버를 다시 시작합니다.
    # systemctl restart httpd
    모든 복제본에서 systemctl restart httpd 도 반복합니다.
참고
SSSD를 사용하면 관리자가 인증서에 정의된 OCSP(Online Certificate Status Protocol) 서버에 연결할 수 없는 경우와 같이 certificate_verification 매개변수를 사용하여 인증서 확인 프로세스를 조정할 수 있습니다. 자세한 내용은 sssd.conf(5) 매뉴얼 페이지를 참조하십시오.

23.3.3. 콘솔 로그인을 사용하여 스마트 카드가 있는 ID 관리 클라이언트에서 인증

Identity Management 사용자로 인증하려면 사용자 이름과 PIN을 입력합니다.
  • 명령줄에서 로그인하는 경우:
    client login: idm_user
    PIN for PIV Card Holder pin (PIV_II) for user idm_user@idm.example.com:
  • GDM(Gnome Desktop Manager)을 사용하여 로그인할 때 필요한 사용자를 선택한 후 GDM에서 스마트 카드 PIN을 입력하라는 메시지를 표시합니다.

    그림 23.13. Gnome 데스크탑 관리자에 스마트 카드 PIN 입력

    Gnome 데스크탑 관리자에 스마트 카드 PIN 입력
Active Directory 사용자로 인증하려면 NetBIOS 도메인 이름을 사용하는 형식으로 사용자 이름을 입력합니다. AD.EXAMPLE.COM\ad_user 또는 ad_user@AD.EXAMPLE.COM.
인증에 실패하는 경우 A.4절. “스마트 카드 인증 오류 조사” 을 참조하십시오.

23.3.4. 로컬 시스템에서 원격 시스템에 인증

로컬 시스템에서 다음 단계를 수행하십시오.
  1. 스마트 카드를 삽입합니다.
  2. ssh 를 시작하고 -I 옵션을 사용하여 PKCS#11 라이브러리를 지정합니다.
    • Identity Management 사용자:
      $ ssh -I /usr/lib64/opensc-pkcs11.so -l idm_user server.idm.example.com
      
      Enter PIN for 'PIV_II (PIV Card Holder pin)':
      Last login: Thu Apr  6 12:49:32 2017 from 10.36.116.42
    • Active Directory 사용자:
      $ ssh -I /usr/lib64/opensc-pkcs11.so -l ad_user@ad.example.com server.idm.example.com
      
      Enter PIN for 'PIV_II (PIV Card Holder pin)':
      Last login: Thu Apr  6 12:49:32 2017 from 10.36.116.42
  3. 선택 사항입니다. id 유틸리티를 사용하여 원하는 사용자로 로그인했는지 확인합니다.
    • Identity Management 사용자:
      $ id
      uid=1928200001(idm_user) gid=1928200001(idm_user) groups=1928200001(idm_user) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
    • Active Directory 사용자:
      $ id
      uid=1171201116(ad_user@ad.example.com) gid=1171201116(ad_user@ad.example.com) groups=1171201116(ad_user@ad.example.com),1171200513(domain users@ad.example.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
인증에 실패하는 경우 A.4절. “스마트 카드 인증 오류 조사” 을 참조하십시오.

23.3.5. 추가 리소스

  • 스마트 카드로 ssh 를 사용한 인증은 원격 시스템에서 TGT( ticket-granting ticket)를 받을 수 없습니다. 원격 시스템에서 TGT를 가져오려면 관리자가 로컬 시스템에서 Kerberos를 구성하고 Kerberos 위임을 활성화해야 합니다. 필수 구성의 예는 이 Kerberos 지식 기반 항목을 참조하십시오.
  • OpenSSH를 통한 스마트 카드 인증에 대한 자세한 내용은 보안 가이드에서 Smart Cards to supply Credentials to OpenSSH 를 참조하십시오.

23.4. 스마트 카드 인증을 위한 사용자 이름 힌트 정책 구성

ID 관리 관리자는 여러 계정에 연결된 스마트 카드에 대한 사용자 이름 힌트 정책을 구성할 수 있습니다.

23.4.1. ID 관리의 사용자 이름 힌트

사용자 이름 힌트 정책은 스마트 카드 사용자에게 사용자 이름을 묻는 메시지를 표시하도록 ID 관리를 구성합니다. 사용자가 ID 관리에서 여러 사용자 계정과 일치하는 스마트 카드 인증서로 인증을 시도하면 다음 중 하나가 발생합니다.
  • 사용자 이름 힌트 정책이 활성화되면 사용자에게 사용자 이름을 묻는 메시지가 표시되면 인증을 계속 진행할 수 있습니다.
  • 사용자 이름 힌트 정책이 비활성화되면 메시지가 표시되지 않고 인증이 실패합니다.
Identity Management는 기본적으로 사용자 이름을 요청하지 않고 스마트 카드 PIN을 요청하는 메시지가 표시되는 애플리케이션에 사용자 이름 힌트를 추가합니다. Red Hat Enterprise Linux에서는 현재 GDM(Gnome Desktop Manager) 로그인에 불과합니다.

그림 23.14. Gnome 데스크탑 관리자의 사용자 이름 힌트

Gnome 데스크탑 관리자의 사용자 이름 힌트
ID 관리는 기본적으로 사용자 이름을 요청하는 애플리케이션에 사용자 이름 힌트를 추가하지 않습니다. 예를 들면 다음과 같습니다.
  • GUI가 항상 Username 필드를 표시하므로 Identity Management 웹 UI 인증
  • ssh 는 현재 사용자의 로그인 이름 또는 -l 옵션과 함께 제공된 이름을 사용하거나 username@host 형식으로 사용하기 때문에 SSH 인증
  • 로그인 이름이 항상 제공되는 콘솔 인증
이러한 상황에서는 여러 사용자와 일치하는 인증서를 사용한 인증이 항상 허용됩니다.

23.4.2. ID 관리에서 사용자 이름 힌트 활성화

ID 관리 관리자는 사용자 이름 힌트 정책을 중앙에서 설정합니다. 정책은 Identity Management 도메인에 등록된 모든 호스트에 적용됩니다.
모든 Identity Management 시스템에서 다음 단계를 수행하십시오.

명령줄: ID 관리에서 사용자 이름 힌트 활성화

  1. Identity Management 관리자로 로그인합니다.
    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  2. --promptusername=True 옵션과 함께 ipa certmapconfig-mod 명령을 사용하여 사용자 이름 힌트를 활성화합니다.
    $ ipa certmapconfig-mod --promptusername=TRUE
    Prompt for the username: TRUE
    사용자 이름 힌트를 비활성화하려면 --promptusername=False 옵션을 사용합니다.

웹 UI: ID 관리에서 사용자 이름 힌트 활성화

  1. AuthenticationCertificate Identity Mapping RulesCertificate Mapping Global Configuration 을 클릭합니다.
  2. 사용자 이름 프롬프트를 선택하고 저장 을 클릭합니다.

    그림 23.15. 웹 UI에서 사용자 이름 힌트 활성화

    웹 UI에서 사용자 이름 힌트 활성화

추가 리소스

  • ipa certmapconfig-mod 명령에 대한 자세한 내용은 --help 옵션을 사용하여 실행하십시오.

23.5. ID 관리에서의 PKINIT 스마트 카드 인증

Identity Management 사용자는 Identity Management에 연결된 데스크탑 클라이언트 시스템에 스마트 카드로 인증하고 TGT(Kerberos 티켓 승인 티켓)를 자동으로 받을 수 있습니다. 사용자는 클라이언트의 추가 SSO(Single Sign-On) 인증에 티켓을 사용할 수 있습니다.

23.5.1. PKINIT 인증을 위한 ID 관리 클라이언트 준비

ID 관리 관리자로서 사용자가 인증하려는 클라이언트에서 다음 단계를 수행하십시오.
  1. 서버에서 클라이언트를 구성할 쉘 스크립트를 만듭니다.
    1. ipa-advise config-client-for-smart-card-auth 명령을 사용하여 출력을 파일에 저장합니다.
      # ipa-advise config-client-for-smart-card-auth > client_smart_card_script.sh
    2. 스크립트 파일을 열고 해당 콘텐츠를 검토합니다.
    3. 10.0.0.1 유틸리티를 사용하여 파일에 실행 권한 추가합니다.
      # chmod +x client_smart_card_script.sh
  2. 스크립트를 클라이언트에 복사하고 실행합니다. 스마트 카드 인증서에 서명한 CA(인증 기관)를 사용하여 PEM 파일의 경로를 추가합니다.
    # ./client_smart_card_script.sh CA_cert.pem
  3. the krb5-pkinit 패키지가 설치되어 있는지 확인합니다.
또한 외부 CA(인증 기관)가 스마트 카드의 인증서에 서명한 경우 스마트 카드 CA를 신뢰할 수 있는 CA로 추가합니다.
  1. Identity Management 서버에서 CA 인증서를 설치합니다.
    # ipa-cacert-manage -n "SmartCard CA" -t CT,C,C install ca.pem
    # ipa-certupdate
    모든 복제본 및 클라이언트에서도 ipa-certupdate 를 반복합니다.
  2. HTTP 서버를 다시 시작합니다.
    # systemctl restart httpd
    모든 복제본에서 systemctl restart httpd 도 반복합니다.
참고
SSSD를 사용하면 관리자가 인증서에 정의된 OCSP(Online Certificate Status Protocol) 서버에 연결할 수 없는 경우와 같이 certificate_verification 매개변수를 사용하여 인증서 확인 프로세스를 조정할 수 있습니다. 자세한 내용은 sssd.conf(5) 매뉴얼 페이지를 참조하십시오.

23.5.2. ID 관리 사용자: ID 관리 클라이언트에서 PKINIT를 사용하여 인증

Identity Management 클라이언트에서 kinit 유틸리티를 사용하여 인증합니다.
$ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' idm_user
X 옵션은 opensc-pkcs11.so 모듈을 사전 인증 속성으로 지정합니다. 자세한 내용은 kinit(1) 매뉴얼 페이지를 참조하십시오.

23.5.3. Active Directory 사용자: ID 관리 클라이언트에서 PKINIT를 사용하여 인증

사전 요구 사항

관리자는 Active Directory 사용자에 대한 PKINIT 인증을 지원하도록 환경을 구성합니다.
  • 스마트 카드 인증서를 발행한 CA(인증 기관)를 신뢰하도록 Active Directory 서버를 구성합니다. NTAuth 저장소에서 CA를 가져오고( Microsoft 지원참조) 신뢰할 수 있는 CA로 CA를 추가합니다. 자세한 내용은 Active Directory 설명서를 참조하십시오.
  • 스마트 카드 인증서를 발급한 CA를 신뢰하도록 Kerberos 클라이언트를 구성합니다.
    1. Identity Management 클라이언트에서 /etc/krb5.conf 파일을 엽니다.
    2. 파일에 다음 행을 추가합니다.
      [libdefaults]
      [... file truncated ...]
       pkinit_eku_checking = kpServerAuth
       pkinit_kdc_hostname = adserver.ad.domain.com
  • 사용자 인증서에 인증서 폐기 목록(CRL) 배포 지점 확장이 포함되어 있지 않은 경우 취소 오류를 무시하도록 Active Directory를 구성합니다.
    1. 다음 REG 형식 콘텐츠를 일반 텍스트 파일에 저장하고 파일을 두 번 클릭하여 Windows 레지스트리로 가져옵니다.
      Windows Registry Editor Version 5.00
      
      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc]
      "UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001
      
      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\Kerberos\Parameters]
      "UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001
      또는 regedit.exe 애플리케이션을 사용하여 값을 수동으로 설정합니다.
    2. Windows 시스템을 재부팅하여 변경 사항을 적용합니다.

절차

Identity Management 클라이언트에서 kinit 유틸리티를 사용하여 인증합니다. 사용자 이름과 도메인 이름을 사용하여 Active Directory 사용자를 지정합니다.
$ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' ad_user@AD.DOMAIN.COM
X 옵션은 opensc-pkcs11.so 모듈을 사전 인증 속성으로 지정합니다. 자세한 내용은 kinit(1) 매뉴얼 페이지를 참조하십시오.

23.6. 스마트 카드를 사용하여 ID 관리 웹 UI 인증

ID 관리 서버에서 여러 역할 계정이 있는 ID 관리 사용자는 선택한 역할로 스마트 카드로 ID 관리 웹 UI에 인증할 수 있습니다. 이를 통해 웹 UI를 선택한 역할로 사용할 수 있습니다.
참고
ID 관리 사용자만 스마트 카드를 사용하여 웹 UI에 로그인할 수 있습니다. Active Directory 사용자는 사용자 이름과 암호로 로그인할 수 있습니다. 자세한 내용은 5.4.2.4절. “AD 사용자로 IdM 웹 UI에 인증” 의 내용을 참조하십시오.
인증을 사용하도록 환경을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
인증 방법에 대한 자세한 내용은 다음을 참조하십시오.

23.6.1. 웹 UI에서 스마트 카드 인증을 위한 ID 관리 서버 준비

Identity Management 관리자로서:
  1. Identity Management 서버에서 서버를 구성할 쉘 스크립트를 생성합니다.
    1. ipa-advise config-server-for-smart-card-auth 명령을 사용하여 출력을 파일에 저장합니다.
      # ipa-advise config-server-for-smart-card-auth > server_smart_card_script.sh
    2. 스크립트 파일을 열고 해당 콘텐츠를 검토합니다.
    3. 10.0.0.1 유틸리티를 사용하여 파일에 실행 권한 추가합니다.
      # chmod +x server_smart_card_script.sh
  2. Identity Management 도메인의 모든 서버에서 스크립트를 실행합니다.
  3. sssd-dbus 패키지가 설치되어 있는지 확인합니다.
또한 외부 CA(인증 기관)가 스마트 카드의 인증서에 서명한 경우 다음을 수행합니다.
  1. ID 관리 서버에서 HTTP 서버에서 사용하는 NSS 데이터베이스에 CA 인증서를 추가합니다.
    # ipa-cacert-manage -n "SmartCard CA" -t CT,C,C install ca.pem
    # ipa-certupdate
    모든 복제본 및 클라이언트에서 ipa-certupdate 를 반복합니다.
  2. HTTP 서버 및 Kerberos 서버를 다시 시작합니다.
    # systemctl restart httpd
    # systemctl restart krb5kdc
    모든 복제본에서 명령을 반복합니다.

23.6.2. 스마트 카드 인증을 위한 브라우저 준비

스마트 카드 인증을 위해 브라우저를 구성하려면 사용자가 웹 UI에 액세스하기 위해 웹 브라우저를 시작하는 클라이언트에서 이러한 단계를 수행합니다. 브라우저가 실행 중인 시스템에서 Identity Management 도메인의 일부가 아니어도 됩니다. 이 절차에서는 Firefox 브라우저를 사용하고 있습니다.
  1. Firefox를 실행합니다.
  2. 스마트 카드에서 인증서를 읽도록 Firefox를 구성합니다.
    1. EditAdvancedcertificateSecurityDevices를 선택합니다.

      그림 23.16. Firefox에서 보안 장치 구성

      Firefox에서 보안 장치 구성
    2. Load 를 클릭합니다. Load PKCS#11 장치 창에서 다음 정보를 작성합니다.
      • 모듈 이름: OpenSC
      • 모듈 파일 이름:/usr/lib64/opensc-pkcs11.so

      그림 23.17. Firefox에서 장치 관리자

      Firefox에서 장치 관리자
    3. 확인을 클릭하여 확인합니다. 확인 을 클릭하여 장치 관리자를 종료합니다.Click OK to close the Device Manager.
이제 Firefox에서 인증을 위해 스마트 카드 인증서를 사용할 수 있습니다.

23.6.3. ID 관리 사용자로 스마트 카드를 사용하여 ID 관리 웹 UI 인증

인증하려면 다음을 수행합니다.
  1. 스마트 카드 리더에 스마트 카드를 삽입합니다.
  2. 브라우저에서 https://ipaserver.example.com/ipa/ui 에서 Identity Management 웹 UI로 이동합니다.
  3. 스마트 카드 인증서가 단일 사용자 계정에 연결된 경우 Username 필드를 작성하지 마십시오.
    스마트 카드 인증서가 여러 사용자 계정에 연결된 경우 Username 필드를 작성하여 필요한 계정을 지정합니다.
  4. 인증서를 사용하여 로그인을 클릭합니다.

    그림 23.18. Identity Management 웹 UI에서 인증서를 사용하여 로그인

    Identity Management 웹 UI에서 인증서를 사용하여 로그인
  5. 메시지가 표시되면 스마트 카드 PIN을 입력합니다.

    그림 23.19. 스마트 카드 PIN 입력

    스마트 카드 PIN 입력
  6. 새 창이 열리고 사용할 인증서를 제공합니다. 스마트 카드 인증서를 선택합니다.

    그림 23.20. 스마트 카드 인증서 선택

    스마트 카드 인증서 선택
이제 스마트 카드 인증서에 해당하는 사용자로 인증됩니다.
참고
관리자가 사용자의 암호를 재설정하면 IdM 웹 UI는 사용자가 kinit 유틸리티를 사용하여 새 암호를 설정할 때까지 액세스를 거부합니다.

추가 리소스

23.6.4. 추가 리소스

23.7. 웹 애플리케이션과 ID 관리 스마트 카드 인증 통합

애플리케이션이 ID 관리 웹 인프라 Apache 모듈을 통해 인증 백엔드로 ID 관리 서버를 사용하는 개발자로서, 스마트 카드에 연결된 여러 역할 계정이 있는 사용자의 인증을 활성화하도록 애플리케이션을 구성할 수 있습니다. 이를 통해 이러한 사용자는 허용된 역할 계정에서 애플리케이션을 사용할 수 있습니다.

23.7.1. 스마트 카드로 웹 애플리케이션 인증 필수 조건

Apache 웹 애플리케이션이 실행 중인 서버에서 다음을 수행합니다.
  • ID 관리 도메인에 서버를 클라이언트로 등록합니다.
  • sssd-dbusmod_lookup_identity 패키지를 설치합니다.
  • Apache에 mod_nss 모듈을 사용하여 구성된 작동 HTTPS 연결이 있는지 확인합니다.

23.7.2. 웹 애플리케이션에 대한 ID 관리 스마트 카드 인증 구성

  1. /etc/httpd/conf.d/nss.conf 파일의 mod_nss 구성에서 TLS 재협정을 활성화합니다.
    NSSRenegotiation
    NSSRequireSafeNegotiation on
  2. mod_nss 인증서 데이터베이스의 클라이언트 인증서에 대해 사용자 인증서를 발행하는 CA가 신뢰할 수 있는지 확인합니다. 데이터베이스의 기본 위치는 /etc/httpd/alias 입니다.
  3. 웹 애플리케이션을 추가합니다. 이 절차에서는 로그인 페이지와 보호 영역으로 구성된 거의 최소한의 예를 사용하고 있습니다.
    • /login 엔드포인트는 사용자만 사용자 이름을 제공하고 사용자를 애플리케이션의 보호된 부분으로 보낼 수 있습니다.
    • /app 엔드 포인트는 REMOTE_USER 환경 변수를 확인합니다. 로그인에 성공하면 변수에는 로그인한 사용자의 ID가 포함됩니다. 그렇지 않으면 변수가 설정되지 않습니다.
  4. 디렉터리를 만들고 그룹을 apache 로 설정하고 모드를 최소 10.0.0.1으로 설정합니다. 이 절차에서는 /var/www/app/ 이라는 디렉토리를 사용하고 있습니다.
  5. 파일을 만들고 그룹을 apache 로 설정하고 모드를 최소 10.0.0.1으로 설정합니다. 이 절차에서는 /var/www/app/login.py 라는 파일을 사용하고 있습니다.
    다음 내용을 파일에 저장합니다.
    #! /usr/bin/env python
    
    def application(environ, start_response):
        status = '200 OK'
        response_body = """
    <!DOCTYPE html>
    <html>
        <head>
            <title>Login</title>
        </head>
        <body>
            <form action='/app' method='get'>
                Username: <input type='text' name='username'>
                <input type='submit' value='Login with certificate'>
            </form>
        </body>
    </html>
    """
        response_headers = [
            ('Content-Type', 'text/html'),
            ('Content-Length', str(len(response_body)))
        ]
        start_response(status, response_headers)
        return [response_body]
  6. 파일을 만들고 그룹을 apache 로 설정하고 모드를 최소 10.0.0.1으로 설정합니다. 이 절차에서는 /var/www/app/protected.py 라는 파일을 사용하고 있습니다.
    다음 내용을 파일에 저장합니다.
    #! /usr/bin/env python
    
    def application(environ, start_response):
        try:
            user = environ['REMOTE_USER']
        except KeyError:
            status = '400 Bad Request'
            response_body = 'Login failed.\n'
        else:
            status = '200 OK'
            response_body = 'Login succeeded. Username: {}\n'.format(user)
    
        response_headers = [
            ('Content-Type', 'text/plain'),
            ('Content-Length', str(len(response_body)))
        ]
        start_response(status, response_headers)
        return [response_body]
  7. 애플리케이션에 대한 구성 파일을 생성합니다. 이 절차에서는 /etc/httpd/conf.d/app.conf 라는 파일을 다음 콘텐츠와 함께 사용하고 있습니다.
    <IfModule !lookup_identity_module>
        LoadModule lookup_identity_module modules/mod_lookup_identity.so
    </IfModule>
    
    WSGIScriptAlias /login /var/www/app/login.py
    WSGIScriptAlias /app /var/www/app/protected.py
    
    <Location "/app">
        NSSVerifyClient require
        NSSUserName SSL_CLIENT_CERT
        LookupUserByCertificate On
        LookupUserByCertificateParamName "username"
    </Location>
    이 파일에서는 다음을 수행합니다.
    • 첫 번째 부분은 mod_lookup_identity 가 아직 로드되지 않은 경우 로드합니다.
    • 다음 부분에서는 /login/app 엔드가 해당 WSGI(Web Server Gateway Interface) 스크립트를 가리킵니다.
    • 마지막 부분에서는 TLS 핸드셰이크 중에 클라이언트 인증서가 필요하므로 /app 엔드 포인트에 대해 mod_nss 를 구성합니다. 또한 사용자의 ID를 조회하기 위해 선택적 요청 매개변수 사용자 이름을 구성합니다.

23.8. KDC에서 티켓 획득 시 특정 인증 ID 적용

특정 인증 지표를 적용하려면 다음을 수행합니다.
  • 호스트 오브젝트는 다음을 실행합니다.
    # ipa host-mod host_name --auth-ind=indicator
  • Kerberos 서비스는 다음을 실행합니다.
    # ipa service-mod service/host_name --auth-ind=indicator
여러 인증 지표를 설정하려면 --auth-ind 매개변수를 여러 번 지정합니다.
주의
HTTP/IdM_master 서비스에 인증 표시기를 설정하면 IdM 마스터가 실패합니다. 또한 IdM에서 제공하는 유틸리티에서는 마스터를 복원할 수 없습니다.

예 23.2. 특정 호스트에서 pkinit Indicator 실행

다음 명령은 스마트 카드를 통해 인증된 사용자만 host.idm.example.com 호스트의 서비스 티켓을 얻을 수 있도록 구성합니다.
# ipa host-mod host.idm.example.com --auth-ind=pkinit
위의 설정은 Kerberos 티켓을 요청하는 사용자의 TGT( ticket-granting ticket)에 pkinit 인증 표시기가 포함되어 있는지 확인합니다.

24장. 사용자, 호스트 및 서비스를 위한 인증서 관리

IdM(Identity Management)은 두 가지 유형의 CA(인증 기관)를 지원합니다.
통합 IdM CA
통합 CA는 사용자, 호스트 및 서비스에 대한 인증서를 생성, 취소 및 발급할 수 있습니다. 자세한 내용은 24.1절. “통합 IdM CA로 인증서 관리” 의 내용을 참조하십시오.
IdM은 경량의 하위 CA 생성을 지원합니다. 자세한 내용은 을 참조하십시오. 26.1절. “경량의 서브 CA”
외부 CA
외부 CA는 통합 IdM CA가 아닌 CA입니다.
IdM 도구를 사용하여 이러한 CA에서 발급한 인증서를 사용자, 서비스 또는 호스트에 추가하고 제거합니다. 자세한 내용은 24.2절. “외부 CA에서 발급한 인증서 관리” 의 내용을 참조하십시오.
각 사용자, 호스트 또는 서비스에는 여러 개의 인증서가 할당될 수 있습니다.
참고
IdM 서버의 지원되는 CA 구성에 대한 자세한 내용은 2.3.2절. “사용할 CA 구성 결정” 을 참조하십시오.

24.1. 통합 IdM CA로 인증서 관리

24.1.1. 사용자, 호스트 또는 서비스에 대한 새 인증서 요청

다음을 사용하여 인증서를 요청하려면 다음을 수행합니다.
타사 도구를 사용하여 인증서 요청 자체를 생성해야 합니다. 다음 절차에서는 certutilopenSSL 유틸리티를 사용합니다.
중요
서비스는 일반적으로 개인 키가 저장되는 전용 서비스 노드에서 실행됩니다. 서비스의 개인 키를 IdM 서버에 복사하는 것은 안전하지 않은 것으로 간주됩니다. 따라서 서비스 인증서를 요청할 때 서비스 노드에 CSR을 생성합니다.

웹 UI: 새 인증서 요청

  1. Identity (ID) 탭에서 Users (사용자),Hosts, Services (서비스)를 선택합니다.
  2. 사용자, 호스트 또는 서비스의 이름을 클릭하여 구성 페이지를 엽니다.

    그림 24.1. 호스트 목록

    호스트 목록
  3. ActionsNew Certificate 를 클릭합니다.
  4. 선택 사항: 발행 CA 및 프로필 ID를 선택합니다.
  5. certutil 을 사용하도록 화면의 지침을 따르십시오.
  6. Issue 를 클릭합니다.

명령줄: 새 인증서 요청

표준 상황에서 certutil 을 사용하여 새 인증서를 요청합니다. 24.1.1.1절. “certutil을 사용하여 새 인증서 요청” 을 참조하십시오. 호스트 또는 서비스 인증서를 사용하도록 Kerberos 별칭을 활성화하려면 openSSL 을 사용하여 새 인증서를 요청합니다. 24.1.1.2절. “OpenSSL을 사용하여 여러 SAN 필드를 사용하여 인증서 요청 준비”.

24.1.1.1. certutil을 사용하여 새 인증서 요청

  1. 인증서 데이터베이스에 대한 임시 디렉터리를 생성합니다.
    # mkdir ~/certdb/
  2. 임시 인증서 데이터베이스를 새로 생성합니다. 예를 들면 다음과 같습니다.
    # certutil -N -d ~/certdb/
  3. CSR(인증서 서명 요청)을 생성하고 출력을 파일로 리디렉션합니다. 예를 들어 4096비트 인증서에 대한 CSR을 생성하고 CN=server.example.com,O=EXAMPLE.COM의 주체를 설정하려면 다음을 수행합니다.
    # certutil -R -d ~/certdb/ -a -g 4096 -s "CN=server.example.com,O=EXAMPLE.COM" -8 server.example.com > certificate_request.csr
  4. 인증서 요청을 CA에 제출합니다. 자세한 내용은 24.1.1.4절. “IdM CA에 인증서 요청 제출” 의 내용을 참조하십시오.

24.1.1.2. OpenSSL을 사용하여 여러 SAN 필드를 사용하여 인증서 요청 준비

  1. Kerberos 주체 test / server.example.com에 대한test1/server.example.com, test2/server.example.com 등 하나 이상의 별칭을 만듭니다. 자세한 내용은 20.2.1절. “Kerberos 기본 별칭”를 참조하십시오.
  2. CSR에서 dnsName(server.example.com) 및 otherName(test2/server.example.com)에 subjectAltName을 추가합니다. 이렇게 하려면 UPN otherName 및 subjectAltName을 지정하는 다음 행을 포함하도록 openssl.conf 파일을 구성합니다.
    otherName=1.3.6.1.4.1.311.20.2.3;UTF8:test2/server.example.com@EXAMPLE.COM
    DNS.1 = server.example.com
  3. openssl 을 사용하여 인증서 요청을 생성합니다.
    openssl req -new -newkey rsa:2048 -keyout test2service.key -sha256 -nodes -out certificate_request.csr -config openssl.conf
  4. 인증서 요청을 CA에 제출합니다. 자세한 내용은 24.1.1.4절. “IdM CA에 인증서 요청 제출” 의 내용을 참조하십시오.

24.1.1.3. Certmonger를 사용하여 새 인증서 요청

certmonger 서비스를 사용하여 IdM CA에서 인증서를 요청할 수 있습니다. 자세한 내용은 시스템 수준 인증 가이드의 SCEP를 통해 CA 서명 인증서 요청 섹션을 참조하십시오.

24.1.1.4. IdM CA에 인증서 요청 제출

IdM 서버에서 실행 중인 CA에 인증서 요청 파일을 제출합니다. 새로 발행된 인증서와 연결할 Kerberos 주체를 지정해야 합니다.
# ipa cert-request certificate_request.csr --principal=host/server.example.com
IdM의 ipa cert-request 명령은 다음 기본값을 사용합니다.
  • 인증서 프로필: caIPAserviceCert
    사용자 지정 프로필을 선택하려면 ipa cert-request 명령과 함께 --profile-id 옵션을 사용합니다.
    사용자 정의 인증서 프로파일 생성에 대한 자세한 내용은 24.4.1절. “인증서 프로파일 생성” 을 참조하십시오.
  • 통합 CA: ipa (IdM 루트 CA)
    하위 CA를 선택하려면 ipa cert-request 명령과 함께 --ca 옵션을 사용합니다.
자세한 내용은 ipa cert-request --help 명령의 출력을 참조하십시오.

24.1.2. 통합 IdM CA로 인증서 박탈

만료일 전에 인증서를 무효화해야 하는 경우 해지할 수 있습니다. 다음을 사용하여 인증서를 취소하려면 다음을 수행합니다.
취소된 인증서가 유효하지 않으며 인증에 사용할 수 없습니다. 모든 취소는 6 이유를 제외하고 영구적입니다. 자격증 보유.

표 24.1. 취소 이유

ID 이유 설명
0 지정되지 않음
1 키 Compromized
인증서를 발급한 키는 더 이상 신뢰할 수 없습니다.
가능한 원인: 토큰이 잘못 액세스되어 파일에 잘못 액세스됨.
2 CA Compromized 인증서를 발급한 CA는 더 이상 신뢰할 수 없습니다.
3 제휴가 변경되었습니다
가능한 원인:
  • 직원이 퇴사했거나 다른 부서로 이동했습니다.
  • 호스트 또는 서비스가 폐기 중입니다.
4 대체 최신 인증서는 현재 인증서를 교체했습니다.
5 작업 중단 호스트 또는 서비스가 해제되고 있습니다.
6 인증서 저장 인증서가 일시적으로 취소됩니다. 나중에 인증서를 복원할 수 있습니다.
8 CRL에서 삭제 인증서가 CRL(인증서 폐기 목록)에 포함되지 않습니다.
9 권한 상승 사용자, 호스트 또는 서비스는 더 이상 인증서를 사용할 수 없습니다.
10 attribute Authority (AA) Compromise AA 인증서는 더 이상 신뢰할 수 없습니다.

웹 UI: 인증서 박탈

인증서를 취소하려면 다음을 수행합니다.
  1. Authentication 탭을 열고 10.0.0.1을 선택합니다.
  2. 인증서의 일련 번호를 클릭하여 인증서 정보 페이지를 엽니다.

    그림 24.2. 인증서 목록

    인증서 목록
  3. 작업Revoke Certificate 를 클릭합니다.
  4. 취소 이유를 선택하고 Revoke 를 클릭합니다. 자세한 내용은 표 24.1. “취소 이유” 을 참조하십시오.

명령줄: 인증서 박탈

ipa cert-revoke 명령을 사용하고 다음을 지정합니다.
  • 인증서 일련 번호
  • 취소 이유를 식별하는 숫자입니다. 자세한 내용은 표 24.1. “취소 이유” 에서 참조하십시오.
예를 들어 일련 번호가 1032 인 인증서를 취소하려면 1번 이유 때문입니다. 주요 구성:
$ ipa cert-revoke 1032 --revocation-reason=1

24.1.3. 통합 IdM CA로 인증서 복원

이유 6 때문에 인증서를 취소한 경우: 인증서 유지, 다시 복구할 수 있습니다. 다음을 사용하여 인증서를 복원하려면 다음을 수행합니다.

웹 UI: 인증서 복원

  1. Authentication 탭을 열고 10.0.0.1을 선택합니다.
  2. 인증서의 일련 번호를 클릭하여 인증서 정보 페이지를 엽니다.

    그림 24.3. 인증서 목록

    인증서 목록
  3. 작업복원 인증서를 클릭합니다.

명령줄: 인증서 복원

ipa cert-remove-hold 명령을 사용하고 인증서 일련 번호를 지정합니다. 예를 들어 다음과 같습니다.
$ ipa cert-remove-hold 1032

24.2. 외부 CA에서 발급한 인증서 관리

24.2.1. 명령줄: 외부 CA에서 발급한 인증서 추가 및 제거

사용자, 호스트 또는 서비스에 인증서를 추가하려면 다음을 수행합니다.
  • ipa user-add-cert
  • ipa host-add-cert
  • ipa service-add-cert
사용자, 호스트 또는 서비스에서 인증서를 제거하려면 다음을 수행합니다.
  • ipa user-remove-cert
  • ipa host-remove-cert
  • ipa service-remove-cert
IdM에서 제거한 후 외부 CA에서 발급한 인증서는 취소되지 않습니다. 인증서가 IdM CA 데이터베이스에 없기 때문입니다. 이러한 인증서는 외부 CA 측에서만 수동으로 취소할 수 있습니다.
명령에는 다음 정보를 지정해야 합니다.
  • 사용자, 호스트 또는 서비스의 이름
  • Base64로 인코딩된 DER 인증서
명령을 대화식으로 실행하려면 옵션을 추가하지 않고 실행합니다.
명령과 함께 필요한 정보를 직접 제공하려면 명령줄 인수 및 옵션을 사용합니다.
$ ipa user-add-cert user --certificate=MIQTPrajQAwg...
참고
인증서 내용을 명령줄에 복사하여 붙여넣는 대신 인증서를 DER 형식으로 변환한 다음 base64로 다시 코딩할 수 있습니다. 예를 들어 user_cert.pem 인증서를 사용자에게 추가하려면 다음을 수행합니다.
$ ipa user-add-cert user --certificate="$(openssl x509 -outform der -in user_cert.pem | base64 -w 0)"

24.2.2. 웹 UI: 외부 CA에서 발급한 인증서 추가 및 제거

사용자, 호스트 또는 서비스에 인증서를 추가하려면 다음을 수행합니다.
  1. ID 탭을 열고 사용자,호스트 또는 서비스를 선택합니다.
  2. 사용자, 호스트 또는 서비스의 이름을 클릭하여 구성 페이지를 엽니다.
  3. certificate 항목 옆에 있는 Add 클릭합니다.

    그림 24.4. 사용자 계정에 인증서 추가

    사용자 계정에 인증서 추가
  4. Base64 또는 PEM 인코딩 형식으로 인증서를 텍스트 필드에 붙여넣고 추가 를 클릭합니다.
  5. 저장 을 클릭하여 변경 사항을 저장합니다.
사용자, 호스트 또는 서비스에서 인증서를 제거하려면 다음을 수행합니다.
  1. ID 탭을 열고 사용자,호스트 또는 서비스를 선택합니다.
  2. 사용자, 호스트 또는 서비스의 이름을 클릭하여 구성 페이지를 엽니다.
  3. 삭제할 인증서 옆에 있는 작업을 클릭하고 삭제를 선택합니다.
  4. 저장 을 클릭하여 변경 사항을 저장합니다.

24.3. 인증서 나열 및 표시

웹 UI에서 인증서 나열 및 표시

사용자, 호스트 또는 서비스 항목에 할당된 인증서를 나열하려면 다음을 수행합니다.
  1. ID 탭을 열고 사용자,호스트 또는 서비스를 선택합니다.
  2. 사용자, 호스트 또는 서비스의 이름을 클릭하여 구성 페이지를 엽니다.

    그림 24.5. 호스트 목록

    호스트 목록
  3. 구성 페이지에는 항목에 할당된 모든 인증서가 나열됩니다. 또한 Show 를 클릭하면 특정 인증서가 표시됩니다.
IdM 서버에 등록된 모든 인증서를 나열하려면 다음을 수행합니다.
  1. Authentication 탭을 열고 10.0.0.1을 선택합니다.
  2. 모든 인증서 목록이Unhealthy 섹션에 표시됩니다. 특정 인증서를 표시하려면 일련 번호를 클릭합니다.

    그림 24.6. 인증서 목록

    인증서 목록

명령줄에서 인증서 나열

IdM 데이터베이스의 모든 인증서를 나열하려면 ipa cert-find 명령을 실행합니다.
$ ipa cert-find
-----------------------
10 certificates matched
-----------------------
  Serial number (hex): 0x1
  Serial number: 1
  Status: VALID
  Subject: CN=Certificate Authority,O=EXAMPLE.COM
...
-----------------------------
Number of entries returned 10
-----------------------------
발급 날짜 또는 유효일과 같은 특정 인증서 속성을 지정하여 검색 결과를 필터링할 수 있습니다. 예를 들어 문제 날짜 간격으로 검색하려면 --issuedon-from 또는 --issuedon-to 옵션을 사용하여 시작 및 엔드포인트 또는 기간을 지정합니다.
ipa cert-find --issuedon-from=2020-01-07 --issuedon-to=2020-02-07
인증서 검색을 필터링하는 데 사용되는 전체 옵션 목록은 --help 옵션이 추가된 ipa cert-find 를 실행합니다.

명령줄에서 인증서 표시

인증서를 표시하려면 ipa cert-show 명령을 사용하고 일련 번호를 지정합니다.
$ ipa cert-show 132
Serial number: 132
  Certificate: MIIDtzCCAp+gAwIBAgIBATANBgkqhkiG9w0BAQsFADBBMR8wHQYDVQQKExZMQUIu
...
LxIQjrEFtJmoBGb/TWRlwGEWy1ayr4iTEf1ayZ+RGNylLalEAtk9RLjEjg==
  Subject: CN=Certificate Authority,O=EXAMPLE.COM
  Issuer: CN=Certificate Authority,O=EXAMPLE.COM
  Not Before: Sun Jun 08 05:51:11 2014 UTC
  Not After: Thu Jun 08 05:51:11 2034 UTC
  Serial number (hex): 0x132
  Serial number: 132
사용자, 호스트 또는 서비스 항목에 할당된 인증서를 표시하려면 ipa cert-show 를 사용하고 항목을 지정합니다. 예를 들어 사용자에게 할당된 인증서를 표시하려면 다음을 수행합니다.
$ ipa user-show user
  User login: user
  ...
  Certificate: MIICfzCCAWcCAQA...
  ...
cert-show를 ipa--out 옵션을 추가하여 파일에 인증서를 저장할 수도 있습니다.
$ ipa cert-show certificate_serial_number --out=path_to_file
사용자, 호스트 또는 서비스에 둘 이상의 인증서가 있는 경우 --out 옵션은 모든 인증서를 내보냅니다. 인증서 또는 인증서는 PEM 오브젝트로 내보냅니다.

24.4. 인증서 프로필

인증서 프로필은 특정 프로필에 속하는 인증서의 내용과 등록을 위한 인증서, 등록 방법, 입력 및 출력 양식을 발행하기 위한 제약 조건을 정의합니다. 단일 인증서 프로필은 특정 유형의 인증서를 발행하는 것과 연결되어 있습니다. IdM의 사용자, 서비스 및 호스트에 대해 다양한 인증서 프로필을 정의할 수 있습니다.
CA는 인증서 서명에 인증서 프로필을 사용하여 다음을 결정합니다.
  • CA에서 CSR(인증서 서명 요청)을 수락할 수 있는지 여부
  • 인증서에 존재하는 기능 및 확장 기능
IdM에는 기본적으로 caIPAserviceCert 및ECDHE UserRoles 의 두 개의 인증서 프로필이 포함되어 있습니다. 사용자 지정 프로필도 가져올 수 있습니다.
사용자 지정 인증서 프로필을 사용하면 관련이 없는 특정 목적에 대한 인증서를 발급할 수 있습니다. 예를 들어 특정 프로필의 사용을 하나의 사용자 또는 한 그룹으로만 제한하여 다른 사용자와 그룹이 해당 프로필을 사용하여 인증을 위해 인증서를 발행하지 못하게 할 수 있습니다.
지원되는 인증서 프로파일 구성에 대한 자세한 내용은 Red Hat Certificate System 관리 가이드의 기본값 참조 및 제약 조건 참조를 참조하십시오.
참고
인증 프로필과 CA ACL을 결합하여 관리자가 사용자 정의 인증서 프로필에 대한 액세스를 정의하고 제어할 수 있습니다. 24.5절. “인증 기관 ACL 규칙” 프로필 및 CA ACL을 사용하여 사용자 인증서를 발급하는 방법에 대한 설명은 24.6절. “IdM CA에서 사용자 인증서 발급에 인증서 프로필과 ACL 사용” 을 참조하십시오.

24.4.1. 인증서 프로파일 생성

인증서 프로파일 생성에 대한 자세한 내용은 Red Hat Certificate System 9 관리 가이드에서 다음 문서를 참조하십시오.

24.4.2. 명령줄에서 인증서 프로필 관리

IdM 프로필 관리를 위한 certprofile 플러그인을 사용하면 권한 있는 사용자가 IdM 인증서 프로필을 가져오고, 수정하거나 제거할 수 있습니다. 플러그인에서 지원하는 모든 명령을 표시하려면 ipa certprofile 명령을 실행합니다.
$ ipa certprofile
Manage Certificate Profiles

...

EXAMPLES:

  Import a profile that will not store issued certificates:
    ipa certprofile-import ShortLivedUserCert \
      --file UserCert.profile --desc "User Certificates" \
      --store=false

  Delete a certificate profile:
    ipa certprofile-del ShortLivedUserCert
...
certprofile 작업을 수행하려면 필요한 권한이 있는 사용자로 작동해야 합니다. IdM에는 기본적으로 다음 인증서 프로필 관련 권한이 포함됩니다.
시스템: 인증서 프로필 읽기
사용자가 모든 프로필 속성을 읽을 수 있습니다.
시스템: 인증서 프로파일 가져 오기
사용자가 인증서 프로필을 IdM로 가져올 수 있습니다.
시스템: 인증서 프로파일 삭제
사용자가 기존 인증서 프로필을 삭제할 수 있습니다.
시스템: 인증서 프로파일 수정
사용자가 프로필 속성을 수정하고 프로필을 비활성화하거나 활성화할 수 있습니다.
이러한 권한은 모두 기본 CA 관리자 권한에 포함됩니다. IdM 역할 기반 액세스 제어 및 권한 관리에 대한 자세한 내용은 10.4절. “역할 기반 액세스 제어 정의” 을 참조하십시오.
참고
인증서를 요청할 때 ipa cert-request 명령에 --profile-id 옵션을 추가하여 사용할 프로필을 지정할 수 있습니다. 프로필 ID를 지정하지 않으면 인증서에 기본 caIPAserviceCert 프로필이 사용됩니다.
이 섹션에서는 프로필 관리에 ipa certprofile 명령을 사용하는 가장 중요한 측면만 설명합니다. 명령에 대한 전체 정보를 보려면 추가된 --help 옵션을 사용하여 이를 실행합니다. 예를 들면 다음과 같습니다.
$ ipa certprofile-mod --help
Usage: ipa [global-options] certprofile-mod ID [options]

Modify Certificate Profile configuration.
Options:
  -h, --help     show this help message and exit
  --desc=STR     Brief description of this profile
  --store=BOOL   Whether to store certs issued using this profile
...

인증서 프로필 가져오기

새 인증서 프로필을 IdM으로 가져오려면 ipa certprofile-import 명령을 사용합니다. 옵션 없이 명령을 실행하면 certprofile-import 스크립트가 인증서를 가져오는 데 필요한 정보를 묻는 대화형 세션이 시작됩니다.
$ ipa certprofile-import

Profile ID: smime
Profile description: S/MIME certificates
Store issued certificates [True]: TRUE
Filename of a raw profile. The XML format is not supported.: smime.cfg
------------------------
Imported profile "smime"
------------------------
  Profile ID: smime
  Profile description: S/MIME certificates
  Store issued certificates: TRUE
ipa certprofile-import 명령은 여러 명령줄 옵션을 허용합니다. 가장 중요한 것은 다음과 같습니다.
--file
이 옵션은 프로필 구성이 포함된 파일을 ipa certprofile-import 로 직접 전달합니다. 예를 들어 다음과 같습니다.
$ ipa certprofile-import --file=smime.cfg
--store
이 옵션은 Store issued certificates 속성을 설정합니다. 두 개의 값을 허용합니다.
  • True: 발행된 인증서를 클라이언트에 전달하여 대상 IdM 주체의 userCertificate 속성에 저장합니다.
  • 발행 된 인증서를 클라이언트에 제공하지만 IdM에 저장하지 않는 false입니다. 이 옵션은 여러 개의 단기 인증서를 발급해야 할 때 가장 일반적으로 사용됩니다.
ipa certprofile-import 로 지정된 프로필 ID가 이미 사용 중이거나 프로필 콘텐츠가 잘못된 경우 가져오기에 실패합니다. 예를 들어 필수 속성이 없거나 제공된 파일에 정의된 프로필 ID 값이 ipa certprofile-import 로 지정된 프로필 ID와 일치하지 않는 경우 가져오기가 실패합니다.
새 프로필에 대한 템플릿을 얻으려면 지정된 기존 프로필을 파일로 내보내는 --out 옵션과 함께 ipa certprofile-show 명령을 실행할 수 있습니다. 예를 들어 다음과 같습니다.
$ ipa certprofile-show caIPAserviceCert --out=file_name
그런 다음 필요에 따라 내보낸 파일을 편집하고 새 프로필로 가져올 수 있습니다.

인증서 프로필 표시

IdM에 현재 저장된 모든 인증서 프로필을 표시하려면 ipa certprofile-find 명령을 사용합니다.
$ ipa certprofile-find
------------------
3 profiles matched
------------------
  Profile ID: caIPAserviceCert
  Profile description: Standard profile for network services
  Store issued certificates: TRUE

  Profile ID: IECUserRoles
...
특정 프로필에 대한 정보를 표시하려면 ipa certprofile-show 명령을 사용합니다.
$ ipa certprofile-show profile_ID
  Profile ID: profile_ID
  Profile description: S/MIME certificates
  Store issued certificates: TRUE

인증서 프로파일 수정

기존 인증서 프로필을 수정하려면 ipa certprofile-mod 명령을 사용합니다. ipa certprofile-mod 에서 허용하는 명령줄 옵션을 사용하여 명령으로 필요한 수정 사항을 전달합니다. 예를 들어 프로필 설명을 수정하고 IdM이 발급한 인증서를 저장하는지 여부를 변경하려면 다음을 수행합니다.
$ ipa certprofile-mod profile_ID --desc="New description" --store=False
------------------------------------
Modified Certificate Profile "profile_ID"
------------------------------------
  Profile ID: profile_ID
  Profile description: New description
  Store issued certificates: FALSE
인증서 프로필 구성을 업데이트하려면 --file 옵션을 사용하여 업데이트된 구성이 포함된 파일을 가져옵니다. 예를 들어 다음과 같습니다.
$ ipa certprofile-mod profile_ID --file=new_configuration.cfg

인증서 프로파일 삭제

IdM에서 기존 인증서 프로필을 제거하려면 ipa certprofile-del 명령을 사용합니다.
$ ipa certprofile-del profile_ID
-----------------------
Deleted profile "profile_ID"
-----------------------

24.4.3. 웹 UI에서 인증서 프로파일 관리

IdM 웹 UI에서 인증서 프로필을 관리하려면 다음을 수행합니다.
  1. Authentication 탭과 10.0.0.1 엽니다.
  2. 인증서 프로필 섹션을 엽니다.

    그림 24.7. 웹 UI의 인증서 프로필 관리

    웹 UI의 인증서 프로필 관리
인증서 프로필 섹션에서 기존 프로필에 대한 정보를 표시하거나 해당 특성을 수정하거나 선택한 프로필을 삭제할 수 있습니다.
예를 들어 기존 인증서 프로필을 수정하려면 다음을 수행합니다.
  1. 프로필 이름을 클릭하여 프로필 구성 페이지를 엽니다.
  2. 프로필 구성 페이지에서 필요한 정보를 입력합니다.
  3. 저장 을 클릭하여 새 구성을 확인합니다.

    그림 24.8. 웹 UI에서 인증서 프로파일 수정

    웹 UI에서 인증서 프로파일 수정
Store가 발행한 인증서 옵션을 활성화하면 발급된 인증서가 클라이언트에 전달되고 대상 IdM 주체의 userCertificate 속성에 저장됩니다. 옵션을 비활성화하면 발급된 인증서가 클라이언트에 전달되지만 IdM에는 저장되지 않습니다. 여러 개의 수명이 짧은 인증서를 발급해야 하는 경우 인증서 저장이 종종 비활성화됩니다.
현재 웹 UI에서 일부 인증서 프로필 관리 작업을 사용할 수 없습니다.
  • 웹 UI에서 인증서 프로필을 가져올 수 없습니다. 인증서를 가져오려면 ipa certprofile-import 명령을 사용합니다.
  • 특성 및 값 쌍을 설정, 추가 또는 삭제할 수 없습니다. 속성 및 값 쌍을 수정하려면 ipa certprofile-mod 명령을 사용합니다.
  • 업데이트된 인증서 프로필 구성을 가져올 수 없습니다. 업데이트된 프로필 구성이 포함된 파일을 가져오려면 ipa certprofile-mod --file=file_name 명령을 사용합니다.
인증서 프로필 관리에 사용되는 명령에 대한 자세한 내용은 24.4.2절. “명령줄에서 인증서 프로필 관리” 을 참조하십시오.

24.4.4. 인증서 프로필을 사용하여 IdM 서버 업그레이드

IdM 서버를 업그레이드할 때 서버에 포함된 프로필을 모두 가져와서 활성화할 수 있습니다.
여러 서버 복제본을 업그레이드하는 경우 첫 번째 업그레이드된 복제본의 프로필을 가져옵니다. 다른 복제본에서 IdM은 다른 프로필의 존재를 감지하고 두 프로필 세트 간의 충돌을 해결하지 않습니다. 복제본에 사용자 지정 프로필이 정의되어 있는 경우 업그레이드하기 전에 모든 복제본의 프로필이 일관적인지 확인합니다.

24.5. 인증 기관 ACL 규칙

CA ACL(인증 기관 액세스 제어 목록) 규칙은 어떤 사용자, 서비스 또는 호스트에 대한 인증서를 발급하는 데 사용할 수 있는 프로필을 정의합니다. 프로필, 주체 및 그룹을 연결하면 CA ACL에서 주체 또는 그룹이 특정 프로필을 사용하여 인증서를 요청할 수 있습니다.
  • ACL은 여러 프로필에 대한 액세스를 허용할 수 있습니다.
  • ACL에는 연결된 여러 사용자, 서비스, 호스트, 사용자 그룹 및 호스트 그룹이 있을 수 있습니다.
예를 들어 관리자는 CA ACL을 사용하여 런던에 위치한 사무실에서 작업하는 직원을 런던 사무소 관련 그룹의 구성원으로만 사용하도록 제한할 수 있습니다.
참고
관리자는 24.4절. “인증서 프로필” 및 CA ACL에 설명된 인증서 프로필을 결합하여 사용자 정의 인증서 프로필에 대한 액세스를 정의하고 제어할 수 있습니다. 프로필 및 CA ACL을 사용하여 사용자 인증서를 발급하는 방법에 대한 설명은 24.6절. “IdM CA에서 사용자 인증서 발급에 인증서 프로필과 ACL 사용” 을 참조하십시오.

24.5.1. 명령줄에서 CA ACL 관리

CA ACL 규칙 관리를 위한 caacl 플러그인을 사용하면 권한 있는 사용자가 지정된 CA ACL을 추가, 표시, 수정 또는 삭제할 수 있습니다. 플러그인에서 지원하는 모든 명령을 표시하려면 ipa caacl 명령을 실행합니다.
$ ipa caacl
Manage CA ACL rules.

...

EXAMPLES:

  Create a CA ACL "test" that grants all users access to the
  "UserCert" profile:
    ipa caacl-add test --usercat=all
    ipa caacl-add-profile test --certprofiles UserCert

  Display the properties of a named CA ACL:
    ipa caacl-show test

  Create a CA ACL to let user "alice" use the "DNP3" profile on "DNP3-CA":
    ipa caacl-add alice_dnp3
    ipa caacl-add-ca alice_dnp3 --cas DNP3-CA
    ipa caacl-add-profile alice_dnp3 --certprofiles DNP3
    ipa caacl-add-user alice_dnp3 --user=alice
...
caacl 작업을 수행하려면 필요한 권한이 있는 사용자로 작동해야 합니다. IdM에는 기본적으로 다음 CA ACL 관련 권한이 포함됩니다.
시스템: CA ACL 읽기
사용자가 CA ACL의 모든 속성을 읽을 수 있습니다.
시스템: CA ACL 추가
사용자가 새 CA ACL을 추가할 수 있습니다.
시스템: CA ACL 삭제
사용자가 기존 CA ACL을 삭제할 수 있습니다.
시스템: CA ACL 수정
사용자가 CA ACL의 속성을 수정하고 CA ACL을 비활성화 또는 활성화하도록 활성화합니다.
시스템: CA ACL 멤버십 관리
사용자가 CA ACL의 CA, 프로필, 사용자, 호스트 및 서비스 멤버십을 관리할 수 있습니다.
이러한 권한은 모두 기본 CA 관리자 권한에 포함됩니다. IdM 역할 기반 액세스 제어 및 권한 관리에 대한 자세한 내용은 10.4절. “역할 기반 액세스 제어 정의” 을 참조하십시오.
이 섹션에서는 CA ACL 관리에 ipa caacl 명령 사용의 가장 중요한 측면만 설명합니다. 명령에 대한 전체 정보를 보려면 추가된 --help 옵션을 사용하여 이를 실행합니다. 예를 들면 다음과 같습니다.
$ ipa caacl-mod --help
Usage: ipa [global-options] caacl-mod NAME [options]

Modify a CA ACL.
Options:
  -h, --help            show this help message and exit
  --desc=STR            Description
  --cacat=['all']       CA category the ACL applies to
  --profilecat=['all']  Profile category the ACL applies to
...

CA ACL 생성

새 CA ACL을 생성하려면 ipa caacl-add 명령을 사용합니다. 옵션 없이 명령을 실행하면 ipa caacl-add 스크립트에서 새 CA ACL에 대한 필수 정보를 묻는 대화형 세션이 시작됩니다.
$ ipa caacl-add
ACL name: smime_acl
------------------------
Added CA ACL "smime_acl"
------------------------
  ACL name: smime_acl
  Enabled: TRUE
새 CA ACL은 기본적으로 활성화되어 있습니다.
ipa caacl-add 에서 허용하는 가장 주목할 만한 옵션은 CA ACL을 CA, 인증서 프로파일, 사용자, 호스트 또는 서비스 카테고리와 연결하는 옵션입니다.
  • --cacat
  • --profilecat
  • --usercat
  • --hostcat
  • --servicecat
IdM은 모든 CA, 프로필, 사용자, 호스트 또는 서비스와 CA ACL을 연결하는 모든 옵션과 모든 값만 허용합니다. 예를 들어, CA ACL을 모든 사용자 및 사용자 그룹과 연결하려면 다음을 수행합니다.
$ ipa caacl-add ca_acl_name --usercat=all
CA, 프로필, 사용자, 호스트 및 서비스 카테고리는 특정 오브젝트 또는 오브젝트 그룹을 CA ACL에 추가하는 대신, “CA ACL에 항목 추가 및 CA ACL에서 항목 제거” 에 설명되어 있습니다. 카테고리를 사용하고 동일한 유형의 오브젝트 또는 그룹도 추가할 수 없습니다. 예를 들어 --usercat=all 옵션을 사용한 다음 ipa caacl-add-user --users=user_name 명령을 사용하여 CA ACL에 사용자를 추가할 수 없습니다.
참고
사용자 또는 그룹이 해당 CA ACL에 추가되지 않은 경우 인증서 프로필을 사용하여 사용자 또는 그룹에 대한 인증서를 요청하지 않습니다. 예를 들어 다음과 같습니다.
$ ipa cert-request CSR-FILE --principal user --profile-id profile_id
ipa: ERROR Insufficient access: Principal 'user' is not permitted to use CA '.' with profile 'profile_id' for certificate issuance.
“CA ACL에 항목 추가 및 CA ACL에서 항목 제거” 에 설명된 대로 CA ACL에 사용자 또는 그룹을 추가하거나 CA ACL을 all 사용자 카테고리와 연결해야 합니다.

CA ACL 표시

모든 CA ACL을 표시하려면 ipa caacl-find 명령을 사용합니다.
$ ipa caacl-find
-----------------
2 CA ACLs matched
-----------------
  ACL name: hosts_services_caIPAserviceCert
  Enabled: TRUE
...
ipa caacl-find--cacat,--profilecat,--usercat,--hostcat, --servicecat 옵션을 허용합니다. 이 옵션은 해당 CA, 인증서 프로필, 사용자, 호스트 또는 서비스 카테고리로 검색 결과를 CA ACL로 필터링할 수 있습니다. IdM은 이러한 옵션이 있는 모든 카테고리만 허용합니다. 옵션에 대한 자세한 내용은 “CA ACL 생성” 을 참조하십시오.
특정 CA ACL에 대한 정보를 표시하려면 ipa caacl-show 명령을 사용합니다.
$ ipa caacl-show ca_acl_name
  ACL name: ca_acl_name
  Enabled: TRUE
  Host category: all
...

CA ACL 수정

기존 CA ACL을 수정하려면 ipa caacl-mod 명령을 사용합니다. ipa caacl-mod 에서 허용하는 명령줄 옵션을 사용하여 필요한 수정 사항을 전달합니다. 예를 들어 CA ACL에 대한 설명을 수정하고 CA ACL을 모든 인증서 프로필과 연결하려면 다음을 수행합니다.
$ ipa caacl-mod ca_acl_name --desc="New description" --profilecat=all
---------------------------
Modified CA ACL "ca_acl_name"
---------------------------
  ACL name: smime_acl
  Description: New description
  Enabled: TRUE
  Profile category: all
ipa caacl-mod 에서 허용되는 가장 주목할 만한 옵션은 --cacat,--profilecat,--usercat,--hostcat, --servicecat 옵션입니다. 이러한 옵션에 대한 자세한 내용은 “CA ACL 생성” 을 참조하십시오.

CA ACL 비활성화 및 활성화

CA ACL을 비활성화하려면 ipa caacl-disable 명령을 사용합니다.
$ ipa caacl-disable ca_acl_name
---------------------------
Disabled CA ACL "ca_acl_name"
---------------------------
비활성화된 CA ACL은 적용되지 않으며 인증서를 요청하는 데 사용할 수 없습니다. CA ACL을 비활성화해도 IdM에서 제거되지 않습니다.
비활성화된 CA ACL을 활성화하려면 ipa caacl-enable 명령을 사용합니다.
$ ipa caacl-enable ca_acl_name
---------------------------
Enabled CA ACL "ca_acl_name"
---------------------------

CA ACL 삭제

기존 CA ACL을 제거하려면 ipa caacl-del 명령을 사용합니다.
$ ipa caacl-del ca_acl_name

CA ACL에 항목 추가 및 CA ACL에서 항목 제거

ipa caacl-add-*ipa caacl-remove-* 명령을 사용하면 CA ACL에 새 항목을 추가하거나 기존 항목을 제거할 수 있습니다.
IPA caacl-add-caipa caacl-remove-ca
CA를 추가하거나 제거합니다.
IPA caacl-add-hostipa caacl-remove-host
호스트 또는 호스트 그룹을 추가하거나 제거합니다.
IPA caacl-add-profileipa caacl-remove-profile
프로필을 추가하거나 제거합니다.
IPA caacl-add-serviceipa caacl-remove-service
서비스를 추가하거나 제거합니다.
IPA caacl-add-useripa caacl-remove-user
사용자 또는 그룹을 추가하거나 제거합니다.
예를 들어 다음과 같습니다.
$ ipa caacl-add-user ca_acl_name --groups=group_name
오브젝트 또는 오브젝트 그룹을 CA ACL에 추가할 수 없으며 “CA ACL 생성” 에 설명된 동일한 오브젝트 범주도 사용할 수 없습니다. 이러한 설정은 상호 배타적입니다. 예를 들어 --usercat=all 옵션으로 지정된 CA ACL에서 ipa caacl-add-user --users=user_name 명령을 실행하려고 하면 명령이 실패합니다.
$ ipa caacl-add-user ca_acl_name --users=user_name
ipa: ERROR: users cannot be added when user category='all'
참고
사용자 또는 그룹이 해당 CA ACL에 추가되지 않은 경우 인증서 프로필을 사용하여 사용자 또는 그룹에 대한 인증서를 요청하지 않습니다. 예를 들어 다음과 같습니다.
$ ipa cert-request CSR-FILE --principal user --profile-id profile_id
ipa: ERROR Insufficient access: Principal 'user' is not permitted to use CA '.' with profile 'profile_id' for certificate issuance.
사용자 또는 그룹을 CA ACL에 추가하거나 “CA ACL 생성” 에 설명된 대로 CA ACL을 all 사용자 카테고리와 연결해야 합니다.
이러한 명령에 필요한 구문 및 사용 가능한 옵션에 대한 자세한 정보를 보려면 --help 옵션을 추가하여 명령을 실행합니다. 예를 들어 다음과 같습니다.
$ ipa caacl-add-user --help

24.5.2. 웹 UI의 CA ACL 관리

IdM 웹 UI에서 CA ACL을 관리하려면 다음을 수행합니다.
  1. Authentication 탭과 10.0.0.1 엽니다.
  2. CA ACL 섹션을 엽니다.

    그림 24.9. 웹 UI의 CA ACL 규칙 관리

    웹 UI의 CA ACL 규칙 관리
CA ACL 섹션에서는 새 CA ACL을 추가하고, 기존 CA ACL에 대한 정보를 표시하고, 속성을 수정하고, 선택한 CA ACL을 활성화, 비활성화 또는 삭제할 수 있습니다.
예를 들어 기존 CA ACL을 수정하려면 다음을 수행합니다.
  1. CA ACL의 이름을 클릭하여 CA ACL 구성 페이지를 엽니다.
  2. CA ACL 구성 페이지에서 필요한 정보를 입력합니다.
    ProfilesPermitted는 인증서 발행 섹션을 통해 CA ACL을 인증서 프로필, 사용자 또는 사용자 그룹, 호스트 또는 호스트 그룹 또는 서비스와 연결할 수 있습니다. 추가 버튼을 사용하여 이러한 오브젝트를 추가하거나 Anyone 옵션을 선택하여 CA ACL을 모든 사용자, 호스트 또는 서비스와 연결할 수 있습니다.
  3. 저장 을 클릭하여 새 구성을 확인합니다.

    그림 24.10. 웹 UI에서 CA ACL 규칙 수정

    웹 UI에서 CA ACL 규칙 수정

24.6. IdM CA에서 사용자 인증서 발급에 인증서 프로필과 ACL 사용

사용자는 CA ACL(인증 기관 액세스 제어 목록)에서 허용된 경우 인증서를 요청할 수 있습니다. 다음 절차에서는 24.4절. “인증서 프로필”24.5절. “인증 기관 ACL 규칙” 에 별도로 설명된 인증서 프로필과 CA ACL을 사용합니다. 인증서 프로필 및 CA ACL 사용에 대한 자세한 내용은 다음 섹션을 참조하십시오.

명령줄에서 사용자에게 인증서 실행

  1. 사용자 인증서에 대한 요청을 처리하기 위한 새 사용자 정의 인증서 프로필을 생성하거나 가져옵니다. 예를 들어 다음과 같습니다.
    $ ipa certprofile-import certificate_profile --file=certificate_profile.cfg --store=True
    
  2. 사용자 항목에 대한 인증서 요청을 허용하는 데 사용할 새 CA(인증 기관) ACL을 추가합니다. 예를 들어 다음과 같습니다.
    $ ipa caacl-add users_certificate_profile --usercat=all
    
  3. 사용자 정의 인증서 프로필을 CA ACL에 추가합니다.
    $ ipa caacl-add-profile users_certificate_profile --certprofiles=certificate_profile
  4. 사용자에 대한 인증서 요청을 생성합니다. 예를 들어 OpenSSL을 사용합니다.
    $ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=user'
    
  5. ipa cert-request 명령을 실행하여 IdM CA가 사용자의 새 인증서를 발행하도록 합니다.
    $ ipa cert-request cert.csr --principal=user --profile-id=certificate_profile
    선택적으로 --ca sub-CA_name 옵션을 명령에 전달하여 루트 CA ipa 대신 하위 CA에서 인증서를 요청합니다.
새로 발행된 인증서가 사용자에게 할당되었는지 확인하려면 ipa user-show 명령을 사용합니다.
$ ipa user-show user
  User login: user
  ...
  Certificate: MIICfzCCAWcCAQA...
  ...

웹 UI에서 사용자에게 인증서 실행

  1. 사용자 인증서에 대한 요청을 처리하기 위한 새 사용자 정의 인증서 프로필을 생성하거나 가져옵니다. 다음은 명령줄에서만 프로필 가져오기를 수행할 수 있습니다. 예를 들면 다음과 같습니다.
    $ ipa certprofile-import certificate_profile --file=certificate_profile.txt --store=True
    
    인증서 프로필에 대한 자세한 내용은 24.4절. “인증서 프로필” 을 참조하십시오.
  2. 웹 UI의 Authentication 탭에서 CA ACL 섹션을 엽니다.

    그림 24.11. 웹 UI의 CA ACL 규칙 관리

    웹 UI의 CA ACL 규칙 관리
    CA(인증 기관) ACL 목록의 상단에 있는 추가 를 클릭하여 사용자 항목에 대한 인증서를 요청할 수 있는 새 CA ACL을 추가합니다.
    1. 열리는 CA ACL 추가 창에서 새 CA ACL에 대한 필요한 정보를 입력합니다.

      그림 24.12. 새 CA ACL 추가

      새 CA ACL 추가
      그런 다음 추가 및 편집 을 클릭하여 CA ACL 구성 페이지로 직접 이동합니다.
    2. CA ACL 구성 페이지의 Profiles 섹션까지 스크롤하고 profiles 목록 상단에 있는 추가 를 클릭합니다.

      그림 24.13. CA ACL에 인증서 프로필 추가

      CA ACL에 인증서 프로필 추가
    3. 프로필을 선택하고 Prospective 열로 이동하여 CA ACL에 사용자 정의 인증서 프로필을 추가합니다.

      그림 24.14. 인증서 프로파일 선택

      인증서 프로파일 선택
      그런 다음 추가 를 클릭합니다.
    4. Permitted로 스크롤하여 CA ACL을 사용자 또는 사용자 그룹과 연결하는 인증서 발행 섹션이 있는지 확인합니다.
      추가 버튼을 사용하여 사용자 또는 그룹을 추가하거나 Anyone 옵션을 선택하여 CA ACL을 모든 사용자와 연결할 수 있습니다.

      그림 24.15. CA ACL에 사용자 추가

      CA ACL에 사용자 추가
    5. Permitted to have certificates issued 섹션에서 CA ACL을 하나 이상의 CA와 연결할 수 있습니다.
      추가 버튼을 사용하여 CA를 추가하거나 Any CA 옵션을 선택하여 CA ACL을 모든 CA와 연결할 수 있습니다.

      그림 24.16. CA ACL에 CA 추가

      CA ACL에 CA 추가
    6. CA ACL 구성 페이지 상단에서 저장 을 클릭하여 CA ACL에 대한 변경 사항을 확인합니다.
  3. 사용자에 대한 새 인증서를 요청합니다.
    1. Identity (ID) 탭과 Users (사용자)에서 인증서가 요청할 사용자를 선택합니다. 사용자 사용자 이름을 클릭하여 사용자 항목 구성 페이지를 엽니다.
    2. 사용자 구성 페이지 상단에서 작업을 클릭한 다음 새 인증서를 클릭합니다.

      그림 24.17. 사용자를 위한 인증서 요청

      사용자를 위한 인증서 요청
    3. 필요한 정보를 입력합니다.

      그림 24.18. 사용자의 인증서 발급

      사용자의 인증서 발급
      그런 다음 이ssue 클릭합니다.
이 후에는 새로 발행된 인증서가 사용자 구성 페이지에 표시됩니다.

25장. Vault를 사용하여 인증 보안 저장

자격 증명 모음은 시크릿 저장, 검색, 공유 및 복구를 위한 안전한 위치입니다. 시크릿은 제한된 사용자 또는 엔터티 그룹에서만 액세스할 수 있어야 하는 보안에 민감한 데이터입니다. 예를 들어 보안에는 다음이 포함됩니다.
  • 암호
  • 고정
  • 개인 SSH 키
사용자와 서비스는 IdM(Identity Management) 도메인에 등록된 모든 시스템에서 자격 증명 모음에 저장된 시크릿에 액세스할 수 있습니다.
참고
Vault는 IdM 웹 UI가 아닌 명령줄에서만 사용할 수 있습니다.
자격 증명 모음 사용 사례는 다음과 같습니다.
사용자의 개인 시크릿 저장
자세한 내용은 25.4절. “사용자의 개인 시크릿 저장” 을 참조하십시오.
서비스 시크릿 저장
자세한 내용은 25.5절. “Vault에 서비스 시크릿 저장” 을 참조하십시오.
여러 사용자가 사용하는 공통 시크릿 저장
자세한 내용은 25.6절. “여러 사용자를 위한 공통 시크릿 저장” 을 참조하십시오.
자격 증명 모음을 사용하려면 25.2절. “Vault 사용 사전 요구 사항” 에 설명된 조건을 충족해야 합니다.

25.1. Vault의 작동 방식

25.1.1. Vault 소유자, 멤버 및 관리자

IdM은 다음 vault 사용자 유형을 구분합니다.
Vault 소유자
자격 증명 모음 소유자는 자격 증명 모음에서 기본 관리 권한이 있는 사용자 또는 서비스입니다. 예를 들어 vault 소유자는 vault의 속성을 수정하거나 새 자격 증명 모음 멤버를 추가할 수 있습니다.
각 자격 증명 모음에는 최소한 하나의 소유자가 있어야 합니다. 자격 증명 모음에는 여러 소유자가 있을 수도 있습니다.
Vault 멤버
자격 증명 모음 멤버는 다른 사용자 또는 서비스에서 만든 자격 증명 모음에 액세스할 수 있는 사용자 또는 서비스입니다.
Vault 관리자
Vault 관리자는 모든 자격 증명 모음에 대한 무제한 액세스 권한이 있으며 모든 자격 증명 모음 작업을 수행할 수 있습니다.
참고
대칭 자격 증명 모음은 암호 또는 키로 보호되며 특수 액세스 제어 규칙을 적용합니다( 25.1.2절. “Standard, Symmetric 및 Asymmetric Vaults”참조). 관리자는 다음 규칙을 충족해야 합니다.
  • 대칭 및 비대칭 자격 증명 모음의 시크릿 액세스
  • vault 암호 또는 키 변경 또는 재설정
자격 증명 모음 관리자는 Vault 관리자 권한이 있는 모든 사용자입니다. 사용자 권한 정의에 대한 자세한 내용은 10.4절. “역할 기반 액세스 제어 정의” 을 참조하십시오.
특정 소유자 및 멤버 권한은 자격 증명 모음 유형에 따라 다릅니다. 자세한 내용은 25.1.2절. “Standard, Symmetric 및 Asymmetric Vaults” 을 참조하십시오.

Vault 사용자

ipa vault-show 명령과 같은 일부 명령의 출력에는 사용자 자격 증명 모음에 대한 Vault 사용자 도 표시됩니다.
$ ipa vault-show my_vault
  Vault name: my_vault
  Type: standard
  Owner users: user
  Vault user: user
vault 사용자는 자격 증명 모음이 있는 컨테이너가 있는 사용자를 나타냅니다. 자격 증명 모음 컨테이너 및 사용자 자격 증명 모음에 대한 자세한 내용은 25.1.4절. “다양한 유형의 Vault 컨테이너”25.1.3절. “사용자, 서비스 및 공유 Vaults” 을 참조하십시오.

25.1.2. Standard, Symmetric 및 Asymmetric Vaults

다음 자격 증명 모음 유형은 보안 및 액세스 제어 수준을 기반으로 합니다.
표준 자격 증명 모음
Vault 소유자 및 vault 멤버는 암호 또는 키를 사용하지 않고도 비밀을 보관하고 검색할 수 있습니다.
대칭 자격 증명 모음
자격 증명 모음의 시크릿은 대칭 키로 보호됩니다. Vault 멤버 및 자격 증명 모음 소유자는 시크릿을 보관하고 검색할 수 있지만 vault 암호를 제공해야 합니다.
비대칭 자격 증명 모음
자격 증명 모음의 비밀은 비대칭 키로 보호됩니다. 사용자는 공개 키를 사용하여 비밀을 보관하고 개인 키를 사용하여 검색합니다. Vault 멤버는 비밀만 보관할 수 있지만 vault 소유자는 시크릿을 아카이브하고 검색할 수 있습니다.

25.1.3. 사용자, 서비스 및 공유 Vaults

다음 자격 증명 모음 유형은 소유권을 기반으로 합니다.
사용자 자격 증명 모음: 사용자의 개인 자격 증명 모음
소유자: 단일 사용자.
모든 사용자는 하나 이상의 사용자 자격 증명 모음을 보유할 수 있습니다.
서비스 자격 증명 모음: 서비스의 개인 자격 증명 모음
소유자: 단일 서비스.
모든 서비스는 하나 이상의 서비스 자격 증명 모음을 보유할 수 있습니다.
공유 자격 증명 모음
소유자: 자격 증명 모음을 생성한 자격 증명 모음 관리자입니다. 다른 자격 증명 모음 관리자는 자격 증명 모음에 대한 전체 액세스 권한도 있습니다.
공유 자격 증명 모음은 여러 사용자 또는 서비스에서 사용할 수 있습니다.

25.1.4. 다양한 유형의 Vault 컨테이너

자격 증명 모음 컨테이너는 자격 증명 모음 컬렉션입니다.
IdM은 다음과 같은 기본 자격 증명 모음 컨테이너를 제공합니다.
사용자 컨테이너: 사용자의 개인 컨테이너
이 컨테이너는 특정 사용자의 사용자 자격 증명 모음을 저장합니다.
서비스 컨테이너: 서비스의 개인 컨테이너
이 컨테이너는 특정 서비스의 서비스 자격 증명 모음을 저장합니다.
공유 컨테이너
이 컨테이너 저장소: 여러 사용자 또는 서비스에서 공유할 수 있는 자격 증명 모음입니다.
IdM은 사용자 또는 서비스의 첫 번째 개인 자격 증명 모음이 생성될 때 각 사용자 또는 서비스에 대한 사용자 및 서비스 컨테이너를 자동으로 생성합니다. 사용자 또는 서비스가 삭제되면 IdM은 컨테이너와 해당 콘텐츠를 제거합니다.

25.2. Vault 사용 사전 요구 사항

자격 증명 모음을 활성화하려면 IdM 도메인에 있는 하나 이상의 서버에 KRA(키 복구 기관) 인증서 시스템 구성 요소를 설치합니다.
# ipa-kra-install
참고
Vault 서비스를 고가용성으로 만들려면 두 개의 IdM 서버에 KRA를 설치해야 합니다.

25.3. Vault 명령에 대한 도움말 가져오기

자격 증명 모음 및 vault 컨테이너를 관리하는 데 사용되는 모든 명령을 표시하려면 다음을 수행합니다.
$ ipa help vault
특정 명령에 대한 자세한 도움말을 표시하려면 명령에 --help 옵션을 추가합니다.
$ ipa vault-add --help

Vault 명령 Fail with 자격 증명 모음이 없는 오류를 찾을 수 없음

일부 명령에서는 다음 옵션을 사용하여 자격 증명 모음의 소유자 또는 유형을 지정해야 합니다.
  • --user 또는 --service 는 보려는 자격 증명 모음 소유자를 지정합니다.
    $ ipa vault-show user_vault --user user
  • 볼 vault가 공유 자격 증명 모음으로 표시되도록 --shared 를 지정합니다.
예를 들어 --user 를 추가하지 않고 다른 사용자의 자격 증명 모음을 표시하려는 경우 IdM에 자격 증명 모음이 발견되지 않았음을 알립니다.
[admin@server ~]$ ipa vault-show user_vault
ipa: ERROR: user_vault: vault not found

25.4. 사용자의 개인 시크릿 저장

이 섹션에서는 사용자가 하나 이상의 개인 자격 증명 모음을 생성하여 개인 시크릿을 안전하게 저장하는 방법을 보여줍니다. 그런 다음 사용자는 필요한 경우 도메인의 모든 시스템에서 시크릿을 검색합니다. 예를 들어 사용자는 자격 증명 모음에 개인 인증서를 보관하여 중앙 집중식 위치에 안전하게 인증서를 저장할 수 있습니다.
이 섹션에는 다음 절차가 포함되어 있습니다.
절차의 경우:
  • 사용자는 자격 증명 모음을 생성하려는 사용자입니다.
  • my_vault 는 사용자 인증서를 저장하는 데 사용되는 자격 증명 모음입니다.
  • 자격 증명 모음 유형은 표준 이므로 보관된 인증서에 액세스하면 사용자가 자격 증명 모음 암호를 제공할 필요가 없습니다.
  • secret.txt 는 사용자가 자격 증명 모음에 저장하려는 인증서를 포함하는 파일입니다.
  • secret_exported.txt 는 사용자가 보관된 인증서를 내보내는 파일입니다.

25.4.1. 사용자의 개인 시크릿 보관

개인 사용자 자격 증명 모음을 생성하고 인증서를 저장합니다. 자격 증명 모음 유형은 표준이므로 인증서에 액세스할 때 인증할 필요가 없습니다.
  1. 사용자로 로그인합니다.
    $ kinit user
  2. ipa vault-add 명령을 사용하여 표준 자격 증명 모음을 생성합니다.
    $ ipa vault-add my_vault --type standard
    ----------------------
    Added vault "my_vault"
    ----------------------
      Vault name: my_vault
      Type: standard
      Owner users: user
      Vault user: user
    중요
    동일한 사용자가 사용자의 첫 번째 사용자 자격 증명 모음이 생성되었는지 확인합니다. 예를 들어 admin 과 같은 다른 사용자가 user1 에 대한 첫 번째 사용자 자격 증명 모음을 생성하는 경우 사용자의 Vault 컨테이너 소유자도 admin 이 되고 user1 은 사용자 자격 증명 모음에 액세스하거나 새 사용자 자격 증명 모음을 생성할 수 없습니다. 자세한 내용은 B.5.1절. “사용자가 해당 Vault Due에 액세스 할 수 없습니다. '추가' 권한” 참조하십시오.
  3. ipa vault-archive --in 명령을 사용하여 secret.txt 파일을 자격 증명 모음에 저장합니다.
    $ ipa vault-archive my_vault --in secret.txt
    -----------------------------------
    Archived data into vault "my_vault"
    -----------------------------------
    참고
    자격 증명 모음은 하나의 비밀만 저장할 수 있습니다.

25.4.2. 사용자의 개인 시크릿 검색

개인 표준 자격 증명 모음에서 인증서를 내보냅니다.
  1. 사용자로 로그인합니다.
    $ kinit user
  2. ipa vault-retrieve --out 명령을 사용하여 자격 증명 모음의 콘텐츠를 검색하여 secret_exported.txt 파일에 저장합니다.
    $ ipa vault-retrieve my_vault --out secret_exported.txt
    --------------------------------------
    Retrieved data from vault "my_vault"
    --------------------------------------

25.5. Vault에 서비스 시크릿 저장

이 섹션에서는 관리자가 자격 증명 모음을 사용하여 서비스 시크릿을 중앙 집중식 위치에 안전하게 저장하는 방법을 보여줍니다. 서비스 비밀은 서비스 공개 키로 암호화됩니다. 그런 다음 서비스는 도메인의 모든 시스템에서 개인 키를 사용하여 시크릿을 검색합니다. 서비스와 관리자만 시크릿에 액세스할 수 있습니다.
이 섹션에는 다음 절차가 포함되어 있습니다.
절차의 경우:
  • admin 은 서비스 암호를 관리하는 관리자입니다.
  • http_password 는 관리자가 생성한 개인 사용자 자격 증명 모음의 이름입니다.
  • password.txt 는 서비스 암호를 포함하는 파일입니다.
  • password_vault 는 서비스에 대해 생성된 자격 증명 모음입니다.
  • HTTP/server.example.com 은 암호가 보관되는 서비스입니다.
  • service-public.pempassword_vault에 저장된 암호를 암호화하는 데 사용되는 서비스 공개 키입니다.

25.5.1. 서비스 암호를 저장할 사용자 Vault 만들기

관리자 소유 사용자 자격 증명 모음을 만들고 이를 사용하여 서비스 암호를 저장합니다. 자격 증명 모음 유형은 표준이므로 자격 증명 모음 내용에 액세스할 때 관리자가 인증할 필요가 없습니다.
  1. 관리자로 로그인합니다.
    $ kinit admin
  2. 표준 사용자 자격 증명 모음을 생성합니다.
    $ ipa vault-add http_password --type standard
    ---------------------------
    Added vault "http_password"
    ---------------------------
      Vault name: http_password
      Type: standard
      Owner users: admin
      Vault user: admin
  3. 서비스 암호를 자격 증명 모음에 보관합니다.
    $ ipa vault-archive http_password --in password.txt
    ----------------------------------------
    Archived data into vault "http_password"
    ----------------------------------------
    주의
    암호를 자격 증명 모음에 보관한 후 시스템에서 password.txt 를 삭제합니다.

25.5.2. User Vault에서 서비스 인스턴스로 서비스 암호 배포

서비스에 대해 생성된 비대칭 자격 증명 모음을 사용하여 서비스 인스턴스에 서비스 암호를 프로비저닝합니다.
  1. 관리자로 로그인합니다.
    $ kinit admin
  2. 서비스 인스턴스의 공개 키를 가져옵니다. 예를 들어 openssl 유틸리티를 사용합니다.
    1. service-private.pem 개인 키를 생성합니다.
      $ openssl genrsa -out service-private.pem 2048
      Generating RSA private key, 2048 bit long modulus
      .+++
      ...........................................+++
      e is 65537 (0x10001)
    2. 개인 키를 기반으로 service-public.pem 공개 키를 생성합니다.
      $ openssl rsa -in service-private.pem -out service-public.pem -pubout
      writing RSA key
  3. 서비스 인스턴스 자격 증명 모음으로 비대칭 자격 증명 모음을 생성하고 공개 키를 제공합니다.
    $ ipa vault-add password_vault --service HTTP/server.example.com --type asymmetric --public-key-file service-public.pem
    ----------------------------
    Added vault "password_vault"
    ----------------------------
    Vault name: password_vault
    Type: asymmetric
    Public key: LS0tLS1C...S0tLS0tCg==
    Owner users: admin
    Vault service: HTTP/server.example.com@EXAMPLE.COM
    자격 증명 모음에 저장된 암호는 키로 보호됩니다.
  4. 관리자의 개인 자격 증명 모음에서 서비스 암호를 검색하여 새 서비스 자격 증명 모음에 보관합니다.
    $ ipa vault-retrieve http_password --out password.txt
    -----------------------------------------
    Retrieved data from vault "http_password"
    -----------------------------------------
    $ ipa vault-archive password_vault --service HTTP/server.example.com --in password.txt
    -----------------------------------
    Archived data into vault "password_vault"
    -----------------------------------
    이렇게 하면 서비스 인스턴스 공개 키로 암호를 암호화합니다.
    주의
    암호를 자격 증명 모음에 보관한 후 시스템에서 password.txt 를 삭제합니다.
암호가 필요한 모든 서비스 인스턴스에 대해 이 단계를 반복합니다. 각 서비스 인스턴스에 대한 새 비대칭 자격 증명 모음을 만듭니다.

25.5.3. 서비스 인스턴스의 서비스 암호 검색

서비스 인스턴스는 로컬에 저장된 서비스 개인 키를 사용하여 서비스 vault 암호를 검색할 수 있습니다.
  1. 관리자로 로그인합니다.
    $ kinit admin
  2. 서비스에 대한 Kerberos 티켓을 받습니다.
    # kinit HTTP/server.example.com -k -t /etc/httpd/conf/ipa.keytab
  3. 서비스 vault 암호를 검색합니다.
    $ ipa vault-retrieve password_vault --service HTTP/server.example.com --private-key-file service-private.pem --out password.txt
    ------------------------------------
    Retrieved data from vault "password_vault"
    ------------------------------------
    

25.5.4. 서비스 Vault 암호 변경

서비스 인스턴스가 손상된 경우 서비스 vault 암호를 변경한 다음 새 암호를 압축되지 않은 서비스 인스턴스로 다시 프로비저닝하여 격리합니다.
  1. 관리자의 사용자 자격 증명 모음에 새 암호를 보관합니다.
    $ ipa vault-archive http_password --in new_password.txt
    ----------------------------------------
    Archived data into vault "http_password"
    ----------------------------------------
    자격 증명 모음에 저장된 현재 암호를 덮어씁니다.
  2. 손상된 인스턴스를 제외하고 각 서비스 인스턴스에 새 암호를 다시 프로비저닝합니다.
    1. 관리자 자격 증명 모음에서 새 암호를 검색합니다.
      $ ipa vault-retrieve http_password --out password.txt
      -----------------------------------------
      Retrieved data from vault "http_password"
      -----------------------------------------
    2. 새 암호를 서비스 인스턴스 자격 증명 모음에 보관합니다.
      $ ipa vault-archive password_vault --service HTTP/server.example.com --in password.txt
      -----------------------------------
      Archived data into vault "password_vault"
      -----------------------------------
      주의
      암호를 자격 증명 모음에 보관한 후 시스템에서 password.txt 를 삭제합니다.

25.6. 여러 사용자를 위한 공통 시크릿 저장

이 섹션에서는 관리자가 공유 자격 증명 모음을 생성하고 다른 사용자가 자격 증명 모음의 시크릿에 액세스할 수 있는 방법을 보여줍니다. 관리자는 일반 암호를 자격 증명 모음에 보관하고 다른 사용자는 도메인의 모든 시스템에서 암호를 검색할 수 있습니다.
이 섹션에는 다음 절차가 포함되어 있습니다.
절차의 경우:
  • shared_vault 는 공통 암호를 저장하는 데 사용되는 자격 증명 모음입니다.
  • admin 은 공유 자격 증명 모음을 생성하는 관리자입니다.
  • 자격 증명 모음 유형은 표준 이므로 보관된 암호에 액세스할 때 사용자가 자격 증명 모음 암호를 제공할 필요가 없습니다.
  • secret.txt 는 공통 시크릿을 포함하는 파일입니다.
  • user1user2 는 자격 증명 모음에 액세스할 수 있는 사용자입니다.

25.6.1. 공통 시크릿을 사용하여 공유 Vault 생성

공유 자격 증명 모음을 만들고 이를 사용하여 공통 시크릿을 저장합니다. 비밀에 액세스할 사용자를 vault 멤버로 추가합니다. 자격 증명 모음 유형은 표준이므로 시크릿에 액세스하는 사용자가 인증할 필요가 없습니다.
  1. 관리자로 로그인합니다.
    $ kinit admin
  2. 공유 자격 증명 모음을 생성합니다.
    $ ipa vault-add shared_vault --shared --type standard
    ---------------------------
    Added vault "shared_vault"
    ---------------------------
      Vault name: shared_vault
      Type: standard
      Owner users: admin
      Shared vault: True
  3. 비밀을 자격 증명 모음에 보관합니다. share 옵션을 추가하여 vault가 공유 컨테이너에 있음을 지정합니다.
    $ ipa vault-archive shared_vault --shared --in secret.txt
    -----------------------------------
    Archived data into vault "shared_vault"
    -----------------------------------
    참고
    자격 증명 모음은 하나의 비밀만 저장할 수 있습니다.
  4. user1user2 를 자격 증명 모음 멤버로 추가합니다.
    ipa vault-add-member shared_vault --shared --users={user1,user2}
    Vault name: shared_vault
    Type: standard
    Owner users: admin
    Shared vault: True
    Member users: user1, user2
    -------------------------
    Number of members added 2
    -------------------------

25.6.2. 공유 Vault에서 멤버 사용자로 시크릿 검색

자격 증명 모음의 멤버 사용자로 로그인하고 자격 증명 모음에서 시크릿을 사용하여 파일을 내보냅니다.
  1. user1 멤버 사용자로 로그인합니다.
    $ kinit user1
  2. 공유 자격 증명 모음에서 시크릿을 검색합니다.
    $ ipa vault-retrieve shared_vault --shared --out secret_exported.txt
    -----------------------------------------
    Retrieved data from vault "shared_vault"
    -----------------------------------------

25.7. Vault의 암호 또는 공개 키 변경

자격 증명 모음의 소유자는 자격 증명 모음의 암호를 변경할 수 있습니다. 자격 증명 모음이 대칭인지 또는 비대칭인지에 따라 명령이 다릅니다.
  • 대칭 자격 증명 모음의 암호를 변경하려면 다음을 수행합니다.
    # ipa vault-mod --change-password
    Vault name: example_symmetric_vault
    Password: old_password
    New password: new_password
    Enter New password again to verify: new_password
    -----------------------
    Modified vault "example_symmetric_vault"
    -----------------------
      Vault name: example_symmetric_vault
      Type: symmetric
      Salt: dT+M+4ik/ltgnpstmCG1sw==
      Owner users: admin
      Vault user: admin
  • 비대칭 자격 증명 모음의 공개 키를 변경하려면 다음을 수행합니다.
    # ipa vault-mod example_asymmetric_vault --private-key-file=old_private_key.pem --public-key-file=new_public_key.pem
    -------------------------------
    Modified vault "example_assymmetric_vault"
    -------------------------------
      Vault name: example_assymmetric_vault
      Typ: asymmetric
      Public key: ...
      Owner users: admin
      Vault user: admin

26장. 인증서 및 인증 기관 관리

26.1. 경량의 서브 CA

IdM 설치가 통합 인증서 시스템(CS) 인증 기관(CA)으로 구성된 경우 경량 하위 CA를 생성할 수 있습니다. VPN(가상 사설 네트워크) 게이트웨이와 같은 서비스를 구성하여 하나의 하위 CA에서 발급한 인증서만 허용할 수 있습니다. 동시에 다른 하위 CA 또는 루트 CA에서 발급한 인증서만 수락하도록 다른 서비스를 구성할 수 있습니다.
하위 CA의 중간 인증서를 취소하면 이 하위 CA에서 발급한 모든 인증서가 자동으로 무효화됩니다.
통합 CA를 사용하여 IdM을 설정하는 경우 자동으로 생성된 ipa CA는 인증서 시스템의 루트 CA입니다. 생성하는 모든 하위 CA는 이 루트 CA로 하위됩니다.

26.1.1. 경량 서브 CA 생성

하위 CA 생성에 대한 자세한 내용은 를 참조하십시오.

웹 UI에서 하위 CA 생성

vpn-ca 라는 새 하위 CA를 만들려면 다음을 수행합니다.
  1. Authentication 탭을 열고 10.0.0.1을 선택합니다.
  2. 인증 기관을 선택하고 추가 를 클릭합니다.
  3. CA의 이름 및 주제 DN을 입력합니다.

    그림 26.1. CA 추가

    CA 추가
    주체 DN은 IdM CA 인프라에서 고유해야 합니다.

명령줄에서 하위 CA 생성

vpn-ca 라는 새 하위 CA를 생성하려면 다음을 입력합니다.
[root@ipaserver ~]# ipa ca-add vpn-ca --subject="CN=VPN,O=IDM.EXAMPLE.COM"
-------------------
Created CA "vpn-ca"
-------------------
  Name: vpn-ca
  Authority ID: ba83f324-5e50-4114-b109-acca05d6f1dc
  Subject DN: CN=VPN,O=IDM.EXAMPLE.COM
  Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM
이름
CA의 이름입니다.
권한 ID
CA의 개별 ID가 자동으로 생성됩니다.
제목 DN
제목 고유 이름(DN). 주체 DN은 IdM CA 인프라에서 고유해야 합니다.
발행자 DN
하위 CA 인증서를 발급한 상위 CA. 모든 하위 CA는 IdM 루트 CA의 하위 항목으로 생성됩니다.
새 CA 서명 인증서가 IdM 데이터베이스에 추가되었는지 확인하려면 다음을 실행합니다.
[root@ipaserver ~]# certutil -d /etc/pki/pki-tomcat/alias/ -L

Certificate Nickname                                           Trust Attributes
                                                               SSL,S/MIME,JAR/XPI

caSigningCert cert-pki-ca                                      CTu,Cu,Cu
Server-Cert cert-pki-ca                                        u,u,u
auditSigningCert cert-pki-ca                                   u,u,Pu
caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u
ocspSigningCert cert-pki-ca                                    u,u,u
subsystemCert cert-pki-ca                                      u,u,u
참고
인증서 시스템 인스턴스가 설치된 경우 새 CA 인증서가 모든 복제본으로 자동으로 전송됩니다.

26.1.2. 경량 서브 CA 제거

하위 CA 삭제에 대한 자세한 내용은 를 참조하십시오.

웹 UI에서 하위 CA 제거

  1. Authentication 탭을 열고 10.0.0.1을 선택합니다.
  2. 인증 기관을 선택합니다.
  3. 제거할 하위 CA를 선택하고 삭제 를 클릭합니다.
  4. 삭제를 클릭하여 확인합니다.

명령줄에서 하위 CA 제거

하위 CA를 삭제하려면 다음을 입력합니다.
[root@ipaserver ~]# ipa ca-del vpn-ca
-------------------
Deleted CA "vpn-ca"
-------------------

26.2. 인증서 갱신

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

26.2.1. 인증서 자동 갱신

certmonger 서비스는 만료일 28일 전에 다음 인증서를 자동으로 갱신합니다.
  • IdM CA에서 루트 CA로 발행한 CA 인증서
  • 내부 IdM 서비스에서 사용하는 통합 IdM CA에서 발행한 하위 시스템 및 서버 인증서
하위 CA 인증서를 자동으로 갱신하려면 certmonger 추적 목록에 나열되어야 합니다. 추적 목록을 업데이트하려면 다음을 수행합니다.
[root@ipaserver ~]# ipa-certupdate
trying https://idmserver.idm.example.com/ipa/json
Forwarding 'schema' to json server 'https://idmserver.idm.example.com/ipa/json'
trying https://idmserver.idm.example.com/ipa/json
Forwarding 'ca_is_enabled' to json server 'https://idmserver.idm.example.com/ipa/json'
Forwarding 'ca_find/1' to json server 'https://idmserver.idm.example.com/ipa/json'
Systemwide CA database updated.
Systemwide CA database updated.
The ipa-certupdate command was successful
참고
외부 CA를 루트 CA로 사용하는 경우 26.2.2절. “수동으로 CA 인증서 갱신” 에 설명된 대로 인증서를 수동으로 갱신해야 합니다. certmonger 서비스는 외부 CA에서 서명한 인증서를 자동으로 갱신할 수 없습니다.
certmonger 가 인증서 만료 날짜를 모니터링하는 방법에 대한 자세한 내용은 System-Level Authentication Guidecertmonger를 사용한 인증서 추적을 참조하십시오.
자동 갱신이 예상대로 작동하는지 확인하려면 /var/log/ECDHE 파일에서 certmonger 로그 메시지를 검사합니다.
  • 인증서를 갱신한 후 certmonger 레코드 메시지는 갱신 작업이 성공 또는 실패했음을 나타내는 다음과 같습니다.
    Certificate named "NSS Certificate DB" in token "auditSigningCert cert-pki-ca" in database "/var/lib/pki-ca/alias" renew success
  • 인증서가 만료되면 certmonger 는 다음 메시지를 기록합니다.
    certmonger: Certificate named "NSS Certificate DB" in token "auditSigningCert cert-pki-ca" in database "/var/lib/pki-ca/alias" will not be valid after 20160204065136.

26.2.2. 수동으로 CA 인증서 갱신

ipa-cacert-manage 유틸리티를 사용하여 수동으로 갱신할 수 있습니다.
  • 자체 서명된 IdM CA 인증서
  • 외부 서명 IdM CA 인증서
ipa-cacert-manage renew 명령으로 갱신된 인증서는 이전 인증서와 동일한 키 쌍과 주체 이름을 사용합니다. 인증서를 갱신해도 인증서 롤오버를 활성화하기 위해 이전 버전이 제거되지 않습니다.
자세한 내용은 ipa-cacert-manage(1) 매뉴얼 페이지를 참조하십시오.

26.2.2.1. 수동으로 자체 서명된 IdM CA 인증서 갱신

  1. ipa-cacert-manage renew 명령을 실행합니다. 이 명령에는 인증서 경로를 지정할 필요가 없습니다.
  2. 이제 업데이트된 인증서가 LDAP 인증서 저장소 및 /etc/pki/pki-tomcat/alias NSS 데이터베이스에 있습니다.
  3. 모든 서버 및 클라이언트에서 ipa-certupdate 유틸리티를 실행하여 LDAP의 새 인증서에 대한 정보로 업데이트합니다. 모든 서버와 클라이언트에서 ipa-certupdate 를 별도로 실행해야 합니다.
    중요
    인증서를 수동으로 설치한 후 항상 ipa-certupdate 를 실행합니다. 그렇지 않으면 인증서가 다른 시스템에 배포되지 않습니다.
업데이트된 인증서가 올바르게 설치되었는지 확인하려면 certutil 유틸리티를 사용하여 데이터베이스의 인증서를 나열합니다. 예를 들어 다음과 같습니다.
# certutil -L -d /etc/pki/pki-tomcat/alias

26.2.2.2. 외부 서명 IdM CA 인증서 수동으로 갱신

  1. ipa-cacert-manage renew --external-ca 명령을 실행합니다.
  2. 이 명령은 /var/lib/ipa/ca.csr CSR 파일을 생성합니다. CSR을 외부 CA에 제출하여 업데이트된 CA 인증서를 발급합니다.
  3. ipa-cacert-manage renew 를 다시 실행하고, 이번에는 --external-cert-file 옵션을 사용하여 갱신된 CA 인증서 및 외부 CA 인증서 체인 파일을 지정합니다. 예를 들어 다음과 같습니다.
    # ipa-cacert-manage renew --external-cert-file=/tmp/servercert20110601.pem --external-cert-file=/tmp/cacert.pem
  4. 이제 업데이트된 CA 인증서 및 외부 CA 인증서 체인이 LDAP 인증서 저장소와 /etc/pki/pki-tomcat/alias/ NSS 데이터베이스에 있습니다.
  5. 모든 서버 및 클라이언트에서 ipa-certupdate 유틸리티를 실행하여 LDAP의 새 인증서에 대한 정보로 업데이트합니다. 모든 서버와 클라이언트에서 ipa-certupdate 를 별도로 실행해야 합니다.
    중요
    인증서를 수동으로 설치한 후 항상 ipa-certupdate 를 실행합니다. 그렇지 않으면 인증서가 다른 시스템에 배포되지 않습니다.
업데이트된 인증서가 올바르게 설치되었는지 확인하려면 certutil 유틸리티를 사용하여 데이터베이스의 인증서를 나열합니다. 예를 들어 다음과 같습니다.
# certutil -L -d /etc/pki/pki-tomcat/alias/

26.2.3. IdM이 오프라인될 때 만료된 시스템 인증서 갱신

시스템 인증서가 만료된 경우 IdM이 시작되지 않습니다. IdM은 ipa-cert-fix 툴을 사용하여 이러한 상황에서도 시스템 인증서 갱신을 지원합니다.

사전 요구 사항

  • 호스트에 ipactl start --ignore-service-failures 명령을 입력하여 LDAP 서비스가 실행 중인지 확인합니다.

절차 26.1. IdM 서버에서 만료된 시스템 인증서 모두 갱신

  1. IdM 도메인의 CA에서 다음을 수행합니다.
    1. ipa-cert-fix 유틸리티를 시작하여 시스템을 분석하고 만료된 인증서를 나열합니다.
      # ipa-cert-fix
      ...
      The following certificates will be renewed:
      
      Dogtag sslserver certificate:
        Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
        Serial:  13
        Expires: 2019-05-12 05:55:47
      ...
      Enter "yes" to proceed:
    2. yes 를 입력하여 갱신 프로세스를 시작합니다.
      Enter "yes" to proceed: yes
      Proceeding.
      Renewed Dogtag sslserver certificate:
        Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
        Serial:  268369925
        Expires: 2021-08-14 02:19:33
      ...
      
      Becoming renewal master.
      The ipa-cert-fix command was successful
      ipa-cert-fix 가 만료된 모든 인증서를 갱신하기까지 최대 1분 정도 걸릴 수 있습니다.
      참고
      갱신 마스터가 아닌 CA 호스트에서 ipa-cert-fix 유틸리티를 실행하고 유틸리티 공유 인증서를 업데이트한 경우 이 호스트는 자동으로 도메인의 새 갱신 마스터가 됩니다. 불일치를 방지하려면 항상 도메인에는 하나의 갱신 마스터만 있어야 합니다.
    3. 선택적으로 모든 서비스가 실행 중인지 확인합니다.
      # ipactl status
      Directory Service: RUNNING
      krb5kdc Service: RUNNING
      kadmin Service: RUNNING
      httpd Service: RUNNING
      ipa-custodia Service: RUNNING
      pki-tomcatd Service: RUNNING
      ipa-otpd Service: RUNNING
      ipa: INFO: The ipactl command was successful
  2. IdM 도메인의 다른 서버에서 다음을 수행합니다.
    1. --force 매개변수를 사용하여 IdM을 다시 시작합니다.
      # ipactl restart --force
      --force 매개변수를 사용하면 ipactl 유틸리티에서 개별 시작 오류를 무시합니다. 예를 들어 서버가 CA인 경우 pki-tomcat 서비스가 시작되지 않습니다. --force 매개변수를 사용하므로 이는 예상되고 무시됩니다.
    2. 재시작 후 certmonger 서비스가 인증서를 갱신했는지 확인합니다.
      # getcert list | egrep '^Request|status:|subject:'
      Request ID '20190522120745':
              status: MONITORING
              subject: CN=IPA RA,O=EXAMPLE.COM 201905222205
      Request ID '20190522120834':
              status: MONITORING
              subject: CN=Certificate Authority,O=EXAMPLE.COM 201905222205
      ...
      certmonger 가 복제본에서 공유 인증서를 갱신하기 전에 시간이 걸릴 수 있습니다.
    3. 서버가 CA인 경우 이전 명령은 pki-tomcat 서비스에서 사용하는 인증서에 대해 CA_UNREACHABLE 을 보고합니다.
      Request ID '20190522120835':
              status: CA_UNREACHABLE
              subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
      ...
      이 인증서를 갱신하려면 ipa-cert-fix 유틸리티를 사용합니다.
      # ipa-cert-fix
      Dogtag sslserver certificate:
        Subject: CN=ca2.example.com,O=EXAMPLE.COM
        Serial:  3
        Expires: 2019-05-11 12:07:11
      
      Enter "yes" to proceed: yes
      Proceeding.
      Renewed Dogtag sslserver certificate:
        Subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
        Serial:  15
        Expires: 2019-08-14 04:25:05
      
      The ipa-cert-fix command was successful

26.3. 수동으로 CA 인증서 설치

IdM에 새 인증서를 설치하려면 ipa-cacert-manage install 명령을 사용합니다. 예를 들어 명령을 사용하면 만료일이 임박할 때 현재 인증서를 변경할 수 있습니다.
  1. ipa-cacert-manage install 명령을 실행하고 인증서가 포함된 파일의 경로를 지정합니다. 명령은 PEM 형식의 인증서 파일을 허용합니다.
    [root@server ~]# ipa-cacert-manage install /etc/group/cert.pem
    이제 LDAP 인증서 저장소에 인증서가 있습니다.
  2. 모든 서버 및 클라이언트에서 ipa-certupdate 유틸리티를 실행하여 LDAP의 새 인증서에 대한 정보로 업데이트합니다. 모든 서버와 클라이언트에서 ipa-certupdate 를 별도로 실행해야 합니다.
    중요
    인증서를 수동으로 설치한 후 항상 ipa-certupdate 를 실행합니다. 그렇지 않으면 인증서가 다른 시스템에 배포되지 않습니다.
ipa-cacert-manage install 명령은 다음 옵션을 사용할 수 있습니다.
-n
인증서의 닉네임; 기본값은 인증서의 제목 이름입니다.
-t
인증서에 대한 신뢰 플래그를 certutil 형식으로 지정합니다. 기본값은 C,, 입니다. 신뢰 플래그를 지정하는 형식에 대한 자세한 내용은 ipa-cacert-manage(1) 매뉴얼 페이지를 참조하십시오.

26.4. 인증서 변경

ipa-cacert-manage 갱신을 사용하여 CA 인증서를 갱신 하여 인증서 체인을 수정할 수 있습니다.
자체 서명 CA 인증서 → 외부 서명 CA 인증서
ipa -cacert-manage renew 에 --external -caca 옵션을 추가합니다. 그러면 자체 서명 CA 인증서가 외부 서명 CA 인증서로 갱신됩니다.
이 옵션과 함께 명령을 실행하는 방법에 대한 자세한 내용은 26.2.2절. “수동으로 CA 인증서 갱신” 을 참조하십시오.
외부 서명 CA 인증서 → 자체 서명된 CA 인증서
ipa-cacert-manage renew--self-signed 옵션을 추가합니다. 그러면 외부 서명 CA 인증서가 자체 서명된 CA 인증서로 갱신됩니다.

26.5. IdM이 만료된 인증서로 시작하도록 허용

IdM 관리 서버 인증서가 만료된 후 대부분의 IdM 서비스에 액세스할 수 없게 됩니다. 인증서가 만료된 경우에도 서비스에 대한 SSL 액세스를 허용하도록 기본 Apache 및 LDAP 서비스를 구성할 수 있습니다.
만료된 인증서로 제한된 액세스를 허용하는 경우:
  • Apache, Kerberos, DNS 및 LDAP 서비스가 계속 작동합니다. 이러한 서비스를 활성화하면 사용자가 IdM 도메인에 로그인할 수 있습니다.
  • SSL이 필요한 클라이언트 서비스는 여전히 실패합니다. 예를 들어, IdM 클라이언트에 SSSD가 필요하므로 sudo 가 실패하고 SSSD에 IdM에 문의하려면 SSL이 필요합니다.
중요
이 절차는 임시 해결 방법을 통해서만 이루어집니다. 필요한 인증서를 가능한 한 빨리 갱신한 다음 설명된 변경 사항을 되돌립니다.
  1. Apache 서버에 유효한 인증서를 적용하지 않도록 mod_nss 모듈을 구성합니다.
    1. /etc/httpd/conf.d/nss.conf 파일을 엽니다.
    2. NSSEnforceValidCerts 매개변수를 off 로 설정합니다.
      NSSEnforceValidCerts off
  2. Apache를 다시 시작합니다.
    # systemctl restart httpd.service
  3. LDAP 디렉터리 서버에 대해 유효성 검사를 비활성화했는지 확인합니다. 이렇게 하려면 nsslapd-validate-cert 속성이 warn 으로 설정되어 있는지 확인합니다.
    # ldapsearch -h server.example.com -p 389 -D "cn=directory manager" -w secret -LLL -b cn=config -s base "(objectclass=*)" nsslapd-validate-cert
    
    dn: cn=config
    nsslapd-validate-cert: warn
    속성이 warn 으로 설정되지 않은 경우 다음을 변경합니다.
    # ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com
    
    dn: cn=config
    changetype: modify
    replace: nsslapd-validate-cert
    nsslapd-validate-cert: warn
  4. 디렉터리 서버를 다시 시작합니다.
    # systemctl restart dirsrv.target

26.6. HTTP 또는 LDAP용 타사 인증서 설치

Apache Web Server, Directory Server 또는 둘 다에 대한 새 SSL 서버 인증서를 설치하면 현재 SSL 인증서가 새 인증서로 대체됩니다. 이렇게 하려면 다음이 필요합니다.
  • 개인 SSL 키 (아래 절차의ssl.key )
  • SSL 인증서(아래 절차의ssl.crt )
허용되는 키 및 인증서 형식 목록은 ipa-server-certinstall(1) 도움말 페이지를 참조하십시오.

사전 요구 사항

인증서를 로드하는 서비스에서 알려진 CA에서 ssl.crt 인증서를 서명해야 합니다. 그렇지 않은 경우 26.3절. “수동으로 CA 인증서 설치” 에 설명된 대로 ssl.crt 에 서명한 CA의 CA 인증서를 IdM에 설치합니다.
이렇게 하면 IdM에서 CA를 인식하여 ssl.crt 를 허용합니다.

타사 인증서 설치

  1. ipa-server-certinstall 유틸리티를 사용하여 인증서를 설치합니다. 설치할 위치를 지정합니다.
    • --HTTP 에서 Apache 웹 서버에 인증서 설치
    • --dirsrv 는 Directory 서버에 인증서를 설치
    예를 들어 SSL 인증서를 둘 다에 설치하려면 다음을 수행합니다.
    # ipa-server-certinstall --http --dirsrv ssl.key ssl.crt
  2. 인증서를 설치한 서버를 다시 시작합니다.
    • Apache 웹 서버를 다시 시작하려면 다음을 수행합니다.
      # systemctl restart httpd.service
    • Directory Server를 다시 시작하려면 다음을 수행합니다.
      # systemctl restart dirsrv@REALM.service
  3. 인증서가 올바르게 설치되었는지 확인하려면 인증서 데이터베이스에 있어야 합니다.
    • Apache 인증서 데이터베이스를 표시하려면 다음을 수행합니다.
      # certutil -L -d /etc/httpd/alias
    • Directory Server 인증서 데이터베이스를 표시하려면 다음을 수행합니다.
      # certutil -L -d /etc/dirsrv/slapd-REALM/

26.7. OCSP 응답자 구성

IdM 서버와 통합된 모든 CA는 내부 온라인 인증서 상태 프로토콜(OCSP) 응답을 사용합니다. OCSP 응답자에 액세스할 수 있는 IdM 서비스는 http://ca-server.example.com/ca/ocsp 에서 사용할 수 있습니다. 클라이언트가 이 URL에 연결하여 인증서의 유효성을 확인할 수 있습니다.
참고
OCSP에 대한 자세한 내용은 Red Hat Certificate System 문서를 참조하십시오. 예: 2.2.4. 계획, 설치 및 배포 가이드에서 인증서 취소 및 상태 점검.

26.7.1. CRL 업데이트 간격 변경

CRL 파일은 기본적으로 IdM CA에서 4시간마다 자동으로 생성합니다. 이 간격을 변경하려면 다음을 수행합니다.
  1. CA 서버를 중지합니다.
    # systemctl stop pki-tomcatd@pki-tomcat.service
  2. /var/lib/pki/pki-tomcat/conf/ca/CS.cfg 파일을 열고 ca.crl.MasterCRL.autoUpdateInterval 값을 새 간격 설정으로 변경합니다. 예를 들어 60분마다 CRL을 생성하려면 다음을 수행합니다.
    ca.crl.MasterCRL.autoUpdateInterval=60
    참고
    ca.crl.MasterCRL.autoUpdateInterval 매개변수를 업데이트하면 다음 이미 예약된 CRL 업데이트 후에 변경 사항이 적용됩니다.
  3. CA 서버를 시작합니다.
    # systemctl start pki-tomcatd@pki-tomcat.service

26.8. 기존 IdM 도메인에 CA 설치

IdM 도메인을 CA(인증 기관) 없이 설치한 경우 나중에 CA 서비스를 설치할 수 있습니다. 환경에 따라 IdM 인증서 서버 CA를 설치하거나 외부 CA를 사용할 수 있습니다.
참고
지원되는 CA 구성에 대한 자세한 내용은 2.3.2절. “사용할 CA 구성 결정” 을 참조하십시오.
IdM 인증서 서버 설치
  1. 다음 명령을 사용하여 IdM 인증서 서버 CA를 설치합니다.
    [root@ipa-server ~] ipa-ca-install
  2. 모든 서버 및 클라이언트에서 ipa-certupdate 유틸리티를 실행하여 LDAP의 새 인증서에 대한 정보로 업데이트합니다. 모든 서버와 클라이언트에서 ipa-certupdate 를 별도로 실행해야 합니다.
    중요
    인증서를 수동으로 설치한 후 항상 ipa-certupdate 를 실행합니다. 그렇지 않으면 인증서가 다른 시스템에 배포되지 않습니다.
외부 CA 설치
외부 CA의 후속 설치는 여러 단계로 구성됩니다.
  1. 설치를 시작합니다.
    [root@ipa-server ~] ipa-ca-install --external-ca
    이 단계 후에는 CSR(인증서 서명 요청)이 저장된 것으로 정보가 표시됩니다. 외부 CA에 CSR을 제출하고 발행된 인증서를 IdM 서버에 복사합니다.
  2. ipa-ca-install 에 인증서와 외부 CA 파일의 전체 경로를 전달하여 설치를 계속합니다.
    [root@ipa-server ~]# ipa-ca-install --external-cert-file=/root/master.crt --external-cert-file=/root/ca.crt
  3. 모든 서버 및 클라이언트에서 ipa-certupdate 유틸리티를 실행하여 LDAP의 새 인증서에 대한 정보로 업데이트합니다. 모든 서버와 클라이언트에서 ipa-certupdate 를 별도로 실행해야 합니다.
    중요
    인증서를 수동으로 설치한 후 항상 ipa-certupdate 를 실행합니다. 그렇지 않으면 인증서가 다른 시스템에 배포되지 않습니다.
CA 설치는 LDAP 및 웹 서버의 기존 서비스 인증서를 설치된 CA에서 발급한 인증서로 대체하지 않습니다. 인증서를 교체하는 방법에 대한 자세한 내용은 26.9절. “웹 서버와 LDAP 서버의 인증서 교체” 을 참조하십시오.

26.9. 웹 서버와 LDAP 서버의 인증서 교체

웹 서버 및 LDAP 서버의 서비스 인증서를 교체하려면 다음을 수행합니다.
  1. 새 인증서 요청. 다음을 사용하여 이 작업을 수행할 수 있습니다.
    • 통합 CA: 보다 자세한 내용은 24.1.1절. “사용자, 호스트 또는 서비스에 대한 새 인증서 요청” 을 참조하십시오.
    • 외부 CA: 개인 키 및 CSR(인증서 서명 요청)을 생성합니다. 예를 들어 OpenSSL을 사용합니다.
      $ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout new.key -out new.csr -subj '/CN=idmserver.idm.example.com,O=IDM.EXAMPLE.COM'
      CSR을 외부 CA에 제출합니다. 프로세스는 외부 CA로 사용할 서비스에 따라 다릅니다.
  2. Apache 웹 서버의 개인 키와 인증서를 교체합니다.
    [root@ipaserver ~]# ipa-server-certinstall -w --pin=password new.key new.crt
  3. LDAP 서버의 개인 키 및 인증서를 교체합니다.
    [root@ipaserver ~]# ipa-server-certinstall -d --pin=password new.key new.cert

27장. IdM의 Kerberos PKINIT 인증

Kerberos에서의 Initial Authentication(PKINIT)용 공개 키 암호화는 Kerberos용 사전 인증 메커니즘입니다. Red Hat Enterprise Linux 7.4부터 IdM(Identity Management) 서버에는 Kerberos PKINIT 인증을 위한 메커니즘이 포함되어 있습니다. 다음 섹션에서는 IdM의 PKINIT 구현에 대한 개요를 제공하고 IdM에서 PKINIT를 구성하는 방법을 설명합니다.

27.1. 다른 IdM 버전의 기본 PKINIT 상태

IdM 서버의 기본 PKINIT 구성은 RHEL(Red Hat Enterprise Linux)의 IdM 버전과 CA(인증 기관) 구성에 따라 다릅니다. 표 27.1. “IdM 버전의 기본 PKINIT 구성” 참조하십시오.

표 27.1. IdM 버전의 기본 PKINIT 구성

RHEL 버전 CA 구성 PKINIT 구성
7.3 이상 CA 없음 로컬 PKINIT: IdM은 서버의 내부 목적으로만 PKINIT를 사용합니다.
7.3 이상 통합 CA 사용
IdM은 통합 IdM CA에서 서명한 인증서를 사용하여 PKINIT를 구성합니다.
시도가 실패하면 IdM은 로컬 PKINIT만 구성합니다.
7.4 이상
CA 없음
IdM에 제공된 외부 PKINIT 인증서 없음
로컬 PKINIT: IdM은 서버의 내부 목적으로만 PKINIT를 사용합니다.
7.4 이상
CA 없음
IdM에 제공되는 외부 PKINIT 인증서
IdM은 외부 Kerberos KMS(키 배포 센터) 인증서 및 CA 인증서를 사용하여 PKINIT를 구성합니다.
7.4 이상 통합 CA 사용 IdM은 IdM CA에서 서명한 인증서를 사용하여 PKINIT를 구성합니다.
도메인 수준 0에서는 PKINIT가 비활성화됩니다. 기본 동작은 로컬 PKINIT입니다. IdM은 서버의 내부 목적으로만 PKINIT를 사용합니다. 7장. 도메인 수준 표시 및 승격 참조하십시오.

27.2. 현재 PKINIT 설정 표시

IdM은 도메인의 PKINIT 구성을 쿼리하는 데 사용할 수 있는 여러 명령을 제공합니다.
도메인에서 PKINIT 상태를 확인하려면 ipa pkinit-status 명령을 사용합니다.
$ ipa pkinit-status
  Server name: server1.example.com
  PKINIT status: enabled
  [...output truncated...]
  Server name: server2.example.com
  PKINIT status: disabled
  [...output truncated...]
로그인한 서버에서 PKINIT 상태를 확인하려면 ipa-pkinit-manage status 명령을 사용합니다.
# ipa-pkinit-manage status
PKINIT is enabled
The ipa-pkinit-manage command was successful
명령은 PKINIT 구성 상태를 enabled 또는 disabled 로 표시합니다.
  • enabled: PKINIT는 통합 IdM CA 또는 외부 PKINIT 인증서에서 서명한 인증서를 사용하여 구성됩니다. 27.1절. “다른 IdM 버전의 기본 PKINIT 상태” 참조하십시오.
  • disabled: IdM은 IdM 서버의 내부 목적으로만 PKINIT를 사용합니다.
IdM 클라이언트용 PKINIT를 지원하는 활성 Kerberos KMS(키 배포 센터)가 있는 IdM 서버를 표시하려면 모든 서버에서 ipa config-show 명령을 사용합니다.
$ ipa config-show
  Maximum username length: 32
  Home directory base: /home
  Default shell: /bin/sh
  Default users group: ipausers
  [...output truncated...]
  IPA masters capable of PKINIT: server1.example.com
  [...output truncated...]

추가 리소스

  • PKINIT 상태를 보고하는 명령줄 툴에 대한 자세한 내용은 ipa help pkinit 명령을 사용합니다.

27.3. IdM에서 PKINIT 구성

IdM 서버가 PKINIT를 비활성화하여 실행 중인 경우 다음 단계를 사용하여 활성화합니다. 예를 들어 ipa-server-install 또는 ipa-replica-install 유틸리티를 사용하여 --no-pkinit 옵션을 전달하면 서버가 PKINIT를 비활성화하여 실행됩니다.

사전 요구 사항

  • CA(인증 기관)가 설치된 모든 IdM 서버가 동일한 도메인 수준에서 실행되고 있는지 확인합니다. 자세한 내용은 7장. 도메인 수준 표시 및 승격 을 참조하십시오.

절차

  1. 서버에서 PKINIT가 활성화되어 있는지 확인합니다.
    # kinit admin
    Password for admin@IPA.TEST:
    # ipa pkinit-status --server=server.idm.example.com
    ----------------
    1 server matched
    ----------------
    Server name: server.idm.example.com
    PKINIT status: enabled
    ----------------------------
    Number of entries returned 1
    ----------------------------
    
    PKINIT가 비활성화된 경우 다음 출력이 표시됩니다.
    # ipa pkinit-status --server server.idm.example.com
    -----------------
    0 servers matched
    -----------------
    ----------------------------
    Number of entries returned 0
    ----------------------------
    
    --server <server_fqdn> 매개변수를 생략하면 명령을 사용하여 PKINIT가 활성화된 모든 서버 를 찾을 수도 있습니다.
  2. CA 없이 IdM을 사용하는 경우:
    1. IdM 서버에서 KDC(Kerberos 키 배포 센터) 인증서에 서명한 CA 인증서를 설치합니다.
      # ipa-cacert-manage install -t CT,C,C ca.pem
    2. 모든 IPA 호스트를 업데이트하려면 모든 복제본 및 클라이언트에서 ipa-certupdate 명령을 반복합니다.
      # ipa-certupdate
    3. ipa-cacert-manage list 명령을 사용하여 CA 인증서가 이미 추가되었는지 확인합니다. 예를 들어 다음과 같습니다.
      # ipa-cacert-manage list
      CN=CA,O=Example Organization
      The ipa-cacert-manage command was successful
      
    4. ipa-server-certinstall 유틸리티를 사용하여 외부 KDC 인증서를 설치합니다. KDC 인증서는 다음 조건을 충족해야 합니다.
      • 일반 이름 CN=fully_qualified_domain_name,certificate_subject_base 로 발급됩니다.
      • Kerberos 보안 주체가 포함 됩니다./REALM_NAME@REALM_NAME.
      • KDC 인증을 위한 OID(Object Identifier)가 포함되어 있습니다. 1.3.6.1.5.2.3.5.
      # ipa-server-certinstall --kdc kdc.pem kdc.key
      # systemctl restart krb5kdc.service
    5. PKINIT 상태를 참조하십시오.
      # ipa pkinit-status
        Server name: server1.example.com
        PKINIT status: enabled
        [...output truncated...]
        Server name: server2.example.com
        PKINIT status: disabled
        [...output truncated...]
      
  3. CA 인증서가 있는 IdM을 사용하는 경우 다음과 같이 PKINIT를 활성화합니다.
    # ipa-pkinit-manage enable
      Configuring Kerberos KDC (krb5kdc)
      [1/1]: installing X509 Certificate for PKINIT
      Done configuring Kerberos KDC (krb5kdc).
      The ipa-pkinit-manage command was successful
    
    IdM CA를 사용하는 경우 명령은 CA에서 PKINIT>-< 인증서를 요청합니다.

추가 리소스

  • 자세한 내용은 ipa-server-certinstall(1) 매뉴얼 페이지를 참조하십시오.

27.4. 추가 리소스

VI 부. 관리: 정책 관리

이 부분에서는 암호 정책을 정의하고, Kerberos 도메인을 관리하며, sudo 유틸리티, 호스트 기반 액세스 제어를 구성하고 SELinux 사용자 맵을 정의하는 방법에 대한 지침을 제공합니다.

28장. 암호 정책 정의

이 장에서는 IdM(Identity Management)의 암호 정책과 관리 방법을 설명합니다.

28.1. 암호 정책이란 무엇이며 왜 사용됩니까

암호 정책은 암호 가 충족해야 하는 규칙 세트입니다.
예를 들어 암호 정책은 최소 암호 길이 및 최대 암호 기간을 정의할 수 있습니다. 이러한 정책의 영향을 받는 모든 사용자는 충분한 긴 암호를 설정하고 자주 변경해야 합니다.
암호 정책은 사용자의 암호를 검색하고 잘못 사용하는 사용자의 위험을 줄이는 데 도움이 됩니다.

28.2. IdM에서 암호 정책이 작동하는 방식

모든 사용자는 IdM(Identity Management) Kerberos 도메인에 인증하는 데 사용하는 암호가 있어야 합니다. IdM의 암호 정책은 이러한 사용자 암호가 충족해야 하는 요구 사항을 정의합니다.
참고
IdM 암호 정책은 기본 LDAP 디렉터리에 설정되지만 KDC(Kerberos 키 배포 센터)에도 적용됩니다.

28.2.1. 지원되는 암호 정책 속성

표 28.1. “암호 정책 속성” IdM의 암호 정책에서 정의할 수 있는 속성을 나열합니다.

표 28.1. 암호 정책 속성

속성 설명 예제
최대 수명 사용자가 암호를 재설정해야 하기 전에 암호가 유효한 최대 시간(일 수)입니다.
최대 수명 = 90
사용자 암호는 90일 동안만 유효합니다. 그런 다음 IdM에서 사용자에게 변경하라는 메시지를 표시합니다.
최소 수명 두 암호 변경 작업 사이에 경과해야 하는 최소 시간(시간)입니다.
최소 수명 = 1
사용자가 암호를 변경한 후 다시 변경하기 전에 1시간 이상 기다려야 합니다.
기록 크기
이전에 저장된 암호 수는 몇 개입니까. 사용자는 암호 내역에서 암호를 재사용할 수 없습니다.
기록 크기 = 0
사용자는 이전 암호를 다시 사용할 수 있습니다.
문자 클래스 사용자가 암호에 사용해야 하는 여러 문자 클래스의 수입니다. 문자 클래스는 다음과 같습니다.
  • 대문자
  • 소문자
  • 숫자
  • 특수 문자(예: 쉼표(,), 마침표(.), 별표(*)
  • 기타 UTF-8 문자
행에 세 번 이상 문자를 사용하면 문자 클래스가 1씩 줄어듭니다. 예를 들어 다음과 같습니다.
  • Secret1 에는 대문자, 소문자, 숫자의 세 가지 문자 클래스가 있습니다.
  • Secret111 은 대문자, 소문자, 숫자 및 -1의 문자 클래스 1 을 반복적으로 사용하는 경우의 두 가지 문자 클래스가 있습니다.
문자 클래스 = 0
기본적으로 필요한 클래스 수는 0입니다. 번호를 구성하려면 --minclasses 옵션을 사용하여 ipa pwpolicy-mod 명령을 실행합니다. 이 명령은 필요한 문자 클래스 수를 1로 설정합니다.
$ ipa pwpolicy-mod --minclasses=1
이 표 아래의 중요 참고 사항도 참조하십시오.
최소 길이 암호의 최소 문자 수입니다.
최소 길이 = 8
사용자는 8자보다 짧은 암호를 사용할 수 없습니다.
최대 실패 수 IdM이 사용자 계정을 잠그기 전에 로그인 시도 횟수입니다. 22.1.3절. “암호 실패 후 사용자 계정 잠금 해제” 참조하십시오.
최대 실패 = 6
IdM은 사용자가 잘못된 암호를 7번 행에 입력한 사용자 계정을 잠급니다.
실패 재설정 간격 IdM에서 로그인 시도 실패 횟수를 현재 재설정한 후 시간(초)입니다.
실패 재설정 간격 = 60
사용자가 Max 에 정의된 로그인 시도 횟수가 1분 이상 기다린 후 사용자 계정 잠금 위험 없이 다시 로그인할 수 있습니다.
잠금 기간 Max에 정의된 로그인 시도 횟수 후 사용자 계정이 잠는 시간(초)입니다. 22.1.3절. “암호 실패 후 사용자 계정 잠금 해제” 참조하십시오.
잠금 기간 = 600
계정이 잠긴 사용자는 10분 동안 로그인할 수 없습니다.
중요
국제 문자와 기호에 액세스할 수 없는 다양한 하드웨어 집합이 있는 경우 문자 클래스에 대한 영문자와 공통 기호를 사용합니다. 암호의 문자 클래스 정책에 대한 자세한 내용은 Red Hat Knowledgebase의 암호에 유효한 문자는 무엇입니까?를 참조하십시오.

28.2.2. 글로벌 및 그룹별 암호 정책

기본 암호 정책은 글로벌 암호 정책입니다. 글로벌 정책 외에도 추가 그룹 암호 정책을 만들 수 있습니다.
글로벌 암호 정책
초기 IdM 서버를 설치하면 기본 설정으로 글로벌 암호 정책이 자동으로 생성됩니다.
글로벌 정책 규칙은 그룹 암호 정책이 없는 모든 사용자에게 적용됩니다.
그룹 암호 정책
그룹 암호 정책은 해당 사용자 그룹의 모든 구성원에게 적용됩니다.
사용자가 한 번에 하나의 암호 정책만 적용할 수 있습니다. 사용자에게 여러 암호 정책이 할당된 경우 해당 정책 중 하나가 우선 순위에 따라 우선합니다. 28.2.3절. “암호 정책 우선순위” 참조하십시오.

28.2.3. 암호 정책 우선순위

모든 그룹 암호 정책에는 우선 순위 가 설정되어 있습니다. 값이 낮을수록 정책의 우선 순위가 높습니다. 지원되는 가장 낮은 우선 순위 값은 0 입니다.
  • 사용자에게 여러 암호 정책이 적용되는 경우 우선 순위가 가장 낮은 정책이 우선합니다. 다른 정책에 정의된 모든 규칙은 무시됩니다.
  • 우선 순위 값이 가장 낮은 암호 정책은 정책에 정의되지 않은 속성도 모든 암호 정책 속성에 적용됩니다.
글로벌 암호 정책에는 우선 순위 값이 설정되지 않습니다. 사용자에게 그룹 정책이 설정되지 않은 경우 대체 정책 역할을 합니다. 글로벌 정책은 그룹 정책보다 우선할 수 없습니다.
표 28.2. “우선 순위에 따라 암호 정책 속성 적용 예” 정책이 정의된 두 그룹에 속하는 사용자의 예에서 암호 정책 우선순위가 작동하는 방식을 보여줍니다.

표 28.2. 우선 순위에 따라 암호 정책 속성 적용 예

최대 수명 최소 길이
그룹 A (우선 순위 0)의 정책 60 10
B 그룹 (우선 순위 1)의 정책 90 0 (제한 없음)
사용자(그룹 A 및 그룹 B의 구성원) 60 10
참고
ipa pwpolicy-show --user=user_name 명령은 특정 사용자에게 현재 적용되는 정책을 표시합니다.

28.3. 새 암호 정책 추가

새 암호 정책을 추가할 때는 다음을 지정해야 합니다.
다음을 사용하여 새 암호 정책을 추가하려면 다음을 수행합니다.

웹 UI: 새 암호 정책 추가

  1. PolicyPassword Policies 선택합니다.
  2. 추가를 클릭합니다.
  3. 사용자 그룹과 우선 순위를 정의합니다.
  4. 추가를 클릭하여 확인합니다.
새 암호 정책의 속성을 구성하려면 28.4절. “암호 정책 속성 수정” 을 참조하십시오.

명령줄: 새 암호 정책 추가

  1. ipa pwpolicy-add 명령을 사용합니다. 사용자 그룹과 우선 순위를 지정합니다.
    $ ipa pwpolicy-add
    Group: group_name
    Priority: priority_level
  2. 선택 사항입니다. ipa pwpolicy-find 명령을 사용하여 정책이 성공적으로 추가되었는지 확인합니다.
    $ ipa pwpolicy-find
새 암호 정책의 속성을 구성하려면 28.4절. “암호 정책 속성 수정” 을 참조하십시오.

28.4. 암호 정책 속성 수정

중요
암호 정책을 수정하면 새 규칙은 새 암호에만 적용됩니다. 변경 사항은 기존 암호에 소급 적용되지 않습니다.
변경을 적용하려면 사용자가 기존 암호를 변경하거나 관리자가 다른 사용자의 암호를 재설정해야 합니다. 22.1.1절. “사용자 암호 변경 및 재설정” 참조하십시오.
참고
보안 사용자 암호에 대한 권장 사항은 보안 가이드의 암호 보안을 참조하십시오.
다음을 사용하여 암호 정책을 수정하려면 다음을 수행합니다.
암호 정책 특성을 0 으로 설정하면 속성 제한이 없음을 의미합니다. 예를 들어 최대 수명을 0 으로 설정하면 사용자 암호가 만료되지 않습니다.

웹 UI: 암호 정책 수정

  1. PolicyPassword Policies 선택합니다.
  2. 변경할 정책을 클릭합니다.
  3. 필수 특성을 업데이트합니다. 사용 가능한 속성에 대한 자세한 내용은 28.2.1절. “지원되는 암호 정책 속성” 을 참조하십시오.
  4. 저장 을 클릭하여 변경 사항을 확인합니다.

명령줄: 암호 정책 수정

  1. ipa pwpolicy-mod 명령을 사용하여 정책 특성을 변경합니다.
    1. 예를 들어 글로벌 암호 정책을 업데이트하고 최소 암호 길이를 10 으로 설정하려면 다음을 수행합니다.
      $ ipa pwpolicy-mod --minlength=10
    2. 그룹 정책을 업데이트하려면 ipa pwpolicy-mod 에 그룹 이름을 추가합니다. 예를 들어 다음과 같습니다.
      $ ipa pwpolicy-mod group_name --minlength=10
  2. 선택 사항입니다. ipa pwpolicy-show 명령을 사용하여 새 정책 설정을 표시합니다.
    1. 글로벌 정책을 표시하려면 다음을 수행합니다.
      $ ipa pwpolicy-show
    2. 그룹 정책을 표시하려면 ipa pwpolicy-show:에 그룹 이름을 추가합니다.
      $ ipa pwpolicy-show group_name

28.5. Immediate Effect를 사용하여 암호 만료 날짜 변경

ipa user-mod 또는 ldapmodify 유틸리티를 사용하여 사용자 암호의 만료 날짜를 변경할 수 있습니다.

ipa user-mod 유틸리티를 사용하여 사용자 암호의 만료일 변경

  • 만료 날짜를 즉시 변경하려면 --password-expiration 옵션과 함께 ipa user-mod 명령을 사용합니다. 예를 들어 UTC 시간대에서 만료 날짜를 2016-02-03 20:37:34 로 설정하려면 다음을 실행합니다.
    # ipa user-mod user_name --password-expiration='2016-02-03 20:37:34Z'
    명령은 일반화된 시간 형식을 사용하고 만료 날짜를 20160203203734Z 로 설정할 수도 있습니다.

ldapmodify 유틸리티를 사용하여 사용자 암호의 만료일 변경

만료 날짜를 즉시 변경하려면 LDAP에서 krbPasswordExpiration 특성 값을 재설정합니다.
단일 사용자의 만료 날짜를 변경하려면 다음을 수행합니다.
  1. 다음 명령을 사용하여 사용자 항목의 krbPasswordExpiration 속성에 대한 새 값을 설정합니다.
     # ldapmodify -D "cn=Directory Manager" -w secret -h server.example.com -p 389 -vv
    
    dn: uid=user_name,cn=users,cn=accounts,dc=example,dc=com
    changetype: modify
    replace: krbPasswordExpiration
    krbPasswordExpiration: 20160203203734Z
    krbPasswordExpiration 형식은 일반화된 시간 형식 YYYYMMDDHHMMSS.0Z를 따릅니다.
  2. Ctrl+D 눌러 변경 사항을 확인하고 서버에 보냅니다.
한 번에 여러 항목을 편집하려면 -f 옵션과 함께 ldapmodify 를 사용하여 LDIF 파일을 참조합니다.

29장. Kerberos 도메인 관리

이 장에서는 ID 관리 서버의 KDC(Kerberos 키 배포 센터) 구성 요소에 대해 설명합니다.
중요
kadmin 또는 kadmin.local 유틸리티를 사용하여 Identity Management Kerberos 정책을 관리하지 마십시오. 이 가이드에 설명된 대로 기본 ID 관리 명령줄 도구를 사용합니다.
언급된 Kerberos 도구를 사용하여 ID 관리 정책을 관리하려고 하면 일부 작업은 해당 Directory Server 인스턴스에 저장된 ID 관리 구성에 영향을 미치지 않습니다.

29.1. Kerberos 티켓 정책 관리

ID 관리의 Kerberos 티켓 정책은 티켓 기간 및 갱신에 대한 제한을 설정합니다. 다음 절차에 따라 ID 관리 서버에서 실행되는 Kerberos KDC(키 배포 센터)에 대한 Kerberos 티켓 정책을 구성할 수 있습니다.

29.1.1. Kerberos 티켓의 수명 확인

ID 관리 클라이언트가 user_name 대신 Kerberos 티켓을 요청한 후 ID 관리 클라이언트가 부여될 티켓의 수명을 결정하는 경우 몇 가지 매개 변수가 고려됩니다. 먼저 kinit 명령 및 /etc/krb5.conf 파일의 ticket_lifetime 설정에 따라 요청할 값을 계산하는 클라이언트 쪽 평가가 수행됩니다. 그런 다음 값은 서버 측 평가가 수행되는 ID 관리 서버로 전송됩니다. 요청된 수명이 전역 설정에서 허용하는 것보다 낮은 경우 요청된 수명 주기가 부여됩니다. 그렇지 않은 경우 부여되는 수명은 전역 설정에서 허용하는 값입니다.
user_name 대신 클라이언트가 요청한 수명은 다음과 같이 결정됩니다.

고객측

  • -l 옵션을 사용하여 kinit 명령 자체에서 user_name 의 값을 명시적으로 표시하는 경우 예를 들면 다음과 같습니다.
    $ kinit user_name -l 90000
    이 경우 90000초는 user_name 을 대신하여 클라이언트에서 해당 값을 요청합니다.
  • 또는 kinit user_name 명령의 인수로 라이프사이클 값이 전달되지 않으면 클라이언트의 /etc/krb5.conf 파일의 ticket_lifetime 설정 값이 user_name 대신 클라이언트에 의해 사용됩니다. /etc/krb5.conf 파일에 값이 지정되지 않은 경우 초기 티켓 요청의 기본 IdM 값이 사용됩니다.

서버측

서버 측에서 2단계 평가가 수행됩니다.
  1. 클라이언트에서 요청한 값은 user_name- 이러한 정책이 존재하는 경우 특정 Kerberos 티켓 정책의 --maxlife 설정과 비교되고 두 정책의 하위 값이 선택됩니다. user_name- 특정 Kerberos 티켓 정책이 없으면 클라이언트에서 보낸 값이 Global Kerberos 티켓 정책의 --maxlife 설정과 비교되고 이 둘 중 더 낮은 값이 선택됩니다. 글로벌 및 사용자별 Kerberos 티켓 정책에 대한 자세한 내용은 29.1.2절. “글로벌 및 사용자별 Kerberos 티켓 정책” 을 참조하십시오.
  2. 이전 단계에서 선택한 값은 다음 두 개의 다른 값과 비교됩니다.
    • /var/kerberos/krb5kdc/kdc.conf 파일의 max_life 설정 값
    • 고유 이름(DN):ECDHE PrincipalName= krbtgt/REALM_NAME@REALM_NAME,cn=NAME ,cn=kerberos,domain_name 을 사용하여 LDAP 항목의>-<MaxTicketLife속성에 설정된 값
    세 값 중 최저가 궁극적으로 user_name 에 부여된 Kerberos 티켓의 수명 동안 선택됩니다.

29.1.2. 글로벌 및 사용자별 Kerberos 티켓 정책

글로벌 Kerberos 티켓 정책을 재정의하고 개별 사용자에게 특별히 추가 정책을 정의할 수 있습니다.
글로벌 Kerberos 티켓 정책
글로벌 정책은 ID 관리 Kerberos 영역 내에서 발행된 모든 티켓에 적용됩니다.
사용자별 Kerberos 티켓 정책
사용자별 정책은 연결된 사용자 계정에만 적용됩니다. 예를 들어 사용자별 Kerberos 티켓 정책은 관리자 의 최대 티켓 수명을 정의할 수 있습니다.
사용자별 정책은 글로벌 정책보다 우선합니다.

29.1.3. 글로벌 Kerberos 티켓 정책 구성

글로벌 Kerberos 티켓 정책을 구성하려면 다음을 사용합니다.

표 29.1. 지원되는 Kerberos 티켓 정책 속성

속성 설명 예제
최대 갱신 수
사용자가 만료 후 Kerberos 티켓을 갱신할 수 있는 시간(초)입니다. 갱신 기간이 지난 후 사용자는 kinit 유틸리티를 사용하여 새 티켓을 받아야 합니다.
티켓을 갱신하려면 kinit -R 명령을 사용합니다.
최대 갱신 = 604800
티켓이 만료되면 사용자는 다음 7일 이내에 갱신할 수 있습니다(604,800초).
최대 수명 Kerberos 티켓의 수명(초). Kerberos 티켓이 활성화된 기간입니다.
최대 수명 = 86400
티켓은 발행된 후 24시간(86,400초) 후에 만료됩니다.

웹 UI: 글로벌 Kerberos 티켓 정책 구성

  1. PolicyKerberos ticket Policy를 선택합니다.
  2. 필요한 값을 정의합니다.
    1. Max renew (최대 갱신) 필드에 Kerberos 티켓의 최대 갱신 기간을 입력합니다.
    2. 최대 수명 필드에 Kerberos 티켓의 최대 수명을 입력합니다.

      그림 29.1. 글로벌 Kerberos 티켓 정책 구성

      글로벌 Kerberos 티켓 정책 구성
  3. 저장을 클릭합니다.

명령줄: 글로벌 Kerberos 티켓 정책 구성

글로벌 Kerberos 티켓 정책을 수정하려면 다음을 수행합니다.
  • ipa>-<tpolicy-mod 명령을 사용하고 다음 옵션 중 하나 이상을 전달합니다.
    • Kerberos 티켓의 최대 갱신 기간을 정의하는 --maxrenew
    • Kerberos 티켓의 최대 수명 주기를 정의하는 --maxlife
    예를 들어 최대 수명을 변경하려면 다음을 수행합니다.
    $ ipa krbtpolicy-mod --maxlife=80000
    Max life: 80000
    Max renew: 604800
글로벌 Kerberos 티켓 정책을 원래 기본값으로 재설정하려면 다음을 수행합니다.
  1. ipa>-<tpolicy-reset 명령을 사용합니다.
  2. 선택 사항입니다. ipa>-<tpolicy-show 명령을 사용하여 현재 설정을 확인합니다.
ipa>-<tpolicy-modipa>-<tpolicy-reset 에 대한 자세한 내용은 --help 옵션을 전달합니다.

29.1.4. 사용자별 Kerberos 티켓 정책 구성

특정 사용자에 대한 Kerberos 티켓 정책을 수정하려면 다음을 수행합니다.
  1. ipa>-<tpolicy-mod user_name 명령을 사용하고 다음 옵션 중 하나를 전달합니다.
    • Kerberos 티켓의 최대 갱신 기간을 정의하는 --maxrenew
    • Kerberos 티켓의 최대 수명 주기를 정의하는 --maxlife
    특성 중 하나만 정의하는 경우 Identity Management는 다른 속성에 대한 글로벌 Kerberos 티켓 정책 값을 적용합니다.
    예를 들어 admin 사용자의 최대 수명을 변경하려면 다음을 수행합니다.
    $ ipa krbtpolicy-mod admin --maxlife=160000
    Max life: 80000
    Max renew: 604800
  2. 선택 사항입니다. ipa>-<tpolicy-show user_name 명령을 사용하여 지정된 사용자의 현재 값을 표시합니다.
새 정책은 kinit 유틸리티 사용 시와 같이 사용자가 요청한 다음 Kerberos 티켓에 즉시 적용됩니다.
사용자별 Kerberos 티켓 정책을 재설정하려면 ipa>-<tpolicy-reset user_name 명령을 사용합니다. 명령은 사용자에게 구체적으로 정의된 값을 지운 다음 Identity Management에서 글로벌 정책 값을 적용합니다.
ipa>-<tpolicy-modipa>-<tpolicy-reset 에 대한 자세한 내용은 --help 옵션을 전달합니다.

29.2. Kerberos 보안 주체 다시 키 입력

Kerberos 주체를 다시 키 입력하면 더 높은 키 버전 번호(KVNO)를 사용하는 새 키탭 항목이 보안 주체의 키 탭에 추가됩니다. 원래 항목은 키 탭에 남아 있지만 더 이상 티켓을 발급하는 데 사용되지 않습니다.
  1. 필요한 기간 내에 발행된 모든 키탭을 찾습니다. 예를 들어, 다음 명령은 ldapsearch 유틸리티를 사용하여 2016년 1월 1일에 자정 사이에 생성된 모든 호스트 및 서비스 주체를 표시하고 2016년 12월 31일 Greenwich Mean Time(GMT)에 11:59 PM을 표시합니다.
    # ldapsearch -x -b "cn=computers,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20160101000000)(krblastpwdchange<=20161231235959))" dn krbprincipalname
    # ldapsearch -x -b "cn=services,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20160101000000)(krblastpwdchange<=20161231235959))" dn krbprincipalname
    • searchbase(-b)는 ldapsearch 가 보안 주체를 찾는 하위 트리를 정의합니다.
      • 호스트 주체는 cn=ECDHEs,cn=accounts,dc=example,dc=com 하위 트리 아래에 저장됩니다.
      • 서비스 주체는 cn=services,cn=accounts,dc=example,dc=com 하위 트리에 저장됩니다.
    • & gt;-<lastpwdchange 매개변수는 마지막 변경 날짜로 검색 결과를 필터링합니다. 매개 변수는 날짜의 YYYYMMDD 형식을 사용할 수 있으며 시간 동안 HHMMSS 형식을 의 시간으로 허용합니다.
    • dn 및>- <principalname 특성을 지정하면 검색 결과가 항목 이름 및 보안 주체로 제한됩니다.
  2. 보안 주체를 다시 입력해야 하는 모든 서비스 및 호스트에 대해 ipa-getkeytab 유틸리티를 사용하여 새 keytab 항목을 검색합니다. 다음 옵션을 전달합니다.
    • --principal (-p)을 사용하여 주체를 지정합니다.
      --keytab (-k)을 사용하여 원래 키 탭의 위치를 지정합니다.
      ID 관리 서버 호스트 이름을 지정하는 --server (-s)
    예를 들어 다음과 같습니다.
    • /etc/krb5.keytab 의 기본 위치에 keytab을 사용하여 호스트 주체를 다시 입력하려면 다음을 수행합니다.
      # ipa-getkeytab -p host/client.example.com@EXAMPLE.COM -s server.example.com -k /etc/krb5.keytab
    • /etc/httpd/conf/ipa.keytab 의 기본 위치에 Apache 서비스의 keytab을 다시 입력하려면 다음을 수행합니다.
      # ipa-getkeytab -p HTTP/client.example.com@EXAMPLE.COM -s server.example.com -k /etc/httpd/conf/ipa.keytab
      중요
      NFS 버전 4와 같은 일부 서비스는 제한된 암호화 유형 세트만 지원합니다. 적절한 인수를 ipa-getkeytab 명령에 전달하여 키 탭을 올바르게 구성합니다.
  3. 선택 사항입니다. 보안 주체를 다시 키를 다시 입력했는지 확인합니다. klist 유틸리티를 사용하여 모든 Kerberos 티켓을 나열합니다. 예를 들어 /etc/krb5.keytab 의 모든 keytab 항목을 나열하려면 다음을 수행합니다.
    # klist -kt /etc/krb5.keytab
    Keytab: WRFILE:/etc/krb5.keytab
    KVNO Timestamp         Principal
    ---- ----------------- --------------------------------------------------------
       1 06/09/16 05:58:47 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
       2 06/09/16 11:23:01 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
       1 03/09/16 13:57:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
       1 03/09/16 13:57:16 HTTP/server.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
       1 03/09/16 13:57:16 ldap/server.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
    
    출력에는 client.example.com 의 keytab 항목이 더 높은 KVNO로 다시 입력되었음이 표시됩니다. 원본 키탭은 이전 KVNO를 통해 데이터베이스에 계속 존재합니다.
    이전 키탭에 대해 발행된 티켓은 계속 작동하지만 KVNO 가장 높은 키를 사용하여 새 티켓이 발급됩니다. 따라서 시스템 운영 중단을 방지할 수 있습니다.

29.3. 키 탭 보호

서버에 대한 액세스 권한이 있는 다른 사용자로부터 Kerberos keytab을 보호하려면 keytab에 대한 액세스를 키tab 소유자로만 제한합니다. 키탭을 검색한 직후 보호하는 것이 좋습니다.
예를 들어 /etc/httpd/conf/ipa.keytab 에서 Apache keytab을 보호하려면 다음을 수행합니다.
  1. 파일의 소유자를 apache 로 설정합니다.
    # chown apache /etc/httpd/conf/ipa.keytab
  2. 파일의 권한을 0600 으로 설정합니다. 이는 소유자에게 읽기, 쓰기, 실행 권한을 부여합니다.
    # chmod 0600 /etc/httpd/conf/ipa.keytab

29.4. 키 탭 제거

예를 들어 호스트 등록을 취소하고 다시 등록하거나 Kerberos 연결 오류가 발생하는 경우 키탭을 제거하고 새 키탭을 만들어야 합니다.
호스트의 모든 키탭을 제거하려면 ipa-rmkeytab 유틸리티를 사용하여 다음 옵션을 전달합니다.
  • Kerberos 영역을 지정하기 위한 --realm (-r)
  • --keytab (-k) 키탭 파일의 경로를 지정합니다
# ipa-rmkeytab --realm EXAMPLE.COM --keytab /etc/krb5.keytab
특정 서비스의 키탭을 제거하려면 --principal (-p) 옵션을 사용하여 서비스 주체를 지정합니다.
# ipa-rmkeytab --principal ldap/client.example.com --keytab /etc/krb5.keytab

30장. sudo사용

Identity Management는 IdM 도메인에 예측 가능하고 일관되게 sudo 정책을 적용하기 위한 메커니즘을 제공합니다. IdM 도메인의 모든 시스템은 sudo 클라이언트로 구성할 수 있습니다.

30.1. Identity Management의 sudo utility

sudo 유틸리티는 지정된 사용자에게 관리 권한을 부여합니다. 신뢰할 수 있는 사용자가 sudo 를 사용하여 관리 명령 앞에 있는 경우 해당 사용자의 암호를 입력하라는 메시지가 표시됩니다. 그런 다음, 인증되고 명령이 허용되었다고 가정하면 root 사용자인 것처럼 관리 명령이 실행됩니다. sudo 에 대한 자세한 내용은 시스템 관리자 가이드를 참조하십시오.

30.1.1. sudo용 ID 관리 LDAP 스키마

IdM에는 sudo 항목을 위한 특수 LDAP 스키마가 있습니다. 스키마는 다음을 지원합니다.
  • 호스트 그룹 및 넷그룹. sudo 는 netgroups만 지원합니다.
  • sudo 명령 그룹 - 여러 명령이 포함되어 있습니다.
참고
sudo 는 호스트 그룹 또는 명령 그룹을 지원하지 않기 때문에 IdM은 sudo 규칙이 생성될 때 IdM sudo 구성을 기본 sudo 구성으로 변환합니다. 예를 들어, IdM은 모든 호스트 그룹에 대해 해당 shadow netgroup을 생성하여 IdM 관리자가 호스트 그룹을 참조하는 sudo 규칙을 생성할 수 있는 반면 로컬 sudo 명령은 해당 netgroup을 사용합니다.
기본적으로 sudo 정보는 LDAP에서 사용할 수 없습니다. 따라서 IdM은 uid= sudo,cn=sysaccounts,cn=etc,$SUFFIX 에 기본 sudo 사용자를 정의합니다. LDAP sudo 설정 파일 /etc/sudo-ldap.conf 에서 이 사용자를 변경할 수 있습니다.

30.1.2. NIS 도메인 이름 요구 사항

netgroups 및 sudo 가 제대로 작동하려면 NIS 도메인 이름을 설정해야 합니다. sudo 구성을 사용하려면 netgroup의 NIS 형식의 netgroups 및 NIS 도메인 이름이 필요합니다. 그러나 IdM에는 NIS 도메인이 실제로 존재할 필요가 없습니다. NIS 서버를 설치할 수도 없습니다.
참고
ipa-client-install 유틸리티는 기본적으로 NIS 도메인 이름을 IdM 도메인 이름으로 자동으로 설정합니다.

30.2. Identity Management의 sudo 규칙

sudo 규칙을 사용하면 누가 무엇을 할 수있는지, 어디서, 어떤 사람인지 정의할 수 있습니다.
  • 누가 sudo 를 사용할 수 있었습니까?
  • sudo 와 함께 사용할 수 있는 명령은 무엇입니까.
  • 사용자가 sudo 를 사용할 수 있는 대상 호스트는 어디에 있습니까.
  • 사용자가 작업을 수행한다고 가정하는 시스템 또는 기타 사용자 ID 누구입니까.

30.2.1. 외부 사용자 및 호스트 sudo 규칙

IdM은 sudo 규칙에서 외부 엔티티를 허용합니다. 외부 엔터티는 IdM 도메인 외부에 저장된 엔터티입니다(예: IdM 도메인에 속하지 않는 사용자 또는 호스트).
예를 들어 sudo 규칙을 사용하여 IdM의 IT 그룹 멤버에 대한 root 액세스 권한을 부여할 수 있습니다. 여기서 root 사용자는 IdM 도메인에 정의된 사용자가 아닙니다. 또는 관리자가 네트워크에 있지만 IdM 도메인의 일부가 아닌 특정 호스트에 대한 액세스를 차단할 수 있습니다.

30.2.2. sudo 규칙에 대한 사용자 그룹 지원

sudo 를 사용하여 IdM의 전체 사용자 그룹에 액세스 권한을 부여할 수 있습니다. IdM은 Unix 및 비POSIX 그룹을 둘 다 지원합니다. 비POSIX 그룹을 만들면 비POSIX 그룹의 사용자가 그룹에서 non-POSIX 권한을 상속하기 때문에 액세스 문제가 발생할 수 있습니다.

30.2.3. sudoers 옵션 지원

IdM은 sudoers 옵션을 지원합니다. 사용 가능한 sudoers 옵션의 전체 목록은 sudoers(5) 도움말 페이지를 참조하십시오.
IdM은 sudoers 옵션에서 공백이나 줄 바꿈을 허용하지 않습니다. 따라서 여러 옵션을 쉼표로 구분된 목록으로 제공하는 대신 별도로 추가합니다. 예를 들어 명령줄에서 두 개의 sudoers 옵션을 추가하려면 다음을 수행합니다.
$ ipa sudorule-add-option sudo_rule_name
Sudo Option: first_option
$ ipa sudorule-add-option sudo_rule_name
Sudo Option: second_option
마찬가지로 한 줄에 긴 옵션을 제공해야 합니다. 예를 들어 명령줄에서 다음을 수행합니다.
$ ipa sudorule-add-option sudo_rule_name
Sudo Option: env_keep="COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 XAUTHORITY"

30.3. sudo 정책 검색을 위한 위치 구성

sudo 구성을 위한 중앙 집중식 IdM 데이터베이스를 사용하면 모든 도메인 호스트에서 IdM에 정의된 sudo 정책을 전역적으로 사용할 수 있습니다. Red Hat Enterprise Linux 7.1 시스템 이상에서는 ipa-server-installipa-client-install 유틸리티에서 SSSD를 sudo 의 데이터 공급자로 설정하여 시스템이 IdM 정의 정책을 사용하도록 자동으로 구성됩니다.
sudo 정책을 조회하기 위한 위치는 /etc/nsswitch.conf 파일의 sudoers 행에 정의되어 있습니다. Red Hat Enterprise Linux 7.1 이상을 실행하는 IdM 시스템에서 nsswitch.conf 의 기본 sudoers 구성은 다음과 같습니다.
sudoers: files sss
files 옵션은 시스템이 /etc/sudoers 로컬 SSSD 구성 파일에 정의된 sudo 구성을 사용하도록 지정합니다. sss 옵션은 IdM에 정의된 sudo 구성이 사용되도록 지정합니다.

30.3.1. IdM 이전 버전에서 IdM sudo 정책을 사용하도록 호스트 구성

7.1 이전 Red Hat Enterprise Linux 버전을 실행하는 IdM 시스템에 IdM 정의 sudo 정책을 구현하려면 로컬 시스템을 수동으로 설정합니다. SSSD 또는 LDAP를 사용하여 이 작업을 수행할 수 있습니다. Red Hat은 SSSD 기반 구성을 사용할 것을 강력하게 권장합니다.

30.3.1.1. SSSD를 사용하여 호스트에 sudo 정책 적용

sudo 규칙에 SSSD를 사용하는 데 필요한 각 시스템에서 다음 단계를 따르십시오.
  1. sudoers 파일에 대해 SSSD를 찾도록 sudo 를 설정합니다.
    # vim /etc/nsswitch.conf
    
    sudoers:  files sss
    files 옵션을 제 위치에 두면 sudo 가 IdM 구성에 SSSD를 확인하기 전에 로컬 구성을 확인할 수 있습니다.
  2. 로컬 SSSD 클라이언트가 관리하는 서비스 목록에 sudo 를 추가합니다.
    # vim /etc/sssd/sssd.conf
    
    [sssd]
    config_file_version = 2
    services = nss, pam, sudo
    domains = IPADOMAIN
  3. sudo 구성에서 NIS 도메인의 이름을 설정합니다. sudo 는 NIS 스타일 netgroups를 사용하므로 IdM sudo 구성에 사용된 호스트 그룹을 찾을 수 있도록 sudo 의 시스템 구성에 NIS 도메인 이름을 설정해야 합니다.
    1. 재부팅해도 NIS 도메인 이름이 지속되는지 확인하기 위해 rhel-domainname 서비스를 활성화하십시오.
      # systemctl enable rhel-domainname.service
    2. sudo 규칙에 사용할 NIS 도메인 이름을 설정합니다.
      # nisdomainname example.com
    3. NIS 도메인 이름을 지속하도록 시스템 인증 설정을 구성합니다. 예를 들어 다음과 같습니다.
      # echo "NISDOMAIN=example.com" >> /etc/sysconfig/network
      이렇게 하면 /etc/sysconfig/network/etc/yp.conf 파일이 NIS 도메인으로 업데이트됩니다.
    4. rhel-domainname 서비스를 다시 시작합니다.
      # systemctl restart rhel-domainname.service
  4. 선택적으로 SSSD에서 디버깅을 활성화하여 사용 중인 LDAP 설정을 표시합니다.
    [domain/IPADOMAIN]
    debug_level = 6
    ....
    SSSD에서 작업에 사용하는 LDAP 검색 기반은 sssd_DOMAINNAME.log 로그에 기록됩니다.

30.3.1.2. LDAP를 사용하여 호스트에 sudo 정책 적용

중요
SSSD를 사용하지 않는 클라이언트에는 LDAP 기반 설정만 사용합니다. Red Hat은 30.3.1.1절. “SSSD를 사용하여 호스트에 sudo 정책 적용” 에 설명된 대로 SSSD 기반 구성을 사용하여 기타 모든 클라이언트를 구성할 것을 권장합니다.
LDAP를 사용하여 sudo 정책 적용에 대한 자세한 내용은 Red Hat Enterprise Linux 6 Identity Management Guide 에서 LDAP를 사용하여 호스트에 sudo 정책 적용을 참조하십시오.
LDAP 기반 구성은 주로 Red Hat Enterprise Linux 7 이전 Red Hat Enterprise Linux 버전을 기반으로 하는 클라이언트에 사용됩니다. 따라서 Red Hat Enterprise Linux 6에 대한 설명서에만 설명되어 있습니다.

30.4. sudo 명령, 명령 그룹, 규칙 추가

30.4.1. sudo 명령 추가

웹 UI에 sudo 명령 추가

  1. Policy 탭에서 SudoSudo 명령을 클릭합니다.
  2. 목록 위쪽에서 추가 를 클릭합니다.
  3. 명령에 대한 정보를 입력합니다. 실행 가능한 명령의 전체 시스템 경로를 입력합니다.

    그림 30.1. 새 sudo 명령 추가

    새 sudo 명령 추가
  4. 추가를 클릭합니다. 또는 추가 를 클릭하고 다른 항목 추가 또는 추가 및 편집 을 클릭하여 새 항목 편집을 시작합니다.

명령줄에서 sudo 명령 추가

sudo 명령을 추가하려면 ipa sudocmd-add 명령을 사용합니다. 실행 가능한 명령에 대한 전체 시스템 경로를 제공합니다. 예를 들어 /usr/bin/less 명령 및 설명을 추가하려면 다음을 수행합니다.
$ ipa sudocmd-add /usr/bin/less --desc="For reading log files"
----------------------------------
Added sudo command "/usr/bin/less"
----------------------------------
  sudo Command: /usr/bin/less
  Description: For reading log files

30.4.2. sudo 명령 그룹 추가

웹 UI에 sudo 명령 그룹 추가

  1. Policy 탭에서 SudoSudo 명령 그룹을 클릭합니다.
  2. 목록 위쪽에서 추가 를 클릭합니다.
  3. 명령 그룹에 대한 정보를 입력합니다.

    그림 30.2. 새 sudo 명령 그룹 추가

    새 sudo 명령 그룹 추가
  4. 추가 및 편집 을 클릭하여 명령 그룹 편집을 시작합니다.
  5. Sudo 명령 탭에서 추가 를 클릭하여 그룹에 sudo 명령을 추가합니다. 필요한 명령을 선택하고 > 버튼을 사용하여 Prospective 열로 이동합니다.

    그림 30.3. sudo 명령 그룹에 명령 추가

    sudo 명령 그룹에 명령 추가
  6. 추가를 클릭합니다.

명령줄에서 sudo 명령 그룹 추가

  1. ipa sudocmdgroup-add 명령을 사용하여 명령 그룹을 생성합니다. 예를 들어 files 명령 그룹을 생성하고 설명을 추가하려면 다음을 수행합니다.
    $ ipa sudocmdgroup-add files --desc="File editing commands"
    -----------------------------------
    Added sudo command group "files"
    -----------------------------------
      sudo Command Group: files
      Description: File editing commands
  2. ipa sudo cmdgroup-add-member 명령을 사용하여 그룹에 sudo 명령을 포함합니다. 30.4.1절. “sudo 명령 추가” 에 설명된 대로 IdM에 이미 추가된 명령만 포함할 수 있습니다.
    $ ipa sudocmdgroup-add-member files --sudocmds "/usr/bin/vim"
      sudo Command Group: files
      Description: File editing commands
      Member sudo commands: /usr/bin/vim
    -------------------------
    Number of members added 1
    -------------------------

30.4.3. sudo 규칙 추가

웹 UI에 sudo 규칙 추가

  1. Policy 탭에서 SudoSudo Rules 를 클릭합니다.
  2. 목록 위쪽에서 추가 를 클릭합니다.
  3. 규칙의 이름을 입력합니다.

    그림 30.4. 새 sudo 규칙 이름

    새 sudo 규칙 이름
  4. 추가를 클릭합니다. 또는 추가 를 클릭하고 다른 항목 추가 또는 추가 및 편집 을 클릭하여 새 항목 편집을 시작합니다.
sudo 규칙을 편집하는 방법에 대한 자세한 내용은 30.6절. “sudo 규칙 수정” 을 참조하십시오.

명령줄에서 sudo 규칙 추가

sudo 규칙을 추가하려면 ipa sudorule-add 명령을 사용합니다. 예를 들어 files-commands 라는 규칙을 추가하려면 다음을 수행합니다.
$ ipa sudorule-add files-commands
--------------------------------
Added Sudo Rule "files-commands"
--------------------------------
  Rule name: files-commands
  Enabled: TRUE
ipa sudorule-add 및 허용되는 옵션에 대한 자세한 내용은 --help 옵션을 추가하여 명령을 실행합니다.
sudo 규칙을 편집하는 방법에 대한 자세한 내용은 30.6절. “sudo 규칙 수정” 을 참조하십시오.
명령줄에서 새 sudo 규칙을 추가하고 편집하는 전체 예제는 예 30.1. “명령줄에서 새 sudo 규칙 추가 및 수정” 를 참조하십시오.

30.5. sudo 명령 및 명령 그룹 수정

웹 UI에서 sudo 명령 및 명령 그룹 수정

  1. Policy 탭에서 SudoSudo 또는Sudo Sudo명령 그룹을 클릭합니다.
  2. 명령 또는 명령 그룹의 이름을 클릭하여 구성 페이지를 표시합니다.
  3. 필요에 따라 설정을 변경합니다. 일부 구성 페이지의 페이지 상단에 저장 버튼을 사용할 수 있습니다. 이러한 페이지에서 변경 사항을 확인하려면 버튼을 클릭해야 합니다.

명령줄에서 sudo 명령 및 명령 그룹 수정

명령 또는 명령 그룹을 수정하려면 다음 명령을 사용합니다.
  • ipa sudocmd-mod
  • ipa sudocmdgroup-mod
위의 명령에 명령줄 옵션을 추가하여 sudo 명령 또는 명령 그룹 속성을 업데이트합니다. 예를 들어 /usr/bin/less 명령에 대한 새 설명을 추가하려면 다음을 수행합니다.
$ ipa sudocmd-mod /usr/bin/less --desc="For reading log files"
-------------------------------------
Modified Sudo Command "/usr/bin/less"
-------------------------------------
  Sudo Command: /usr/bin/less
  Description: For reading log files
  Sudo Command Groups: files
이러한 명령과 허용되는 옵션에 대한 자세한 내용은 --help 옵션과 함께 실행합니다.

30.6. sudo 규칙 수정

웹 UI에서 sudo 규칙 수정

  1. Policy 탭에서 SudoSudo Rules 를 클릭합니다.
  2. 규칙 이름을 클릭하여 구성 페이지를 표시합니다.
  3. 필요에 따라 설정을 변경합니다. 일부 구성 페이지의 페이지 상단에 저장 버튼을 사용할 수 있습니다. 이러한 페이지에서 버튼을 클릭하여 변경 사항을 확인합니다.
sudo 규칙 구성 페이지에는 다음과 같은 여러 구성 영역이 포함되어 있습니다.
일반 지역
이 영역에서 규칙의 설명과 sudo 순서를 수정할 수 있습니다. sudo order 필드는 정수를 허용하고 IdM이 규칙을 평가하는 순서를 정의합니다. sudo 순서 값이 가장 높은 규칙이 먼저 평가됩니다.
옵션 영역
이 영역에서는 규칙에 sudoers 옵션을 추가할 수 있습니다.
  1. 옵션 목록 위에 추가 를 클릭합니다.

    그림 30.5. sudo 옵션 추가

    sudo 옵션 추가
  2. sudoers 옵션을 입력합니다. 예를 들어 sudo 가 인증하라는 메시지를 표시하지 않도록 지정하려면 !authenticate 옵션을 추가합니다.

    그림 30.6. sudoers 옵션 입력

    sudoers 옵션 입력
    sudoers 옵션에 대한 자세한 내용은 sudoers(5) 도움말 페이지를 참조하십시오.
  3. 추가를 클릭합니다.
everyone 지역
이 영역에서 sudo 규칙이 적용되는 사용자 또는 사용자 그룹을 선택할 수 있습니다. 이러한 사용자는 규칙에 정의된 대로 sudo 를 사용할 수 있습니다.
모든 시스템 사용자가 규칙에 정의된 대로 sudo 를 사용할 수 있도록 지정하려면 Anyone 을 선택합니다.
특정 사용자 또는 그룹에만 규칙을 적용하려면 지정된 사용자 및 그룹을 선택하고 다음 단계를 따르십시오.
  1. 사용자 또는 사용자 그룹 목록 위에 추가 를 클릭합니다.

    그림 30.7. sudo 규칙에 사용자 추가

    sudo 규칙에 사용자 추가
  2. 규칙에 추가할 사용자 또는 사용자 그룹을 선택하고 > 화살표 버튼을 클릭하여 Prospective 열로 이동합니다. 외부 사용자를 추가하려면 외부 필드에서 사용자를 지정한 다음 > 화살표 버튼 클릭합니다.

    그림 30.8. sudo 규칙에 대한 사용자 선택

    sudo 규칙에 대한 사용자 선택
  3. 추가를 클릭합니다.
액세스 이 호스트 영역
이 영역에서 sudo 규칙이 적용되는 호스트를 선택할 수 있습니다. 사용자에게 sudo 권한을 부여할 호스트입니다.
규칙이 모든 호스트에 적용되도록 지정하려면 Anyone 을 선택합니다.
특정 호스트 또는 호스트 그룹에만 규칙을 적용하려면 지정된 호스트 및 그룹을 선택하고 다음 단계를 따르십시오.
  1. 호스트 목록 위에 추가 를 클릭합니다.

    그림 30.9. sudo 규칙에 호스트 추가

    sudo 규칙에 호스트 추가
  2. 규칙에 포함할 호스트 또는 호스트 그룹을 선택하고 > 화살표 버튼을 클릭하여 Prospective 열로 이동합니다. 외부 호스트를 추가하려면 외부 필드에서 호스트를 지정한 다음 > 화살표 버튼 클릭합니다.

    그림 30.10. sudo 규칙에 대한 호스트 선택

    sudo 규칙에 대한 호스트 선택
  3. 추가를 클릭합니다.
명령 실행 영역
이 영역에서 sudo 규칙에 포함할 명령을 선택할 수 있습니다. 사용자가 특정 명령을 사용하도록 허용 또는 거부되도록 지정할 수 있습니다.
사용자가 sudo 와 함께 모든 명령을 사용할 수 있도록 지정하려면 모든 명령을 선택합니다.
규칙을 특정 명령 또는 명령 그룹과 연결하려면 지정된 명령 및 그룹을 선택하고 다음 단계를 따르십시오.
  1. 추가 버튼 중 하나를 클릭하여 명령 또는 명령 그룹을 추가합니다.
    허용된 명령 또는 명령 그룹을 지정하려면 허용 영역을 사용합니다. 거부된 명령 또는 명령 그룹을 지정하려면 거부 영역을 사용합니다.

    그림 30.11. sudo 규칙에 명령 추가

    sudo 규칙에 명령 추가
  2. 규칙에 포함할 명령 또는 명령 그룹을 선택하고 > 화살표 버튼을 클릭하여 Prospective 열로 이동합니다.

    그림 30.12. sudo 규칙에 대한 명령 선택

    sudo 규칙에 대한 명령 선택
  3. 추가를 클릭합니다.
< as whom& gt;
이 영역에서는 지정된 명령을 루트가 아닌 특정 사용자로 실행하도록 sudo 규칙을 구성할 수 있습니다.
RunAs users 그룹을 추가하면 그룹 멤버의 UID가 명령을 실행하는 데 사용됩니다. RunAs 그룹을 추가하면 그룹의 GID가 명령을 실행하는 데 사용됩니다.
규칙을 시스템에서 임의의 사용자로 실행하도록 지정하려면 Anyone 을 선택합니다. 규칙을 시스템에서 임의의 그룹으로 실행하도록 지정하려면 Any Group 을 선택합니다.
  1. 사용자 목록 위에 추가 를 클릭합니다.

    그림 30.13. 특정 사용자로 명령을 실행하도록 sudo 규칙 구성

    특정 사용자로 명령을 실행하도록 sudo 규칙 구성
  2. 필요한 사용자 또는 그룹을 선택하고 > 화살표 버튼을 사용하여 해당 사용자 지정 열로 이동합니다. 외부 엔티티를 추가하려면 외부 필드에서 지정한 다음 > 화살표 버튼 클릭합니다.

    그림 30.14. 명령으로 사용자 선택

    명령으로 사용자 선택
  3. 추가를 클릭합니다.

명령줄에서 sudo 규칙 수정

IdM 명령줄 유틸리티를 사용하면 다음과 같은 여러 sudo 규칙 영역을 구성할 수 있습니다.
일반 sudo 규칙 관리
sudo 규칙에 대한 일반 구성을 변경하려면 ipa sudo rule-mod 명령을 사용하십시오. 명령에서 수락하는 가장 일반적인 옵션은 다음과 같습니다.
  • sudo 규칙 설명을 변경하려면 --desc 옵션입니다. 예를 들어 다음과 같습니다.
    $ ipa sudorule-mod sudo_rule_name --desc="sudo_rule_description"
    
  • 지정된 규칙의 순서를 정의하는 --order 옵션입니다. 예를 들어 다음과 같습니다.
    $ ipa sudorule-mod sudo_rule_name --order=3
  • 엔터티 범주를 지정하는 옵션: --usercat (사용자 범주), --hostcat (호스트 범주), --cmdcat (명령 범주), --runasusercat (사용자 범주로 실행), --runasgroupcat (그룹 범주로 실행). 이러한 옵션은 규칙을 모든 사용자, 호스트, 명령, run-as 사용자 또는 run-as 그룹과 연결하는 모든 값만 허용합니다.
    예를 들어 모든 사용자가 sudo _rule 규칙에 정의된 대로 sudo 를 사용할 수 있도록 지정하려면 다음을 수행합니다.
    $ ipa sudorule-mod sudo_rule --usercat=all
    
    규칙이 이미 특정 엔티티와 연결되어 있는 경우 해당 범주를 정의하기 전에 이를 제거해야 합니다. 예를 들어 sudo_rule 이 이전에 ipa sudorule-add-user 명령을 사용하여 특정 사용자와 연결된 경우 먼저 ipa sudorule-remove-user 명령을 사용하여 사용자를 제거해야 합니다.
ipa sudorule-mod 에서 허용하는 전체 옵션 목록과 자세한 내용은 --help 옵션이 추가된 명령을 실행합니다.
sudo 옵션 관리
sudoers 옵션을 추가하려면 ipa sudorule-add-option 명령을 사용합니다.
예를 들어 files-commands 규칙에 따라 sudo 를 사용하는 사용자를 인증할 필요가 없다고 지정하려면 !authenticate 옵션을 추가합니다.
$ ipa sudorule-add-option files-commands
Sudo Option: !authenticate
---------------------------------------------------------
Added option "!authenticate" to Sudo Rule "files-commands"
---------------------------------------------------------
sudoers 옵션에 대한 자세한 내용은 sudoers(5) 도움말 페이지를 참조하십시오.
sudoers 옵션을 제거하려면 ipa sudorule-remove-option 명령을 사용합니다. 예를 들어 다음과 같습니다.
$ ipa sudorule-remove-option files-commands
Sudo Option: authenticate
-------------------------------------------------------------
Removed option "authenticate" from Sudo Rule "files-commands"
-------------------------------------------------------------
sudo사용 권한이 부여된 사용자 관리
개별 사용자를 지정하려면 ipa sudorule-add-user 명령에 --users 옵션을 추가합니다. 사용자 그룹을 지정하려면 ipa sudorule-add-user--groups 옵션을 추가합니다.
예를 들어 users 및 user _groupfiles-commands 규칙에 추가하려면 다음을 수행합니다.
$ ipa sudorule-add-user files-commands --users=user --groups=user_group
...
-------------------------
Number of members added 2
-------------------------
개별 사용자 또는 그룹을 제거하려면 ipa sudorule-remove-user 를 사용합니다. 예를 들어 사용자를 제거하려면 다음을 수행합니다.
$ ipa sudorule-remove-user files-commands
[member user]: user
[member group]:
...
---------------------------
Number of members removed 1
---------------------------
사용자에게 sudo 권한이 부여된 위치 관리
호스트를 지정하려면 ipa sudorule-add-host 명령에 --hosts 옵션을 추가합니다. 호스트 그룹을 지정하려면 ipa sudorule-add-host--hostgroups 옵션을 추가합니다.
예를 들어 example.comhost_groupfiles-commands 규칙에 추가하려면 다음을 실행합니다.
$ ipa sudorule-add-host files-commands --hosts=example.com --hostgroups=host_group
...
-------------------------
Number of members added 2
-------------------------
호스트 또는 호스트 그룹을 제거하려면 ipa sudorule-remove-host 명령을 사용합니다. 예를 들어 다음과 같습니다.
$ ipa sudorule-remove-host files-commands
[member host]: example.com
[member host group]:
...
---------------------------
Number of members removed 1
---------------------------
sudo와 함께 사용할 수 있는 명령 관리
사용자가 특정 명령을 사용하도록 허용 또는 거부되도록 지정할 수 있습니다.
허용되는 명령 또는 명령 그룹을 지정하려면 ipa sudorule-add-allow-command--sudocmds 또는 --sudocmdgroups 옵션을 추가합니다. 거부된 명령 또는 명령 그룹을 지정하려면 ipa sudorule-add-deny-command 명령에 --sudocmds 또는 --sudocmdgroups 옵션을 추가합니다.
예를 들어 files -commands 규칙에 허용되는 /usr/bin/less 명령 및 files 명령 그룹을 추가하려면 다음을 실행합니다.
$ ipa sudorule-add-allow-command files-commands --sudocmds=/usr/bin/less --sudocmdgroups=files
...
-------------------------
Number of members added 2
-------------------------
규칙에서 명령 또는 명령 그룹을 제거하려면 ipa sudorule-remove-allow-command 또는 ipa sudorule-remove-deny-command 명령을 사용하십시오. 예를 들어 다음과 같습니다.
$ ipa sudorule-remove-allow-command files-commands
[member sudo command]: /usr/bin/less
[member sudo command group]:
...
---------------------------
Number of members removed 1
---------------------------
--sudocmds 옵션은 30.4.1절. “sudo 명령 추가” 에 설명된 대로 IdM에 추가된 명령만 허용합니다.
sudo 명령을 실행할 때 관리
그룹의 개별 사용자 또는 사용자의 UID를 명령이 실행되는 ID로 사용하려면 ipa sudorule-add-runasuser 명령과 함께 --users 또는 --groups 옵션을 사용합니다.
사용자 그룹의 GID를 명령의 ID로 사용하려면 ipa sudorule-add-runasgroup --groups 명령을 사용합니다.
사용자 또는 그룹을 지정하지 않으면 sudo 명령이 root로 실행됩니다.
예를 들어 사용자의 ID를 사용하여 sudo 규칙에서 명령을 실행하도록 지정하려면 다음을 실행합니다.
$ ipa sudorule-add-runasuser files-commands --users=user
...
RunAs Users: user
...
ipa sudorule-* 명령에 대한 자세한 내용은 ipa help sudorule 명령 출력을 참조하거나 --help 옵션이 추가된 특정 명령을 실행하십시오.

예 30.1. 명령줄에서 새 sudo 규칙 추가 및 수정

특정 사용자 그룹이 선택한 서버에서 모든 명령과 함께 sudo 를 사용하도록 허용하려면 다음을 수행하십시오.
  1. admin 사용자 또는 sudo 규칙을 관리할 수 있는 다른 사용자의 Kerberos 티켓을 받습니다.
    $ kinit admin
    Password for admin@EXAMPLE.COM:
    
  2. IdM에 새 sudo 규칙을 추가합니다.
    $ ipa sudorule-add new_sudo_rule --desc="Rule for user_group"
    ---------------------------------
    Added Sudo Rule "new_sudo_rule"
    ---------------------------------
      Rule name: new_sudo_rule
      Description: Rule for user_group
      Enabled: TRUE
    
  3. who: sudo 규칙을 사용할 수 있는 사용자 그룹을 지정합니다.
    $ ipa sudorule-add-user new_sudo_rule --groups=user_group
      Rule name: new_sudo_rule
      Description: Rule for user_group
      Enabled: TRUE
      User Groups: user_group
    -------------------------
    Number of members added 1
    -------------------------
    
  4. 여기서 사용자에게 sudo 권한을 부여할 호스트 그룹을 지정합니다.
    $ ipa sudorule-add-host new_sudo_rule --hostgroups=host_group
      Rule name: new_sudo_rule
      Description: Rule for user_group
      Enabled: TRUE
      User Groups: user_group
      Host Groups: host_group
    -------------------------
    Number of members added 1
    -------------------------
    
  5. 사용자가 sudo 명령을 실행할 수 있도록 하려면 다음을 정의합니다. 모든 명령 카테고리를 규칙에 추가합니다.
    $ ipa sudorule-mod new_sudo_rule --cmdcat=all
    ------------------------------
    Modified Sudo Rule "new_sudo_rule"
    ------------------------------
      Rule name: new_sudo_rule
      Description: Rule for user_group
      Enabled: TRUE
      Command category: all
      User Groups: user_group
      Host Groups: host_group
    
  6. sudo 명령을 root로 실행하도록 하려면 사용자 또는 그룹으로 실행을 지정하지 마십시오.
  7. !authenticate sudoers 옵션을 추가하여 sudo 명령을 사용할 때 사용자를 인증할 필요가 없음을 지정합니다.
    $ ipa sudorule-add-option new_sudo_rule
    Sudo Option: !authenticate
    -----------------------------------------------------
    Added option "!authenticate" to Sudo Rule "new_sudo_rule"
    -----------------------------------------------------
      Rule name: new_sudo_rule
      Description: Rule for user_group
      Enabled: TRUE
      Command category: all
      User Groups: user_group
      Host Groups: host_group
      Sudo Option: !authenticate
    
  8. sudo 규칙 구성을 표시하여 올바른지 확인합니다.
    $ ipa sudorule-show new_sudo_rule
      Rule name: new_sudo_rule
      Description: Rule for user_group
      Enabled: TRUE
      Command category: all
      User Groups: user_group
      Host Groups: host_group
      Sudo Option: !authenticate
    

30.7. sudo 명령, 명령 그룹 및 규칙 나열 및 표시

웹 UI에서 sudo 명령, 명령 그룹 및 규칙 나열 및 표시

  1. Policy 탭에서 Sudo 를 클릭하고 Sudo Rules,Sudo Commands, Sudo Commands를 선택합니다.
  2. 규칙, 명령 또는 명령 그룹의 이름을 클릭하여 구성 페이지를 표시합니다.

명령줄에서 sudo 명령, 명령 그룹 및 규칙 나열 및 표시

모든 명령, 명령 그룹 및 규칙을 나열하려면 다음 명령을 사용하십시오.
  • ipa sudocmd-find
  • ipa sudocmdgroup-find
  • IPA sudorule-find
특정 명령, 명령 그룹 또는 규칙에 대한 정보를 표시하려면 다음 명령을 사용합니다.
  • ipa sudocmd-show
  • ipa sudocmdgroup-show
  • IPA sudorule-show
예를 들어 /usr/bin/less 명령에 대한 정보를 표시하려면 다음을 수행합니다.
$ ipa sudocmd-show /usr/bin/less
  Sudo Command: /usr/bin/less
  Description: For reading log files.
  Sudo Command Groups: files
이러한 명령과 허용되는 옵션에 대한 자세한 내용은 --help 옵션과 함께 실행합니다.

30.8. sudo 규칙 비활성화 및 활성화

sudo 규칙을 비활성화하면 일시적으로 비활성화됩니다. 비활성화된 규칙은 IdM에서 제거되지 않으며 다시 활성화할 수 있습니다.

웹 UI에서 sudo 규칙 비활성화 및 활성화

  1. Policy 탭에서 SudoSudo Rule 을 클릭합니다.
  2. 비활성화할 규칙을 선택하고 비활성화 또는 사용을 클릭합니다.

    그림 30.15. sudo 규칙 비활성화 또는 활성화

    sudo 규칙 비활성화 또는 활성화

명령줄에서 sudo 규칙 비활성화 및 활성화

규칙을 비활성화하려면 ipa sudo-rule-disable 명령을 사용합니다.
$ ipa sudorule-disable sudo_rule_name
-----------------------------------
Disabled Sudo Rule "sudo_rule_name"
-----------------------------------
규칙을 다시 활성화하려면 ipa sudorule-enable 명령을 사용합니다.
$ ipa sudorule-enable sudo_rule_name
-----------------------------------
Enabled Sudo Rule "sudo_rule_name"
-----------------------------------

30.9. sudo 명령, 명령 그룹 및 규칙 제거

웹 UI에서 sudo 명령, 명령 그룹 및 규칙 제거

  1. Policy 탭에서 Sudo 를 클릭하고 Sudo Rules,Sudo Commands, Sudo Commands를 선택합니다.
  2. 삭제할 명령, 명령 그룹 또는 규칙을 선택하고 삭제 를 클릭합니다.

    그림 30.16. sudo 명령 삭제

    sudo 명령 삭제

명령줄에서 sudo 명령, 명령 그룹 및 규칙 제거

명령, 명령 그룹 또는 규칙을 삭제하려면 다음 명령을 사용하십시오.
  • ipa sudocmd-del
  • ipa sudocmdgroup-del
  • ipa sudorule-del
이러한 명령과 허용되는 옵션에 대한 자세한 내용은 --help 옵션과 함께 실행합니다.

31장. 호스트 기반 액세스 제어 구성

이 장에서는 IdM(Identity Management)의 HBAC(Host -based Access Control )에 대해 설명하고 HBAC를 사용하여 IdM 도메인에서 액세스 제어를 관리하는 방법을 설명합니다.

31.1. IdM의 호스트 기반 액세스 제어 작동 방식

호스트 기반 액세스 제어는 지정된 서비스(또는 서비스 그룹의 서비스)를 사용하여 지정된 호스트(또는 호스트 그룹)에 액세스할 수 있는 사용자(또는 사용자 그룹)를 정의합니다. 예를 들어 다음을 수행할 수 있습니다.
  • 도메인의 지정된 시스템에 대한 액세스를 특정 사용자 그룹의 멤버로 제한합니다.
  • 특정 서비스만 도메인의 시스템에 액세스하도록 허용합니다.
관리자는 HBAC 규칙이라는 규칙 집합을 사용하여 호스트 기반 액세스 제어를 구성합니다. 기본적으로 IdM은 전체 IdM 도메인에서 범용 액세스를 허용하는 allow_all 이라는 기본 HBAC 규칙으로 구성됩니다.

그룹에 HBAC 규칙 적용

중앙 집중식 액세스 제어 관리를 위해 개별 사용자, 호스트 또는 서비스 그룹 대신 HBAC 규칙을 전체 사용자, 호스트 또는 서비스 그룹에 적용할 수 있습니다.

그림 31.1. 호스트 그룹 및 호스트 기반 액세스 제어

호스트 그룹 및 호스트 기반 액세스 제어
그룹에 HBAC 규칙을 적용할 때 automember 규칙 사용을 고려하십시오. 13.6절. “사용자 및 호스트에 대한 자동 그룹 멤버십 정의” 참조하십시오.

31.2. IdM 도메인에서 호스트 기반 액세스 제어 구성

호스트 기반 액세스 제어를 위해 도메인을 구성하려면 다음을 수행합니다.
  1. 중요
    사용자 정의 HBAC 규칙을 만들기 전에 allow_all 규칙을 비활성화하지 마십시오. 이렇게 하면 사용자가 호스트에 액세스할 수 없습니다.

31.2.1. HBAC 규칙 생성

HBAC 규칙을 만들려면 다음을 사용합니다.
예를 들면 “HBAC 규칙의 예” 의 내용을 참조하십시오.
참고
IdM은 사용자의 기본 그룹을 IdM 그룹 오브젝트에 대한 링크 대신 gidNumber 속성의 숫자 값으로 저장합니다. 이러한 이유로 HBAC 규칙은 기본 그룹이 아닌 사용자의 보조 그룹만 참조할 수 있습니다.

웹 UI: HBAC 규칙 생성

  1. PolicyHost-Based Access ControlHBAC rules 를 선택합니다.
  2. 추가 를 클릭하여 새 규칙 추가를 시작합니다.
  3. 규칙 이름을 입력하고 추가 를 클릭하여 HBAC 규칙 구성 페이지로 직접 이동합니다.
  4. who 영역에서 대상 사용자를 지정합니다.
    • 지정된 사용자 또는 그룹에만 HBAC 규칙을 적용하려면 지정된 사용자 및 그룹을 선택합니다. 그런 다음 추가 를 클릭하여 사용자 또는 그룹을 추가합니다.
    • 모든 사용자에게 HBAC 규칙을 적용하려면 Anyone 을 선택합니다.

    그림 31.2. HBAC 규칙의 대상 사용자 지정

    HBAC 규칙의 대상 사용자 지정
  5. 액세스 영역에서 대상 호스트를 지정합니다.
    • 지정된 호스트 또는 그룹에만 HBAC 규칙을 적용하려면 지정된 호스트 및 그룹을 선택합니다. 그런 다음 추가 를 클릭하여 호스트 또는 그룹을 추가합니다.
    • 모든 호스트에 HBAC 규칙을 적용하려면 모든 호스트를 선택합니다.
  6. Via Service 영역에서 대상 HBAC 서비스를 지정합니다.
    • 지정된 서비스 또는 그룹에만 HBAC 규칙을 적용하려면 지정된 서비스 및 그룹을 선택합니다. 그런 다음 추가 를 클릭하여 서비스 또는 그룹을 추가합니다.
    • 모든 서비스에 HBAC 규칙을 적용하려면 모든 서비스를 선택합니다.
    참고
    기본적으로 가장 일반적인 서비스 및 서비스 그룹만 HBAC 규칙에 대해 구성됩니다.
    • 현재 사용 가능한 서비스 목록을 표시하려면 PolicyHost-Based Access ControlHBAC Services 를 선택합니다.
    • 현재 사용 가능한 서비스 그룹 목록을 표시하려면 PolicyHost-Based Access ControlHBAC 서비스 그룹을 선택합니다.
    더 많은 서비스 및 서비스 그룹을 추가하려면 31.3절. “사용자 지정 HBAC 서비스에 대한 HBAC 서비스 항목 추가”31.4절. “HBAC 서비스 그룹 추가” 을 참조하십시오.
  7. HBAC 규칙 구성 페이지에서 특정 설정을 변경하면 페이지 상단의 저장 버튼이 강조 표시됩니다. 이 경우 버튼을 클릭하여 변경 사항을 확인합니다.

명령줄: HBAC 규칙 생성

  1. ipa hbacrule-add 명령을 사용하여 규칙을 추가합니다.
    $ ipa hbacrule-add
    Rule name: rule_name
    ---------------------------
    Added HBAC rule "rule_name"
    ---------------------------
      Rule name: rule_name
      Enabled: TRUE
  2. 대상 사용자를 지정합니다.
    • 지정된 사용자 또는 그룹에만 HBAC 규칙을 적용하려면 ipa hbacrule-add-user 명령을 사용합니다.
      예를 들어 그룹을 추가하려면 다음을 수행합니다.
      $ ipa hbacrule-add-user
      Rule name: rule_name
      [member user]:
      [member group]: group_name
        Rule name: rule_name
        Enabled: TRUE
        User Groups: group_name
      -------------------------
      Number of members added 1
      -------------------------
      여러 사용자 또는 그룹을 추가하려면 --users 및 -- groups 옵션을 사용합니다.
      $ ipa hbacrule-add-user rule_name --users=user1 --users=user2 --users=user3
        Rule name: rule_name
        Enabled: TRUE
        Users: user1, user2, user3
      -------------------------
      Number of members added 3
      -------------------------
    • 모든 사용자에게 HBAC 규칙을 적용하려면 ipa hbacrule-mod 명령을 사용하고 모든 사용자 카테고리를 지정합니다.
      $ ipa hbacrule-mod rule_name --usercat=all
      ------------------------------
      Modified HBAC rule "rule_name"
      ------------------------------
        Rule name: rule_name
        User category: all
        Enabled: TRUE
      참고
      HBAC 규칙이 개별 사용자 또는 그룹과 연결된 경우 ipa hbacrule-mod --usercat=all 이 실패합니다. 이 경우 ipa hbacrule-remove-user 명령을 사용하여 사용자와 그룹을 제거합니다.
      자세한 내용은 --help 옵션을 사용하여 ipa hbacrule-remove-user 를 실행합니다.
  3. 대상 호스트를 지정합니다.
    • 지정된 호스트 또는 그룹에만 HBAC 규칙을 적용하려면 ipa hbacrule-add-host 명령을 사용합니다.
      예를 들어 단일 호스트를 추가하려면 다음을 수행합니다.
      $ ipa hbacrule-add-host
      Rule name: rule_name
      [member host]: host.example.com
      [member host group]:
        Rule name: rule_name
        Enabled: TRUE
        Hosts: host.example.com
      -------------------------
      Number of members added 1
      -------------------------
      여러 호스트 또는 그룹을 추가하려면 --hosts 및 -- hostgroups 옵션을 사용합니다.
      $ ipa hbacrule-add-host rule_name --hosts=host1 --hosts=host2 --hosts=host3
        Rule name: rule_name
        Enabled: TRUE
        Hosts: host1, host2, host3
      -------------------------
      Number of members added 3
      -------------------------
    • 모든 호스트에 HBAC 규칙을 적용하려면 ipa hbacrule-mod 명령을 사용하고 모든 호스트 카테고리를 지정합니다.
      $ ipa hbacrule-mod rule_name --hostcat=all
      ------------------------------
      Modified HBAC rule "rule_name"
      ------------------------------
        Rule name: rule_name
        Host category: all
        Enabled: TRUE
      참고
      HBAC 규칙이 개별 호스트 또는 그룹과 연결된 경우 ipa hbacrule-mod --hostcat=all 이 실패합니다. 이 경우 ipa hbacrule-remove-host 명령을 사용하여 호스트 및 그룹을 제거합니다.
      자세한 내용은 --help 옵션을 사용하여 ipa hbacrule-remove-host 를 실행합니다.
  4. 대상 HBAC 서비스를 지정합니다.
    • 지정된 서비스 또는 그룹에만 HBAC 규칙을 적용하려면 ipa hbacrule-add-service 명령을 사용합니다.
      예를 들어 단일 서비스를 추가하려면 다음을 수행합니다.
      $ ipa hbacrule-add-service
      Rule name: rule_name
      [member HBAC service]: ftp
      [member HBAC service group]:
      Rule name: rule_name
      Enabled: TRUE
      Services: ftp
      -------------------------
      Number of members added 1
      -------------------------
      여러 서비스 또는 그룹을 추가하려면 --hbacsvcs 및 --hbacsvc groups 옵션을 사용하면 됩니다.
      $ ipa hbacrule-add-service rule_name --hbacsvcs=su --hbacsvcs=sudo
        Rule name: rule_name
        Enabled: TRUE
        Services: su, sudo
      -------------------------
      Number of members added 2
      -------------------------
      참고
      HBAC 규칙에 대해 가장 일반적인 서비스 및 서비스 그룹만 구성됩니다. 자세한 내용은 31.3절. “사용자 지정 HBAC 서비스에 대한 HBAC 서비스 항목 추가”31.4절. “HBAC 서비스 그룹 추가” 을 참조하십시오.
    • 모든 서비스에 HBAC 규칙을 적용하려면 ipa hbacrule-mod 명령을 사용하고 모든 서비스 카테고리를 지정합니다.
      $ ipa hbacrule-mod rule_name --servicecat=all
      ------------------------------
      Modified HBAC rule "rule_name"
      ------------------------------
        Rule name: rule_name
        Service category: all
        Enabled: TRUE
      참고
      HBAC 규칙이 개별 서비스 또는 그룹과 연결된 경우 ipa hbacrule-mod --servicecat=all 이 실패합니다. 이 경우 ipa hbacrule-remove-service 명령을 사용하여 서비스 및 그룹을 제거합니다.
      자세한 내용은 --help 옵션을 사용하여 ipa hbacrule-remove-service 를 실행합니다.
  5. 선택 사항입니다. HBAC 규칙이 올바르게 추가되었는지 확인합니다.
    1. ipa hbacrule-find 명령을 사용하여 HBAC 규칙이 IdM에 추가되었는지 확인합니다.
    2. ipa hbacrule-show 명령을 사용하여 HBAC 규칙의 속성을 확인합니다.
    자세한 내용은 --help 옵션과 함께 명령을 실행합니다.

HBAC 규칙의 예

예 31.1. 모든 서비스를 사용하여 모든 호스트에 대한 단일 사용자 액세스 권한 부여

admin 사용자가 서비스를 사용하여 도메인의 모든 시스템에 액세스할 수 있도록 하려면 새 HBAC 규칙을 생성하고 다음을 설정합니다.
  • admin사용자
  • 모든 호스트에 대한 호스트 (웹 UI에서) 또는 ipa hbacrule-add (규칙 추가 시) 또는 ipa hbacrule-mod와 함께 --hostcat=all 을 사용합니다.
  • 모든 서비스에 대한 서비스 (웹 UI에서) 또는 ipa hbacrule-add (규칙 추가 시) 또는 ipa hbacrule-mod와 함께 --servicecat=all 을 사용합니다.

예 31.2. 특정 서비스만 호스트에 액세스하는 데 사용될 수 있는지 확인

모든 사용자가 sudo- 관련 서비스를 사용하여 host.example.com 이라는 호스트에 액세스하도록 하려면 새 HBAC 규칙을 생성하고 다음을 설정합니다.
  • 사용자는 Anyone (웹 UI에서) 또는 ipa hbacrule-add (규칙 추가 시) 또는 ipa hbacrule-mod와 함께 --usercat=all 을 사용합니다.
  • host.example.com의 호스트
  • Sudo.do의 HBAC 서비스 그룹( sudo 및 관련 서비스의 기본 그룹)

31.2.2. HBAC 규칙 테스트

IdM을 사용하면 시뮬레이션된 시나리오를 사용하여 다양한 상황에서 HBAC 구성을 테스트할 수 있습니다. 시뮬레이션된 테스트 실행을 수행하면 HBAC 규칙을 프로덕션에 배포하기 전에 잘못된 문제나 보안 위험을 발견할 수 있습니다.
중요
프로덕션에서 사용하기 전에 사용자 지정 HBAC 규칙을 항상 테스트하십시오.
IdM은 신뢰할 수 있는 AD(Active Directory) 사용자에 대한 HBAC 규칙의 영향을 테스트하지 않습니다. AD 데이터는 IdM LDAP 디렉터리에 저장되지 않기 때문에 HBAC 시나리오 시뮬레이션 시 IdM은 AD 사용자의 그룹 멤버십을 확인할 수 없습니다.
HBAC 규칙을 테스트하려면 다음을 사용합니다.

웹 UI: HBAC 규칙 테스트

  1. PolicyHost-Based Access ControlHBAC Test 를 선택합니다.
  2. who 화면에서 다음을 수행합니다. 테스트를 수행할 ID 아래에 사용자를 지정하고 다음을 클릭합니다.

    그림 31.3. HBAC 테스트 대상 사용자 지정

    HBAC 테스트 대상 사용자 지정
  3. 액세스 화면에서 다음을 수행합니다. 사용자가 액세스할 호스트를 지정하고 다음을 클릭합니다.
  4. Via 서비스 화면에서 다음을 수행합니다. 사용자가 사용할 서비스를 지정하고 다음을 클릭합니다.
  5. 규칙 화면에서 다음을 수행합니다. 테스트할 HBAC 규칙을 선택하고 다음을 클릭합니다. 규칙을 선택하지 않으면 모든 규칙이 테스트됩니다.
    상태가 Enabled인 모든 규칙에서 테스트를 실행하려면To run the test on all rules whose status is enabled. Include Disabled 를 선택하여 상태가 Disabled 인 모든 규칙에서 테스트를 실행합니다. HBAC 규칙의 상태를 보고 변경하려면 정책호스트 기반 액세스 제어HBAC 규칙 을 선택합니다.
    중요
    테스트가 여러 규칙에서 실행되는 경우 선택한 규칙 중 하나 이상이 액세스를 허용하는 경우 성공적으로 전달됩니다.
  6. 테스트 실행 화면에서 다음을 수행합니다. 테스트 실행을 클릭합니다.

    그림 31.4. HBAC 테스트 실행

    HBAC 테스트 실행
  7. 테스트 결과를 검토합니다.
    • ACCESS DENIED 가 표시되면 테스트에서 사용자에게 액세스 권한이 부여되지 않았습니다.
    • ACCESS GRANTED 가 표시되면 사용자가 호스트에 성공적으로 액세스할 수 있었습니다.

    그림 31.5. HBAC 테스트 결과 검토

    HBAC 테스트 결과 검토
    기본적으로 IdM은 테스트 결과를 표시할 때 테스트된 모든 HBAC 규칙을 나열합니다.
    • 성공적인 액세스를 허용하는 규칙을 표시하려면 일치 를 선택합니다.
    • 액세스할 수 없는 규칙을 표시하려면 Unmatched 를 선택합니다.

명령줄: HBAC 규칙 테스트

ipa hbactest 명령을 사용하여 최소한을 지정합니다.
  • 테스트를 수행하려는 ID 아래의 사용자
  • 사용자가 액세스를 시도하는 호스트
  • 사용자가 사용하려는 서비스
예를 들어 이러한 값을 대화형으로 지정하는 경우 다음을 수행합니다.
$ ipa hbactest
User name: user1
Target host: example.com
Service: sudo
---------------------
Access granted: False
---------------------
Not matched rules: rule1
기본적으로 IdM은 상태가 활성화된 모든 HBAC 규칙에서 테스트를 실행합니다. 다른 HBAC 규칙을 지정하려면 다음을 수행합니다.
  • --rules 옵션을 사용하여 하나 이상의 HBAC 규칙을 정의합니다.
  • --disabled 옵션을 사용하여 상태가 비활성화된 모든 HBAC 규칙을 테스트합니다.
HBAC 규칙의 현재 상태를 보려면 ipa hbacrule-find 명령을 실행합니다.

예 31.3. 명령줄에서 HBAC 규칙 테스트

다음 테스트에서는 rule2 라는 HBAC 규칙에서 user1sudo 서비스를 사용하여 example.com 에 액세스하지 못하도록 합니다.
$ ipa hbactest --user=user1 --host=example.com --service=sudo --rules=rule1
---------------------
Access granted: False
---------------------
  Not matched rules: rule1

예 31.4. 명령줄에서 여러 HBAC 규칙 테스트

여러 HBAC 규칙을 테스트할 때 하나 이상의 규칙이 사용자에게 성공적인 액세스를 허용하는 경우 테스트가 통과합니다.
$ ipa hbactest --user=user1 --host=example.com --service=sudo --rules=rule1 --rules=rule2
--------------------
Access granted: True
--------------------
  Matched rules: rule2
  Not matched rules: rule1
출력에서 다음을 수행합니다.
  • 일치하는 규칙에 는 성공적인 액세스를 허용하는 규칙이 나열됩니다.
  • 규칙이 일치하지 않음 으로, 액세스를 방지하는 규칙이 나열됩니다.

31.2.3. HBAC 규칙 비활성화

HBAC 규칙을 비활성화하면 규칙이 비활성화되지만 삭제되지는 않습니다. HBAC 규칙을 비활성화하면 나중에 다시 활성화할 수 있습니다.
참고
예를 들어 HBAC 규칙을 비활성화하면 사용자 지정 HBAC 규칙을 처음 구성할 때 유용합니다. 새 구성이 기본 allow_all HBAC 규칙으로 재정의되지 않도록 하려면 allow_all 을 비활성화해야 합니다.
HBAC 규칙을 비활성화하려면 다음을 사용할 수 있습니다.

웹 UI: HBAC 규칙 비활성화

  1. PolicyHost-Based Access ControlHBAC rules 를 선택합니다.
  2. 비활성화할 HBAC 규칙을 선택하고 비활성화를 클릭합니다.

그림 31.6. allow_all HBAC 규칙 비활성화

allow_all HBAC 규칙 비활성화

명령줄: HBAC 규칙 비활성화

ipa hbacrule-disable 명령을 사용합니다. 예를 들어 allow_all 규칙을 비활성화하려면 다음을 수행합니다.
$ ipa hbacrule-disable allow_all
------------------------------
Disabled HBAC rule "allow_all"
------------------------------

31.3. 사용자 지정 HBAC 서비스에 대한 HBAC 서비스 항목 추가

기본적으로 가장 일반적인 서비스 및 서비스 그룹만 HBAC 규칙에 대해 구성됩니다. 그러나 PAM(장착형 인증 모듈) 서비스를 HBAC 서비스로 구성할 수도 있습니다. 이를 통해 HBAC 규칙에서 사용자 지정 PAM 서비스를 정의할 수 있습니다.
참고
서비스를 HBAC 서비스로 추가하는 것은 도메인에 서비스를 추가하는 것과 같지 않습니다. 도메인에 서비스를 추가하면 서비스가 도메인의 다른 리소스에서 인식되는 리소스를 사용할 수 있지만 HBAC 규칙에서 서비스를 사용할 수는 없습니다. 16.1절. “서비스 항목 및 키 탭 추가 및 편집”
HBAC 서비스 항목을 추가하려면 다음을 사용합니다.

웹 UI: HBAC 서비스 항목 추가

  1. PolicyHost-Based Access ControlHBAC Services 를 선택합니다.
  2. 추가 를 클릭하여 HBAC 서비스 항목을 추가합니다.
  3. 서비스 이름을 입력하고 추가 를 클릭합니다.

명령줄: HBAC 서비스 항목 추가

ipa hbacsvc-add 명령을 사용합니다. 예를 들어 tftp 서비스에 대한 항목을 추가하려면 다음을 수행합니다.
$ ipa hbacsvc-add tftp
-------------------------
Added HBAC service "tftp"
-------------------------
  Service name: tftp

31.4. HBAC 서비스 그룹 추가

HBAC 서비스 그룹은 HBAC 규칙으로 개별 서비스를 추가하는 대신 전체 서비스 그룹을 추가할 수 있습니다.
HBAC 서비스 그룹을 추가하려면 다음을 사용합니다.

웹 UI: HBAC 서비스 그룹 추가

  1. PolicyHost-Based Access ControlHBAC Service Groups 를 선택합니다.
  2. 추가 를 클릭하여 HBAC 서비스 그룹을 추가합니다.
  3. 서비스 그룹의 이름을 입력하고 추가 및 편집을 클릭합니다.
  4. 서비스 그룹 구성 페이지에서 추가를 클릭하여 HBAC 서비스를 그룹의 멤버로 추가합니다.

    그림 31.7. HBAC 서비스 그룹에 HBAC 서비스 추가

    HBAC 서비스 그룹에 HBAC 서비스 추가

명령줄: HBAC 서비스 그룹 추가

  1. ipa hbacsvcgroup-add 명령을 사용하여 HBAC 서비스 그룹을 추가합니다. 예를 들어 login 이라는 그룹을 추가하려면 다음을 수행합니다.
    $ ipa hbacsvcgroup-add
    Service group name: login
    --------------------------------
    Added HBAC service group "login"
    --------------------------------
      Service group name: login
  2. ipa hbacsvcgroup-add-member 명령을 사용하여 HBAC 서비스를 그룹 멤버로 추가합니다. 예를 들어 sshd 서비스를 로그인 그룹에 추가하려면 다음을 수행합니다.
    $ ipa hbacsvcgroup-add-member
    Service group name: login
    [member HBAC service]: sshd
      Service group name: login
      Member HBAC service: sshd
    -------------------------
    Number of members added 1
    -------------------------

32장. SELinux 사용자 맵 정의

SELinux(Security-enhanced Linux)는 시스템 사용자가 프로세스, 파일, 디렉터리 및 시스템 설정에 액세스할 수 있는 항목에 대한 규칙을 설정합니다. 시스템 관리자와 시스템 애플리케이션 모두 다른 애플리케이션에서 액세스를 제한하거나 허용하는 보안 컨텍스트를 정의할 수 있습니다.
Identity Management 도메인에 중앙 집중식 보안 정책을 정의하는 과정의 일환으로 ID 관리에서는 IdM 사용자를 기존 SELinux 사용자 컨텍스트에 매핑하고 정의된 SELinux 정책을 기반으로 호스트당 클라이언트 및 서비스에 대한 액세스 권한을 부여하거나 제한하는 방법을 제공합니다.

32.1. ID 관리, SELinux 및 매핑 사용자 매핑 정보

Identity Management는 시스템에서 SELinux 컨텍스트를 생성하거나 수정하지 않습니다. 대신 도메인의 IdM 사용자를 시스템의 SELinux 사용자에게 매핑하는 기반으로 대상 호스트의 기존 컨텍스트와 일치할 수 있는 문자열을 사용합니다.
Security-enhanced Linux는 프로세스가 시스템의 다른 리소스와 상호 작용하는 방법에 대한 커널 수준의 필수 액세스 제어를 정의합니다. 시스템에서 프로세스의 예상 동작과 보안에 미치는 영향에 따라 정책이라는 특정 규칙이 설정됩니다. 이는 주로 파일 소유권 및 사용자 ID와 관련된 높은 수준의 선택적 액세스 제어와 대조적입니다. 시스템의 모든 리소스에는 컨텍스트가 할당됩니다. 리소스에는 사용자, 애플리케이션, 파일 및 프로세스가 포함됩니다.
시스템 사용자는 SELinux 역할과 연결됩니다. 이 역할에는 다중 계층 보안 컨텍스트(MLS)와 다중 범주 보안 컨텍스트(MCS)가 모두 할당됩니다. MLS 및 MCS 컨텍스트는 시스템에서 특정 프로세스, 파일 및 작업에만 액세스할 수 있도록 사용자를 제한합니다.
사용 가능한 SELinux 사용자의 전체 목록을 얻으려면 다음을 수행하십시오.
[root@server1 ~]# semanage user -l

                Labelling  MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

guest_u         user       s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r unconfined_r
unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        user       s0         s0                             xguest_r
Red Hat Enterprise Linux의 SELinux에 대한 자세한 내용은 Red Hat Enterprise Linux 7 SELinux 사용자 및 관리자 가이드를 참조하십시오.
SELinux 사용자 및 정책은 네트워크 수준이 아닌 시스템 수준에서 작동합니다. 즉, SELinux 사용자는 각 시스템에 독립적으로 구성됩니다. SELinux에는 일반 정의된 시스템 사용자가 있으며 SELinux 인식 서비스는 자체 정책을 정의하므로 원격 사용자와 시스템이 로컬 리소스에 액세스하는 경우 문제가 발생할 수 있습니다. 원격 사용자 및 서비스에는 실제 SELinux 사용자 및 역할이 무엇인지 모르는 상태에서 기본 게스트 컨텍스트를 할당할 수 있습니다.
Identity Management는 ID 도메인을 로컬 SELinux 서비스와 통합할 수 있습니다. ID 관리는 IdM 사용자를 호스트별로 또는 HBAC 규칙에 따라 구성된 SELinux 역할에 매핑할 수 있습니다. SELinux 및 IdM 사용자를 매핑하면 사용자 관리가 향상됩니다.
  • IdM 그룹 할당에 따라 원격 사용자에게 적절한 SELinux 사용자 컨텍스트를 부여할 수 있습니다. 또한 관리자는 로컬 계정을 생성하거나 SELinux를 재구성하지 않고도 동일한 사용자에게 동일한 정책을 일관되게 적용할 수 있습니다.
  • 사용자와 연결된 SELinux 컨텍스트는 중앙 집중화됩니다.
  • SELinux 정책은 IdM 호스트 기반 액세스 제어 규칙과 같은 설정을 통해 도메인 전체 보안 정책과 관련될 수 있습니다.
  • 관리자는 SELinux에서 사용자와 시스템을 할당하는 방법을 환경 전반의 가시성과 제어 권한을 갖게 됩니다.
SELinux 사용자 맵은 시스템용 SELinux 사용자, IdM 사용자 및 IdM 호스트 사이에 존재하는 두 가지 별도의 관계를 정의합니다. 먼저 SELinux 사용자 맵은 SELinux 사용자와 IdM 호스트(로컬 또는 대상 시스템) 간의 관계를 정의합니다. 두 번째는 SELinux 사용자와 IdM 사용자 간의 관계를 정의합니다.
이러한 정렬을 통해 관리자는 액세스하는 호스트에 따라 동일한 IdM 사용자에 대해 다른 SELinux 사용자를 설정할 수 있습니다.
SELinux 매핑 규칙의 핵심은 SELinux 시스템 사용자입니다. 각 맵은 먼저 SELinux 사용자와 연결됩니다. 매핑에 사용할 수 있는 SELinux 사용자는 IdM 서버에 구성되므로 중앙 및 범용 목록이 있습니다. 이러한 방식으로 IdM은 로그인 시 IdM을 알고 IdM 사용자와 연결할 수 있는 SELinux 사용자 집합을 정의합니다. 기본적으로 다음과 같습니다.
  • unconfined_u ( IdM 사용자의 기본으로도 사용)
  • guest_u
  • xguest_u
  • user_u
  • staff_u
그러나 이 기본 목록은 수정될 수 있으며 기본 SELinux 사용자( 32.1절. “ID 관리, SELinux 및 매핑 사용자 매핑 정보”참조)는 중앙 IdM SELinux 사용자 목록에서 추가하거나 제거할 수 있습니다.
IdM 서버 구성에서 각 SELinux 사용자는 사용자 이름뿐만 아니라 MLS 및 MCS 범위, SELinux_user:MLS[:MCS] 에도 구성됩니다. IPA 서버는 맵을 구성할 때 SELinux 사용자를 식별하기 위해 이 형식을 사용합니다.
IdM 사용자 및 호스트 구성은 매우 유연합니다. 사용자와 호스트는 SELinux 사용자 맵에 명시적으로, 개별적으로 할당하거나 사용자 그룹 또는 호스트 그룹을 맵에 명시적으로 할당할 수 있습니다.
또한 SELinux 매핑 규칙을 호스트 기반 액세스 제어 규칙과 연결하여 관리를 쉽게 만들고, 동일한 규칙을 두 위치에서 복제하고, 규칙을 동기화된 상태로 유지할 수 있습니다. 호스트 기반 액세스 제어 규칙이 사용자와 호스트를 정의하는 한 SELinux 사용자 맵에 사용할 수 있습니다. 호스트 기반 액세스 제어 규칙( 31장. 호스트 기반 액세스 제어 구성에서 설명됨)은 SELinux 사용자 맵을 IdM의 다른 액세스 제어 기능과 통합하고 원격 사용자를 위해 호스트 기반 사용자 액세스를 제한하거나 허용하고 로컬 보안 컨텍스트를 정의하는 데 도움이 될 수 있습니다.
참고
호스트 기반 액세스 제어 규칙이 SELinux 사용자 맵과 연결된 경우 SELinux 사용자 맵 구성에서 제거될 때까지 호스트 기반 액세스 제어 규칙을 삭제할 수 없습니다.
SELinux 사용자 맵은 SSSD(System Security Services Daemon) 및 10.0.0.1 _selinux 모듈과 함께 작동합니다. 원격 사용자가 시스템에 로그인하려고 하면 SSSD는 해당 IdM ID 공급자를 확인하여 SELinux 맵을 포함한 사용자 정보를 수집합니다. 그런 다음 PAM 모듈은 사용자를 처리하고 적절한 SELinux 사용자 컨텍스트를 할당합니다. SSSD 캐싱을 사용하면 매핑이 오프라인으로 작동할 수 있습니다.

32.2. SELinux 사용자 맵 순서 및 기본값 구성

SELinux 사용자 맵은 클라이언트의 SELinux 사용자와 IdM 사용자를 연결하는 것입니다.
사용 가능한 SELinux 사용자 맵 순서는 IdM 서버 구성의 일부입니다. SELinux 사용자 맵 순서는 가장 제한된 순서로 SELinux 사용자 목록입니다. SELinux 사용자 항목 자체에는 다음 형식이 있습니다.
SELinux_user:MLS[:MCS]
개별 사용자 항목은 달러 기호($)로 구분됩니다.
사용자 항목에 SELinux 맵이 있어야 하는 요구 사항이 없으므로 많은 항목이 매핑되지 않을 수 있습니다. IdM 서버 구성은 매핑되지 않은 IdM 사용자 항목에 사용할 전체 SELinux 맵 목록의 사용자 중 하나인 기본 SELinux 사용자를 설정합니다. 이렇게 하면 매핑되지 않은 IdM 사용자에게도 기능이 있는 SELinux 컨텍스트가 있습니다. 매핑되지 않은 IdM 사용자 항목의 기본 SELinux 사용자는 Red Hat Enterprise Linux의 시스템 사용자의 기본 SELinux 사용자인 unconfined_u 입니다.
이 구성은 사용 가능한 시스템 SELinux 사용자의 맵 순서를 정의합니다. IdM 사용자 SELinux 정책을 정의하지 않습니다. IdM 사용자 - SELinux 사용자 맵을 정의한 다음 사용자를 맵에 추가해야 합니다. 자세한 내용은 32.3절. “SELinux 사용자 및 IdM 사용자 매핑” 의 내용을 참조하십시오.

32.2.1. 웹 UI에서

  1. 상단 메뉴에서 IPA 서버 메인 탭과 Configuration (구성)을 클릭합니다.
  2. 서버 구성 영역 목록의 맨 아래로 스크롤하여 SELINUX OPTIONS 로 스크롤합니다.
  3. SELinux 사용자 구성, SELinux 사용자 맵 순서, 기본 SELinux 사용자 또는 둘 다를 편집합니다.
  4. 페이지 상단에 있는 업데이트 링크를 클릭하여 변경 사항을 저장합니다.

32.2.2. CLI에서

SELinux 사용자 목록을 보려면 매핑할 수 있는 IdM 서버 구성으로 설정합니다.
[user1]@server ~]$ ipa config-show
...
SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023
SELinux 사용자 설정을 편집하려면 config-mod 명령을 사용합니다.

예 32.1. SELinux 사용자 목록

매핑에 사용할 수 있는 SELinux 사용자 목록을 편집하려면 --ipaselinuxusermaporder 옵션을 사용합니다. 목록은 SELinux 사용자를 가장 적게 제한된 상태로 주문합니다. 예를 들면 다음과 같습니다.
[user1@server ~]$ ipa config-mod --ipaselinuxusermaporder="unconfined_u:s0-s0:c0.c1023$guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023"
참고
매핑되지 않은 항목에 사용되는 기본 SELinux 사용자는 사용자 맵 목록에 포함되어 있거나 편집 작업이 실패해야 합니다. 마찬가지로, 기본값을 편집한 경우 SELinux 맵 목록의 사용자로 변경하거나 맵 목록을 먼저 업데이트해야 합니다.

예 32.2. 기본 SELinux 사용자

IdM 사용자는 계정에 매핑된 특정 SELinux 사용자가 필요하지 않습니다. 그러나 로컬 시스템은 여전히 IdM 사용자 계정에 사용할 SELinux 사용자의 IdM 항목을 확인합니다.
기본 SELinux 사용자를 수정하려면 --ipaselinuxusermapdefault 옵션을 사용합니다. 예를 들어 다음과 같습니다.
[user1@server ~]$ ipa config-mod --ipaselinuxusermapdefault="guest_u:s0"

32.3. SELinux 사용자 및 IdM 사용자 매핑

SELinux 맵은 로컬 시스템의 SELinux 사용자 컨텍스트를 도메인 내에서 IdM 사용자 또는 사용자와 연결합니다. SELinux 맵에는 SELinux 사용자 컨텍스트 및 IdM 사용자 호스트 쌍의 세 부분이 있습니다. IdM 사용자-호스트 쌍은 두 가지 방법 중 하나로 정의할 수 있습니다. 즉, 명시적 사용자를 위해 설정하거나 명시적 호스트 또는 호스트 그룹에서 사용자 그룹을 설정하거나 호스트 기반 액세스 제어 규칙을 사용하여 정의할 수 있습니다.

32.3.1. 웹 UI에서

  1. 상단 메뉴에서 Policy main 탭과 SELinux User Mappings 를 클릭합니다.
  2. 매핑 목록에서 추가 버튼을 클릭하여 새 맵을 생성합니다.
  3. 맵 이름과 SELinux 사용자를 입력합니다. SELinux 사용자의 형식은 IdM 서버 구성에 표시되는 방식과 동일해야 합니다. SELinux 사용자의 형식은 SELinux_user:MLS[:MCS] 입니다.
  4. 추가 및 편집 을 클릭하여 IdM 사용자 정보를 추가합니다.
  5. 호스트 기반 액세스 제어 규칙을 설정하려면 구성의 일반 영역에 있는 드롭다운 메뉴에서 규칙을 선택합니다. 호스트 기반 액세스 제어 규칙을 사용하면 원격 사용자가 대상 시스템에 액세스하는 데 사용할 수 있는 호스트에 대한 액세스 제어가 가능합니다. 호스트 기반 액세스 제어 규칙은 하나만 할당할 수 있습니다.
    참고
    호스트 기반 액세스 제어 규칙에는 서비스가 아닌 사용자와 호스트가 포함되어야 합니다.
    또는 사용자 및 호스트 영역을 아래로 스크롤하고 추가 링크를 클릭하여 사용자, 사용자 그룹, 호스트 또는 호스트 그룹을 SELinux 맵에 할당합니다.
    왼쪽에서 사용자 (또는 호스트 또는 그룹)를 선택하고 오른쪽 화살표 버튼 (> )을 클릭하여 Prospective 열로 이동한 다음 Add 버튼을 클릭하여 규칙에 추가합니다.
    참고
    하나의 옵션만 사용할 수 있습니다. 호스트 기반 액세스 제어 규칙을 제공하거나 사용자 및 호스트를 수동으로 설정할 수 있습니다. 두 옵션을 동시에 사용할 수 없습니다.
  6. 상단에서 Update 링크를 클릭하여 SELinux 사용자 맵에 변경 사항을 저장합니다.

32.3.2. CLI에서

SELinux 맵 규칙에는 다음 세 가지 기본 부분이 있습니다.
  • SELinux 사용자: --selinuxuser
  • SELinux 사용자와 연결된 사용자 또는 사용자 그룹: --users 또는 --groups
  • SELinux 사용자와 연결된 호스트 또는 호스트 그룹: --hosts 또는 --hostgroups
  • 또는 호스트 및 사용자 모두를 지정하는 호스트 기반 액세스 제어 규칙: --hbacrule
selinuxusermap-add 명령을 사용하여 한 번에 모든 정보를 사용하여 규칙을 만들 수 있습니다. 각각 selinuxusermap-add-userselinuxusermap-add-host 명령을 사용하여 사용자 및 호스트를 생성한 후 규칙에 추가할 수 있습니다.

예 32.3. 새 SELinux 맵 생성

--selinuxuser 값은 IdM 서버 구성에 표시되는 대로 SELinux 사용자 이름이어야 합니다. SELinux 사용자의 형식은 SELinux_user:MLS[:MCS] 입니다.
SELinux 매핑이 유효하려면 사용자 또는 사용자 그룹 및 호스트 또는 호스트 그룹을 지정해야 합니다. 사용자, 호스트 및 그룹 옵션은 여러 번 사용하거나 중괄호 안에 쉼표로 구분된 목록으로 한 번 사용할 수 있습니다(예: --option={val1,val2,val3} ).
[user1@server ~]$ ipa selinuxusermap-add --selinuxuser="xguest_u:s0" selinux1
[user1@server ~]$ ipa selinuxusermap-add-user --users=user1 --users=user2 --users=user3 selinux1
[user1@server ~]$ ipa selinuxusermap-add-host --hosts=server.example.com --hosts=test.example.com selinux1

예 32.4. 호스트 기반 액세스 제어 규칙을 사용하여 SELinux 맵 생성

--hbacrule 값은 매핑에 사용할 호스트 기반 액세스 제어 규칙을 식별합니다. 호스트 기반 액세스 제어 규칙을 사용하면 원격 사용자가 대상 시스템에 로그인한 후 SELinux 컨텍스트를 적용하는 데 사용할 수 있는 호스트에 대한 액세스 제어가 가능합니다.
액세스 제어 규칙은 SELinux 맵에서 SELinux 사용자, IdM 사용자 및 호스트 위임을 구성할 수 있도록 사용자와 호스트를 적절하게 지정해야 합니다.
호스트 기반 액세스 제어 규칙은 하나만 지정할 수 있습니다.
[user1@server ~]$ ipa selinuxusermap-add --hbacrule=webserver --selinuxuser="xguest_u:s0" selinux1
호스트 기반 액세스 제어 규칙은 31장. 호스트 기반 액세스 제어 구성 에 설명되어 있습니다.

예 32.5. SELinux 맵에 사용자 추가

사용자와 호스트는 이미 존재하는 맵에 추가할 수 있습니다. 이 작업은 특정 명령인 selinuxusermap-add-user 또는 selinuxusermap-add-host 를 사용하여 수행됩니다.
[user1@server ~]$ ipa selinuxusermap-add-user --users=user1 selinux1
selinuxusermap-mod 명령을 --hbacrule 옵션과 함께 사용하여 기존 SELinux 맵을 수정하는 경우 새 SELinux 맵은 이전 SELinux 맵을 덮어씁니다.

예 32.6. SELinux 맵에서 사용자 제거

특정 사용자 또는 호스트는 selinuxusermap-remove-host 또는 selinuxusermap-remove-user 명령을 사용하여 SELinux 맵에서 제거할 수 있습니다. 예를 들어 다음과 같습니다.
[user1@server ~]$ ipa selinuxusermap-remove-user --users=user2 selinux1

VII 부. 관리: 네트워크 서비스 관리

이 부분에서는 ID 관리와 통합된 DNS( Domain Name Service )를 관리하는 방법과 Automount를 사용하여 여러 시스템에서 디렉터리를 관리, 구성 및 액세스하는 방법에 대해 설명합니다.

33장. DNS 관리

외부 DNS 서비스를 사용하거나 DNS를 구성한 상태로 ID 관리 서버를 통합 DNS 서비스 없이 설치할 수 있습니다. 자세한 내용은 2.3절. “IdM 서버 설치: 소개”2.3.1절. “통합 DNS 사용 여부 결정” 을 참조하십시오.
도메인 내에 DNS 서비스가 구성된 경우 IdM은 관리자에게 상당한 양의 유연성을 제공하고 DNS 설정을 제어합니다. 예를 들어 호스트 항목, 위치 또는 레코드와 같은 도메인의 DNS 항목은 기본 IdM 도구를 사용하여 관리할 수 있으며 클라이언트는 자체 DNS 레코드를 동적으로 업데이트할 수 있습니다.
BIND 버전 9.9에 사용할 수 있는 대부분의 문서 자료와 자습서도 IdM DNS에 적용할 수 있습니다. 대부분의 구성 옵션은 BIND 및 IdM에서 동일한 방식으로 작동하기 때문입니다. 이 장에서는 대부분 BIND와 IdM의 주요 차이점에 중점을 둡니다.

33.1. Identity Management의 BIND

IdM은 BIND DNS 서버 버전 9.9와 데이터 복제에 사용되는 LDAP 데이터베이스와 GSS-TSIG 프로토콜을 사용하여 DNS 업데이트 서명을 위해 Kerberos와 통합 [3]. IdM 툴을 사용하여 편리하게 DNS 관리를 가능하게 하고, IdM 통합 DNS 서버가 다중 마스터 작업을 지원하므로, 동시에 모든 IdM 통합 DNS 서버가 단일 장애 지점 없이 클라이언트의 DNS 업데이트를 허용할 수 있기 때문에 복원력이 향상됩니다.
기본 IdM DNS 구성은 공용 인터넷에서 액세스할 수 없는 내부 네트워크에 적합합니다. 공용 인터넷에서 IdM DNS 서버에 액세스할 수 있는 경우 Red Hat은 Red Hat Enterprise Linux 네트워킹 가이드에 설명된 BIND 서비스에 일반적인 강화를 적용하는 것이 좋습니다.
참고
chroot 환경 내에서 IdM과 통합된 BIND를 실행할 수 없습니다.
Red Hat Enterprise Linux의 DNS(Domain Name System) 프로토콜의 BIND(Berkeley Internet Name Domain) 구현에는 이름이 지정된 DNS 서버가 포함되어 있습니다. named -pkcs11 은 PKCS#11 암호화 표준을 기본적으로 지원하는 BIND DNS 서버 버전입니다.
IdM과 통합된 BIND는 bind-dyndb-ldap 플러그인을 사용하여 Directory 서버와 통신합니다. IdM은 /etc/named.conf 파일에 BIND 서비스에 대해 dynamic-db 구성 섹션을 생성합니다. 이 섹션은 BIND named-pkcs11 서비스에 대해 bind-dyndb-ldap 플러그인을 구성합니다.
표준 BIND와 IdM DNS의 가장 중요한 차이점은 IdM이 모든 DNS 정보를 LDAP 항목으로 저장하는 것입니다. 모든 도메인 이름은 LDAP 항목으로 표시되며 모든 리소스 레코드는 LDAP 항목의 LDAP 속성으로 저장됩니다. 예를 들어 다음 client1.example.com. 도메인 이름에 세 개의 A 레코드와 하나의 AAAA 레코드가 포함되어 있습니다.
dn: idnsname=client1,idnsname=example.com.,cn=dns,dc=idm,dc=example,dc=com
objectclass: top
objectclass: idnsrecord
idnsname: client1
Arecord: 192.0.2.1
Arecord: 192.0.2.2
Arecord: 192.0.2.3
AAAArecord: 2001:DB8::ABCD
중요
DNS 데이터 또는 BIND 구성을 편집하려면 항상 이 장에서 설명하는 IdM 도구를 사용합니다.

33.2. 지원되는 DNS 영역 유형

IdM은 마스터 영역 유형과 전달 영역의 두 가지 DNS 영역을 지원합니다.
참고
이 가이드에서는 Microsoft Windows DNS에 사용되는 용어와 다른 영역 유형에 대한 BIND 용어를 사용합니다. BIND의 마스터 영역은 Microsoft Windows DNS에서 정방향 조회 영역역방향 조회 영역과 동일한 목적을 제공합니다. BIND의 전달 영역은 Microsoft Windows DNS 의 조건부 전달자 와 동일한 목적을 제공합니다.
마스터 DNS 영역
마스터 DNS 영역에는 권한 있는 DNS 데이터가 포함되어 있으며 동적 DNS 업데이트를 허용할 수 있습니다. 이 동작은 표준 BIND 구성 의 master 설정과 동일합니다. 마스터 영역은 ipa dnszone-* 명령을 사용하여 관리됩니다.
표준 DNS 규칙에 따라 모든 마스터 영역에 SOA 및 NS 레코드가 포함되어야 합니다. IdM은 DNS 영역이 생성될 때 이러한 레코드를 자동으로 생성하지만 올바른 위임을 생성하려면 NS 레코드를 상위 영역에 수동으로 복사해야 합니다.
표준 BIND 동작에 따라 마스터 영역에 대해 지정된 전달 구성은 서버에 권한이 없는 이름에 대해서만 쿼리에 영향을 미칩니다.

예 33.1. DNS 전달의 시나리오 예

IdM 서버에는 test.example. 마스터 영역이 포함되어 있습니다. 이 영역에는 sub.test.example. 이름에 대한 NS 위임 레코드가 포함되어 있습니다. 또한 test.example. 영역은 192.0.2.254 전달자 IP 주소로 구성됩니다.
존재하지 않는.test.example. 이름을 쿼리하는 클라이언트는 NXDomain 응답을 수신하며 IdM 서버에 이 이름에 대한 권한이 있기 때문에 전달이 수행되지 않습니다.
반면 IdM 서버는 이 이름에 대한 권한이 없기 때문에 sub.test.example. 이름을 쿼리하는 것은 구성된 전달자 192.0.2.254 로 전달됩니다.
정방향 DNS 영역
정방향 DNS 영역에는 권한 있는 데이터가 포함되어 있지 않습니다. 전달 DNS 영역에 속하는 이름에 대한 모든 쿼리는 지정된 전달자로 전달됩니다. 이 동작은 표준 BIND 구성의 type forward 설정과 동일합니다. 전달 영역은 ipa dnsforwardzone-* 명령을 사용하여 관리됩니다.

33.3. DNS 구성 우선순위

많은 DNS 구성 옵션을 세 가지 다른 수준에서 구성할 수 있습니다.
영역별 구성
IdM에 정의된 특정 영역에 해당하는 구성 수준은 우선 순위가 가장 높습니다. 영역별 구성은 ipa dnszone-*ipa dnsforwardzone-* 명령을 사용하여 관리됩니다.
글로벌 DNS 구성
영역별 구성이 정의되지 않은 경우 IdM은 LDAP에 저장된 글로벌 DNS 구성을 사용합니다. 글로벌 DNS 구성은 ipa dnsconfig-* 명령을 사용하여 관리됩니다. 글로벌 DNS 구성에 정의된 설정은 모든 IdM DNS 서버에 적용됩니다.
/etc/named.conf의 구성
각 IdM DNS 서버의 /etc/named.conf 파일에 정의된 구성이 우선 순위가 가장 낮습니다. 각 서버에 따라 다르며 수동으로 편집해야 합니다.
/etc/named.conf 파일은 일반적으로 로컬 DNS 캐시로의 DNS 전달을 지정하는 데만 사용됩니다. 다른 옵션은 위에서 언급한 영역별 및 글로벌 DNS 구성에 대해 명령을 사용하여 관리됩니다.
DNS 옵션은 한 번에 여러 수준에서 구성할 수 있습니다. 이러한 경우 우선 순위가 가장 높은 구성이 더 낮은 수준에서 정의된 구성보다 우선합니다.

33.4. 마스터 DNS 영역 관리

33.4.1. 마스터 DNS 영역 추가 및 제거

웹 UI에서 마스터 DNS 영역 추가

  1. Network Services 탭을 열고 DNS Zones 섹션 다음에 DNS를 선택합니다.

    그림 33.1. DNS 마스터 영역 관리

    DNS 마스터 영역 관리
  2. 새 마스터 영역을 추가하려면 모든 영역 목록 상단에 있는 추가 를 클릭합니다.

    그림 33.2. 마스터 DNS 영역 추가

    마스터 DNS 영역 추가
  3. 영역 이름을 입력하고 추가 를 클릭합니다.

    그림 33.3. 새 마스터 영역 입력

    새 마스터 영역 입력

명령줄에서 마스터 DNS 영역 추가

ipa dnszone-add 명령은 DNS 도메인에 새 영역을 추가합니다. 새 영역을 추가하려면 새 하위 도메인의 이름을 지정해야 합니다. 명령을 사용하여 하위 도메인 이름을 직접 전달할 수 있습니다.
$ ipa dnszone-add newserver.example.com
ipa dnszone-add 에 이름을 전달하지 않으면 스크립트에서 자동으로 메시지를 표시합니다.
ipa dnszone-add 명령은 다양한 명령줄 옵션도 허용합니다. 이러한 옵션의 전체 목록은 ipa dnszone-add --help 명령을 실행합니다.

마스터 DNS 영역 제거

웹 UI에서 마스터 DNS 영역을 제거하려면 모든 영역 목록에서 영역 이름으로 확인란을 선택하고 삭제 를 클릭합니다.

그림 33.4. 마스터 DNS 영역 제거

마스터 DNS 영역 제거
명령줄에서 마스터 DNS 영역을 제거하려면 ipa dnszone-del 명령을 사용합니다. 예를 들어 다음과 같습니다.
$ ipa dnszone-del server.example.com

33.4.2. 마스터 DNS 영역에 대한 추가 구성 추가

IdM은 새로 고침 기간, 전송 설정 또는 캐시 설정과 같은 특정 기본 구성으로 새 영역을 생성합니다.

DNS 영역 구성 속성

사용 가능한 영역 설정은 표 33.1. “영역 속성” 에 나열됩니다. 영역에 대한 실제 정보와 함께 설정은 DNS 서버가 SOA( 권한 시작 ) 레코드 항목을 처리하는 방법과 DNS 이름 서버에서 레코드를 업데이트하는 방법을 정의합니다.

표 33.1. 영역 속성

속성 명령줄 옵션 Description
권한 있는 이름 서버 --name-server
SOA MNAME이라고도 하는 마스터 DNS 이름 서버의 도메인 이름을 설정합니다.
기본적으로 각 IdM 서버는 SOA MNAME 필드에서 자신을 알립니다. 결과적으로 --name-server 를 사용하여 LDAP에 저장된 값은 무시됩니다.
관리자 이메일 주소 --admin-email 영역 관리자에게 사용할 이메일 주소를 설정합니다. 이는 기본적으로 호스트의 root 계정입니다.
SOA 직렬 --serial SOA 레코드에 일련 번호를 설정합니다. IdM은 버전 번호를 자동으로 설정하며 사용자는 이를 수정할 필요가 없습니다.
SOA 새로 고침 --refresh 기본 DNS 서버에서 업데이트를 요청하기 전에 대기할 보조 DNS 서버의 간격(초)을 설정합니다.
SOA 재시도 --retry 실패한 새로 고침 작업을 재시도하기 전에 대기할 시간(초)을 설정합니다.
SOA 만료 --expire 보조 DNS 서버가 작업 시도를 종료하기 전에 새로 고침 업데이트를 시도하는 시간(초)을 설정합니다.
SOA 최소 --minimum RFC 2308 에 따라 음수 캐싱의 TTL(Time to live) 값을 초 단위로 설정합니다.
SOA 사용 시간 --ttl 영역 apex에서 레코드에 TTL(초)을 설정합니다. 예를 들어, 영역 example.com 에서 example.com이라는 이름의 모든 레코드(A, NS, 또는 SOA)는 구성되지만 test.example.com 과 같은 다른 도메인 이름은 영향을 받지 않습니다.
기본 사용 시간 --default-ttl 이전에 설정된 개별 TTL 값이 없는 영역의 모든 값에 대해 음수 캐싱의 기본 TTL(초) 값을 설정합니다. 변경 사항을 적용하려면 모든 IdM DNS 서버에서 named-pkcs11 서비스를 다시 시작해야 합니다.
BIND 업데이트 정책 --update-policy
DNS 영역의 클라이언트에 허용된 권한을 설정합니다.
동적 업데이트 --dynamic-update=TRUE|FALSE 클라이언트의 DNS 레코드 동적 업데이트를 활성화합니다.
이 값이 false로 설정되면 IdM 클라이언트 시스템이 IP 주소를 추가하거나 업데이트할 수 없습니다. 자세한 내용은 33.5.1절. “동적 DNS 업데이트 활성화”을 참조하십시오.
전송 허용 --allow-transfer=string
세미콜론(;)으로 구분된 지정된 영역을 전송할 수 있는 IP 주소 또는 네트워크 이름 목록을 제공합니다.
영역 전송은 기본적으로 비활성화되어 있습니다. 기본 --allow-transfer 값은 none 입니다.
쿼리 허용 --allow-query 세미콜론(;)으로 구분된 DNS 쿼리를 실행할 수 있는 IP 주소 또는 네트워크 이름 목록을 제공합니다.
PTR 동기화 허용 --allow-sync-ptr=1|0 영역의 A 또는 AAAA 레코드(전달 레코드)가 PTR(역방향) 레코드와 자동으로 동기화되는지 여부를 설정합니다.
영역 전달자 --forwarder=IP_address DNS 영역에 맞게 특별히 구성된 전달자를 지정합니다. IdM 도메인에 사용된 글로벌 전달자와는 다릅니다.
여러 전달자를 지정하려면 옵션을 여러 번 사용합니다.
전달 정책 --forward-policy=none|only|first 전달 정책을 지정합니다. 지원되는 정책에 대한 자세한 내용은 를 참조하십시오. “전달 정책”

웹 UI에서 영역 구성 편집

웹 UI에서 DNS 마스터 영역을 관리하려면 Network Services 탭을 열고 DNS 영역과 DNS 영역 섹션을 선택합니다.

그림 33.5. DNS 마스터 영역 관리

DNS 마스터 영역 관리
DNS 영역 섹션에서 기존 마스터 영역을 편집하려면 다음을 수행합니다.
  1. 모든 영역 목록에서 영역 이름을 클릭하여 DNS 영역 페이지를 엽니다.

    그림 33.6. 마스터 영역 편집

    마스터 영역 편집
  2. Settings (설정)를 클릭한 다음 필요에 따라 영역 구성을 변경합니다.

    그림 33.7. 마스터 영역 편집 페이지의 Settings(설정) 탭

    마스터 영역 편집 페이지의 Settings(설정) 탭
    사용 가능한 설정에 대한 자세한 내용은 표 33.1. “영역 속성” 을 참조하십시오.
  3. 저장 을 클릭하여 새 구성을 확인합니다.
참고
기본 시간을 영역의 라이브(TTL)로 변경하는 경우 모든 IdM DNS 서버에서 named-pkcs11 서비스를 다시 시작하여 변경 사항을 적용합니다. 다른 모든 설정은 즉시 자동으로 활성화됩니다.

명령줄에서 영역 구성 편집

명령줄에서 기존 마스터 DNS 영역을 수정하려면 ipa dnszone-mod 명령을 사용합니다. 사용 가능한 설정에 대한 자세한 내용은 표 33.1. “영역 속성” 을 참조하십시오.
DNS 영역 항목에 속성이 없는 경우 ipa dnszone-mod 명령에서 속성을 추가합니다. 특성이 있으면 명령은 현재 값을 지정된 값으로 덮어씁니다.
ipa dnszone-mod 및 해당 옵션에 대한 자세한 내용은 ipa dnszone-mod --help 명령을 실행하십시오.
참고
기본 시간을 영역의 라이브(TTL)로 변경하는 경우 모든 IdM DNS 서버에서 named-pkcs11 서비스를 다시 시작하여 변경 사항을 적용합니다. 다른 모든 설정은 즉시 자동으로 활성화됩니다.

33.4.3. 영역 전송 활성화

이름 서버는 영역에 대한 권한 있는 데이터를 유지 관리합니다. 영역에 대한 변경 사항은 DNS 도메인의 이름 서버로 전송하고 배포해야 합니다. 영역은 한 이름 서버에서 다른 이름 서버로 모든 리소스 레코드를 복사합니다.
IdM은 RFC 5936 (AXFR) 및 RFCFR ( IXFR) 표준에 따른 영역 전송을 지원합니다.
중요
IdM 통합 DNS는 다중 마스터입니다. IdM 영역의 SOA 일련 번호는 IdM 서버 간에 동기화되지 않습니다. 이러한 이유로 하나의 IdM 마스터 서버만 사용하도록 DNS 슬레이브 서버를 구성합니다. 이렇게 하면 동기화되지 않은 SOA 일련 번호로 인한 영역 전송 실패가 방지됩니다.

UI에서 영역 전송 활성화

“웹 UI에서 영역 구성 편집” 에 설명된 대로 DNS 영역 페이지를 열고 설정 탭으로 전환합니다.
허용 전송 에서 영역 레코드를 전송할 이름 서버를 지정합니다.

그림 33.8. 영역 전송 활성화

영역 전송 활성화
DNS 영역 페이지 상단에 있는 저장 을 클릭하여 새 구성을 확인합니다.

명령줄에서 영역 전송 활성화

명령줄에서 영역 전송을 활성화하려면 ipa dnszone-mod 명령에 --allow-transfer 옵션을 추가합니다. --allow-transfer 를 사용하여 영역 레코드를 전송할 이름 서버 목록을 지정합니다. 예를 들어 다음과 같습니다.
[user@server ~]$ ipa dnszone-mod --allow-transfer="192.0.2.1;198.51.100.1;203.0.113.1" example.com
바인드 서비스에서 영역 전송이 활성화되면 dig 유틸리티와 같은 클라이언트가 IdM DNS 영역을 이름별로 전송할 수 있습니다.
[root@server ~]# dig @ipa-server zone_name AXFR

33.4.4. DNS 영역에 레코드 추가

IdM은 다양한 레코드 유형을 지원합니다. 다음 네 가지 항목이 가장 자주 사용됩니다.
A
호스트 이름 및 일반 IPv4 주소에 대한 기본 맵입니다. A 레코드의 레코드 이름은 10.0.0.1과 같은 호스트 이름입니다. A 레코드의 IP Address 값은 192.0.2.1 과 같은 표준 IPv4 주소입니다.
A 레코드에 대한 자세한 내용은 RFC 1035 를 참조하십시오.
AAAA
호스트 이름 및 IPv6 주소에 대한 기본 맵입니다. AAAA 레코드의 레코드 이름은 10.0.0.1과 같은 호스트 이름입니다. IP Address 값은 2001:DB8::1111 과 같은 표준 16진수 IPv6 주소입니다.
AAAA 레코드에 대한 자세한 내용은 RFC 3596 을 참조하십시오.
SRV
SRV(서비스) 리소스 레코드는 서비스 이름을 특정 서비스를 제공하는 서버의 DNS 이름에 매핑합니다. 예를 들어 이 레코드 유형은 LDAP 디렉터리와 같은 서비스를 관리하는 서버에 매핑할 수 있습니다.
SRV 레코드의 레코드 이름은 _service._protocol형식(예: _ ldap._tcp )입니다. SRV 레코드의 구성 옵션에는 대상 서비스의 우선 순위, 가중치, 포트 번호, 호스트 이름이 포함됩니다.
SRV 레코드에 대한 자세한 내용은 RFC 2782 를 참조하십시오.
PTR
포인터 레코드 유형(PTR) 레코드는 IP 주소를 도메인 이름에 매핑하는 역방향 DNS 레코드를 추가합니다.
참고
IPv4 주소의 모든 역방향 DNS 조회에서는 in-addr.arpa. 도메인에 정의된 역방향 항목을 사용합니다. 사람이 읽을 수 있는 형식의 역방향 주소는 일반 IP 주소의 정확한 반대이며 in-addr.arpa. 도메인이 추가됩니다. 예를 들어 네트워크 주소 192.0.2.0/24 의 경우 역방향 영역은 2.0.192.in-addr.arpa 입니다.
PTR 레코드의 레코드 이름은 RFC 1035에 지정된 표준 형식이어야 하며 RFC 2317에서 확장되고 RFC 3596 이어야 합니다. 호스트 이름 값은 레코드를 생성하려는 호스트의 정식 호스트 이름이어야 합니다. 자세한 내용은 예 33.8. “PTR 레코드”의 내용을 참조하십시오.
참고
.ip6.arpa. 도메인의 영역을 사용하여 IPv6 주소에 대해 역방향 영역을 구성할 수도 있습니다. IPv6 역방향 영역에 대한 자세한 내용은 RFC 3596 을 참조하십시오.
DNS 리소스 레코드를 추가할 때 대부분의 레코드에는 서로 다른 데이터가 필요합니다. 예를 들어 CNAME 레코드에는 호스트 이름이 필요하지만 A 레코드에는 IP 주소가 필요합니다. 웹 UI에서 새 레코드를 추가하기 위한 양식의 필드는 현재 선택된 레코드 유형에 필요한 데이터를 반영하여 자동으로 업데이트됩니다.

DNS 와일드카드 지원

IdM은 DNS 영역에서 와일드카드로 특수 레코드 * 를 지원합니다.

예 33.2. DNS 와일드카드 결과 시연

  1. DNS 영역 example.com에서 다음을 구성합니다.
    • 와일드카드 A 레코드 *.example.com.
    • mail.example.com 에 대한 MX 레코드이지만 이 호스트에 대한 A 레코드는 없습니다.
    • demo.example.com 에 대한 레코드가 없습니다.
  2. 기존 및 존재하지 않는 DNS 레코드 및 유형을 쿼리합니다. 다음과 같은 결과가 나타납니다.
    # host -t MX mail.example.com.
    mail.example.com mail is handled by 10 server.example.com.
    
    # host -t MX demo.example.com.
    demo.example.com. has no MX record.
    
    # host -t A mail.example.com.
    mail.example.com has no A record
    
    # host -t A demo.example.com.
    random.example.com has address 192.168.1.1
    
자세한 내용은 RFC1034 를 참조하십시오.

웹 UI에서 DNS 리소스 레코드 추가

  1. “웹 UI에서 영역 구성 편집” 에 설명된 대로 DNS 영역 페이지를 엽니다.
  2. DNS 리소스 레코드 섹션에서 추가 를 클릭하여 새 레코드를 추가합니다.

    그림 33.9. 새 DNS 리소스 레코드 추가

    새 DNS 리소스 레코드 추가
  3. 필요에 따라 레코드 유형을 선택하고 다른 필드를 작성합니다.

    그림 33.10. 새 DNS 리소스 레코드 정의

    새 DNS 리소스 레코드 정의
  4. 추가 를 클릭하여 새 레코드를 확인합니다.

명령줄에서 DNS 리소스 레코드 추가

명령줄에서 모든 유형의 DNS 리소스 레코드를 추가하려면 ipa dns records-add 명령을 사용합니다. 명령은 다음 구문을 따릅니다.
$ ipa dnsrecord-add zone_name record_name --record_type_option=data
zone_name 은 레코드를 추가할 DNS 영역의 이름입니다. record_name 은 새 DNS 리소스 레코드의 식별자입니다.
표 33.2. “Common ipa dnsrecord-add Options” 가장 일반적인 리소스 레코드 유형에 대한 옵션을 나열합니다. A(IPv4), AAAA(IPv6), SRV 및 PTR. 항목 목록은 동일한 명령 호출과 함께 옵션을 여러 번 사용하거나 Bash에서 --option={val1,val2,val3} 과 같이 중괄호 안에 쉼표로 구분된 목록에 옵션을 나열하여 설정할 수 있습니다.
ipa dnsrecord-add 사용 방법과 IdM에서 지원하는 DNS 레코드 유형에 대한 자세한 내용은 ipa dnsrecord-add --help 명령을 실행하십시오.

표 33.2. Common ipa dnsrecord-add Options

일반 레코드 옵션
옵션 Description
--ttl=number 레코드의 시간을 live으로 설정합니다.
--structured 원시 DNS 레코드를 구문 분석하고 구조화된 형식으로 반환합니다.
"a" 레코드 옵션
옵션 Description
--a-rec=ARECORD A 레코드 목록을 전달합니다.
--a-ip-address=string 레코드의 IP 주소를 제공합니다.
"AAAA" 레코드 옵션
옵션 Description
--aaaa-rec=AAAARECORD AAAA(IPv6) 레코드 목록을 전달합니다.
--aaaa-ip-address=string 레코드의 IPv6 주소를 제공합니다.
"PTR" 레코드 옵션
옵션 Description
--ptr-rec=PTRRECORD PTR 레코드 목록을 전달합니다.
--ptr-hostname=string 레코드의 호스트 이름을 제공합니다.
"SRV" 레코드 옵션
옵션 Description
--srv-rec=SRVRECORD SRV 레코드 목록을 전달합니다.
--srv-priority=number 레코드의 우선 순위를 설정합니다. 서비스 유형에는 여러 SRV 레코드가 있을 수 있습니다. 우선 순위 (0 - 65535)는 레코드의 순위를 설정하고 숫자가 낮을수록 우선 순위가 높습니다. 서비스는 우선 순위가 가장 높은 레코드를 먼저 사용해야 합니다.
--srv-weight=number 레코드의 가중치를 설정합니다. 이렇게 하면 우선 순위가 동일한 SRV 레코드의 순서를 결정하는 데 도움이 됩니다. 설정 가중치는 특정 레코드가 사용되는 가능성을 나타내는 최대 100을 추가해야 합니다.
--srv-port=number 대상 호스트에서 서비스의 포트를 제공합니다.
--srv-target=string 대상 호스트의 도메인 이름을 제공합니다. 도메인에서 서비스를 사용할 수 없는 경우 이 마침표(.)가 될 수 있습니다.

33.4.5. 명령줄에서 DNS 리소스 레코드 추가 또는 수정의 예

예 33.3. IPv4 레코드 추가

다음 예제에서는 IP 주소 192.0.2.123 을 사용하여 레코드 www.example.com 를 생성합니다.
$ ipa dnsrecord-add example.com www --a-rec 192.0.2.123

예 33.4. IPv4 와일드카드 레코드 추가

다음 예제에서는 IP 주소 192.0.2.123 을 사용하여 와일드카드 A 레코드를 생성합니다.
$ ipa dnsrecord-add example.com "*" --a-rec 192.0.2.123

예 33.5. IPv4 레코드 수정

레코드를 만들 때 A 레코드 값을 지정하는 옵션은 --a-record 입니다. 그러나 A 레코드를 수정할 때 --a- record 옵션을 사용하여 A 레코드의 현재 값을 지정합니다. 새 값은 --a-ip-address 옵션으로 설정됩니다.
$ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1

예 33.6. IPv6 레코드 추가

다음 예제에서는 IP 주소 2001:db8::1231:5675 를 사용하여 www.example.com 레코드를 생성합니다.
$ ipa dnsrecord-add example.com www --aaaa-rec 2001:db8::1231:5675

예 33.7. SRV 레코드 추가

다음 예에서 _ldap._tcp 는 SRV 레코드에 대한 서비스 유형 및 연결 프로토콜을 정의합니다. srv -rec 옵션은 priority, weight, port 및 target 값을 정의합니다.
예를 들어 다음과 같습니다.
[root@server ~]# ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="0 51 389 server1.example.com."
[root@server ~]# ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="1 49 389 server2.example.com."
가중치 값(이 예에서5149 )은 최대 100을 추가하고 특정 레코드가 사용될 확률(%)을 나타냅니다.

예 33.8. PTR 레코드

역방향 DNS 레코드를 추가할 때 ipa dns records-add 명령과 함께 사용된 영역 이름은 다른 DNS 레코드를 추가하는 사용과 비교됩니다.
$ ipa dnsrecord-add reverseNetworkIpAddress hostIpAddress --ptr-rec FQDN
일반적으로 hostIpAddress 는 지정된 네트워크에 있는 IP 주소의 마지막 옥텟입니다.
예를 들어 IPv4 주소 192.0.2.4를 사용하는 server4.example.com 의 PTR 레코드가 추가됩니다.
$ ipa dnsrecord-add 2.0.192.in-addr.arpa 4 --ptr-rec server4.example.com.
다음 예제에서는 역방향 DNS 항목을 0.0.0.0.0.0.8.b.0.1.0.0.2.ip6.arpa에 추가합니다. IP 주소 2001:DB8::1111 을 사용하여 호스트 server2.example.com 의 IPv6 역방향 영역:
$ ipa dnsrecord-add 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 1.1.1.0.0.0.0.0.0.0.0.0.0.0.0 --ptr-rec server2.example.com.

33.4.6. DNS 영역에서 레코드 삭제

웹 UI에서 레코드 삭제

리소스 레코드에서 특정 레코드 유형만 삭제하려면 다음을 수행합니다.
  1. “웹 UI에서 영역 구성 편집” 에 설명된 대로 DNS 영역 페이지를 엽니다.
  2. DNS 리소스 레코드 섹션에서 리소스 레코드의 이름을 클릭합니다.

    그림 33.11. DNS 리소스 레코드 선택

    DNS 리소스 레코드 선택
  3. 삭제할 레코드 유형의 이름으로 확인란을 선택합니다.

    그림 33.12. DNS 리소스 레코드 삭제

    DNS 리소스 레코드 삭제
    이 후에는 선택한 레코드 유형만 삭제됩니다. 다른 구성은 그대로 유지됩니다.
영역에서 리소스의 모든 레코드를 삭제하려면 다음을 수행합니다.
  1. “웹 UI에서 영역 구성 편집” 에 설명된 대로 DNS 영역 페이지를 엽니다.
  2. DNS 리소스 레코드 섹션에서 삭제할 리소스 레코드의 이름으로 확인란을 선택한 다음 영역 레코드 목록의 맨 위에 있는 삭제 를 클릭합니다.

    그림 33.13. 전체 리소스 레코드 삭제

    전체 리소스 레코드 삭제
    이 후에는 전체 리소스 레코드가 삭제됩니다.

명령줄에서 레코드 삭제

영역에서 레코드를 제거하려면 ipa dns records-del 명령을 사용하고 레코드 값과 함께 --recordType-rec 옵션을 추가합니다.
예를 들어 A 유형 레코드를 제거하려면 다음을 수행합니다.
$ ipa dnsrecord-del example.com www --a-rec 192.0.2.1
옵션 없이 ipa dnsrecord-del 을 실행하면 명령에서 삭제할 레코드에 대한 정보를 입력하라는 메시지를 표시합니다. 명령과 함께 --del-all 옵션을 전달하면 영역의 관련 레코드가 모두 제거됩니다.
ipa dnsrecord-del 을 사용하는 방법과 명령에서 허용하는 전체 옵션 목록에 대한 자세한 내용은 ipa dnsrecord-del --help 명령을 실행하십시오.

33.4.7. 영역 비활성화 및 활성화

IdM을 사용하면 관리자가 DNS 영역을 비활성화 및 활성화할 수 있습니다. “마스터 DNS 영역 제거” 에 설명된 DNS 영역을 삭제하는 동안 영역 항목 및 모든 관련 구성이 완전히 제거되므로, IdM에서 영역을 영구적으로 제거하지 않고 영역이 활동에서 제거됩니다. 비활성화된 영역도 다시 활성화할 수 있습니다.

웹 UI에서 영역 비활성화 및 활성화

웹 UI에서 DNS 영역을 관리하려면 Network Services 탭을 열고 DNS 영역 다음에 DNS 영역 섹션을 선택합니다.

그림 33.14. DNS 영역 관리

DNS 영역 관리
영역을 비활성화하려면 영역 이름 옆에 있는 확인란을 선택하고 비활성화 를 클릭합니다.

그림 33.15. DNS 영역 비활성화

DNS 영역 비활성화
마찬가지로, 비활성화된 영역을 활성화하려면 영역 이름 옆에 있는 확인란을 선택하고 사용을 클릭합니다.

명령줄에서 DNS 영역 비활성화 및 활성화

명령줄에서 DNS 영역을 비활성화하려면 ipa dnszone-disable 명령을 사용합니다. 예를 들어 다음과 같습니다.
[user@server ~]$ ipa dnszone-disable zone.example.com
-----------------------------------------
Disabled DNS zone "example.com"
-----------------------------------------
비활성화된 영역을 다시 활성화하려면 ipa dnszone-enable 명령을 사용합니다.

33.5. 동적 DNS 업데이트 관리

33.5.1. 동적 DNS 업데이트 활성화

동적 DNS 업데이트는 IdM의 새 DNS 영역에 대해 기본적으로 비활성화되어 있습니다. 동적 업데이트가 비활성화된 경우 ipa-client-install 스크립트는 새 클라이언트를 가리키는 DNS 레코드를 추가할 수 없습니다.
참고
동적 업데이트를 활성화하면 보안 위험이 발생할 수 있습니다. 그러나 사용자 환경에서 동적 업데이트를 활성화할 수 있는 경우 더 쉽게 클라이언트 설치를 수행할 수 있습니다.
동적 업데이트를 활성화하려면 다음이 필요합니다.
  • 동적 업데이트를 허용하도록 DNS 영역을 구성해야 합니다
  • 동적 업데이트를 보내도록 로컬 클라이언트를 구성해야 합니다.

33.5.1.1. 동적 업데이트를 허용하도록 DNS 영역 구성

웹 UI에서 동적 DNS 업데이트 활성화

  1. Network Services 탭을 열고 DNS Zones 섹션 다음에 DNS를 선택합니다.

    그림 33.16. DNS 영역 관리

    DNS 영역 관리
  2. 모든 영역 목록에서 영역 이름을 클릭하여 DNS 영역 페이지를 엽니다.

    그림 33.17. 마스터 영역 편집

    마스터 영역 편집
  3. 설정을 클릭하여 DNS 영역 설정 탭으로 전환합니다.

    그림 33.18. 마스터 영역 편집 페이지의 Settings(설정) 탭

    마스터 영역 편집 페이지의 Settings(설정) 탭
  4. 아래로 스크롤하여 Dynamic update 필드까지 스크롤하고 값을 True 로 설정합니다.

    그림 33.19. 동적 DNS 업데이트 활성화

    동적 DNS 업데이트 활성화
  5. 페이지 상단에서 저장 을 클릭하여 새 구성을 확인합니다.

명령줄에서 동적 DNS 업데이트 활성화

명령줄에서 DNS 영역을 동적으로 업데이트할 수 있도록 하려면 --dynamic-update=TRUE 옵션과 함께 ipa dnszone-mod 명령을 사용합니다. 예를 들어 다음과 같습니다.
[user@server ~]$ ipa dnszone-mod server.example.com --dynamic-update=TRUE

33.5.1.2. 동적 업데이트를 전송하도록 클라이언트 구성

클라이언트는 ipa-client-install 스크립트와 함께 --enable-dns-updates 옵션을 사용하여 도메인에 등록할 때 DNS 업데이트를 자동으로 보내도록 설정됩니다.
[root@client ~]# ipa-client-install --enable-dns-updates
DNS 영역에는 SOA 구성 내의 레코드에 대해 설정된 TTL(Time to Live) 값이 있습니다. 그러나 동적 업데이트의 TTL은 SSSD(시스템 보안 서비스 데몬)에 의해 로컬 시스템에서 관리됩니다. 동적 업데이트의 TTL 값을 변경하려면 SSSD 파일을 편집하여 값을 설정합니다. 기본값은 1200초입니다.
  1. SSSD 구성 파일을 엽니다.
    [root@server ~]# vim /etc/sssd/sssd.conf
  2. IdM 도메인의 도메인 섹션을 찾습니다.
    [domain/ipa.example.com]
  3. 클라이언트에 동적 업데이트가 활성화되지 않은 경우 dyndns_update 값을 true로 설정합니다.
    dyndns_update = true
  4. dyndns_ttl 매개 변수를 추가하거나 편집하여 값을 초 단위로 설정합니다.
    dyndns_ttl = 2400

33.5.2. A/AAAA 및 PTR 레코드 동기화

및 AAAA 레코드는 역방향 영역의 PTR 레코드와 별도로 구성됩니다. 이러한 레코드는 독립적으로 구성되므로 해당 PTR 레코드 없이 A/AAAA 레코드가 존재할 수 있으며 그 반대의 경우도 마찬가지입니다.
PTR 동기화가 작동하려면 몇 가지 DNS 설정 요구 사항이 있습니다.
  • 정방향 및 역방향 영역 모두 IdM 서버에서 관리해야 합니다.
  • 두 영역 모두 동적 업데이트를 활성화해야 합니다.
    동적 업데이트 활성화에 대해서는 33.5.1절. “동적 DNS 업데이트 활성화” 에서 다룹니다.
  • 마스터 정방향 및 역방향 영역에 대해 PTR 동기화를 활성화해야 합니다.
  • PTR 레코드는 요청하는 클라이언트의 이름이 PTR 레코드의 이름과 일치하는 경우에만 업데이트됩니다.
중요
IdM 웹 UI를 통해 또는 IdM 명령줄 도구를 통해 수행된 변경 사항 또는 LDAP 항목을 직접 편집하여 PTR 레코드를 업데이트 하지 않습니다. DNS 서비스 자체의 변경 사항만 PTR 레코드 동기화를 트리거합니다.
주의
클라이언트 시스템은 자체 IP 주소를 업데이트할 수 있습니다. 즉, 손상된 클라이언트를 사용하여 IP 주소를 변경하여 PTR 레코드를 덮어쓸 수 있습니다.

33.5.2.1. 웹 UI에서 PTR 레코드 동기화 구성

PTR 레코드는 PTR 레코드가 있는 역방향 DNS 영역이 아닌 A 또는 AAAA 레코드가 저장된 영역에서 PTR 레코드 동기화를 구성해야 합니다.
  1. Network Services 탭을 열고 DNS Zones 섹션 다음에 DNS를 선택합니다.

    그림 33.20. DNS 영역 관리

    DNS 영역 관리
  2. 모든 영역 목록에서 영역 이름을 클릭하여 DNS 영역 페이지를 엽니다.

    그림 33.21. DNS 영역 편집

    DNS 영역 편집
  3. 설정을 클릭하여 DNS 영역 설정 탭으로 전환합니다.

    그림 33.22. 마스터 영역 편집 페이지의 Settings(설정) 탭

    마스터 영역 편집 페이지의 Settings(설정) 탭
  4. Allow PTR sync 확인란을 선택합니다.

    그림 33.23. PTR 동기화 활성화

    PTR 동기화 활성화
  5. 페이지 상단에서 저장 을 클릭하여 새 구성을 확인합니다.

33.5.2.2. 명령줄을 사용하여 PTR 레코드 동기화 구성

특정 영역에 대해 PTR 레코드 동기화를 구성하거나 명령줄을 사용하는 모든 영역에 대해 전역적으로 구성할 수 있습니다.
33.5.2.2.1. 특정 영역에 대한 PTR 레코드 동기화 구성
예를 들어 idm.example.com 전달 영역에 대한 PTR 레코드 동기화를 구성하려면 다음을 수행합니다.
  1. 정방향 영역에 대한 동적 업데이트를 활성화합니다.
    # ipa dnszone-mod idm.example.com. --dynamic-update=TRUE
  2. forward 영역의 업데이트 정책을 구성합니다.
    # ipa dnszone-mod idm.example.com. --update-policy='grant IDM.EXAMPLE.COM krb5-self * A; grant IDM.EXAMPLE.COM krb5-self * AAAA; grant IDM.EXAMPLE.COM krb5-self * SSHFP;'
  3. 전달 영역에 대한 PTR 레코드 동기화를 활성화합니다.
    # ipa dnszone-mod idm.example.com. --allow-sync-ptr=True
  4. 역방향 영역에 대한 동적 업데이트를 활성화합니다.
    # ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE
33.5.2.2.2. 모든 영역에 대해 전역적으로 PTR 레코드 동기화 구성
다음 절차 중 하나를 사용하여 IdM에서 관리하는 모든 영역에 대해 PTR 동기화를 활성화할 수 있습니다.
  • 모든 서버의 모든 영역에 대해 동시에 PTR 동기화를 활성화하려면 다음을 수행합니다.
    # ipa dnsconfig-mod --allow-sync-ptr=true
  • 서버당 동기화를 활성화하려면 다음을 수행합니다.
    1. /etc/named.conf 파일의 dyndb "/usr/lib64/bind/ldap.so" 섹션에 sync_ptr yes; 설정을 추가합니다.
      dyndb "ipa" "/usr/lib64/bind/ldap.so" {
         ...
         sync_ptr yes;
      };
    2. IdM을 다시 시작합니다.
      # ipactl restart
    3. DNS 서비스가 설치된 각 IdM 서버에서 단계를 반복합니다.

33.5.3. DNS 동적 업데이트 정책 업데이트

IdM 서버에서 유지 관리하는 DNS 도메인을 RFC 3007에 따라 DNS 동적 업데이트를 수락할 수 있습니다.[4].
특정 클라이언트에서 수정할 수 있는 레코드를 결정하는 규칙은 /etc/named.conf 파일의 update-policy 문과 동일한 구문을 따릅니다. 동적 업데이트 정책에 대한 자세한 내용은 BIND 9 설명서를 참조하십시오.
동적 DNS 업데이트가 DNS 영역에 대해 비활성화되어 있으면 동적 업데이트 정책 문을 반영하지 않고 모든 DNS 업데이트가 거부됩니다. 동적 DNS 업데이트 활성화에 대한 자세한 내용은 33.5.1절. “동적 DNS 업데이트 활성화” 을 참조하십시오.

웹 UI에서 DNS 업데이트 정책 업데이트

  1. Network Services 탭을 열고 DNS Zones 섹션 다음에 DNS를 선택합니다.

    그림 33.24. DNS 영역 관리

    DNS 영역 관리
  2. 모든 영역 목록에서 영역 이름을 클릭하여 DNS 영역 페이지를 엽니다.

    그림 33.25. DNS 영역 편집

    DNS 영역 편집
  3. 설정을 클릭하여 DNS 영역 설정 탭으로 전환합니다.

    그림 33.26. 마스터 영역 편집 페이지의 Settings(설정) 탭

    마스터 영역 편집 페이지의 Settings(설정) 탭
  4. BIND 업데이트 정책 텍스트 상자에 enmi-colon 구분 목록에 필요한 업데이트 정책을 설정합니다.

    그림 33.27. DNS 업데이트 정책 설정

    DNS 업데이트 정책 설정
  5. DNS 영역 페이지 상단에 있는 저장 을 클릭하여 새 구성을 확인합니다.

명령줄에서 DNS 업데이트 정책 업데이트

명령줄에서 DNS 업데이트 정책을 설정하려면 --update-policy 옵션을 사용하고 옵션 뒤의 문에 액세스 제어 규칙을 추가합니다. 예를 들어 다음과 같습니다.
$ ipa dnszone-mod zone.example.com --update-policy "grant EXAMPLE.COM  krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; grant EXAMPLE.COM  krb5-self * SSHFP;"


[4] RFC 3007의 전체 텍스트는 다음을 참조하십시오. http://tools.ietf.org/html/rfc3007

33.6. DNS 전달 관리

DNS 전달은 DNS 쿼리 응답 방법에 영향을 미칩니다. 기본적으로 IdM과 통합된 BIND 서비스는 권한 있고 재귀적인 DNS 서버 역할을 하도록 구성됩니다.
DNS 클라이언트가 IdM 서버가 권한 있는 DNS 영역에 속하는 이름을 쿼리하면 BIND에서 구성된 영역에 포함된 데이터로 응답합니다. 권한 있는 데이터는 항상 다른 데이터보다 우선합니다.
DNS 클라이언트가 IdM 서버에 권한이 없는 이름을 쿼리하면 BIND에서 다른 DNS 서버를 사용하여 쿼리합니다. 전달자가 정의되지 않은 경우 BIND에서 인터넷의 루트 서버에 질문을 하고 재귀 확인 알고리즘을 사용하여 DNS 쿼리에 응답합니다.
경우에 따라 BIND에서 다른 DNS 서버에 직접 연결하고 인터넷에서 사용 가능한 데이터를 기반으로 재귀를 수행하는 것이 바람직하지 않습니다. 이러한 경우는 다음과 같습니다.
  • DNS 서버가 다른 클라이언트에 다른 응답을 반환하는 분할 DNS 구성(DNS 구성이라고도 함). 분할 DNS 구성은 회사 네트워크 내에서 일부 DNS 이름을 사용할 수 있지만 외부에서는 사용할 수 없는 환경에 일반적으로 사용됩니다.
  • 방화벽이 인터넷의 DNS에 대한 액세스를 제한하는 구성입니다.
  • 중앙 집중식 필터링 또는 DNS 수준에서 로깅이 포함된 구성.
  • 로컬 DNS 캐시로 전달할 수 있는 구성으로 네트워크 트래픽을 최적화하는 데 도움이 됩니다.
이러한 구성에서는 BIND에서 공용 인터넷에서 전체 재귀를 사용하지 않습니다. 대신, 쿼리를 확인하기 위해 forwarder 라는 다른 DNS 서버를 사용합니다. BIND가 전달자를 사용하도록 구성되면 IdM 서버와 전달자 간에 쿼리와 응답이 전달되고 IdM 서버는 권한 없는 데이터의 DNS 캐시 역할을 합니다.

전달 정책

IdM은 번째 및 유일한 표준 BIND 전달 정책뿐만 아니라 none IdM 관련 전달 정책을 지원합니다.
전달 첫 번째 (기본값)
DNS 쿼리는 구성된 전달자로 전달됩니다. 서버 오류 또는 시간 초과로 인해 쿼리가 실패하면 BIND에서 인터넷의 서버를 사용하여 재귀 확인으로 대체됩니다. forward first 정책이 기본 정책입니다. 트래픽 최적화에 적합합니다.
앞으로 전용
DNS 쿼리는 구성된 전달자로 전달됩니다. 서버 오류 또는 시간 초과로 인해 쿼리가 실패하면 BIND에서 클라이언트에 오류를 반환합니다. 분할된 DNS 구성이 있는 환경에는 정방향 전용 정책이 권장됩니다.
없음: 전달 비활성화
DNS 쿼리는 전달되지 않습니다. 전달 비활성화는 글로벌 전달 구성의 영역별 재정의로만 유용합니다. 이 옵션은 BIND 구성에 빈 전달자 목록을 지정하는 것과 동일한 IdM입니다.

IdM 및 기타 DNS 서버에서 데이터를 결합하지 않음

전달은 IdM의 데이터와 다른 DNS 서버의 데이터를 결합하는 데 사용할 수 없습니다. IdM DNS에서 마스터 영역의 특정 하위 영역에 대한 쿼리만 전달할 수 있습니다. “IdM DNS 마스터 영역의 영역 위임” 을 참조하십시오.
기본적으로 쿼리된 DNS 이름이 IdM 서버에 권한이 있는 영역에 속하는 경우 BIND 서비스는 쿼리를 다른 서버로 전달하지 않습니다. 이러한 상황에서 IdM 데이터베이스에서 쿼리된 DNS 이름을 찾을 수 없는 경우 NXDOMAIN 응답이 반환됩니다. 전달이 사용되지 않습니다.

예 33.9. 예제 시나리오

IdM 서버에는 test.example 권한이 있습니다. DNS 영역. BIND는 192.0.2.254 IP 주소를 사용하여 DNS 서버로 쿼리를 전달하도록 구성되어 있습니다.
클라이언트가 nonexistent.test.example에 대한 쿼리를 보내는 경우 DNS 이름인 BIND는 IdM 서버에 test.example. 영역에 대한 권한이 있고, 쿼리를 192.0.2.254. 서버로 전달하지 않음을 탐지합니다. 결과적으로 DNS 클라이언트는 NXDomain 응답을 수신하여 쿼리된 도메인이 존재하지 않음을 사용자에게 알립니다.
IdM DNS 마스터 영역의 영역 위임
IdM DNS에서 마스터 영역의 특정 하위 영역에 대한 쿼리를 전달할 수 있습니다. 예를 들어 IdM DNS가 영역 idm.example.com 을 처리하는 경우 sub_zone1.idm.example.com 하위 영역에 대한 권한을 다른 DNS 서버에 위임할 수 있습니다. 이 동작을 수행하려면 위에서 설명한 대로 하위 영역을 다른 DNS 서버에 위임하는 이름 서버 레코드와 함께 전달을 사용해야 합니다. 다음 예에서 sub_zone1 은 하위 영역이며 192.0.2.1 은 하위 영역이 위임된 DNS 서버의 IP 주소입니다.
$ ipa dnsrecord-add idm.example.com. sub_zone1 --ns-rec=192.0.2.1
forward 영역을 추가한 후 다음과 같이 표시됩니다.
$ ipa dnsforwardzone-add  sub_zone1.idm.example.com. --forwarder 192.0.2.1

33.6.1. 글로벌 전달자 구성

글로벌 전달자는 33.6절. “DNS 전달 관리” 에 설명된 대로 IdM 서버가 권한이 없는 모든 DNS 쿼리를 확인하는 데 사용하는 DNS 서버입니다.
관리자는 다음 두 가지 방법으로 글로벌 전달에 대한 IP 주소 및 전달 정책을 구성할 수 있습니다.
ipa dnsconfig-mod 명령 또는 IdM 웹 UI 사용
이러한 기본 IdM 도구를 사용하는 구성은 모든 IdM DNS 서버에 즉시 적용됩니다. 33.3절. “DNS 구성 우선순위” 에 설명된 대로 글로벌 DNS 구성은 /etc/named.conf 파일에 정의된 로컬 구성보다 우선 순위가 높습니다.
/etc/named.conf 파일을 편집합니다.
모든 IdM DNS 서버에서 /etc/named.conf 를 수동으로 편집하면 각 서버에서 다른 글로벌 전달자 및 정책을 사용할 수 있습니다. /etc/named.conf 를 변경한 후 BIND 서비스를 다시 시작해야 합니다.

웹 UI에서 전달자 구성

IdM 웹 UI에서 DNS 글로벌 구성을 정의하려면 다음을 수행합니다.
  1. Network Services 탭을 클릭하고 DNS Global Configuration 섹션을 선택합니다.
  2. 새 글로벌 전달자를 추가하려면 추가 를 클릭하고 IP 주소를 입력합니다. 새 전달 정책을 정의하려면 사용 가능한 정책 목록에서 선택합니다.

    그림 33.28. 웹 UI에서 글로벌 DNS 구성 편집

    웹 UI에서 글로벌 DNS 구성 편집
  3. 저장 을 클릭하여 새 구성을 확인합니다.

명령줄에서 전달자 구성

명령줄에서 전달자 전체 목록을 설정하려면 ipa dnsconfig-mod 명령을 사용합니다. LDAP 데이터를 편집하여 DNS 전역 구성을 편집합니다. ipa dnsconfig-mod 명령과 해당 옵션은 모든 IdM DNS 서버에 즉시 영향을 미치고 로컬 구성을 재정의합니다.
예를 들어 ipa dnsconfig-mod 를 사용하여 글로벌 전달자 목록을 편집하려면 다음을 수행합니다.
[user@server ~]$ ipa dnsconfig-mod --forwarder=192.0.2.254
  Global forwarders: 192.0.2.254

33.6.2. 전달 영역 구성

전달 영역에는 신뢰할 수 있는 데이터가 포함되어 있지 않으며 이름 서버에서 특정 영역에 속하는 이름에 대한 쿼리만 구성된 전달자에게 전달하도록 지시합니다.
중요
꼭 필요한 경우가 아니면 전달 영역을 사용하지 마십시오. 를 사용하여 전역 전달 구성을 재정의합니다. 대부분의 경우 33.6.1절. “글로벌 전달자 구성” 에 설명된 글로벌 전달 만 구성하는 것만으로는 충분하지만 전달 영역은 필요하지 않습니다.
전달 영역은 비표준 솔루션이며 이를 사용하면 예기치 않고 문제가 발생할 수 있습니다. 새 DNS 영역을 만들 때 Red Hat은 항상 NS 레코드를 사용하여 표준 DNS 위임을 사용하고 전달 영역을 방지하는 것이 좋습니다.
지원되는 전달 정책에 대한 자세한 내용은 “전달 정책” 을 참조하십시오.
BIND 서비스에 대한 자세한 내용은 Red Hat Enterprise Linux Networking Guide, /usr/share/doc/bind-version_number/ directory 또는 외부 소스에 포함된 BIND 9 관리자 참조 매뉴얼을 참조하십시오. [5] .

웹 UI에서 전달 영역 구성

웹 UI에서 전달 영역을 관리하려면 Network Services 탭을 클릭하고 DNS Forward Zones 섹션을 선택합니다.

그림 33.29. DNS 전달 영역 관리

DNS 전달 영역 관리
DNS Forward Zones 섹션에서 관리자는 전달 영역에 대한 모든 필수 작업 처리: 현재 전달 영역 목록을 표시하고, 새 전달 영역을 추가하고, 전달 영역을 삭제하고, 전달 영역을 표시하고, 전달 영역별로 전달자 및 전달 정책을 수정할 수 있으며, 전달 영역을 비활성화 또는 활성화할 수 있습니다.

명령줄에서 전달 영역 구성

명령줄에서 전달 영역을 관리하려면 아래에 설명된 ipa dnsforwardzone-* 명령을 사용합니다.
참고
ipa dnsforwardzone-* 명령은 마스터 영역을 관리하는 데 사용되는 ipa dnszone-* 명령과 일관되게 작동합니다.
ipa dnsforwardzone-* 명령은 여러 옵션(특히 --forwarder,--forward-policy, --name-from-ip ) 옵션을 허용합니다. 사용 가능한 옵션에 대한 자세한 내용은 표 33.1. “영역 속성” 을 참조하거나 --help 옵션이 추가된 명령을 실행합니다. 예를 들면 다음과 같습니다.
ipa dnsforwardzone-add --help
전달 영역 추가
dnsforwardzone-add 명령을 사용하여 새 전달 영역을 추가합니다. 전달 정책이 none 으로 설정되지 않은 경우 하나 이상의 전달자를 지정해야 합니다.
[user@server ~]$ ipa dnsforwardzone-add zone.test. --forwarder=172.16.0.1 --forwarder=172.16.0.2 --forward-policy=first

Zone name: zone.test.
Zone forwarders: 172.16.0.1, 172.16.0.2
Forward policy: first
전달 영역 수정
dnsforwardzone-mod 명령을 사용하여 전달 영역을 수정합니다. 전달 정책이 none 이 아닌 경우 하나 이상의 전달자를 지정해야 합니다. 몇 가지 방법으로 수정할 수 있습니다.
[user@server ~]$ ipa dnsforwardzone-mod zone.test. --forwarder=172.16.0.3

Zone name: zone.test.
Zone forwarders: 172.16.0.3
Forward policy: first
[user@server ~]$ ipa dnsforwardzone-mod zone.test. --forward-policy=only

Zone name: zone.test.
Zone forwarders: 172.16.0.3
Forward policy: only
전달 영역 표시
dnsforwardzone-show 명령을 사용하여 지정된 전달 영역에 대한 정보를 표시합니다.
[user@server ~]$ ipa dnsforwardzone-show zone.test.

Zone name: zone.test.
Zone forwarders: 172.16.0.5
Forward policy: first
앞으로 영역 찾기
dnsforwardzone-find 명령을 사용하여 지정된 전달 영역을 찾습니다.
[user@server ~]$ ipa dnsforwardzone-find zone.test.

Zone name: zone.test.
Zone forwarders: 172.16.0.3
Forward policy: first
----------------------------
Number of entries returned 1
----------------------------
앞으로 영역 삭제
dnsforwardzone-del 명령을 사용하여 지정된 전달 영역을 삭제합니다.
[user@server ~]$ ipa dnsforwardzone-del zone.test.

----------------------------
Deleted forward DNS zone "zone.test."
----------------------------
앞으로 영역 활성화 및 비활성화
dnsforwardzone-enablednsforwardzone-disable 명령을 사용하여 전달 영역을 활성화 및 비활성화합니다. 전달 영역은 기본적으로 활성화되어 있습니다.
[user@server ~]$ ipa dnsforwardzone-enable zone.test.

----------------------------
Enabled forward DNS zone "zone.test."
----------------------------
[user@server ~]$ ipa dnsforwardzone-disable zone.test.

----------------------------
Disabled forward DNS zone "zone.test."
----------------------------
권한 추가 및 제거
dnsforwardzone-add-permissiondnsforwardzone-remove-permission 명령을 사용하여 시스템 권한을 추가하거나 제거합니다.
[user@server ~]$ ipa dnsforwardzone-add-permission zone.test.

---------------------------------------------------------
Added system permission "Manage DNS zone zone.test."
---------------------------------------------------------
  Manage DNS zone zone.test.
[user@server ~]$ ipa dnsforwardzone-remove-permission zone.test.

---------------------------------------------------------
Removed system permission "Manage DNS zone zone.test."
---------------------------------------------------------
  Manage DNS zone zone.test.


[5] 자세한 내용은 BIND 9 구성 참조를 참조하십시오.

33.7. 역방향 DNS 영역 관리

역방향 DNS 영역은 다음 두 가지 방법으로 식별할 수 있습니다.
  • 영역 이름으로 reverse_ipv4_address.in-addr.arpa 또는 reverse_ipv6_address.ip6.arpa 형식으로 되어 있습니다.
    역방향 IP 주소는 IP 주소의 구성 요소 순서를 취소하여 생성됩니다. 예를 들어 IPv4 네트워크가 192.0.2.0/24 인 경우 역방향 영역 이름은 2.0.192.in-addr.arpa 입니다(후행 기간 포함).
  • 네트워크 주소별 network_ip_address/subnet_mask_bit_count형식
    IP 네트워크를 통해 역방향 영역을 만들려면 네트워크 정보를 (forward-style) IP 주소로 설정하고 서브넷 마스크 비트 수를 사용합니다. 비트 수는 IPv4 주소에 대한 8의 배수이거나 IPv6 주소의 경우 4개 중 배수여야 합니다.

웹 UI에서 역방향 DNS 영역 추가

  1. Network Services 탭을 열고 DNS Zones 섹션 다음에 DNS를 선택합니다.

    그림 33.30. DNS 영역 관리

    DNS 영역 관리
  2. 모든 영역 목록 맨 위에서 추가 를 클릭합니다.

    그림 33.31. 역방향 DNS 영역 추가

    역방향 DNS 영역 추가
  3. 영역 이름 또는 역방향 영역 IP 네트워크를 입력합니다.
    1. 예를 들어 영역 이름을 사용하여 역방향 DNS 영역을 추가하려면 다음을 수행합니다.

      그림 33.32. 이름으로 역방향 영역 생성

      이름으로 역방향 영역 생성
    2. 또는 역방향 영역 IP 네트워크를 통해 역방향 DNS 영역을 추가하려면 다음을 수행합니다.

      그림 33.33. IP 네트워크를 통한 역방향 영역 생성

      IP 네트워크를 통한 역방향 영역 생성
      Reverse zone IP network( Reverse zone IP network ) 필드의 유효성 검사기에서 입력 시 잘못된 네트워크 주소에 대해 경고합니다. 전체 네트워크 주소를 입력하면 경고가 사라집니다.
  4. Add 를 클릭하여 새 역방향 영역을 확인합니다.

명령줄에서 역방향 DNS 영역 추가

명령줄에서 역방향 DNS 영역을 생성하려면 ipa dnszone-add 명령을 사용합니다.
예를 들어 영역 이름으로 역방향 영역을 생성하려면 다음을 수행합니다.
[user@server]$ ipa dnszone-add 2.0.192.in-addr.arpa.
또는 IP 네트워크에서 역방향 영역을 생성하려면 다음을 수행합니다.
[user@server ~]$ ipa dnszone-add --name-from-ip=192.0.2.0/24

역방향 DNS 영역에 대한 기타 관리 작업

33.4절. “마스터 DNS 영역 관리” DNS 영역의 편집 또는 비활성화 및 활성화와 같은 역방향 DNS 영역 관리에도 적용 가능한 다른 영역 관리 작업을 설명합니다.

33.8. DNS 쿼리 정책 정의

DNS 도메인 내에서 호스트 이름을 확인하기 위해 DNS 클라이언트는 DNS 이름 서버에 대한 쿼리를 실행합니다. 일부 보안 컨텍스트 또는 성능을 위해 영역의 DNS 레코드를 쿼리할 수 있는 클라이언트를 제한하는 것이 좋습니다.
영역이 생성될 때 또는 ipa dnszone-mod 명령과 함께 --allow-query 옵션을 사용하여 쿼리를 실행할 수 있는 클라이언트 목록을 설정하여 DNS 쿼리를 구성할 수 있습니다.
예를 들어 다음과 같습니다.
[user@server ~]$ ipa dnszone-mod --allow-query=192.0.2.0/24;2001:DB8::/32;203.0.113.1 example.com
기본 --allow-query 값은 임의 의 클라이언트가 영역을 쿼리할 수 있는 any입니다.

33.9. DNS 위치

33.9.1. DNS 기반 서비스 검색

DNS 기반 서비스 검색은 클라이언트가 DNS 프로토콜을 사용하여 LDAP 또는 Kerberos 와 같은 특정 서비스를 제공하는 네트워크에서 서버를 찾는 프로세스입니다. 일반적인 작업 유형 중 하나는 클라이언트가 처리량이 높고 네트워크 대기 시간을 줄여 전체 비용을 절감하므로 클라이언트가 가장 가까운 네트워크 인프라 내에서 인증 서버를 찾을 수 있도록 하는 것입니다.
서비스 검색의 주요 장점은 다음과 같습니다.
  • 클라이언트가 가까운 서버의 이름으로 명시적으로 구성할 필요가 없습니다.
  • DNS 서버는 정책의 중앙 공급자로 사용됩니다. 동일한 DNS 서버를 사용하는 클라이언트는 서비스 프로바이더 및 기본 주문에 대해 동일한 정책에 액세스할 수 있습니다.
IdM 도메인에는 LDAP, Kerberos 및 기타 서비스에 대해 SRV 레코드(DNS 서비스 레코드)가 있습니다. 예를 들어 다음 명령은 IdM DNS 도메인에 TCP 기반 Kerberos 서비스를 제공하는 호스트의 DNS 서버를 쿼리합니다.

예 33.10. DNS 위치 독립 결과

$ dig -t SRV +short _kerberos._tcp.idm.example.com
0 100 88 idmserver-01.idm.example.com.
0 100 88 idmserver-02.idm.example.com.
출력에는 다음 정보가 포함됩니다.
  • 0 (우선 순위): 대상 호스트의 우선 순위. 더 낮은 값이 선호됩니다.
  • 100 (중요). 동일한 우선 순위인 항목의 상대 가중치를 지정합니다. 자세한 내용은 RFC 2782, 섹션 3을 참조하십시오.
  • 88 (포트 번호): 서비스의 포트 번호입니다.
  • 서비스를 제공하는 호스트의 표준 이름입니다.
이전 예에서 반환된 두 호스트 이름은 동일한 우선 순위 및 가중치를 갖습니다. 이 경우 클라이언트는 결과 목록의 임의 항목을 사용합니다.
클라이언트가 DNS 위치에 구성된 DNS 서버를 쿼리하면 출력이 달라집니다. 위치에 할당된 IdM 서버의 경우 맞춤형 값이 반환됩니다. 아래 예제에서 클라이언트는 위치 germany 의 DNS 서버를 쿼리합니다.

예 33.11. DNS 위치 기반 결과

$ dig -t SRV +short _kerberos._tcp.idm.example.com
_kerberos._tcp.germany._locations.idm.example.com.
0 100 88 idmserver-01.idm.example.com.
50 100 88 idmserver-02.idm.example.com.
IdM DNS 서버는 로컬 서버를 선호하는 DNS 위치별 SRV 레코드를 가리키는 DNS 별칭(CNAME)을 자동으로 반환합니다. 이 CNAME 레코드는 출력의 첫 번째 줄에 표시됩니다. 이전 예에서 호스트 idmserver-01.idm.example.com 은 우선순위 값이 가장 낮으므로 선호됩니다. idmserver-02.idm.example.com 은 우선 순위가 높으며 기본 호스트를 사용할 수 없는 경우 백업으로만 사용됩니다.

33.9.2. DNS 위치에 대한 배포 고려 사항

기본 IdM DNS 도메인에 대한 권한이 있는 IdM DNS 서버의 경우 IdM에서 위치별 SRV 레코드를 생성할 수 있습니다. 각 IdM DNS 서버는 위치별 SRV 레코드를 생성하므로 각 DNS 위치에 하나 이상의 IdM DNS 서버를 설치해야 합니다.
DNS 위치에 대한 클라이언트의 선호도는 클라이언트에서 받은 DNS 레코드에서만 정의됩니다. 따라서 클라이언트가 IdM DNS 서버의 위치별 레코드를 확인하는 경우 IdM DNS 서버를 비IdM DNS 슬레이브 서버와 결합하고, DNS 서비스 검색에서 위치별 레코드를 확인하는 경우 반복을 수행할 수 있습니다.
혼합 IdM 및 비IdM DNS 서비스가 있는 대부분의 배포에서 DNS recursors는 왕복 시간 지표를 사용하여 가장 가까운 IdM DNS 서버를 자동으로 선택합니다. 일반적으로 비IdM DNS 서버를 사용하는 클라이언트에 가장 가까운 DNS 위치에 대한 레코드가 수신되므로 IdM 서버 세트를 최적으로 사용합니다.

33.9.2.1. DNS TTL(Time To Live)

클라이언트는 영역의 구성에 설정된 기간 동안 DNS 리소스 레코드를 캐시할 수 있습니다. 이 캐싱으로 인해 TTL(Time to live) 값이 만료될 때까지 클라이언트에서 변경 사항을 받지 못할 수 있습니다. IdM의 기본 TTL 값은 1일입니다.
클라이언트가 사이트 간에 로밍하는 경우 IdM DNS 영역의 TTL 값을 조정해야 합니다. 해당 값을 클라이언트가 사이트 간에 로밍해야 하는 시간보다 낮은 값으로 설정합니다. 이렇게 하면 클라이언트에서 캐시된 DNS 항목이 다른 사이트에 다시 연결하기 전에 만료되므로 DNS 서버를 쿼리하여 위치별 SRV 레코드를 새로 고칩니다.
DNS 영역의 기본 TTL을 수정하는 방법에 대한 자세한 내용은 33.4.2절. “마스터 DNS 영역에 대한 추가 구성 추가” 을 참조하십시오.

33.9.3. DNS 위치 생성

웹 UI에서 DNS 위치 생성

  1. IPA 서버 탭을 열고 토폴로지 를 선택합니다.
  2. 탐색 모음 에서 IPA 위치를 클릭합니다.
  3. 위치 목록 위쪽에서 추가 를 클릭합니다.
  4. 위치 이름을 입력합니다.
  5. Add 버튼을 클릭하여 위치를 저장합니다.
추가할 추가 위치에 대해 단계를 반복합니다.

명령줄에서 DNS 위치 생성

예를 들어 새 위치 germany 를 생성하려면 다음을 입력합니다.
[root@server ~]# ipa location-add germany
----------------------------
Added IPA location "germany"
----------------------------
  Location name: germany
추가할 모든 위치에 대해 단계를 반복합니다.

33.9.4. DNS 위치에 IdM 서버 할당

웹 UI에서 DNS 위치에 IdM 서버 할당

  1. IPA 서버 탭을 열고 토폴로지 를 선택합니다.
  2. 탐색에서 IPA 서버를 클릭합니다.
  3. IdM 서버 이름을 클릭합니다.
  4. DNS 위치를 선택하고 선택적으로 서비스 가중치를 설정합니다.

    그림 33.34. 서버를 DNS 위치에 할당

    서버를 DNS 위치에 할당
  5. 저장을 클릭합니다.
  6. 이전 단계에서 지정한 호스트에서 named-pkcs11 서비스를 다시 시작합니다.
    [root@idmserver-01 ~]# systemctl restart named-pkcs11
DNS 위치를 할당하려는 추가 IdM 서버에 대한 단계를 반복합니다.

명령줄에서 DNS 위치에 IdM 서버 할당

  1. 선택 사항: 구성된 모든 DNS 위치를 나열합니다.
    [root@server ~]# ipa location-find
    -----------------------
    2 IPA locations matched
    -----------------------
    Location name: australia
    Location name: germany
    -----------------------------
    Number of entries returned: 2
    -----------------------------
  2. 서버를 DNS 위치에 할당합니다. 예를 들어 위치 germanyidmserver-01.idm.example.com 서버에 할당하려면 다음을 실행합니다.
    [root@server ~]# ipa server-mod idmserver-01.idm.example.com --location=germany
    ipa: WARNING: Service named-pkcs11.service requires restart on IPA server
    idmserver-01.idm.example.com to apply configuration changes.
    --------------------------------------------------
    Modified IPA server "idmserver-01.idm.example.com"
    --------------------------------------------------
    Servername: idmserver-01.idm.example.com
    Min domain level: 0
    Max domain level: 1
    Location: germany
    Enabled server roles: DNS server, NTP server
  3. 이전 단계에서 지정한 호스트에서 named-pkcs11 서비스를 다시 시작합니다.
    [root@idmserver-01 ~]# systemctl restart named-pkcs11
DNS 위치를 할당하려는 추가 IdM 서버에 대한 단계를 반복합니다.

33.9.5. 동일한 위치에서 IdM 서버를 사용하도록 클라이언트 구성

IdM 서버는 33.9.4절. “DNS 위치에 IdM 서버 할당” 에 설명된 대로 DNS 위치에 할당됩니다. 이제 IdM 서버와 동일한 위치에 있는 DNS 서버를 사용하도록 클라이언트를 구성할 수 있습니다.
  • DHCP 서버에서 DNS 서버 IP 주소를 클라이언트에 할당하는 경우 DHCP 서비스를 구성합니다. DHCP 서비스에서 DNS 서버를 할당하는 방법에 대한 자세한 내용은 DHCP 서비스 설명서를 참조하십시오.
  • 클라이언트에서 DHCP 서버에서 DNS 서버 IP 주소를 수신하지 못하면 클라이언트의 네트워크 구성에서 IP를 수동으로 설정합니다. Red Hat Enterprise Linux에서 네트워크 구성에 대한 자세한 내용은 Red Hat Enterprise Linux 네트워킹 가이드의 네트워크 연결 설정 구성 섹션을 참조하십시오.
참고
다른 위치에 할당된 DNS 서버를 사용하도록 클라이언트를 구성하면 클라이언트는 두 위치에 있는 IdM 서버에 연결합니다.

예 33.12. 클라이언트의 위치에 따라 다른 이름 서버 항목

다음 예제는 다른 위치의 클라이언트에 대해 /etc/resolv.conf 파일의 다른 이름 서버 항목을 보여줍니다.
프라하의 고객:
nameserver 10.10.0.1
nameserver 10.10.0.2
구매자의 고객:
nameserver 10.50.0.1
nameserver 10.50.0.3
Oslo의 클라이언트:
nameserver 10.30.0.1
콜롬비아의 고객:
nameserver 10.30.0.1
각 DNS 서버가 IdM의 위치에 할당되면 클라이언트는 해당 위치에서 IdM 서버를 사용합니다.

33.10. 외부 DNS를 사용할 때 DNS 레코드를 체계적으로 업데이트

외부 DNS를 사용하는 경우 토폴로지 변경 후 Identity Management에서 DNS 레코드를 자동으로 업데이트하지 않습니다. 다음 절차에서는 외부 DNS 서비스에서 관리하는 DNS 레코드를 체계적으로 업데이트하는 방법을 설명하므로 수동 DNS 업데이트의 필요성이 줄어듭니다.
기본 개요는 33.10.1절. “ID 관리에서 외부 DNS 업데이트” 의 내용을 참조하십시오.
절차 및 예제는 다음을 참조하십시오.

33.10.1. ID 관리에서 외부 DNS 업데이트

DNS 레코드를 업데이트하면 이전 또는 유효하지 않은 DNS 레코드가 제거되고 새 레코드가 추가됩니다.
토폴로지를 변경한 후 DNS 레코드를 업데이트해야 합니다. 예를 들면 다음과 같습니다.
  • 복제를 설치하거나 설치 제거한 후
  • ID 관리 서버에 CA, DNS, KRA 또는 Active Directory 신뢰를 설치한 후

33.10.2. GUI: 외부 DNS 레코드 업데이트

  1. 업데이트해야 하는 레코드를 표시합니다. ipa dns-update-system- recordss --dry-run 명령을 사용합니다.
    $ ipa dns-update-system-records --dry-run
     IPA DNS records:
       _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 ipa.example.com.
       _kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 ipa.example.com.
    [... output truncated ...]
  2. 외부 DNS GUI를 사용하여 레코드를 업데이트합니다.

33.10.3. 명령줄: nsupdate를 사용하여 외부 DNS 레코드 업데이트

이 섹션에서는 nsupdate 유틸리티를 사용하여 외부 DNS 레코드를 수동으로 업데이트하는 방법을 설명합니다. 스크립트에서 이 섹션의 명령을 사용하여 프로세스를 자동화할 수도 있습니다.

nsupdate의 DNS 레코드로 파일 생성

  1. ipa dns-update-system- recordss --dry-run 명령을 --out 옵션과 함께 사용합니다. 옵션은 생성할 파일의 경로를 지정합니다.
    $ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate
     IPA DNS records:
       _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 ipa.example.com.
       _kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 ipa.example.com.
    [... output truncated ...]
    생성된 파일에는 nsupdate 유틸리티에서 수락한 형식의 필수 DNS 레코드가 포함되어 있습니다.
  2. 생성된 레코드는 다음과 같습니다.
    • 레코드를 업데이트할 영역의 자동 감지
    • 영역의 권한 있는 서버 자동 감지
    atypical DNS 설정을 사용 중이거나 영역 위임이 누락된 경우 nsupdate 에서 올바른 영역과 서버를 찾지 못할 수 있습니다. 이 경우 생성된 파일의 시작 부분에 다음 옵션을 추가합니다.
    • servernsupdate 가 레코드를 전송하는 권한 있는 DNS 서버의 서버 이름 또는 포트를 지정합니다.
    • zonensupdate 가 레코드를 배치하는 영역의 영역 이름을 지정합니다.
    예:
    $ cat dns_records_file.nsupdate
    zone example.com.
    server 192.0.2.1
    ; IPA DNS records
    update delete _kerberos-master._tcp.example.com. SRV
    update add _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 ipa.example.com.
    [... output truncated ...]

이름 서버에 동적 DNS 업데이트 요청 제출

nsupdate 를 사용하여 요청을 보낼 때 보안을 적절하게 확인하십시오. 이러한 메커니즘을 사용하여 요청을 보호할 수 있습니다.
트랜잭션 서명(TSIG) 프로토콜
TSIG를 사용하면 공유 키와 함께 nsupdate 를 사용할 수 있습니다. 절차 33.1. “TSIG를 사용하여 보안 된 nsupdate 요청 전송” 참조하십시오.
TSIG(GSS-TSIG)에 대한 GSS 알고리즘
GSS-TSIG는 GSS-API 인터페이스를 사용하여 비밀 TSIG 키를 가져옵니다. GSS-TSIG는 TSIG 프로토콜의 확장입니다. 보기 절차 33.2. “GSS-TSIG를 사용하여 보안된 nsupdate 요청 전송”

절차 33.1. TSIG를 사용하여 보안 된 nsupdate 요청 전송

  1. 다음 사전 요구 사항을 충족해야 합니다.
    • DNS 서버는 TSIG용으로 구성해야 합니다. 다음 서버 설정 예제를 참조하십시오. BIND, PowerDNS
    • DNS 서버와 클라이언트에는 모두 공유 키가 있어야 합니다.
  2. nsupdate 를 실행하고 다음 옵션 중 하나를 사용하여 공유 시크릿을 제공합니다.
    • -K: TSIG 인증 키를 제공:
      $ nsupdate -k tsig_key.file dns_records_file.nsupdate
    • -Y: 키 이름 및 Base64로 인코딩된 공유 보안에서 서명을 생성합니다.
      $ nsupdate -y algorithm:keyname:secret dns_records_file.nsupdate

절차 33.2. GSS-TSIG를 사용하여 보안된 nsupdate 요청 전송

  1. 다음 사전 요구 사항을 충족해야 합니다.
    • GSS-TSIG에 맞게 DNS 서버를 구성해야 합니다. 다음 서버 설정 예제를 참조하십시오. BIND, PowerDNS, Windows DNS.
    참고
    이 절차에서는 Kerberos V5 프로토콜이 GSS-API의 기술로 사용된다고 가정합니다.
  2. DNS 업데이트 요청을 제출하려면 레코드를 업데이트할 수 있는 보안 주체로 인증하고 -g 옵션으로 nsupdate 를 실행하여 GSS-TSIG 모드를 활성화합니다.
    $ kinit principal_allowed_to_update_records@REALM
    $ nsupdate -g dns_records_file.nsupdate

추가 리소스

  • nsupdate(8) 매뉴얼 페이지
  • RFC 2845 는 TSIG 프로토콜을 설명합니다.
  • RFC 3645 는 GSS-TSIG 알고리즘에 대해 설명합니다.

33.11. 기존 서버에 DNS 서비스 설치

DNS 서비스를 원래 설치되지 않고 설치한 IdM 서버에 설치할 수 있습니다. 이 작업을 수행하려면 ipa-server-dns 패키지가 설치되어 있는지 확인한 다음 ipa-dns-install 유틸리티를 사용합니다.
ipa-dns-install 을 사용하여 DNS 서비스를 구성하는 방법은 2.3.3절. “통합 DNS로 서버 설치” 에 설명된 대로 ipa-server-install 유틸리티를 사용하여 DNS를 설치하는 것과 동일한 원칙을 따릅니다.
ipa-dns-install 에 대한 자세한 내용은 ipa-dns-install(1) 매뉴얼 페이지를 참조하십시오.

33.11.1. 추가 이름 서버 설정

33.11.1.1. 추가 이름 서버 설정

IdM은 새로 구성된 IdM DNS 서버를 /etc/resolv.conf 파일의 DNS 서버 목록에 추가합니다. IdM 서버를 사용할 수 없는 경우 수동으로 다른 DNS 서버를 백업 서버로 추가하는 것이 좋습니다. 예를 들어 다음과 같습니다.
search example.com

; the IdM server
nameserver 192.0.2.1

; backup DNS servers
nameserver 198.51.100.1
nameserver 198.51.100.2
/etc/resolv.conf 구성에 대한 자세한 내용은 resolv.conf(5) 매뉴얼 페이지를 참조하십시오.


[3] GSS-TSIG에 대한 자세한 내용은 RFC 3545 를 참조하십시오.

34장. 자동 마운트 사용

자동 마운트는 여러 시스템에서 디렉토리를 관리, 구성 및 액세스하는 방법입니다. 자동 마운트는 액세스 권한이 요청될 때마다 디렉토리를 자동으로 마운트합니다. IdM 도메인 내에서는 도메인 내의 클라이언트의 디렉터리를 쉽게 공유할 수 있으므로 매우 잘 작동합니다. 사용자 홈 디렉터리에서는 특히 중요합니다. 11.1절. “사용자 홈 디렉터리 설정” 을 참조하십시오.
IdM에서 자동 마운트는 내부 LDAP 디렉토리와 구성된 경우 DNS 서비스와 함께 작동합니다.

34.1. 자동 마운트 및 IdM 정보

자동 마운트는 디렉토리가 구성되는 방식과 일관된 구조를 제공합니다. 모든 디렉토리를 마운트 지점 또는 라고 합니다. 함께 그룹화되는 여러 개의 키는 을 만들고, 맵은 실제 또는 개념적 위치에 따라 연결됩니다.
ation을 위한 기본 설정 파일은 /etc 디렉토리의 auto.master 파일입니다. 필요한 경우 별도의 서버 위치에 auto.master 구성 파일이 여러 개 있을 수 있습니다.
CloudEvent 유틸리티 가 서버에 구성되어 있고 서버가 IdM 도메인의 클라이언트인 경우, 자동 마운트에 대한 모든 구성 정보가 IdM 디렉터리에 저장됩니다. 별도의 텍스트 파일이 아닌 맵, 위치 및 키를 포함하는 CloudEvent 구성은 LDAP 항목으로 저장됩니다. 예를 들어 기본 맵 파일인 auto.master 는 다음과 같이 저장됩니다.
dn: automountmapname=auto.master,cn=default,cn=automount,dc=example,dc=com
objectClass: automountMap
objectClass: top
automountMapName: auto.master
중요
ID 관리는 기존 CloudEvent 배포 함께 작동하지만 CloudEvent 자체를 설정하거나 구성하지 않습니다.
각 새 위치는 cn=automount,dc=example,dc=com 에서 컨테이너 항목으로 추가되며 각 맵과 각 키는 해당 위치 아래에 저장됩니다.
다른 IdM 도메인 서비스와 마찬가지로 자동 마운트는 IdM과 기본적으로 작동합니다. 자동 조정 구성은 IdM 툴에서 관리할 수 있습니다.
  • 위치에 대한 ipa autoscalelocation* 명령
  • 직접 및 간접 맵에 대한 ipa autoscalemap* 명령
  • 키에 대한 ipa autoscalekey* 명령 .
IdM 도메인 내에서 작업하려면 NFS 서버를 IdM 클라이언트로 구성해야 합니다. NFS 구성 자체는 Red Hat Enterprise Linux 스토리지 관리 가이드에서 다룹니다.

34.2. 자동 마운트 구성

Identity Management에서 위치 및 맵과 같은 gRPC 항목을 구성하려면 기존 CloudEvent/NFS 서버가 필요합니다. 자동 마운트 항목을 생성해도 기본 CloudEvent 구성이 생성되지 않습니다. LDAP 또는 SSSD를 데이터 저장소로 사용하여 수동으로 구성하거나 자동으로 구성할 수 있습니다.
참고
중단 구성을 변경하기 전에 한 명 이상의 사용자에 대해 명령줄에서 /home 디렉토리를 성공적으로 마운트할 수 있는지 테스트합니다. NFS가 올바르게 작동하는지 확인하면 나중에 잠재적인 IdM의 설정 오류 문제를 보다 쉽게 해결할 수 있습니다.

34.2.1. 자동으로 NFS 설정

시스템이 구성의 일부로 도메인 클라이언트로 구성된 IdM 서버 및 복제본을 포함하는 IdM 클라이언트로 구성된 IdM 클라이언트로 구성된 후 IdM 도메인을 NFS 도메인으로 사용하고 CloudEvent 서비스가 활성화되도록 구성할 수 있습니다.
기본적으로 ipa-client-automount 유틸리티는 NFS 구성 파일 /etc/sysconfig/nfs/etc/idmapd.conf 를 자동으로 구성합니다. 또한 NFS의 자격 증명을 관리하도록 SSSD를 구성합니다. ipa-client-automount 명령을 옵션 없이 실행하는 경우 DNS 검색 검사를 실행하여 사용 가능한 IdM 서버를 확인하고 default 라는 기본 위치를 생성합니다.
[root@ipa-server ~]# ipa-client-automount
Searching for IPA server...
IPA server: DNS discovery
Location: default
Continue to configure the system with these values? [no]: yes
Configured /etc/nsswitch.conf
Configured /etc/sysconfig/nfs
Configured /etc/idmapd.conf
Started rpcidmapd
Started rpcgssd
Restarting sssd, waiting for it to become available.
Started autofs
사용할 IdM 서버를 지정하고 default 이외의 mount location을 생성할 수 있습니다.
[root@server ~]# ipa-client-automount --server=ipaserver.example.com --location=boston
NFS 설정과 함께 ipa-client-automount 유틸리티는 외부 IdM 저장소에 액세스할 수 없는 경우 자동 마운트 맵을 캐시하도록 SSSD를 구성합니다. SSSD는 다음 두 가지 작업을 수행합니다.
  • SSSD 구성에 서비스 구성 정보를 추가합니다. IdM 도메인 항목에는 CloudEvent 공급자 및 마운트 위치에 대한 설정이 제공됩니다.
    autofs_provider = ipa
    ipa_automount_location = default
    또한 NFS는 지원되는 서비스(서비스 = nss,pam,autofs...) 목록에 추가되고 빈 구성 항목([autofs])이 제공됩니다.
  • NSS(Name Service Switch) 서비스 정보가 업데이트되어 자동 마운트 정보가 필요한 경우 먼저 SSSD에서 자동 마운트 정보를 확인한 다음 로컬 파일을 확인합니다.
    automount: sss files
클라이언트가 자동 마운트 맵을 캐시하는 데 적합하지 않은 보안 환경과 같은 일부 인스턴스가 있을 수 있습니다. 이 경우 ipa-client-automount 명령은 --no-sssd 옵션을 사용하여 실행할 수 있습니다. 이 옵션을 사용하면 필수 NFS 구성 파일이 모두 변경되지만 SSSD 구성은 변경되지 않습니다.
[root@server ~]# ipa-client-automount --no-sssd
--no-sssd 를 사용하는 경우 ipa-client-automount 에 의해 업데이트된 구성 파일 목록이 다릅니다.
  • 이 명령은 /etc/sysconfig/nfs 대신 /etc/sysconfig/autofs 를 업데이트합니다.
  • 이 명령은 IdM LDAP 구성을 사용하여 /etc/autofs_ldap_auth.conf 를 구성합니다.
  • 명령은 LDAP 서비스를 mount 맵에 사용하도록 /etc/nsswitch.conf 를 구성합니다.
참고
ipa-client-automount 명령은 한 번만 실행할 수 있습니다. 구성에 오류가 있는 경우 구성 파일을 수동으로 편집해야 하는 것보다 오류가 있습니다.

34.2.2. SSSD 및 ID 관리를 사용하도록 수동으로 구성

  1. /etc/sysconfig/autofs 파일을 편집하여 CloudEvent가 검색하는 스키마 속성을 지정합니다.
    #
    # Other common LDAP naming
    #
    MAP_OBJECT_CLASS="automountMap"
    ENTRY_OBJECT_CLASS="automount"
    MAP_ATTRIBUTE="automountMapName"
    ENTRY_ATTRIBUTE="automountKey"
    VALUE_ATTRIBUTE="automountInformation"
    
  2. LDAP 구성을 지정합니다. 이 작업을 수행하는 방법에는 두 가지가 있습니다. 가장 간단한 방법은 자동 마운트 서비스에서 LDAP 서버 및 위치를 자체적으로 검색하도록 하는 것입니다.
    LDAP_URI="ldap:///dc=example,dc=com"
    또는 사용할 LDAP 서버와 LDAP 검색을 위한 기본 DN을 명시적으로 설정합니다.
    LDAP_URI="ldap://ipa.example.com"
    SEARCH_BASE="cn=location,cn=automount,dc=example,dc=com"
    참고
    location 의 기본값은 default 입니다. 추가 위치 추가(34.5절. “위치 구성”), 대신 해당 위치를 사용하도록 클라이언트를 가리킬 수 있습니다.
  3. /etc/autofs_ldap_auth.conf 파일을 편집하여 IdM LDAP 서버로 클라이언트 인증을 허용합니다.
    • authrequired 를 yes로 변경합니다.
    • 주체를 NFS 클라이언트 서버 host /fqdn@REALM의 Kerberos 호스트 주체로 설정합니다. 주체 이름은 GSS 클라이언트 인증의 일부로 IdM 디렉터리에 연결하는 데 사용됩니다.
    <autofs_ldap_sasl_conf
         usetls="no"
         tlsrequired="no"
         authrequired="yes"
         authtype="GSSAPI"
         clientprinc="host/server.example.com@EXAMPLE.COM"
         />
    필요한 경우 klist -k 를 실행하여 정확한 호스트 주체 정보를 가져옵니다.
  4. autofs를 SSSD에서 관리하는 서비스 중 하나로 구성합니다.
    1. SSSD 구성 파일을 엽니다.
      [root@server ~]# vim /etc/sssd/sssd.conf
    2. SSSD에서 처리하는 서비스 목록에 autofs 서비스를 추가합니다.
      [sssd]
      services = nss,pam,autofs
    3. [autofs] 섹션을 만듭니다. 이 값은 비워 둘 수 있습니다. autofs 서비스의 기본 설정은 대부분의 인프라에서 작동합니다.
      [nss]
      
      [pam]
      
      [sudo]
      
      [autofs]
      
      [ssh]
      
      [pac]
    4. 필요한 경우 autofs 항목에 대한 검색 기준을 설정합니다. 기본적으로 LDAP 검색 기반이지만 하위 트리를 ldap_autofs_search_base 매개변수에 지정할 수 있습니다.
      [domain/EXAMPLE]
      ...
      ldap_search_base = "dc=example,dc=com"
      ldap_autofs_search_base = "ou=automount,dc=example,dc=com"
  5. SSSD를 다시 시작:
    [root@server ~]# systemctl restart sssd.service
  6. /etc/nsswitch.conf 파일을 확인하여 SSSD가 자동 마운트 구성의 소스로 나열되도록 합니다.
    automount: sss files
  7. autofs를 다시 시작하십시오.
    [root@server ~]# systemctl restart autofs.service
  8. 사용자의 /home 디렉토리를 나열하여 구성을 테스트합니다.
    [root@server ~]# ls /home/userName
    원격 파일 시스템을 마운트하지 않으면 /var/log/ECDHE 파일에서 오류가 있는지 확인합니다. 필요한 경우 LOGGING 매개변수를 debug로 설정하여 /etc/sysconfig/autofs 파일에서 debug 수준을 높입니다.
참고
ationation에 문제가 있는 경우, IdM 인스턴스에 대한 389 Directory Server 액세스 로그로 자동 마운트 시도한 후 시도된 액세스, 사용자 및 검색 기반이 표시됩니다.
에서 디버그 로깅을 사용하여 포그라운드에서 자동 마운트를 실행하는 것도 간단합니다.
automount -f -d
그러면 자동 마운트 로그를 사용하여 LDAP 액세스 로그를 교차 확인하지 않고도 디버그 로그 정보가 직접 출력됩니다.

34.2.3. Solaris에서 자동 마운트 구성

참고
솔라리스는 Identity Management에서 사용하는 스키마와 다른 schema를 사용함. ID 관리는 389 Directory Server에 대해 정의된 2307bis 스타일 자동 마운트 스키마를 사용합니다(VPC의 내부 디렉터리 서버 인스턴스에서 사용됨).
  1. NFS 서버가 Red Hat Enterprise Linux에서 실행 중인 경우 Solaris 시스템에서 NFSv3가 지원되는 최대 버전임을 지정합니다. /etc/default/nfs 파일을 편집하고 다음 매개변수를 설정합니다.
    NFS_CLIENT_VERSMAX=3
    
  2. ldapclient 명령을 사용하여 LDAP를 사용하도록 호스트를 구성합니다.
    ldapclient -v manual -a authenticationMethod=none
        -a defaultSearchBase=dc=example,dc=com
        -a defaultServerList=ipa.example.com
        -a serviceSearchDescriptor=passwd:cn=users,cn=accounts,dc=example,dc=com
        -a serviceSearchDescriptor=group:cn=groups,cn=compat,dc=example,dc=com
        -a serviceSearchDescriptor=auto_master:automountMapName=auto.master,cn=location,cn=automount,dc=example,dc=com?one
        -a serviceSearchDescriptor=auto_home:automountMapName=auto_home,cn=location,cn=automount,dc=example,dc=com?one
        -a objectClassMap=shadow:shadowAccount=posixAccount
        -a searchTimelimit=15
        -a bindTimeLimit=5
    
  3. mount를 활성화합니다.
    # svcadm enable svc:/system/filesystem/autofs
  4. 구성을 테스트합니다.
    1. LDAP 구성을 확인합니다.
      # ldapclient -l auto_master
      
      dn: automountkey=/home,automountmapname=auto.master,cn=location,cn=automount,dc=example,dc=com
      objectClass: automount
      objectClass: top
      automountKey: /home
      automountInformation: auto.home
      
    2. 사용자의 /home 디렉토리를 나열합니다.
      # ls /home/userName

34.3. Kerberos 인식 NFS 서버 설정

  1. NFS 클라이언트가 Red Hat Enterprise Linux 5 클라이언트와 같이 취약한 암호화만 지원하는 경우:
    1. 약한 des-cbc-crc 암호화 유형을 활성화하려면 IdM 서버 Kerberos 구성을 업데이트합니다.
      $ ldapmodify -x -D "cn=directory manager" -w password -h ipaserver.example.com -p 389
      
      dn: cn=REALM_NAME,cn=kerberos,dc=example,dc=com
      changetype: modify
      add: krbSupportedEncSaltTypes
      krbSupportedEncSaltTypes: des-cbc-crc:normal
      -
      add: krbSupportedEncSaltTypes
      krbSupportedEncSaltTypes: des-cbc-crc:special
      -
      add: krbDefaultEncSaltTypes
      krbDefaultEncSaltTypes: des-cbc-crc:special
    2. NFS 서버에서 NFS 서버의 /etc/krb5.conf 파일에 다음 항목을 추가하면 약한 암호화 지원이 가능합니다.
      allow_weak_crypto = true
  2. Kerberos 티켓을 받습니다.
    [root@nfs-server ~]# kinit admin
  3. NFS 호스트 시스템이 IdM 도메인에 클라이언트로 추가되지 않은 경우 호스트 항목을 생성합니다. 12.3절. “호스트 항목 추가” 참조하십시오.
  4. NFS 서비스 항목을 생성합니다.
    [root@nfs-server ~]# ipa service-add nfs/nfs-server.example.com
    자세한 내용은 16.1절. “서비스 항목 및 키 탭 추가 및 편집” 의 내용을 참조하십시오.
  5. /etc/krb5.keytab 파일에 키를 저장하는 다음 ipa-getkeytab 명령을 사용하여 NFS 서버의 NFS 서비스 키 탭을 검색합니다.
    [root@nfs-server ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/nfs-server.example.com -k /etc/krb5.keytab
    NFS 클라이언트가 취약한 암호화만 지원하는 경우 -e des-cbc-crc 옵션을 명령에 전달하여 DES-encrypted keytab을 요청합니다.
  6. 서비스 항목을 확인하여 keytab을 사용하여 NFS 서비스가 IdM에 올바르게 구성되었는지 확인합니다.
    [root@nfs-server ~]# ipa service-show nfs/nfs-server.example.com
      Principal name: nfs/nfs-server.example.com@IDM.EXAMPLE.COM
      Principal alias: nfs/nfs-server.example.com@IDM.EXAMPLE.COM
      Keytab: True
      Managed by: nfs-server.example.com
  7. nfs-utils 패키지를 설치합니다.
    [root@nfs-server ~]# yum install nfs-utils
  8. ipa-client-automount 유틸리티를 실행하여 NFS 설정을 구성합니다.
    [root@nfs-server ~] ipa-client-automount
    Searching for IPA server...
    IPA server: DNS discovery
    Location: default
    Continue to configure the system with these values? [no]: yes
    Configured /etc/sysconfig/nfs
    Configured /etc/idmapd.conf
    Started rpcidmapd
    Started rpcgssd
    Restarting sssd, waiting for it to become available.
    Started autofs
    기본적으로 이 명령은 보안 NFS를 활성화하고 /etc/idmapd.conf 파일의 Domain 매개변수를 IdM DNS 도메인으로 설정합니다. 다른 도메인을 사용하는 경우 --idmap-domain domain_name 매개변수를 사용하여 지정합니다.
  9. 시스템이 부팅될 때 nfs-idmapd 서비스가 자동으로 시작되도록 구성합니다.
    # systemctl enable nfs-idmapd
  10. /etc/exports 파일을 편집하고>-< 5p Kerberos 보안 설정을 사용하여 공유를 추가합니다.
    /export  *(rw,sec=krb5:krb5i:krb5p)
    /home  *(rw,sec=krb5:krb5i:krb5p)
    이 예에서는 /export/home 디렉터리를 읽기-쓰기 모드로 Kerberos 인증이 활성화된 것과 공유합니다.
  11. 공유 디렉터리를 다시 내보냅니다.
    [root@nfs-server ~]# exportfs -rav
  12. 선택적으로 NFS 서버를 NFS 클라이언트로 구성합니다. 34.4절. “Kerberos 인식 NFS 클라이언트 설정” 참조하십시오.

34.4. Kerberos 인식 NFS 클라이언트 설정

  1. NFS 클라이언트가 Red Hat Enterprise Linux 5 클라이언트와 같은 약한 암호화만 지원하는 경우 서버의 /etc/krb5.conf 파일에 다음 항목을 설정하여 약한 암호화를 허용합니다.
    allow_weak_crypto = true
  2. NFS 클라이언트가 IdM 도메인에 클라이언트로 등록되지 않은 경우 12.3절. “호스트 항목 추가” 에 설명된 대로 필요한 호스트 항목을 설정합니다.
  3. nfs-utils 패키지를 설치합니다.
    [root@nfs-client ~]# yum install nfs-utils
  4. IdM 툴을 실행하기 전에 Kerberos 티켓을 받으십시오.
    [root@nfs-client ~]# kinit admin
  5. ipa-client-automount 유틸리티를 실행하여 NFS 설정을 구성합니다.
    [root@nfs-client ~] ipa-client-automount
    Searching for IPA server...
    IPA server: DNS discovery
    Location: default
    Continue to configure the system with these values? [no]: yes
    Configured /etc/sysconfig/nfs
    Configured /etc/idmapd.conf
    Started rpcidmapd
    Started rpcgssd
    Restarting sssd, waiting for it to become available.
    Started autofs
    기본적으로 이를 통해 /etc/sysconfig/nfs 파일에서 보안 NFS를 활성화하고 /etc/idmapd.conf 파일의 Domain 매개변수에 IdM DNS 도메인을 설정합니다.
  6. 시스템이 부팅될 때 자동으로 시작하도록 서비스를 구성합니다.
    [root@nfs-client ~]# systemctl enable rpc-gssd.service
    [root@nfs-client ~]# systemctl enable rpcbind.service
  7. 시스템이 부팅될 때 nfs-server.example.com 호스트의 NFS 공유를 마운트하려면 /etc/fstab 파일에 다음 항목을 추가합니다.
    nfs-server.example.com:/export  /mnt          nfs4  sec=krb5p,rw
    nfs-server.example.com:/home    /home  nfs4  sec=krb5p,rw
    이러한 설정은 /export 공유를 /mnt 및 /home 공유에 /home 디렉토리에 마운트하도록 Red Hat Enterprise Linux를 구성합니다.
  8. 마운트 지점이 없는 경우 만듭니다.
    # mkdir -p /mnt/
    # mkdir -p /home
  9. NFS 공유를 마운트합니다.
    [root@nfs-client ~]# mount /mnt/
    [root@nfs-client ~]# mount /home
    명령은 /etc/fstab 항목의 정보를 사용합니다.
  10. Kerberos 티켓을 갱신하도록 SSSD를 설정합니다.
    1. /etc/sssd/sssd.conf 파일의 IdM 도메인 섹션에 다음 매개변수를 설정하여 티켓을 자동으로 업데이트하도록 SSSD를 설정합니다.
      [domain/EXAMPLE.COM]
      ...
      krb5_renewable_lifetime = 50d
      krb5_renew_interval = 3600
    2. SSSD를 다시 시작:
      [root@nfs-client ~]# systemctl restart sssd
중요
CloudEvent _oddjob_mkhomedir 모듈은 NFS 공유에 홈 디렉터리의 자동 생성을 지원하지 않습니다. 따라서 홈 디렉터리가 포함된 공유의 루트에 있는 서버에 홈 디렉터리를 수동으로 생성해야 합니다.

34.5. 위치 구성

위치는 모두 auto.master 에 저장된 맵 세트이며, 위치는 여러 맵을 저장할 수 있습니다. 위치 항목은 맵 항목의 컨테이너로만 작동하며, 에서 자동 마운트 구성이 아닙니다.
중요
Identity Management는 CloudEvent를 설정하거나 구성하지 않습니다. 이 작업은 별도로 수행해야 합니다. ID 관리는 기존 CloudEvent 배포와 함께 작동합니다.

34.5.1. 웹 UI를 통한 위치 구성

  1. 정책 탭을 클릭합니다.
  2. 자동 마운트 를 클릭합니다.
  3. 위치 목록의 맨 위에 있는 Add 링크를 클릭합니다.
  4. 새 위치의 이름을 입력합니다.
  5. 추가 및 편집 버튼을 클릭하여 새 위치의 맵 구성으로 이동합니다. 34.6.1.1절. “웹 UI에서 직접 맵 구성”34.6.2.1절. “웹 UI에서 간접 맵 구성” 에 설명된 대로 맵을 만듭니다.

34.5.2. 명령줄을 통한 위치 구성

map을 생성하려면 autoscale location-add 를 사용하여 위치 이름을 지정합니다.
$ ipa automountlocation-add location
예를 들어 다음과 같습니다.
$ ipa automountlocation-add raleigh
----------------------------------
Added automount location "raleigh"
----------------------------------
  Location: raleigh
새 위치가 생성되면 자동.master 및 auto.direct 두 개의 맵이 자동으로 생성됩니다. auto.master 는 해당 위치에 대한 모든 자동 마운트 맵의 루트 맵입니다. auto.direct 는 직접 마운트의 기본 맵이며 /- 에 마운트됩니다.
위치에 구성된 모든 맵을 파일 시스템에 배포된 것처럼 보려면 autoscale location-tofiles 명령을 사용합니다.
$ ipa automountlocation-tofiles raleigh
/etc/auto.master:
/-      /etc/auto.direct
---------------------------
/etc/auto.direct:

34.6. 맵 구성

맵을 구성하면 맵이 생성될 뿐만 아니라 마운트 지점을 키를 통해 연결하며, 디렉터리에 액세스할 때 사용해야 하는 마운트 옵션을 할당합니다. IdM은 직접 맵과 간접 맵을 모두 지원합니다.
참고
클라이언트마다 다른 맵 세트를 사용할 수 있습니다. 맵 세트는 트리 구조를 사용하므로 위치 간에 맵을 공유할 수 없습니다.
중요
Identity Management는 CloudEvent를 설정하거나 구성하지 않습니다. 이 작업은 별도로 수행해야 합니다. ID 관리는 기존 CloudEvent 배포와 함께 작동합니다.

34.6.1. 직접 맵 구성

직접 맵은 파일 마운트 지점에 대한 정확한 위치( 절대 경로)를 정의합니다. 위치 항목에서 직접 맵은 앞의 슬래시로 식별됩니다.
---------------------------
/etc/auto.direct:
/shared/man server.example.com:/shared/man

34.6.1.1. 웹 UI에서 직접 맵 구성

  1. 정책 탭을 클릭합니다.
  2. 자동 마운트 를 클릭합니다.
  3. 맵을 추가할 자동 마운트 위치의 이름을 클릭합니다.
  4. Automount Maps 탭에서 + Add 링크를 클릭하여 새 맵을 생성합니다.
  5. 팝업 창에서 직접 라디오 버튼을 선택하고 새 맵의 이름을 입력합니다.
  6. Automount Keys 탭에서 + Add 링크를 클릭하여 맵의 새 키를 생성합니다.
  7. 마운트 지점을 입력합니다. 키는 키 이름에 실제 마운트 지점을 정의합니다. Info 필드는 디렉터리의 네트워크 위치와 사용할 마운트 옵션을 설정합니다.
  8. Add 버튼을 클릭하여 새 키를 저장합니다.

34.6.1.2. 명령줄에서 직접 맵 구성

키는 실제 마운트 지점(키 이름에)과 모든 옵션을 정의합니다. 맵은 키 형식을 기반으로 직접 또는 간접 맵입니다.
각 위치는 auto.direct 항목으로 생성됩니다. 가장 간단한 구성은 자동 마운트 키를 기존 직접 맵 항목에 추가하여 직접 매핑을 정의하는 것입니다. 또한 다양한 직접 맵 항목을 만들 수 있습니다.
위치의 auto.direct 파일에 직접 맵의 키를 추가합니다. key 옵션은 마운트 지점을 식별하고 --info 는 디렉터리의 네트워크 위치와 사용할 마운트 옵션을 제공합니다. 예를 들어 다음과 같습니다.
$ ipa automountkey-add raleigh auto.direct --key=/share --info="ro,soft,ipaserver.example.com:/home/share"
  Key: /share
  Mount information: ro,soft,ipaserver.example.com:/home/share
마운트 옵션은 mount manpage에 설명되어 있습니다 http://linux.die.net/man/8/mount.
Solaris에서 ldapclient 명령을 사용하여 직접 맵과 키를 추가하여 LDAP 항목을 직접 추가합니다.
ldapclient -a serviceSearchDescriptor=auto_direct:automountMapName=auto.direct,cn=location,cn=automount,dc=example,dc=com?one

34.6.2. 간접 맵 구성

간접 맵은 기본적으로 맵의 상대 경로를 지정합니다. 상위 항목은 모든 간접 맵에 대한 기본 디렉터리를 설정합니다. 간접 맵 키는 하위 디렉터리를 설정합니다. 간접 맵 위치가 로드될 때마다 키가 해당 기본 디렉터리에 추가됩니다. 예를 들어 기본 디렉터리가 /docs 이고 키가 man 인 경우 맵은 /docs/man 입니다.

34.6.2.1. 웹 UI에서 간접 맵 구성

  1. 정책 탭을 클릭합니다.
  2. 자동 마운트 를 클릭합니다.
  3. 맵을 추가할 자동 마운트 위치의 이름을 클릭합니다.
  4. Automount Maps 탭에서 + Add 링크를 클릭하여 새 맵을 생성합니다.
  5. 팝업 창에서 Indirect 라디오 버튼을 선택하고 간접 맵에 필요한 정보를 입력합니다.
    • 새 맵의 이름
    • 마운트 지점. Mount 필드는 모든 간접 맵 키에 사용할 기본 디렉터리를 설정합니다.
    • 선택적으로 상위 맵입니다. 기본 상위는 auto.master 이지만 사용해야 하는 다른 맵이 있으면 Map 필드에 지정할 수 있습니다.
  6. Add 버튼을 클릭하여 새 키를 저장합니다.

34.6.2.2. 명령줄에서 간접 맵 구성

직접 맵과 간접 맵의 주요 차이점은 간접 키 앞에 슬래시가 없다는 것입니다.
---------------------------
/etc/auto.share:
man     ipa.example.com:/docs/man
---------------------------
  1. autoscalemap -add-indirect 명령을 사용하여 기본 항목을 설정하는 간접 맵 을 만듭니다. mount 옵션은 모든 간접 맵 키에 사용할 기본 디렉터리를 설정합니다. 기본 상위 항목은 auto.master 항목이지만 사용해야 하는 다른 맵이 있는 경우 --parentmap 옵션을 사용하여 지정할 수 있습니다.
    $ ipa automountmap-add-indirect location mapName --mount=directory [--parentmap=mapName]
    예를 들어 다음과 같습니다.
    $ ipa automountmap-add-indirect raleigh auto.share --mount=/share
    --------------------------------
    Added automount map "auto.share"
    --------------------------------
  2. 마운트 위치의 간접 키를 추가합니다.
    $ ipa automountkey-add raleigh auto.share --key=docs --info="ipa.example.com:/export/docs"
    -------------------------
    Added automount key "docs"
    -------------------------
      Key: docs
      Mount information: ipa.example.com:/export/docs
  3. 설정을 확인하려면 autoscale location-tofiles를 사용하여 위치 파일 목록을 확인하십시오.
    $ ipa automountlocation-tofiles raleigh
    /etc/auto.master:
    /-      /etc/auto.direct
    /share  /etc/auto.share
    ---------------------------
    /etc/auto.direct:
    ---------------------------
    /etc/auto.share:
    man     ipa.example.com:/export/docs
Solaris에서 ldapclient 명령을 사용하여 간접 맵을 추가하여 LDAP 항목을 직접 추가합니다.
ldapclient -a serviceSearchDescriptor=auto_share:automountMapName=auto.share,cn=location,cn=automount,dc=example,dc=com?one

34.6.3. 자동 마운트 맵 가져오기

기존의 마운팅 맵이 있는 경우 해당 맵을 IdM mount configuration으로 가져올 수 있습니다.
ipa automountlocation-import location map_file [--continuous]
필요한 유일한 정보는 IdM의 위치 및 전체 경로 및 맵 파일 이름입니다. --continuous 옵션은 명령이 오류가 발생하더라도 맵 파일을 계속 진행하도록 CloudEventlocation-import 명령을 지시합니다.
예를 들어 다음과 같습니다.
$ ipa automountlocation-import raleigh /etc/custom.map

VIII 부. 보안 강화

이 부분에서는 ID 관리를 안전하게 사용하는 권장 사례를 제공합니다.

35장. ID 관리를 위한 TLS 구성

이 문서에서는 Red Hat Enterprise Linux 7.3 이상에서 TLS 프로토콜 버전 1.2를 요구하도록 ID 관리 서버를 구성하는 방법에 대해 설명합니다.
TLS 1.2는 이전 버전의 TLS보다 더 안전한 것으로 간주됩니다. IdM 서버가 높은 보안 요구 사항이 있는 환경에 배포된 경우 TLS 1.2보다 덜 안전한 프로토콜을 사용하여 통신이 금지되도록 구성할 수 있습니다.
중요
TLS 1.2를 사용하려는 모든 IdM 서버에서 이 단계를 반복합니다.

35.1. httpd 데몬 구성

  1. /etc/httpd/conf.d/nss.conf 파일을 열고 NSSProtocolNSSCipherSuite 항목에 대해 다음 값을 설정합니다.
    NSSProtocol TLSv1.2
    NSSCipherSuite +ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
    또는 다음 명령을 사용하여 값을 설정합니다.
    # sed -i 's/^NSSProtocol .*/NSSProtocol TLSv1.2/' /etc/httpd/conf.d/nss.conf
    # sed -i 's/^NSSCipherSuite .*/NSSCipherSuite +ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_sha,+rsa_aes_256_sha/' /etc/httpd/conf.d/nss.conf
  2. httpd 데몬을 다시 시작합니다.
    # systemctl restart httpd

35.2. 디렉터리 서버 구성 요소 구성

ldapmodify 유틸리티를 사용하여 DS를 자동으로 구성하려면 다음을 수행합니다.
  1. ldapmodify 를 사용하여 설정을 변경합니다.
    ldapmodify -h localhost -p 389 -D 'cn=directory manager' -W << EOF
    dn: cn=encryption,cn=config
    changeType: modify
    replace: sslVersionMin
    sslVersionMin: TLS1.2
    EOF
  2. DS를 다시 시작하여 새 구성을 로드합니다.
    # systemctl restart dirsrv@EXAMPLE-COM.service
수동으로 디렉터리 서버(DS)를 구성하려면 다음을 수행합니다.
  1. DS 중지:
    # systemctl stop dirsrv@EXAMPLE-COM.service
  2. /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif 파일을 열고 cn=encryption,cn=config 항목을 수정하여 다음을 설정합니다.
    sslVersionMin: TLS1.2
  3. DS를 시작하십시오.
    # systemctl start dirsrv@EXAMPLE-COM.service
중요
dse.ldif 파일을 수동으로 편집하기 전에 서버를 종료해야 합니다. DS는 시작 시 한 번만 이 파일을 읽으므로 LDAP를 통해 구성이 변경되면 서버가 실행되는 동안 수동 변경이 손실됩니다. dse.ldif 파일을 편집하는 것은 동적으로 변경할 수 없는 속성의 변경에만 권장됩니다.

35.3. 인증서 서버 구성 요소 구성

  1. 인증서 서버(CS)를 수동으로 구성하려면 /etc/pki/pki-tomcat/server.xml 파일을 엽니다. sslVersionRangeStreamsslVersionRangeDatagram 매개변수의 모든 발생을 다음 값으로 설정합니다.
    sslVersionRangeStream="tls1_2:tls1_2"
    sslVersionRangeDatagram="tls1_2:tls1_2"
    또는 다음 명령을 사용하여 값을 바꿉니다.
    # sed -i 's/tls1_[01]:tls1_2/tls1_2:tls1_2/g' /etc/pki/pki-tomcat/server.xml
  2. CS를 다시 시작하십시오.
    # systemctl restart pki-tomcatd@pki-tomcat.service

35.4. 결과

ID 관리 서버는 TLS 1.2가 요구되도록 구성되어 있습니다. 이전 TLS 버전만 지원하는 ID 관리 클라이언트는 더 이상 ID 관리 서버와 통신할 수 없습니다.

36장. 익명 Bind 비활성화

도메인 리소스 액세스 및 클라이언트 툴 실행에는 항상 Kerberos 인증이 필요합니다. 그러나 IdM 서버에서 사용하는 백엔드 LDAP 디렉터리는 기본적으로 익명을 바인딩할 수 있습니다. 이렇게 하면 사용자, 시스템, 그룹, 서비스, 네트그룹 및 DNS 구성에 대한 정보를 포함하여 권한이 없는 사용자에게 모든 도메인 구성이 생성될 수 있습니다.
LDAP 도구를 사용하여 nsslapd-allow-anonymous-access 특성을 재설정하는 방식으로 389 Directory Server 인스턴스에서 익명 바인딩을 비활성화할 수 있습니다.
주의
특정 클라이언트는 익명 바인딩을 사용하여 IdM 설정을 검색합니다. 또한 인증을 사용하지 않는 레거시 클라이언트에 대해 compat 트리가 중단될 수 있습니다.
  1. nsslapd-allow-anonymous-access 특성을 rootdse 로 변경합니다.
    $ ldapmodify -x -D "cn=Directory Manager" -W -h server.example.com -p 389 -ZZ
    Enter LDAP Password:
    dn: cn=config
    changetype: modify
    replace: nsslapd-allow-anonymous-access
    nsslapd-allow-anonymous-access: rootdse
    
    modifying entry "cn=config"
    중요
    익명 액세스를 완전히 허용하거나 (on) 완전히 차단(off)할 수 있습니다. 그러나 익명 액세스를 완전히 차단하면 외부 클라이언트가 서버 구성을 확인하지 못합니다. LDAP 및 웹 클라이언트는 반드시 도메인 클라이언트가 아니므로, 연결 정보를 얻기 위해 정기적으로 연결하여 루트 DSE 파일을 읽습니다.
    rootdse 를 사용하면 디렉터리 데이터에 대한 액세스 권한 없이 루트 DSE 및 서버 구성에 액세스할 수 있습니다.
  2. 389 Directory Server 인스턴스를 다시 시작하여 새 설정을 로드합니다.
    # systemctl restart dirsrv.target
추가 리소스:

IX 부. 성능 튜닝

이 부분에서는 Identity Management 의 성능을 최적화하는 권장 사례를 제공합니다.

37장. 항목 프로비저닝을 위한 성능 튜닝

일반적인 워크플로우를 사용하여 많은 수의 항목을 추가합니다(예: 사용자 추가의 경우 11장. 사용자 계정 관리 ) 매우 느려질 수 있습니다. 이 장에서는 프로비저닝이 가능한 한 빨리 완료되도록 프로세스를 조정하는 방법을 설명합니다.
절차의 일부로 다음을 수행합니다.
  • IdM(Identity Management)은 LDIF 파일에서 프로비저닝할 항목을 읽은 다음 대상 IdM LDAP 인스턴스로 가져옵니다.
  • 관리자는 캐시 크기와 같은 특정 속성에 대한 사용자 지정 값을 설정하고 MemberOf 및 Schema 호환성 플러그인을 비활성화합니다. 이 절차에는 MemberOf를 비활성화하기 위해 프로비저닝된 항목에서 fixup-memberof.pl 플러그인을 실행하는 작업이 포함됩니다.
이 절차는 사용자, 사용자 그룹, 호스트, 호스트 그룹, sudo 규칙 및 HBAC(Host-based Access Control) 규칙의 입력 유형을 프로비저닝하도록 설계 및 테스트되었습니다.

프로비저닝을 위한 권장 사항 및 사전 요구 사항

권장 사항:
  • 다수의 항목(10,000 이상)을 프로비저닝할 때 LDAP 클라이언트가 항목이 프로비저닝되거나 서버의 정보를 사용하는 서버에 액세스하는 것을 허용하지 마십시오. 예를 들어 서버에서 포트 389 및 636을 비활성화하고 LDAPI를 사용하여 Unix 소켓을 통해 작업할 수 있습니다.
    이유: MemberOf 플러그인이 서버에서 비활성화되어 있으므로 서버의 멤버십 정보가 유효하지 않습니다.
  • 프로비저닝 중에 실행할 필요가 없는 애플리케이션을 중지합니다.
    이유: 이렇게 하면 시스템의 메모리를 최대한 확보할 수 있습니다. 사용 가능한 메모리는 파일 시스템 캐시에서 사용하므로 프로비저닝 성능이 향상됩니다.
    아래 절차에는 IdM 서비스를 중지하고, Directory Server(DS) 인스턴스만 다시 시작하는 단계가 이미 포함되어 있습니다. IdM 서비스, 특히 tomcat 은 많은 메모리를 사용하지만 프로비저닝 중에는 사용되지 않습니다.
  • 서버가 하나만 있는 새로운 IdM 배포에서 절차를 실행합니다. 프로비저닝이 완료된 후에만 복제본을 생성합니다.
    이유: 프로비저닝 처리량은 복제보다 훨씬 빠릅니다. 서버가 하나 이상 있는 배포에서는 복제본에 대한 정보가 상당히 오래되었습니다.
사전 요구 사항:
  • 프로비저닝할 항목이 포함된 LDIF 파일을 생성합니다. 예를 들어 기존 IdM 배포를 마이그레이션하는 경우 ldapsearch 유틸리티를 사용하여 모든 항목을 내보내서 LDIF 파일을 생성합니다.
    LDIF 형식에 대한 자세한 내용은 Red Hat Directory Server 10 관리 가이드의 LDIF 파일 형식 정보를 참조하십시오.

현재 DS 튜닝 매개 변수 값 백업

  1. DS 튜닝 매개변수의 현재 값을 검색합니다.
    • 데이터베이스 캐시 크기 및 데이터베이스 잠금:
      # ldapsearch -D "cn=directory manager" -w secret -b "cn=config,cn=ldbm database,cn=plugins,cn=config" nsslapd-dbcachesize nsslapd-db-locks
      
      ...
      nsslapd-dbcachesize: 10000000
      nsslapd-db-locks: 50000
      ...
    • 입력 캐시 크기 및 DN 캐시 크기:
      # ldapsearch -D "cn=directory manager" -w secret -b "cn=userRoot,cn=ldbm database,cn=plugins,cn=config" nsslapd-cachememsize nsslapd-dncachememsize
      
      ...
      nsslapd-cachememsize: 10485760
      nsslapd-dncachememsize: 10485760
      ...
  2. 가져온 값을 기록합니다. 배포를 완료한 후 매개 변수를 다시 이러한 값으로 재설정합니다.

데이터베이스, 도메인 항목 및 DN 캐시 크기 조정

데이터베이스 캐시 크기의 경우:
  1. 필요한 값을 확인합니다.
    권장 값은 일반적으로 200MB에서 500MB 사이입니다. 사용 사례에 적합한 값은 시스템에서 사용 가능한 메모리에 따라 다릅니다.
    • 8GB 이상의 메모리 → 500MB
    • 8GB - 메모리 4GB → 200MB
    • 메모리 4GB 미만 → 100MB
  2. 이 템플릿을 사용하여 결정된 값을 설정합니다.
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-dbcachesize
    nsslapd-dbcachesize: db_cache_size_in_bytes
    ldapmodify 유틸리티를 사용하여 LDAP 속성을 수정하는 예는 예 37.1. “ldapmodify 를 사용하여 LDAP 속성 변경” 를 참조하십시오.

예 37.1. ldapmodify 를 사용하여 LDAP 속성 변경

  1. ldapmodify 명령을 실행한 다음, 특성 값을 수정할 문을 추가합니다. 예를 들어 다음과 같습니다.
    # ldapmodify -D "cn=directory manager" -w secret -x
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-dbcachesize
    nsslapd-dbcachesize: 200000000
  2. Ctrl+D 눌러 변경 사항을 확인하고 서버에 보냅니다. 작업이 성공적으로 완료되면 다음 메시지가 표시됩니다.
    modifying entry "cn=config,cn=ldbm database,cn=plugins,cn=config"
도메인 항목 캐시 크기의 경우 다음을 수행합니다.
  1. 필요한 값을 확인합니다.
    권장 값은 100MB에서 400MB 사이입니다. 적절한 값은 시스템에서 사용 가능한 메모리에 따라 다릅니다.
    • 4GB 이상의 메모리 → 400MB
    • 2GB - 메모리 4GB → 200MB
    • 2GB 이상의 메모리 → 100MB 미만
    큰 정적 그룹을 프로비저닝하는 경우 항목 캐시가 모든 항목(그룹 및 멤버)에 맞게 충분히 큰 것이 좋습니다.
  2. 이 템플릿을 사용하여 결정된 값을 설정합니다.
    dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-cachememsize
    nsslapd-cachememsize: entry_cache_size_in_bytes
DN(도메인 이름) 캐시 크기의 경우 다음을 수행합니다.
  1. 가능한 최상의 성능을 위해 DN 캐시가 프로비저닝된 항목의 모든 DN에 맞는 것이 좋습니다. 사용 사례에 적합한 값을 추정하려면 다음을 수행합니다.
    1. 파일에서 모든 DN 항목 수를 확인합니다. DN 항목은 dn: 로 시작하는 행에 있습니다. 예를 들어 # grep,sed, wc 를 사용합니다.
      # grep '^dn: ' ldif_file | sed 's/^dn: //' | wc -l
      92200
    2. LDIF 파일에서 모든 DN 항목 문자열의 크기를 확인합니다.
      # grep '^dn: ' ldif_file | sed 's/^dn: //' | wc -c
      9802460
    3. 평균 DN 크기 가져오기: 모든 DN 입력 문자열의 크기를 파일의 모든 DN 항목 수로 나눕니다.
      예를 들어 다음과 같습니다. 9,802,460 / 92,200 ≈ 106
    4. 평균 메모리 크기: 평균 DN 크기를 2만큼 여러 개 가져온 다음 결과에 32를 추가합니다.
      예를 들어 다음과 같습니다. (106 * 2) + 32 = 244
    5. 적절한 DN 캐시 크기를 가져오기: 평균 메모리 크기를 LDIF 파일의 전체 DN 항목 수에 곱합니다.
      예를 들어 다음과 같습니다. 244 * 92,200 = 22,496,800
  2. 이 템플릿을 사용하여 결정된 값을 설정합니다.
    dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
    changetype: modify
    Replace: nsslapd-dncachememsize
    Nsslapd-dncachememsize: dn_cache_size

불필요한 서비스 비활성화 및 데이터베이스 잠금 조정

  1. MemberOf 및 Schema 호환성 플러그인을 비활성화합니다.
    dn: cn=MemberOf Plugin,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: off
    dn: cn=Schema Compatibility,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: off
    MemberOf를 비활성화하면 프로비저닝 속도가 훨씬 빨라집니다. 스키마 호환성을 비활성화하면 작업 기간도 줄일 수 있습니다.
    ldapmodify 유틸리티를 사용하여 LDAP 속성을 수정하는 예는 예 37.1. “ldapmodify 를 사용하여 LDAP 속성 변경” 를 참조하십시오.
  2. 토폴로지에 복제본이 설치되어 있지 않은 경우 ( “프로비저닝을 위한 권장 사항 및 사전 요구 사항”에서 권장) Content Synchronization and Retro Changelog 플러그인을 비활성화합니다.
    dn: cn=Content Synchronization,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: off
    dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: off
    이러한 추가 플러그인을 비활성화하면 프로비저닝의 성능이 향상됩니다.
  3. IdM 서버를 중지합니다. 이렇게 하면 DS 인스턴스도 중지됩니다.
    # ipactl stop
    다음 단계에서 데이터베이스 잠금 수를 설정하려면 DS를 중지해야 합니다. 나중에 다시 시작합니다.
  4. 데이터베이스 잠금 수를 조정합니다. 적절한 값은 프로비저닝된 항목 수의 절반과 같습니다.
    • 최소 값은 10,000입니다.
    • 최대 값은 200,000입니다.
    DS가 중지되었으므로 /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif 파일을 수정하여 값을 설정해야 합니다.
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
    ...
    nsslapd-db-locks: db_lock_number
    IdM은 컴퓨팅 멤버십 시 다수의 데이터베이스 페이지에 액세스합니다. 페이지에 액세스할수록 배포에 더 많은 잠금이 필요합니다.
  5. DS를 시작하십시오.
    # systemctl start dirsrv.target

항목 가져오기

새 항목을 LDIF 파일에서 IdM LDAP 인스턴스로 가져오려면 다음을 수행합니다. 예를 들어 ldapadd 유틸리티를 사용합니다.
# ldapadd -D "binddn" -y password_file -f ldif_file
ldapadd 사용에 대한 자세한 내용은 ldapadd(1) 도움말 페이지를 참조하십시오.

비활성화된 서비스 다시 활성화 및 원래 속성 값 복구

  1. MemberOf 활성화:
    dn: cn=MemberOf Plugin,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: on
    ldapmodify 유틸리티를 사용하여 LDAP 속성을 수정하는 예는 예 37.1. “ldapmodify 를 사용하여 LDAP 속성 변경” 를 참조하십시오.
  2. DS를 다시 시작하십시오.
    # systemctl restart dirsrv.target
    이전 단계에서 MemberOf를 활성화했기 때문에 이 시점에서 DS를 다시 시작해야 합니다.
  3. (objectClass=*) 필터를 사용하여 fixup-memberof.pl 스크립트를 실행하여 모든 프로비저닝된 항목에서 memberOf 속성을 다시 생성하고 업데이트합니다. 예를 들어 다음과 같습니다.
    # fixup-memberof.pl -D "cn=directory manager" -j password_file -Z server_id -b "suffix" -f "(objectClass=*)" -P LDAP
    항목을 가져올 때 MemberOf 플러그인이 비활성화되어 있었기 때문에 fixup-memberof.pl 을 실행해야 합니다. 프로비저닝을 계속하려면 스크립트가 성공적으로 완료해야 합니다.
    fixup-memberof.pl 에 대한 자세한 내용은 fixup-memberof.pl(8) 매뉴얼 페이지를 참조하십시오.
  4. 스키마 호환성 플러그인을 활성화합니다.
    dn: cn=Schema Compatibility,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: on
  5. “불필요한 서비스 비활성화 및 데이터베이스 잠금 조정” 에서 콘텐츠 동기화 및 Retro Changelog 플러그인을 비활성화한 경우 다시 활성화합니다.
    dn: cn=Content Synchronization,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: on
    dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: on
  6. 데이터베이스 캐시, 항목 캐시, DN 캐시의 원래 값을 “현재 DS 튜닝 매개 변수 값 백업” 에서 백업합니다.
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-dbcachesize
    nsslapd-dbcachesize: backup_db_cache_size
    
    dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
    changetype: modify
    Replace: nsslapd-dncachememsize
    Nsslapd-dncachememsize: backup_dn_cache_size
    -
    replace: nsslapd-cachememsize
    nsslapd-cachememsize: backup_entry_cache_size
  7. DS 중지:
    # systemctl stop dirsrv.target
  8. 데이터베이스 잠금의 원래 값을 “현재 DS 튜닝 매개 변수 값 백업” 백업합니다. DS가 중지되었으므로 /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif 파일을 수정하여 값을 설정해야 합니다.
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
    ...
    nsslapd-db-locks: backup_db_lock_number
  9. IdM 서버를 시작합니다.
    # ipactl start
    이렇게 하면 DS를 포함한 모든 IdM 서비스가 시작됩니다.

38장. Identity Management의 장애 조치, 로드 밸런싱 및 고가용성

IdM(Identity Management)에는 자체 페일오버, 로드 밸런싱 및 고가용성(예: LDAP ID 도메인 및 인증서 복제)과 함께 제공되며 SSSD( System Security Services Daemon )에서 제공하는 서비스 검색 및 페일오버 지원이 제공됩니다.
IdM은 다음과 같은 기능을 갖추고 있습니다.

클라이언트 측 장애 조치 기능

SSSD 는 클라이언트가 자동으로 검색하는 DNS 서버에서 SRV(서비스) 리소스 레코드를 가져옵니다. SRV 레코드를 기반으로 SSSD 는 이러한 서버 연결에 대한 정보를 포함하여 사용 가능한 IdM 서버 목록을 유지합니다. 하나의 IdM 서버가 오프라인되거나 과부하가 발생하는 경우 SSSD는 이미 통신할 다른 서버를 알고 있습니다.
DNS 자동 검색을 사용할 수 없는 경우 적어도 오류 발생 시 SRV 레코드를 검색하도록 IdM 클라이언트의 고정 IdM 서버 목록을 구성해야 합니다.
IdM 클라이언트를 설치하는 동안 설치 프로그램은 클라이언트의 호스트 이름에 대한 상위 도메인의 _ldap._tcp.DOMAIN DNS SRV 레코드를 검색합니다. 이러한 방식으로 설치 프로그램은 클라이언트와 통신하기 위해 가장 편리하게 위치한 IdM 서버의 호스트 이름을 검색하고 해당 도메인을 사용하여 클라이언트 구성 요소를 구성합니다.

서버측 서비스 가용성

IdM을 사용하면 지리적으로 분산된 데이터 센터의 서버를 복제하여 IdM 클라이언트와 가장 가까운 액세스 가능한 서버 간의 경로를 줄일 수 있습니다. 서버를 복제하면 더 많은 클라이언트의 부하를 분산하고 확장할 수 있습니다.
IdM 복제 메커니즘은 활성/활성 서비스 가용성을 제공합니다. 모든 IdM 복제본에서 서비스를 동시에 쉽게 사용할 수 있습니다.
참고
IdM을 다른 로드 밸런싱과 결합하려고 하면 HA 소프트웨어는 권장되지 않습니다. 많은 타사 HA(고가용성) 솔루션은 액티브/패시브 시나리오를 가정하고 IdM 가용성에 대한 불필요한 서비스 중단을 야기합니다. 다른 솔루션은 클러스터된 서비스당 가상 IP 또는 단일 호스트 이름을 사용합니다. 이러한 모든 방법은 IdM 솔루션이 제공하는 서비스 가용성 유형에서 일반적으로 잘 작동하지 않습니다. 또한 Kerberos와의 통합이 매우 잘못되어 배포의 전체적인 보안과 안정성을 낮춥니다.
특히 이러한 서비스가 고가용성이어야 하고 네트워킹 구성을 수정하여 HA 기능을 제공하는 솔루션을 사용하는 경우와 관련이 없는 다른 서비스를 IdM 마스터에 배포하는 것을 권장하지 않습니다.
Kerberos가 인증에 사용될 때 로드 밸런서를 사용하는 방법에 대한 자세한 내용은 이 블로그 포스트 를 참조하십시오.

X 부. Migration

이 부분에서는 다른 솔루션에서 ID 관리로 배포를 마이그레이션하기 위한 권장 사례를 제공합니다.

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 _ldapnss_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 환경을 마이그레이션하려고 시도하기 전에 마이그레이션 프로세스를 테스트합니다.

39.2. ipa migrate-ds사용 예

데이터 마이그레이션은 ipa migrate-ds 명령을 사용하여 수행됩니다. 가장 간단하게 명령은 디렉터리의 LDAP URL을 사용하여 일반적인 기본 설정에 따라 데이터를 마이그레이션하고 내보냅니다.
ipa migrate-ds ldap://ldap.example.com:389
마이그레이션된 항목
migrate-ds 명령은 posixAccount 오브젝트 클래스에 필요한 gidNumber 속성과 person 오브젝트 클래스에 필요한 sn 속성만 포함하는 계정을 마이그레이션합니다.
프로세스 사용자 정의
ipa migrate-ds 명령을 사용하면 데이터를 식별하고 내보내는 방법을 사용자 지정할 수 있습니다. 이 기능은 원래 디렉터리 트리에 고유한 구조가 있거나 항목 내 일부 항목 또는 속성을 제외해야 하는 경우 유용합니다. 자세한 내용은 명령에 --help 를 전달합니다.
DN 바인딩
기본적으로 DN "cn=Directory Manager"는 원격 LDAP 디렉터리에 바인딩하는 데 사용됩니다. 명령에 --bind-dn 옵션을 전달하여 사용자 정의 바인딩 DN을 지정합니다. 자세한 내용은 39.1.3.5절. “마이그레이션 툴” 의 내용을 참조하십시오.
컨텍스트 변경 이름 지정
Directory Server 이름 지정 컨텍스트가 ID 관리에 사용된 컨텍스트와 다른 경우 개체의 기본 DN이 변환됩니다. 예: uid=user,ou=people,dc=ldap,dc=example,dc=comuid=사용자,ou=people,dc=idm,dc=example,dc=com. --base-dnipa migrate-ds 명령에 전달하여 마이그레이션을 위해 원격 LDAP 서버에서 사용된 기본 DN을 설정합니다.

39.2.1. 특정 하위 트리 마이그레이션

기본 디렉터리 구조는 ou=People 하위 트리에 사람 항목을 배치하고 ou=Groups 하위 트리에 그룹 항목을 배치합니다. 이러한 하위 트리는 다양한 유형의 디렉터리 데이터를 위한 컨테이너 항목입니다. migrate-ds 명령과 함께 옵션을 전달하지 않으면 유틸리티는 지정된 LDAP 디렉터리가 ou=Peopleou=Groups 구조를 사용하도록 가정합니다.
대부분의 배포에는 완전히 다른 디렉터리 구조가 있을 수 있습니다(또는 디렉토리 트리의 특정 부분만 내보내려는 경우). 관리자가 소스 LDAP 서버에서 다른 사용자 또는 그룹 하위 트리의 RDN을 지정할 수 있는 두 가지 옵션이 있습니다.
  • --user-container
  • --group-container
참고
두 경우 모두 하위 트리는 RDN이어야 하며 기본 DN과 관련되어야 합니다. 예를 들어 > ou=ECDHEs,dc=example,dc=com 디렉터리 트리는 --user-container=ou=knatives 를 사용하여 마이그레이션할 수 있습니다.
예를 들어 다음과 같습니다.
[root@ipaserver ~]# ipa migrate-ds --user-container=ou=employees \
                        --group-container="ou=employee groups" \
			ldap://ldap.example.com:389
ipa migrate-ds 명령에 --scope 옵션을 전달하여 범위를 설정합니다.
  • 한 수준: 기본값. 지정된 컨테이너의 항목만 마이그레이션됩니다.
  • subtree: 지정된 컨테이너 및 모든 하위 컨테이너의 항목이 마이그레이션됩니다.
  • base: 지정된 오브젝트 자체만 마이그레이션됩니다.

39.2.2. 특히 포함 또는 제외 항목

기본적으로 ipa migrate-ds 스크립트는 person 개체 클래스와 groupOfUniqueNames 또는 groupOfNames 오브젝트 클래스를 사용하여 모든 사용자 항목을 가져옵니다.
일부 마이그레이션 경로에서는 특정 유형의 사용자와 그룹만 내보내야 하거나 반대로 특정 사용자와 그룹만 제외해야 할 수 있습니다.
한 가지 옵션은 포함할 사용자 및 그룹 유형을 독점적으로 설정하는 것입니다. 이 작업은 사용자 또는 그룹 항목을 찾을 때 검색할 오브젝트 클래스를 설정하여 수행됩니다.
이 옵션은 다양한 사용자 유형의 환경에 사용자 지정 개체 클래스를 사용하는 경우 매우 유용합니다. 예를 들어 사용자 정의 fullTime >-< 개체 클래스가 있는 사용자만 마이그레이션합니다.
[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee ldap://ldap.example.com:389
다양한 유형의 그룹 때문에 인증서 그룹과 같은 다른 유형의 그룹을 제외하고 특정 유형의 그룹(예: 사용자 그룹)만 마이그레이션하는 데도 매우 유용합니다. 예를 들어 다음과 같습니다.
[root@ipaserver ~]# ipa migrate-ds --group-objectclass=groupOfNames --group-objectclass=groupOfUniqueNames ldap://ldap.example.com:389
오브젝트 클래스를 기반으로 마이그레이션할 사용자 및 그룹을 적극적으로 지정하여 다른 모든 사용자 및 그룹을 마이그레이션에서 암시적으로 제외합니다.
또는 소수의 항목만 제외하고 모든 사용자와 그룹 항목을 마이그레이션하는 것이 유용할 수 있습니다. 해당 유형의 다른 모든 항목은 마이그레이션하는 동안 특정 사용자 또는 그룹 계정을 제외할 수 있습니다. 예를 들어, 한 개의 그룹과 두 명의 사용자를 제외합니다.
[root@ipaserver ~]# ipa migrate-ds --exclude-groups="Golfers Group" --exclude-users=jsmith --exclude-users=bjensen ldap://ldap.example.com:389
exclude 명령문은 uid 의 패턴과 일치하는 사용자와 cn 속성에서 일치하는 그룹에 적용됩니다.
마이그레이션할 오브젝트 클래스를 지정하는 것은 특정 항목을 제외하고 함께 사용할 수 있습니다. 예를 들어, 여기에는 특히 fullTime >-< 개체 클래스를 가진 사용자가 포함되지만 3명의 관리자를 제외합니다.
[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee --exclude-users=jsmith --exclude-users=bjensen --exclude-users=mreynolds ldap://ldap.example.com:389

39.2.3. Entry Attributes 제외

기본적으로 사용자 또는 그룹 항목의 모든 특성 및 개체 클래스가 마이그레이션됩니다. 대역폭 및 네트워크 제약 조건으로 인해 또는 특성 데이터가 더 이상 관련이 없기 때문에 이러한 경우가 있습니다. 예를 들어, 사용자에게 IdM 도메인에 참여할 때 새 사용자 인증서가 할당되는 경우 userCertificate 특성을 마이그레이션할 이유가 없습니다.
migrate-ds 에서는 다음과 같은 여러 옵션을 사용하여 특정 오브젝트 클래스 및 속성을 무시할 수 있습니다.
  • --user-ignore-objectclass
  • --user-ignore-attribute
  • --group-ignore-objectclass
  • --group-ignore-attribute
예를 들어 사용자에 대한 userCertificate 속성 및 strongAuthenticationUser 개체 클래스를 제외하고 그룹에 대해 groupOfCertificates 오브젝트 클래스를 제외하려면 다음을 실행합니다.
[root@ipaserver ~]# ipa migrate-ds --user-ignore-attribute=userCertificate --user-ignore-objectclass=strongAuthenticationUser --group-ignore-objectclass=groupOfCertificates ldap://ldap.example.com:389
참고
필수 속성을 무시하지 않도록 하십시오. 또한 개체 클래스를 제외할 때 해당 개체 클래스에서만 지원되는 속성을 제외해야 합니다.

39.2.4. 사용할 스키마 설정

ID 관리에서는 RFC2307bis 스키마를 사용하여 사용자, 호스트, 호스트 그룹 및 기타 네트워크 ID를 정의합니다. 그러나 마이그레이션 소스로 사용된 LDAP 서버가 RFC2307 스키마를 대신 사용하는 경우 --schema 옵션을 ipa migrate-ds 명령에 전달합니다.
[root@ipaserver ~]# ipa migrate-ds --schema=RFC2307 ldap://ldap.example.com:389

39.3. LDAP 서버를 Identity Management로 마이그레이션

중요
이는 일반적인 마이그레이션 절차이지만 모든 환경에서 작동하지 않을 수 있습니다.
실제 LDAP 환경을 마이그레이션하기 전에 LDAP 환경을 테스트하고 마이그레이션 프로세스를 테스트하는 것이 좋습니다. 마이그레이션이 올바르게 완료되었는지 확인하려면 다음을 수행하십시오.
  • ipa user-add 명령을 사용하여 IdM에 테스트 사용자를 생성하고 마이그레이션된 사용자의 출력을 테스트 사용자와 비교합니다. 마이그레이션된 사용자에게 테스트 사용자에게 제공되는 최소 특성 및 개체 클래스 집합이 포함되어 있는지 확인합니다.
    $ ipa user-add TEST_USER
  • 마이그레이션된 사용자 출력( IdM에서seen)을 소스 사용자(원래 LDAP 서버에 있음)와 비교합니다. 가져온 속성이 이중화되지 않고 예상 값이 있는지 확인합니다.
    $ ipa user-show --all TEST_USER
  1. 기존 LDAP 디렉터리의 다른 시스템에 사용자 지정 LDAP 디렉터리 스키마를 포함하여 IdM 서버를 설치합니다.
    참고
    사용자 지정 사용자 또는 그룹 스키마는 IdM에서 제한된 지원을 제공합니다. 마이그레이션 중에 호환되지 않는 개체 정의로 인해 문제가 발생할 수 있습니다.
  2. compat 플러그인을 비활성화합니다.
    [root@server ~]# ipa-compat-manage disable
    마이그레이션 중에 compat 트리에서 제공하는 데이터가 필요한 경우에는 이 단계가 필요하지 않습니다.
  3. IdM 디렉터리 서버 인스턴스를 다시 시작합니다.
    [root@server ~]# systemctl restart dirsrv.target
  4. 마이그레이션을 허용하도록 IdM 서버를 구성합니다.
    [root@server ~]# ipa config-mod --enable-migration=TRUE
  5. IdM 마이그레이션 스크립트 ipa migrate-ds 를 실행합니다. 가장 기본적인 경우 마이그레이션하려면 LDAP 디렉터리 인스턴스의 LDAP URL만 필요합니다.
    [root@server ~]# ipa migrate-ds ldap://ldap.example.com:389
    단순히 LDAP URL을 전달하면 일반적인 기본 설정을 사용하여 모든 디렉터리 데이터가 마이그레이션됩니다. 39.2절. “ipa migrate-ds사용 예” 에서 설명한 대로 다른 옵션을 지정하여 사용자 및 그룹 데이터를 선택적으로 마이그레이션할 수 있습니다.
    이전 단계에서 compat 플러그인이 비활성화되지 않은 경우 --with-compat 옵션을 ipa migrate-ds 로 전달합니다.
    정보를 내보내면 스크립트는 필요한 모든 IdM 오브젝트 클래스와 속성을 추가하고 이름 지정 컨텍스트가 다른 경우 IdM 디렉터리 트리와 일치하도록 속성에서 DN을 변환합니다. 예: uid=user,ou=people,dc=ldap,dc=example,dc=comuid=사용자,ou=people,dc=idm,dc=example,dc=com.
  6. 마이그레이션 전에 비활성화된 compat 플러그인을 다시 활성화합니다.
    [root@server ~]# ipa-compat-manage enable
  7. IdM 디렉터리 서버 인스턴스를 다시 시작합니다.
    [root@server ~]# systemctl restart dirsrv.target
  8. 마이그레이션 모드를 비활성화합니다.
    [root@server ]# ipa config-mod --enable-migration=FALSE
  9. 선택 사항입니다. LDAP 인증(ovn_ldap) 대신 Kerberos 인증을 사용하도록 SSD가 아닌 클라이언트를 재구성합니다. 모든 사용자가 마이그레이션될 때까지 PAM_LDAP 모듈을 사용합니다. 그런 다음 PAM_KRB5를 사용할 수 있습니다. 자세한 내용은 시스템 수준 인증 가이드 의 Kerberos 클라이언트 구성 을 참조하십시오.
  10. 사용자가 해시된 Kerberos 암호를 생성하는 방법은 두 가지가 있습니다. 둘 다 39.1.2절. “암호 마이그레이션 플래닝” 에 설명된 바와 같이 추가 사용자 상호 작용없이 사용자 암호를 마이그레이션합니다.
    1. SSSD 사용:
      1. LDAP 백엔드에서 IdM 백엔드로 SSSD가 설치된 클라이언트를 이동하여 IdM에 클라이언트로 등록합니다. 그러면 필요한 키와 인증서가 다운로드됩니다.
        Red Hat Enterprise Linux 클라이언트에서는 ipa-client-install 명령을 사용하여 이 작업을 수행할 수 있습니다. 예를 들어 다음과 같습니다.
        [root@server ~]# ipa-client-install --enable-dns-update
    2. IdM 마이그레이션 웹 페이지 사용:
      1. 마이그레이션 웹 페이지를 사용하여 IdM에 로그인하도록 사용자에게 지시합니다.
        https://ipaserver.example.com/ipa/migration
  11. 사용자 마이그레이션 프로세스를 모니터링하려면 기존 LDAP 디렉터리를 쿼리하여 암호가 있지만 아직 Kerberos 보안 키가 없는 사용자 계정을 확인합니다.
    [user@server ~]$ ldapsearch -LL -x -D 'cn=Directory Manager' -w secret -b 'cn=users,cn=accounts,dc=example,dc=com' '(&(!(krbprincipalkey=*))(userpassword=*))' uid
    참고
    쉘에서 해석하지 않도록 필터의 작은따옴표를 포함합니다.
  12. 모든 클라이언트 및 사용자의 마이그레이션이 완료되면 LDAP 디렉터리를 폐기합니다.

39.4. SSL을 통한 마이그레이션

마이그레이션 중에 LDAP와 IdM 간 데이터 전송을 암호화하려면 다음을 수행합니다.
  1. 원격 LDAP 서버의 인증서를 IdM 서버의 파일에 저장한 CA 인증서를 저장합니다. 예: /etc/ipa/remote.crt
  2. 39.3절. “LDAP 서버를 Identity Management로 마이그레이션” 에 설명된 단계를 따르십시오. 그러나 마이그레이션 중에 암호화된 LDAP 연결의 경우 URL에서 ldaps 프로토콜을 사용하고 --ca-cert-file 옵션을 명령에 전달합니다. 예를 들어 다음과 같습니다.
    [root@ipaserver ~]# ipa migrate-ds --ca-cert-file=/etc/ipa/remote.crt ldaps://ldap.example.com:636


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

40장. 비 RHEL Linux 배포판의 FreeIPA에서 RHEL 7의 IdM으로 마이그레이션

RHEL이 아닌 Linux 배포에서 RHEL 7 서버의 IdM(Identity Management) 배포로 FreeIPA 배포를 마이그레이션하려면 먼저 새 RHEL 7 IdM 인증 기관(CA) 복제본을 기존 FreeIPA 환경에 추가하고 인증서 관련 역할을 전송한 다음 비 RHEL FreeIPA 서버를 중단해야 합니다.
중요
Convert2RHEL 툴을 사용하여 RHEL 7 IdM 서버로 RHEL FreeIPA 서버를 내부 변환을 수행하는 것은 지원되지 않습니다.

사전 요구 사항

  • RHEL FreeIPA 인증 기관(CA) 갱신 서버의 도메인 수준을 확인했습니다. 자세한 내용은 현재 도메인 수준 표시를 참조하십시오.
  • 새 CA 갱신 서버가 될 시스템에 RHEL 7.9를 설치했습니다.

절차

마이그레이션을 수행하려면 RHEL 6 서버 역할을 하는 비 RHEL FreeIPA CA 서버를 사용하여 Red Hat Enterprise Linux 6에서 버전 7로 Identity Management 마이그레이션 과 동일한 절차를 따르십시오.
  1. 원래 비 RHEL CA 갱신 서버가 FreeIPA 버전 3.1 이상을 실행하는 경우 ID 관리 스키마를 업데이트합니다. 설치된 FreeIPA 버전을 표시하려면 ipa --version 명령을 사용합니다.
  2. RHEL 7 서버를 구성하고 RHEL Linux 배포판의 현재 FreeIPA 환경에 IdM 복제본으로 추가합니다. 도메인의 도메인 수준이 0이면 RHEL 7 Replica 설치를 참조하십시오. 도메인 수준이 1인 경우 복제 생성에 설명된 단계를 따르십시오. Introduction.
  3. RHEL 7에서 CA 갱신 서버를 복제하고 RHEL이 아닌 서버의 CRL(인증서 취소 목록) 생성을 중지하고 CRL 요청을 RHEL 7 복제본으로 리디렉션합니다. 자세한 내용은 Red Hat Enterprise Linux 7 Server로 CA 서비스 전환을 참조하십시오.
  4. 원래 비 RHEL FreeIPA CA 갱신 서버를 중지하여 도메인 검색을 새 RHEL 7 서버로 강제 적용합니다. 자세한 내용은 Red Hat Enterprise Linux 6 Server 중지 를 참조하십시오.
  5. 다른 RHEL 7 시스템에 새 복제본을 설치하고 RHEL 이외의 서버를 해제합니다. 자세한 내용은 마스터 CA 서버를 마이그레이션한 후 다음 단계를 참조하십시오.
    중요
    Red Hat은 토폴로지에 하나의 주요 RHEL 버전인 IdM 복제본만 사용하는 것이 좋습니다. 따라서 이전 서버 해제를 지연하지 마십시오.

추가 리소스

부록 A. 문제 해결: 일반 지침

이 부록에서는 문제의 근본 원인을 확인하기 위한 일반적인 단계(예: 로그 및 서비스 상태를 쿼리하는 경우)에 대해 설명합니다.
참고
특정 문제 및 해당 솔루션 목록은 부록 B. 문제 해결: 특정 문제에 대한 해결책 를 참조하십시오.
문제가 발생했을 때 어떤 작업을 수행하셨습니까?
IdM의 특정 영역을 알고 있는 경우 다음 링크를 따르십시오.
이 가이드가 문제를 찾아서 해결하는 데 도움이 되지 않고 고객 사례를 제출하려는 경우 사례 보고서에서 이러한 문제 해결 절차를 사용하여 결정한 주목할 만한 오류 출력을 포함합니다. 또한 Red Hat 기술 지원 문의를 참조하십시오.

A.1. ipa utility 실행 시 실패 조사

기본 문제 해결

  1. 명령에 --verbose (-v) 옵션을 추가합니다. 그러면 디버그 정보가 표시됩니다.
  2. 명령에 -vv 옵션을 추가합니다. JSON 응답 및 요청이 표시됩니다.

고급 문제 해결

그림 A.1. “ipa cert-show 명령을 실행하는 아키텍처” 사용자가 IdM 명령줄 유틸리티를 사용할 때 상호 작용하는 구성 요소를 표시합니다. 이러한 구성 요소를 쿼리하면 문제가 발생한 위치와 이로 인해 무엇이 발생했는지 조사하는 데 도움이 될 수 있습니다.
  1. 다음 유틸리티를 사용하십시오.
    • 호스트: IdM 서버 또는 클라이언트의 DNS 확인을 확인
    • ping 을 실행하여 IdM 서버를 사용할 수 있는지 확인합니다.
    • IdM 서버에서 현재 방화벽 구성을 확인하는 iptables
    • 현재 시간을 확인하는 날짜
    • 다음에 나열된 대로 필요한 포트에 연결을 시도합니다. 2.1.6절. “포트 요구 사항”
    이러한 유틸리티 사용에 대한 자세한 내용은 도움말 페이지를 참조하십시오.
  2. kRB 5_TRACE 환경 변수를 /dev/stdout 파일로 설정하여 trace-logging 출력을 /dev/stdout 로 보냅니다.
    $ KRB5_TRACE=/dev/stdout ipa cert-find
    Kerberos KMS(키 배포 센터) 로그: /var/log/krb5kdc.log 를 검토합니다.
  3. Apache 오류 로그를 검토합니다.
    1. 서버에서 디버그 수준을 활성화합니다. /etc/ipa/server.conf 파일을 열고 debug=True 옵션을 [global] 섹션에 추가합니다.
    2. httpd 서비스를 다시 시작합니다.
      # systemctl restart httpd.service
    3. 다시 실패한 명령을 실행합니다.
    4. 서버에서 httpd 오류 로그를 검토합니다. /var/log/httpd/error_log.
    HTTP 요청 및 응답을 표시하려면 -vvv 옵션으로 명령을 실행합니다.
  4. Apache 액세스 로그 /var/log/httpd/access_log 를 검토합니다.
    Certificate System 구성 요소에 대한 로그를 검토합니다.
    • /var/log/pki/pki-ca-spawn.time_of_installation.log
    • /var/log/pki/pki-tomcat/ca/debug
    • /var/log/pki/pki-tomcat/ca/system
    • /var/log/pki/pki-tomcat/ca/selftests.log
    • # journalctl -u pki-tomcatd@pki-tomcat.service 명령을 사용하여 저널 로그를 검토합니다.
  5. Directory Server 액세스 로그( /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/access )를 검토합니다.

그림 A.1. ipa cert-show 명령을 실행하는 아키텍처

ipa cert-show 명령을 실행하는 아키텍처

관련 정보

A.2. kinit 인증 실패 조사

일반 문제 해결

  1. IdM 클라이언트에서 kinit 프로세스의 디버그 메시지를 표시합니다.
    $ KRB5_TRACE=/dev/stdout kinit admin
  2. 다음을 확인합니다.
    • 클라이언트 전달 레코드는 서버와 영향을 받는 클라이언트의 올바른 항목입니다.
      # host client_fully_qualified_domain_name
    • 서버 전달 레코드가 서버와 영향을 받는 클라이언트 모두 올바릅니다.
      # host server_fully_qualified_domain_name
      # host server_IP_address
      host server_IP_address 명령은 끝에 후행 점이 있는 정규화된 호스트 이름을 반환해야 합니다. 예를 들면 다음과 같습니다.
      server.example.com.
  3. 클라이언트에서 /etc/hosts 파일을 검토하고 다음을 확인합니다.
    • 파일의 모든 서버 항목이 올바른지
    • 모든 서버 항목에서 첫 번째 이름은 정규화된 도메인 이름입니다.
    /etc/hosts 파일” 참조하십시오.
  4. 2.1.5절. “호스트 이름 및 DNS 구성” 의 다른 조건을 충족하는지 확인하십시오.
  5. IdM 서버에서>-< 5kdcdirsrv 서비스가 실행 중인지 확인합니다.
    # systemctl status krb5kdc
    # systemctl status dirsrv.target
  6. Kerberos KMS(키 배포 센터) 로그: /var/log/krb5kdc.log 를 검토합니다.
  7. ScanSettings가 /etc/krb5.conf 파일에 하드 코딩되는 경우 (파일이 명시적으로 10.0.0.1 지시문을 설정하고 dns_lookup_kdc = false 설정을 사용하는 경우 각 마스터 서버에서 ipactl status 명령을 사용합니다. 명령을 통해 각 서버에서 KDC로 나열된 IdM 서비스의 상태를 확인합니다.
    # ipactl status
    Directory Service: RUNNING
    krb5kdc Service: RUNNING
    kadmin Service: RUNNING
    named Service: RUNNING
    httpd Service: RUNNING
    ipa-custodia Service: RUNNING
    ntpd Service: RUNNING
    pki-tomcatd Service: RUNNING
    ipa-otpd Service: RUNNING
    ipa-dnskeysyncd Service: RUNNING
    ipa: INFO: The ipactl command was successful

영역에 대한 오류 문제 해결 Cannot find#177 for realm

초기 인증 정보를 가져오는 동안 Cannot findECDHE for realm "EXAMPLE.COM" 이라는 오류와 함께 kinit 인증이 실패하면, servers에서 실행되고 있지 않거나 클라이언트가 DNS를 잘못 구성했음을 나타냅니다. 이 경우 다음 단계를 수행하십시오.
  1. /etc/krb5.conf 파일( dns_lookup_kdc = true 설정)에서 DNS 검색을 활성화하면 dig 유틸리티를 사용하여 다음 레코드를 확인할 수 있는지 확인합니다.
    $ dig -t TXT _kerberos.ipa.example.com
    $ dig -t SRV _kerberos._udp.ipa.example.com
    $ dig -t SRV _kerberos._tcp.ipa.example.com
    다음 예제에서는 위의 dig 명령 중 하나가 다음 출력과 함께 실패했습니다.
    ; <<>> DiG 9.11.0-P2-RedHat-9.11.0-6.P2.fc25 <<>> -t SRV _kerberos._tcp.ipa.server.example
    ;; global options: +cmd
    ;; connection timed out; no servers could be reached
    출력에서 named 서비스가 마스터 서버에서 실행되지 않았음을 나타냅니다.
  2. DNS 조회에 실패하면 A.6절. “DNS 문제 해결” 의 단계를 계속 진행합니다.

관련 정보

A.3. IdM 웹 UI 인증 오류 조사

  1. kinit 유틸리티를 사용하여 명령줄에서 인증할 수 있는지 확인합니다. 인증에 실패하는 경우 A.2절. “kinit 인증 실패 조사” 도 참조하십시오.
  2. 영향을 받는 서버의 httpddirsrv 서비스가 실행 중인지 확인합니다.
    # systemctl status httpd.service
    # systemctl status dirsrv@IPA-EXAMPLE-COM.service
  3. 관련 AVC(SELinux Access Vector Cache) 메시지가 /var/log/audit/audit.log 및 / var/log/ ECDHE 파일에 기록되지 않았는지 확인합니다.
    AVC 메시지 해결에 대한 자세한 내용은 Red Hat Knowledgebase의 CLI 기본 SELinux 문제 해결을 참조하십시오.
  4. 쿠키를 인증하는 브라우저에서 사용하도록 설정해야 합니다.
  5. IdM 서버와 인증 중인 시스템의 시간 차이가 최대 5분인지 확인합니다.
  6. Apache 오류 로그 /var/log/httpd/error_log 를 검토합니다.
  7. 인증 프로세스에 대한 상세 로깅을 활성화하여 문제를 진단할 수 있습니다. Firefox에서 자세한 로깅을 활성화하는 방법에 대한 지침은 시스템 수준 인증 가이드에서 Firefox Kerberos 구성 문제 해결을 참조하십시오.
인증서를 사용하여 로그인할 때 문제가 있는 경우:
  1. /etc/httpd/conf.d/nss.conf 파일에서 LogLevel 특성을 info 로 변경합니다.
  2. Apache 서버를 다시 시작하십시오.
    # systemctl restart httpd
  3. 인증서를 다시 사용하여 로그인해 보십시오.
  4. Apache 오류 로그 /var/log/httpd/error_log 를 검토합니다.
    로그는 mod_lookup_identity 모듈에서 기록한 메시지를 표시합니다. 여기에는 로그인 시도 중에 모듈이 사용자와 성공적으로 일치하는지에 대한 정보가 포함됩니다.

관련 정보

A.4. 스마트 카드 인증 오류 조사

  1. /etc/sssd/sssd.conf 파일을 열고 debug_level 옵션을 2 로 설정합니다.
  2. sssd_pam.logsssd_EXAMPLE.COM.log 파일을 검토합니다. 파일에 시간 초과 오류 메시지가 표시되면 B.4.4절. “시간 제한 오류 메시지와 함께 스마트 카드 인증 실패” 을 참조하십시오.

A.5. 서비스가 시작되지 않는 이유 조사

  1. 시작하지 못한 서비스의 로그를 검토합니다. C.2절. “ID 관리 로그 파일 및 디렉토리” 참조하십시오.
    예를 들어 Directory Server의 로그는 /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errors 에 있습니다.
  2. 서비스가 실행 중인 서버에 FQDN(정규화된 도메인 이름)이 있는지 확인합니다. “서버 호스트 이름 확인” 참조하십시오.
  3. /etc/hosts 파일에 서비스가 실행 중인 서버의 항목이 포함된 경우 정규화된 도메인 이름이 먼저 나열되어 있는지 확인합니다. /etc/hosts 파일” 참조하십시오.
  4. 2.1.5절. “호스트 이름 및 DNS 구성” 의 다른 조건을 충족하는지 확인하십시오.
  5. 서비스 인증에 사용되는 키탭에 포함된 키를 확인합니다. 예를 들어 dirsrv 서비스 티켓의 경우:
    # klist -kt /etc/dirsrv/ds.keytab
    Keytab name: FILE:/etc/dirsrv/ds.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       2 01/10/2017 14:54:39 ldap/server.example.com@EXAMPLE.COM
       2 01/10/2017 14:54:39 ldap/server.example.com@EXAMPLE.COM
       [... output truncated ...]
    1. 표시된 주체가 시스템의 FQDN과 일치하는지 확인합니다.
    2. 위에 있는 서비스 키 탭의 표시된 KVNO(키 버전)가 server 키 탭의 KVNO와 일치하는지 확인합니다. 서버 키탭을 표시하려면 다음을 수행합니다.
      $ kinit admin
      $ kvno ldap/server.example.com@EXAMPLE.COM
    3. 클라이언트의 정방향(A, AAAA 또는 둘 다) 및 역방향 레코드가 표시된 시스템 이름 및 서비스 주체와 일치하는지 확인합니다.
  6. 클라이언트의 정방향(A, AAAA 또는 둘 다) 및 역방향 레코드가 올바른지 확인합니다.
  7. 클라이언트와 서버의 시스템 시간 차이가 최대 5분인지 확인합니다.
  8. IdM 관리 서버 인증서가 만료된 후 서비스가 시작되지 않을 수 있습니다. 해당 경우의 원인인지 확인하려면 다음을 수행하십시오.
    1. getcert list 명령을 사용하여 certmonger 유틸리티에서 추적한 모든 인증서를 나열합니다.
    2. 출력에서 IdM 관리 인증서( ldaphttpd 서버 인증서를 찾습니다.
    3. status 라는 필드를 검사하고 만료합니다.
      # getcert list
      Number of certificates and requests being tracked: 8.
      [... output truncated ...]
      Request ID '20170421124617':
      	status: MONITORING
      	stuck: no
      	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IPA-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IPA-EXAMPLE-COM/pwdfile.txt'
      	certificate: type=NSSDB,location='/etc/dirsrv/slapd-IPA-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB'
      	CA: IPA
      	issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
      	subject: CN=ipa.example.com,O=IPA.EXAMPLE.COM
      	expires: 2019-04-22 12:46:17 UTC
      [... output truncated ...]
      Request ID '20170421130535':
      	status: MONITORING
      	stuck: no
      	key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
      	certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
      	CA: IPA
      	issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
      	subject: CN=ipa.example.com,O=IPA.EXAMPLE.COM
      	expires: 2019-04-22 13:05:35 UTC
      [... output truncated ...]
    인증서가 만료된 경우에도 서비스를 시작해야 하는 경우 26.5절. “IdM이 만료된 인증서로 시작하도록 허용” 을 참조하십시오.

A.6. DNS 문제 해결

  1. 대부분의 DNS 문제는 잘못된 설정으로 인해 발생합니다. 따라서 2.1.5절. “호스트 이름 및 DNS 구성” 의 조건을 충족하는지 확인하십시오.
  2. dig 유틸리티를 사용하여 DNS 서버의 응답을 확인합니다.
    # dig _ldap._tcp.ipa.example.com. SRV
    
    ; <<>> DiG 9.9.4-RedHat-9.9.4-48.el7 <<>> _ldap._tcp.ipa.example.com. SRV
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17851
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 5
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;_ldap._tcp.ipa.example.com. IN SRV
    
    ;; ANSWER SECTION:
    _ldap._tcp.ipa.example.com. 86400 IN SRV        0 100 389 ipaserver.ipa.example.com.
    
    ;; AUTHORITY SECTION:
    ipa.example.com.        86400 IN NS       ipaserver.ipa.example.com.
    
    ;; ADDITIONAL SECTION:
    ipaserver.ipa.example.com. 86400 IN A 192.0.21
    ipaserver.ipa.example.com 86400 IN AAAA 2001:db8::1
  3. host 유틸리티를 사용하여 DNS 이름 조회를 수행합니다.
    $ host server.ipa.example.com
    server.ipa.example.com. 86400 IN A 192.0.21
    server.ipa.example.com 86400 IN AAAA 2001:db8::1
  4. ipa dnszone-show 명령을 사용하여 LDAP에서 DNS 레코드를 검토합니다.
    $ ipa dnszone-show zone_name
    $ ipa dnsrecord-show zone_name record_name_in_the_zone
    IdM 툴을 사용하여 DNS 관리에 대한 자세한 내용은 33장. DNS 관리 을 참조하십시오.
  5. BIND를 다시 시작하여 LDAP로 강제로 다시 동기화합니다.
    $ systemctl restart named-pkcs11
  6. 필요한 DNS 레코드 목록을 가져옵니다.
    $ ipa dns-update-system-records --dry-run
    dig 유틸리티를 사용하여 표시된 레코드가 DNS에 있는지 확인합니다. Identity Management DNS를 사용하는 경우 ipa dns-update-system- recordss 명령을 사용하여 누락된 레코드를 업데이트합니다.

A.7. 복제 문제 해결

두 개 이상의 서버에서 복제를 테스트합니다( 4.6절. “새 복제 테스트”참조). 한 IdM 서버에서 변경한 사항이 다른 서버에 복제되지 않은 경우:
  1. 2.1.5절. “호스트 이름 및 DNS 구성” 의 조건을 충족하는지 확인하십시오.
  2. 두 서버가 서로의 정방향 및 역방향 DNS 레코드를 확인할 수 있는지 확인합니다.
    [root@server1 ~]# dig +short server2.example.com A
    [root@server1 ~]# dig +short server2.example.com AAAA
    [root@server1 ~]# dig +short -x server2_IPv4_or_IPv6_address
    [root@server2 ~]# dig +short server1.example.com A
    [root@server2 ~]# dig +short server1.example.com AAAA
    [root@server2 ~]# dig +short -x server1_IPv4_or_IPv6_address
  3. 두 서버의 시간 차이가 최대 5분인지 확인합니다.
  4. 두 서버에서 모두 Directory Server 오류 로그를 검토합니다. /var/log/dirsrv/slapd-SERVER-EXAMPLE-COM/errors.
  5. Kerberos와 관련된 오류가 표시되면 Directory Server keytab이 올바른지 확인하고 이를 사용하여 다른 서버 (이 예제의 server2)를 쿼리할 수 있는지 확인하십시오.
    [root@server1 ~]# kinit -kt /etc/dirsrv/ds.keytab ldap/server1.example.com
    [root@server1 ~]# klist
    [root@server1 ~]# ldapsearch -Y GSSAPI -h server1.example.com -b "" -s base
    [root@server1 ~]# ldapsearch -Y GSSAPI -h server2_FQDN. -b "" -s base

관련 정보

부록 B. 문제 해결: 특정 문제에 대한 해결책

문제 해결의 경우 다음 사항에 대한 조언을 참조하십시오.

B.1. ID 관리 서버

B.1.1. 외부 CA 설치 실패

ipa-server-install --external-ca 명령은 다음 오류와 함께 실패합니다.
ipa         : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/configuration_file' returned non-zero exit status 1
Configuration of CA failed
env|grep proxy 명령은 다음과 같은 변수를 표시합니다.
env|grep proxy
http_proxy=http://example.com:8080
ftp_proxy=http://example.com:8080
https_proxy=http://example.com:8080

이것이 의미하는 바:

*_proxy 환경 변수를 사용하면 서버가 설치되지 않습니다.

문제를 해결하려면 다음을 수행합니다.

  1. 다음 쉘 스크립트를 사용하여 *_proxy 환경 변수를 설정 해제합니다.
    # for i in ftp http https; do unset ${i}_proxy; done
  2. pkidestroy 유틸리티를 실행하여 실패한 CA 하위 시스템 설치를 제거합니다.
    # pkidestroy -s CA -i pki-tomcat; rm -rf /var/log/pki/pki-tomcat  /etc/sysconfig/pki-tomcat  /etc/sysconfig/pki/tomcat/pki-tomcat  /var/lib/pki/pki-tomcat  /etc/pki/pki-tomcat /root/ipa.csr
  3. 실패한 IdM 서버 설치를 제거하십시오.
    # ipa-server-install --uninstall
  4. ipa-server-install --external-ca 를 실행합니다.

B.1.2. Daemon Fails to Start

통합된 DNS가 있는 IdM 서버를 설치한 후 named-pkcs11 이 시작되지 않습니다. /var/log/ ECDHE 파일에는 named-pkcs11 서비스 및 ldap.so 라이브러리와 관련된 오류 메시지가 포함됩니다.
ipaserver named[6886]: failed to dynamically load driver 'ldap.so': libldap-2.4.so.2: cannot open shared object file: No such file or directory

이것이 의미하는 바:

bind-chroot 패키지가 설치되고 named-pkcs11 서비스가 시작되지 않습니다.

문제를 해결하려면 다음을 수행합니다.

  1. bind-chroot 패키지를 제거합니다.
    # yum remove bind-chroot
  2. IdM 서버를 다시 시작합니다.
    # ipactl restart

B.1.3. IPv6 비활성화로 시스템에 서버 오류 설치

IPv6이 비활성화된 시스템에 IdM 서버를 설치하려고 하면 설치 프로세스 중에 다음과 같은 오류가 발생합니다.
CRITICAL Failed to restart the directory server
Command '/bin/systemctl restart dirsrv@EXAMPLE.service' returned non-zero exit status 1

이것이 의미하는 바:

서버를 설치하고 실행하려면 네트워크에서 IPv6를 활성화해야 합니다. 2.1.3절. “시스템 요구 사항” 참조하십시오.

문제를 해결하려면 다음을 수행합니다.

IPv6는 Red Hat Enterprise Linux 7 시스템에서 기본적으로 활성화되어 있습니다.

B.2. Identity Management 복제

이 가이드에서는 Red Hat Enterprise Linux의 ID 관리의 일반적인 복제 문제에 대해 설명합니다.
추가 리소스:

B.2.1. 새 복제본 Fails에 AD 사용자 인증

ID 관리 - Active Directory 신뢰 설정에 새 복제본을 설치한 후 IdM 복제본에 대해 AD(Active Directory) 사용자를 인증하려고 하면 실패합니다.

이것이 의미하는 바:

복제본은 신뢰 컨트롤러와 신뢰 에이전트가 아닙니다. 이 때문에 AD 신뢰에서 정보를 제공할 수 없습니다.

문제를 해결하려면 다음을 수행합니다.

복제본을 신뢰 에이전트로 구성합니다. Windows 통합 가이드에서 신뢰 컨트롤러 및 신뢰 에이전트 를 참조하십시오.

B.2.2. 디렉터리 서버 로그에서 SASL, GSS-API 및 Kerberos 오류를 사용한 복제 시작

복제본이 시작되면 일련의 SASL 바인드 오류가 Directory Server (DS) 로그에 기록됩니다. 오류에서는 인증 정보 캐시를 찾을 수 없기 때문에 GSS-API 연결에 실패했습니다.
slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ...
또한 서버에서 호스트 주체의 Kerberos 자격 증명을 얻을 수 없다는 다른 메시지가 표시될 수 있습니다.
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)

이것이 의미하는 바:

IdM은 Kerberos 연결에 GSS-API를 사용합니다. DS 인스턴스는 Kerberos 자격 증명 캐시를 메모리에 유지합니다. IdM 복제본이 중지될 때와 같이 DS 프로세스가 종료되면 자격 증명 캐시가 삭제됩니다.
복제본이 다시 시작되면 KDC 서버가 시작되기 전에 DS가 시작됩니다. 이 시작 순서로 인해 DS가 시작되면 Kerberos 자격 증명이 아직 자격 증명 캐시에 저장되지 않으므로 오류가 발생합니다.
초기 실패 후 DS는 KDC가 시작된 후 GSS-API 연결을 다시 설정하려고 시도합니다. 이 두 번째 시도는 성공적으로 수행되며 복제본이 예상대로 작동하는지 확인합니다.
GSS-API 연결이 성공적으로 설정되고 복제본이 예상대로 작동하는 한 설명된 시작 오류는 무시할 수 있습니다. 다음 메시지는 연결에 성공했음을 보여줍니다.
Replication bind with GSSAPI auth resumed

B.2.3. DNS 전달 레코드가 역방향 주소와 일치하지 않음

새 복제본을 구성할 때 일련의 인증서 오류로 인해 설치에 실패하고 DNS 전달 레코드가 역방향 주소와 일치하지 않음을 나타내는 DNS 오류가 발생합니다.
ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer
ipa: DEBUG: cert valid True for "CN=replica.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = 192.0.2.2:9444
Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)

...

ipa: DEBUG: Created connection context.ldap2_21534032
ipa: DEBUG: Destroyed connection context.ldap2_21534032
The DNS forward record replica.example.com. does not match the reverse address replica.example.org

이것이 의미하는 바:

단일 PTR 레코드에 여러 호스트 이름이 사용됩니다. DNS 표준은 이러한 구성을 허용하지만 IdM 복제본 설치에 실패합니다.

문제를 해결하려면 다음을 수행합니다.

“정방향 및 역방향 DNS 구성 확인” 에 설명된 대로 DNS 구성을 확인합니다.

B.2.4. 일련 번호를 찾을 수 없음

참고
이 솔루션은 도메인 수준 0 에 적용됩니다. 자세한 내용은 7장. 도메인 수준 표시 및 승격 을 참조하십시오.
인증서 일련 번호를 찾을 수 없다는 오류가 복제된 서버에 표시됩니다.
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)

이것이 의미하는 바:

두 복제본 간 인증서 복제 연결이 제거되었지만 데이터 복제 연결은 아직 진행 중입니다. 두 복제본 모두 여전히 인증서를 발행하지만 인증서에 대한 정보는 더 이상 복제되지 않습니다.
예제 상황:
  1. Replication A에서 인증서를 호스트에 발행합니다.
  2. 복제본에 인증서 복제 연결이 설정되어 있지 않으므로 인증서가 복제본 B에 복제되지 않습니다.
  3. 사용자는 복제본 B를 사용하여 호스트를 관리하려고 시도합니다.
  4. replica B는 호스트의 인증서 일련 번호를 확인할 수 없는 오류를 반환합니다. 복제본 B에는 데이터 디렉터리에 호스트에 대한 정보가 있지만 인증서 디렉터리에 호스트 인증서가 없기 때문입니다.

문제를 해결하려면 다음을 수행합니다.

  1. ipa-csreplica-manage connect 명령을 사용하여 두 복제본 간에 인증서 서버 복제를 활성화합니다. D.3.3절. “복제 계약 생성 및 제거” 참조하십시오.
  2. 다른 복제본에서 복제본 중 하나를 다시 초기화하여 동기화합니다. D.3.5절. “복제 다시 초기화” 참조하십시오.
    주의
    다시 초기화된 복제본의 데이터를 다른 복제본의 데이터로 재초기화합니다. 일부 정보가 손실될 수 있습니다.

B.2.5. 복제 업데이트 벡터(RUV) 오류 정리

참고
이 솔루션은 도메인 수준 0 에 적용됩니다. 자세한 내용은 7장. 도메인 수준 표시 및 승격 을 참조하십시오.
IdM 토폴로지에서 복제본이 제거되면 더 이상 사용되지 않는 RUV 레코드가 나머지 하나 이상의 복제본에 표시됩니다.
가능한 원인:
  • “복제 계약 제거” 에 설명된 대로 복제 계약을 제대로 제거하지 않고 복제본이 제거되었습니다.
  • 다른 복제본이 오프라인 상태였을 때 복제본이 제거되었습니다.

이것이 의미하는 바:

다른 복제본은 여전히 제거된 복제본에서 업데이트를 수신할 것으로 예상됩니다.
참고
복제를 제거하는 올바른 절차는 D.3.6절. “복제 제거” 에 설명되어 있습니다.

문제를 해결하려면 다음을 수행합니다.

업데이트를 수신할 복제본에서 RUV 레코드를 정리합니다.
  1. ipa-replica-manage list-ruv 명령을 사용하여 더 이상 사용되지 않는 RUV에 대한 세부 정보를 나열합니다. 명령은 복제본 ID를 표시합니다.
    # ipa-replica-manage list-ruv
    server1.example.com:389: 6
    server2.example.com:389: 5
    server3.example.com:389: 4
    server4.example.com:389: 12
  2. ipa-replica-manage clean-ruv replica_ID 명령을 사용하여 손상된 RUV를 지웁니다. 명령은 지정된 복제본과 연결된 모든 RUV를 제거합니다.
    더 이상 사용되지 않는 RUV를 사용하여 모든 복제본에 대해 명령을 반복합니다. 예를 들어 다음과 같습니다.
    # ipa-replica-manage clean-ruv 6
    # ipa-replica-manage clean-ruv 5
    # ipa-replica-manage clean-ruv 4
    # ipa-replica-manage clean-ruv 12
    주의
    ipa-replica-manage clean-ruv 를 사용할 때 매우 주의를 기울입니다. 유효한 복제본 ID에 대해 명령을 실행하면 복제 데이터베이스에서 해당 복제본과 연결된 모든 데이터가 손상됩니다.
    이 경우 D.3.5절. “복제 다시 초기화” 에 설명된 대로 다른 복제본에서 복제본을 다시 초기화합니다.
  3. ipa-replica-manage list-ruv 를 다시 실행합니다.
    • 명령이 손상된 RUV를 더 이상 표시하지 않으면 레코드가 성공적으로 정리되었습니다.
    • 명령에서 손상된 RUV를 계속 표시하는 경우 이 작업을 사용하여 수동으로 지웁니다.
      dn: cn=clean replica_ID, cn=cleanallruv, cn=tasks, cn=config
      objectclass: extensibleObject
      replica-base-dn: dc=example,dc=com
      replica-id: replica_ID
      replica-force-cleaning: no
      cn: clean replica_ID
RUV를 정리할 복제본이 확실하지 않은 경우 다음을 수행하십시오.
  1. 모든 서버에서 활성 복제본 ID를 검색합니다. 수정되지 않고 신뢰할 수 있는 복제 ID 목록을 만듭니다.
    유효한 복제본의 ID를 찾으려면 토폴로지의 모든 노드에 대해 이 LDAP 쿼리를 실행합니다.
    # ldapsearch -p 389 -h IdM_node -D "cn=directory manager" -W -b "cn=config" "(objectclass=nsds5replica)" nsDS5ReplicaId
  2. 모든 서버에서 ipa-replica-manage list-ruv 를 실행합니다. 손상되지 않은 복제본 ID 목록에 없는 모든 복제본 ID를 확인합니다.
  3. 손상된 모든 복제본 ID에 대해 ipa-replica-manage clean-ruv replica_ID 를 실행합니다.

B.2.6. 손실된 CA 서버 복구

참고
이 솔루션은 도메인 수준 0 에 적용됩니다. 자세한 내용은 7장. 도메인 수준 표시 및 승격 을 참조하십시오.
CA가 설치된 서버가 하나뿐이었습니다. 이 서버가 실패하고 이제 손실됩니다.

이것이 의미하는 바:

IdM 도메인의 CA 구성을 더 이상 사용할 수 없습니다.

문제를 해결하려면 다음을 수행합니다.

원래 CA 서버의 백업이 있는 경우 서버를 복원하고 복제에 CA를 설치할 수 있습니다.
  1. 백업에서 CA 서버를 복구합니다. 자세한 내용은 9.2절. “백업 복원” 을 참조하십시오.
    그러면 복제본에서 CA 서버를 사용할 수 있습니다.
  2. 복제 충돌을 방지하려면 초기 서버와 복제본 간 복제 계약을 삭제합니다. D.3.3절. “복제 계약 생성 및 제거” 참조하십시오.
  3. 복제에 CA를 설치합니다. 6.5.2절. “마스터 CA 서버로 복제 승격” 참조하십시오.
  4. 원래 CA 서버를 폐기합니다. D.3.6절. “복제 제거” 참조하십시오.
원래 CA 서버의 백업이 없는 경우 서버가 실패하면 CA 구성이 손실되어 복구할 수 없습니다.

B.3. Identity Management 클라이언트

이 섹션에서는 Red Hat Enterprise Linux에서 IdM의 일반적인 클라이언트 문제에 대해 설명합니다.
추가 리소스:

B.3.1. 클라이언트는 외부 DNS를 사용할 때 역방향 조회를 해결할 수 없습니다.

외부 DNS 서버는 IdM 서버의 잘못된 호스트 이름을 반환합니다. IdM 서버와 관련된 다음 오류가 Kerberos 데이터베이스에 표시됩니다.
Jun 30 11:11:48 server1 krb5kdc[1279](info): AS_REQ (4 etypes {18 17 16 23}) 192.0.2.1: NEEDED_PREAUTH: admin EXAMPLE COM for krbtgt/EXAMPLE COM EXAMPLE COM, Additional pre-authentication required
Jun 30 11:11:48 server1 krb5kdc[1279](info): AS_REQ (4 etypes {18 17 16 23}) 192.0.2.1: ISSUE: authtime 1309425108, etypes {rep=18 tkt=18 ses=18}, admin EXAMPLE COM for krbtgt/EXAMPLE COM EXAMPLE COM
Jun 30 11:11:49 server1 krb5kdc[1279](info): TGS_REQ (4 etypes {18 17 16 23}) 192.0.2.1: UNKNOWN_SERVER: authtime 0,  admin EXAMPLE COM for HTTP/server1.wrong.example.com@EXAMPLE.COM, Server not found in Kerberos database

이것이 의미하는 바:

외부 DNS 이름 서버에서 IdM 서버의 잘못된 호스트 이름을 반환하거나 답변을 전혀 반환하지 않습니다.

문제를 해결하려면 다음을 수행합니다.

  1. DNS 구성을 확인하고 IdM에서 사용하는 DNS 도메인이 올바르게 위임되었는지 확인합니다. 자세한 내용은 2.1.5절. “호스트 이름 및 DNS 구성” 을 참조하십시오.
  2. 역방향(PTR) DNS 레코드 설정을 확인합니다. 자세한 내용은 33장. DNS 관리 을 참조하십시오.

B.3.2. 클라이언트가 DNS 영역에 추가되지 않음

ipa-client-install 유틸리티를 실행할 때 nsupdate 유틸리티가 DNS 영역에 클라이언트를 추가하지 못합니다.

이것이 의미하는 바:

DNS 구성이 잘못되었습니다.

문제를 해결하려면 다음을 수행합니다.

  1. 상위 영역에서 IdM로 DNS 위임에 대한 구성을 확인합니다. 자세한 내용은 2.1.5절. “호스트 이름 및 DNS 구성” 을 참조하십시오.
  2. IdM 영역에서 동적 업데이트가 허용되는지 확인합니다. 자세한 내용은 33.5.1절. “동적 DNS 업데이트 활성화” 을 참조하십시오.
IdM에서 DNS 관리에 대한 자세한 내용은 33.7절. “역방향 DNS 영역 관리” 을 참조하십시오. Red Hat Enterprise Linux에서 DNS 관리에 대한 자세한 내용은 네트워킹 가이드의 영역 파일 편집 을 참조하십시오.

B.3.3. 클라이언트 연결 문제

사용자는 시스템에 로그인할 수 없습니다. getent passwd admin 명령과 같은 사용자 및 그룹 정보에 액세스하려고 하면 실패합니다.

이것이 의미하는 바:

클라이언트 인증 문제는 종종 SSSD(시스템 보안 서비스 데몬) 서비스에 문제가 있음을 나타냅니다.

문제를 해결하려면 다음을 수행합니다.

/var/log/sssd/ 디렉터리에서 SSSD 로그를 검사합니다. 디렉터리에는 sssd_example.com.log와 같은 DNS 도메인의 로그 파일이 포함됩니다.
로그에 충분한 정보가 없으면 로그 수준을 높입니다.
  1. /etc/sssd/sssd.conf 파일에서 [domain/example.com] 섹션을 찾습니다. debug_level 옵션을 조정하여 자세한 정보를 로그에 기록합니다.
    debug_level = 9
  2. sssd 서비스를 다시 시작합니다.
    # systemctl start sssd
  3. sssd_example.com.log 를 다시 검사합니다. 이제 파일에 더 많은 오류 메시지가 포함됩니다.

B.4. 로그인 및 인증 문제

B.4.1. ipa 명령을 실행할 때 Kerberos GSS 실패

서버를 설치한 직후 ipa 명령을 실행하려고 할 때 Kerberos 오류가 발생합니다. 예를 들어 다음과 같습니다.
ipa: ERROR: Kerberos error: ('Unspecified GSS failure.  Minor code may provide more information', 851968)/('Decrypt integrity check failed', -1765328353)

이것이 의미하는 바:

DNS가 올바르게 구성되지 않았습니다.

문제를 해결하려면 다음을 수행합니다.

DNS 구성을 확인합니다.

B.4.2. GSS-API를 사용할 때 SSH 연결 실패

사용자는 SSH를 사용하여 IdM 시스템에 로그인할 수 없습니다.

이것이 의미하는 바:

SSH가 GSS-API를 보안 방법으로 사용하여 IdM 리소스에 연결을 시도하는 경우 GSS-API는 먼저 DNS 레코드를 확인합니다. SSH 오류는 종종 잘못된 역방향 DNS 항목으로 인해 발생합니다. 잘못된 레코드는 SSH가 IdM 리소스를 찾지 못하게 합니다.

문제를 해결하려면 다음을 수행합니다.

2.1.5절. “호스트 이름 및 DNS 구성” 에 설명된 대로 DNS 구성을 확인합니다.
임시 해결 방법으로 SSH 구성에서 역방향 DNS 조회를 비활성화할 수도 있습니다. 이렇게 하려면 /etc/ssh/ssh_config 파일에 GSSAPITrustDNSno 로 설정합니다. 역방향 DNS 레코드를 사용하는 대신 SSH는 지정된 사용자 이름을 GSS-API에 직접 전달합니다.

B.4.3. OTP 토큰이 동기화되지 않음

토큰이 감소되어 OTP를 사용한 인증이 실패합니다.

문제를 해결하려면 다음을 수행합니다.

토큰 재동기화. 모든 사용자는 토큰 유형 및 사용자가 토큰 설정을 수정할 권한이 있는지 여부에 관계없이 토큰을 다시 동기화할 수 있습니다.
  1. IdM 웹 UI에서 다음을 수행합니다. 로그인 페이지에서 Sync OTP Token 을 클릭합니다.

    그림 B.1. OTP 토큰 동기화

    OTP 토큰 동기화
    명령줄에서 다음을 수행합니다. ipa otptoken-sync 명령을 실행합니다.
  2. 토큰을 다시 동기화하는 데 필요한 정보를 제공합니다. 예를 들어 IdM은 표준 암호와 토큰이 생성한 두 개의 후속 토큰 코드를 제공하도록 요청합니다.
    참고
    표준 암호가 만료된 경우에도 재동기화가 작동합니다. 토큰이 만료된 암호를 사용하여 다시 동기화된 후 IdM에 로그인하여 시스템에서 암호를 변경하라는 메시지를 표시하도록 합니다.

B.4.4. 시간 제한 오류 메시지와 함께 스마트 카드 인증 실패

sssd_pam.logsssd_EXAMPLE.COM.log 파일에는 다음과 같은 시간 초과 오류 메시지가 포함되어 있습니다.
Wed Jun 14 18:24:03 2017) [sssd[pam]] [child_handler_setup] (0x2000):
Setting up signal handler up for pid [12370]
(Wed Jun 14 18:24:03 2017) [sssd[pam]] [child_handler_setup] (0x2000): Signal
handler set up for pid [12370]
(Wed Jun 14 18:24:08 2017) [sssd[pam]] [pam_initgr_cache_remove] (0x2000):
[idmeng] removed from PAM initgroup cache
(Wed Jun 14 18:24:13 2017) [sssd[pam]] [p11_child_timeout] (0x0020): Timeout
reached for p11_child.
(Wed Jun 14 18:24:13 2017) [sssd[pam]] [pam_forwarder_cert_cb] (0x0040):
get_cert request failed.
(Wed Jun 14 18:24:13 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called
with result [4]: System error.

이것이 의미하는 바:

전달된 스마트 카드 리더 또는 OCSSP(Online Certificate Status Protocol)를 사용하는 경우 사용자가 스마트 카드로 인증할 수 있도록 특정 기본값을 조정해야 할 수 있습니다.

문제를 해결하려면 다음을 수행합니다.

사용자 인증을 원하는 서버와 클라이언트의 경우 /etc/sssd/sssd.conf 파일에서 이러한 변경을 수행합니다.
  1. [pam] 섹션에서 p11_child_timeout 값을 60초로 늘립니다.
  2. [domain/EXAMPLE.COM] 섹션에서 CloudEvent 5_auth_timeout 값을 60초로 늘립니다.
  3. 인증서에서 OCSP를 사용하는 경우 OCSP 서버에 연결할 수 있는지 확인합니다. OCSP 서버에 직접 연결할 수 없는 경우 /etc/sssd/sssd.conf 에 다음 옵션을 추가하여 OCSP 서버를 구성합니다.
    certificate_verification = ocsp_default_responder=http://ocsp.proxy.url,
    ocsp_default_responder_signing_cert=nickname
    /etc/pki/nssdb/ 디렉터리에 있는 OCSP 서명 인증서의 별 이름으로 닉네임을 바꿉니다.
    이러한 옵션에 대한 자세한 내용은 sssd.conf(5) 도움말 페이지를 참조하십시오.
  4. SSSD를 다시 시작:
    # systemctl restart sssd.service

B.5. 자격 증명 모음

B.5.1. 사용자가 해당 Vault Due에 액세스 할 수 없습니다. '추가' 권한

사용자는 자신의 사용자 자격 증명 모음에 액세스하거나 새 사용자 자격 증명 모음을 추가할 수 없습니다. 다음과 같은 오류 메시지가 표시됩니다.
ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the entry 'cn=testvault,cn=user,cn=users,cn=vaults,cn=kra,dc=example,dc=com'.

이것이 의미하는 바:

사용자의 vault 컨테이너는 다른 사용자가 소유합니다. 일반적으로 이 상황은 admin 과 같은 다른 사용자가 첫 번째 사용자에 대한 첫 번째 사용자 자격 증명 모음을 생성한 후에 발생합니다. 첫 번째 사용자는 자신의 자격 증명 모음 컨테이너의 자격 증명 모음에 액세스할 수 없습니다.

문제를 해결하려면 다음을 수행합니다.

의도한 사용자를 vault 컨테이너의 소유자로 추가합니다.
  1. admin 으로 로그인합니다.
    $ kinit admin
  2. 사용자를 컨테이너 소유자로 추가합니다.
    $ ipa vaultcontainer-add-owner --user=user --users=user
      Owner users: admin, user
      Vault user: user
    ------------------------
    Number of owners added 1
    ------------------------
    
    이제 adminuser 모두 컨테이너의 소유자이기 때문에 사용자의 자격 증명 모음 컨테이너에 액세스할 수 있습니다.
  3. 선택 사항입니다. 사용자가 이제 새 사용자 자격 증명 모음을 생성할 수 있는지 확인합니다.
    $ kinit user
    $ ipa vault-add testvault2
    ------------------------
    Added vault "testvault2"
    ------------------------

추가 리소스

부록 C. ID 관리 파일 및 로그 참조

C.1. ID 관리 구성 파일 및 디렉토리

표 C.1. IdM 서버 및 클라이언트 구성 파일 및 디렉토리

디렉토리 또는 파일 Description
/etc/ipa/ 기본 IdM 구성 디렉터리입니다.
/etc/ipa/default.conf IdM의 기본 설정 파일입니다. 서버 및 클라이언트가 시작할 때 및 사용자가 ipa 유틸리티를 사용할 때 참조됩니다.
/etc/ipa/server.conf
선택적 구성 파일 은 기본적으로 존재하지 않습니다. IdM 서버가 시작될 때 참조됩니다.
파일이 존재하는 경우 /etc/ipa/default.conf 보다 우선합니다.
/etc/ipa/cli.conf
선택적 구성 파일 은 기본적으로 존재하지 않습니다. ipa 유틸리티를 사용할 때 참조됩니다.
파일이 존재하는 경우 /etc/ipa/default.conf 보다 우선합니다.
/etc/ipa/ca.crt IdM 서버의 CA에서 발급한 CA 인증서입니다.
~/.ipa/
사용자가 IdM 명령을 처음 실행할 때 로컬 시스템에서 생성된 사용자별 IdM 디렉터리입니다.
사용자는 ~./ipa/ 에 사용자별 default.conf,server.conf 또는 cli.conf 파일을 생성하여 개별 구성 덮어쓰기를 설정할 수 있습니다.
/etc/sssd/sssd.conf IdM 도메인 및 SSSD에서 사용하는 IdM 서비스 구성.
/usr/share/sssd/sssd.api.d/sssd-ipa.conf IdM 관련 SSSD 옵션 및 해당 값의 스키마.
/etc/gssproxy/ GSS-Proxy 프로토콜의 구성을 위한 디렉토리입니다. 디렉터리에는 각 GSS-API 서비스 및 일반적인 /etc/gssproxy/gssproxy.conf 파일에 대한 파일이 포함되어 있습니다.
/etc/certmonger/certmonger.conf 이 구성 파일에는 인증서가 임박한 만료를 모니터링하는 certmonger 데몬의 기본 설정이 포함되어 있습니다.
/etc/custodia/custodia.conf IdM 애플리케이션의 시크릿을 관리하는 Custodia 서비스의 구성 파일입니다.

표 C.2. 시스템 서비스 파일 및 디렉토리

디렉토리 또는 파일 Description
/etc/sysconfig/ systemd- 특정 파일

표 C.3. 웹 UI 파일 및 디렉토리

디렉토리 또는 파일 Description
/etc/ipa/html/ IdM 웹 UI에서 사용하는 HTML 파일에 대한 심볼릭 링크입니다.
/etc/httpd/conf.d/ipa.conf 웹 UI 애플리케이션에 Apache 호스트에서 사용하는 구성 파일입니다.
/etc/httpd/conf.d/ipa-rewrite.conf
/etc/httpd/conf/ipa.keytab 웹 서버에서 사용하는 키탭 파일.
/usr/share/ipa/ 웹 UI에서 사용하는 모든 HTML 파일, 스크립트 및 스타일시트에 대한 디렉터리입니다.
/usr/share/ipa/ipa.conf  
/usr/share/ipa/updates/ IdM에 대한 LDAP 데이터, 구성 및 스키마 업데이트를 포함합니다.
/usr/share/ipa/html/ 웹 UI에서 사용하는 HTML 파일, JavaScript 파일 및 스타일시트를 포함합니다.
/usr/share/ipa/migration/ 마이그레이션 모드에서 IdM 서버를 실행하는 데 사용되는 HTML 페이지, 스타일시트, Python 스크립트가 포함되어 있습니다.
/usr/share/ipa/ui/ UI에서 IdM 작업을 수행하는 데 사용하는 스크립트가 포함되어 있습니다.
/etc/httpd/conf.d/ipa-pki-proxy.conf web-server-to-Certificate-System 브리징을 위한 구성 파일.

표 C.4. Kerberos 파일 및 디렉토리

디렉토리 또는 파일 Description
/etc/krb5.conf Kerberos 서비스 구성 파일.
/var/lib/sss/pubconf/krb5.include.d/ Kerberos 클라이언트 구성에 대한 IdM별 재정의 포함.

표 C.5. 디렉터리 서버 파일 및 디렉토리

디렉토리 또는 파일 Description
/var/lib/dirsrv/slapd-REALM_NAME/ IdM 서버에서 사용하는 Directory Server 인스턴스와 연결된 데이터베이스입니다.
/etc/sysconfig/dirsrv dirsrv systemd 서비스의 IdM별 구성입니다.
/etc/dirsrv/slapd-REALM_NAME/ IdM 서버에서 사용하는 Directory Server 인스턴스와 연결된 구성 및 스키마 파일입니다.

표 C.6. 인증서 시스템 파일 및 디렉토리

디렉토리 또는 파일 Description
/etc/pki/pki-tomcat/ca/ IdM CA 인스턴스의 기본 디렉터리입니다.
/var/lib/pki/pki-tomcat/conf/ca/CS.cfg IdM CA 인스턴스의 기본 구성 파일입니다.

표 C.7. 캐시 파일 및 디렉토리

디렉토리 또는 파일 Description
~/.cache/ipa/ IdM 클라이언트의 서버별 API 스키마를 포함합니다. IdM은 클라이언트의 API 스키마를 1시간 동안 캐시합니다.

표 C.8. 시스템 백업 파일 및 디렉토리

디렉토리 또는 파일 Description
/var/lib/ipa/sysrestore/ IdM 서버를 설치할 때 재구성된 시스템 파일 및 스크립트의 백업이 포함되어 있습니다. NSS, Kerberos(여기서 5 .confkdc.conf )의 원본 .conf 파일, NTP가 포함됩니다.
/var/lib/ipa-client/sysrestore/ IdM 클라이언트 설치 시 재구성된 시스템 파일 및 스크립트의 백업이 포함되어 있습니다. 일반적으로 SSSD 인증 서비스의 sssd.conf 파일입니다.

C.2. ID 관리 로그 파일 및 디렉토리

표 C.9. IdM 서버 및 클라이언트 로그 파일 및 디렉토리

디렉토리 또는 파일 Description
/var/log/ipaserver-install.log IdM 서버의 설치 로그입니다.
/var/log/ipareplica-install.log IdM 복제본의 설치 로그입니다.
/var/log/ipaclient-install.log IdM 클라이언트의 설치 로그입니다.
/var/log/sssd/ SSSD의 로그 파일.
~/.ipa/log/cli.log ipa 유틸리티에서 XML-RPC 호출 및 응답에서 반환된 오류에 대한 로그 파일입니다. 툴을 실행하는 시스템 사용자의 홈 디렉터리에 IdM 사용자와 다른 사용자 이름이 생성될 수 있습니다.
/etc/logrotate.d/ DNS, SSSD, Apache, Tomcat, Kerberos에 대한 로그 순환 정책.
/etc/pki/pki-tomcat/logging.properties 이 링크는 /usr/share/pki/server/conf/logging.properties 에서 기본 인증 기관 로깅 구성을 가리킵니다.

표 C.10. Apache Server 로그 파일

디렉토리 또는 파일 Description
/var/log/httpd/ Apache 웹 서버의 로그 파일.
/var/log/httpd/access_log Apache 서버에 대한 표준 액세스 및 오류 로그. IdM 웹 UI 및 XML-RPC 명령줄 인터페이스에서 Apache를 사용하므로 IdM 관련 메시지는 Apache 메시지와 함께 기록됩니다.
/var/log/httpd/error_log
자세한 내용은 Apache 문서 의 로그 파일을 참조하십시오.

표 C.11. 인증서 시스템 로그 파일

디렉토리 또는 파일 Description
/var/log/pki/pki-ca-spawn.time_of_installation.log IdM CA의 설치 로그입니다.
/var/log/pki/pki-kra-spawn.time_of_installation.log IdM KRA의 설치 로그입니다.
/var/log/pki/pki-tomcat/ PKI 작업 로그의 최상위 디렉토리. CA 및 KRA 로그가 포함되어 있습니다.
/var/log/pki/pki-tomcat/ca/ 인증서 작업과 관련된 로그가 있는 디렉터리입니다. IdM에서 이러한 로그는 인증서를 사용하는 서비스 주체, 호스트 및 기타 엔티티에 사용됩니다.
/var/log/pki/pki-tomcat/kra KRA와 관련된 로그가 있는 디렉토리.
/var/log/messages 다른 시스템 메시지 중 인증서 오류 메시지가 포함됩니다.
자세한 내용은 Red Hat Certificate System 관리 가이드에서 하위 시스템 로그 구성 을 참조하십시오.

표 C.12. 디렉터리 서버 로그 파일

디렉토리 또는 파일 Description
/var/log/dirsrv/slapd-REALM_NAME/
IdM 서버에서 사용하는 디렉터리 서버 인스턴스와 연결된 로그 파일입니다. 여기에 기록된 대부분의 운영 데이터는 서버 복제 상호 작용과 관련이 있습니다.
/var/log/dirsrv/slapd-REALM_NAME/access
도메인 디렉터리 서버 인스턴스에 대해 시도한 액세스 및 작업에 대한 자세한 정보를 포함합니다.
/var/log/dirsrv/slapd-REALM_NAME/errors
/var/log/dirsrv/slapd-REALM_NAME/audit Directory Server 구성에서 감사가 활성화될 때 모든 Directory Server 작업의 감사 추적을 포함합니다.
자세한 내용은 Red Hat Directory Server 설명서의 서버 및 데이터베이스 활동 및 로그 파일 참조 모니터링 을 참조하십시오.

표 C.13. Kerberos 로그 파일

디렉토리 또는 파일 Description
/var/log/krb5kdc.log Kerberos KDC 서버의 기본 로그 파일.
/var/log/kadmind.log Kerberos 관리 서버의 기본 로그 파일.
이러한 파일의 위치는>-< 5.conf 파일에 구성되어 있습니다. 일부 시스템에서는 다를 수 있습니다.

표 C.14. DNS 로그 파일

디렉토리 또는 파일 Description
/var/log/messages
다른 시스템 메시지 중 DNS 오류 메시지를 포함합니다.
이 파일의 DNS 로깅은 기본적으로 활성화되어 있지 않습니다. 활성화하려면 # /usr/sbin/rndc querylog 명령을 실행합니다. 로깅을 비활성화하려면 명령을 다시 실행합니다.

표 C.15. custodia 로그 파일

디렉토리 또는 파일 Description
/var/log/custodia/ Custodia 서비스의 로그 파일 디렉토리.

추가 리소스

  • journalctl 유틸리티 를 사용하는 방법에 대한 자세한 내용은 시스템 관리자 가이드의 journal 사용을 참조하십시오. journalctl 을 사용하여 systemd 장치 파일의 로깅 출력을 볼 수 있습니다.

C.3. IdM 도메인 서비스 및 로그 순환

여러 IdM 도메인 서비스에서 시스템 10.0.0.1 서비스를 사용하여 로그 회전 및 압축을 처리합니다.
  • 이름 (DNS)
  • httpd (Apache)
  • Tomcat
  • sssd
  • ScanSetting5kdc (Kerberos 도메인 컨트롤러)
10.0.0.1 구성 파일은 /etc/logrotate.d/ 디렉터리에 저장됩니다.

예 C.1. /etc/logrotate.d/ httpd 의 기본 httpd 로그회전 파일

/var/log/httpd/*log {
    missingok
    notifempty
    sharedscripts
    delaycompress
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
}
주의
대부분의 서비스에 대한 policy 파일은 이전 로그와 동일한 이름, 기본 소유자 및 기본 권한이 있는 새 로그 파일을 생성합니다. 그러나 namedtomcat 에 대한 파일을 사용하면 특수 create 규칙은 명시적 권한뿐만 아니라 사용자 및 그룹 소유권으로 이 동작을 설정합니다.
namedtomcat 로그 파일을 소유하는 권한 또는 사용자 및 그룹을 변경하지 마십시오. 이는 IdM 작업 및 SELinux 설정 모두에 필요합니다. 로그 교체 정책 또는 파일의 소유권을 변경하면 IdM 도메인 서비스가 실패할 수 있습니다.

추가 리소스

  • IdM에서 백엔드로 사용하고 Dogtag Certificate System에서 사용하는 389 Directory Server 인스턴스에는 자체 내부 로그 교체 정책이 있습니다. Red Hat Directory Server 10 관리 가이드의 CloudEvent 로그 구성을 참조하십시오.
  • 압축 설정 또는 로그 파일의 크기와 같은 다른 잠재적 로그 회전 설정에 대한 자세한 내용은 시스템 관리자 가이드 또는 logrotate(8) 매뉴얼 페이지에서 로그 회전을 참조하십시오.

부록 D. 도메인 수준 0에서 복제본 관리

이 부록에서는 도메인 수준 0 에서 복제본 관리를 설명합니다( 7장. 도메인 수준 표시 및 승격참조). 도메인 수준 1 에서 복제본 관리 방법에 대한 자세한 내용은 다음을 참조하십시오.

D.1. 복제 정보 파일

복제본 생성 프로세스 중에 ipa-replica-prepare 유틸리티는 /var/lib/ipa/ 디렉터리에 복제본 서버 이름을 따서 이름이 지정된 복제본 정보 파일을 생성합니다. 복제본 정보 파일은 마스터 서버에 대한 영역과 구성 정보를 포함하는 GPG 암호화 파일입니다.
ipa-replica-install 복제본 설정 스크립트는 복제본 정보 파일에 포함된 정보를 기반으로 Directory Server 인스턴스를 구성하고 복제 초기화 프로세스를 시작하여 스크립트가 마스터 서버에서 복제본으로 데이터를 복사합니다. 복제본 정보 파일은 생성된 특정 시스템에 복제본을 설치하는 데만 사용할 수 있습니다. 여러 시스템에서 여러 복제본을 생성하는 데 사용할 수 없습니다.

D.2. 복제 생성

다음 섹션에서는 가장 주목할 만한 복제 설치 시나리오에 대해 설명합니다.
  • 프로시저와 예제는 함께 사용할 수 없습니다. CA, DNS 및 기타 명령줄 옵션을 동시에 사용할 수 있습니다. 다음 섹션의 예는 각 구성 영역에 필요한 사항을 명확하게 정의하기 위해 별도로 호출됩니다.
  • ipa-replica-install 유틸리티도 여러 다른 옵션도 허용합니다. 전체 목록은 ipa-replica-install(1) 매뉴얼 페이지입니다.

D.2.1. DNS 없이 복제 설치

  1. 마스터 IdM 서버 에서 ipa- replica -prepare 유틸리티를 실행하고 복제본 시스템의 FQDN(정규화된 도메인 이름)을 추가합니다. ipa-replica-prepare 스크립트는 IP 주소의 유효성을 검사하거나 다른 서버에서 복제본의 IP 주소에 연결할 수 있는지 확인하지 않습니다.
    중요
    단일 레이블 도메인 이름(예: .company)을 사용하지 마십시오. IdM 도메인은 하나 이상의 하위 도메인과 최상위 도메인(예: example.com 또는 company.example.com)으로 구성되어야 합니다.
    정규화된 도메인 이름은 다음 조건을 충족해야 합니다.
    • 유효한 DNS 이름이므로 숫자, 영문자 및 하이픈(-)만 사용할 수 있습니다. 밑줄(_)과 같은 기타 문자는 호스트 이름에서 DNS 오류가 발생합니다.
    • 이 모든 것이 더 낮은 사례입니다. 대문자는 허용되지 않습니다.
    • 정규화된 도메인 이름은 루프백 주소로 해석해서는 안 됩니다. 127.0.0.1 이 아닌 머신의 공용 IP 주소로 확인되어야 합니다.
    다른 권장 이름 지정 사례는 Red Hat Enterprise Linux 보안 가이드의 권장 이름 지정 사례를 참조하십시오.
    마스터 서버가 통합 DNS로 구성된 경우 --ip-address 옵션을 사용하여 복제본 시스템의 IP 주소를 지정합니다. 그런 다음 설치 스크립트에서 복제본에 대해 역방향 영역을 설정할지 묻습니다. IdM 서버가 통합 DNS로 구성된 경우에만 --ip-address 를 전달합니다. 그러지 않으면 업데이트할 DNS 레코드가 없으며 DNS 레코드 작업이 실패하면 복제본 생성 시도가 실패합니다.
    메시지가 표시되면 초기 마스터 서버의 DM(Directory Manager) 암호를 입력합니다. ipa-replica-prepare 의 출력에는 복제본 정보 파일의 위치가 표시됩니다. 예를 들어 다음과 같습니다.
    [root@server ~]# ipa-replica-prepare replica.example.com --ip-address 192.0.2.2
    Directory Manager (existing master) password:
    
    Do you want to configure the reverse zone? [yes]: no
    Preparing replica for replica.example.com from server.example.com
    Creating SSL certificate for the Directory Server
    Creating SSL certificate for the dogtag Directory Server
    Saving dogtag Directory Server port
    Creating SSL certificate for the Web Server
    Exporting RA certificate
    Copying additional files
    Finalizing configuration
    Packaging replica information into /var/lib/ipa/replica-info-replica.example.com.gpg
    Adding DNS records for replica.example.com
    Waiting for replica.example.com. A or AAAA record to be resolvable
    This can be safely interrupted (Ctrl+C)
    The ipa-replica-prepare command was successful
    
    주의
    복제본 정보 파일에는 중요한 정보가 포함되어 있습니다. 적절한 보호를 위해 적절한 조치를 취할 수 있습니다.
    ipa-replica-prepare 에 추가할 수 있는 다른 옵션은 ipa-replica-prepare(1) 도움말 페이지를 참조하십시오.
  2. 복제본 시스템에 ipa-server 패키지를 설치합니다.
    [root@replica ~]# yum install ipa-server
  3. 복제본 정보 파일을 초기 서버에서 복제본 시스템으로 복사합니다.
    [root@server ~]# scp /var/lib/ipa/replica-info-replica.example.com.gpg root@replica:/var/lib/ipa/
  4. 복제본 시스템 에서 ipa-replica-install 유틸리티를 실행하고 복제 정보 파일의 위치를 추가하여 복제본 초기화 프로세스를 시작합니다. 메시지가 표시되면 원래 마스터 서버의 Directory Manager 및 관리자 암호를 입력하고 복제본 설치 스크립트가 완료될 때까지 기다립니다.
    [root@replica ~]# ipa-replica-install /var/lib/ipa/replica-info-replica.example.com.gpg
    Directory Manager (existing master) password:
    
    Run connection check to master
    Check connection from replica to remote master 'server.example.com':
    
    ...
    
    Connection from replica to master is OK.
    Start listening on required ports for remote master check
    Get credentials to log in to remote master
    admin@MASTER.EXAMPLE.COM password:
    
    Check SSH connection to remote master
    
    ...
    
    Connection from master to replica is OK.
    
    ...
    
    Configuring NTP daemon (ntpd)
      [1/4]: stopping ntpd
      [2/4]: writing configuration
    
    ...
    
    Restarting Directory server to apply updates
      [1/2]: stopping directory server
      [2/2]: starting directory server
    Done.
    Restarting the directory server
    Restarting the KDC
    Restarting the web server
    
    참고
    설치 중인 복제본 파일이 현재 호스트 이름과 일치하지 않는 경우 복제 설치 스크립트에서 경고 메시지를 표시하고 확인을 요청합니다. 다중 홈 시스템의 와 같은 경우에 일치하지 않는 호스트 이름을 계속 진행하도록 확인할 수 있습니다.
    ipa-replica-install 에 추가할 수 있는 명령줄 옵션은 ipa-replica-prepare(1) 도움말 페이지를 참조하십시오. ipa-replica-install 에서 허용하는 옵션 중 하나는 --ip-address 옵션입니다. ipa-replica-install 에 추가할 때--ip-address 는 로컬 인터페이스와 연결된 IP 주소만 허용합니다.

D.2.2. DNS를 사용하여 복제본 설치

통합 DNS를 사용하여 복제본을 설치하려면 D.2.1절. “DNS 없이 복제 설치” 에 설명된 DNS 없이 설치 절차를 따르지만 ipa-replica-install 에 다음 옵션을 추가하십시오.
  • --setup-dns
  • --forwarder
자세한 내용은 4.5.3절. “DNS를 사용하여 복제본 설치” 을 참조하십시오.
예를 들어 다음과 같습니다.
[root@replica ~]# ipa-replica-install /var/lib/ipa/replica-info-replica.example.com.gpg --setup-dns --forwarder 198.51.100.0
ipa-replica-install 을 실행한 후 적절한 DNS 항목이 생성되었는지 확인하고 선택적으로 다른 DNS 서버를 백업 서버로 추가합니다. 자세한 내용은 4.5.3절. “DNS를 사용하여 복제본 설치” 을 참조하십시오.

D.2.3. 다양한 CA 구성으로 복제본 설치

주의
두 개 이상의 서버에 CA 서비스를 설치하는 것이 좋습니다. CA 서비스를 포함한 초기 서버 복제 설치에 대한 자세한 내용은 4.5.4절. “CA를 사용하여 복제본 설치” 을 참조하십시오.
CA를 하나의 서버에만 설치하는 경우 CA 서버가 실패할 경우 복구 가능성 없이 CA 구성을 손실할 수 있습니다. 자세한 내용은 B.2.6절. “손실된 CA 서버 복구” 을 참조하십시오.

인증서 시스템 CA가 설치된 서버에서 복제본 설치

통합된 Red Hat Certificate System 인스턴스로 구성된 초기 서버가 (루트 CA인지 아니면 외부 CA에 종속되었는지의 여부와 관계없이) 복제본에서 CA를 설정하려면 D.2.1절. “DNS 없이 복제 설치” 에 설명된 기본 설치 절차를 따르고 ipa-replica-install 유틸리티에 --setup-ca 옵션을 추가합니다. setup -ca 옵션은 초기 서버 구성에서 CA 구성을 복사합니다.
[root@replica ~]# ipa-replica-install /var/lib/ipa/replica-info-replica.example.com.gpg --setup-ca

인증서 시스템 CA가 설치되지 않은 서버에서 복제본 설치

CA가 없는 복제본 설치의 경우 D.2.1절. “DNS 없이 복제 설치” 에 설명된 기본 절차를 따르고 초기 서버에서 ipa-replica-prepare 유틸리티를 실행할 때 다음 옵션을 추가합니다.
  • --dirsrv-cert-file
  • --dirsrv-pin
  • --http-cert-file
  • --http-pin
자세한 내용은 4.5.5절. “CA 없이 서버에서 복제본 설치” 을 참조하십시오.
예를 들어 다음과 같습니다.
[root@server ~]# ipa-replica-prepare replica.example.com --dirsrv-cert-file /tmp/server.key --dirsrv-pin secret --http-cert-file /tmp/server.crt --http-cert-file /tmp/server.key --http-pin secret --dirsrv-cert-file /tmp/server.crt

D.2.4. 복제 계약 추가

ipa-replica-install 을 사용하여 복제본을 설치하면 마스터 서버와 복제본 간의 초기 복제 계약이 생성됩니다. 복제본을 다른 서버 또는 복제본에 연결하려면 ipa-replica-manage 유틸리티를 사용하여 계약을 추가합니다.
마스터 서버와 새 복제본에 CA가 설치되어 있으면 CA의 복제 계약도 생성됩니다. 다른 서버 또는 복제본에 CA 복제 계약을 추가하려면 ipa-csreplica-manage 유틸리티를 사용하십시오.
복제 계약 추가에 대한 자세한 내용은 D.3절. “복제 및 복제 계약 관리” 을 참조하십시오.

D.3. 복제 및 복제 계약 관리

이 장에서는 복제 계약에 대해 자세히 설명하고 이를 관리하는 방법을 설명합니다.
참고
추가 복제 계약 설정에 대한 지침은 4.2.2절. “복제 토폴로지 권장 사항” 을 참조하십시오.

D.3.1. 복제 계약 설명

복제본은 복제 연결로 결합되어 데이터 간 데이터를 복사합니다. 복제 계약: 데이터는 첫 번째 복제본에서 다른 복제본으로 복제되고 첫 번째 복제본에서 첫 번째 복제본으로 복제됩니다.
참고
초기 복제 계약은 ipa-replica-install 스크립트를 통해 두 복제본 간에 설정됩니다. 초기 복제 설치에 대한 자세한 내용은 4장. ID 관리 복제본 설치 및 제거 을 참조하십시오.

복제 계약의 유형

ID 관리는 다음과 같은 세 가지 유형의 복제 계약을 지원합니다.
  • 사용자, 그룹 및 정책과 같은 디렉터리 데이터를 복제하는 복제 계약. ipa-replica-manage 유틸리티를 사용하여 이러한 계약을 관리할 수 있습니다.
  • 인증서 서버 데이터를 복제하는 복제 계약. ipa-csreplica-manage 유틸리티를 사용하여 이러한 계약을 관리할 수 있습니다.
  • Active Directory 서버와 사용자 정보를 복제하는 동기화 계약. 이러한 계약은 이 가이드에 설명되어 있지 않습니다. IdM 및 Active Directory 동기화에 대한 설명서는 Windows 통합 가이드의 Active Directory 및 ID 관리 사용자 동기화 를 참조하십시오.
ipa-replica-manageipa-csreplica-manage 유틸리티는 동일한 형식과 인수를 사용합니다. 이 장의 다음 섹션에서는 이러한 유틸리티를 사용하여 수행할 수 있는 가장 주목할 만한 복제 관리 작업에 대해 설명합니다. 유틸리티에 대한 자세한 내용은 ipa-replica-manage(1)ipa-csreplica-manage(1) 매뉴얼 페이지를 참조하십시오.

D.3.2. 복제 계약 나열

현재 복제본에 대해 구성된 디렉터리 데이터 복제 계약을 나열하려면 ipa-replica-manage list 명령을 사용합니다.
  1. 인수 없이 ipa-replica-manage list 를 실행하여 복제 토폴로지의 모든 복제본을 나열합니다. 출력에서 필요한 복제본을 찾습니다.
    $ ipa-replica-manage list
    server1.example.com: master
    server2.example.com: master
    server3.example.com: master
    server4.example.com: master
  2. 복제본의 호스트 이름을 ipa-replica-manage 목록에 추가하여 복제 계약을 나열합니다.
    $ ipa-replica-manage list server1.example.com
    server2.example.com: replica
    server3.example.com: replica
    출력에 server1.example.com 에서 업데이트를 전송하는 복제본이 표시됩니다.
인증서 서버 복제 계약을 나열하려면 ipa-csreplica-manage list 명령을 사용합니다.

D.3.3. 복제 계약 생성 및 제거

복제 계약 생성

새 복제 계약을 만들려면 ipa-replica-manage connect 명령을 사용합니다.
$ ipa-replica-manage connect server1.example.com server2.example.com
명령은 server1.example.com에서 server2.example.com 으로, server2.example.com 에서 server1.example.com 으로 이동하는 새 버전의 복제 계약을 생성합니다.
ipa-replica-manage connect 를 사용하여 하나의 서버만 지정하면 IdM에서 로컬 호스트와 지정된 서버 간에 복제 계약을 생성합니다.
새 인증서 서버 복제 계약을 만들려면 ipa-csreplica-manage connect 명령을 사용합니다.

복제 계약 제거

복제 계약을 제거하려면 ipa-replica-manage disconnect 명령을 사용합니다.
$ ipa-replica-manage disconnect server1.example.com server4.example.com
이 명령은 server1.example.com에서 server4.example.com 으로 복제를 비활성화하고 server4.example .com 에서 server1.example.com 으로의 복제를 비활성화합니다.
ipa-replica-manage disconnect 명령은 복제 계약만 제거합니다. 두 서버 모두 Identity Management 복제 토폴로지에 남아 있습니다. 복제본과 관련된 모든 복제 계약 및 데이터를 제거하려면 ipa-replica-manage del 명령을 사용하여 ID 관리 도메인에서 복제본을 완전히 제거합니다.
$ ipa-replica-manage del server2.example.com
인증서 서버 복제 계약을 제거하려면 ipa-csreplica-manage disconnect 명령을 사용합니다. 마찬가지로 두 서버 간에 모든 인증서 복제 계약과 데이터를 제거하려면 ipa-csreplica-manage del 명령을 사용합니다.

D.3.4. 수동 복제 업데이트 시작

서로 직접 복제 계약을 통해 복제본 간 데이터 변경 사항은 거의 즉시 복제됩니다. 그러나 직접 복제 계약에 참여하지 않은 복제본은 업데이트를 신속하게 받지 않습니다.
경우에 따라 계획되지 않은 복제 업데이트를 수동으로 시작해야 할 수도 있습니다. 예를 들어 유지 관리를 위해 복제본을 오프라인으로 전환하기 전에 계획된 업데이트를 기다리는 대기열에 있는 모든 변경 사항을 하나 이상의 다른 복제본으로 전송해야 합니다. 이 경우 복제본을 오프라인으로 이동하기 전에 수동 복제 업데이트를 시작할 수 있습니다.
복제 업데이트를 수동으로 시작하려면 ipa-replica-manage force-sync 명령을 사용합니다. 명령을 실행하는 로컬 호스트는 업데이트를 수신하는 복제본입니다. 업데이트를 전송하는 복제본을 지정하려면 --from 옵션을 사용합니다.
$ ipa-replica-manage force-sync --from server1.example.com
인증서 서버 데이터에 대한 복제 업데이트를 시작하려면 ipa-csreplica-manage force-sync 명령을 사용합니다.

D.3.5. 복제 다시 초기화

복제본이 오랫동안 오프라인 상태이거나 해당 데이터베이스가 손상된 경우 다시 초기화할 수 있습니다. 재초기화는 4.5절. “복제 생성: 소개” 에 설명된 초기화와 유사합니다. 업데이트된 데이터 집합으로 복제본을 다시 초기화합니다. 예를 들어 백업에서 권한 있는 복원이 필요한 경우 다시 초기화할 수 있습니다.
참고
이 경우 일반 복제 업데이트를 기다리거나 수동 복제 업데이트를 시작하는 데 도움이 되지 않습니다. 이러한 복제 업데이트 중에 복제본은 변경된 항목만 서로 보냅니다. 재시작과 달리 복제 업데이트는 전체 데이터베이스를 새로 고치지 않습니다.
복제본에 대한 데이터 복제 계약을 다시 초기화하려면 ipa-replica-manage re-initialize 명령을 사용합니다. 명령을 실행하는 로컬 호스트는 다시 초기화된 복제본입니다. 데이터를 가져오는 복제본을 지정하려면 --from 옵션을 사용합니다.
$ ipa-replica-manage re-initialize --from server1.example.com
인증서 서버 복제 계약을 다시 초기화하려면 ipa-csreplica-manage re-initialize 명령을 사용합니다.

D.3.6. 복제 제거

복제를 삭제하거나 강등 하면 더 이상 IdM 요청을 처리하지 않도록 토폴로지에서 IdM 복제가 제거됩니다. 또한 IdM 도메인에서 호스트 시스템 자체를 제거합니다.
복제본을 삭제하려면 복제본에서 다음 단계를 수행합니다.
  1. IdM 도메인의 모든 복제 계약을 나열합니다. 출력에서 복제본의 호스트 이름을 확인합니다.
    $ ipa-replica-manage list
    server1.example.com: master
    server2.example.com: master
    server3.example.com: master
    server4.example.com: master
  2. ipa-replica-manage del 명령을 사용하여 복제본에 대해 구성된 모든 계약과 복제본에 대한 모든 데이터를 제거합니다.
    $ ipa-replica-manage del server3.example.com
  3. 복제본이 자체 CA로 구성된 경우 ipa-csreplica-manage del 명령을 사용하여 모든 인증서 서버 복제 계약을 제거합니다.
    $ ipa-csreplica-manage del server3.example.com
    참고
    이 단계는 복제 자체가 IdM CA로 구성된 경우에만 필요합니다. 마스터 서버 또는 다른 복제본만 CA로 구성된 경우에는 필요하지 않습니다.
  4. IdM 서버 패키지를 설치 제거합니다.
    $ ipa-server-install --uninstall -U

D.4. 마스터 CA 서버로 복제 승격

IdM 배포에서 임베디드 CA(인증 기관)를 사용하는 경우 IdM CA 서버 중 하나가 마스터 CA 역할을 합니다. CA 하위 시스템의 인증서 갱신을 관리하고 CRL(인증서 폐기 목록)을 생성합니다. 기본적으로 마스터 CA는 시스템 관리자가 ipa-server-install 또는 ipa-ca-install 명령을 사용하여 CA 역할을 설치한 첫 번째 서버입니다.
마스터 CA 서버를 오프라인으로 사용하거나 해제하려는 경우 복제본을 마스터 CA로 대체하도록 승격 합니다.

D.4.1. Which Server가 인증서 갱신을 처리하는 변경

인증서 갱신을 처리하는 서버를 변경하려면 IdM 서버에서 다음 절차를 사용하십시오.
  1. 현재 갱신 마스터인 서버를 확인합니다.
    • Red Hat Enterprise Linux 7.3 이상에서 다음을 수행합니다.
      $ ipa config-show | grep "CA renewal master"
      IPA CA renewal master: server.example.com
    • Red Hat Enterprise Linux 7.2 이하의 경우:
      $ ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn
      ...
      # CA, server.example.com, masters, ipa, etc, example.com
      dn: cn=CA,cn=server.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
      ...
    두 예 모두에서 server.example.com 은 현재 갱신 마스터입니다.
  2. 인증서 갱신을 처리하도록 다른 서버를 설정하려면 다음을 수행합니다.
    • Red Hat Enterprise Linux 7.4 이상에서 다음을 수행합니다.
      # ipa config-mod --ca-renewal-master-server new_server.example.com
    • Red Hat Enterprise Linux 7.3 이하의 경우:
      # ipa-csreplica-manage set-renewal-master
      참고
      이 명령은 명령을 새 갱신 마스터로 실행하는 서버를 설정합니다.
    또한 이러한 명령은 이전 CA를 갱신 마스터에서 복제본으로 자동으로 재구성합니다.

부록 E. ID 관리 서버 포트 고려 사항

E.1. ID 관리 구성 요소 및 관련 서비스

표 E.1. “ID 관리 구성 요소 및 관련 서비스” 개별 ID 관리 서비스가 외부에 노출되는 포트를 나열합니다.

표 E.1. ID 관리 구성 요소 및 관련 서비스

구성 요소 Service 액세스가 허용되는 포트
Identity Management 프레임워크* Apache 기반 웹 서비스 및 다른 서비스로의 경로 HTTPS 포트 443(TCP/TCP6)
LDAP 디렉토리 서버* 389-DS 인스턴스
포트 389(TCP/TCP6): 연결을 보호하기 위한 StartTLS 확장 또는 SASL GSSAPI를 사용하는 일반 LDAP 트래픽
포트 636 (TCP/TCP6): SSL을 통한 일반 LDAP 트래픽
포트 389 (UDP): Active Directory 서비스와 쉽게 통합하기 위한 연결 없는 LDAP 액세스
Kerberos 키 배포 센터* krb5kdc
포트 88(TCP/TCP6 및 UDP/UDP6): 일반 Kerberos 트래픽
포트 464 (TCP/TCP6 및 UDP/UDP6): Kerberos 암호 변경 프로토콜 액세스
Kerberos 관리자 데몬* kadmind 포트 749 (TCP/TCP6): 내부적으로 사용되는 Kerberos 원격 관리 프로토콜
custodia 키 관리* custodia HTTPS 포트 443 (TCP/TCP6): ID 관리 프레임워크의 일부로
시스템 보안 서비스 데몬* sssd HTTPS 포트 443 (TCP/TCP6): ID 관리 프레임워크의 일부로
MS-KDCP 프록시** HTTPS를 통해 Kerberos에 대한 프록시 액세스 HTTPS 포트 443 (TCP/TCP6): ID 관리 프레임워크의 일부로
인증 기관 Tomcat에 있는 Dogtag 인스턴스
HTTPS 포트 443 (TCP/TCP6): ID 관리 프레임워크의 일부로
ID 관리를 위해 설정된 Apache 규칙에 따라 포트 80(TCP/TCP6) 을 통한 HTTP 액세스(TCP/TCP6)로 인해 내부적으로 포트 8080(TCP/TCP6) 으로 리디렉션됩니다. 검색된 정보는 OCSP 응답기 및 인증서 상태(인증서 취소 목록)입니다.
내부적으로 포트 8443(TCP/TCP6) 을 통한 HTTPS 액세스 : CA 관리를 위해
내부적으로 IPA 마스터에서 포트 8005 및 8009(TCP/TCP6)127.0.0.1::1 로컬 인터페이스 주소에서 인증 기관 서비스의 구성 요소를 실행하는 데 사용됩니다.
DNS named
포트 53(TCP/TCP6 및 UDP/UDP6): 표준 DNS 확인자
포트 953 (TCP/TCP6): 127.0.0.1::1 로컬 인터페이스 주소의 BIND 서비스 원격 제어
Active Directory 통합 Samba 서비스(smbd, winbindd)
포트 135 (TCP/TCP6): DCE RPC 엔드 포인트 매퍼(smbd 데몬)
포트 138(TCP/TCP6), NetBIOS Datagram 서비스(선택 사항, nmbd 데몬이 실행되어야 함)
포트 139(TCP/TCP6), NetBIOS 세션 서비스(smbd daemon)
포트 445(TCP/TCP6), TCP/TCP6을 통한 SMB 프로토콜(smbd daemon)
DCE RPC 엔드 포인트 서비스의 포트 49152-65535(TCP/TCP6) 를 동적으로 엽니다.
인증 기관 Vault Dogtag 인스턴스의 KRA 구성 요소
HTTPS 포트 443 (TCP/TCP6): ID 관리 프레임워크의 일부로
포트 80(TCP/TCP6) 을 통한 HTTP 액세스(TCP/TCP6)를 통해 내부적으로 Apache 규칙에서 포트 8080(TCP/TCP6) 으로 리디렉션합니다: OCSP 응답기 및 인증서 상태(Certificate Revocation List)
내부적으로 포트 8443(TCP/TCP6) 을 통한 HTTPS 액세스 : CA 관리를 위해
내부적으로 IPA 마스터에서 포트 8005 및 8009(TCP/TCP6)127.0.0.1::1 로컬 인터페이스 주소에서 인증 기관 서비스의 구성 요소를 실행하는 데 사용됩니다.
* 별표가 표시된 서비스는 모든 ID 관리 배포에서 필수입니다.
** MS-KDCP 프록시 구성 요소는 선택 사항이지만 기본적으로 활성화되어 있습니다.

부록 F. IdM에서 주요 변경 사항

특정 IdM 버전에서는 새 명령을 도입하거나 기존 명령을 교체합니다. 또한 구성 또는 설치 절차가 광범위하게 변경되는 경우도 있습니다. 이 부록은 가장 중요한 변경 사항을 설명합니다.
자세한 변경 사항 목록은 개별 버전에 대한 RHEL (Red Hat Enterprise Linux) 7 릴리스 노트를 참조하십시오.

RHEL 7.7에서 실행되는 IdM 4.6

  • IdM이 오프라인 상태가 되면 ipa-cert-fix 유틸리티가 시스템 인증서를 갱신하기 위해 추가되었습니다. 자세한 내용은 26.2.3절. “IdM이 오프라인될 때 만료된 시스템 인증서 갱신” 의 내용을 참조하십시오.
  • IdM은 인증서의 SAN 확장에서 IP 주소를 지원합니다. 특정 상황에서 관리자는 SAN(주체 대체 이름) 확장에서 IP 주소로 인증서를 발행해야 합니다. 이 릴리스부터 관리자는 IdM DNS 서비스에서 주소가 관리되고 제목 호스트 또는 서비스 주체와 연결된 경우 SAN 확장에 IP 주소를 설정할 수 있습니다.
  • 이제 IdM에서 단일 레이블 도메인 이름(예: .company) 사용을 금지합니다. IdM 도메인은 하나 이상의 하위 도메인과 최상위 도메인(예: example.com 또는 company.example.com)으로 구성되어야 합니다.
  • 이 릴리스에 대한 자세한 내용은 Red Hat Enterprise Linux 7.7 릴리스 노트 의 다음 섹션을 참조하십시오.

RHEL 7.6에서 실행되는 IdM 4.6

RHEL 7.5에서 실행되는 IdM 4.5

RHEL 7.4에서 실행되는 IdM 4.5

  • 이 버전은 클라이언트 HTTPS 연결의 SSL 백엔드를 NSS(Network Security Services)에서 OpenSSL로 변경했습니다. 결과적으로 등록 기관(RA)은 NSS 데이터베이스 대신 /var/lib/ipa/ 디렉터리에 인증서를 저장합니다.
  • 이 릴리스에 대한 자세한 내용은 Red Hat Enterprise Linux 7.4 릴리스 노트 의 다음 섹션을 참조하십시오.

RHEL 7.3에서 실행되는 IdM 4.4

  • ipa replica-manage clean-dangling-ruv 명령을 사용하면 관리자가 제거된 복제본에서 모든 상대 업데이트 벡터(RUV)를 제거할 수 있습니다.
  • ipa server-del 명령을 사용하면 관리자가 IdM 서버를 제거할 수 있습니다.
  • 이 버전에 도입된 다음 명령을 사용하면 관리자가 IdM CA(인증 기관)를 관리할 수 있습니다.
    • ipa ca-add
    • ipd ca-del
    • ipa ca-enable
    • ipa ca-disble
    • IPA ca-find
    • ipa ca-mod
    • ipa ca-show
  • 이 버전에 도입된 다음 명령은 복제 계약을 관리하기 위해 ipa-replica manage 명령을 대체합니다.
    • ipa topology-configure
    • ipa topologysegment-mod
    • ipa topologysegment-del
    • ipa topologysuffix-add
    • ipa topologysuffix-show
    • ipa topologysuffix-verify
  • 이 버전에 도입된 다음 명령을 사용하면 관리자가 cn=masters,cn=ipa,cn=etc,domain_suffix 항목에 저장된 IdM 서버 목록을 표시할 수 있습니다.
    • ipa server-find
    • ipa server-show
  • certmonger 도우미 스크립트는 /usr/lib64/ipa/certmonger/ 에서 /usr/libexec/ipa/certmonger/ 디렉터리로 이동되었습니다.
  • 이 버전에서는 도메인 수준을 표시하고 설정하는 다음 명령을 도입했습니다.
    • ipa domainlevel-set
    • ipa domainlevel-show
  • 이 릴리스에 대한 자세한 내용은 Red Hat Enterprise Linux 7.3 릴리스 노트 의 다음 섹션을 참조하십시오.

RHEL 7.2에서 실행되는 IdM 4.2

  • 여러 인증서 프로필 및 사용자 인증서 지원: Identity Management는 단일 서버 인증서 프로필만 지원하는 대신 서버 및 기타 인증서를 발급하기 위해 여러 프로필을 지원합니다. 프로필은 Directory Server에 저장되며 IdM 복제본 간에 공유됩니다. 또한 관리자는 이제 개별 사용자에게 인증서를 발급할 수 있습니다. 이전에는 호스트와 서비스에 인증서를 발급할 수 있었습니다.
  • 이 릴리스의 자세한 내용은 Red Hat Enterprise Linux 7.2 릴리스 노트새로운 기능 - 인증 및 상호 운용성 섹션을 참조하십시오.

RHEL 7.1에서 실행되는 IdM 4.1

  • 이 버전에 도입된 다음 명령은 keytabs를 검색하고 검색 권한을 설정하기 위해 ipa-getkeytab -r 명령을 교체합니다.
    • ipa-host-allow-retrieve-keytab
    • ipa-host-disallow-retrieve-keytab
    • ipa-host-allow-create-keytab
    • ipa-host-disallow-create-keytab
    • ipa-service-allow-retrieve-keytab
    • ipa-service-disallow-retrieve-keytab
    • ipa-service-allow-create-keytab
    • ipa-service-disallow-create-keytab
  • 이 릴리스의 자세한 내용은 Red Hat Enterprise Linux 7.1 릴리스 노트새로운 기능 - 인증 및 상호 운용성 섹션을 참조하십시오.

RHEL 7.0에서 실행되는 IdM 3.3

부록 G. 개정 내역

버전 번호는 Red Hat Enterprise Linux 버전 번호가 아닌 이 설명서의 에디션과 관련이 있습니다.

고친 과정
고침 7.0-53Tue Feb 16 2021Florian Delehaye
IdM 서비스 및 구성 파일 및 기타 사소한 수정 사항에 대한 다양한 설명.
고침 7.0-52Tue Sep 29 2020Florian Delehaye
7.9 GA 게시용 문서 버전.
고침 7.0-51Tue Mar 31 2020Florian Delehaye
7.8 GA 게시용 문서 버전.
고침 7.0-50Wed Aug 28 2019Marc Muehlfeld
IdM 부록에 Notable Changes가 추가되었습니다. 몇 가지 마이너 업데이트.
고침 7.0-49Tue Aug 06 2019Marc Muehlfeld
7.7 GA 게시용 문서 버전.
고침 7.0-48Fri Jun 21 2019Marc Muehlfeld
IdM이 오프라인될 때 만료된 시스템 인증서 갱신 섹션 추가.
고침 7.0-47Thu Jun 13 2019Marc Muehlfeld
숨겨진 복제본 구성에 대한 추가 콘텐츠입니다.
고침 7.0-46Wed Jun 04 2019Marc Muehlfeld
마지막 성공적인 Kerberos 인증 추적 활성화 섹션 추가. 몇 가지 사소한 편집 내용.
고침 7.0-45Tue Apr 09 2019Marc Muehlfeld
웹 UI 세션 길이 추가, 인증 지표에 대한 두 섹션 및 몇 가지 사소한 편집이 추가되었습니다.
고침 7.0-44Thu Nov 22 2018Filip Hanzelka
IdM 서버 설치 및 설치 제거 장에서 ID 관리 구성 요소 및 관련 서비스 및 마이너 편집 추가.
고침 7.0-43Mon Oct 29 2018Lucie Maňásková
7.6 GA 게시를 위한 문서 준비.
고침 7.0-42Tue Jun 26 2018Lucie Maňásková
통합 IdM CA로 업데이트된 관리 인증서. 기타 업데이트.
고침 7.0-41Fri Apr 23 2018Filip Hanzelka
Kerberos 티켓의 수명 지정 추가. 기타 마이너 픽스.
고침 7.0-40Fri Apr 6 2018Lucie Maňásková
7.5 GA 게시를 위한 문서 준비.
고침 7.0-39Wed Mar 14 2018Filip Hanzelka
마이너 업데이트.
고침 7.0-38Wed Feb 28 2018Lucie Maňásková
마이너 업데이트.
고침 7.0-37Mon Feb 12 2018Aneta Šteflová Petrová
추가된 사용자는 '추가' 권한을 얻기 위해 Vault Due에 액세스할 수 없습니다. 기타 마이너 픽스.
고침 7.0-36Mon Jan 29 2018Aneta Šteflová Petrová
업데이트된 SELinux 사용자 맵 정의. 기타 마이너 픽스.
고침 7.0-35Fri Dec 15 2017Aneta Šteflová Petrová
업데이트된 호스트 관리. 기타 마이너 픽스.
고침 7.0-34Mon Dec 4 2017Aneta Šteflová Petrová
IdM에 Kerberos PKINIT 인증을 추가했습니다. IdM 사용자를 위한 액세스 제어 업데이트. 기타 마이너 픽스.
고침 7.0-33Mon Nov 20 2017Aneta Šteflová Petrová
업데이트된 사용자 및 그룹 스키마암호 정책 정의.
고침 7.0-32Mon Oct 9 2017Aneta Šteflová Petrová
마이너 픽스.
고침 7.0-31Tue Sep 12 2017Aneta Šteflová Petrová
일부 웹 UI 스크린샷과 절차를 업데이트했습니다. ID 관리의 스마트 카드 인증에 대한 마이너 업데이트.
고침 7.0-30Mon Aug 28 2017Aneta Šteflová Petrová
ID 관리 및 ID 관리 구성 파일 및 디렉터리에서 업데이트된 스마트 카드 인증 .
고침 7.0-29Tue Jul 18 2017Aneta Šteflová Petrová
7.4 GA 게시용 문서 버전.
고침 7.0-28Mon Apr 24 2017Aneta Šteflová Petrová
업데이트 및 병합된 관리 사용자 그룹, 호스트 그룹, automember. 기타 마이너 업데이트.
고침 7.0-27Mon Apr 10 2017Aneta Šteflová Petrová
ID 관리를 위한 TLS 구성이 추가되었습니다. 다양한 마이너 수정 및 업데이트.
고침 7.0-26Mon Mar 27 2017Aneta Šteflová Petrová
클라이언트에 대한 설치 후 고려 사항 추가 및 암호 재설정 활성화. 기타 마이너 업데이트.
고침 7.0-25Mon Feb 27 2017Aneta Šteflová Petrová
Kerberos 도메인, 업그레이드 및 HBAC 관리에 대한 장이 업데이트되었습니다. 여러 단원의 기타 업데이트.
고침 7.0-24Wed Dec 7 2016Aneta Šteflová Petrová
업데이트된 automember 및 암호 정책 장. NIS 지원 플러그인에 대한 설명 추가. 기타 마이너 업데이트.
고침 7.0-23Tue Oct 18 2016Aneta Šteflová Petrová
7.3 GA 게시 버전.
고침 7.0-22Fri Jul 29 2016Aneta Petrová
자격 증명 모음을 사용하여 에 장을 추가합니다.
고침 7.0-21Thu Jul 28 2016Marc Muehlfeld
업데이트된 소개, 기타 마이너 수정 사항.
고침 7.0-19Tue Jun 28 2016Aneta Petrová
업데이트된 다이어그램. IdM을 사용하여 얻을 수 있는 이점에 대한 섹션을 intro 장에 추가합니다. 기타 사소한 수정 및 수정 사항.
고침 7.0-18Fri Jun 10 2016Aneta Petrová
업데이트된 소개, 서버 설치 및 문제 해결 장. 기타 픽스.
고침 7.0-17Fri May 27 2016Aneta Petrová
사용자 라이프사이클에 대한 다이어그램을 추가했습니다.
고침 7.0-16Thu Mar 24 2016Aneta Petrová
사용자 라이프사이클이 추가되었습니다. 사용자 계정, 사용자 인증 및 복제본 관리 장 업데이트.
고침 7.0-15Thu Mar 03 2016Aneta Petrová
업데이트된 여러 DNS 섹션. PAM 서비스의 제한된 도메인을 시스템 수준 인증 가이드로 이동.
고침 7.0-14Tue Feb 09 2016Aneta Petrová
스마트 카드, ID 뷰 및 OTP 추가. 설치 제거 절차를 설치 장으로 이동. 기타 마이너 업데이트.
고침 7.0-13Thu Nov 19 2015Aneta Petrová
인증서 프로필 관리 및 복제를 마스터로 승격하는 부 업데이트.
고침 7.0-12Fri Nov 13 2015Aneta Petrová
DNS 및 기타 섹션에 대한 업데이트가 포함된 7.2 GA 릴리스 버전.
고침 7.0-11Thu Nov 12 2015Aneta Petrová
7.2 GA 릴리스 버전.
고침 7.0-10Fri Mar 13 2015Tomáš Čapek
7.1에 대한 최근 편집 작업이 포함된 비동기 업데이트.
고침 7.0-8Wed Feb 25 2015Tomáš Čapek
7.1 GA 릴리스 버전.
고침 7.0-6Fri Dec 05 2014Tomáš Čapek
를 다시 빌드하여 시작 페이지의 정렬 순서를 업데이트합니다.
고침 7.0-4Wed Jun 11 2014Ella Deon Ballard
초기 릴리스.

법적 공지

Copyright © 2020 Red Hat, Inc.
이 문서의 텍스트와 그림은 Creative Commons Attribution-Share Alike 3.0 Unported 라이센스("CC-BY-SA")에 따라 Red Hat에서 라이센스를 부여합니다. CC-BY-SA에 대한 설명은 http://creativecommons.org/licenses/by-sa/3.0/ 에서 확인할 수 있습니다. CC-BY-SA에 따라 이 문서 또는 문서의 수정본을 배포할 경우 원본의 URL을 제공해야 합니다.
Red Hat은 이 문서의 라이센스 제공자로서 관련 법률이 허용하는 한도 내에서 CC-BY-SA의 섹션 4d를 시행할 권리를 포기하며 이를 주장하지 않을 것에 동의합니다.
Red Hat, Red Hat Enterprise Linux, Shadowman 로고, Red Hat 로고, JBoss, OpenShift, Fedora, Infinity 로고 및 RHCE는 미국 및 기타 국가에 등록된 Red Hat, Inc.의 상표입니다.
Linux® 는 미국 및 기타 국가에 등록된 Linus Torvalds의 등록 상표입니다.
Java® 는 Oracle 및/또는 그 계열사의 등록 상표입니다.
XFS® 는 미국 및/또는 기타 국가에 등록된 Silicon Graphics International Corp. 또는 그 자회사의 상표입니다.
MySQL® 은 미국, 유럽 연합 및 기타 국가에 있는 MySQL AB의 등록 상표입니다.
Node.js® 는 Joyent의 공식 상표입니다. Red Hat은 공식 Joyent Node.js 오픈 소스 또는 상용 프로젝트에서 공식적으로 관련되거나 보증되지 않습니다.
OpenStack® Word Mark 및 OpenStack 로고는 미국 및 기타 국가에서 OpenStack Foundation의 등록 상표/서비스표 또는 상표/서비스표이며 OpenStack Foundation의 권한과 함께 사용됩니다. 당사는 OpenStack Foundation 또는 OpenStack 커뮤니티와 제휴 관계가 아니며 보증 또는 후원을 받지 않습니다.
기타 모든 상표는 각각 해당 소유자의 자산입니다.