Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

시스템 수준 인증 가이드

Red Hat Enterprise Linux 7

애플리케이션 및 서비스를 사용하여 로컬 시스템에서 인증 구성

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

초록

이 가이드에서는 로컬 시스템에서 인증을 구성하는 데 사용할 수 있는 다양한 애플리케이션과 서비스를 설명합니다.
이 가이드 외에도 Red Hat Enterprise Linux Identity Management와 관련된 기능 및 서비스에 대한 문서는 다음 가이드를 참조하십시오.

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

Linux 도메인 ID, 인증 및 정책 가이드 에는 Linux 기반 도메인의 인증 및 권한 부여 정책뿐만 아니라 ID 저장소를 관리하는 중앙 집중식 통합 방법을 제공하는 솔루션인 Red Hat Identity Management가 문서화되어 있습니다.

Windows 통합 가이드

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

1장. 시스템 인증 소개
링크 복사

보안 네트워크 환경을 설정하는 초석 중 하나는 네트워크에 액세스할 권한이 있는 사람들에게만 액세스가 제한되어야 한다는 것입니다. 액세스가 허용되면 사용자가 시스템에 인증할 수 있으므로 ID를 확인할 수 있습니다.
모든 Red Hat Enterprise Linux 시스템에는 사용자 ID를 생성하고 식별하는 데 사용할 수 있는 다양한 서비스가 있습니다. 이러한 파일은 로컬 시스템 파일, Kerberos 또는 Samba와 같은 대규모 ID 도메인에 연결하는 서비스 또는 해당 도메인을 생성하는 툴일 수 있습니다.
이 가이드에서는 관리자가 로컬 시스템의 인증 및 ID를 관리하는 데 사용할 수 있는 몇 가지 일반적인 시스템 서비스와 애플리케이션을 검토합니다. Linux 도메인 생성 및 Linux 시스템을 Windows 도메인에 통합하는 방법에 대한 자세한 정보를 제공하는 기타 가이드를 사용할 수 있습니다.

1.1. 사용자 ID 확인
링크 복사

인증은 ID 를 확인하는 프로세스입니다. 네트워크 상호 작용의 경우 인증에는 다른 당사자가 식별하는 작업이 포함됩니다. 네트워크를 통한 인증을 사용하는 방법에는 간단한 암호, 인증서, 일회성 암호(OTP) 토큰, biometric 스캔 등 여러 가지가 있습니다.
권한 부여 는 인증된 당사자가 수행할 수 있거나 액세스할 수 있는 작업을 정의합니다.
인증에는 사용자가 ID를 확인할 수 있는 일종의 자격 증명을 제공해야 합니다. 필요한 자격 증명의 종류는 사용 중인 인증 메커니즘에 의해 정의됩니다. 시스템의 로컬 사용자에 대한 여러 종류의 인증이 있습니다.
  • 암호 기반 인증. 거의 모든 소프트웨어는 사용자가 인식되는 이름과 암호를 제공하여 인증을 허용합니다. 이를 단순한 인증 이라고도 합니다.
  • 인증서 기반 인증. 인증서를 기반으로 하는 클라이언트 인증은 SSL 프로토콜의 일부입니다. 클라이언트는 임의로 생성된 데이터에 디지털 서명하고 인증서와 서명된 데이터를 네트워크 전체에서 전송합니다. 서버는 서명의 유효성을 검사하고 인증서의 유효성을 확인합니다.
  • Kerberos 인증. Kerberos는 티켓 발행 티켓(TGT) 이라는 수명이 짧은 자격 증명 시스템을 설정합니다. 사용자는 사용자를 식별하고 사용자가 티켓을 발행할 수 있는 시스템을 나타내는 자격 증명(즉, 사용자 이름 및 암호)을 표시합니다. TGT는 웹 사이트 및 이메일과 같은 다른 서비스에 대한 액세스 티켓을 요청하는 데 반복적으로 사용될 수 있습니다. TGT를 사용한 인증은 이러한 방식으로 단일 인증 프로세스만 수행할 수 있습니다.
  • 스마트 카드 기반 인증. 이는 인증서 기반 인증의 변형입니다. 스마트 카드(또는 토큰)는 사용자 인증서를 저장합니다. 사용자가 토큰을 시스템에 삽입하면 시스템에서 인증서를 읽고 액세스 권한을 부여할 수 있습니다. 스마트 카드를 사용하는 SSO(Single Sign-On)는 세 단계로 진행됩니다.
    1. 사용자가 스마트 카드를 카드 리더에 삽입합니다. Red Hat Enterprise Linux의 PAM(Pluggable Authentication Module)은 삽입된 스마트 카드를 감지합니다.
    2. 시스템은 인증서를 사용자 항목에 매핑한 다음, 인증서 기반 인증에 설명된 대로 개인 키로 암호화되는 스마트 카드의 현재 인증서를 사용자 항목에 저장된 인증서와 비교합니다.
    3. 인증서가 KDC(키 배포 센터)에 대해 성공적으로 검증되면 사용자가 로그인할 수 있습니다.
    스마트 카드 기반 인증은 인증서를 추가 식별 메커니즘으로 추가하고 물리적 액세스 요구 사항을 추가하여 Kerberos에서 설정한 간단한 인증 계층을 기반으로 합니다.

1.2. 계획 Single Sign-On의 일부로
링크 복사

1.1절. “사용자 ID 확인” 에 설명된 대로 인증에 관한 것은 모든 보안 애플리케이션에서 액세스하기 위해 적어도 암호가 필요하다는 것입니다. 중앙 ID 저장소와 자체 사용자 및 자격 증명 세트를 유지하는 모든 애플리케이션이 없으면 사용자가 열리는 모든 서비스 또는 애플리케이션의 암호를 입력해야 합니다. 이를 위해서는 하루에 여러 번 암호를 입력해야 하며, 심지어는 몇 분마다 암호를 입력해야 합니다.
여러 개의 암호를 유지 관리하고 지속적으로 입력하라는 메시지가 표시되는 것은 사용자와 관리자에게 번거로움이 됩니다. Single Sign-On 은 관리자가 단일 암호를 사용하여 한 번 로그인할 수 있도록 단일 암호 저장소를 만들고 모든 네트워크 리소스에 인증할 수 있는 구성입니다.
Red Hat Enterprise Linux는 워크스테이션에 로그인, 화면 보호기를 잠금 해제, Mozilla Firefox를 사용하여 보안 웹 페이지에 액세스하는 등 여러 리소스에 대한 SSO(Single Sign-On)를 지원합니다. PAM, NSS 및 Kerberos와 같은 기타 사용 가능한 시스템 서비스를 사용하면 이러한 ID 소스를 사용하도록 기타 시스템 애플리케이션을 구성할 수 있습니다.
SSO(Single Sign-On)는 사용자 편의성과 서버 및 네트워크에 대한 또 다른 보안 계층입니다. SSO(Single Sign-On)는 안전하고 효과적인 인증을 보장합니다. Red Hat Enterprise Linux는 SSO(Single Sign-On)를 활성화하는 데 사용할 수 있는 두 가지 인증 메커니즘을 제공합니다.
  • Kerberos 영역 및 Active Directory 도메인을 통한 Kerberos 기반 인증
  • 스마트 카드 기반 인증
두 방법 모두 중앙 집중화된 ID 저장소(Kerberos 영역 또는 공용 키 인프라의 인증 기관을 통해)를 생성하고, 로컬 시스템 서비스는 여러 로컬 저장소를 유지 관리하는 대신 이러한 ID 도메인을 사용합니다.

1.3. 사용 가능한 서비스
링크 복사

모든 Red Hat Enterprise Linux 시스템에는 로컬 시스템에서 로컬 사용자에 대한 인증을 구성할 수 있는 일부 서비스가 이미 있습니다. 여기에는 다음이 포함됩니다.
인증 설정
  • authconfig(인증 구성 도구)는 시스템에 대해 다양한 ID 백엔드 및 인증 수단(예: 암호, 지문 또는 스마트 카드)을 설정합니다.
ID 백엔드 설정
  • SSSD(Security System Services Daemon)는 여러 ID 프로바이더(주로 Microsoft Active Directory 또는 Red Hat Enterprise Linux IdM과 같은 LDAP 기반 디렉터리)를 설정한 다음 사용자를 위해 로컬 시스템과 애플리케이션에서 모두 사용할 수 있습니다. 암호와 티켓이 캐시되므로 자격 증명을 재사용하여 오프라인 인증과 SSO(Single Sign-On)가 모두 가능합니다.
  • realmd 서비스는 IdM의 SSSD인 인증 백엔드를 구성할 수 있는 명령줄 유틸리티입니다. realmd 서비스는 DNS 레코드를 기반으로 사용 가능한 IdM 도메인을 감지하고 SSSD를 구성한 다음 시스템을 도메인으로 결합합니다.
  • NSS(Name Service Switch)는 사용자, 그룹 또는 호스트에 대한 정보를 반환하는 낮은 수준의 시스템 호출을 위한 메커니즘입니다. NSS는 필요한 정보를 가져오는 데 사용해야 하는 모듈, 즉 어떤 소스가 결정됩니다. 예를 들어 사용자 정보는 /etc/passwd 파일과 같은 기존 UNIX 파일 또는 LDAP 기반 디렉터리에 있을 수 있지만 호스트 주소는 /etc/hosts 파일 또는 DNS 레코드와 같은 파일에서 읽을 수 있습니다. NSS는 정보가 저장된 위치를 찾습니다.
인증 메커니즘
  • PAM(Pluggable Authentication Modules)은 인증 정책을 설정하는 시스템을 제공합니다. 인증을 위해 PAM을 사용하는 애플리케이션은 다양한 인증 측면을 제어하는 다양한 모듈을 로드합니다. 애플리케이션에서 사용하는 PAM 모듈은 애플리케이션 구성 방식을 기반으로 합니다. 사용 가능한 PAM 모듈에는 Kerberos, Winbind 또는 로컬 UNIX 파일 기반 인증이 포함됩니다.
다른 서비스 및 애플리케이션도 사용할 수 있지만 이러한 서비스도 일반적으로 사용됩니다.

I 부. 시스템 로그인
링크 복사

이 부분에서는 authconfig,ipa-client-install 및 realmd 툴을 사용하여 시스템 인증을 구성하는 방법에 대한 지침을 제공합니다.

2장. 시스템 인증 구성
링크 복사

인증은 사용자가 시스템에서 식별 및 확인되는 프로세스 입니다. 사용자 이름 및 암호와 같은 일종의 ID 및 자격 증명을 제공해야 합니다. 그러면 시스템은 구성된 인증 서비스와 자격 증명을 비교합니다. 자격 증명이 일치하고 사용자 계정이 활성이면 사용자가 인증 됩니다.
사용자가 인증되면 해당 정보가 액세스 제어 서비스로 전달되어 사용자가 수행할 수 있는 작업을 결정합니다. 이 리소스는 사용자가 액세스할 권한이 있는 리소스입니다. 인증과 권한 부여는 두 개의 별도 프로세스입니다.
사용자 인증을 확인하기 위해서는 시스템에 유효한 계정 데이터베이스 목록이 있어야 합니다. 사용자를 확인하는 정보는 로컬 시스템에 있거나 로컬 시스템이 원격 시스템의 사용자 데이터베이스를 참조할 수 있습니다(예: LDAP 또는 Kerberos). 로컬 시스템은 LDAP(Lightweight Directory Access Protocol), NIS(Network Information Service) 및 Winbind 등의 사용자 정보에 다양한 데이터 저장소를 사용할 수 있습니다. LDAP 및 NIS 데이터 저장소는 Kerberos를 사용하여 사용자를 인증할 수 있습니다.
SSSD(System Security Services Daemon)를 중앙 데몬으로 사용하여 사용자에게 다른 ID 백엔드에 대해 인증하거나, 사용자에게 TGT( 티켓 제공 티켓)를 요청하는 등 편의성 및 잠재적으로 SSO(Single Sign-On)를 사용할 수 있습니다. SSSD는 LDAP, Kerberos 및 외부 애플리케이션과 상호 작용하여 사용자 자격 증명을 확인할 수 있습니다.
이 장에서는 시스템 인증을 구성하기 위해 Red Hat Enterprise Linux에서 사용할 수 있는 툴을 설명합니다.

2.1. 시스템 인증을 위한 ID 관리 도구
링크 복사

ipa-client-install 유틸리티 및 realmd 시스템을 사용하여 Identity Management 시스템에서 시스템 인증을 자동으로 구성할 수 있습니다.
ipa-client-install
ipa-client-install 유틸리티는 Identity Management 도메인에 클라이언트 시스템으로 연결하도록 시스템을 구성합니다. ipa-client-install 에 대한 자세한 내용은 Linux 도메인 ID, 인증 및 정책 가이드에서 클라이언트 설치를 참조하십시오.
Identity Management 시스템의 경우 realmd 에서 ipa-client-install 을 사용하는 것이 좋습니다.
realmd
realmd 시스템은 ID 관리 또는 Active Directory 도메인과 같은 ID 도메인에 머신을 결합합니다. realmd 에 대한 자세한 내용은 Windows 통합 가이드의 realmd를 사용하여 Active Directory 도메인에 연결 섹션을 참조하십시오.

2.2. authconfig사용
링크 복사

authconfig 툴은 LDAP와 같은 사용자 자격 증명에 사용할 데이터 저장소를 구성하는 데 도움이 될 수 있습니다. Red Hat Enterprise Linux에서 authconfig 에는 사용자 데이터 저장소를 구성하는 GUI 및 명령줄 옵션이 모두 있습니다. authconfig 툴은 다양한 형태의 인증 메커니즘과 함께 사용자 데이터베이스의 경우 SSSD, LDAP, NIS 또는 Winbind와 같은 특정 서비스를 사용하도록 시스템을 구성할 수 있습니다.
중요
Identity Management 시스템을 구성하려면 authconfig 대신 ipa-client-install 유틸리티 또는 realmd 시스템을 사용하는 것이 좋습니다. authconfig 유틸리티는 제한되어 있으며 훨씬 덜 유연합니다. 자세한 내용은 2.1절. “시스템 인증을 위한 ID 관리 도구” 의 내용을 참조하십시오.
인증 설정 구성에 다음 세 가지 authconfig 유틸리티를 사용할 수 있습니다.
  • authconfig-gtk 는 전체 그래픽 인터페이스를 제공합니다.
  • authconfig 는 수동 구성을 위한 명령줄 인터페이스를 제공합니다.
  • authconfig-tui 는 텍스트 기반 UI를 제공합니다. 이 유틸리티는 더 이상 사용되지 않습니다.
이러한 모든 구성 유틸리티는 root 로 실행해야 합니다.

2.2.1. authconfig CLI를 사용하는 팁
링크 복사

authconfig 명령줄 툴은 스크립트에 전달된 설정에 따라 시스템 인증에 필요한 모든 구성 파일 및 서비스를 업데이트합니다. UI를 통해 설정할 수 있는 것보다 더 많은 ID 및 인증 구성 옵션을 제공하는 것과 함께 authconfig 툴을 사용하여 백업 및 Kickstart 파일을 생성할 수도 있습니다.
authconfig 옵션의 전체 목록은 도움말 출력 및 도움말 페이지를 확인합니다.
authconfig 를 실행할 때 명심해야 할 몇 가지 사항이 있습니다.
  • 모든 명령에 --update 또는 -- test 옵션을 사용합니다. 명령을 성공적으로 실행하려면 해당 옵션 중 하나가 필요합니다. update를 사용하면 구성 변경 사항을 씁니다. test 옵션은 변경 사항을 표시하지만 변경 사항을 구성에 적용하지 않습니다.
    update 옵션을 사용하지 않으면 변경 사항이 시스템 구성 파일에 작성되지 않습니다.
  • 명령줄을 사용하여 기존 구성을 업데이트하고 새 구성을 설정할 수 있습니다. 이로 인해 명령 행은 지정된 호출과 함께 필요한 속성을 사용하도록 강제 적용하지 않습니다(명령은 완전한 설정 업데이트일 수 있기 때문입니다).
    인증 구성을 편집할 때는 구성이 완료되고 정확해야 합니다. 인증 설정을 불완전하거나 잘못된 값으로 변경하면 사용자가 시스템에서 잠길 수 있습니다. --test 옵션을 사용하여 --update 옵션을 사용하여 쓰기 전에 설정이 적절한지 확인합니다.
  • 각 활성화 옵션에는 해당 비활성화 옵션이 있습니다.

2.2.2. authconfig UI 설치
링크 복사

authconfig UI는 기본적으로 설치되지 않지만 관리자가 인증 구성을 빠르게 변경하는 것이 유용할 수 있습니다.
UI를 설치하려면 authconfig-gtk 패키지를 설치합니다. 여기에는 authconfig 명령줄 툴, Bash 및 Python과 같은 몇 가지 일반적인 시스템 패키지에 대한 종속 항목이 있습니다. 대부분의 항목은 기본적으로 설치됩니다. 
[root@server ~]# yum install authconfig-gtk
Loaded plugins: langpacks, product-id, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package authconfig-gtk.x86_64 0:6.2.8-8.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package              Arch         Version            Repository           Size
================================================================================
Installing:
 authconfig-gtk       x86_64       6.2.8-8.el7        RHEL-Server       105 k

Transaction Summary
================================================================================
Install  1 Package

... 8< ...
Copy to Clipboard Toggle word wrap

2.2.3. authconfig UI 시작
링크 복사

  1. 터미널을 열고 root로 로그인합니다.
  2. system-config-authentication 명령을 실행합니다.
중요
authconfig UI가 종료되면 모든 변경 사항이 즉시 적용됩니다.
인증 대화 상자에는 세 가지 구성 탭이 있습니다.
  • ID 및 인증: ID 저장소로 사용되는 리소스(사용자 ID 및 해당 인증 정보가 저장된 데이터 리포지토리)를 구성합니다.
  • 고급 옵션: 스마트 카드 및 지문과 같은 암호 또는 인증서 이외의 인증 방법을 구성합니다.
  • 암호 인증 방법을 구성하는 암호 옵션.

그림 2.1. authconfig 창

authconfig 창
View larger image
authconfig 창

2.2.4. 인증 설정 테스트
링크 복사

인증이 완전히 올바르게 구성되어 있어야 합니다. 그렇지 않으면 모든 사용자(루트도)가 시스템에서 잠겨 있거나 일부 사용자가 차단될 수 있습니다.
test 옵션은 가능한 모든 ID 및 인증 메커니즘에 대해 시스템의 모든 인증 구성을 출력합니다. 그러면 활성화된 항목과 비활성화된 영역에 대한 설정이 모두 표시됩니다.
test 옵션은 자체적으로 실행하여 전체, 현재 구성을 표시하거나 authconfig 명령과 함께 사용하여 구성이 변경되는 방식을 표시할 수 있습니다(실제 변경 없이). 이 기능은 제안된 인증 설정이 완료되고 올바른지 확인하는 데 매우 유용할 수 있습니다. 
[root@server ~]# authconfig --test
caching is disabled
nss_files is always enabled
nss_compat is disabled
nss_db is disabled
nss_hesiod is disabled
 hesiod LHS = ""
 hesiod RHS = ""
nss_ldap is disabled
 LDAP+TLS is disabled
 LDAP server = ""
 LDAP base DN = ""
nss_nis is disabled
 NIS server = ""
 NIS domain = ""
nss_nisplus is disabled
nss_winbind is disabled
 SMB workgroup = "MYGROUP"
 SMB servers = ""
 SMB security = "user"
 SMB realm = ""
 Winbind template shell = "/bin/false"
 SMB idmap range = "16777216-33554431"
nss_sss is enabled by default
nss_wins is disabled
nss_mdns4_minimal is disabled
DNS preference over NSS or WINS is disabled
pam_unix is always enabled
 shadow passwords are enabled
 password hashing algorithm is sha512
pam_krb5 is disabled
 krb5 realm = "#"
 krb5 realm via dns is disabled
 krb5 kdc = ""
 krb5 kdc via dns is disabled
 krb5 admin server = ""
pam_ldap is disabled
 LDAP+TLS is disabled
 LDAP server = ""
 LDAP base DN = ""
 LDAP schema = "rfc2307"
pam_pkcs11 is disabled
 use only smartcard for login is disabled
 smartcard module = ""
 smartcard removal action = ""
pam_fprintd is disabled
pam_ecryptfs is disabled
pam_winbind is disabled
 SMB workgroup = "MYGROUP"
 SMB servers = ""
 SMB security = "user"
 SMB realm = ""
pam_sss is disabled by default
 credential caching in SSSD is enabled
 SSSD use instead of legacy services if possible is enabled
IPAv2 is disabled
IPAv2 domain was not joined
 IPAv2 server = ""
 IPAv2 realm = ""
 IPAv2 domain = ""
pam_pwquality is enabled (try_first_pass local_users_only retry=3 authtok_type=)
pam_passwdqc is disabled ()
pam_access is disabled ()
pam_mkhomedir or pam_oddjob_mkhomedir is disabled (umask=0077)
Always authorize local users is enabled ()
Authenticate system accounts against network services is disabled
Copy to Clipboard Toggle word wrap

2.2.5. authconfig를 사용하여 구성 저장 및 복원
링크 복사

인증 설정 변경에 문제가 있을 수 있습니다. 구성을 잘못 변경하면 액세스 권한이 있어야 하는 사용자를 잘못 제외하거나, ID 저장소에 대한 연결이 실패하거나 시스템에 대한 모든 액세스를 잠글 수 있습니다.
인증 구성을 편집하기 전에 관리자가 모든 구성 파일을 백업하는 것이 좋습니다. 이 작업은 --savebackup 옵션을 사용하여 수행합니다. 
[root@server ~]# authconfig --savebackup=/backups/authconfigbackup20200701
Copy to Clipboard Toggle word wrap
인증 구성은 사용할 백업 이름과 함께 --restorebackup 옵션을 사용하여 이전에 저장된 모든 버전으로 복원할 수 있습니다. 
[root@server ~]# authconfig --restorebackup=/backups/authconfigbackup20200701
Copy to Clipboard Toggle word wrap
authconfig 명령은 구성이 변경될 때마다 자동 백업을 저장합니다. restore lastbackup 옵션을 사용하여 마지막 백업을 복원 할 수 있습니다. 
[root@server ~]# authconfig --restorelastbackup
Copy to Clipboard Toggle word wrap

3장. authconfig를 사용한 인증용 ID 저장소 선택
링크 복사

authconfig UI의 ID 및 인증 탭에서는 사용자를 인증해야 하는 방법을 설정합니다. 기본값은 로컬 시스템 인증을 사용하는 것입니다. 즉, 사용자와 해당 암호를 로컬 시스템 계정에 대해 확인합니다. Red Hat Enterprise Linux 시스템은 LDAP, NIS, Winbind를 포함한 사용자와 자격 증명을 포함하는 외부 리소스를 사용할 수도 있습니다.

3.1. IPAv2
링크 복사

ID 관리 서버를 ID 백엔드로 구성하는 두 가지 다른 방법이 있습니다. IdM 버전 2(Red Hat Enterprise Linux 버전 6.3 및 이전 버전), 버전 3(Red Hat Enterprise Linux 6.4 이상) 및 버전 4(Red Hat Enterprise Linux 7.1 이상)의 경우 authconfig 에서 IPAv2 공급자로 구성됩니다. 이전 IdM 버전 및 커뮤니티 FreeIPA 서버의 경우 이러한 서버는 LDAP 프로바이더로 구성됩니다.

3.1.1. UI에서 IdM 구성
링크 복사

  1. authconfig UI를 엽니다.
  2. User Account Database 드롭다운 메뉴에서 IPAv2 를 선택합니다.

    그림 3.1. 인증 설정

    인증 설정
    View larger image
    인증 설정
  3. IdM 서버에 연결하는 데 필요한 정보를 설정합니다.
    • IPA 도메인 은 IdM 도메인의 DNS 도메인을 제공합니다.
    • IPA Cryo stat는 IdM 도메인의 Kerberos 도메인을 제공합니다.
    • IPA 서버는 IdM 도메인 토폴로지 내의 모든 IdM 서버의 호스트 이름을 제공합니다.
    • 클라이언트가 구성된 경우 NTP 서비스를 선택적으로 비활성화 하지 마십시오. IdM 서버와 모든 클라이언트가 Kerberos 인증 및 인증서가 제대로 작동하려면 클록을 동기화해야 하므로 이 방법은 일반적으로 권장되지 않습니다. IdM 서버가 도메인 내에서 호스팅하지 않고 다른 NTP 서버를 사용하는 경우 비활성화할 수 있습니다.
  4. 도메인 참여 버튼을 클릭합니다.
    그러면 ipa-client-install 명령을 실행하고 필요한 경우 ipa-client 패키지를 설치합니다. 설치 스크립트는 로컬 시스템에 필요한 모든 시스템 파일을 자동으로 구성하고 도메인 서버에 연결하여 도메인 정보를 업데이트합니다.

3.1.2. 명령줄에서 IdM 구성
링크 복사

IdM 도메인은 여러 공통적이고 중요한 여러 서비스를 하나의 계층 구조, 특히 DNS 및 Kerberos로 중앙 집중화합니다.
authconfig ( 8장. realmd 를 사용하여 ID 도메인에 연결에서 realmd 와 마찬가지로)는 IdM 도메인에 시스템을 등록하는 데 사용할 수 있습니다. 그러면 ipa-client-install 명령을 실행하고 필요한 경우 ipa-client 패키지를 설치합니다. 설치 스크립트는 로컬 시스템에 필요한 모든 시스템 파일을 자동으로 구성하고 도메인 서버에 연결하여 도메인 정보를 업데이트합니다.
도메인 가입에는 DNS 도메인 이름(--ipav2domain), Kerberos 영역 이름(--ipav2realm), 연결할 IdM 서버(--ipav2server)의 세 가지 정보가 필요합니다. --ipav2join 옵션은 IdM 서버 연결에 사용할 관리자 이름을 제공합니다. 이는 일반적으로 admin 입니다. 
[root@server ~]# authconfig --enableipav2 --ipav2domain=IPAEXAMPLE --ipav2realm=IPAEXAMPLE --ipav2server=ipaexample.com --ipav2join=admin
Copy to Clipboard Toggle word wrap
IdM 도메인이 자체 NTP 서비스를 실행하지 않는 경우 --disableipav2nontp 옵션을 사용하여 설정 스크립트가 IdM 서버를 NTP 서버로 사용하지 못하게 할 수 있습니다. IdM 서버와 모든 클라이언트가 Kerberos 인증 및 인증서가 제대로 작동하려면 클록을 동기화해야 하므로 일반적으로 이 방법은 권장되지 않습니다.

3.2. LDAP 및 IdM
링크 복사

표준 LDAP 디렉토리(예: OpenLDAP 및 Red Hat Directory Server)를 LDAP ID 프로바이더로 사용할 수 있습니다. 또한 이전 IdM 버전 및 FreeIPA는 관련 Kerberos 서버로 LDAP 프로바이더로 구성하여 ID 프로바이더로 구성할 수 있습니다.
openldap-clients 패키지 또는 sssd 패키지는 사용자 데이터베이스에 대한 LDAP 서버를 구성하는 데 사용됩니다. 두 패키지 모두 기본적으로 설치됩니다.

3.2.1. UI에서 LDAP 인증 구성
링크 복사

  1. 2.2.3절. “authconfig UI 시작” 에서와 같이 authconfig UI를 엽니다.
  2. User Account Database 드롭다운 메뉴에서 LDAP 를 선택합니다.
    View larger image
  3. LDAP 서버 연결에 필요한 정보를 설정합니다.
    • LDAP Search Base DN 은 사용자 디렉터리의 루트 접미사 또는 고유 이름 (DN)을 제공합니다. ID 또는 인증에 사용되는 모든 사용자 항목은 이 상위 항목 아래에 있습니다. 예를 들어 ou=people,dc=example,dc=com.
      이 필드는 선택 사항입니다. 지정하지 않으면 SSSD(System Security Services Daemon)에서 LDAP 서버 구성 항목에서 namingContexts 및 defaultNamingContext 특성을 사용하여 검색 기반을 탐지하려고 합니다.
    • LDAP 서버는 LDAP 서버의 URL을 제공합니다. 일반적으로 ldap://ldap.example.com:389 와 같은 LDAP 서버의 호스트 이름과 포트 번호가 필요합니다.
      ldaps:// 로 시작하는 URL을 사용하여 보안 프로토콜을 입력하면 인증 기관이 발급한 LDAP 서버의 발행 CA 인증서를 검색하는 CA 인증서 다운로드 버튼이 활성화됩니다. CA 인증서는 개인 정보 보호 강화 메일(PEM) 형식이어야 합니다.
    • 비보안 표준 포트 연결( ldap://부터 URL)을 사용하는 경우 Use TLS를 사용하여 연결 확인란을 사용하여 STARTTLS 를 사용하여 LDAP 서버와의 통신을 암호화할 수 있습니다. 이 확인란을 선택하면 CA 인증서 다운로드 버튼도 활성화됩니다.
      참고
      통신이 이미 암호화되어 있으므로 서버 URL에서 LDAPS(LDAP over SSL) 보안 프로토콜을 사용하는 경우 Use TLS to encrypt connections 확인란을 선택할 필요가 없습니다.
  4. 인증 방법을 선택합니다. LDAP는 간단한 암호 인증 또는 Kerberos 인증을 허용합니다.
    Kerberos 사용은 4.3.1절. “UI에서 Kerberos 인증 구성” 에 설명되어 있습니다.
    LDAP password 옵션은 PAM 애플리케이션을 사용하여 LDAP 인증을 사용합니다. 이 옵션을 사용하려면 LDAPS 또는 TLS를 사용하여 LDAP 서버에 연결함으로써 보안 연결을 설정해야 합니다.

3.2.2. 명령줄에서 LDAP 사용자 저장소 구성
링크 복사

LDAP ID 저장소를 사용하려면 --enableldap 을 사용합니다. LDAP를 인증 소스로 사용하려면 --enableldapauth 를 사용한 다음, LDAP 서버 이름, 사용자 접미사의 기본 DN, TLS 사용 여부와 같은 필수 연결 정보를 사용합니다. authconfig 명령에는 사용자 항목에 대해 RFC 2307bis 스키마를 활성화하거나 비활성화하는 옵션도 있으며 authconfig UI를 통해 사용할 수 없습니다.
프로토콜(ldap 또는 ldaps) 및 포트 번호를 포함하여 전체 LDAP URL을 사용해야 합니다. --enableldaptls 옵션과 함께 보안 LDAP URL(ldaps)을 사용하지 마십시오. 
authconfig --enableldap --enableldapauth --ldapserver=ldap://ldap.example.com:389,ldap://ldap2.example.com:389 --ldapbasedn="ou=people,dc=example,dc=com" --enableldaptls --ldaploadcacert=https://ca.server.example.com/caCert.crt --update
Copy to Clipboard Toggle word wrap
LDAP 암호 인증에 --ldapauth 를 사용하는 대신 LDAP 사용자 저장소에서 Kerberos를 사용할 수 있습니다. 이러한 옵션은 4.3.2절. “명령줄에서 Kerberos 인증 구성” 에 설명되어 있습니다.

3.3. NIS
링크 복사

중요
NIS를 ID 저장소로 구성하려면 NIS 자체를 환경에 맞게 구성해야 합니다.
  • NIS 서버는 사용자 계정을 설정하여 완전히 구성해야 합니다.
  • ypbind 패키지가 로컬 시스템에 설치되어 있어야 합니다. 이는 NIS 서비스에 필요하지만 기본적으로 설치되지 않습니다.
  • portmap 및 ypbind 서비스가 시작되고 부팅 시 시작되도록 활성화됩니다. 이는 ypbind 패키지 설치의 일부로 구성해야 합니다.

3.3.1. UI에서 NIS 인증 구성
링크 복사

  1. 2.2.3절. “authconfig UI 시작” 에서와 같이 authconfig UI를 엽니다.
  2. User Account Database 드롭다운 메뉴에서 NIS 를 선택합니다.
    View larger image
  3. NIS 도메인 이름과 서버 호스트 이름을 의미하는 NIS 서버에 연결할 정보를 설정합니다. NIS 서버를 지정하지 않으면 authconfig 데몬은 NIS 서버에서 검색합니다.
  4. 인증 방법을 선택합니다. NIS는 단순한 암호 인증 또는 Kerberos 인증을 허용합니다.
    Kerberos 사용은 4.3.1절. “UI에서 Kerberos 인증 구성” 에 설명되어 있습니다.

3.3.2. 명령줄에서 NIS 구성
링크 복사

NIS ID 저장소를 사용하려면 --enablenis 를 사용합니다. Kerberos 매개 변수가 명시적으로 설정되지 않은 한4.3.2절. “명령줄에서 Kerberos 인증 구성”NIS 인증을 자동으로 사용합니다. 유일한 매개 변수는 NIS 서버와 NIS 도메인을 식별하는 것입니다. 이러한 도메인을 사용하지 않는 경우 authconfig 서비스는 NIS 서버에서 네트워크를 검색합니다. 
[root@server ~]# authconfig --enablenis --nisdomain=EXAMPLE --nisserver=nis.example.com --update
Copy to Clipboard Toggle word wrap

3.4. winbind
링크 복사

Winbind를 시스템의 ID 저장소로 구성하기 전에 Samba를 구성해야 합니다. Samba 서버를 설정하고 사용자 계정에 사용해야 하거나 Samba를 백엔드 ID 저장소로 사용하도록 Samba를 구성해야 합니다.
Samba 구성은 Samba 프로젝트 문서에서 다룹니다. Samba를 Active Directory와 통합 지점으로 구체적으로 구성하는 것은 Windows 통합 가이드 의 Active Directory 통합에 Samba 사용 섹션에서도 다룹니다.

3.4.1. authconfig GUI에서 Winbind 활성화
링크 복사

  1. samba-winbind 패키지를 설치합니다. 이는 Samba 서비스의 Windows 통합 기능에 필요하지만 기본적으로 설치되지 않습니다. 
    [root@server ~]# yum install samba-winbind
    Copy to Clipboard Toggle word wrap
  2. authconfig UI를 엽니다. 
    [root2server ~]# authconfig-gtk
    Copy to Clipboard Toggle word wrap
  3. ID 및 인증 탭의 사용자 계정 데이터베이스 드롭다운 메뉴에서 Winbind 를 선택합니다.
    View larger image
  4. Microsoft Active Directory 도메인 컨트롤러에 연결하는 데 필요한 정보를 설정합니다.
    • winbind 도메인 은 연결할 Windows 도메인을 제공합니다.
      이는 DOMAIN 과 같은 Windows 2000 형식이어야 합니다.
    • Security Model 은 Samba 클라이언트에 사용할 보안 모델을 설정합니다. authconfig 는 다음 네 가지 유형의 보안 모델을 지원합니다.
      • ads 는 Active Directory Server 영역에서 도메인 멤버로 작동하도록 Samba를 구성합니다. 이 모드에서 작동하려면 krb5-server 패키지를 설치해야 하며 Kerberos를 올바르게 구성해야 합니다.
      • domain 은 Windows 서버와 유사하게 Windows 기본 또는 백업 도메인 컨트롤러를 통해 인증하여 사용자 이름과 암호를 검증합니다.
      • 서버에 는 로컬 Samba 서버가 Windows 서버와 같은 다른 서버를 통해 인증하여 사용자 이름과 암호의 유효성을 검사합니다. 서버 인증 시도가 실패하면 시스템은 사용자 모드를 사용하여 인증을 시도합니다.
      • 사용자가 유효한 사용자 이름과 암호를 사용하여 로그인해야 합니다. 이 모드는 암호화된 암호를 지원합니다.
        사용자 이름 형식은 domain\user 여야 합니다(예: EXAMPLE\jsmith ).
        참고
        지정된 사용자가 Windows 도메인에 있는지 확인하는 경우 항상 domain\user_name 형식을 사용하고 백슬래시(\) 문자를 이스케이프합니다. 예를 들어 다음과 같습니다. 
        [root@server ~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
        Copy to Clipboard Toggle word wrap
        기본 옵션입니다.
    • winbind ADS Cryostat 는 Samba 서버가 참여할 Active Directory 영역을 제공합니다. 이는 광고 보안 모델에만 사용됩니다.
    • winbind 도메인 컨트롤러는 시스템을 등록하는 데 사용할 도메인 컨트롤러의 호스트 이름 또는 IP 주소를 제공합니다.
    • 템플릿 쉘 은 Windows 사용자 계정 설정에 사용할 로그인 쉘을 설정합니다.
    • 오프라인 로그인을 허용 하면 인증 정보를 로컬 캐시에 저장할 수 있습니다. 사용자가 시스템이 오프라인 상태인 상태에서 시스템 리소스를 인증하려고 할 때 캐시를 참조합니다.

3.4.2. 명령줄에서 Winbind 활성화
링크 복사

Windows 도메인에는 여러 가지 보안 모델이 있으며 도메인에 사용되는 보안 모델은 로컬 시스템의 인증 구성을 결정합니다. 사용자 및 서버 보안 모델의 경우 Winbind 구성에는 도메인(또는 작업 그룹) 이름과 도메인 컨트롤러 호스트 이름만 필요합니다.
--winbindjoin 매개변수는 Active Directory 도메인에 연결하는 데 사용할 사용자를 설정하고 --enablelocalauthorize 는 로컬 권한 부여 작업을 설정하여 /etc/passwd 파일을 확인합니다.
authconfig 명령을 실행한 후 Active Directory 도메인에 참여합니다. 
[root@server ~]# authconfig --enablewinbind --enablewinbindauth --smbsecurity=user|server  --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --update --enablelocauthorize --winbindjoin=admin
[root@server ~]# net join ads
Copy to Clipboard Toggle word wrap
참고
사용자 이름 형식은 domain\user 여야 합니다(예: EXAMPLE\jsmith ).
지정된 사용자가 Windows 도메인에 있는지 확인하는 경우 항상 domain\user 형식을 사용하고 백슬래시(\) 문자를 이스케이프합니다. 예를 들어 다음과 같습니다. 
[root@server ~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
Copy to Clipboard Toggle word wrap
광고 및 도메인 보안 모델의 경우 Winbind 구성은 템플릿 쉘 및 영역에 대한 추가 구성을 허용합니다(ads only). 예를 들어 다음과 같습니다. 
[root@server ~]# authconfig --enablewinbind --enablewinbindauth --smbsecurity ads  --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --smbrealm EXAMPLE.COM --winbindtemplateshell=/bin/sh --update
Copy to Clipboard Toggle word wrap
Windows 기반 인증을 구성하는 다른 옵션과 이름 형식, 사용자 이름을 사용하여 도메인 이름 필요 여부, UID 범위 등의 Windows 사용자 계정에 대한 정보가 많이 있습니다. 이러한 옵션은 authconfig 도움말에 나열됩니다.

4장. 인증 메커니즘 구성
링크 복사

Red Hat Enterprise Linux는 다양한 인증 방법을 지원합니다. authconfig 툴을 사용하거나 경우에 따라 Identity Management 툴을 사용하여 구성할 수 있습니다.

4.1. authconfig를 사용하여 로컬 인증 구성
링크 복사

로컬 인증 옵션 영역은 백엔드에 저장된 사용자가 아닌 로컬 시스템 계정에 대한 설정을 정의합니다. 이러한 설정은 시스템 서비스에 대한 사용자 기반 권한 부여를 정의합니다( /etc/security/access.conf에 정의됨). 그렇지 않으면 인증 정책을 ID 프로바이더 또는 서비스 자체에 정의할 수 있습니다.

4.1.1. UI에서 로컬 액세스 제어 활성화
링크 복사

로컬 액세스 제어를 사용하면 시스템이 /etc/security/access.conf 파일에 로컬 사용자 권한 부여 규칙을 확인합니다. 이는 PAM 권한 부여입니다.

그림 4.1. 로컬 계정 필드

로컬 계정 필드
View larger image
로컬 계정 필드

4.1.2. 명령줄에서 로컬 액세스 제어 구성
링크 복사

authconfig 는 로컬 권한 부여 제어를 활성화하는 두 가지 옵션이 있습니다. --enablelocauthorize 는 네트워크 인증을 건너뛰고 시스템 사용자의 로컬 파일만 확인합니다. --enablepamaccess 는 /etc/security/access.conf 에서 시스템 권한 부여 정책을 찾도록 시스템을 구성합니다. 
[root@server ~]# authconfig --enablelocauthorize --enablepamaccess --update
Copy to Clipboard Toggle word wrap

4.2. authconfig를 사용하여 시스템 암호 구성
링크 복사

4.2.1. 암호 보안
링크 복사

암호가 일반 텍스트 형식으로 저장되면 크래킹, 무단 액세스 또는 변조에 취약합니다. 이를 방지하기 위해 암호화 해시 알고리즘을 사용하여 암호 해시 다이제스트를 안전하게 저장할 수 있습니다. IdM에서 지원되는 권장(기본값) 해시 알고리즘은 SHA-512로, 64비트 단어를 사용하고 솔트와 추가 보안을 위해 확장됩니다. 이전 버전과의 호환성을 보장하기 위해 SHA-256, DES, BigCrypt 및 MD5 해싱 알고리즘도 지원됩니다.
중요
이전 버전과의 호환성이 필요하지 않은 경우 SHA-512만 더 안전하므로 사용합니다.
4.2.1.1. UI에서 암호 해싱 구성
링크 복사
로컬 인증 옵션 탭은 시스템에 로컬 암호가 저장되는 방법을 설정합니다. 암호 해시 알고리즘 드롭다운 메뉴에서는 암호 해시를 안전하게 저장하도록 알고리즘을 설정합니다.
  1. 2.2.3절. “authconfig UI 시작” 에서와 같이 authconfig UI를 엽니다.
  2. 고급 옵션 탭을 엽니다.
  3. 암호 해시 알고리즘 드롭다운 메뉴에서 사용할 알고리즘을 선택합니다.
    View larger image
  4. Apply 버튼을 클릭합니다.
4.2.1.2. 명령줄에서 암호 해싱 구성
링크 복사
사용자 암호 다이제스트를 안전하게 저장하는 데 사용되는 해시 알고리즘을 설정하거나 변경하려면 --passalgo 옵션과 알고리즘의 짧은 이름을 사용합니다. 다음 예제에서는 SHA-512 알고리즘을 사용합니다. 
[root@server ~]# authconfig --passalgo=sha512 --update
Copy to Clipboard Toggle word wrap

4.2.2. 암호 복잡성
링크 복사

암호 복잡성 은 로컬 사용자 계정에 대해 암호를 설정할 수 있도록 하는 데 얼마나 강력한지 설정합니다. 복잡성은 길이와 문자 클래스의 변형의 조합입니다. 한 가지 방법은 암호(예: 대문자 및 특수 문자)에서 사용할 수 있는 문자 유형 식별과 암호 내에서 이러한 문자를 사용하는 방법(사용 가능한 시간 및 반복되는 문자 수)의 두 부분이 있다는 것입니다.
4.2.2.1. UI에서 암호 복잡성 구성
링크 복사
  1. 2.2.3절. “authconfig UI 시작” 에서와 같이 authconfig UI를 엽니다.
  2. 암호 옵션 탭을 엽니다.
    View larger image
  3. 암호에 대한 최소 요구 사항을 설정합니다.
    • 암호의 최소 길이
    • 암호에 사용해야 하는 최소 문자 클래스 수입니다.
  4. 암호에 사용해야 하는 문자 클래스를 활성화합니다. 예를 들어 대문자를 임의의 암호와 함께 사용할 수 있지만 대문자 확인란을 선택한 경우 모든 암호에서 대문자를 사용해야 합니다.
  5. 문자 또는 문자 클래스를 연속적으로 반복할 수 있는 횟수를 설정합니다. (이 값을 0으로 설정하면 반복 제한이 없습니다.)
    동일한 문자 필드의 경우 단일 문자 또는 문자를 반복할 수 있는 빈도를 설정합니다. 예를 들어 이 값을 2로 설정하면 ssecret 이 허용되지만 sssecret 은 거부됩니다.
    마찬가지로 Same 클래스는 문자 클래스 (대소문자, 숫자, 특수 문자)의 문자 수에 대한 제한을 설정합니다. 예를 들어 이 값이 3으로 설정된 경우 secret✓이 허용되지만 secret✓@ 또는 secret1234 가 거부됩니다.
  6. Apply 버튼을 클릭합니다.
4.2.2.2. 명령줄에서 암호 복잡성 구성
링크 복사
주석 줄에서 암호 복잡성을 정의할 때 요구 사항을 설정하는 데 절반이 있습니다. 첫 번째는 암호 생성 방법에 대한 요구 사항( 길이, 반복 가능, 그리고 사용해야 하는 문자 유형)을 설정하는 것입니다.
  • 최소 길이(--passminlen).
  • 사용해야 하는 다양한 유형의 최소 문자 수(--passminclass).
  • 문자가 연속적으로 반복될 수 있는 횟수(--passmaxrepeat). 이 값을 0으로 설정하면 반복 제한이 없음을 의미합니다.
  • 같은 문자 유형(예: 숫자)을 행(--passmaxclassrepeat)으로 사용할 수 있습니다. 이 값을 0으로 설정하면 반복 제한이 없음을 의미합니다.
나머지는 암호에 사용할 수 있는 문자의 유형 또는 클래스를 정의하는 것입니다. 모든 문자 유형은 암시적으로 허용됩니다 . --enablereqType 옵션을 사용하면 지정된 클래스가 완전히 필요하거나 암호가 거부됩니다. (따라서 유형도 명시적으로 거부할 수 있습니다.)
  • 대문자(--enablerequpper)
  • 소문자(--enablereqlower)
  • 숫자(--enablereqdigit)
  • 특수 문자 (--enablereqother)
예를 들어 최소 9자 길이를 설정하며 문자 또는 클래스를 두 번 이상 반복할 수 없으며 대문자 및 특수 문자가 모두 필요합니다. 
[root@server ~]# authconfig --passminlen=9 --passminclass=3 --passmaxrepeat=2 -passmaxclassrepeat=2 --enablerequpper --enablereqother --update
Copy to Clipboard Toggle word wrap

4.3. authconfig를 사용하여 Kerberos(LDAP 또는 NIS 포함) 구성
링크 복사

LDAP 및 NIS 인증 저장소는 모두 Kerberos 인증 방법을 지원합니다. Kerberos를 사용하면 다음과 같은 몇 가지 이점이 있습니다.
  • 표준 포트를 통한 연결을 계속 허용하면서 통신에 보안 계층을 사용합니다.
  • SSSD를 사용하여 인증 정보 캐싱을 자동으로 사용하므로 오프라인으로 로그인할 수 있습니다.
참고
Kerberos 인증을 사용하려면 krb5-libs 및 krb5-workstation 패키지가 필요합니다.

4.3.1. UI에서 Kerberos 인증 구성
링크 복사

Authentication Method 드롭다운 메뉴의 Kerberos password 옵션은 Kerberos 영역에 연결하는 데 필요한 필드를 자동으로 엽니다.

그림 4.2. Kerberos 필드

Kerberos 필드
View larger image
Kerberos 필드
  • realm 은 Kerberos 서버의 영역 이름을 제공합니다. 영역은 하나 이상의 KDC(키 배포 센터 ) 및 잠재적으로 많은 클라이언트로 구성된 Kerberos를 사용하는 네트워크입니다.
  • KDCs 는 Kerberos 티켓을 발행하는 쉼표로 구분된 서버 목록을 제공합니다.
  • 관리 서버는 영역에서 kadmind 프로세스를 실행하는 관리 서버 목록을 제공합니다.
  • 선택적으로 DNS를 사용하여 서버 호스트 이름을 확인하고 영역 내에서 추가 KDC를 찾습니다.

4.3.2. 명령줄에서 Kerberos 인증 구성
링크 복사

LDAP 및 NIS를 사용하면 Kerberos 인증을 기본 인증 메커니즘 대신 사용할 수 있습니다. 최소한 Kerberos 인증을 사용하려면 영역, KDC 및 관리 서버를 지정해야 합니다. DNS를 사용하여 클라이언트 이름을 확인하고 추가 관리 서버를 찾는 옵션도 있습니다. 
[root@server ~]# authconfig NIS or LDAP options --enablekrb5 --krb5realm EXAMPLE --krb5kdc kdc.example.com:88,server.example.com:88 --krb5adminserver server.example.com:749 --enablekrb5kdcdns --enablekrb5realmdns --update
Copy to Clipboard Toggle word wrap

4.4. 스마트 카드
링크 복사

스마트 카드를 기반으로 하는 인증은 암호 기반 인증 대신 사용됩니다. 사용자 자격 증명이 스마트 카드에 저장되고 특수 소프트웨어와 하드웨어를 사용하여 액세스하게 됩니다. 스마트 카드를 사용하여 인증하려면 사용자가 스마트 카드 리더에 스마트 카드를 둔 다음 스마트 카드의 PIN 코드를 제공해야 합니다.
중요
다음 섹션에서는 pam_pkcs11 및 pam_ krb5 패키지를 사용하여 로컬 사용자로 스마트 카드 인증을 위한 단일 시스템을 구성하는 방법에 대해 설명합니다. 7.4 릴리스 노트 의 더 이상 사용되지 않는 기능에 설명된 대로 이러한 패키지는 더 이상 사용되지 않습니다.
스마트 카드 인증을 중앙에서 구성하려면 SSSD(System Security Services Daemon)에서 제공하는 향상된 스마트 카드 기능을 사용합니다. 자세한 내용은 Linux 도메인 ID, 인증 및 정책 가이드의 ID 관리의 스마트 카드 인증에서 참조하십시오.

4.4.1. authconfig를 사용하여 스마트 카드 구성
링크 복사

스마트 카드 지원 활성화 옵션이 선택되면 스마트 카드의 동작을 구성하기 위한 추가 제어가 나타납니다.

그림 4.3. 스마트 카드 옵션

스마트 카드 옵션
View larger image
스마트 카드 옵션
Red Hat Enterprise Linux 서버 및 워크스테이션에 대한 스마트 카드 로그인은 기본적으로 활성화되어 있지 않으며 시스템 설정에서 활성화해야 합니다.
참고
Red Hat Enterprise Linux에 로그인할 때 SSO(Single Sign-On)를 사용하려면 다음 패키지가 필요합니다.
  • nss-tools
  • nss-pam-ldapd
  • esc
  • pam_pkcs11
  • pam_krb5
  • opensc
  • pcsc-lite-ccid
  • gdm
  • authconfig
  • authconfig-gtk
  • krb5-libs
  • krb5-workstation
  • krb5-pkinit
  • pcsc-lite
  • pcsc-lite-libs
4.4.1.1. UI에서 스마트 카드 인증 활성화
링크 복사
  1. 시스템에 root로 로그인합니다.
  2. 네트워크의 루트 CA 인증서를 base 64 형식으로 다운로드하여 서버에 설치합니다. 인증서는 certutil 명령을 사용하여 적절한 시스템 데이터베이스에 설치됩니다. 예를 들어 다음과 같습니다. 
    [root@server ~]# certutil -A -d /etc/pki/nssdb -n "root CA cert" -t "CT,C,C" -i /tmp/ca_cert.crt
    Copy to Clipboard Toggle word wrap
    참고
    가져온 인증서는 나중에 프로세스 중에 authconfig UI에 표시되지 않습니다. UI에는 인증서를 볼 수 없습니다. 인증 중에 /etc/pki/nssdb/ 디렉토리에서 가져옵니다.
  3. 상단 메뉴에서 애플리케이션 메뉴를 선택하고 Sundry 를 선택한 다음 인증을 클릭합니다.
  4. 고급 옵션 탭을 엽니다.
  5. 스마트 카드 지원 활성화 확인란을 클릭합니다.
  6. 스마트 카드에 대해 구성할 수 있는 두 가지 동작이 있습니다.
    • 카드 제거 작업 메뉴에서는 활성 세션 중에 스마트 카드가 제거되는 경우 시스템이 수행하는 응답을 설정합니다. Ignore 옵션은 스마트 카드를 제거하면 시스템이 화면 잠금을 즉시 잠그는 동안 시스템이 정상으로 작동함을 의미합니다.
    • 로그인에 스마트 카드 필요 확인란은 로그인 에 스마트 카드가 필요한지 여부를 설정합니다. 이 옵션을 선택하면 다른 모든 인증 방법이 차단됩니다.
      주의
      스마트 카드를 사용하여 성공적으로 로그인한 후에 이 항목을 선택하지 마십시오.
  7. 기본적으로 인증서가 취소되었는지 확인하는 메커니즘(Online Certificate Status Protocol 또는 OCSP, 응답)이 비활성화됩니다. 인증서가 만료일 이전에 취소되었는지 확인하려면 cert_policy 지시문에 ocsp_on 옵션을 추가하여 OCSP 검사를 활성화합니다.
    1. pam_pkcs11.conf 파일을 엽니다. 
      vim /etc/pam_pkcs11/pam_pkcs11.conf
      Copy to Clipboard Toggle word wrap
    2. ocsp_on 옵션이 포함되도록 모든 cert_policy 행을 변경합니다. 
      cert_policy = ca, ocsp_on, signature;
      Copy to Clipboard Toggle word wrap
      참고
      파일을 구문 분석하는 방식으로 인해 cert_policy 와 등호 기호 사이에 공백이 있어야 합니다. 그렇지 않으면 매개 변수를 구문 분석하지 못합니다.
  8. 스마트 카드가 아직 등록되지 않은 경우(개인 인증서 및 키를 사용하여 설정) 스마트 카드를 등록하십시오.
  9. 스마트 카드가 CAC 카드인 경우 CAC 사용자의 홈 디렉터리에 .k5login 파일을 만듭니다. CAC 카드에 Microsoft 보안 주체 이름을 사용하려면 .k5login 파일이 필요합니다.
  10. /etc/pam.d/smartcard-auth 및 /etc/pam.d/system-auth 파일에 다음 행을 추가합니다. 
    auth    optional    pam_krb5.so use_first_pass no_subsequent_prompt preauth_options=X509_user_identity=PKCS11:/usr/lib64/pkcs11/opensc-pkcs11.so
    Copy to Clipboard Toggle word wrap
    OpenSC 모듈이 예상대로 작동하지 않는 경우, coldkey 패키지의 모듈을 사용합니다: /usr/lib64/pkcs11/lib coolkey pk11.so. 이 경우 Red Hat 기술 지원에 문의하거나 문제에 대한 Bugzilla 보고서를 작성하는 것이 좋습니다.
  11. /etc/krb5.conf 파일을 구성합니다. 설정은 CAC 카드 사용 여부 또는 Gemalto 64K 카드 사용 여부에 따라 달라집니다.
    • CAC 카드를 사용하면 pkinit_anchors 에서 CAC 카드 사용과 관련된 모든 루트 인증서를 지정합니다. 다음 예에서 CAC 카드를 구성하기 위한 /etc/krb5.conf 파일인 EXAMPLE.COM 은 CAC 카드의 영역 이름이고 kdc.server.hostname.com 은 KDC 서버 호스트 이름입니다. 
      [logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

[libdefaults]
  dns_lookup_realm = false
  dns_lookup_kdc = false
  ticket_lifetime = 1h
  renew_lifetime = 6h
  forwardable = true

  default_realm = EXAMPLE.COM
[realms]
  EXAMPLE.COM = {
    kdc = kdc.server.hostname.com
    admin_server = kdc.server.hostname.com
    pkinit_anchors = FILE:/etc/pki/nssdb/ca_cert.pem
    pkinit_anchors = FILE:/etc/pki/nssdb/CAC_CA_cert.pem
    pkinit_anchors = FILE:/etc/pki/nssdb/CAC_CA_email_cert.pem
    pkinit_anchors = FILE:/etc/pki/nssdb/CAC_root_ca_cert.pem
    pkinit_cert_match = CAC card specific information
  }

[domain_realm]
  EXAMPLE.COM = EXAMPLE.COM
  .EXAMPLE.COM = EXAMPLE.COM

  .kdc.server.hostname.com = EXAMPLE.COM
  kdc.server.hostname.com = EXAMPLE.COM

[appdefaults]
    pam = {
      debug = true
      ticket_lifetime = 1h
      renew_lifetime = 3h
      forwardable = true
      krb4_convert = false
      mappings = username on the CAC card     Principal name on the card
    }
      Copy to Clipboard Toggle word wrap
    • 다음 예에서 Gemalto 64K 카드를 구성하기 위한 /etc/krb5.conf 파일에서 EXAMPLE.COM 은 KDC 서버에서 생성된 영역이며 kdc-ca.pem 은 CA 인증서이며 kdc.server.hostname.com 은 KDC 서버 호스트 이름입니다. 
      [logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

[libdefaults]
  dns_lookup_realm = false
  dns_lookup_kdc = false
  ticket_lifetime = 15m
  renew_lifetime = 6h
  forwardable = true

  default_realm = EXAMPLE.COM
[realms]
  EXAMPLE.COM = {
    kdc = kdc.server.hostname.com
    admin_server = kdc.server.hostname.com
    pkinit_anchors = FILE:/etc/pki/nssdb/kdc-ca.pem
    pkinit_cert_match = <KU>digitalSignature
    pkinit_kdc_hostname = kdc.server.hostname.com
  }

[domain_realm]
  EXAMPLE.COM = EXAMPLE.COM
  .EXAMPLE.COM = EXAMPLE.COM

  .kdc.server.hostname.com = EXAMPLE.COM
  kdc.server.hostname.com = EXAMPLE.COM

[appdefaults]
    pam = {
      debug = true
      ticket_lifetime = 1h
      renew_lifetime = 3h
      forwardable = true
      krb4_convert = false
    }
      Copy to Clipboard Toggle word wrap
참고
스마트 카드가 삽입되면 pklogin_finder 유틸리티는 디버그 모드에서 실행될 때 먼저 로그인 ID를 카드의 인증서에 매핑한 다음 인증서의 유효성에 대한 정보를 출력하려고 합니다. 
pklogin_finder debug
Copy to Clipboard Toggle word wrap
명령은 스마트 카드를 사용하여 시스템에 로그인하는 문제 진단에 유용합니다.
4.4.1.2. 명령줄에서 스마트 카드 인증 구성
링크 복사
시스템에서 스마트 카드를 사용하는 데 필요한 모든 것은 --enablesmartcard 옵션을 설정하는 것입니다. 
[root@server ~]# authconfig --enablesmartcard --update
Copy to Clipboard Toggle word wrap
기본 스마트 카드 모듈 변경, 스마트 카드가 제거될 때 시스템의 동작 설정, 로그인에 스마트 카드가 필요한 등의 다른 구성 옵션이 있습니다.
값이 0 이면 스마트 카드가 제거되면 즉시 사용자를 잠그도록 시스템에 지시합니다. 1 로 설정하면 스마트 카드가 제거되면 이를 무시합니다. 
[root@server ~]# authconfig --enablesmartcard --smartcardaction=0 --update
Copy to Clipboard Toggle word wrap
스마트 카드 인증이 성공적으로 구성되고 테스트되면 단순한 암호 기반 인증이 아닌 사용자에 대해 스마트 카드 인증을 요구하도록 시스템을 구성할 수 있습니다. 
[root@server ~]# authconfig --enablerequiresmartcard --update
Copy to Clipboard Toggle word wrap
주의
스마트 카드를 사용하여 시스템에 성공적으로 인증할 때까지 --enablerequiresmartcard 옵션을 사용하지 마십시오. 그렇지 않으면 사용자가 시스템에 로그인할 수 없을 수 있습니다.

4.4.2. ID 관리의 스마트 카드 인증
링크 복사

Red Hat Identity Management는 IdM 사용자를 위한 스마트 카드 인증을 지원합니다. 자세한 내용은 Linux 도메인 ID, 인증 및 정책 가이드의 ID 관리의 스마트 카드 인증 섹션을 참조하십시오.

4.4.3. 지원되는 스마트 카드
링크 복사

다음은 Red Hat Enterprise Linux에서 지원되는 스마트 카드 및 리더입니다.

스마트 카드

  • athena ASECard 스마트, pkcs15-unit
  • ATOS (시멘스) CardOS 5.0
  • Gemalto ID Classic 230 / IM CY2 64kv2
  • Gemalto Cyberflex Access 64k V2c
  • Gemalto GemPCKey USB 폼 팩터 키
  • G&D(Giesecke & Devrient) SmartCafe Expert 6.0 (SCP03)
  • G&D(Giesecke & Devrient) SmartCafe Expert 7.0 (SCP03)
  • safeNet 330J
  • safeNet SC650 (SCP01)
  • Siemens Card CardOS M4.4
  • 유비키 4

리더

  • 스마트 카드 리더가 내장된 HP 키보드 KUS1206
  • redhatkey 3121 리더
  • PID가 0x3022 리더인 사용자 지정 키 3121
  • Reiner SCT cyberJack komfort reader
  • SCR331 CCID 리더

4.5. 일회성 암호
링크 복사

일회성 암호(OTP)는 하나의 인증 세션에만 유효한 암호입니다. 사용 후 올바르지 않게 됩니다. 오랜 기간 동안 동일하게 유지되는 기존의 정적 암호와 달리 OTP는 계속 변경됩니다. OTP는 이중 인증의 일부로 사용됩니다. 첫 번째 단계에서는 사용자가 기존의 정적 암호로 인증해야 하고, 두 번째 단계는 인식된 인증 토큰에서 발급한 OTP에 대한 프롬프트를 표시합니다.
정적 암호와 결합된 OTP를 사용한 인증은 정적 암호만으로 사용하는 인증보다 더 안전하다고 간주됩니다. OTP는 성공적인 인증에 한 번만 사용할 수 있기 때문에 잠재적인 침입자가 로그인 중에 OTP를 가로채는 경우에도 가로채는 OTP는 해당 시점에서는 이미 유효하지 않습니다.
Red Hat Enterprise Linux에서 1회 암호
Red Hat Identity Management는 IdM 사용자에게 OTP 인증을 지원합니다. 자세한 내용은 Linux 도메인 ID, 인증 및 정책 가이드의 일회성 암호 섹션을 참조하십시오.

4.6. authconfig를 사용하여 지문 구성
링크 복사

4.6.1. UI에서 지문 인증 사용
링크 복사

사용 가능한 적절한 하드웨어가 있는 경우 지문 판독기 지원 옵션을 사용하면 지문 검사를 사용하여 다른 인증 정보 외에 로컬 사용자를 인증할 수 있습니다.

그림 4.4. 지문 옵션

지문 옵션
View larger image
지문 옵션

4.6.2. 명령줄에서 지문 인증 구성
링크 복사

지문 판독기에 대한 지원을 활성화하는 한 가지 옵션이 있습니다. 이 옵션은 단독으로 사용하거나 LDAP 사용자 저장소와 같은 다른 authconfig 설정과 함께 사용할 수 있습니다. 
[root@server ~]# authconfig --enablefingerprint --update
Copy to Clipboard Toggle word wrap

5장. authconfig를 사용하여 Kickstart 및 구성 파일 관리
링크 복사

update 옵션은 구성 변경 사항이 있는 모든 구성 파일을 업데이트합니다. 약간 다른 동작이 있는 몇 가지 대체 옵션이 있습니다.
  • --Kickstart 는 업데이트된 구성을 kickstart 파일에 씁니다.
  • --test 는 전체 구성을 변경 사항으로 표시하지만 구성 파일을 편집하지는 않습니다.
또한 authconfig 를 사용하여 이전 구성을 백업하고 복원할 수 있습니다. 모든 아카이브는 /var/lib/authconfig/ 디렉터리의 고유한 하위 디렉터리에 저장됩니다. 예를 들어 --savebackup 옵션은 2011-07-01 으로 백업 디렉토리를 제공합니다. 
[root@server ~]# authconfig --savebackup=2011-07-01
Copy to Clipboard Toggle word wrap
이렇게 하면 /var/lib/authconfig/backup-2011-07-01 디렉터리 아래의 모든 인증 구성 파일이 백업됩니다.
저장된 백업 중 하나를 사용하여 --restorebackup 옵션을 사용하여 구성을 복원하여 수동으로 저장된 구성 이름을 지정할 수 있습니다. 
[root@server ~]# authconfig --restorebackup=2011-07-01
Copy to Clipboard Toggle word wrap
또한 authconfig 는 변경 사항을 적용하기 전에 구성 백업을 자동으로 수행합니다( --update 옵션 사용). 구성은 --restorelastbackup 옵션을 사용하여 정확한 백업을 지정하지 않고도 최신 자동 백업에서 복원할 수 있습니다.

6장. authconfig를 사용하여 사용자 정의 홈 디렉터리 활성화
링크 복사

LDAP 사용자에게 /home 에 없는 홈 디렉터리가 있고 사용자가 처음 로그인할 때 홈 디렉토리를 생성하도록 시스템이 구성된 경우 이러한 디렉터리는 잘못된 권한으로 생성됩니다.
  1. /home 디렉터리의 올바른 SELinux 컨텍스트 및 권한을 로컬 시스템에 생성된 홈 디렉터리에 적용합니다. 예를 들어 다음과 같습니다. 
    [root@server ~]# semanage fcontext -a -e /home /home/locale
    Copy to Clipboard Toggle word wrap
  2. 시스템에 oddjob-mkhomedir 패키지를 설치합니다.
    이 패키지는 authconfig 명령이 홈 디렉터리를 생성하는 데 사용하는 pam_oddjob_mkhomedir.so 라이브러리를 제공합니다. pam_oddjob_mkhomedir.so 라이브러리는 기본 pam_mkhomedir.so 라이브러리와 달리 SELinux 레이블을 생성할 수 있습니다.
    authconfig 명령은 사용 가능한 경우 pam_oddjob_mkhomedir.so 라이브러리를 자동으로 사용합니다. 그렇지 않으면 기본적으로 pam_mkhomedir.so 를 사용합니다.
  3. oddjobd 서비스가 실행 중인지 확인합니다.
  4. authconfig 명령을 실행하고 홈 디렉터리를 활성화합니다. 명령줄에서 이 작업은 --enablemkhomedir 옵션을 통해 수행됩니다. 
    [root@server ~]# authconfig --enablemkhomedir --update
    Copy to Clipboard Toggle word wrap
    UI에는 사용자가 처음 로그인할 때 자동으로홈 디렉터리를 생성하기 위한 고급 옵션 탭(첫 번째 로그인 시 홈 디렉터리 만들기)에 옵션이 있습니다.

    그림 6.1. 홈 디렉토리 옵션

    홈 디렉토리 옵션
    View larger image
    홈 디렉토리 옵션
    이 옵션은 LDAP와 같이 중앙 집중 방식으로 관리되는 계정에 유용합니다. 그러나 자동 마운트와 같은 시스템을 사용하여 사용자 홈 디렉토리를 관리하는 경우 이 옵션을 선택해서는 안 됩니다.
홈 디렉토리 구성이 변경되기 전에 홈 디렉토리를 만든 경우 권한과 SELinux 컨텍스트를 수정합니다. 예를 들어 다음과 같습니다. 
[root@server ~]# semanage fcontext -a -e /home /home/locale
# restorecon -R -v /home/locale
Copy to Clipboard Toggle word wrap

II 부. ID 및 인증 저장소
링크 복사

이 부분에서는SSSD( System Security Services Daemon ) 구성 방법, realmd 툴을 사용하여 ID 도메인에 연결하는 방법, OpenLDAP 서버를 설치, 구성 및 실행하는 방법을 설명합니다.

7장. SSSD 구성
링크 복사

7.1. SSSD 소개
링크 복사

7.1.1. SSSD 작동 방식
링크 복사

SSSD(시스템 보안 서비스 데몬)는 원격 디렉터리 및 인증 메커니즘에 액세스하기 위한 시스템 서비스입니다. 로컬 시스템(SSSD 클라이언트)을 외부 백엔드 시스템( 프로바이더)에 연결합니다. 이렇게 하면 SSSD 클라이언트가 SSSD 공급자를 사용하여 ID 및 인증 원격 서비스에 액세스할 수 있습니다. 예를 들어, 이러한 원격 서비스에는 LDAP 디렉터리, IdM(Identity Management) 또는 AD(Active Directory) 도메인 또는 Kerberos 영역이 포함됩니다.
이 목적을 위해 SSSD:
  1. 클라이언트를 ID 저장소에 연결하여 인증 정보를 검색합니다.
  2. 가져온 인증 정보를 사용하여 클라이언트에서 사용자 및 자격 증명의 로컬 캐시를 생성합니다.
그런 다음 로컬 시스템의 사용자는 외부 백엔드 시스템에 저장된 사용자 계정을 사용하여 인증할 수 있습니다.
SSSD는 로컬 시스템에서 사용자 계정을 생성하지 않습니다. 대신 외부 데이터 저장소의 ID를 사용하고 사용자가 로컬 시스템에 액세스할 수 있도록 합니다.

그림 7.1. SSSD 작동 방식

SSSD 작동 방식
View larger image
SSSD 작동 방식
SSSD는 NSS(Name Service Switch) 또는 PAM(Pluggable Authentication Modules)과 같은 여러 시스템 서비스에 대한 캐시를 제공할 수도 있습니다.

7.1.2. SSSD 사용의 이점
링크 복사

ID 및 인증 서버에 대한 로드 감소
정보를 요청할 때 SSSD 클라이언트는 캐시를 확인하는 SSSD에 문의합니다. SSSD는 캐시에서 정보를 사용할 수 없는 경우에만 서버에 연결합니다.
오프라인 인증
SSSD는 선택적으로 원격 서비스에서 검색된 사용자 ID 및 자격 증명의 캐시를 유지합니다. 이 설정에서는 원격 서버 또는 SSSD 클라이언트가 오프라인 상태인 경우에도 사용자가 리소스에 성공적으로 인증할 수 있습니다.
단일 사용자 계정: 인증 프로세스의 일관성 향상
SSSD에서는 오프라인 인증을 위해 중앙 계정과 로컬 사용자 계정을 모두 유지 관리할 필요가 없습니다.
원격 사용자에게는 종종 여러 사용자 계정이 있습니다. 예를 들어 VPN(가상 사설 네트워크)에 연결하려면 원격 사용자는 로컬 시스템을 위한 하나의 계정과 VPN 시스템의 다른 계정을 보유합니다.
원격 사용자는 캐싱 및 오프라인 인증으로 간단하게 로컬 시스템에 인증하여 네트워크 리소스에 연결할 수 있습니다. 그런 다음 SSSD에서 네트워크 자격 증명을 유지합니다.

7.2. 클라이언트별 bais에서 여러 SSSD 구성 파일 사용
링크 복사

SSSD의 기본 설정 파일은 /etc/sssd/sssd.conf 입니다. SSSD는 이 파일 외에도 /etc/sssd/conf.d/ 디렉터리의 모든 *.conf 파일에서 구성을 읽을 수 있습니다.
예를 들어 모든 클라이언트에서 기본 /etc/sssd/sssd.conf 파일을 사용하고 추가 구성 파일에 추가 설정을 추가하여 클라이언트별로 기능을 개별적으로 확장할 수 있습니다.
SSSD 프로세스 설정 파일
SSSD는 다음 순서로 구성 파일을 읽습니다.
  1. 기본 /etc/sssd/sssd.conf 파일
  2. 기타 *.conf 파일 /etc/sssd/conf.d/, 알파벳순으로
동일한 매개 변수가 여러 구성 파일에 표시되는 경우 SSSD는 마지막 읽기 매개 변수를 사용합니다.
참고
SSSD는 conf .d 디렉토리에서 숨겨진 파일(..로 시작하는 파일)을 읽지 않습니다.

7.3. SSSD의 ID 및 인증 공급자 구성
링크 복사

7.3.1. SSSD의 ID 및 인증 공급자 소개
링크 복사

SSSD 도메인. ID 및 인증 공급자
ID 및 인증 프로바이더는 SSSD 구성 파일의 도메인으로 구성됩니다. 단일 도메인을 다음과 같이 사용할 수 있습니다.
  • ID 공급자 (사용자 정보용)
  • 인증 공급자 (인증 요청용)
  • 액세스 제어 공급자 (허용 요청용)
  • 이러한 공급자의 조합 (모든 해당 작업이 단일 서버 내에서 수행되는 경우)
SSSD에 대해 여러 도메인을 구성할 수 있습니다. 하나 이상의 도메인을 구성해야 합니다. 그렇지 않으면 SSSD가 시작되지 않습니다.
/etc/sssd/sssd.conf 파일의 access_provider 옵션은 도메인에 사용되는 액세스 제어 공급자를 설정합니다. 기본적으로 옵션은 항상 모든 액세스를 허용하는 용으로 설정됩니다. 자세한 내용은 sssd.conf(5) 도움말 페이지를 참조하십시오.
프록시 공급자
프록시 공급자는 SSSD와 SSSD에서 사용할 수 없는 리소스 간의 중간 릴레이 역할을 합니다. 프록시 공급자를 사용하는 경우 SSSD는 프록시 서비스에 연결하고 프록시는 지정된 라이브러리를 로드합니다.
프록시 공급자를 사용하여 다음을 사용하도록 SSSD를 구성할 수 있습니다.
  • 지문 스캐너와 같은 대체 인증 방법
  • NIS와 같은 레거시 시스템
  • /etc/passwd 및 원격 인증에 정의된 로컬 시스템 계정
ID 및 인증 공급자의 사용 가능한 조합
Expand
표 7.1. ID 및 인증 공급자의 사용 가능한 조합
ID 공급자 인증 공급자
IdM (Identity Management) [a] Identity Management [a]
Active Directory [a] Active Directory [a]
LDAP LDAP
LDAP Kerberos
proxy proxy
proxy LDAP
proxy Kerberos
[a] LDAP 프로바이더 유형의 확장입니다.
이 가이드에서는 모든 프로바이더 유형을 설명하지는 않습니다. 자세한 내용은 다음 추가 리소스를 참조하십시오.

7.3.2. SSSD의 LDAP 도메인 구성
링크 복사

사전 요구 사항
  • SSSD 설치. 
    # yum install sssd
    Copy to Clipboard Toggle word wrap
LDAP 도메인을 검색하도록 SSSD 설정
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. LDAP 도메인에 대한 [domain] 섹션을 생성합니다. 
    [domain/LDAP_domain_name]
    Copy to Clipboard Toggle word wrap
  3. LDAP 서버를 ID 공급자, 인증 공급자 또는 둘 다로 사용하려는 경우 를 지정합니다.
    1. LDAP 서버를 ID 공급자로 사용하려면 id_provider 옵션을 ldap 로 설정합니다.
    2. LDAP 서버를 인증 공급자로 사용하려면 auth_provider 옵션을 ldap 로 설정합니다.
    예를 들어 LDAP 서버를 둘 다 사용하려면 다음을 수행합니다. 
    [domain/LDAP_domain_name]
id_provider = ldap
auth_provider = ldap
    Copy to Clipboard Toggle word wrap
  4. LDAP 서버를 지정합니다. 다음 중 하나를 선택합니다.
    1. 서버를 명시적으로 정의하려면 ldap_uri 옵션을 사용하여 서버의 URI를 지정합니다. 
      [domain/LDAP_domain_name]
id_provider = ldap
auth_provider = ldap

ldap_uri = ldap://ldap.example.com
      Copy to Clipboard Toggle word wrap
      ldap_uri 옵션은 서버의 IP 주소도 허용합니다. 그러나 서버 이름 대신 IP 주소를 사용하면 TLS/SSL 연결이 실패할 수 있습니다. Red Hat Knowledgebase의 인증서 주체 이름에서 IP 주소를 사용하도록 SSSD 공급자 구성을 참조하십시오.
    2. DNS 서비스 검색을 사용하여 서버를 동적으로 검색하도록 SSSD를 구성하려면 7.4.3절. “DNS 서비스 검색 구성” 을 참조하십시오.
    선택적으로 ldap_backup_uri 옵션에 백업 서버를 지정합니다.
  5. ldap_search_base 옵션에 LDAP 서버의 검색 기반을 지정합니다. 
    [domain/LDAP_domain_name]
id_provider = ldap
auth_provider = ldap

ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
    Copy to Clipboard Toggle word wrap
  6. LDAP 서버에 대한 보안 연결을 설정하는 방법을 지정합니다. 권장되는 방법은 TLS 연결을 사용하는 것입니다. 이렇게 하려면 ldap_id_use_start_tls 옵션을 활성화하고 이러한 CA 인증서 관련 옵션을 사용합니다.
    • ldap_tls_reqcert 는 클라이언트가 서버 인증서를 요청하는지 및 인증서에서 수행되는 검사를 지정합니다.
    • ldap_tls_cacert 는 인증서가 포함된 파일을 지정합니다. 
    [domain/LDAP_domain_name]
id_provider = ldap
auth_provider = ldap

ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com

ldap_id_use_start_tls = true
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
    Copy to Clipboard Toggle word wrap
    참고
    SSSD는 항상 암호화된 채널을 인증을 위해 사용하므로 암호가 암호화되지 않은 네트워크를 통해 전송되지 않습니다. ldap_id_use_start_tls = true 에서는 ID 조회(예: id 또는 getent 유틸리티를 기반으로 하는 명령)도 암호화됩니다.
  7. [sssd] 섹션의 domain 옵션에 새 도메인을 추가합니다. 옵션은 SSSD에서 쿼리하는 도메인을 나열합니다. 예를 들어 다음과 같습니다. 
    domains = LDAP_domain_name, domain2
    Copy to Clipboard Toggle word wrap
추가 리소스
위 절차에서는 LDAP 프로바이더에 대한 기본 옵션을 보여줍니다. 자세한 내용은 다음을 참조하십시오.
  • sssd.conf(5) 도움말 페이지: 모든 유형의 도메인에 사용 가능한 글로벌 옵션을 설명합니다.
  • LDAP와 관련된 옵션을 설명하는 sssd-ldap(5) 도움말 페이지

7.3.3. SSSD의 파일 공급자 구성
링크 복사

파일 공급자는 SSSD를 통해 이러한 파일에서 사용자와 그룹을 사용할 수 있도록 /etc/passwd 및 /etc/groups 파일의 콘텐츠를 미러링합니다. 이를 통해 /etc/nsswitch.conf 파일에서 사용자 및 그룹의 첫 번째 소스로 sss 데이터베이스를 설정할 수 있습니다. 
passwd:     sss files
group:      sss files
Copy to Clipboard Toggle word wrap
이 설정을 통해 파일 공급자가 /etc/sssd/sssd.conf 에 구성된 경우 Red Hat Enterprise Linux는 사용자 및 그룹에 대한 모든 쿼리를 먼저 SSSD로 보냅니다. SSSD가 실행 중이 아니거나 SSSD가 요청된 항목을 찾을 수 없는 경우 시스템은 로컬 파일에서 사용자와 그룹을 찾을 수 없습니다. LDAP 디렉터리와 같은 중앙 데이터베이스에 대부분의 사용자와 그룹을 저장하는 경우 이 설정은 사용자 및 그룹 조회의 속도를 높입니다.
사전 요구 사항
  • SSSD 설치. 
    # yum install sssd
    Copy to Clipboard Toggle word wrap
파일 도메인을 검색하도록 SSSD 구성
  1. /etc/sssd/sssd.conf 파일에 다음 섹션을 추가합니다. 
    [domain/files]
id_provider = files
    Copy to Clipboard Toggle word wrap
  2. 선택적으로 /etc/sssd/sssd.conf 파일에서 사용자 및 그룹 조회의 첫 번째 소스로 sss 데이터베이스를 설정합니다. 
    passwd:     sss files
group:      sss files
    Copy to Clipboard Toggle word wrap
  3. 시스템이 부팅될 때 sssd 서비스가 시작되는 방식으로 시스템을 구성합니다. 
    # systemctl enable sssd
    Copy to Clipboard Toggle word wrap
  4. sssd 서비스를 다시 시작합니다. 
    # systemctl restart sssd
    Copy to Clipboard Toggle word wrap
추가 리소스
위의 절차에서는 파일 공급자에 대한 기본 옵션을 보여줍니다. 자세한 내용은 다음을 참조하십시오.
  • sssd.conf(5) 도움말 페이지: 모든 유형의 도메인에 사용 가능한 글로벌 옵션을 설명합니다.
  • 파일 공급자와 관련된 옵션을 설명하는 sssd-files(5) 도움말 페이지

7.3.4. SSSD용 프록시 공급자 구성
링크 복사

사전 요구 사항
  • SSSD 설치. 
    # yum install sssd
    Copy to Clipboard Toggle word wrap
프록시 도메인을 검색하도록 SSSD 구성
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. 프록시 공급자에 대한 [domain] 섹션을 생성합니다. 
    [domain/proxy_name]
    Copy to Clipboard Toggle word wrap
  3. 인증 공급자를 지정하려면 다음을 수행합니다.
    1. auth_provider 옵션을 proxy 로 설정합니다.
    2. proxy_pam_target 옵션을 사용하여 PAM 서비스를 인증 프록시로 지정합니다.
    예를 들어 다음과 같습니다. 
    [domain/proxy_name]
auth_provider = proxy
proxy_pam_target = sssdpamproxy
    Copy to Clipboard Toggle word wrap
    중요
    프록시 PAM 스택에 pam_sss.so 가 재귀적으로 포함되지 않는지 확인합니다.
  4. ID 공급자를 지정하려면 다음을 수행합니다.
    1. id_provider 옵션을 proxy 로 설정합니다.
    2. proxy_lib_name 옵션을 사용하여 NSS 라이브러리를 ID 프록시로 지정합니다.
    예를 들어 다음과 같습니다. 
    [domain/proxy_name]
id_provider = proxy
proxy_lib_name = nis
    Copy to Clipboard Toggle word wrap
  5. [sssd] 섹션의 domain 옵션에 새 도메인을 추가합니다. 옵션은 SSSD에서 쿼리하는 도메인을 나열합니다. 예를 들어 다음과 같습니다. 
    domains = proxy_name, domain2
    Copy to Clipboard Toggle word wrap
추가 리소스
위 절차에서는 프록시 프로바이더에 대한 기본 옵션을 보여줍니다. 자세한 내용은 모든 유형의 도메인 및 기타 프록시 관련 옵션에 사용할 수 있는 글로벌 옵션을 설명하는 sssd.conf(5) 도움말 페이지를 참조하십시오.

7.3.5. Kerberos 인증 공급자 구성
링크 복사

사전 요구 사항
  • SSSD 설치. 
    # yum install sssd
    Copy to Clipboard Toggle word wrap
Kerberos 도메인을 검색하도록 SSSD 구성
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. SSSD 도메인의 [domain] 섹션을 생성합니다. 
    [domain/Kerberos_domain_name]
    Copy to Clipboard Toggle word wrap
  3. ID 공급자를 지정합니다. 예를 들어 LDAP ID 공급자 구성에 대한 자세한 내용은 7.3.2절. “SSSD의 LDAP 도메인 구성” 을 참조하십시오.
    지정된 ID 프로바이더에서 Kerberos 주체 이름을 사용할 수 없는 경우 SSSD는 username@REALM 형식을 사용하여 주체를 구성합니다.
  4. Kerberos 인증 공급자 세부 정보를 지정합니다.
    1. auth_provider 옵션을 krb5 로 설정합니다. 
      [domain/Kerberos_domain_name]
id_provider = ldap
auth_provider = krb5
      Copy to Clipboard Toggle word wrap
    2. Kerberos 서버를 지정합니다.
      1. 서버를 명시적으로 정의하려면 krb5_server 옵션을 사용합니다. 옵션은 서버의 호스트 이름 또는 IP 주소를 허용합니다. 
        [domain/Kerberos_domain_name]
id_provider = ldap
auth_provider = krb5

krb5_server = kdc.example.com
        Copy to Clipboard Toggle word wrap
      2. DNS 서비스 검색을 사용하여 서버를 동적으로 검색하도록 SSSD를 구성하려면 7.4.3절. “DNS 서비스 검색 구성” 을 참조하십시오.
      선택적으로 krb5_backup_server 옵션에 백업 서버를 지정합니다.
    3. 암호 변경 서비스가 krb5_server 또는 krb5_backup_server 에 지정된 KDC에서 실행되지 않는 경우 krb5_passwd 옵션을 사용하여 서비스가 실행 중인 서버를 지정합니다. 
      [domain/Kerberos_domain_name]
id_provider = ldap
auth_provider = krb5

krb5_server = kdc.example.com
krb5_backup_server = kerberos.example.com
krb5_passwd = kerberos.admin.example.com
      Copy to Clipboard Toggle word wrap
      krb5_passwd 를 사용하지 않는 경우 SSSD는 krb5_server 또는 krb5_backup_server 에 지정된 KDC를 사용합니다.
    4. krb5_realm 옵션을 사용하여 Kerberos 영역의 이름을 지정합니다. 
      [domain/Kerberos_domain_name]
id_provider = ldap
auth_provider = krb5

krb5_server = kerberos.example.com
krb5_backup_server = kerberos2.example.com
krb5_passwd = kerberos.admin.example.com
krb5_realm = EXAMPLE.COM
      Copy to Clipboard Toggle word wrap
  5. [sssd] 섹션의 domain 옵션에 새 도메인을 추가합니다. 옵션은 SSSD에서 쿼리하는 도메인을 나열합니다. 예를 들어 다음과 같습니다. 
    domains = Kerberos_domain_name, domain2
    Copy to Clipboard Toggle word wrap
추가 리소스
위의 절차에서는 Kerberos 프로바이더의 기본 옵션을 보여줍니다. 자세한 내용은 다음을 참조하십시오.
  • sssd.conf(5) 도움말 페이지: 모든 유형의 도메인에 사용 가능한 글로벌 옵션을 설명합니다.
  • Kerberos와 관련된 옵션을 설명하는 sssd-krb5(5) 도움말 페이지

7.4. ID 및 인증 공급자에 대한 추가 구성
링크 복사

7.4.1. 사용자 이름 형식 조정
링크 복사

7.4.1.1. 전체 사용자 이름 구문 분석에 대한 정규 표현식 정의
링크 복사
SSSD는 전체 사용자 이름 문자열을 사용자 이름 및 도메인 구성 요소로 구문 분석합니다. 기본적으로 SSSD는 Python 구문의 다음 정규식을 기반으로 user_name@domain_name 형식의 전체 사용자 이름을 해석합니다. 
(?P<name>[^@]+)@?(?P<domain>[^@]*$)
Copy to Clipboard Toggle word wrap
참고
Identity Management 및 Active Directory 공급자의 경우 기본 사용자 이름 형식은 user_name@domain_name 또는 NetBIOS_name\user_name 입니다.
SSSD에서 전체 사용자 이름을 해석하는 방법을 조정하려면 다음을 수행합니다.
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. re_expression 옵션을 사용하여 사용자 지정 정규식을 정의합니다.
    1. 모든 도메인에 대해 정규 표현식을 전역적으로 정의하려면 sssd.conf 의 [sssd] 섹션에 re_expression 을 추가합니다.
    2. 특정 도메인에 대해 정규식을 개별적으로 정의하려면 sssd.conf 의 해당 도메인 섹션에 re_expression 을 추가합니다.
예를 들어 LDAP 도메인의 정규 표현식을 구성하려면 다음을 수행합니다. 
[domain/LDAP]
[... file truncated ...]
re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
Copy to Clipboard Toggle word wrap
자세한 내용은 sssd.conf(5) 도움말 페이지의 SPECIALTIONS 및 DOMAINDOMAINTIONS 부분에서 re_expression 에 대한 설명을 참조하십시오.
7.4.1.2. SSSD가 전체 사용자 이름을 출력하는 방법 정의
링크 복사
/etc/sssd/sssd.conf 파일에서 use_fully_qualified_names 옵션이 활성화된 경우 SSSD는 기본적으로 다음 확장을 기반으로 이름@domain 형식으로 전체 사용자 이름을 출력합니다. 
%1$s@%2$s
Copy to Clipboard Toggle word wrap
참고
use_fully_qualified_names 가 설정되지 않았거나 신뢰할 수 있는 도메인에 대해 명시적으로 false 로 설정된 경우 도메인 구성 요소 없이 사용자 이름만 출력됩니다.
SSSD에서 전체 사용자 이름을 출력하는 형식을 조정하려면 다음을 수행합니다.
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. full_name_format 옵션을 사용하여 전체 사용자 이름 형식의 확장을 정의합니다.
    1. 모든 도메인에 대해 전역적으로 확장을 정의하려면 sssd.conf 의 [sssd] 섹션에 full_name_format 을 추가합니다.
    2. 특정 도메인에 대해 개별적으로 확장을 정의하려면 sssd.conf 의 해당 domain 섹션에 full_name_format 을 추가합니다.
자세한 내용은 sssd.conf(5) 도움말 페이지의 SPECIALTIONS 및 DOMAIN AlertsTIONS 부분에서 full_name_format 에 대한 설명을 참조하십시오.
일부 이름 구성에서는 SSSD에서 이름의 도메인 구성 요소를 제거하여 인증 오류가 발생할 수 있습니다. 이로 인해 full_name_format 을 비표준 값으로 설정하면 경고에 더 표준 형식으로 변경하라는 메시지가 표시됩니다.

7.4.2. 오프라인 인증 활성화
링크 복사

SSSD는 기본적으로 사용자 자격 증명을 캐시하지 않습니다. 인증 요청을 처리할 때 SSSD는 항상 ID 공급자에 연결합니다. 공급자를 사용할 수 없는 경우 사용자 인증에 실패합니다.
중요
SSSD는 일반 텍스트로 암호를 캐시하지 않습니다. 암호의 해시만 저장합니다.
사용자가 ID 공급자를 사용할 수 없는 경우에도 인증할 수 있도록 인증하려면 인증 정보 캐싱을 활성화합니다.
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. domain 섹션에서 cache_credentials = true 설정을 추가합니다. 
    [domain/domain_name]
cache_credentials = true
    Copy to Clipboard Toggle word wrap
  3. 선택 사항이지만 권장되는 옵션입니다. ID 공급자를 사용할 수 없는 경우 SSSD에서 오프라인 인증을 허용하는 기간을 설정합니다.
    1. SSSD에서 작동하도록 PAM 서비스를 구성합니다. 7.5.2절. “서비스 구성: PAM” 참조하십시오.
    2. offline_credentials_expiration 옵션을 사용하여 시간 제한을 지정합니다. 예를 들어 마지막으로 로그인한 후 사용자가 3일 동안 오프라인 인증을 받을 수 있도록 지정하려면 다음을 수행합니다. 
      [pam]
offline_credentials_expiration = 3
      Copy to Clipboard Toggle word wrap
offline_credentials_expiration 에 대한 자세한 내용은 sssd.conf(5) 도움말 페이지를 참조하십시오.

7.4.3. DNS 서비스 검색 구성
링크 복사

/etc/sssd/sssd.conf 파일에 ID 또는 인증 서버가 명시적으로 정의되지 않은 경우 SSSD에서 DNS 서비스 검색을사용하여 동적으로 서버를 검색할 수 있습니다. [1].
예를 들어 sssd.conf 에 id_provider = ldap 설정이 포함되어 있지만 ldap_uri 옵션이 호스트 이름 또는 IP 주소를 지정하지 않는 경우 SSSD는 DNS 서비스 검색을 사용하여 서버를 동적으로 검색합니다.
참고
SSSD는 기본 서버만 사용하여 백업 서버를 동적으로 검색할 수 없습니다.
DNS 서비스 검색을 위한 SSSD 구성
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. 기본 서버 값을 _srv_ 로 설정합니다. LDAP 공급자의 경우 기본 서버는 ldap_uri 옵션을 사용하여 설정됩니다. 
    [domain/domain_name]
id_provider = ldap
ldap_uri = _srv_
    Copy to Clipboard Toggle word wrap
  3. 서비스 유형을 설정하여 암호 변경 공급자에서 서비스 검색을 활성화합니다. 
    [domain/domain_name]
id_provider = ldap
ldap_uri = _srv_

chpass_provider = ldap
ldap_chpass_dns_service_name = ldap
    Copy to Clipboard Toggle word wrap
  4. 선택 사항입니다. 기본적으로 서비스 검색에서는 시스템 호스트 이름의 domain 부분을 도메인 이름으로 사용합니다. 다른 DNS 도메인을 사용하려면 dns_discovery_domain 옵션에 도메인 이름을 지정합니다.
  5. 선택 사항입니다. 기본적으로 서비스 검색은 LDAP 서비스 유형에 대해 스캔합니다. 다른 서비스 유형을 사용하려면 ldap_dns_service_name 옵션에 유형을 지정합니다.
  6. 선택 사항입니다. 기본적으로 SSSD는 IPv4 주소를 조회하려고 시도합니다. 시도에 실패하면 SSSD에서 IPv6 주소를 조회하려고 시도합니다. 이 동작을 사용자 지정하려면 lookup_family_order 옵션을 사용합니다. 자세한 내용은 sssd.conf(5) 도움말 페이지를 참조하십시오.
  7. 서비스 검색을 사용할 모든 서비스에 대해 DNS 서버에 DNS 레코드를 추가합니다. 
    _service._protocol._domain TTL priority weight port host_name
    Copy to Clipboard Toggle word wrap

7.4.4. 간단한 액세스 공급자를 사용하여 액세스 제어 정의
링크 복사

간단한 액세스 공급자는 사용자 이름 또는 그룹 목록에 따라 액세스를 허용하거나 거부합니다. 이를 통해 특정 시스템에 대한 액세스를 제한할 수 있습니다.
예를 들어 회사 랩탑에서는 간단한 액세스 공급자를 사용하여 특정 사용자 또는 특정 그룹에만 액세스를 제한할 수 있습니다. 다른 사용자 또는 그룹은 구성된 인증 프로바이더에 대해 성공적으로 인증하더라도 로그인할 수 없습니다.
간단한 액세스 공급자 규칙 구성
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. access_provider 옵션을 simple 로 설정합니다. 
    [domain/domain_name]
access_provider = simple
    Copy to Clipboard Toggle word wrap
  3. 사용자에 대한 액세스 제어 규칙을 정의합니다. 다음 중 하나를 선택합니다.
    1. 사용자에 대한 액세스를 허용하려면 simple_allow_users 옵션을 사용합니다.
    2. 사용자에 대한 액세스를 거부하려면 simple_deny_users 옵션을 사용합니다.
      중요
      특정 사용자에 대한 액세스 허용은 거부하는 것보다 더 안전하다고 간주됩니다. 특정 사용자에 대한 액세스를 거부하면 다른 모든 사용자에 대한 액세스를 자동으로 허용합니다.
  4. 그룹에 대한 액세스 제어 규칙을 정의합니다. 다음 중 하나를 선택합니다.
    1. 그룹에 대한 액세스를 허용하려면 simple_allow_groups 옵션을 사용합니다.
    2. 그룹에 대한 액세스를 거부하려면 simple_deny_groups 옵션을 사용합니다.
      중요
      특정 그룹에 대한 액세스 허용은 거부하는 것보다 더 안전하다고 간주됩니다. 특정 그룹에 대한 액세스를 거부하면 다른 모든 사용자에 대한 액세스를 자동으로 허용합니다.
다음 예제에서는 다른 모든 사용자에 대한 액세스를 거부하면서 user1,user2 및 group1 의 멤버에 대한 액세스를 허용합니다. 
[domain/domain_name]
access_provider = simple
simple_allow_users = user1, user2
simple_allow_groups = group1
Copy to Clipboard Toggle word wrap
자세한 내용은 sssd-simple(5) 도움말 페이지를 참조하십시오.

7.4.5. LDAP 액세스 필터를 사용하여 액세스 제어 정의
링크 복사

access_provider 옵션이 /etc/sssd/sssd.conf 에 설정된 경우 SSSD는 지정된 액세스 공급자를 사용하여 시스템에 대한 액세스 권한을 부여하는 사용자를 평가합니다. 사용 중인 액세스 프로바이더가 LDAP 공급자 유형의 확장인 경우 시스템에 대한 액세스를 허용하려면 사용자가 일치해야 하는 LDAP 액세스 제어 필터를 지정할 수도 있습니다.
예를 들어 AD(Active Directory) 서버를 액세스 프로바이더로 사용하는 경우 지정된 AD 사용자로만 Linux 시스템에 대한 액세스를 제한할 수 있습니다. 지정된 필터와 일치하지 않는 다른 모든 사용자는 액세스가 거부됩니다.
참고
액세스 필터는 LDAP 사용자 항목에만 적용됩니다. 따라서 중첩된 그룹에서 이 유형의 액세스 제어가 작동하지 않을 수 있습니다. 중첩된 그룹에 액세스 제어를 적용하려면 7.4.4절. “간단한 액세스 공급자를 사용하여 액세스 제어 정의” 을 참조하십시오.
중요
오프라인 캐싱을 사용할 때 SSSD는 사용자의 가장 최근 온라인 로그인 시도에 성공했는지 확인합니다. 최근 온라인 로그인 중에 로그인한 사용자는 액세스 필터와 일치하지 않더라도 오프라인으로 로그인할 수 있습니다.
LDAP 액세스 필터를 적용하도록 SSSD 구성
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. [domain] 섹션에서 LDAP 액세스 제어 필터를 지정합니다.
    • LDAP 액세스 공급자의 경우 ldap_access_filter 옵션을 사용합니다. 자세한 내용은 sssd-ldap(5) 도움말 페이지를 참조하십시오.
    • AD 액세스 공급자의 경우 ad_access_filter 옵션을 사용합니다. 자세한 내용은 sssd-ad(5) 도움말 페이지를 참조하십시오.
    예를 들어 admins 사용자 그룹에 속하고 unixHomeDirectory 속성이 설정된 AD 사용자에게만 액세스를 허용하려면 다음을 수행합니다. 
    [domain/AD_domain_name]
access provider = ad
[... file truncated ...]
ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
    Copy to Clipboard Toggle word wrap
SSSD는 항목의 authorizedService 또는 host 특성을 통해 결과를 확인할 수도 있습니다. 실제로 사용자 항목 및 구성에 따라 LDAP filter, authorizedService 및 host 와 같은 모든 옵션을 평가할 수 있습니다. ldap_access_order 매개 변수는 평가 방법에 따라 사용할 모든 액세스 제어 메서드를 나열합니다. 
[domain/example.com]
access_provider = ldap
ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com
ldap_access_order = filter, host, authorized_service
Copy to Clipboard Toggle word wrap
인증된 서비스 또는 허용된 호스트를 평가하기 위해 사용할 user 항목의 속성을 사용자 지정할 수 있습니다. 추가 액세스 제어 매개변수는 sssd-ldap(5) 도움말 페이지에 나열됩니다.

[1] DNS 서비스 검색을 사용하면 애플리케이션에서 특정 유형의 특정 서비스에 대해 지정된 도메인의 SRV 레코드를 확인한 다음 필수 유형과 일치하는 서버를 반환할 수 있습니다. DNS 서비스 검색은 RFC 2782 에서 정의됩니다.

7.5. SSSD용 시스템 서비스 구성
링크 복사

SSSD는 여러 시스템 서비스에 대한 인터페이스를 제공합니다. 가장 중요한 것은 다음과 같습니다.
NSS(Name Service Switch)
7.5.1절. “서비스 구성: NSS” 참조하십시오.
PAM(Pluggable Authentication Modules)
7.5.2절. “서비스 구성: PAM” 참조하십시오.
OpenSSH
Linux 도메인 ID, 인증 및 정책 가이드에서 OpenSSH 서비스에 대한 캐시를 제공하도록 SSSD 구성을 참조하십시오.
autofs
7.5.3절. “서비스 구성: Cryo stat” 참조하십시오.
sudo
7.5.4절. “서비스 구성: sudo” 참조하십시오.

7.5.1. 서비스 구성: NSS
링크 복사

SSSD가 NSS로 작동하는 방법
NSS(Name Service Switch) 서비스는 구성 소스와 함께 시스템 ID 및 서비스를 매핑합니다. 여기에서는 서비스가 다양한 구성 및 이름 확인 메커니즘의 소스를 검색할 수 있는 중앙 구성 저장소를 제공합니다.
SSSD는 NSS 맵의 공급자로 NSS를 사용할 수 있습니다. 가장 중요한 것은 다음과 같습니다.
  • 사용자 정보( passwd 맵)
  • 그룹( 그룹 맵)
  • netgroups( netgroups 맵)
  • 서비스( 서비스 맵)
사전 요구 사항
  • SSSD 설치. 
    # yum install sssd
    Copy to Clipboard Toggle word wrap
SSSD를 사용하도록 NSS 서비스 구성
  1. authconfig 유틸리티를 사용하여 SSSD를 활성화합니다. 
    [root@server ~]# authconfig --enablesssd --update
    Copy to Clipboard Toggle word wrap
    이렇게 하면 /etc/nsswitch.conf 파일이 업데이트되어 다음 NSS 맵에서 SSSD를 사용할 수 있습니다. 
    passwd:     files sss
shadow:     files sss
group:      files sss

netgroup:   files sss
    Copy to Clipboard Toggle word wrap
  2. /etc/nsswitch.conf 를 열고 sss 를 서비스 맵 줄에 추가합니다. 
    services: files sss
    Copy to Clipboard Toggle word wrap
NSS로 작동하도록 SSSD 구성
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. [sssd] 섹션에서 NSS가 SSSD와 함께 작동하는 서비스 중 하나로 나열되어 있는지 확인합니다. 
    [sssd]
[... file truncated ...]
services = nss, pam
    Copy to Clipboard Toggle word wrap
  3. [nss] 섹션에서 SSSD가 NSS와 상호 작용하는 방법을 구성합니다. 예를 들어 다음과 같습니다. 
    [nss]
filter_groups = root
filter_users = root
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75
    Copy to Clipboard Toggle word wrap
    사용 가능한 옵션의 전체 목록은 sssd.conf(5) 도움말 페이지의 NSS 구성 옵션을 참조하십시오.
  4. SSSD를 다시 시작합니다. 
    # systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap
통합이 올바르게 작동하는지 테스트
다음 명령이 있는 사용자에 대한 정보를 표시합니다.
  • ID 사용자
  • getent passwd 사용자

7.5.2. 서비스 구성: PAM
링크 복사

주의
PAM 구성 파일의 실수는 사용자가 시스템에서 완전히 잠글 수 있습니다. 변경 사항을 수행하기 전에 구성 파일을 항상 백업하고, 변경 사항을 되돌릴 수 있도록 세션을 열어 둡니다.
SSSD를 사용하도록 PAM 구성
  • authconfig 유틸리티를 사용하여 SSSD를 활성화합니다. 
    # authconfig --enablesssdauth --update
    Copy to Clipboard Toggle word wrap
    이렇게 하면 PAM 구성이 업데이트되어 일반적으로 /etc/pam.d/system-auth 및 /etc/pam.d/password-auth 파일에서 SSSD 모듈을 참조합니다. 예를 들어 다음과 같습니다. 
    [... file truncated ...]
auth		required	pam_env.so
auth		sufficient	pam_unix.so nullok try_first_pass
auth		requisite	pam_succeed_if.so uid >= 500 quiet
auth        	sufficient	pam_sss.so use_first_pass
auth		required	pam_deny.so
[... file truncated ...]
    Copy to Clipboard Toggle word wrap
자세한 내용은 pam.conf(5) 또는 pam(8) 도움말 페이지를 참조하십시오.
PAM에서 작동하도록 SSSD 구성
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. [sssd] 섹션에서 PAM이 SSSD와 함께 작동하는 서비스 중 하나로 나열되어 있는지 확인합니다. 
    [sssd]
[... file truncated ...]
services = nss, pam
    Copy to Clipboard Toggle word wrap
  3. [pam] 섹션에서 SSSD가 PAM과 상호 작용하는 방법을 구성합니다. 예를 들어 다음과 같습니다. 
    [pam]
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
    Copy to Clipboard Toggle word wrap
    사용 가능한 옵션의 전체 목록은 sssd.conf(5) 도움말 페이지의 PAM 구성 옵션을 참조하십시오.
  4. SSSD를 다시 시작합니다. 
    # systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap
통합이 올바르게 작동하는지 테스트
  • 사용자로 로그인해 봅니다.
  • sssctl user-checks user_name auth 명령을 사용하여 SSSD 구성을 확인합니다. 자세한 내용은 sssctl user-checks --help 명령을 사용합니다.

7.5.3. 서비스 구성: Cryo stat
링크 복사

SSSD와 함께 작동하는 방법
mount 유틸리티는 시스템 리소스를 절약하기 위해 자동으로 NFS 파일 시스템을 마운트 및 마운트 해제할 수 있습니다. 에 대한 자세한 내용은 스토리지 관리 가이드의 내용을 참조하십시오. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/storage_administration_guide/index#nfs-autofs
SSSD를 가리키 도록 구성할 수 있습니다. 이 설정에서 다음을 수행합니다.
  1. 사용자가 디렉토리를 마운트하려고 하면 SSSD에서 LDAP에 연결하여 현재 meta2 구성에 대한 필요한 정보를 가져옵니다.
  2. SSSD는 LDAP 서버가 오프라인 상태인 경우에도 사용자가 디렉토리를 마운트할 수 있도록 캐시에 필요한 정보를 저장합니다.
SSSD 를 사용하도록 Cryostat 구성
  1. autofs 패키지를 설치합니다. 
    # yum install autofs
    Copy to Clipboard Toggle word wrap
  2. /etc/nsswitch.conf 파일을 엽니다.
  3. lines 에서 ldap 에서 sss 로 map 정보를 찾을 위치를 변경합니다. 
    automount: files sss
    Copy to Clipboard Toggle word wrap
Cryostat와 함께 작동하도록 SSSD 구성
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. [sssd] 섹션에서 SSSD가 관리하는 서비스 목록에 Cryostat를 추가합니다. 
    [sssd]
services = nss,pam,autofs
    Copy to Clipboard Toggle word wrap
  3. 새 [autofs] 섹션을 만듭니다. 비워 둘 수 있습니다. 
    [autofs]
    Copy to Clipboard Toggle word wrap
    사용 가능한 옵션 목록은 sssd.conf(5) 도움말 페이지의 AUTOFS 구성 옵션을 참조하십시오.
  4. SSSD가 LDAP에서 정보를 읽을 수 있도록 sssd.conf 에서 LDAP 도메인을 사용할 수 있는지 확인합니다. 7.3.2절. “SSSD의 LDAP 도메인 구성” 참조하십시오.
    sssd.conf 의 [domain] 섹션에는 다음과 같은 여러 가지 관련옵션을 사용할 수 있습니다. 예를 들어 다음과 같습니다. 
    [domain/LDAP]
[... file truncated ...]
autofs_provider=ldap
ldap_autofs_search_base=cn=automount,dc=example,dc=com
ldap_autofs_map_object_class=automountMap
ldap_autofs_entry_object_class=automount
ldap_autofs_map_name=automountMapName
ldap_autofs_entry_key=automountKey
ldap_autofs_entry_value=automountInformation
    Copy to Clipboard Toggle word wrap
    사용 가능한 옵션의 전체 목록은 sssd.conf(5) 도움말 페이지의 DOMAINEngineTIONS 를 참조하십시오.
    추가 Cryostat 옵션을 제공하지 않으면 구성은 ID 공급자 설정에 따라 다릅니다.
  5. SSSD를 다시 시작합니다. 
    # systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap
설정 테스트
  • SSSD에서 맵을 인쇄하려면 -m 명령을 사용합니다.

7.5.4. 서비스 구성: sudo
링크 복사

SSSD가 sudo로 작동하는 방식
sudo 유틸리티는 지정된 사용자에게 관리자 액세스 권한을 제공합니다. sudo 에 대한 자세한 내용은 시스템 관리자 가이드 의 sudo 유틸리티 설명서 를 참조하십시오.
SSSD를 가리키도록 sudo 를 구성할 수 있습니다. 이 설정에서 다음을 수행합니다.
  1. 사용자가 sudo 작업을 시도하면 SSSD에서 LDAP 또는 AD에 연결하여 현재 sudo 구성에 대한 필요한 정보를 가져옵니다.
  2. SSSD는 sudo 정보를 캐시에 저장하므로 사용자가 LDAP 또는 AD 서버가 오프라인 상태인 경우에도 sudo 작업을 수행할 수 있습니다.
SSSD는 sudo Host 속성 값에 따라 로컬 시스템에 적용되는 sudo 규칙만 캐시합니다. 자세한 내용은 sssd-sudo(5) 도움말 페이지를 참조하십시오.
SSSD를 사용하도록 sudo 구성
  1. /etc/nsswitch.conf 파일을 엽니다.
  2. sudoers 행의 목록에 SSSD를 추가합니다. 
    sudoers: files sss
    Copy to Clipboard Toggle word wrap
sudo와 함께 작동하도록 SSSD 구성
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. [sssd] 섹션에서 SSSD가 관리하는 서비스 목록에 sudo 를 추가합니다. 
    [sssd]
services = nss,pam,sudo
    Copy to Clipboard Toggle word wrap
  3. 새 [sudo] 섹션을 생성합니다. 비워 둘 수 있습니다. 
    [sudo]
    Copy to Clipboard Toggle word wrap
    사용 가능한 옵션 목록은 sssd.conf(5) 도움말 페이지의 SUDO 구성 옵션을 참조하십시오.
  4. SSSD가 디렉터리에서 sudo 정보를 읽을 수 있도록 LDAP 또는 AD 도메인을 sssd.conf 에서 사용할 수 있는지 확인합니다. 자세한 내용은 다음을 참조하십시오.
    LDAP 또는 AD 도메인의 [domain] 섹션에는 다음과 같은 sudo관련 매개변수가 포함되어야 합니다. 
    [domain/LDAP_or_AD_domain]
...
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
    Copy to Clipboard Toggle word wrap
    참고
    ID 공급자로 Identity Management 또는 AD를 설정하면 sudo 공급자가 자동으로 활성화됩니다. 이 경우 sudo_provider 매개 변수를 지정할 필요가 없습니다.
    사용 가능한 옵션의 전체 목록은 sssd.conf(5) 도움말 페이지의 DOMAINEngineTIONS 를 참조하십시오.
    sudo 공급자에 사용할 수 있는 옵션은 sssd-ldap(5) 도움말 페이지를 참조하십시오.
  5. SSSD를 다시 시작합니다. 
    # systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap
AD를 공급자로 사용하는 경우 sudo 규칙을 지원하도록 AD 스키마를 확장해야 합니다. 자세한 내용은 sudo 설명서를 참조하십시오.
LDAP 또는 AD에 sudo 규칙을 제공하는 방법에 대한 자세한 내용은 sudoers.ldap(5) 도움말 페이지를 참조하십시오.

7.6. SSSD 클라이언트 측 보기
링크 복사

SSSD를 사용하면 클라이언트 측 보기를 생성하여 POSIX 사용자 또는 그룹 속성에 대한 새 값을 지정할 수 있습니다. 보기는 재정의가 구성된 로컬 시스템에만 적용됩니다. ipa 를 제외한 모든 id_provider 값에 대해 클라이언트 측 덮어쓰기를 구성할 수 있습니다. ipa 공급자를 사용하는 경우 IdM에서 ID 보기를 중앙에 정의합니다. Linux 도메인 ID, 인증 및 정책 가이드의 해당 섹션을 참조하십시오.
자세한 내용은 Linux 도메인 ID, 인증 및 정책 가이드의 SSSD 성능에 대한 잠재적 부정 영향 섹션 을 참조하십시오.
참고
sss_override user-add,sss_override group-add 또는 sss_override user-import 명령을 사용하여 첫 번째 덮어쓰기를 생성한 후 변경 사항이 적용되도록 SSSD를 다시 시작합니다. 
# systemctl restart sssd
Copy to Clipboard Toggle word wrap

7.6.1. 사용자 계정의 다른 속성 값 정의
링크 복사

관리자는 LDAP의 계정을 사용하도록 기존 호스트를 구성했습니다. 그러나 LDAP의 사용자 새 ID는 로컬 시스템의 사용자 이전 ID와 다릅니다. 기존 파일에 대한 권한을 변경하는 대신 UID를 재정의하도록 클라이언트 측 보기를 구성할 수 있습니다.
사용자 계정의 UID를 UID 6666 으로 재정의하려면 다음을 수행합니다.
  1. 선택 사항입니다. 사용자 계정의 현재 UID를 표시합니다. 
    # id user
uid=1241400014(user_name) gid=1241400014(user_name) Groups=1241400014(user_name)
    Copy to Clipboard Toggle word wrap
  2. 계정의 UID를 6666 으로 재정의합니다. 
    # sss_override user-add user -u 6666
    Copy to Clipboard Toggle word wrap
  3. 메모리 내 캐시가 만료될 때까지 기다립니다. 수동으로 만료하려면 다음을 수행합니다. 
    # sss_cache --users
    Copy to Clipboard Toggle word wrap
  4. 새 UID가 적용되었는지 확인합니다. 
    # id user
uid=6666(user_name) gid=1241400014(user_name) Groups=1241400014(user_name)
    Copy to Clipboard Toggle word wrap
  5. 선택 사항입니다. 사용자에 대한 덮어쓰기를 표시합니다. 
    # sss_override user-show user
user@ldap.example.com::6666:::::
    Copy to Clipboard Toggle word wrap
재정의할 수 있는 속성 목록은 명령에 --help 를 추가하여 명령줄 옵션을 나열합니다. 
# sss_override user-add --help
Copy to Clipboard Toggle word wrap

7.6.2. 호스트에서 모든 덮어쓰기 나열
링크 복사

관리자는 호스트에서 모든 사용자와 그룹 재정의를 나열하여 올바른 속성이 재정의되었는지 확인하려고 합니다.
모든 사용자 덮어쓰기를 나열하려면 다음을 수행합니다. 
# sss_override user-find
user1@ldap.example.com::8000::::/bin/zsh:
user2@ldap.example.com::8001::::/bin/bash:
...
Copy to Clipboard Toggle word wrap
모든 그룹 덮어쓰기를 나열하려면 다음을 수행합니다. 
# sss_override group-find
group1@ldap.example.com::7000
group2@ldap.example.com::7001
...
Copy to Clipboard Toggle word wrap

7.6.3. 로컬 오버라이드 제거
링크 복사

이전에 글로벌 LDAP 디렉터리에 정의된 사용자 계정의 쉘에 대한 재정의를 생성하셨습니다. 계정에 대한 덮어쓰기를 제거하려면 다음을 실행합니다. 
# sss_override user-del user
Copy to Clipboard Toggle word wrap
변경 사항은 즉시 적용됩니다.
그룹에 대한 덮어쓰기를 제거하려면 다음을 실행합니다. 
# sss_override group-del group
Copy to Clipboard Toggle word wrap
참고
사용자 또는 그룹의 재정의를 제거하면 이 오브젝트에 대한 모든 덮어쓰기가 제거됩니다.

7.6.4. 로컬 뷰 내보내기 및 가져오기
링크 복사

클라이언트 측 보기는 로컬 SSSD 캐시에 저장됩니다. 캐시에서 파일로 사용자 및 그룹 보기를 내보내 백업을 생성할 수 있습니다. 예를 들어 SSSD 캐시를 제거하면 나중에 뷰를 다시 복원할 수 있습니다.
사용자 및 그룹 보기를 백업하려면 다음을 수행합니다. 
# sss_override user-export /var/lib/sss/backup/sssd_user_overrides.bak
# sss_override group-export /var/lib/sss/backup/sssd_group_overrides.bak
Copy to Clipboard Toggle word wrap
사용자 및 그룹 보기를 복원하려면 다음을 수행합니다. 
# sss_override user-import /var/lib/sss/backup/sssd_user_overrides.bak
# sss_override group-import /var/lib/sss/backup/sssd_group_overrides.bak
Copy to Clipboard Toggle word wrap

7.7. SSSD 다운그레이드
링크 복사

SSSD 버전을 다운그레이드하거나 운영 체제 자체를 다운그레이드하는 경우 기존 SSSD 캐시를 제거해야 합니다. 캐시가 제거되지 않으면 SSSD 프로세스가 종료되었지만 PID 파일은 남아 있습니다. SSSD 로그는 캐시 버전이 인식되지 않기 때문에 연결된 도메인에 연결할 수 없음을 보여줍니다. 
(Wed Nov 28 21:25:50 2012) [sssd] [sysdb_domain_init_internal] (0x0010): Unknown DB version [0.14], expected [0.10] for domain AD!
Copy to Clipboard Toggle word wrap
그런 다음 사용자는 더 이상 인식되지 않으며 도메인 서비스 및 호스트에 인증할 수 없습니다.
SSSD 버전을 다운그레이드한 후 다음을 수행합니다.
  1. 기존 캐시 데이터베이스 파일을 삭제합니다. 
    [root@server ~]# rm -rf /var/lib/sss/db/*
    Copy to Clipboard Toggle word wrap
  2. SSSD 프로세스를 다시 시작합니다. 
    [root@server ~]# systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap

7.8. SSSD에 NSCD 사용
링크 복사

SSSD는 NSCD 데몬과 함께 사용하도록 설계되지 않았습니다. SSSD가 NSCD와 직접 충돌하지는 않지만 두 서비스를 모두 사용하면 특히 항목이 캐시되는 기간에 예기치 않은 동작이 발생할 수 있습니다.
문제의 가장 일반적인 증거는 NFS와 충돌하는 것입니다. 네트워크 관리자를 사용하여 네트워크 연결을 관리하는 경우 네트워크 인터페이스가 표시되는 데 몇 분이 걸릴 수 있습니다. 이 시간 동안 다양한 서비스가 시작하려고 시도합니다. 네트워크를 가동하기 전에 이러한 서비스가 시작되고 DNS 서버를 사용할 수 있는 경우, 이러한 서비스는 필요한 정방향 또는 역방향 DNS 항목을 식별하지 못합니다. 이러한 서비스는 올바르지 않거나 빈 resolv.conf 파일을 읽습니다. 일반적으로 이 파일은 한 번만 읽으므로 이 파일에 대한 변경 사항은 자동으로 적용되지 않습니다. 이로 인해 해당 서비스를 수동으로 다시 시작하지 않는 한 NSCD 서비스가 실행 중인 시스템에서 NFS 잠금이 실패할 수 있습니다.
이 문제를 방지하려면 /etc/nscd.conf 파일의 호스트에 대해서만 캐싱을 활성화하고 passwd, group ,services 및 netgroup 항목에 대해 SSSD 캐시에 의존합니다.
/etc/nscd.conf 파일을 변경합니다. 
enable-cache hosts yes
enable-cache passwd no
enable-cache group no
enable-cache netgroup no
enable-cache services no
Copy to Clipboard Toggle word wrap
NSCD에서 호스트 요청에 응답하면 해당 항목은 NSCD에서 캐시하고 부팅 프로세스 동안 NSCD에서 반환됩니다. 다른 모든 항목은 SSSD에서 처리합니다.

7.9. 추가 리소스
링크 복사

  • SSSD 관련 도움말 페이지의 전체 목록은 sssd(8) 도움말 페이지의 SEE ALSO 섹션에서 확인할 수 있습니다.
  • 문제 해결 조언: A.1절. “SSSD 문제 해결”.
  • 서버에서 보낸 암호 만료 경고를 처리하고 로컬 시스템의 사용자에게 표시하도록 SSSD를 구성하는 절차입니다. Red Hat Knowledgebase에서 암호 만료 설정
  • SSSD 클라이언트는 LDAP 서버에서 검색한 모든 사용자에 대해 GID를 자동으로 생성할 수 있으며 GID 번호가 이미 사용되지 않는 한 GID가 사용자의 UID와 일치하는지 확인합니다. Active Directory에 직접 통합된 SSSD 클라이언트에서 GID 자동 생성을 설정하는 방법을 보려면 Windows 통합 가이드의 해당 섹션을 참조하십시오.

8장. realmd 를 사용하여 ID 도메인에 연결
링크 복사

realmd 시스템은 ID 도메인을 검색하고 결합할 수 있는 명확하고 간단한 방법을 제공합니다. 도메인 자체에 연결되지 않지만 도메인에 연결하기 위해 SSSD 또는 Winbind와 같은 기본 Linux 시스템 서비스를 구성합니다.
Windows 통합 가이드에서는 realmd 를 사용하여 Microsoft Active Directory(AD) 도메인에 연결하는 방법을 설명합니다. realmd 를 사용하여 AD가 아닌 ID 도메인에 연결하는 것과 동일한 절차가 적용됩니다. Windows 통합 가이드의 Using realmd to connect to a Active Directory Domain 을 참조하십시오.

9장. LDAP 서버
링크 복사

LDAP (Lightweight Directory Access Protocol)는 네트워크를 통해 중앙 집중식으로 저장된 정보에 액세스하는 데 사용되는 오픈 프로토콜 세트입니다. 디렉터리 공유의 X.500 표준을 기반으로 하지만 덜 복잡하고 리소스 집약적입니다. 이러한 이유로 LDAP는 “X.500 Lite” 라고도 합니다.
X.500과 마찬가지로 LDAP는 디렉터리를 사용하여 계층적으로 정보를 구성합니다. 이러한 디렉터리는 이름, 주소 또는 전화 번호와 같은 다양한 정보를 저장할 수 있으며NIS( 네트워크 정보 서비스 )와 유사한 방식으로 사용할 수 있으므로 누구나 LDAP가 활성화된 네트워크의 모든 시스템에서 계정에 액세스할 수 있습니다.
LDAP는 일반적으로 중앙에서 관리되는 사용자 및 그룹, 사용자 인증 또는 시스템 구성에 사용됩니다. 또한 가상 전화 디렉토리 역할을 함으로써 사용자가 다른 사용자의 연락처 정보에 쉽게 액세스할 수 있습니다. 또한 사용자를 전 세계 다른 LDAP 서버로 참조할 수 있으므로 ad-hoc 글로벌 정보 저장소를 제공합니다. 하지만 대학교, 정부 부서, 민간 기업과 같은 개별 조직에서 가장 자주 사용됩니다.

9.1. Red Hat Directory Server
링크 복사

Red Hat Directory Server는 사용자 ID 및 애플리케이션 정보를 중앙 집중화하는 LDAP 호환 서버입니다. 애플리케이션 설정, 사용자 프로필, 그룹 데이터, 정책 및 액세스 제어 정보를 저장하기 위한 운영 체제 독립적 및 네트워크 기반 레지스트리를 제공합니다.
참고
Directory Server를 설치하고 업데이트하려면 현재 Red Hat Directory Server 서브스크립션이 필요합니다.
Directory Server 설정 및 사용에 대한 자세한 내용은 다음을 참조하십시오.

9.2. OpenLDAP
링크 복사

이 섹션에서는 LDAPv2 및 LDAPv3 프로토콜의 오픈 소스 구현인 OpenLDAP 2.4 의 설치 및 구성에 대해 설명합니다.
참고
Red Hat Enterprise Linux 7.4부터 openldap-server 패키지는 더 이상 사용되지 않으며 향후 Red Hat Enterprise Linux 주요 릴리스에는 포함되지 않습니다. 이러한 이유로 Red Hat Enterprise Linux 또는 Red Hat Directory Server에 포함된 Identity Management로 마이그레이션해야 합니다. ID 관리에 대한 자세한 내용은 Linux Domain Identity, Authentication 및 Policy Guide를 참조하십시오. Directory Server에 대한 자세한 내용은 9.1절. “Red Hat Directory Server” 을 참조하십시오.

9.2.1. LDAP 소개
링크 복사

LDAP는 클라이언트-서버 아키텍처를 사용하여 네트워크에서 액세스할 수 있는 중앙 정보 디렉토리를 만들 수 있는 안정적인 수단을 제공합니다. 클라이언트가 이 디렉터리 내에서 정보를 수정하려고 하면 서버에서 사용자에게 변경을 수행할 수 있는 권한이 있는지 확인한 다음 요청된 대로 항목을 추가하거나 업데이트합니다. 통신의 보안을 유지하기 위해TLS( Transport Layer Security ) 암호화 프로토콜을 사용하여 공격자가 전송을 가로채지 않도록 할 수 있습니다.
중요
Red Hat Enterprise Linux 7.5의 OpenLDAP 제품군은 더 이상NSS( Network Security Services )의 Mozilla 구현을 사용하지 않습니다. 대신 OpenSSL 을 사용합니다. OpenLDAP는 기존의 NSS 데이터베이스 구성에서 계속 작동합니다.
중요
구성 설정을 통해 SSLv3을 비활성화하지 않는 구성 요소의 POODLE SSLv3.0 취약점 (CVE-2014-3566)에 설명된 취약점으로 인해 보안을 위해 SSLv3 프로토콜을 사용하지 않는 것이 좋습니다. OpenLDAP는 SSLv3 을 효과적으로 비활성화할 수 있는 구성 매개 변수를 제공하지 않는 시스템 구성 요소 중 하나입니다. 위험을 완화하려면 stunnel 명령을 사용하여 보안 터널을 제공하고 SSLv3 을 사용하지 않도록 stunnel 을 비활성화하는 것이 좋습니다. stunnel 사용에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드를 참조하십시오.
LDAP 서버는 여러 데이터베이스 시스템을 지원하므로 관리자가 서비스하려는 정보 유형에 가장 적합한 솔루션을 선택할 수 있습니다. 잘 정의된 클라이언트API( 애플리케이션 프로그래밍 인터페이스 )로 인해 LDAP 서버와 통신할 수 있는 애플리케이션 수는 다양하며 양과 품질 모두 증가합니다.
9.2.1.1. LDAP 용어
링크 복사
다음은 이 장에서 사용되는 LDAP 관련 용어 목록입니다.
항목
LDAP 디렉터리 내의 단일 단위. 각 항목은DN(별도 이름)으로 식별됩니다.
특성
항목과 직접 연관된 정보. 예를 들어, 조직이 LDAP 항목으로 표현되면 이 조직과 관련된 특성에 주소, 팩스 번호가 포함될 수 있습니다. 마찬가지로 개인 전화 번호 또는 이메일 주소와 같은 일반적인 속성을 가진 항목으로 표현할 수 있습니다.
속성에는 단일 값이 있거나 순서가 지정되지 않은 공백으로 구분된 값 목록이 있을 수 있습니다. 특정 속성은 선택 사항이지만 다른 속성은 필요합니다. 필수 속성은 objectClass 정의를 사용하여 지정되며 /etc/openldap/slapd.d/cn=config/cn=schema/ 디렉터리에 있는 스키마 파일에서 찾을 수 있습니다.
속성과 해당 값의 어설션은RDN(Reelative honorin guished Name )이라고도 합니다. 전역적으로 고유한 고유 이름과 달리 상대 고유 이름은 항목별로 고유합니다.
LDIF
LDAP Data Interchange Format (LDIF)은 LDAP 항목의 일반 텍스트 표현입니다. 다음과 같은 형식을 취합니다. 
[id] dn: distinguished_name
attribute_type: attribute_value…
attribute_type: attribute_value…
…
Copy to Clipboard Toggle word wrap
선택 사항인 ID 는 항목을 편집하는 데 사용되는 애플리케이션에 의해 결정된 숫자입니다. 각 항목에는 모두 해당 스키마 파일에 정의된 한 개수의 attribute_type 및 attribute_value 쌍을 필요에 따라 포함할 수 있습니다. 빈 줄은 항목의 끝을 나타냅니다.
9.2.1.2. OpenLDAP 기능
링크 복사
OpenLDAP 제품군은 다음과 같은 여러 가지 중요한 기능을 제공합니다.
  • LDAPv3 지원 - LDAP 버전 2는 LDAP의 보안을 강화하도록 설계되었으므로 프로토콜의 많은 변경 사항입니다. 그 외에도SASL(Simple Authentication and Security Layer),TLS(Transport Layer Security),SSL(Secure Sockets Layer) 프로토콜 지원이 추가로 개선되었습니다.
  • LDAP Over IPC - IPC (프로세스 간 통신)를 사용하면 네트워크를 통해 통신할 필요가 없어 보안이 향상됩니다.
  • IPv6 지원 - OpenLDAP는 차세대 인터넷 프로토콜인IPv6(Internet Protocol version 6)와 호환됩니다.
  • LDIFv1 지원 - OpenLDAP는 LDIF 버전 1과 완벽하게 호환됩니다.
  • 업데이트된 C API - 프로그래머가 LDAP 디렉터리 서버에 연결하고 사용할 수 있는 방식을 개선합니다.
  • 강화된 독립 실행형 LDAP 서버 - 업데이트된 액세스 제어 시스템, 스레드 풀링, 더 나은 툴 등이 포함됩니다.
9.2.1.3. OpenLDAP 서버 설정
링크 복사
Red Hat Enterprise Linux에 LDAP 서버를 설정하는 일반적인 단계는 다음과 같습니다.
  1. OpenLDAP 제품군 설치. 필수 패키지에 대한 자세한 내용은 9.2.2절. “OpenLDAP 제품군 설치” 을 참조하십시오.
  2. 9.2.3절. “OpenLDAP 서버 구성” 에 설명된 대로 구성을 사용자 지정합니다.
  3. 9.2.5절. “OpenLDAP 서버 실행” 에 설명된 대로 슬폴드 서비스를 시작합니다.
  4. ldapadd 유틸리티를 사용하여 LDAP 디렉터리에 항목을 추가합니다.
  5. ldapsearch 유틸리티를 사용하여 slapd 서비스가 정보에 올바르게 액세스하고 있는지 확인합니다.

9.2.2. OpenLDAP 제품군 설치
링크 복사

OpenLDAP 라이브러리 및 도구 모음은 다음 패키지에서 제공합니다.
Expand
표 9.1. OpenLDAP 패키지 목록
패키지 Description
openldap OpenLDAP 서버 및 클라이언트 애플리케이션을 실행하는 데 필요한 라이브러리를 포함하는 패키지입니다.
openldap-clients LDAP 서버에서 디렉터리를 보고 수정하기 위한 명령줄 유틸리티가 포함된 패키지입니다.
openldap-servers LDAP 서버를 구성하고 실행하는 서비스 및 유틸리티를 모두 포함하는 패키지입니다. 여기에는슬랩된 독립 실행형 LDAP 데몬이 포함됩니다.
compat-openldap OpenLDAP 호환성 라이브러리를 포함하는 패키지입니다.
또한 다음 패키지는 LDAP 서버와 함께 일반적으로 사용됩니다.
Expand
표 9.2. 일반적으로 설치된 추가 LDAP 패키지 목록
패키지 Description
nss-pam-ldapd 사용자가 로컬 LDAP 쿼리를 수행할 수 있는 로컬 LDAP 이름 서비스인 nslcd 가 포함된 패키지입니다.
mod_ldap
mod_authnz_ldap 및 mod_ldap 모듈이 포함된 패키지입니다. mod_authnz_ldap 모듈은 Apache HTTP Server의 LDAP 인증 모듈입니다. 이 모듈은 LDAP 디렉터리에 대해 사용자의 자격 증명을 인증할 수 있으며 사용자 이름, 전체 DN, 그룹 멤버십, 임의의 속성 또는 전체 필터 문자열에 따라 액세스 제어를 적용할 수 있습니다. 동일한 패키지에 포함된 mod_ldap 모듈은 구성 가능한 공유 메모리 캐시를 제공하여 많은 HTTP 요청에서 반복된 디렉터리 액세스를 방지하고 SSL/TLS도 지원합니다. 이 패키지는 선택적 채널에서 제공합니다. Red Hat 추가 채널에 대한 자세한 내용은 시스템 관리자 가이드의 선택적 및 추가 리포지토리 추가를 참조하십시오.
이러한 패키지를 설치하려면 다음 형식으로 yum 명령을 사용하십시오. 
yum install package…
Copy to Clipboard Toggle word wrap
예를 들어 기본 LDAP 서버 설치를 수행하려면 쉘 프롬프트에서 다음을 입력합니다. 
~]# yum install openldap openldap-clients openldap-servers
Copy to Clipboard Toggle word wrap
이 명령을 실행하려면 슈퍼유저 권한(즉, root로 로그인해야 함)이 있어야 합니다. Red Hat Enterprise Linux에서 새 패키지를 설치하는 방법에 대한 자세한 내용은 시스템 관리자 가이드에서 패키지 설치를 참조하십시오.
9.2.2.1. OpenLDAP 서버 유틸리티 개요
링크 복사
관리 작업을 수행하기 위해 openldap-servers 패키지는 슬랩 서비스와 함께 다음 유틸리티를 설치합니다.
Expand
표 9.3. OpenLDAP 서버 유틸리티 목록
명령 Description
slapacl 속성 목록에 대한 액세스를 확인할 수 있습니다.
slapadd LDIF 파일의 항목을 LDAP 디렉터리에 추가할 수 있습니다.
slapauth 인증 및 권한 부여 권한에 대한 ID 목록을 확인할 수 있습니다.
slapcat 기본 형식의 LDAP 디렉토리에서 항목을 가져와 LDIF 파일에 저장할 수 있습니다.
slapdn 사용 가능한 스키마 구문에 따라 고유 이름(DN) 목록을 확인할 수 있습니다.
slapindex 현재 콘텐츠를 기반으로 slapd 디렉토리를 다시 인덱싱할 수 있습니다. 구성 파일에서 인덱싱 옵션을 변경할 때마다 이 유틸리티를 실행합니다.
slappasswd ldapmodify 유틸리티 또는 슬랩된 구성 파일과 함께 사용할 암호화된 사용자 암호를 만들 수 있습니다.
slapschema 해당 스키마를 사용하여 데이터베이스의 규정 준수를 확인할 수 있습니다.
slaptest LDAP 서버 구성을 확인할 수 있습니다.
이러한 유틸리티 및 사용에 대한 자세한 설명은 “설치된 문서” 에서 참조하는 해당 도움말 페이지를 참조하십시오.
중요
root 만 slapadd 를 실행할 수 있지만 slapd 서비스는 ldap 사용자로 실행됩니다. 이로 인해 디렉터리 서버는 slapadd 로 생성된 파일을 수정할 수 없습니다. 이 문제를 해결하려면 slapdadd 유틸리티를 실행한 후 쉘 프롬프트에서 다음을 입력합니다. 
~]# chown -R ldap:ldap /var/lib/ldap
Copy to Clipboard Toggle word wrap
주의
데이터 무결성을 유지하려면 slapadd, slapcat 또는 slapindex 를 사용하기 전에 슬퍼드 서비스를 중지합니다. 쉘 프롬프트에서 다음을 입력하여 이를 수행할 수 있습니다. 
~]# systemctl stop slapd.service
Copy to Clipboard Toggle word wrap
슬라이딩 서비스의 시작, 중지, 재시작 및 현재 상태를 확인하는 방법에 대한 자세한 내용은 9.2.5절. “OpenLDAP 서버 실행” 을 참조하십시오.
9.2.2.2. OpenLDAP 클라이언트 유틸리티 개요
링크 복사
openldap-clients 패키지는 LDAP 디렉터리에서 항목을 추가, 수정 및 삭제하는 데 사용할 수 있는 다음 유틸리티를 설치합니다.
Expand
표 9.4. OpenLDAP 클라이언트 유틸리티 목록
명령 Description
ldapadd 파일에서 또는 표준 입력에서 LDAP 디렉터리에 항목을 추가할 수 있습니다. ldapmodify -a 에 대한 심볼릭 링크입니다.
ldapcompare 지정된 속성을 LDAP 디렉토리 항목과 비교할 수 있습니다.
ldapdelete LDAP 디렉토리에서 항목을 삭제할 수 있습니다.
ldapexop 확장된 LDAP 작업을 수행할 수 있습니다.
ldapmodify 파일에서 또는 표준 입력에서 LDAP 디렉터리의 항목을 수정할 수 있습니다.
ldapmodrdn LDAP 디렉토리 항목의 RDN 값을 수정할 수 있습니다.
ldappasswd LDAP 사용자의 암호를 설정하거나 변경할 수 있습니다.
ldapsearch 를 사용하여 LDAP 디렉토리 항목을 검색할 수 있습니다.
ldapurl LDAP URL을 구성하거나 분해할 수 있습니다.
ldapwhoami LDAP 서버에서 whoami 작업을 수행할 수 있습니다.
ldapsearch 를 제외하고 이러한 각 유틸리티는 LDAP 디렉터리 내에서 변경할 각 항목에 대한 명령을 입력하는 대신 변경할 파일이 포함된 파일을 참조하여 더 쉽게 사용됩니다. 이러한 파일의 형식은 각 유틸리티의 도움말 페이지에 설명되어 있습니다.
9.2.2.3. 일반적인 LDAP 클라이언트 애플리케이션 개요
링크 복사
서버에서 디렉토리를 만들고 수정할 수 있는 다양한 그래픽 LDAP 클라이언트가 있지만, 이 중 Red Hat Enterprise Linux에는 포함되지 않습니다. 읽기 전용 모드에서 디렉터리에 액세스할 수 있는 애플리케이션에는 Mozilla Thunderbird,Evolution 또는 Ekiga 가 포함됩니다.

9.2.3. OpenLDAP 서버 구성
링크 복사

기본적으로 OpenLDAP 구성은 /etc/openldap/ 디렉터리에 저장됩니다. 다음 표는 이 디렉토리 내에서 가장 중요한 디렉토리와 파일을 강조 표시합니다.
Expand
표 9.5. OpenLDAP 구성 파일 및 디렉토리 목록
경로 Description
/etc/openldap/ldap.conf OpenLDAP 라이브러리를 사용하는 클라이언트 애플리케이션의 구성 파일입니다. 여기에는 ldapadd,ldapsearch,Evolution 등이 포함됩니다.
/etc/openldap/slapd.d/ 슬래핑 구성이 포함된 디렉터리입니다.
OpenLDAP는 더 이상 /etc/openldap/slapd.conf 파일에서 구성을 읽지 않습니다. 대신 /etc/openldap/slapd.d/ 디렉터리에 있는 구성 데이터베이스를 사용합니다. 이전 설치의 기존 slapd.conf 파일이 있는 경우 다음 명령을 실행하여 새 형식으로 변환할 수 있습니다. 
~]# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
Copy to Clipboard Toggle word wrap
슬퍼된 구성은 계층 구조로 구성된 LDIF 항목으로 구성되며 이러한 항목을 편집하는 권장 방법은 9.2.2.1절. “OpenLDAP 서버 유틸리티 개요” 에 설명된 서버 유틸리티를 사용하는 것입니다.
중요
LDIF 파일의 오류는 slapd 서비스를 시작할 수 없도록 렌더링할 수 있습니다. 이 때문에 /etc/openldap/slapd.d/ 에서 LDIF 파일을 직접 편집하지 않는 것이 좋습니다.
9.2.3.1. 글로벌 구성 변경
링크 복사
LDAP 서버의 글로벌 구성 옵션은 /etc/openldap/slapd.d/cn=config.ldif 파일에 저장됩니다. 일반적으로 다음 지시문이 사용됩니다.
olcAllows
olcAllows 지시문을 사용하면 활성화할 기능을 지정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcAllows: feature…
Copy to Clipboard Toggle word wrap
표 9.6. “사용 가능한 olcAllows 옵션” 에 설명된 대로 공백으로 구분된 기능 목록을 허용합니다. 기본 옵션은 bind_v2 입니다.
Expand
표 9.6. 사용 가능한 olcAllows 옵션
옵션 Description
bind_v2 LDAP 버전 2 바인드 요청을 수락합니다.
bind_anon_cred 고유 이름(DN)이 비어 있으면 익명 바인딩을 활성화합니다.
bind_anon_dn 고유 이름(DN)이 비어 있지 않은 경우 익명 바인딩을 활성화합니다.
update_anon 익명 업데이트 작업을 처리할 수 있습니다.
proxy_authz_anon 익명 프록시 권한 부여 제어를 처리할 수 있습니다.

예 9.1. olcAllows 지시문 사용

olcAllows: bind_v2 update_anon
Copy to Clipboard Toggle word wrap
olcConnMaxPending
olcConnMaxPending 지시문을 사용하면 익명 세션에 대해 보류 중인 최대 요청 수를 지정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcConnMaxPending: number
Copy to Clipboard Toggle word wrap
기본 옵션은 100 입니다.

예 9.2. olcConnMaxPending 지시문 사용

olcConnMaxPending: 100
Copy to Clipboard Toggle word wrap
olcConnMaxPendingAuth
olcConnMaxPendingAuth 지시문을 사용하면 인증된 세션에 대해 보류 중인 최대 요청 수를 지정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcConnMaxPendingAuth: number
Copy to Clipboard Toggle word wrap
기본 옵션은 1000 입니다.

예 9.3. olcConnMaxPendingAuth 지시문 사용

olcConnMaxPendingAuth: 1000
Copy to Clipboard Toggle word wrap
olcDisallows
olcDisallows 지시문을 사용하면 비활성화할 기능을 지정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcDisallows: feature…
Copy to Clipboard Toggle word wrap
표 9.7. “사용 가능한 olcDisallows 옵션” 에 설명된 대로 공백으로 구분된 기능 목록을 허용합니다. 기본적으로 비활성화된 기능은 없습니다.
Expand
표 9.7. 사용 가능한 olcDisallows 옵션
옵션 Description
bind_anon 익명 바인드 요청의 수락을 비활성화합니다.
bind_simple 간단한 바인드 인증 메커니즘을 비활성화합니다.
tls_2_anon STARTTLS 명령이 수신되면 익명 세션 강제를 비활성화합니다.
tls_authc 인증 시 STARTTLS 명령을 허용하지 않습니다.

예 9.4. olcDisallows 지시문 사용

olcDisallows: bind_anon
Copy to Clipboard Toggle word wrap
olcIdleTimeout
olcIdleTimeout 지시문을 사용하면 유휴 연결을 닫기 전에 대기할 초(초)를 지정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcIdleTimeout: number
Copy to Clipboard Toggle word wrap
이 옵션은 기본적으로 비활성화되어 있습니다(즉 0으로 설정).

예 9.5. olcIdleTimeout 지시문 사용

olcIdleTimeout: 180
Copy to Clipboard Toggle word wrap
olcLogFile
olcLogFile 지시문을 사용하면 로그 메시지를 작성할 파일을 지정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcLogFile: file_name
Copy to Clipboard Toggle word wrap
로그 메시지는 기본적으로 표준 오류에 기록됩니다.

예 9.6. olcLogFile 지시문 사용

olcLogFile: /var/log/slapd.log
Copy to Clipboard Toggle word wrap
olcReferral
olcReferral 옵션을 사용하면 서버가 요청을 처리할 수 없는 경우 서버 URL을 지정하여 요청을 처리할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcReferral: URL
Copy to Clipboard Toggle word wrap
이 옵션은 기본적으로 비활성화되어 있습니다.

예 9.7. olcReferral 지시문 사용

olcReferral: ldap://root.openldap.org
Copy to Clipboard Toggle word wrap
olcWriteTimeout
olcWriteTimeout 옵션을 사용하면 미해결 쓰기 요청으로 연결을 닫기 전에 대기할 초(초)를 지정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcWriteTimeout
Copy to Clipboard Toggle word wrap
이 옵션은 기본적으로 비활성화되어 있습니다(즉 0으로 설정).

예 9.8. olcWriteTimeout 지시문 사용

olcWriteTimeout: 180
Copy to Clipboard Toggle word wrap
9.2.3.2. 프런트 엔드 구성
링크 복사
OpenLDAP 프런트 엔드 구성은 etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif 파일에 저장되고 ACL(액세스 제어 목록)과 같은 글로벌 데이터베이스 옵션을 정의합니다. 자세한 내용은 slapd-config(5) 도움말 페이지의 Global Database Options 섹션을 참조하십시오.
9.2.3.3. 모니터 백엔드
링크 복사
/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif 파일은 OpenLDAP 모니터 백엔드를 제어합니다. 활성화된 경우 데몬의 실행 상태에 대한 정보를 사용하여 OpenLDAP에서 자동으로 생성 및 동적으로 업데이트됩니다. 접미사는 cn=Monitor 이며 변경할 수 없습니다. 자세한 내용은 slapd-monitor(5) 도움말 페이지를 참조하십시오.
9.2.3.4. 데이터베이스별 구성
링크 복사
기본적으로 OpenLDAP 서버는 hdb 데이터베이스 백엔드를 사용합니다. 하위 트리 이름을 지원하는 계층적 데이터베이스 레이아웃을 사용하는 것 외에도 bdb 백엔드와 동일하며 동일한 구성 옵션을 사용합니다. 이 데이터베이스 백엔드의 구성은 /etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif 파일에 저장됩니다.
다른 백엔드 데이터베이스 목록은 slapd.backends(5) 도움말 페이지를 참조하십시오. 개별 백엔드의 도움말 페이지에서 찾은 데이터베이스별 설정입니다. 예를 들어 다음과 같습니다. 
# man slapd-hdb
Copy to Clipboard Toggle word wrap
참고
bdb 및 hdb 백엔드는 더 이상 사용되지 않습니다. 대신 새 설치에 mdb 백엔드를 사용하는 것이 좋습니다.
다음 지시문은 일반적으로 데이터베이스별 구성에서 사용됩니다.
olcReadOnly
olcReadOnly 지시문을 사용하면 읽기 전용 모드에서 데이터베이스를 사용할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcReadOnly: boolean
Copy to Clipboard Toggle word wrap
TRUE (읽기 전용 모드 활성화) 또는 FALSE(데이터베이스 수정 활성화)를 허용합니다. 기본 옵션은 FALSE 입니다.

예 9.9. olcReadOnly 지시문 사용

olcReadOnly: TRUE
Copy to Clipboard Toggle word wrap
olcRootDN
olcRootDN 지시문을 사용하면 LDAP 디렉터리에서 작업에 설정된 액세스 제어 또는 관리 제한 매개 변수로 제한되지 않은 사용자를 지정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcRootDN: distinguished_name
Copy to Clipboard Toggle word wrap
DN(고유 이름)을 허용합니다. 기본 옵션은 cn=Manager,dn=my-domain,dc=com 입니다.

예 9.10. olcRootDN 지시문 사용

olcRootDN: cn=root,dn=example,dn=com
Copy to Clipboard Toggle word wrap
olcRootPW
olcRootPW 지시문을 사용하면 olcRootDN 지시문을 사용하여 지정한 사용자의 암호를 설정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcRootPW: password
Copy to Clipboard Toggle word wrap
일반 텍스트 문자열 또는 해시를 허용합니다. 해시를 생성하려면 쉘 프롬프트에서 다음을 입력합니다. 
~]$ slappaswd
New password:
Re-enter new password:
{SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD
Copy to Clipboard Toggle word wrap

예 9.11. olcRootPW 지시문 사용

olcRootPW: {SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD
Copy to Clipboard Toggle word wrap
olcSuffix
olcSuffix 지시문을 사용하면 정보를 제공할 도메인을 지정할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcSuffix: domain_name
Copy to Clipboard Toggle word wrap
FQDN(정규화 된 도메인 이름)을 허용합니다. 기본 옵션은 dc=my-domain,dc=com 입니다.

예 9.12. olcSuffix 지시문 사용

olcSuffix: dc=example,dc=com
Copy to Clipboard Toggle word wrap
9.2.3.5. 스키마 확장
링크 복사
OpenLDAP 2.3 이후 /etc/openldap/slapd.d/ 디렉터리에는 이전에 /etc/openldap/schema/ 에 있는 LDAP 정의도 포함되어 있습니다. 기본 스키마 파일을 가이드로 사용하여 추가 속성 유형 및 개체 클래스를 지원하도록 OpenLDAP에서 사용하는 스키마를 확장할 수 있습니다. 그러나 이 작업은 이 장의 범위를 벗어납니다. 이 항목에 대한 자세한 내용은 를 참조하십시오 https://openldap.org/doc/admin24/schema.html.
9.2.3.6. 보안 연결 설정
링크 복사
OpenLDAP 제품군 및 서버는 TLS(Transport Layer Security) 프레임워크를 사용하여 보호할 수 있습니다. TLS는 네트워크를 통해 통신 보안을 제공하도록 설계된 암호화 프로토콜입니다. Red Hat Enterprise Linux 7의 OpenLDAP 제품군은 TLS 구현으로 OpenSSL을 사용합니다.
TLS를 사용하여 보안 연결을 설정하려면 필요한 인증서를 가져옵니다. 그런 다음 클라이언트와 서버 모두에 여러 옵션을 구성해야 합니다. 최소한 서버는 CA(인증 기관) 인증서와 자체 서버 인증서 및 개인 키를 사용하여 구성해야 합니다. 클라이언트는 신뢰할 수 있는 모든 CA 인증서가 포함된 파일의 이름으로 구성해야 합니다.
일반적으로 서버는 단일 CA 인증서에만 서명해야 합니다. 클라이언트는 다양한 보안 서버에 연결하려고 할 수 있으므로 구성에 신뢰할 수 있는 여러 CA 목록을 지정하는 것이 일반적입니다.
서버 설정
이 섹션에는 TLS를 설정하기 위해 OpenLDAP 서버의 /etc/openldap/slapd.d/cn=config.ldif 파일에 지정해야 하는 slapd 의 글로벌 구성 지시문이 나열되어 있습니다.
이전 스타일 구성은 단일 파일을 사용하지만 일반적으로 /usr/local/etc/openldap/slapd.conf 로 설치됩니다. 새 스타일은 slapd 백엔드 데이터베이스를 사용하여 구성을 저장합니다. 구성 데이터베이스는 일반적으로 /usr/local/etc/openldap/slapd.d/ 디렉터리에 있습니다.
다음 지시문은 SSL을 설정하는 데도 유효합니다. TLS 지시문 외에도 서버 측에서 SSL 전용 포트를 활성화해야 합니다. 일반적으로 포트 636입니다. 이렇게 하려면 /etc/sysconfig/slapd 파일을 편집하고 SLAPD_URLS 지시문으로 지정된 URL 목록에 ldaps:/// 문자열을 추가합니다.
olcTLSCACertificateFile
olcTLSCACertificateFile 지시문은 신뢰할 수 있는 CA 인증서가 포함된 private-enhanced 메일(PEM) 스키마로 인코딩된 파일을 지정합니다. 지시문은 다음 형식을 사용합니다. 
olcTLSCACertificateFile: path
Copy to Clipboard Toggle word wrap
경로를 CA 인증서 파일의 경로로 바꿉니다.
olcTLSCACertificatePath
olcTLSCACertificatePath 지시문은 별도의 파일에 개별 CA 인증서를 포함하는 디렉터리의 경로를 지정합니다. 이 디렉터리는 실제 인증서 파일을 가리키는 해시된 이름으로 심볼릭 링크를 생성하는 OpenSSL c_rehash 유틸리티를 사용하여 특별히 관리해야 합니다. 일반적으로 olcTLSCACertificateFile 지시문을 사용하는 것이 더 간단합니다.
지시문은 다음 형식을 사용합니다. 
olcTLSCACertificatePath: path
Copy to Clipboard Toggle word wrap
경로를 CA 인증서 파일이 포함된 디렉터리의 경로로 바꿉니다. OpenSSL c_rehash 유틸리티를 사용하여 지정된 디렉터리를 관리해야 합니다.
olcTLSCertificateFile
olcTLSCertificateFile 지시문은 slapd 서버 인증서가 포함된 파일을 지정합니다. 지시문은 다음 형식을 사용합니다. 
olcTLSCertificateFile: path
Copy to Clipboard Toggle word wrap
path 를 slapd 서비스의 서버 인증서 파일의 경로로 바꿉니다.
olcTLSCertificateKeyFile
olcTLSCertificateKeyFile 지시문은 olcTLSCertificateFile 으로 지정된 파일에 저장된 인증서와 일치하는 개인 키가 포함된 파일을 지정합니다. 현재 구현에서는 암호화된 개인 키를 지원하지 않으므로 포함된 파일을 충분히 보호해야 합니다. 지시문은 다음 형식을 사용합니다. 
olcTLSCertificateKeyFile: path
Copy to Clipboard Toggle word wrap
경로를 개인 키 파일의 경로로 바꿉니다.
클라이언트 설정
클라이언트 시스템의 /etc/openldap/ldap.conf 구성 파일에 다음 지시문을 지정합니다. 이러한 지시문은 대부분 서버 구성 옵션과 병렬로 지정됩니다. /etc/openldap/ldap.conf 의 지시문은 시스템 전체에서 구성되지만 개별 사용자는 ~/.ldaprc 파일에서 해당 지시문을 덮어쓸 수 있습니다.
동일한 지시문을 사용하여 SSL 연결을 설정할 수 있습니다. ldapsearch 와 같은 OpenLDAP 명령에서 ldap:// 대신 ldaps:// 문자열을 사용해야 합니다. 이렇게 하면 명령이 서버에 구성된 SSL, 포트 636에 기본 포트를 사용하도록 강제 적용합니다.
TLS_CACERT
TLS_CACERT 지시문은 클라이언트가 인식할 모든 인증 기관의 인증서가 포함된 파일을 지정합니다. 서버의 olcTLSCACertificateFile 지시문과 동일합니다. TLS_CACERT 는 항상 /etc/openldap/ldap.conf 의 TLS_CACERTDIR 앞에 지정해야 합니다. 지시문은 다음 형식을 사용합니다. 
TLS_CACERT path
Copy to Clipboard Toggle word wrap
경로를 CA 인증서 파일의 경로로 바꿉니다.
TLS_CACERTDIR
TLS_CACERTDIR 지시문은 별도의 파일에 인증 기관 인증서가 포함된 디렉터리의 경로를 지정합니다. 서버의 olcTLSCACertificatePath 와 마찬가지로 OpenSSL c_rehash 유틸리티를 사용하여 지정된 디렉터리를 관리해야 합니다. 
TLS_CACERTDIR directory
Copy to Clipboard Toggle word wrap
디렉터리를 CA 인증서 파일이 포함된 디렉터리의 경로로 바꿉니다.
TLS_CERT
TLS_CERT 는 클라이언트 인증서를 포함하는 파일을 지정합니다. 이 지시문은 사용자의 ~/.ldaprc 파일에만 지정할 수 있습니다. 지시문은 다음 형식을 사용합니다. 
TLS_CERT path
Copy to Clipboard Toggle word wrap
경로를 클라이언트 인증서 파일의 경로로 바꿉니다.
TLS_KEY
TLS_KEY 는 TLS_CERT 지시문으로 지정된 파일에 저장된 인증서와 일치하는 개인 키가 포함된 파일을 지정합니다. 서버의 olcTLSCertificateFile 과 마찬가지로 암호화된 키 파일은 지원되지 않으므로 파일 자체를 신중하게 보호해야 합니다. 이 옵션은 사용자의 ~/.ldaprc 파일에서만 구성할 수 있습니다.
TLS_KEY 지시문은 다음 형식을 취합니다. 
TLS_KEY path
Copy to Clipboard Toggle word wrap
경로를 클라이언트 인증서 파일의 경로로 바꿉니다.
9.2.3.7. 복제 설정
링크 복사
복제는 하나의 LDAP 서버(프로바이더)에서 하나 이상의 다른 서버 또는 클라이언트(소켓)로 업데이트를 복사하는 프로세스입니다. 프로바이더는 디렉터리 업데이트를 소비자에게 복제하고, 수신된 업데이트는 소비자가 다른 서버에 추가로 전파할 수 있으므로 소비자가 공급업체로 동시에 작동할 수도 있습니다. 또한 소비자가 LDAP 서버일 필요는 없으며 LDAP 클라이언트일 수 있습니다. OpenLDAP에서는 여러 복제 모드를 사용할 수 있으며 가장 중요한 것은 미러 및 동기화 입니다. OpenLDAP 복제 모드에 대한 자세한 내용은 openldap-servers 패키지를 사용하여 설치된 OpenLDAP 소프트웨어 관리자 가이드를 참조하십시오( “설치된 문서”참조).
선택한 복제 모드를 활성화하려면 공급자와 소비자 모두에서 /etc/openldap/slapd.d/ 에서 다음 지시문 중 하나를 사용합니다.
olcMirrorMode
olcMirrorMode 지시문을 사용하면 미러 복제 모드를 사용할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcMirrorMode on
Copy to Clipboard Toggle word wrap
이 옵션은 프로바이더와 소비자 모두에 지정해야 합니다. 또한 syncrepl 옵션과 함께 serverID 를 지정해야 합니다. 18.3.4에서 자세한 예제를 찾습니다. OpenLDAP 소프트웨어 관리자 가이드의 MirrorMode 섹션( “설치된 문서”참조).
olcSyncrepl
olcSyncrepl 지시문을 사용하면 동기화 복제 모드를 사용할 수 있습니다. 다음과 같은 형식을 취합니다. 
olcSyncrepl on
Copy to Clipboard Toggle word wrap
동기화 복제 모드에는 프로바이더와 소비자 모두에 대한 특정 구성이 필요합니다. 이 구성은 18.3.1에 자세히 설명되어 있습니다. OpenLDAP 소프트웨어 관리자 가이드의 Syncrepl 섹션( “설치된 문서”참조).
9.2.3.8. 모듈 및 백엔드 로드
링크 복사
동적으로 로드된 모듈을 사용하여 slapd 서비스를 향상시킬 수 있습니다. 슬리핑을 구성할 때 --enable-modules 옵션을 사용하여 이러한 모듈에 대한 지원을 활성화해야 합니다. 모듈은 .la 확장자가 있는 파일에 저장됩니다. 
module_name.la
Copy to Clipboard Toggle word wrap
백엔드 는 LDAP 요청에 대한 응답으로 데이터를 저장하거나 검색합니다. 백엔드는 슬폴드로 정적 으로 컴파일 되거나 모듈 지원이 활성화된 경우 동적으로 로드할 수 있습니다. 후자의 경우 다음 명명 규칙이 적용됩니다. 
back_backend_name.la
Copy to Clipboard Toggle word wrap
모듈 또는 백엔드를 로드하려면 /etc/openldap/slapd.d/:에서 다음 지시문을 사용하십시오.
olcModuleLoad
olcModuleLoad 지시문은 로드할 동적으로 로드 가능한 모듈을 지정합니다. 다음과 같은 형식을 취합니다. 
olcModuleLoad: module
Copy to Clipboard Toggle word wrap
여기서 모듈은 모듈이 포함된 파일 또는 로드될 백엔드를 나타냅니다.

9.2.4. LDAP를 사용하여 응용 프로그램에 대한 SELinux 정책
링크 복사

SELinux는 Linux 커널의 필수 액세스 제어 메커니즘 구현입니다. 기본적으로 SELinux는 애플리케이션이 OpenLDAP 서버에 액세스하는 것을 방지합니다. 여러 애플리케이션에 필요한 LDAP를 통한 인증을 활성화하려면 allow_ypbind SELinux 부울을 활성화해야 합니다. 특정 애플리케이션에는 이 시나리오에서 활성화된 authlogin_nsswitch_use_ldap 부울도 필요합니다. 앞에서 언급한 부울을 활성화하려면 다음 명령을 실행합니다. 
~]# setsebool -P allow_ypbind=1
Copy to Clipboard Toggle word wrap 
~]# setsebool -P authlogin_nsswitch_use_ldap=1
Copy to Clipboard Toggle word wrap
P 옵션을 사용하면 시스템 재부팅 시 이 설정이 지속됩니다. SELinux에 대한 자세한 내용은 Red Hat Enterprise Linux 7 SELinux 사용자 및 관리자 가이드를 참조하십시오.

9.2.5. OpenLDAP 서버 실행
링크 복사

이 섹션에서는 독립 실행형 LDAP 데몬 의 현재 상태를 시작, 중지, 다시 시작하는 방법을 설명합니다. 일반적으로 시스템 서비스를 관리하는 방법에 대한 자세한 내용은 시스템 관리자 가이드에서 systemd를 사용하여 서비스 관리를 참조하십시오.
9.2.5.1. 서비스 시작
링크 복사
현재 세션에서 슬apd 서비스를 시작하려면 쉘 프롬프트에 root 로 다음을 입력합니다. 
~]# systemctl start slapd.service
Copy to Clipboard Toggle word wrap
부팅 시 자동으로 시작하도록 서비스를 구성하려면 root 로 다음 명령을 사용합니다. 
~]# systemctl enable slapd.service
ln -s '/usr/lib/systemd/system/slapd.service' '/etc/systemd/system/multi-user.target.wants/slapd.service'
Copy to Clipboard Toggle word wrap
9.2.5.2. 서비스 중지
링크 복사
현재 세션에서 실행 중인 slapd 서비스를 중지하려면 쉘 프롬프트에 root 로 다음을 입력합니다. 
~]# systemctl stop slapd.service
Copy to Clipboard Toggle word wrap
부팅 시 서비스가 자동으로 시작되지 않도록 하려면 root 로 입력합니다. 
~]# systemctl disable slapd.service
rm '/etc/systemd/system/multi-user.target.wants/slapd.service'
Copy to Clipboard Toggle word wrap
9.2.5.3. 서비스 재시작
링크 복사
실행 중인 슬apd 서비스를 다시 시작하려면 쉘 프롬프트에서 다음을 입력합니다. 
~]# systemctl restart slapd.service
Copy to Clipboard Toggle word wrap
그러면 서비스가 중지되고 즉시 다시 시작됩니다. 이 명령을 사용하여 구성을 다시 로드합니다.
9.2.5.4. 서비스 상태 확인
링크 복사
slapd 서비스가 실행 중인지 확인하려면 쉘 프롬프트에 다음을 입력합니다. 
~]$ systemctl is-active slapd.service
active
Copy to Clipboard Toggle word wrap

9.2.6. OpenLDAP를 사용하여 인증할 시스템 구성
링크 복사

OpenLDAP를 사용하여 인증할 시스템을 구성하려면 적절한 패키지가 LDAP 서버 및 클라이언트 시스템에 모두 설치되어 있는지 확인합니다. 서버 설정 방법에 대한 자세한 내용은 9.2.2절. “OpenLDAP 제품군 설치” 및 9.2.3절. “OpenLDAP 서버 구성” 의 지침을 따르십시오. 클라이언트의 쉘 프롬프트에서 다음을 입력합니다. 
~]# yum install openldap openldap-clients nss-pam-ldapd
Copy to Clipboard Toggle word wrap
9.2.6.1. LDAP 형식으로 이전 인증 정보 마이그레이션
링크 복사
migrationtools 패키지는 인증 정보를 LDAP 형식으로 마이그레이션하는 데 도움이 되는 쉘 및 Perl 스크립트 집합을 제공합니다. 이 패키지를 설치하려면 쉘 프롬프트에서 다음을 입력합니다. 
~]# yum install migrationtools
Copy to Clipboard Toggle word wrap
그러면 /usr/share/migrationtools/ 디렉터리에 스크립트가 설치됩니다. 설치가 완료되면 /usr/share/migrationtools/migrate_common.ph 파일을 편집하고 다음 행을 변경하여 올바른 도메인을 반영합니다. 
# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "example.com";

# Default base
$DEFAULT_BASE = "dc=example,dc=com";
Copy to Clipboard Toggle word wrap
또는 명령줄에서 직접 환경 변수를 지정할 수 있습니다. 예를 들어 기본 base를 dc=example,dc=com, type 로 설정하여 migrate_all_online.sh 스크립트를 실행하려면 다음을 입력합니다. 
~]# export DEFAULT_BASE="dc=example,dc=com" \
/usr/share/migrationtools/migrate_all_online.sh
Copy to Clipboard Toggle word wrap
사용자 데이터베이스를 마이그레이션하기 위해 실행할 스크립트를 확인하려면 표 9.8. “일반적으로 사용되는 LDAP 마이그레이션 스크립트” 을 참조하십시오.
Expand
표 9.8. 일반적으로 사용되는 LDAP 마이그레이션 스크립트
기존 이름 서비스 LDAP가 실행 중입니까? 사용할 스크립트
/etc 플랫 파일 제공됨 migrate_all_online.sh
/etc 플랫 파일 아니요 migrate_all_offline.sh
NetInfo 제공됨 migrate_all_netinfo_online.sh
NetInfo 아니요 migrate_all_netinfo_offline.sh
NIS (YP) 제공됨 migrate_all_nis_online.sh
NIS (YP) 아니요 migrate_all_nis_offline.sh
이러한 스크립트를 사용하는 방법에 대한 자세한 내용은 /usr/share/doc/migrationtools-버전/ 디렉터리의 README 및 migration-tools.txt 파일을 참조하십시오.

9.2.7. 추가 리소스
링크 복사

다음 리소스는 경량 디렉터리 액세스 프로토콜에 대한 추가 정보를 제공합니다. 시스템에서 LDAP를 구성하기 전에 이러한 리소스, 특히 OpenLDAP 소프트웨어 관리자 가이드를 검토하는 것이 좋습니다.

설치된 문서

다음 설명서는 openldap-servers 패키지와 함께 설치됩니다.
  • /usr/share/doc/openldap-servers-버전/guide.html - OpenLDAP 소프트웨어 관리자 가이드의 사본 .
  • /usr/share/doc/openldap-servers-버전/README.schema - 설치된 스키마 파일에 대한 설명이 포함된 README 파일입니다.
또한 openldap, openldap-servers 및 openldap - clients 패키지와 함께 설치된 여러 도움말 페이지도 있습니다.
클라이언트 애플리케이션
  • ldapadd(1) - ldapadd 명령의 도움말 페이지는 LDAP 디렉터리에 항목을 추가하는 방법을 설명합니다.
  • ldapdelete(1) - ldapdelete 명령의 도움말 페이지는 LDAP 디렉터리 내의 항목을 삭제하는 방법을 설명합니다.
  • ldapmodify(1) - ldapmodify 명령의 도움말 페이지에서 LDAP 디렉터리 내의 항목을 수정하는 방법을 설명합니다.
  • ldapsearch(1) - ldapsearch 명령의 도움말 페이지는 LDAP 디렉터리 내에서 항목을 검색하는 방법을 설명합니다.
  • ldappasswd(1) - ldappasswd 명령의 도움말 페이지에서 LDAP 사용자의 암호를 설정하거나 변경하는 방법을 설명합니다.
  • ldapcompare(1) - ldapcompare 툴 사용 방법을 설명합니다.
  • ldapwhoami(1) - ldapwhoami 툴 사용 방법을 설명합니다.
  • ldapmodrdn(1) - 항목의 RDNs를 수정하는 방법을 설명합니다.
서버 애플리케이션
  • slapd(8C) - LDAP 서버의 명령행 옵션을 설명합니다.
관리 애플리케이션
  • slapadd(8C) - 슬랩된 데이터베이스에 항목을 추가하는 데 사용되는 명령행 옵션에 대해 설명합니다.
  • slapcat(8C) - 슬립 된 데이터베이스에서 LDIF 파일을 생성하는 데 사용되는 명령행 옵션에 대해 설명합니다.
  • slapindex(8C) - 슬립 된 데이터베이스의 내용을 기반으로 인덱스를 다시 생성하는 데 사용되는 명령행 옵션에 대해 설명합니다.
  • slappasswd(8C) - LDAP 디렉터리의 사용자 암호를 생성하는 데 사용되는 명령행 옵션을 설명합니다.
설정 파일
  • ldap.conf(5) - ldap.conf 파일의 도움말 페이지는 LDAP 클라이언트의 구성 파일에서 사용할 수 있는 형식과 옵션을 설명합니다.
  • slapd-config(5) - /etc/openldap/slapd.d 구성 디렉터리 내에서 사용할 수 있는 형식 및 옵션을 설명합니다.
기타 리소스

III 부. 애플리케이션 보안
링크 복사

이 부분에서는PAM( Pluggable Authentication Modules ) 사용 방법, Kerberos 인증 프로토콜 및 certmonger 데몬 사용 방법, 마지막으로SSO( Single Sign-On )에 대한 애플리케이션을 구성하는 방법에 대해 자세히 설명합니다.

10장. PAM(Pluggable Authentication Module) 사용
링크 복사

PAM( 장착형 인증 모듈 )은 인증 및 권한 부여를 위한 일반적인 프레임워크입니다. Red Hat Enterprise Linux의 대부분의 시스템 애플리케이션은 인증 및 권한 부여를 위한 기본 PAM 구성에 따라 다릅니다.

10.1. PAM 정보
링크 복사

PAM(Pluggable Authentication Modules)은 시스템 애플리케이션이 중앙 집중식으로 구성된 프레임워크에 인증을 릴레이하는 데 사용할 수 있는 중앙 집중식 인증 메커니즘을 제공합니다.
PAM은 다양한 유형의 인증 소스(예: Kerberos, SSSD, NIS 또는 로컬 파일 시스템)에 대한 PAM 모듈이 있으므로 연결할 수 있습니다. 서로 다른 인증 소스에 우선 순위를 지정할 수 있습니다.
이 모듈식 아키텍처는 관리자가 시스템에 대한 인증 정책을 설정할 때 상당한 유연성을 제공합니다. PAM은 다음과 같은 몇 가지 이유로 개발자와 관리자에게 유용한 시스템입니다.
  • PAM은 다양한 애플리케이션과 함께 사용할 수 있는 공통 인증 체계를 제공합니다.
  • PAM은 시스템 관리자에게 상당한 유연성과 인증에 대한 제어를 제공합니다.
  • PAM은 개발자가 자체 인증 체계를 만들 필요 없이 프로그램을 작성할 수 있는 완전한 문서화된 단일 라이브러리를 제공합니다.

10.1.1. 기타 PAM 리소스
링크 복사

PAM에는 PAM을 사용하고 모듈을 작성하여 PAM을 확장하거나 다른 애플리케이션과 통합하는 방법에 대한 자세한 내용이 포함된 광범위한 문서가 있습니다. PAM이 포함된 거의 모든 주요 모듈 및 구성 파일에는 고유한 도움말 페이지가 있습니다. 또한 /usr/share/doc/pam-version#/ 디렉터리에는 시스템 관리자 가이드, 모듈 작성기 매뉴얼, 애플리케이션 개발자 매뉴얼, PAM 표준 DCE-RFC 86.0의 사본이 포함되어 있습니다.
PAM 라이브러리는 에서 사용할 수 있습니다 http://www.linux-pam.org. Linux-PAM 프로젝트의 기본 배포 웹 사이트로, 다양한 PAM 모듈에 대한 정보, 자주 묻는 질문 및 추가 PAM 문서가 포함되어 있습니다.

10.1.2. 사용자 정의 PAM 모듈
링크 복사

새 PAM 모듈은 PAM 인식 애플리케이션에서 사용할 수 있도록 언제든지 생성하거나 추가할 수 있습니다. PAM 인식 프로그램은 재컴파일 또는 기타 수정 없이 새 모듈 및 정의하는 메서드를 즉시 사용할 수 있습니다. 이를 통해 개발자와 시스템 관리자는 다시 컴파일하지 않고도 다양한 프로그램에 대해 선택한 인증 모듈과 테스트를 사용할 수 있습니다.
모듈 작성에 대한 문서는 /usr/share/doc/pam-devel-version#/ 디렉터리에 포함되어 있습니다.

10.2. PAM 구성 파일 정보
링크 복사

각 PAM 인식 애플리케이션 또는 서비스에는 /etc/pam.d/ 디렉터리에 파일이 있습니다. 이 디렉터리의 각 파일의 이름은 액세스를 제어하는 서비스와 동일합니다. 예를 들어 로그인 프로그램은 서비스 이름을 login 로 정의하고 /etc/pam.d/login PAM 구성 파일을 설치합니다.
주의
PAM 구성 파일을 수동으로 편집하는 대신 authconfig 도구를 사용하여 PAM을 구성하는 것이 좋습니다.

10.2.1. PAM 구성 파일 형식
링크 복사

각 PAM 구성 파일에는 모듈(인증 구성 영역)을 정의하는 지시문 그룹과 모든 제어 또는 인수를 포함합니다.
지시문에는 모듈 목적(인터페이스)과 모듈의 구성 설정을 식별하는 간단한 구문이 있습니다. 
module_interface	control_flag	module_name module_arguments
Copy to Clipboard Toggle word wrap
PAM 구성 파일에서 모듈 인터페이스는 정의된 첫 번째 필드입니다. 예를 들어 다음과 같습니다. 
auth	required	pam_unix.so
Copy to Clipboard Toggle word wrap
PAM 인터페이스는 특정 모듈이 수행할 수 있는 인증 작업의 유형입니다. 각각 인증 및 권한 부여 프로세스의 다른 측면에 해당하는 4가지 유형의 PAM 모듈 인터페이스를 사용할 수 있습니다.
  • auth - 이 모듈 인터페이스는 사용자를 인증합니다. 예를 들어 암호의 유효성을 요청하고 확인합니다. 이 인터페이스의 모듈은 그룹 멤버십과 같은 자격 증명을 설정할 수도 있습니다.
  • account - 이 모듈 인터페이스는 액세스가 허용되는지 확인합니다. 예를 들어 사용자 계정이 만료되었는지 또는 사용자가 특정 시간에 로그인할 수 있는지 확인합니다.
  • password - 이 모듈 인터페이스는 사용자 암호를 변경하는 데 사용됩니다.
  • 세션 - 이 모듈 인터페이스는 사용자 세션을 구성하고 관리합니다. 이 인터페이스의 모듈은 사용자의 홈 디렉터리를 마운트하고 사용자의 사서함을 사용할 수 있도록 액세스를 허용하는 데 필요한 추가 작업도 수행할 수 있습니다.
개별 모듈은 일부 또는 모든 모듈 인터페이스를 제공할 수 있습니다. 예를 들어 pam_unix.so 는 4개의 모듈 인터페이스를 모두 제공합니다.
pam_unix.so 와 같은 모듈 이름은 PAM에 지정된 모듈 인터페이스가 포함된 라이브러리 이름을 제공합니다. 애플리케이션이 올바른 버전의 모듈을 찾을 수 있는 libpam 의 적절한 버전에 연결되어 있기 때문에 디렉터리 이름이 생략됩니다.
모든 PAM 모듈은 호출 시 성공 또는 실패 결과를 생성합니다. Control 플래그는 PAM에 결과와 함께 수행할 작업을 지시합니다. 모듈은 특정 순서로 나열(스택)될 수 있으며, 제어 플래그는 특정 모듈의 성공 또는 실패가 사용자를 서비스에 인증하는 전체 목표에 얼마나 중요한지를 결정합니다.
몇 가지 간단한 플래그가 있습니다.[2], 키워드만 사용하여 구성을 설정합니다.
  • required - 인증을 계속하려면 모듈 결과가 성공해야 합니다. 이 시점에서 테스트가 실패하면 해당 인터페이스를 참조하는 모든 모듈의 결과가 완료될 때까지 사용자에게 알리지 않습니다.
  • 필수 조건 - 모듈 결과가 인증을 계속하려면 성공해야 합니다. 그러나 이 시점에서 테스트에 실패하면 첫 번째 실패 또는 필수 모듈 테스트를 반영하는 메시지와 함께 사용자에게 즉시 알림을 받습니다.
  • sufficient - 모듈 결과가 실패하는 경우 무시됩니다. 그러나 모듈 결과에 sufficient 으로 플래그가 지정되어 있고 필요한 이전 모듈이 실패한 경우 다른 결과가 필요하지 않으며 사용자가 서비스에 인증됩니다.
  • 선택 사항 - 모듈 결과가 무시됩니다. 다른 모듈이 인터페이스를 참조하지 않는 경우 성공적인 인증에만 선택 옵션으로 플래그가 지정됩니다.
  • include - 다른 제어와 달리 모듈 결과가 처리되는 방법과 관련이 없습니다. 이 플래그는 지정된 매개 변수와 일치하는 구성 파일의 모든 행을 가져와 모듈에 인수로 추가합니다.
모듈 인터페이스 지시문을 스택 하거나 서로 배치하여 여러 모듈을 한 용도로 함께 사용할 수 있습니다.
참고
모듈의 제어 플래그에서 sufficient 또는 requisite 값을 사용하는 경우 모듈이 나열되는 순서가 인증 프로세스에 중요합니다.
관리자는 스태킹을 사용하여 사용자가 인증하기 전에 특정 조건을 사용해야 할 수 있습니다. 예를 들어 설정 유틸리티는 일반적으로 PAM 구성 파일에 표시된 대로 여러 개의 스택된 모듈을 사용합니다. 
[root@MyServer ~]# cat /etc/pam.d/setup

auth       sufficient	pam_rootok.so
auth       include	system-auth
account    required	pam_permit.so
session	   required	pam_permit.so
Copy to Clipboard Toggle word wrap
  • auth sufficient pam_rootok.so - 이 행은 pam_rootok.so 모듈을 사용하여 UID가 0인지 확인하여 현재 사용자가 root인지 확인합니다. 이 테스트에 성공하면 다른 모듈이 확인되지 않고 명령이 실행됩니다. 이 테스트가 실패하면 다음 모듈이 참조됩니다.
  • auth include system-auth - 이 행에는 /etc/pam.d/system-auth 모듈의 콘텐츠가 포함되어 인증을 위해 이 콘텐츠를 처리합니다.
  • 계정 필수 pam_permit.so - 이 줄은 pam_permit.so 모듈을 사용하여 root 사용자 또는 콘솔에 로그인한 모든 사용자가 시스템을 재부팅할 수 있도록 허용합니다.
  • 세션 필수 pam_permit.so - 이 행은 세션 설정과 관련이 있습니다. pam_permit.so 를 사용하면 설정 유틸리티가 실패하지 않습니다.
PAM은 인수를 사용하여 일부 모듈에 대한 인증 중에 플러그형 모듈에 정보를 전달합니다.
예를 들어 pam_pwquality.so 모듈은 암호가 얼마나 강하고 여러 개의 인수를 사용할 수 있는지 확인합니다. 다음 예에서 enforce_for_root 는 루트 사용자의 암호도 강력한 검사를 성공적으로 통과해야 하며 재시도는 사용자가 강력한 암호를 입력할 수 있는 세 가지 기회를 수신하도록 정의합니다. 
password	requisite	pam_pwquality.so enforce_for_root retry=3
Copy to Clipboard Toggle word wrap
잘못된 인수는 일반적으로 무시되며 그렇지 않으면 PAM 모듈의 성공 또는 실패에 영향을 주지 않습니다. 그러나 일부 모듈은 유효하지 않은 인수에서 실패할 수 있습니다. 대부분의 모듈은 journald 서비스에 오류를 보고합니다. journald 및 관련 journalctl 툴을 사용하는 방법에 대한 자세한 내용은 시스템 관리자 가이드를 참조하십시오.
참고
journald 서비스는 Red Hat Enterprise Linux 7.1에서 도입되었습니다. 이전 버전의 Red Hat Enterprise Linux에서 대부분의 모듈은 오류를 /var/log/secure 파일에 보고합니다.

10.2.2. 주석이 있는 PAM 구성 예
링크 복사

예 10.1. “간단한 PAM 구성” 샘플 PAM 애플리케이션 구성 파일입니다.

예 10.1. 간단한 PAM 구성

#%PAM-1.0
auth		required	pam_securetty.so
auth		required	pam_unix.so nullok
auth		required	pam_nologin.so
account		required	pam_unix.so
password	required	pam_pwquality.so retry=3
password	required	pam_unix.so shadow nullok use_authtok
session		required	pam_unix.so
Copy to Clipboard Toggle word wrap
  • 첫 번째 줄은 행 시작 부분에 해시 표시(#)로 표시된 주석입니다.
  • 로그인 인증을 위해 2-4개의 스택 3개 모듈을 행합니다.
    auth required pam_securetty.so - 이 모듈은 사용자가 root로 로그인하려고 하는 경우 해당 파일이 있는 경우 사용자가 로그인하는 TTY가 /etc/securetty 파일에 나열되도록 합니다.
    TTY가 파일에 나열되지 않은 경우 root로 로그인하려고 하면 로그인 잘못된 메시지와 함께 실패합니다.
    auth required pam_unix.so nullok - 이 모듈은 사용자에게 암호를 묻는 다음 /etc/passwd 에 저장된 정보를 사용하여 암호를 확인하고, 존재하는 경우 /etc/shadow.
    nullok 인수는 pam_unix.so 모듈을 지시하여 빈 암호를 허용합니다.
  • auth required pam_nologin.so - 최종 인증 단계입니다. /etc/nologin 파일이 있는지 확인합니다. 존재하고 사용자가 root가 아닌 경우 인증에 실패합니다.
    참고
    이 예제에서는 첫 번째 auth 모듈이 실패하더라도 세 개의 auth 모듈이 모두 확인됩니다. 이렇게 하면 사용자가 인증에 실패한 단계에서 알 수 없습니다. 공격자는 이러한 지식을 통해 시스템을 크래핑하는 방법을 보다 쉽게 줄일 수 있습니다.
  • 계정 필수 pam_unix.so - 이 모듈은 필요한 계정 확인을 수행합니다. 예를 들어 shadow 암호가 활성화된 경우 pam_unix.so 모듈의 계정 인터페이스에서 계정이 만료되었는지 또는 사용자가 허용된 유예 기간 내에 암호를 변경하지 않았는지 확인합니다.
  • 암호 required pam_pwquality.so retry=3 - 암호가 만료된 경우 pam_pwquality.so 모듈의 password 구성 요소에서 새 암호를 입력하라는 메시지를 표시합니다. 그런 다음 새로 생성된 암호를 테스트하여 사전 기반 암호 크래킹 프로그램으로 쉽게 결정할 수 있는지 확인합니다.
    retry=3 인수는 테스트가 처음으로 실패하면 사용자에게 강력한 암호를 만들 가능성이 두 개 더 있음을 나타냅니다.
  • 암호 required pam_unix.so shadow nullok use_authtok - 이 줄은 프로그램이 pam_unix.so 모듈의 암호 인터페이스를 사용하여 사용자의 암호를 변경하는 경우 를 나타냅니다.
    • 인수 shadow 는 사용자의 암호를 업데이트할 때 섀도우 암호를 생성하도록 모듈에 지시합니다.
    • nullok 인수는 사용자가 빈 암호 에서 암호를 변경할 수 있도록 모듈에 지시합니다. 그렇지 않으면 null 암호가 계정 잠금으로 처리됩니다.
    • 이 행의 마지막 인수인 use_authtok 에서는 PAM 모듈을 스택할 때 순서가 중요합니다. 이 인수는 모듈에 새 암호를 요청하는 메시지를 표시하지 않도록 지시합니다. 대신 이전 암호 모듈에서 기록한 암호를 허용합니다. 이렇게 하면 모든 새 암호가 허용되기 전에 보안 암호를 위해 pam_pwquality.so 테스트를 전달해야 합니다.
  • 세션 required pam_unix.so - 최종 줄은 pam_unix.so 모듈의 세션 인터페이스에 세션을 관리하도록 지시합니다. 이 모듈은 사용자 이름과 서비스 유형을 각 세션의 시작과 종료 시 /var/log/secure 에 기록합니다. 이 모듈은 추가 기능을 위해 다른 세션 모듈과 스택하여 보완할 수 있습니다.

[2] 설정할 수 있는 다양한 제어 플래그가 있습니다. 이는 attribute=value 쌍으로 설정됩니다. 전체 속성 목록은 pam.d manpage에서 사용할 수 있습니다.

10.3. PAM 및 관리 인증 정보 캐싱
링크 복사

GNOME의 control-center 와 같은 Red Hat Enterprise Linux의 여러 그래픽 관리 툴은 사용자에게 pam_timestamp.so 모듈을 사용하여 최대 5분 동안 승격된 권한을 제공합니다. pam_timestamp.so 는 실제로 콘솔에 대한 물리적 액세스 권한이 있는 모든 사용자가 조작하기 때문에 이 메커니즘이 작동하는 방식을 이해하는 것이 중요합니다.
PAM 타임스탬프 체계에서 그래픽 관리 애플리케이션은 루트 암호를 시작할 때 사용자에게 메시지를 표시합니다. 사용자가 인증되면 pam_timestamp.so 모듈은 타임스탬프 파일을 생성합니다. 기본적으로 이는 /var/run/sudo/ 디렉터리에 생성됩니다. 타임스탬프 파일이 이미 있으면 그래픽 관리 프로그램에서 암호를 묻는 메시지가 표시되지 않습니다. 대신 pam_timestamp.so 모듈은 타임스탬프 파일을 새로 고치고 사용자를 위해 예약되지 않은 5분의 추가 관리 액세스를 예약합니다.
/var/run/sudo/사용자 디렉터리에서 파일을 검사하여 타임스탬프 파일의 실제 상태를 확인할 수 있습니다. 데스크탑의 경우 관련 파일은 unknown:root 입니다. 이 항목이 있고 타임스탬프가 5분 미만인 경우 자격 증명이 유효합니다.
타임스탬프 파일이 있으면 패널의 알림 영역에 표시되는 인증 아이콘으로 표시됩니다.

그림 10.1. 인증 아이콘

인증 아이콘
View larger image
인증 아이콘

[D]

10.3.1. 공통 pam_timestamp 지시문
링크 복사

pam_timestamp.so 모듈은 다음 두 인터페이스를 제공합니다.
  • auth
  • 세션
또한 pam_timestamp.so 에 대해 다음 옵션을 사용할 수 있습니다.
  • timestamp_timeout: 타임스탬프 파일의 유효 기간(초)을 기본적으로 300분(five 분)으로 지정합니다.
  • timestampdir: 기본적으로 /var/run/sudo/ )로 타임스탬프 파일이 저장되는 디렉터리를 지정합니다.
  • 자세한 메시지는 verbose 또는 debug 를 사용할 수도 있습니다.
예를 들어 다음과 같습니다. 
auth       sufficient    pam_timestamp.so timestamp_timeout=600
session    optional     pam_timestamp.so
Copy to Clipboard Toggle word wrap
PAM의 지시문을 사용하고 구성하는 방법에 대한 자세한 내용은 10.2절. “PAM 구성 파일 정보” 을 참조하십시오. pam_timestamp(8) 도움말 페이지 및 pam.conf(5) 도움말 페이지도 참조하십시오.

10.3.2. 타임 스탬프 파일 제거
링크 복사

PAM 타임스탬프가 활성화된 콘솔을 종료하기 전에 타임스탬프 파일을 삭제하는 것이 좋습니다. 그래픽 환경에서 이 작업을 수행하려면 패널에서 인증 아이콘을 클릭합니다. 그러면 대화 상자가 표시됩니다. 활성 타임스탬프 파일을 삭제하려면 Forget Authorization 버튼을 클릭합니다.

그림 10.2. 인증 대화 상자 비활성화

인증 대화 상자 비활성화
View larger image
인증 대화 상자 비활성화

[D]
PAM 타임스탬프 파일에는 다음과 같은 몇 가지 중요한 특징이 있습니다.
  • ssh 를 사용하여 원격으로 시스템에 로그인한 경우 /sbin/pam_timestamp_check -k root 명령을 사용하여 타임스탬프 파일을 제거합니다.
  • 권한이 있는 애플리케이션이 시작된 동일한 터미널 창에서 /sbin/pam_timestamp_check -k root 명령을 실행합니다.
  • 처음 pam_timestamp.so 모듈을 호출한 로그인 사용자는 /sbin/pam_timestamp_check -k 명령을 실행하는 사용자여야 합니다. 이 명령을 root로 실행하지 마십시오.
  • 아이콘에서 Forget Authorization 작업을 사용하지 않고 데스크탑의 인증 정보를 종료하는 것은 /sbin/pam_timestamp_check 명령을 사용하여 수행할 수 있습니다. 
    /sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
    Copy to Clipboard Toggle word wrap
    다른 모든 메서드는 명령이 실행된 PTY에서 자격 증명만 제거합니다.
pam_timestamp_check 를 사용하여 타임스탬프 파일 제거에 대한 자세한 내용은 pam_timestamp_check 도움말 페이지를 참조하십시오.

10.4. PAM 서비스의 도메인 제한
링크 복사

중요
이 기능을 사용하려면 SSSD가 시스템에서 실행 중이어야 합니다.
SSSD를 사용하면 PAM 서비스에서 액세스할 수 있는 도메인을 제한할 수 있습니다. SSSD는 특정 PAM 서비스가 실행 중인 사용자를 기반으로 PAM 서비스의 인증 요청을 평가합니다. PAM 서비스가 SSSD 도메인에 액세스할 수 있는지 여부는 PAM 서비스 사용자가 도메인에 액세스할 수 있는지 여부에 따라 다릅니다.
예제 사용 사례는 외부 사용자가 FTP 서버에 인증할 수 있는 환경입니다. FTP 서버는 내부 회사 계정과는 별도로 선택한 SSSD 도메인에만 인증할 수 있는 별도의 권한이 없는 사용자로 실행 중입니다. 이 기능을 사용하면 FTP 사용자가 FTP PAM 구성 파일에 지정된 선택된 도메인에만 인증할 수 있습니다.
참고
이 기능은 pam_ldap 와 같은 기존 PAM 모듈과 유사합니다. 이 모듈은 별도의 구성 파일을 PAM 모듈의 매개 변수로 사용할 수 있었습니다.
도메인에 대한 액세스를 제한하는 옵션
다음 옵션을 사용하여 선택한 도메인에 대한 액세스를 제한할 수 있습니다.
pam_trusted_users in /etc/sssd/sssd.conf
이 옵션은 SSSD에서 신뢰할 수 있는 PAM 서비스를 나타내는 숫자 UID 또는 사용자 이름 목록을 허용합니다. 기본 설정은 all 입니다. 즉, 모든 서비스 사용자가 신뢰할 수 있으며 모든 도메인에 액세스할 수 있습니다.
pam_public_domains in /etc/sssd/sssd.conf
이 옵션은 공용 SSSD 도메인 목록을 허용합니다. 공용 도메인은 신뢰할 수 없는 PAM 서비스 사용자의 경우에도 액세스할 수 있는 도메인입니다. 옵션에서는 all 및 none 값도 허용합니다. 기본값은 none 입니다. 즉, 도메인은 공용이 아니며 신뢰할 수 없는 서비스 사용자가 도메인에 액세스할 수 없습니다.
PAM 구성 파일의 도메인
이 옵션은 PAM 서비스가 인증할 수 있는 도메인 목록을 지정합니다. 도메인을 지정하지 않고 도메인을 사용하는 경우 PAM 서비스는 모든 도메인에 대해 인증할 수 없습니다. 예를 들면 다음과 같습니다. 
auth     required   pam_sss.so domains=
Copy to Clipboard Toggle word wrap
PAM 구성 파일에서 도메인 을 사용하지 않는 경우 PAM 서비스는 신뢰할 수 있는 사용자로 서비스가 실행 중인 상태에서 모든 도메인에 대해 인증할 수 있습니다.
/etc/sssd/sssd.conf SSSD 구성 파일의 domain 옵션도 SSSD가 인증을 시도하는 도메인 목록을 지정합니다. PAM 구성 파일의 domain 옵션은 sssd.conf 의 도메인 목록을 확장할 수 없습니다. 더 짧은 목록을 지정하여 도메인의 sssd.conf 목록만 제한할 수 있습니다. 따라서 도메인이 PAM 파일에 지정되어 있지만 sssd.conf 에 없는 경우 PAM 서비스는 도메인에 대해 인증할 수 없습니다.
기본 설정 pam_trusted_users = all 및 pam_public_domains = none 은 모든 PAM 서비스 사용자가 신뢰할 수 있으며 모든 도메인에 액세스할 수 있음을 지정합니다. PAM 구성 파일의 domain 옵션은 액세스할 수 있는 도메인을 제한하도록 이 상황에서 사용할 수 있습니다.
sssd.conf 에 pam_public_domains 를 포함하는 동안 PAM 구성 파일의 도메인을 사용하여 도메인을 지정하는 경우 pam_public_domains 에도 도메인을 지정해야 할 수 있습니다. pam_public_domains 가 사용되지만 필요한 도메인을 포함하지 않으면 신뢰할 수 없는 사용자에서 실행되는 경우 PAM 서비스가 도메인에 대해 성공적으로 인증할 수 없습니다.
참고
PAM 구성 파일에 정의된 도메인 제한은 사용자 조회가 아닌 인증 작업에만 적용됩니다.
pam_trusted_users 및 pam_public_domains 옵션에 대한 자세한 내용은 sssd.conf(5) 도움말 페이지를 참조하십시오. PAM 구성 파일에 사용된 도메인 옵션에 대한 자세한 내용은 pam_sss(8) 도움말 페이지를 참조하십시오.

예 10.2. PAM 서비스의 도메인 제한

PAM 서비스가 인증할 수 있는 도메인을 제한하려면 다음을 수행합니다.
  1. SSSD가 필요한 도메인 또는 도메인에 액세스하도록 구성되어 있는지 확인합니다. SSSD를 인증할 수 있는 도메인 은 /etc/sssd/sssd.conf 파일의 domain 옵션에 정의되어 있습니다. 
    [sssd]
domains = domain1, domain2, domain3
    Copy to Clipboard Toggle word wrap
  2. PAM 서비스가 인증할 수 있는 도메인 또는 도메인을 지정합니다. 이렇게 하려면 PAM 구성 파일에서 domain 옵션을 설정합니다. 예를 들어 다음과 같습니다. 
    auth        sufficient    pam_sss.so forward_pass domains=domain1
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
password    sufficient    pam_sss.so use_authtok
    Copy to Clipboard Toggle word wrap
이제 PAM 서비스는 domain1 에 대해서만 인증할 수 있습니다.

11장. Kerberos 사용
링크 복사

네트워크 내에서 시스템 보안과 무결성을 유지하는 것은 매우 중요하며, 네트워크 인프라 내의 모든 사용자, 애플리케이션, 서비스 및 서버를 포함합니다. 네트워크에서 실행 중인 모든 사항과 이러한 서비스가 사용되는 방식을 이해해야 합니다. 이러한 보안 유지 관리의 핵심은 이러한 애플리케이션 및 서비스에 대한 액세스를 유지하고 이러한 액세스를 적용하는 것입니다.
Kerberos는 일반적인 암호 기반 인증보다 훨씬 더 안전한 인증 프로토콜입니다. Kerberos를 사용하면 다른 시스템에서 서비스에 액세스하는 경우에도 암호를 네트워크를 통해 전송하지 않습니다.
Kerberos는 사용자와 시스템 모두 네트워크를 식별하고 관리자가 구성한 영역 및 서비스에 대해 정의되고 제한된 액세스를 받을 수 있는 메커니즘을 제공합니다. Kerberos는 ID를 확인하여 엔터티를 인증하고 Kerberos는 이러한 인증 데이터를 보호하여 외부 사용자가 액세스하거나 사용하거나 조작할 수 없도록 합니다.

11.1. Kerberos 정보
링크 복사

Kerberos, 대칭-키 암호화 사용[3] 사용자를 네트워크 서비스에 인증하기 위해 암호는 실제로 네트워크를 통해 전송되지 않습니다.
결과적으로 사용자가 Kerberos를 사용하여 네트워크 서비스를 인증하면 네트워크 트래픽을 모니터링하여 암호 수집을 시도하지 않는 무단 사용자가 효과적으로 무시됩니다.

11.1.1. Kerberos 작동 방식의 기본 사항
링크 복사

대부분의 일반적인 네트워크 서비스는 사용자가 지정된 네트워크 서버에 액세스할 수 있는 암호를 제공하는 암호 기반 인증 체계를 사용합니다. 그러나 많은 서비스에 대한 인증 정보 전송은 암호화되지 않습니다. 이러한 체계를 안전하게 보호하려면 외부 사용자가 네트워크에 액세스할 수 없어야 하며 네트워크의 모든 컴퓨터와 사용자는 신뢰할 수 있어야 합니다.
단순한 암호 기반 인증을 통해 인터넷에 연결된 네트워크는 안전한 것으로 간주할 수 없습니다. 네트워크에 액세스하도록 하는 공격자는 단순한 패킷 분석기 또는 패킷 스니퍼 를 사용하여 사용자 이름과 암호를 가로채고 사용자 계정을 손상시켜 전체 보안 인프라의 무결성을 훼손할 수 있습니다.
Kerberos는 네트워크에서 암호화되지 않은 암호 전송을 제거하고 공격자가 네트워크를 스니핑하는 위협을 제거합니다.
Kerberos는 각 사용자를 각 네트워크 서비스에 대한 간단한 암호 인증과 다르게 인증하는 대신, 사용자를 네트워크 서비스 제품군에 인증하기 위해 대칭 암호화와 신뢰할 수 있는 타사( 핵심 배포 센터 또는 KDC)를 사용합니다. KDC와 보조 KDC가 관리하는 컴퓨터는 영역을 구성합니다.
사용자가 KDC에 인증하면 KDC는 해당 세션에 해당하는 일련의 자격 증명( 티켓)을 사용자 시스템으로 다시 보내고 Kerberos 인식 서비스는 사용자가 암호를 사용하여 인증할 필요 없이 사용자 시스템에서 티켓을 찾습니다.
그림 11.1. “Kerberos 인증” 에 표시된 대로 각 사용자는 보안 주체 라는 고유한 ID를 사용하여 KDC로 식별됩니다. Kerberos 인식 네트워크 사용자가 워크스테이션에 로그인하면 해당 주체가 인증 서버에서 티켓 제공 티켓 (또는 TGT) 요청의 일부로 KDC로 전송됩니다. 로그인 프로그램에서 이 요청을 전송하여 사용자에게 투명하거나 사용자가 로그인한 후 kinit 프로그램을 통해 수동으로 보낼 수 있습니다.
그런 다음 KDC는 해당 데이터베이스의 주체를 확인합니다. 주체가 발견되면 KDC는 TGT를 생성하고 사용자 키를 사용하여 암호화하며 TGT를 해당 사용자에게 전송합니다.

그림 11.1. Kerberos 인증

Kerberos 인증
View larger image
Kerberos 인증
클라이언트의 login 또는 kinit 프로그램은 사용자의 암호에서 계산하는 사용자의 키를 사용하여 TGT의 암호를 해독합니다. 사용자의 키는 클라이언트 시스템에서만 사용되며 네트워크를 통해 전송되지 않습니다. KDC에서 전송한 티켓(또는 자격 증명)은 Kerberos 인식 서비스에서 확인할 수 있는 인증 정보 캐시(ccache) 인 로컬 저장소에 저장됩니다. Red Hat Enterprise Linux 7은 다음과 같은 유형의 인증 정보 캐시를 지원합니다.
  • 영구 KEYRING ccache 유형, Red Hat Enterprise Linux 7의 기본 캐시
  • Red Hat Enterprise Linux 7.4 이후의 대안 옵션인 KCM(System Security Services Daemon) KCM
  • 파일
  • DIR
  • 메모리
SSSD KCM을 사용하면 Kerberos 캐시가 패시브 저장소에 저장되지 않고 데몬에서 관리합니다. 이 설정에서 kinit 와 같은 애플리케이션에서 일반적으로 사용하는 Kerberos 라이브러리는 KCM 클라이언트이며 데몬을 KCM 서버라고 합니다.
SSSD KCM 데몬에서 Kerberos 인증 정보 캐시를 관리하면 다음과 같은 몇 가지 이점이 있습니다.
  • 데몬은 상태를 저장하므로 Kerberos 자격 증명 캐시 갱신 또는 이전 ccache 가져오기와 같은 작업을 수행할 수 있습니다. 갱신 및 추적은 SSSD 자체에서 얻은 티켓뿐만 아니라 pam_sss.so 를 통해 로그인을 통해 얻을 수 있을 뿐만 아니라 kinit 와 같이 얻은 티켓에도 사용할 수 있습니다.
  • 프로세스가 사용자 공간에서 실행되므로 커널 KEYRING과 달리 UID 이름 붙여넣기가 적용됩니다.
  • 호출자의 UID와 컨테이너화된 환경에서는 모든 컨테이너에서 공유되는 커널 KEYRING 기반 캐시와 달리 KCM 서버의 진입점은 선택한 컨테이너에만 바인딩 마운트할 수 있는 UNIX 소켓입니다.
인증 후 서버는 kinit 를 확인하는 대신 암호화되지 않은 보안 주체 및 키 목록을 확인할 수 있습니다. 이 목록은 키탭 에 유지됩니다.
TGT는 특정 기간(일반적으로 10 ~ 24시간) 후에 만료되도록 설정되며 클라이언트 시스템의 인증 정보 캐시에 저장됩니다. 손상된 TGT가 짧은 기간 동안 공격자가 사용할 수 있도록 만료 시간이 설정됩니다. TGT가 발행되면 사용자는 TGT가 만료되거나 로그아웃한 후 다시 로그인할 때까지 암호를 다시 입력할 필요가 없습니다.
사용자가 네트워크 서비스에 액세스해야 할 때마다 클라이언트 소프트웨어는 TGT를 사용하여 티켓 제공 서버(TGS)에서 해당 특정 서비스에 대한 새 티켓을 요청합니다. 그런 다음 서비스 티켓은 사용자를 해당 서비스에 투명하게 인증하는 데 사용됩니다.

11.1.2. Kerberos 주체 이름 정보
링크 복사

주체는 사용자 또는 서비스뿐만 아니라 엔터티가 속하는 영역도 식별합니다. 주요 이름에는 식별자와 영역이라는 두 부분이 있습니다. 
identifier@REALM
Copy to Clipboard Toggle word wrap
사용자의 경우 식별자는 Kerberos 사용자 이름일 뿐입니다. 서비스의 경우 식별자는 서비스 이름과 서비스가 실행되는 시스템의 호스트 이름의 조합입니다. 
service/FQDN@REALM
Copy to Clipboard Toggle word wrap
서비스 이름은 호스트,ldap,http 및 DNS 와 같은 서비스 유형에 고유한 대소문자를 구분하는 문자열입니다. 모든 서비스에 고유 고유 식별자가 있는 것은 아닙니다. 예를 들어 sshd 데몬은 호스트 서비스 주체를 사용합니다.
호스트 주체는 일반적으로 /etc/krb5.keytab 에 저장됩니다.
Kerberos에서 티켓을 요청하면 항상 도메인 이름 별칭(DNS CNAME 레코드)을 해당 DNS 주소(A 또는 AAAA 레코드)로 확인합니다. 그러면 서비스 또는 호스트 주체가 생성될 때 주소 레코드의 호스트 이름이 사용됩니다.
예를 들어 다음과 같습니다. 
www.example.com		CNAME		web-01.example.com
web-01.example.com		A		192.0.2.145
Copy to Clipboard Toggle word wrap
서비스는 CNAME 별칭을 사용하여 호스트에 연결을 시도합니다. 
$ ssh www.example.com
Copy to Clipboard Toggle word wrap
Kerberos 서버는 확인된 호스트 이름 web-01.example.com@EXAMPLE.COM 에 대한 티켓을 요청하므로 호스트 주체는 host/web-01.example.com@EXAMPLE.COM 여야 합니다.

11.1.3. Domain-to-Realm Mapping 정보
링크 복사

클라이언트가 특정 서버에서 실행 중인 서비스에 액세스하려고 하면 서비스 이름(호스트)과 서버 이름(foo.example.com)을 알고 있지만 두 개 이상의 영역이 네트워크에 배포할 수 있기 때문에 서비스가 상주하는 Kerberos 영역의 이름을 추측해야 합니다.
기본적으로 영역의 이름은 모든 대문자로 서버의 DNS 도메인 이름이 되도록 합니다. 
foo.example.org → EXAMPLE.ORG
foo.example.com → EXAMPLE.COM
foo.hq.example.com → HQ.EXAMPLE.COM
Copy to Clipboard Toggle word wrap
일부 구성에서는 이것으로 충분하지만, 다른 구성에서는 파생된 영역 이름이 존재하지 않는 영역의 이름이 됩니다. 이 경우 서버의 DNS 도메인 이름에서 영역 이름으로의 매핑은 클라이언트 시스템의 /etc/krb5.conf 파일의 domain_realm 섹션에 지정해야 합니다. 예를 들어 다음과 같습니다. 
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Copy to Clipboard Toggle word wrap
구성은 두 개의 매핑을 지정합니다. 첫 번째 매핑은 example.com DNS 도메인의 모든 시스템이 EXAMPLE.COM 영역에 속하도록 지정합니다. 두 번째는 이름이 example.com인 시스템도 영역에 있음을 지정합니다. 도메인과 특정 호스트 간의 차이점은 초기 기간 문자의 존재 여부 또는 부족으로 표시됩니다. 매핑은 "_kerberos TXT" 레코드를 사용하여 DNS에 직접 저장할 수도 있습니다. 예를 들면 다음과 같습니다. 
$ORIGIN example.com
_kerberos		TXT	"EXAMPLE.COM"
Copy to Clipboard Toggle word wrap

11.1.4. 환경 요구 사항
링크 복사

Kerberos는 시스템 이름을 확인할 수 있습니다. 따라서 작동 중인 DNS(Domain Name Service)가 필요합니다. 네트워크의 DNS 항목과 호스트 모두 /usr/share/doc/krb5-server-version-number 의 Kerberos 문서에서 다루는 올바르게 구성해야 합니다.
Kerberos 인증을 허용하는 애플리케이션에서는 시간 동기화가 필요합니다. ntpd 와 같은 서비스를 사용하여 네트워크의 시스템 간에 대략적인 클럭 동기화를 설정할 수 있습니다. ntpd 서비스에 대한 자세한 내용은 /usr/share/doc/ntp-version-number/html/index.html 또는 ntpd(8) 도움말 페이지를 참조하십시오.
참고
Red Hat Enterprise Linux 7을 실행하는 Kerberos 클라이언트는 KDC를 통한 자동 시간 조정을 지원하며 엄격한 타이밍 요구 사항이 없습니다. 이를 통해 Red Hat Enterprise Linux 7을 통해 IdM 클라이언트를 배포할 때 차이가 보다 클 수 있습니다.

11.1.5. Kerberos 배포를 위한 고려 사항
링크 복사

Kerberos는 일반 및 심각한 보안 위협을 제거하지만 다음과 같은 다양한 이유로 구현하기가 어렵습니다.
  • Kerberos는 각 사용자가 신뢰할 수 있지만 신뢰할 수 없는 네트워크에서 신뢰할 수 없는 호스트를 사용하고 있다고 가정합니다. 기본 목표는 암호화되지 않은 암호가 해당 네트워크에서 전송되지 않도록 하는 것입니다. 그러나 적절한 사용자 이외의 사용자가 인증에 사용되는 티켓을 발행하는 하나의 호스트에 액세스할 수 있는 경우, KDC - 전체 Kerberos 인증 시스템이 위험합니다.
  • 애플리케이션이 Kerberos 라이브러리를 사용하려면 해당 소스를 수정하여 Kerberos 라이브러리를 적절하게 호출해야 합니다. 이러한 방식으로 수정된 애플리케이션은 Kerberos 인식으로 간주됩니다. 일부 애플리케이션의 경우 애플리케이션 크기 또는 설계로 인해 문제가 될 수 있습니다. 호환되지 않는 다른 애플리케이션의 경우 서버와 클라이언트에서 통신하는 방식을 변경해야 합니다. 이 작업에도 광범위한 프로그래밍이 필요할 수 있습니다. 기본적으로 Kerberos 지원이 없는 클로즈드 소스 애플리케이션이 가장 문제가 되는 경우가 많습니다.
  • Kerberos로 네트워크를 보호하려면 암호화되지 않은 암호를 전송하는 모든 클라이언트 및 서버 애플리케이션의 Kerberos 인식 버전을 사용하거나 해당 클라이언트 및 서버 애플리케이션을 사용하지 않아야 합니다.
  • /etc/passwd 또는 /etc/shadow 와 같은 표준 UNIX 암호 데이터베이스에서 사용자 암호를 Kerberos 암호 데이터베이스로 마이그레이션하는 것은 번거로울 수 있습니다. 이 작업을 수행하는 자동화된 메커니즘은 없습니다. 마이그레이션 방법은 Kerberos를 배포하는 특정 방식에 따라 크게 달라질 수 있습니다. 따라서 ID 관리 기능을 사용하는 것이 좋습니다. 이 기능에는 특수화된 툴과 마이그레이션 방법이 있습니다.
주의
네트워크상의 사용자가 일반 텍스트로 암호를 전송하여 비Kerberos 인식 서비스에 대해 인증하면 Kerberos 시스템이 손상될 수 있습니다. 비Kerberos 인식 서비스(telnet 및 FTP 포함)는 권장되지 않습니다. SSH 또는 SSL 보안 서비스와 같은 기타 암호화된 프로토콜은 암호화되지 않은 서비스에 선호되지만, 여전히 이상적이지 않습니다.

11.1.6. Kerberos 추가 리소스
링크 복사

Kerberos는 배포 방법에 있어 많은 유연성을 통해 구현하는 복잡한 서비스일 수 있습니다. 표 11.1. “외부 Kerberos 문서” 및 표 11.2. “중요한 Kerberos man 페이지” 는 Kerberos 사용에 대한 자세한 정보를 위해 가장 중요한 소스 또는 가장 유용한 소스 중 몇 가지 목록입니다.
Expand
표 11.1. 외부 Kerberos 문서
문서 위치
Kerberos V5 설치 가이드 (PostScript와 HTML 모두) /usr/share/doc/krb5-server-version-number
Kerberos V5 시스템 관리자 가이드 (PostScript와 HTML 모두) /usr/share/doc/krb5-server-version-number
Kerberos V5 UNIX 사용자 가이드 (PostScript와 HTML 모두) /usr/share/doc/krb5-workstation-version-number
"Kerberos: MIT의 Network Authentication Protocol" 웹 페이지 http://web.mit.edu/kerberos/www/
인증 시스템 설계: 2004년에 Bill Bryant가 제작한 Scenes의 대화 상자. 2005년 Theodore Ts'o에 의해 수정됨. 이 문서는 Kerberos 스타일 인증 시스템을 만들 때 고려해야 하는 두 개발자 간의 대화입니다. 토론의 대화 스타일은 Kerberos에 익숙하지 않은 사람들에게 좋은 출발점입니다. http://web.mit.edu/kerberos/www/dialogue.html
Kerberos 인식 네트워크를 만들기 위한 기사. http://www.ornl.gov/~jar/HowToKerb.html
man command_name 을 실행하여 man page 파일을 열 수 있습니다.
Expand
표 11.2. 중요한 Kerberos man 페이지
manpage Description
클라이언트 애플리케이션
kerberos 자격 증명이 작동하는 방법을 설명하고 Kerberos 티켓을 가져오고 삭제하기 위한 권장 사항을 제공하는 Kerberos 시스템을 소개합니다. 도움말 페이지의 맨 아래에는 여러 관련 도움말 페이지를 참조합니다.
kinit 이 명령을 사용하여 티켓을 받고 캐시하는 방법을 설명합니다.
kdestroy 이 명령을 사용하여 Kerberos 자격 증명을 삭제하는 방법을 설명합니다.
klist 이 명령을 사용하여 캐시된 Kerberos 자격 증명을 나열하는 방법을 설명합니다.
관리 애플리케이션
kadmin 이 명령을 사용하여 Kerberos V5 데이터베이스를 관리하는 방법을 설명합니다.
kdb5_util 이 명령을 사용하여 Kerberos V5 데이터베이스에서 낮은 수준의 관리 기능을 생성하고 수행하는 방법을 설명합니다.
서버 애플리케이션
krb5kdc Kerberos V5 KDC에 사용 가능한 명령줄 옵션을 설명합니다.
kadmind Kerberos V5 관리 서버에 사용 가능한 명령줄 옵션을 설명합니다.
설정 파일
krb5.conf 는 Kerberos V5 라이브러리의 구성 파일 내에서 사용할 수 있는 형식 및 옵션을 설명합니다.
kdc.conf 는 Kerberos V5 AS 및 KDC의 구성 파일 내에서 사용 가능한 형식 및 옵션을 설명합니다.

11.2. Kerberos KDC 구성
링크 복사

먼저 마스터 KDC를 설치한 다음 마스터가 설정된 후 필요한 보조 서버를 설치합니다.
중요
Kerberos KDC를 수동으로 설정하는 것은 권장되지 않습니다. Red Hat Enterprise Linux 환경에 Kerberos를 도입하는 권장 방법은 ID 관리 기능을 사용하는 것입니다.

11.2.1. 마스터 KDC 서버 구성
링크 복사

중요
KDC 시스템은 전용 머신이어야 합니다. 이 시스템은 매우 안전해야 합니다. 가능한 경우 KDC 이외의 서비스를 실행해서는 안 됩니다.
  1. KDC에 필요한 패키지를 설치합니다. 
    [root@server ~]# yum install krb5-server krb5-libs krb5-workstation
    Copy to Clipboard Toggle word wrap
  2. 영역 이름 및 domain-to-realm 매핑을 반영하도록 /etc/krb5.conf 및 /var/kerberos/krb5kdc/kdc.conf 구성 파일을 편집합니다. 예를 들어 다음과 같습니다. 
    [logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 allow_weak_crypto = true

[realms]
  EXAMPLE.COM = {
  kdc = kdc.example.com.:88
  admin_server = kdc.example.com
  default_domain = example.com
 }

[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM
    Copy to Clipboard Toggle word wrap
    EXAMPLE.COM 및 example. com 의 인스턴스를 올바른 도메인 이름으로 교체하여 간단한 영역을 생성할 수 있습니다. 올바른 형식으로 대문자 및 소문자를 유지하고 KDC를 kerberos.example.com 에서 Kerberos 서버의 이름으로 변경하여 만들 수 있습니다. 관례적으로 모든 영역 이름은 대문자이며 모든 DNS 호스트 이름과 도메인 이름은 소문자가 됩니다. 이러한 구성 파일의 도움말 페이지에는 파일 형식에 대한 전체 세부 정보가 있습니다.
  3. kdb5_util 유틸리티를 사용하여 데이터베이스를 생성합니다. 
    [root@server ~]# kdb5_util create -s
    Copy to Clipboard Toggle word wrap
    create 명령은 Kerberos 영역의 키를 저장하는 데이터베이스를 생성합니다. -s 인수는 마스터 서버 키가 저장되는 stash 파일을 생성합니다. 키를 읽을 stash 파일이 없는 경우 Kerberos 서버(krb5kdc)는 시작할 때마다 마스터 서버 암호(키를 다시 생성하는 데 사용할 수 있음)를 묻는 메시지를 표시합니다.
  4. /var/kerberos/krb5kdc/kadm5.acl 파일을 편집합니다. 이 파일은 kadmind 에서 Kerberos 데이터베이스에 대한 관리 액세스 권한과 해당 액세스 수준을 결정하는 데 사용됩니다. 예를 들어 다음과 같습니다. 
    */admin@EXAMPLE.COM  *
    Copy to Clipboard Toggle word wrap
    대부분의 사용자는 데이터베이스에 단일 주체(예: joe@EXAMPLE.COM)가 NULL 또는 비어 있는 인스턴스로 표시됩니다 . 이 구성에서 admin 인스턴스(예: joe/admin@EXAMPLE.COM)가 있는 두 번째 주체가 있는 사용자는 영역의 Kerberos 데이터베이스에 대한 전체 관리 제어를 실행할 수 있습니다.
    서버에서 kadmind 를 시작한 후 모든 사용자는 영역의 모든 클라이언트 또는 서버에서 kadmin 을 실행하여 서비스에 액세스할 수 있습니다. 그러나 kadm5.acl 파일에 나열된 사용자만 고유한 암호를 변경하는 것을 제외하고 어떠한 방식으로든 데이터베이스를 수정할 수 있습니다.
    참고
    kadmin 유틸리티는 네트워크를 통해 kadmind 서버와 통신하며 Kerberos를 사용하여 인증을 처리합니다. 결과적으로 첫 번째 주체는 이미 네트워크를 통해 서버에 연결하여 관리해야 합니다. kadmin.local 명령을 사용하여 첫 번째 주체를 생성합니다. 이 명령은 특히 KDC와 동일한 호스트에서 사용하도록 설계되었으며 인증에 Kerberos를 사용하지 않습니다.
  5. KDC 터미널에서 kadmin.local 을 사용하여 첫 번째 주체를 생성합니다. 
    [root@server ~]# kadmin.local -q "addprinc username/admin"
    Copy to Clipboard Toggle word wrap
  6. 다음 명령을 사용하여 Kerberos를 시작합니다. 
    [root@server ~]# systemctl start krb5kdc.service
[root@server ~]# systemctl start kadmin.service
    Copy to Clipboard Toggle word wrap
  7. kadmin. kadmin 및 kadmin.local에서 addprinc 명령을 사용하여 사용자의 주체를 추가합니다. kadmin.local 은 KDC에 대한 명령줄 인터페이스입니다. 따라서 addprinc 와 같은 많은 명령을 kadmin 프로그램을 시작한 후 사용할 수 있습니다. 자세한 내용은 kadmin 도움말 페이지를 참조하십시오.
  8. KDC에서 티켓을 발행하고 있는지 확인합니다. 먼저 kinit 를 실행하여 티켓을 가져와서 인증 정보 캐시 파일에 저장합니다. 다음으로 klist 를 사용하여 캐시의 인증 정보 목록을 보고 kdestroy 를 사용하여 포함된 캐시 및 인증 정보를 삭제합니다.
    참고
    기본적으로 kinit 는 Kerberos 서버가 아닌 동일한 시스템 로그인 사용자 이름을 사용하여 인증을 시도합니다. 해당 사용자 이름이 Kerberos 데이터베이스의 주체에 해당하지 않으면 kinit 에서 오류 메시지를 발행합니다. 이 경우 명령줄에서 인수로 올바른 주체 이름을 kinit 에 제공합니다. 
    kinit principal
    Copy to Clipboard Toggle word wrap

11.2.2. 보조 KDC 설정
링크 복사

지정된 영역에 대한 KDC가 여러 개 있는 경우 하나의 KDC( 마스터 KDC)는 realm 데이터베이스의 쓰기 가능한 복사본을 유지하고 kadmind 를 실행합니다. 마스터 KDC는 영역의 관리 서버이기도 합니다. 추가 보조 KDC는 데이터베이스의 읽기 전용 복사본을 유지하고 kpropd 를 실행합니다.
마스터 및 슬레이브 전파 절차에서는 데이터베이스를 임시 덤프 파일로 덤프한 후 해당 파일을 각 슬레이브로 전송하여 이전에 수신한 읽기 전용 복사본을 덤프 파일 내용으로 덮어씁니다.
보조 KDC를 설정하려면 다음을 수행합니다.
  1. KDC에 필요한 패키지를 설치합니다. 
    [root@slavekdc ~]# yum install krb5-server krb5-libs krb5-workstation
    Copy to Clipboard Toggle word wrap
  2. 마스터 KDC의 krb5.conf 및 kdc.conf 파일을 보조 KDC에 복사합니다.
  3. 마스터 KDC의 루트 쉘에서 kadmin.local 을 시작합니다.
    1. kadmin.local add_principal 명령을 사용하여 master KDC의 호스트 서비스에 대한 새 항목을 생성합니다. 
      [root@masterkdc ~]# kadmin.local -r EXAMPLE.COM
 Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin: add_principal -randkey host/masterkdc.example.com
Principal "host/masterkdc.example.com@EXAMPLE.COM" created.
kadmin: ktadd host/masterkdc.example.com
Entry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
kadmin: quit
      Copy to Clipboard Toggle word wrap
    2. kadmin.local ktadd 명령을 사용하여 서비스의 임의의 키를 설정하고 임의의 키를 마스터의 기본 키탭 파일에 저장합니다.
      참고
      이 키는 kprop 명령에서 보조 서버를 인증하는 데 사용됩니다. 설치하는 보조 KDC 서버 수에 관계없이 한 번만 실행하면 됩니다.
  4. 보조 KDC의 루트 쉘에서 kadmin 을 시작합니다.
    1. kadmin.local add_principal 명령을 사용하여 보조 KDC의 호스트 서비스에 대한 새 항목을 생성합니다. 
      [root@slavekdc ~]# kadmin -p jsmith/admin@EXAMPLE.COM -r EXAMPLE.COM
Authenticating as principal jsmith/admin@EXAMPLE.COM with password.
Password for jsmith/admin@EXAMPLE.COM:
kadmin: add_principal -randkey host/slavekdc.example.com
Principal "host/slavekdc.example.com@EXAMPLE.COM" created.
kadmin: ktadd host/slavekdc.example.com@EXAMPLE.COM
Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
kadmin: quit
      Copy to Clipboard Toggle word wrap
    2. kadmin.local ktadd 명령을 사용하여 서비스의 임의의 키를 설정하고 보조 KDC 서버의 기본 키탭 파일에 임의의 키를 저장합니다. 이 키는 클라이언트를 인증할 때 kpropd 서비스에서 사용합니다.
  5. 서비스 키를 사용하면 보조 KDC에서 연결하려는 클라이언트를 인증할 수 있었습니다. 분명히 모든 잠재적인 클라이언트가 새 영역 데이터베이스를 kprop 서비스에 제공할 수 있어야 하는 것은 아닙니다. 액세스를 제한하기 위해 보조 KDC의 kprop 서비스는 사용자 이름이 /var/kerberos/krb5kdc/kpropd.acl 에 나열된 클라이언트의 업데이트만 허용합니다.
    마스터 KDC의 호스트 서비스 이름을 해당 파일에 추가합니다. 
    [root@slavekdc ~]# echo host/masterkdc.example.com@EXAMPLE.COM > /var/kerberos/krb5kdc/kpropd.acl
    Copy to Clipboard Toggle word wrap
  6. 보조 KDC에서 데이터베이스 복사본을 가져오면 이를 암호화하는 데 사용된 마스터 키도 필요합니다. KDC 데이터베이스의 마스터 키가 마스터 KDC의 stash 파일에 저장된 경우(일반적으로 /var/kerberos/krb5kdc/.k5.REALM라고도 함) 사용 가능한 보안 방법을 사용하여 보조 KDC에 복사하거나 kdb5_util create -s 를 실행하여 보조 KDC에 dummy 데이터베이스와 동일한 stash 파일을 생성합니다. 더미 데이터베이스는 첫 번째 성공적인 데이터베이스 전파로 덮어씁니다.
  7. 보조 KDC의 방화벽을 통해 마스터 KDC가 포트 754(krb5_prop)의 TCP를 사용하여 연결할 수 있는지 확인하고 kprop 서비스를 시작합니다.
  8. kadmin 서비스가 비활성화되어 있는지 확인합니다.
  9. kprop 명령이 읽을 기본 데이터 파일에 master KDC의 realm 데이터베이스를 덤프하여 수동 데이터베이스 전파 테스트를 수행합니다(/var/kerberos/krb5kdc/slave_datatrans). 
    [root@masterkdc ~]# kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans
    Copy to Clipboard Toggle word wrap
  10. kprop 명령을 사용하여 콘텐츠를 보조 KDC로 전송합니다. 
    [root@masterkdc ~]# kprop slavekdc.example.com
    Copy to Clipboard Toggle word wrap
  11. kinit 를 사용하여 클라이언트 시스템이 KDC에서 초기 자격 증명을 올바르게 가져올 수 있는지 확인합니다.
    클라이언트의 /etc/krb5.conf 는 KDC 목록에 있는 보조 KDC만 나열해야 합니다. 
    [realms]
  EXAMPLE.COM = {
  kdc = slavekdc.example.com.:88
  admin_server = kdc.example.com
  default_domain = example.com
 }
    Copy to Clipboard Toggle word wrap
  12. realm 데이터베이스를 덤프하고 kprop 명령을 실행하여 데이터베이스를 차례로 각 보조 KDC로 전송하는 스크립트를 생성하고 주기적으로 스크립트를 실행하도록 cron 서비스를 구성합니다.

11.2.3. Kerberos 키 배포 센터 프록시
링크 복사

일부 관리자는 배포에 액세스할 수 없는 기본 Kerberos 포트를 사용하도록 선택할 수 있습니다. 사용자, 호스트 및 서비스에서 Kerberos 자격 증명을 가져올 수 있도록 HTTPS 서비스를 HTTPS 포트 443을 통해 Kerberos와 통신하는 프록시로 사용할 수 있습니다.
IdM(Identity Management)에서 Kerberos KMS(Key Distribution Center Proxy )는 이 기능을 제공합니다.
KKDCP 서버
IdM 서버에서 KKDCP는 기본적으로 활성화되어 있습니다. 속성 및 값 쌍 ipaConfigString=kdcProxyEnabled 가 디렉터리에 있는 경우 Apache 웹 서버가 시작될 때마다 KKDCP가 자동으로 활성화됩니다. 이 경우 심볼릭 링크 /etc/httpd/conf.d/ipa-kdc-proxy.conf 가 생성됩니다. 따라서 심볼릭 링크가 있는지 확인하여 IdM 서버에서 KKDCP가 활성화되어 있는지 확인할 수 있습니다. 
$ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
lrwxrwxrwx. 1 root root 36 Aug 15 09:37 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf
Copy to Clipboard Toggle word wrap
자세한 내용은 아래 서버 구성 예제를 참조하십시오.

예 11.1. KKDCP 서버 구성 I

다음 예제 구성을 사용하면 여러 Kerberos 서버가 사용되는 IdM KKDCP와 Active Directory 영역 간의 전송 프로토콜로 TCP를 사용할 수 있습니다.
  1. /etc/ipa/kdcproxy/kdcproxy.conf 파일에서 [global] 섹션의 use_dns 매개변수를 false 로 설정합니다. 
    [global]
use_dns = false
    Copy to Clipboard Toggle word wrap
  2. 프록시된 영역 정보를 /etc/ipa/kdcproxy/kdcproxy.conf 파일에 넣습니다. 프록시가 있는 [AD.EXAMPLE.COM] 영역의 경우 다음과 같이 영역 구성 매개변수를 나열합니다. 
    [AD.EXAMPLE.COM]
kerberos = kerberos+tcp://1.2.3.4:88 kerberos+tcp://5.6.7.8:88
kpasswd = kpasswd+tcp://1.2.3.4:464 kpasswd+tcp://5.6.7.8:464
    Copy to Clipboard Toggle word wrap
    중요
    realm 구성 매개 변수는 특정 옵션을 여러 번 지정할 수 있는 /etc/krb5.conf 및 kdc.conf 와 달리 공백으로 구분된 여러 서버를 나열해야 합니다.
  3. IdM 서비스를 다시 시작하십시오. 
    # ipactl restart
    Copy to Clipboard Toggle word wrap

예 11.2. KKDCP 서버 II 구성

이 예제 서버 구성은 DNS 서비스 레코드를 사용하여 통신할 AD 서버를 찾습니다.
  1. /etc/ipa/kdcproxy/kdcproxy.conf 파일에서 [global] 섹션에서 use_dns 매개변수를 true 로 설정합니다. 
    [global]
configs = mit
use_dns = true
    Copy to Clipboard Toggle word wrap
    configs 매개변수를 사용하면 다른 구성 모듈을 로드할 수 있습니다. 이 경우 구성은 MIT libkrb5 라이브러리에서 읽습니다.
  2. 선택 사항: DNS 서비스 레코드를 사용하지 않으려면 명시적 AD 서버를 /etc/krb5.conf 파일의 [realms] 섹션에 추가합니다. 프록시가 있는 영역이 AD.EXAMPLE.COM 이면 다음을 추가합니다. 
    [realms]
AD.EXAMPLE.COM = {
    kdc = ad-server.ad.example.com
    kpasswd_server = ad-server.ad.example.com
}
    Copy to Clipboard Toggle word wrap
  3. IdM 서비스를 다시 시작하십시오. 
    # ipactl restart
    Copy to Clipboard Toggle word wrap
KKDCP Client
클라이언트 시스템은 /etc/krb5.conf 파일을 통해 KDC 프록시를 가리킵니다. AD 서버에 연결하려면 다음 절차를 따르십시오.
  1. 클라이언트에서 /etc/krb5.conf 파일을 열고 AD 영역의 이름을 [realms] 섹션에 추가합니다. 
    [realms]
AD.EXAMPLE.COM {
    kdc = https://ipa-server.example.com/KdcProxy
    kdc = https://ipa-server2.example.com/KdcProxy
    kpasswd_server = https://ipa-server.example.com/KdcProxy
    kpasswd_server = https://ipa-server2.example.com/KdcProxy
}
    Copy to Clipboard Toggle word wrap
  2. /etc/sssd/sssd.conf 파일을 열고 krb5_use_kdcinfo = False 행을 IdM 도메인 섹션에 추가합니다. 
    [domain/example.com]
krb5_use_kdcinfo = False
    Copy to Clipboard Toggle word wrap
  3. SSSD 서비스를 다시 시작하십시오. 
    # systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap
추가 리소스

11.3. Kerberos 클라이언트 구성
링크 복사

Kerberos 5 클라이언트를 설정하는 데 필요한 것은 클라이언트 패키지를 설치하고 각 클라이언트에 유효한 krb5.conf 구성 파일을 제공하는 것입니다. ssh 및 slogin 은 클라이언트 시스템에 원격으로 로그인하는 기본 방법이지만, 추가 구성 변경으로 rsh 및 rlogin 의 Kerberos 인식 버전을 계속 사용할 수 있습니다.
  1. 모든 클라이언트 시스템에 krb5-libs 및 krb5-workstation 패키지를 설치합니다. 
    [root@server ~]# yum install krb5-workstation krb5-libs
    Copy to Clipboard Toggle word wrap
  2. 각 클라이언트에 유효한 /etc/krb5.conf 파일을 제공합니다. 일반적으로 이는 Kerberos Distribution Center(KDC)에서 사용하는 것과 동일한 krb5.conf 파일일 수 있습니다. 예를 들어 다음과 같습니다. 
    [logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 allow_weak_crypto = true

[realms]
  EXAMPLE.COM = {
  kdc = kdc.example.com.:88
  admin_server = kdc.example.com
  default_domain = example.com
 }

[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM
    Copy to Clipboard Toggle word wrap
    일부 환경에서 KDC는 HTTPS KKDCP(Kerberos Key Distribution Center Proxy)를 사용해서만 액세스할 수 있습니다. 이 경우 다음과 같이 변경합니다.
    1. [realms] 섹션의 kdc 및 admin_server 옵션에 호스트 이름 대신 KKDCP의 URL을 할당합니다. 
      [realms]
EXAMPLE.COM = {
  kdc = https://kdc.example.com/KdcProxy
  admin_server = https://kdc.example.com/KdcProxy
  kpasswd_server = https://kdc.example.com/KdcProxy
  default_domain = example.com
}
      Copy to Clipboard Toggle word wrap
      중복을 위해 다양한 KKDCP 서버를 사용하여 kdc,admin _server 및 kpasswd_server 매개 변수를 여러 번 추가할 수 있습니다.
    2. IdM 클라이언트에서 sssd 서비스를 다시 시작하여 변경 사항을 적용합니다. 
      [root@server ~]# systemctl restart sssd
      Copy to Clipboard Toggle word wrap
  3. Kerberos 인식 rsh 및 rlogin 서비스를 사용하려면 rsh 패키지를 설치합니다.
  4. 워크스테이션에서 Kerberos를 사용하여 ssh,rsh 또는 rlogin 을 사용하여 연결하는 사용자를 인증하려면 먼저 Kerberos 데이터베이스에 자체 호스트 주체가 있어야 합니다. sshd,kshd, klogind 서버 프로그램은 모두 호스트 서비스 주체의 키에 액세스할 수 있어야 합니다.
    1. kadmin 을 사용하여 KDC에 워크스테이션에 대한 호스트 주체를 추가합니다. 이 경우 인스턴스는 워크스테이션의 호스트 이름입니다. kadmin 'saddprinc 명령에 -randkey 옵션을 사용하여 주체를 생성하고 임의의 키를 할당합니다. 
      addprinc -randkey host/server.example.com
      Copy to Clipboard Toggle word wrap
    2. ktadd 명령을 사용하여 워크스테이션 자체에 kadmin 을 실행하여 워크스테이션에 대해 키를 추출할 수 있습니다. 
      ktadd -k /etc/krb5.keytab host/server.example.com
      Copy to Clipboard Toggle word wrap
  5. 다른 Kerberos 인식 네트워크 서비스를 사용하려면 krb5-server 패키지를 설치하고 서비스를 시작합니다. Kerberos 인식 서비스는 표 11.3. “일반적인 Kerberos 인식 서비스” 에 나열됩니다.
Expand
표 11.3. 일반적인 Kerberos 인식 서비스
서비스 이름 사용 정보
ssh 클라이언트 및 서버 구성이 모두 GSSAPIAuthentication 이 활성화된 경우 OpenSSH는 GSS-API를 사용하여 서버에 사용자를 인증합니다. 클라이언트에 GSSAPIDelegateCredentials 도 활성화된 경우 원격 시스템에서 사용자의 자격 증명을 사용할 수 있습니다. OpenSSH에는 SFTP 서버에 FTP와 같은 인터페이스를 제공하고 GSS-API를 사용할 수 있는 sftp 도구도 포함되어 있습니다.
IMAP
cyrus-imap 패키지는 cyrus-sasl-gssapi 패키지도 설치된 경우 Kerberos 5를 사용합니다. cyrus-sasl-gssapi 패키지에는 GSS-API 인증을 지원하는 Cyrus SASL 플러그인이 포함되어 있습니다. cyrus 사용자가 /etc/krb5.keytab 에서 적절한 키를 찾을 수 있고 주체의 root가 imap ( kadmin)으로 설정된 경우 Cyrus Cryostat가 Kerberos로 제대로 작동합니다.
cyrus-imap 의 대안은 Red Hat Enterprise Linux에도 포함된 dovecot 패키지에서 찾을 수 있습니다. 이 패키지에는 IMAP 서버가 포함되어 있지만 지금까지는 GSS-API 및 Kerberos를 지원하지 않습니다.

11.4. 스마트 카드를 위한 Kerberos 클라이언트 설정
링크 복사

스마트 카드를 Kerberos와 함께 사용할 수 있지만 스마트 카드의 X.509(SSL) 사용자 인증서를 인식하려면 추가 구성이 필요합니다.
  1. 필요한 PKI/OpenSSL 패키지를 다른 클라이언트 패키지와 함께 설치합니다. 
    [root@server ~]# yum install krb5-pkinit
[root@server ~]# yum install krb5-workstation krb5-libs
    Copy to Clipboard Toggle word wrap
  2. /etc/krb5.conf 구성 파일을 편집하여 PKI(공개 키 인프라)의 매개 변수를 구성의 [realms] 섹션에 추가합니다. pkinit_anchors 매개변수는 CA 인증서 번들 파일의 위치를 설정합니다. 
    [realms]
  EXAMPLE.COM = {
    kdc = kdc.example.com.:88
    admin_server = kdc.example.com
    default_domain = example.com
    ...
    pkinit_anchors = FILE:/usr/local/example.com.crt
 }
    Copy to Clipboard Toggle word wrap
  3. 스마트 카드 인증(/etc/pam.d/smartcard-auth) 및 시스템 인증(/etc/pam.d/system-auth)에 대한 PKI 모듈 정보를 PAM 구성에 추가합니다. 두 파일에 모두 추가할 행은 다음과 같습니다. 
    auth    optional    pam_krb5.so use_first_pass no_subsequent_prompt preauth_options=X509_user_identity=PKCS11:/usr/lib64/pkcs11/opensc-pkcs11.so
    Copy to Clipboard Toggle word wrap
    OpenSC 모듈이 예상대로 작동하지 않는 경우, coldkey 패키지의 모듈을 사용합니다: /usr/lib64/pkcs11/lib coolkey pk11.so. 이 경우 Red Hat 기술 지원에 문의하거나 문제에 대한 Bugzilla 보고서를 작성하는 것이 좋습니다.

11.5. Cross-Realm Kerberos 트러스트 설정
링크 복사

Kerberos V5 영역은 연결된 모든 마스터 및 슬레이브의 Kerberos 데이터베이스에 정의된 Kerberos 사용자 집합입니다. 서로 통신하기 위해 다양한 영역의 주체가 서로 통신하려면 교차 영역 Kerberos 트러스트를 구성해야 합니다.
많은 Linux 환경과 혼합 환경은 이미 SSO(Single Sign-On), 애플리케이션 인증 및 사용자 관리를 위해 Kerberos 영역이 배포되어 있습니다. 이는 특히 Linux 환경이 ID 관리와 같은 구조화된 도메인 구성을 사용하지 않는 경우 Kerberos가 서로 다른 도메인 및 혼합 시스템(예: Windows 및 Linux) 환경에 대한 일반적인 통합 경로입니다.

11.5.1. 신뢰 관계
링크 복사

신뢰 는 한 영역 내의 사용자가 해당 영역에 속해 있는 것처럼 다른 도메인의 리소스에 액세스하도록 신뢰할 수 있음을 의미합니다. 이 작업은 두 도메인에서 공통으로 보유하는 단일 주체에 대해 공유 키를 만들어 수행됩니다.

그림 11.2. 기본 신뢰

기본 신뢰
View larger image
기본 신뢰
그림 11.2. “기본 신뢰” 에서 공유 주체는 도메인 B(krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM)에 속합니다. 해당 주체도 도메인 A에 추가되면 도메인 A의 클라이언트는 도메인 B의 리소스에 액세스할 수 있습니다. 구성된 주체는 두 영역에 모두 있습니다. 공유 주체는 다음 세 가지 특성을 갖습니다.
  • 두 영역에 모두 존재합니다.
  • 키가 생성되면 두 영역에서 동일한 암호가 사용됩니다.
  • 키의 키 버전 번호(kvno)가 같습니다.
교차 영역 신뢰는 기본적으로 단방향입니다. 이 신뢰는 자동으로 복구되지 않으므로 B.EXAMPLE.COM 영역이 A.EXAMPLE.COM 영역의 서비스에 인증할 수 있습니다. 다른 방향으로 신뢰를 설정하려면 두 영역 모두 krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM 서비스의 키를 공유해야 합니다. - 이전 예제의 역방향 매핑이 있는 항목입니다.
영역에는 여러 개의 신뢰가 있을 수 있으며, 두 영역 모두 신뢰하는 영역과 신뢰할 수 있는 영역입니다. Kerberos를 신뢰하면 체인으로 신뢰가 쌓을 수 있습니다. Realm A가 Realm B와 Realm B가 Realm C를 신뢰한다면 Realm A도 Realm C를 신뢰합니다. 신뢰는 영역을 따라가며, 이는 전이적인 신뢰입니다.

그림 11.3. 전향적인 신뢰

전향적인 신뢰
View larger image
전향적인 신뢰
전향적인 신뢰의 방향은 신뢰 흐름 입니다. 신뢰 흐름을 정의해야 합니다. 먼저 서비스가 속한 영역을 인식한 다음 클라이언트에서 해당 서비스에 액세스하기 위해 연결해야 하는 영역을 식별하여 정의해야 합니다.
Kerberos 주체 이름은 service/hostname@REALM 형식으로 구성됩니다. 서비스는 일반적으로 LDAP, IMAP, HTTP 또는 호스트와 같은 프로토콜입니다. 호스트 이름은 호스트 시스템의 정규화된 도메인 이름이며 REALM 은 속해 있는 Kerberos 영역입니다. Kerberos 클라이언트는 일반적으로 Kerberos 영역 매핑에 호스트 이름 또는 DNS 도메인 이름을 사용합니다. 이 매핑은 명시적이거나 암시적일 수 있습니다. 명시적 매핑은 /etc/krb5.conf 파일의 [domain_realm] 섹션을 사용합니다. 암시적 매핑을 사용하면 도메인 이름이 대문자로 변환됩니다. 그런 다음 변환된 이름은 검색할 Kerberos 영역으로 간주됩니다.
신뢰를 전달하는 경우 Kerberos는 각 영역이 루트 도메인 및 하위 도메인을 사용하는 계층형 DNS 도메인과 같이 구성되어 있다고 가정합니다. 즉, 신뢰는 공유 루트로 이동합니다. 각 단계 또는 홉 에는 공유 키가 있습니다. 그림 11.4. “동일한 도메인에서의 신뢰” 에서 SALES.EXAMPLE.COM은 EXAMPLE.COM과 키를 공유하며 EXAMPLE.COM은 EVERYWHERE.EXAMPLE.COM과 키를 공유합니다.

그림 11.4. 동일한 도메인에서의 신뢰

동일한 도메인에서의 신뢰
View larger image
동일한 도메인에서의 신뢰
클라이언트는 영역 이름을 DNS 이름으로 처리하고, 루트 이름에 도달할 때까지 자체 영역 이름의 요소를 제거하여 신뢰 경로를 결정합니다. 그런 다음 이름 앞에 붙은 이름이 서비스 영역에 도달할 때까지 시작됩니다.

그림 11.5. 동일한 도메인의 자식/기존 신뢰

동일한 도메인의 자식/기존 신뢰
View larger image
동일한 도메인의 자식/기존 신뢰
이는 전향적인 신뢰의 속성입니다. SITE.SALES.EXAMPLE.COM에는 SALES.EXAMPLE.COM이 포함된 하나의 공유 키만 있습니다. 하지만 일련의 신뢰감으로 인해 SITE.SALES.EXAMPLE.COM에서 EVERYWHERE.EXAMPLE.COM으로 신뢰가 가능합니다.
이 신뢰 흐름은 사이트에서 공통 접미사를 공유하지 않는 도메인 수준에서 공유 키를 만들어 완전히 다른 도메인 간에도 이동할 수 있습니다.

그림 11.6. 다른 도메인의 신뢰

다른 도메인의 신뢰
View larger image
다른 도메인의 신뢰
[capaths] 섹션
또한 흐름을 명시적으로 정의하여 홉 수를 줄이고 매우 복잡한 신뢰 흐름을 나타낼 수 있습니다. /etc/krb5.conf 파일의 [capaths] 섹션은 서로 다른 영역 간의 신뢰 흐름을 정의합니다.
[capaths] 섹션 형식은 비교적 간단합니다. 클라이언트에 주체가 있는 각 영역의 주요 항목이 있으며, 각 realm 섹션 내에는 클라이언트가 자격 증명을 받아야 하는 중간 영역 목록이 있습니다.
예를 들어 [capaths] 를 사용하여 인증 정보를 가져오기 위한 다음 프로세스를 지정할 수 있습니다.
  1. 클라이언트는 A의 인증 정보를 사용하여 클라이언트는 KDC A에서 krbtgt/A@A 티켓을 받습니다. 이 티켓을 사용하면 클라이언트는 krbtgt/B@A 티켓을 요청합니다.
    krbtgt/B@A 티켓은 KDC A 에서 발행한 티켓입니다. 이를 통해 고객은 Realm B의 서비스 주체에게 티켓을 요청하도록 Realm B의 KDC에 요청할 수 있습니다.
  2. krbtgt/B@A 티켓을 사용하면 클라이언트에서 krbtgt/C@B cross-realm 티켓을 요청합니다.
  3. krbtgt/C@B 티켓에서 krbtgt/C@B 티켓에서 발급한 상태에서 클라이언트는 krbtgt/D@C cross-realm 티켓을 요청합니다.
  4. krbtgt/D@C 티켓에서 발행한 krbtgt/D@C 티켓에서 client는 Cryostat D의 서비스 주체에 대한 티켓을 요청합니다.
이 후 인증 정보 캐시에는 krbtgt/A@A,krbtgt/B@A,krbtgt/C@B,krbtgt/D@C, service/hostname@D 에 대한 티켓이 포함되어 있습니다. 서비스/hostname@D 티켓을 얻으려면 3개의 중간 교차 실제 티켓을 받아야 했습니다.
[capaths] 구성 예제를 포함하여 [capaths] 섹션에 대한 자세한 내용은 krb5.conf(5) 도움말 페이지를 참조하십시오.

11.5.2. Realm Trust 설정
링크 복사

이 예제에서 Kerberos 영역은 A.EXAMPLE.COM 및 B.EXAMPLE.COM 입니다.
kadmin 을 사용하여 A 영역의 B 영역에 대한 공유 주체의 항목을 만듭니다. 
[root@server ~]# kadmin -r A.EXAMPLE.COM
kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM
Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created.
quit
Copy to Clipboard Toggle word wrap
즉, A 영역이 B 주체를 신뢰함을 의미합니다.
중요
교차 영역 주체에 대해 매우 강력한 암호를 선택하는 것이 좋습니다. 사용자가 하루에 여러 번 표시되는 다른 암호와 달리 시스템은 자주 교차 영역 주체에 대한 암호를 요청하지 않습니다. 따라서 기억하기 쉬운 것은 아닙니다.
양방향 신뢰성을 만든 후 그 반대 방향으로 원칙을 만드십시오. kadmin 을 사용하여 B 영역에서 A 영역에 대한 주체를 생성합니다. 
[root@server ~]# kadmin -r B.EXAMPLE.COM
kadmin: add_principal krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM
Enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM":
Re-enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM":
Principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM" created.
quit
Copy to Clipboard Toggle word wrap
get_principal 명령을 사용하여 두 항목이 모두 일치하는 키 버전 번호(kvno 값) 및 암호화 유형이 있는지 확인합니다.
중요
일반적이지만 잘못된 상황은 관리자가 add_principal 명령의 -randkey 옵션을 사용하여 암호 대신 임의의 키를 할당하고 첫 번째 영역의 데이터베이스에서 새 항목을 덤프한 다음 두 번째 항목으로 가져오는 것입니다. 데이터베이스 덤프에 포함된 키가 master 키를 사용하여 암호화되므로 영역 데이터베이스의 마스터 키가 동일하지 않는 한 이 작업은 작동하지 않습니다.

[3] 클라이언트와 서버가 네트워크 통신을 암호화하고 암호 해독하는 데 사용되는 공통 키를 공유하는 시스템입니다.

12장. certmonger 작업
링크 복사

시스템 인증을 관리하는 일부는 시스템 인증서를 관리하는 것입니다. certmonger 서비스는 애플리케이션의 인증서 라이프사이클을 관리하고, 올바르게 구성된 경우 CA(인증 기관)와 함께 작동하여 인증서를 갱신할 수 있습니다.
certmonger 데몬과 해당 명령줄 클라이언트는 공개/개인 키 쌍을 생성하고 인증서 요청을 생성하고 서명을 위해 CA에 요청을 제출하는 프로세스를 단순화합니다. certmonger 데몬은 인증서 만료를 모니터링하고 만료될 인증서를 갱신할 수 있습니다. certmonger 가 모니터링하는 인증서는 구성 가능한 디렉터리에 저장된 파일에서 추적됩니다. 기본 위치는 /var/lib/certmonger/requests 입니다.
참고
certmonger 데몬은 인증서를 취소할 수 없습니다. 인증서는 인증서를 무효화하고 인증서 해지 목록을 업데이트해야 하는 관련 인증 기관에서만 취소할 수 있습니다.

12.1. certmonger 및 인증 기관
링크 복사

기본적으로 certmonger 는 인증서에서 사용하는 권한 소스와 다른 세 가지 종류의 인증서를 자동으로 가져올 수 있습니다.
  • 자체 서명 인증서
    각 인증서는 인증서의 자체 키를 사용하여 서명되므로 자체 서명 인증서를 생성하는 데 CA가 포함되지 않습니다. 자체 서명된 인증서를 확인하는 소프트웨어는 인증서를 직접 신뢰하도록 지시해야 합니다.
    자체 서명된 인증서를 얻으려면 selfsign-getcert 명령을 실행합니다.
  • Red Hat Enterprise Linux IdM의 일부로 Dogtag 인증서 시스템 CA의 인증서
    IdM 서버를 사용하여 인증서를 가져오려면 ipa-getcert 명령을 실행합니다.
  • 시스템에 로컬 CA가 서명한 인증서
    로컬 서명자가 서명한 인증서를 확인하는 소프트웨어는 이 로컬 서명자의 인증서를 신뢰하도록 지시해야 합니다.
    로컬로 서명된 인증서를 얻으려면 local-getcert 명령을 실행합니다.
다른 CA는 인증서 관리를 위해 certmonger 를 사용할 수도 있지만 특수 CA 도우미 를 생성하여 certmonger 에 지원을 추가해야 합니다. CA 도우미를 생성하는 방법에 대한 자세한 내용은 에서 certmonger 프로젝트 설명서를 참조하십시오 https://pagure.io/certmonger/blob/master/f/doc/submit.txt.

12.2. certmonger를 사용하여 자체 서명 인증서 요청
링크 복사

certmonger 를 사용하여 인증서를 요청하려면 getcert 요청 유틸리티를 사용합니다.
인증서 및 키는 .pem 확장 또는 NSS 데이터베이스를 사용하여 일반 텍스트 파일에 로컬로 저장되며 인증서 닉네임으로 식별됩니다. 인증서를 요청할 때 요청은 인증서가 저장되는 위치와 인증서의 컬렉터를 식별해야 합니다. 예를 들어 다음과 같습니다. 
[root@server ~]# selfsign-getcert request -d /etc/pki/nssdb -n Server-Cert
Copy to Clipboard Toggle word wrap
/etc/pki/nssdb 파일은 글로벌 NSS 데이터베이스이며 Server-Cert 는 이 인증서의 닉네임입니다. 인증서는 이 데이터베이스 내에서 고유해야 합니다.
인증서를 생성하기 위해 명령을 제공할 수 있는 옵션은 요청하는 인증서 유형 및 최종 인증서에 필요한 구성 및 기타 설정에 따라 달라집니다.
  • -R은 키 쌍이 이미 있는 경우 만료 날짜가 닫히면 자동으로 인증서를 갱신합니다. 이 옵션은 기본적으로 사용됩니다.
  • -f 는 지정된 파일에 인증서를 저장합니다.
  • -k 지정된 파일에 키를 저장하거나 키 파일이 이미 있는 경우 파일에서 키를 사용합니다.
  • -k는 인증서를 사용할 서비스의 Kerberos 주체 이름을 제공합니다. -K 는 IdM 서버에서 인증서를 요청할 때 필요하며 자체 서명 또는 로컬 서명 인증서를 요청할 때 선택 사항입니다.
  • -n은 주체 이름을 지정합니다.
  • - d는 인증서에 subjectAltName 값으로 포함할 DNS 도메인 이름을 요청합니다.
  • -u는 확장된 키 사용 플래그를 설정합니다.
  • - a는 인증서에 subjectAltName 값으로 포함될 IP 주소를 요청합니다.
  • -I 는 작업의 이름을 설정합니다. certmonger 는 이 이름을 사용하여 스토리지 위치 및 요청 옵션의 조합을 참조하며 getcert list 명령의 출력에도 표시됩니다. 이 옵션을 지정하지 않으면 certmonger 에서 작업에 자동으로 생성된 이름을 할당합니다.
IdM과 같은 실제 CA는 CA 자체 정책에 따라 -K, -N, - D, - U 및 - A 옵션을 사용하여 서명 요청에 지정한 모든 항목을 무시할 수 있습니다. 예를 들어 IdM에서는 -K 및 -N 이 로컬 호스트 이름에 동의해야 합니다. 반면 selfsign-getcert 및 local-getcert 명령을 사용하여 생성된 인증서는 이러한 명령이 정책을 적용하지 않기 때문에 지정하는 옵션에 동의합니다.

예 12.1. 서비스에 certmonger 사용

[root@server ~]# selfsign-getcert request -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key -N CN=`hostname --fqdn` -D `hostname` -U id-kp-serverAuth
Copy to Clipboard Toggle word wrap

12.3. SCEP를 통해 CA 서명 인증서 요청
링크 복사

SCEP(Simple Certificate Enrollment Protocol)는 CA를 사용하여 인증서 관리 프로세스를 자동화하고 단순화합니다. 클라이언트가 CA의 SCEP 서비스에서 직접 HTTP를 통해 인증서를 요청하고 검색할 수 있습니다. 이 프로세스는 일회성 PIN으로 보호되며 일반적으로 제한된 시간 동안만 유효합니다.
다음 예제에서는 certmonger 에 SCEP CA 구성을 추가하고 새 인증서를 요청하고 로컬 NSS 데이터베이스에 추가합니다.
  1. certmonger 에 CA 구성을 추가합니다. 
    [root@server ~]# getcert add-scep-ca -c CA_Name -u SCEP_URL
    Copy to Clipboard Toggle word wrap
    • -c: CA 구성에 대한 필수 닉네임입니다. 나중에 동일한 값을 다른 getcert 명령에 전달할 수 있습니다.
    • -u: 서버의 SCEP 인터페이스 URL입니다.
    • HTTPS URL을 사용하는 경우 필수 매개변수:
      -r CA_Filename: HTTPS 암호화에 사용되는 SCEP 서버 CA 인증서의 PEM 형식 사본의 위치입니다.
  2. CA 구성이 성공적으로 추가되었는지 확인합니다. 
    [root@server ~]# getcert list-cas -c CA_Name
CA 'CA_Name':
       is-default: no
       ca-type: EXTERNAL
       helper-location: /usr/libexec/certmonger/scep-submit -u http://SCEP_server_enrollment_interface_URL
       SCEP CA certificate thumbprint (MD5): A67C2D4B 771AC186 FCCA654A 5E55AAF7
       SCEP CA certificate thumbprint (SHA1): FBFF096C 6455E8E9 BD55F4A5 5787C43F 1F512279
    Copy to Clipboard Toggle word wrap
    SCEP에서 CA 인증서 지문을 검색하고 명령 출력에 표시할 때 CA 구성이 성공적으로 추가되었습니다. 암호화되지 않은 HTTP를 통해 서버에 액세스하는 경우 수동으로 SCEP 서버에 표시되는 지문과 지문을 비교하여 중간자 공격을 방지합니다.
  3. CA에서 인증서를 요청합니다. 
    [root@server ~]# getcert request -I Task_Name -c CA_Name -d /etc/pki/nssdb -n Certificate_Name -N cn="Subject Name" -L one-time_PIN
    Copy to Clipboard Toggle word wrap
    • -I: 작업 이름입니다. 나중에 동일한 값을 getcert list 명령에 전달할 수 있습니다.
    • -c: 요청을 제출할 CA 구성입니다.
    • -d: 인증서와 키를 저장할 NSS 데이터베이스가 있는 디렉터리입니다.
    • -n: NSS 데이터베이스에 사용된 인증서의 리포지토리입니다.
    • -N: CSR의 주체 이름입니다.
    • -L: CA에서 발행한 시간 제한 일회성 PIN.
  4. 요청을 제출한 직후 인증서가 실행되고 로컬 데이터베이스에 올바르게 저장되었는지 확인할 수 있습니다. 
    [root@server ~]# getcert list -I TaskName
	Request ID 'Task_Name':
        status: MONITORING
        stuck: no
        key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB'
        certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB'
        signing request thumbprint (MD5): 503A8EDD DE2BE17E 5BAA3A57 D68C9C1B
        signing request thumbprint (SHA1): B411ECE4 D45B883A 75A6F14D 7E3037F1 D53625F4
        CA: AD-Name
        issuer: CN=windows-CA,DC=ad,DC=example,DC=com
        subject: CN=Test Certificate
        expires: 2018-05-06 10:28:06 UTC
        key usage: digitalSignature,keyEncipherment
        eku: iso.org.dod.internet.security.mechanisms.8.2.2
        certificate template/profile: IPSECIntermediateOffline
        pre-save command:
        post-save command:
        track: yes
	auto-renew: yes
    Copy to Clipboard Toggle word wrap
    상태 MONITORING 은 발급한 인증서를 성공적으로 검색하는 것을 나타냅니다. getcert-list(1) 도움말 페이지에는 다른 가능한 상태 및 해당 의미가 나열됩니다.

12.4. NSS 데이터베이스에 인증서 저장
링크 복사

기본적으로 certmonger 는 .pem 파일을 사용하여 키와 인증서를 저장합니다. 키와 인증서를 NSS 데이터베이스에 저장하려면 인증서를 요청하는 데 사용하는 명령으로 -d 및 -n 을 지정합니다.
  • -d 보안 데이터베이스 위치 설정
  • -N NSS 데이터베이스의 인증서에 사용되는 인증서 컬렉터를 제공합니다.
참고
d 및 -n 옵션은 .pem 파일을 제공하는 -f 및 -k 옵션 대신 사용됩니다.
예를 들어 다음과 같습니다. 
[root@server ~]# selfsign-getcert request -d /export/alias -n ServerCert ...
Copy to Clipboard Toggle word wrap
ipa-getcert 및 local-getcert 를 사용하여 인증서를 요청하면 다른 두 옵션을 지정할 수 있습니다.
  • -f는 CA 인증서를 저장할 파일을 제공합니다.
  • -a 는 CA 인증서를 저장할 NSS 데이터베이스의 위치를 제공합니다.
참고
selfsign-getcert 를 사용하여 인증서를 요청하는 경우 자체 서명된 인증서를 생성해도 CA가 포함되어 있지 않기 때문에 -F 및 -a 옵션을 지정할 필요가 없습니다.
-F 옵션, -a 옵션 또는 local-getcert 둘 다 제공하면 로컬 서명자가 발급한 인증서를 확인하는 데 필요한 CA 인증서 사본을 가져올 수 있습니다. 예를 들어 다음과 같습니다. 
[root@server ~]# local-getcert request -F /etc/httpd/conf/ssl.crt/ca.crt -n ServerCert -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key
Copy to Clipboard Toggle word wrap

12.5. certmonger를 사용하여 인증서 추적
링크 복사

certmonger 는 인증서의 만료 날짜를 모니터링하고 유효 기간이 끝나면 자동으로 인증서를 갱신할 수 있습니다. 이러한 방식으로 인증서를 추적하려면 getcert start-tracking 명령을 실행합니다.
참고
getcert 요청 명령을 기본적으로 추적하여 요청된 인증서를 자동으로 추적하므로 getcert 시작 추적을 실행할 필요는 없습니다. getcert start-tracking 명령은 다른 프로세스를 통해 키와 인증서를 이미 가져온 경우 사용하기 위한 것이므로 certmonger 에 추적을 시작하도록 수동으로 지시해야 합니다.
getcert start-tracking 명령에는 다음과 같은 몇 가지 옵션이 있습니다.
  • -R은 키 쌍이 이미 있는 경우 만료 날짜가 닫히면 자동으로 인증서를 갱신합니다. 이 옵션은 기본적으로 사용됩니다.
  • -I 추적 요청의 이름을 설정합니다. certmonger 는 이 이름을 사용하여 스토리지 위치 및 요청 옵션의 조합을 참조하며 getcert list 명령의 출력에도 표시됩니다. 이 옵션을 지정하지 않으면 certmonger 에서 자동으로 생성된 작업 이름을 할당합니다. 
[root@server ~]# getcert start-tracking -I cert1-tracker -d /export/alias -n ServerCert
Copy to Clipboard Toggle word wrap
인증서 추적을 취소하려면 stop-tracking 명령을 실행합니다.

13장. Single Sign-On에 대한 애플리케이션 구성
링크 복사

브라우저 및 이메일 클라이언트와 같은 일부 일반적인 애플리케이션은 Kerberos 티켓, SSL 인증 또는 토큰을 사용자를 인증하는 수단으로 사용하도록 구성할 수 있습니다.
모든 애플리케이션을 구성하는 정확한 절차는 해당 애플리케이션 자체에 따라 다릅니다. 이 장의 예제(Mozilla Thunder¢ 및 Mozilla Firefox)는 Kerberos 또는 기타 자격 증명을 사용하도록 사용자 애플리케이션을 구성하는 방법에 대한 개념을 제공하기 위한 것입니다.

13.1. Single Sign-On에 Kerberos를 사용하도록 Firefox 구성
링크 복사

Firefox는 SSO(Single Sign-On)에 Kerberos를 사용하여 인트라넷 사이트 및 기타 보호되는 웹 사이트에 사용할 수 있습니다. Firefox에서 Kerberos를 사용하려면 먼저 적절한 KDC에 Kerberos 자격 증명을 보내도록 구성해야 합니다.
Firefox에서 Kerberos 자격 증명을 전달하도록 구성한 후에도 여전히 유효한 Kerberos 티켓이 필요합니다. Kerberos 티켓을 생성하려면 kinit 명령을 사용하고 KDC에서 사용자의 사용자 암호를 제공합니다. 
[jsmith@host ~] $ kinit
Password for jsmith@EXAMPLE.COM:
Copy to Clipboard Toggle word wrap
SSO에 Kerberos를 사용하도록 Firefox를 구성하려면 다음을 수행합니다.
  1. Firefox의 주소 표시줄에 about:config 를 입력하여 현재 구성 옵션 목록을 표시합니다.
  2. 필터 필드에 negotiate 를 입력하여 옵션 목록을 제한합니다.
  3. network.negotiate-auth.trusted-uris 항목을 두 번 클릭합니다.
  4. 이전 기간(.)을 포함하여 인증할 도메인 이름을 입력합니다. 여러 도메인을 추가하려면 쉼표로 구분된 목록에 입력합니다.

    그림 13.1. Firefox 수동 설정

    Firefox 수동 설정
    View larger image
    Firefox 수동 설정
중요
Firefox 구성 옵션에서 network.negotiate-auth.delegation-uris 항목을 사용하여 위임을 구성하지 않는 것이 좋습니다. 이렇게 하면 모든 Kerberos 인식 서버가 사용자로 작동할 수 있기 때문입니다.
참고
자세한 내용은 Linux 도메인 ID, 인증 및 정책 가이드에서 Kerberos 인증용 브라우저 구성을 참조하십시오.

13.2. Firefox의 인증서 관리
링크 복사

Firefox에서 인증서를 관리하려면 인증서 관리자를 엽니다.
  1. Mozilla Firefox에서 Firefox 메뉴를 열고 기본 설정을 클릭합니다.

    그림 13.2. Firefox 환경 설정

    Firefox 환경 설정
    View larger image
    Firefox 환경 설정
  2. 고급 섹션을 열고 인증서 탭을 선택합니다.

    그림 13.3. Firefox의 인증서 탭

    Firefox의 인증서 탭
    View larger image
    Firefox의 인증서 탭
  3. 인증서 보기를 클릭하여 인증서 관리자를 엽니다.
CA 인증서를 가져오려면 다음을 수행합니다.
  1. CA 인증서를 다운로드하여 컴퓨터에 저장합니다.
  2. Certificate Manager 에서 Authorities 탭을 선택하고 Import 를 클릭합니다.

    그림 13.4. Firefox에서 CA 인증서 가져오기

    Firefox에서 CA 인증서 가져오기
    View larger image
    Firefox에서 CA 인증서 가져오기
  3. 다운로드한 CA 인증서를 선택합니다.
인증서 신뢰 관계를 설정하려면 다음을 수행합니다.
  1. Certificate Manager 의 Authorities 탭에서 적절한 인증서를 선택하고 Edit Trust 를 클릭합니다.
  2. 인증서 신뢰 설정을 편집합니다.

    그림 13.5. Firefox에서 인증서 신뢰 설정 편집

    Firefox에서 인증서 신뢰 설정 편집
    View larger image
    Firefox에서 인증서 신뢰 설정 편집
인증에 개인 인증서를 사용하려면 다음을 수행합니다.
  1. 인증서 관리자 의 인증서 탭에서 가져오기 를 클릭합니다.

    그림 13.6. Firefox에서 개인 인증 인증서 가져오기

    Firefox에서 개인 인증 인증서 가져오기
    View larger image
    Firefox에서 개인 인증 인증서 가져오기
  2. 컴퓨터에서 필요한 인증서를 선택합니다.

13.3. 이메일 클라이언트의 인증서 관리
링크 복사

다음 예제에서는 Mozilla Thunder¢ 이메일 클라이언트에서 인증서를 관리하는 방법을 보여줍니다. 일반적으로 이메일 클라이언트에 인증서를 설정하는 절차를 나타냅니다.
  1. Mozilla Thunderbird에서 Thunderbird 메인 메뉴를 열고 환경 설정 → 계정 설정을 선택합니다.
  2. 보안 항목을 선택하고 인증서 보기를 클릭하여 인증서 관리자를 엽니다.

    그림 13.7. Thunder bootstrap의 계정 설정

    Thunder bootstrap의 계정 설정
    View larger image
    Thunder bootstrap의 계정 설정
CA 인증서를 가져오려면 다음을 수행합니다.
  1. CA 인증서를 다운로드하여 컴퓨터에 저장합니다.
  2. Certificate Manager 에서 Authorities 탭을 선택하고 Import 를 클릭합니다.

    그림 13.8. Thunder에서 CA 인증서 가져오기

    Thunder에서 CA 인증서 가져오기
    View larger image
    Thunder에서 CA 인증서 가져오기
  3. 다운로드한 CA 인증서를 선택합니다.
인증서 신뢰 관계를 설정하려면 다음을 수행합니다.
  1. Certificate Manager 의 Authorities 탭에서 적절한 인증서를 선택하고 Edit Trust 를 클릭합니다.
  2. 인증서 신뢰 설정을 편집합니다.

    그림 13.9. Thunder에서 인증서 신뢰 설정 편집

    Thunder에서 인증서 신뢰 설정 편집
    View larger image
    Thunder에서 인증서 신뢰 설정 편집
인증에 개인 인증서를 사용하려면 다음을 수행합니다.
  1. 인증서 관리자 의 인증서 탭에서 가져오기 를 클릭합니다.

    그림 13.10. Thunder에서 개인 인증 인증서 가져오기

    Thunder에서 개인 인증 인증서 가져오기
    View larger image
    Thunder에서 개인 인증 인증서 가져오기
  2. 컴퓨터에서 필요한 인증서를 선택합니다.
  3. 인증서 관리자를 닫고 계정 설정 의 보안 항목으로 돌아갑니다.
  4. 양식의 디지털 서명 섹션에서 선택 을 클릭하여 메시지에 서명하는 데 사용할 개인 인증서를 선택합니다.
  5. 암호화 에서 Select 를 클릭하여 메시지를 암호화하고 해독할 개인 인증서를 선택합니다.

부록 A. 문제 해결
링크 복사

A.1. SSSD 문제 해결
링크 복사

A.1.1. SSSD 도메인의 디버그 로그 설정
링크 복사

각 도메인은 디버그 로그 수준을 설정합니다. 로그 수준을 늘리면 SSSD 또는 도메인 구성과 관련된 문제에 대한 자세한 정보를 제공할 수 있습니다.
로그 수준을 변경하려면 추가 로그를 생성할 sssd.conf 파일의 각 섹션에 대해 debug_level 매개변수를 설정합니다. 예를 들어 다음과 같습니다. 
[domain/LDAP]
cache_credentials = true
debug_level = 9
Copy to Clipboard Toggle word wrap
Expand
표 A.1. 로그 수준 디버그
level Description
0 치명적인 오류. SSSD가 시작되지 않거나 실행이 중단되는 모든 항목.
1 중요한 오류. SSSD를 강제 종료하지 않지만 하나 이상의 주요 기능이 제대로 작동하지 않을 것임을 나타내는 오류입니다.
2 심각한 오류. 특정 요청 또는 작업이 실패했음을 알리는 동안 오류가 발생했습니다.
3 사소한 오류. 이는 작업 실패가 발생하여 2를 발생시키는 오류입니다.
4 구성 설정.
5 기능 데이터.
6 작업 기능에 대한 메시지를 추적합니다.
7 내부 제어 기능에 대한 메시지를 추적합니다.
8 흥미로운 함수 내부 변수의 내용.
9 매우 낮은 수준의 추적 정보.
SSSD가 실행되는 동안 디버그 수준을 변경하려면 sssd-tools 패키지에 포함된 sss_debuglevel 유틸리티를 사용합니다. 작동 방식에 대한 자세한 내용은 sss_debuglevel 도움말 페이지를 참조하십시오.

A.1.2. SSSD 로그 파일 확인
링크 복사

SSSD는 여러 로그 파일을 사용하여 /var/log/sssd/ 디렉터리에 있는 작업에 대한 정보를 보고합니다. SSSD는 각 도메인에 대한 로그 파일과 sssd_pam.log 및 sssd_nss.log 파일을 생성합니다.
  • krb5_child.log: Kerberos 인증에 관련된 단기 도우미 프로세스의 로그 파일
  • ldap_child.log: LDAP 서버와 통신하는 데 관련된 수명이 짧은 도우미 프로세스의 로그 파일
  • selinux_child.log: SELinux 정보를 검색하는 짧은 도우미 프로세스의 로그 파일
  • sssd.log: 응답자 프로세스와 통신하는 SSSD의 로그 파일
  • sssd_[domain].log: 각 SSSD domain 섹션은 LDAP 서버와의 통신에 대한 정보를 별도의 로그 파일로 기록합니다.
  • sssd_ifp.log: InfoPipe 응답자의 로그 파일은 시스템 버스를 통해 액세스할 수 있는 공용 D-Bus 인터페이스를 제공합니다.
  • sssd_nss.log: 사용자 및 그룹 정보를 검색하는NSS(Name Services Switch)의 로그 파일
  • sssd_pac.log: SSSD가 Kerberos로 작동하는 방식을 정의하는 PAC(Microsoft Privilege Attribute Certificate) 응답자 서비스에 대한 로그 파일 Active Directory 사용자 및 그룹 관리
  • sssd_pam.log: PAM(Pluggable Authentication Module) 응답자의 로그 파일
  • sssd_ssh.log: SSH 응답자 프로세스의 로그 파일
또한 /var/log/secure 파일은 인증 실패와 실패 이유를 기록합니다.

A.1.3. SSSD 설정 문제
링크 복사

질문
SSSD 시작 실패
답변
SSSD에서는 데몬을 시작하기 전에 필요한 모든 항목을 구성 파일을 올바르게 설정해야 합니다.
  • SSSD를 사용하려면 서비스를 시작하기 전에 하나 이상의 올바르게 구성된 도메인이 필요합니다. 도메인이 없으면 SSSD를 시작하려고 하면 도메인이 구성되지 않은 오류가 반환됩니다. 
    # sssd -d4 -i

[sssd] [ldb] (3): server_sort:Unable to register control with rootdse!
[sssd] [confdb_get_domains] (0): No domains configured, fatal error!
[sssd] [get_monitor_config] (0): No domains configured.
    Copy to Clipboard Toggle word wrap
    /etc/sssd/sssd.conf 파일을 편집하고 하나 이상의 도메인을 생성합니다.
  • SSSD를 시작하기 전에 하나 이상의 사용 가능한 서비스 공급자도 필요합니다. 서비스 공급자 구성에 문제가 있으면 서비스가 구성되지 않았음을 오류 메시지에 표시합니다. 
    [sssd] [get_monitor_config] (0): No services configured!
    Copy to Clipboard Toggle word wrap
    /etc/sssd/sssd.conf 파일을 편집하고 하나 이상의 서비스 공급자를 구성합니다.
    중요
    SSSD를 /etc/sssd/sssd.conf 파일의 단일 서비스 항목에 쉼표로 구분된 목록으로 구성해야 합니다. 서비스가 여러 항목에 나열된 경우 마지막 항목만 SSSD에서 인식됩니다.
  • SSSD에는 /etc/sssd/sssd.conf 의 소유권 및 권한도 올바르게 설정되어야 합니다. 소유권 또는 권한이 잘못 설정된 경우 SSSD를 시작하면 다음 오류 메시지를 반환합니다. 
    [sssd] [confdb_ldif_from_ini_file] (0x0020): Permission check on config file failed.
[sssd] [confdb_init_db] (0x0020): Cannot convert INI to LDIF [1]: [Operation not permitted]
[sssd] [confdb_setup] (0x0010): ConfDB initialization has failed [1]: Operation not permitted
[sssd] [load_configuration] (0x0010): Unable to setup ConfDB [1]: Operation not permitted
[sssd] [main] (0x0020): Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root.
    Copy to Clipboard Toggle word wrap
    /etc/sssd/sssd.conf 파일의 올바른 소유권 및 권한을 설정합니다. 
    # chmod 600 /etc/sssd/sssd.conf
# chown root:root /etc/sssd/sssd.conf
    Copy to Clipboard Toggle word wrap
질문
getent 그룹이 있는 id 또는 그룹 멤버가 있는 그룹은 표시되지 않습니다.
답변
이는 sssd.conf 의 [domain/DOMAINNAME] 섹션에 있는 잘못된 ldap_schema 설정으로 인해 발생할 수 있습니다.
SSSD는 RFC 2307 및 RFC 2307bis 스키마 유형을 지원합니다. 기본적으로 SSSD에서는 보다 일반적인 RFC 2307 스키마를 사용합니다.
RFC 2307과 RFC 2307bis의 차이점은 그룹 멤버십이 LDAP 서버에 저장되는 방식입니다. RFC 2307 서버에서 그룹 멤버는 멤버인 사용자 이름을 포함하는 다중 값 memberuid 속성으로 저장됩니다. RFC2307bis 서버에서 그룹 멤버는 이 그룹의 멤버인 사용자 또는 그룹의 DN을 포함하는 다중 값 멤버 또는 uniqueMember 속성으로 저장됩니다. RFC2307bis를 사용하면 중첩 그룹도 유지 관리할 수 있습니다.
그룹 조회가 정보를 반환하지 않는 경우:
  1. ldap_schema 를 rfc2307bis 로 설정합니다.
  2. Delete /var/lib/sss/db/cache_DOMAINNAME.ldb.
  3. SSSD 다시 시작.
이 기능이 작동하지 않으면 다음 행을 sssd.conf 에 추가하십시오. 
ldap_group_name = uniqueMember
Copy to Clipboard Toggle word wrap
그런 다음 캐시를 삭제하고 SSSD를 다시 시작합니다.
질문
LDAP에 대한 인증이 실패합니다.
답변
인증을 수행하려면 SSSD에서 통신 채널을 암호화해야 합니다. 즉, sssd.conf 가 표준 프로토콜(ldap://)을 통해 연결하도록 구성된 경우 Start TLS를 사용하여 통신 채널을 암호화하려고 합니다. sssd.conf 가 보안 프로토콜(ldaps://)을 통해 연결하도록 구성된 경우 SSSD는 SSL을 사용합니다.
즉, LDAP 서버는 SSL 또는 TLS에서 실행되도록 구성해야 합니다. 보안 LDAPS 포트(636)에서 표준 LDAP 포트(389) 또는 SSL을 활성화하려면 TLS를 활성화해야 합니다. SSL 또는 TLS를 사용하면 LDAP 서버도 유효한 인증서 신뢰로 구성해야 합니다.
잘못된 인증서 신뢰는 LDAP 인증에 가장 일반적인 문제 중 하나입니다. 클라이언트에 LDAP 서버 인증서에 대한 신뢰가 없으면 연결을 검증할 수 없으며 SSSD에서 암호를 보내는 것을 거부합니다. LDAP 프로토콜에서는 일반 텍스트로 암호를 LDAP 서버로 보내야 합니다. 암호화되지 않은 연결을 통해 일반 텍스트로 암호를 전송하는 것은 보안 문제입니다.
인증서를 신뢰할 수 없는 경우 TLS 암호화를 시작할 수 없음을 나타내는 syslog 메시지가 기록됩니다. 인증서 구성은 SSSD와 별도로 LDAP 서버에 액세스할 수 있는지 확인하여 테스트할 수 있습니다. 예를 들어, 이 테스트에서는 TLS 연결을 통해 test.example.com 에 대한 익명 바인딩을 테스트합니다. 
$ ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com
Copy to Clipboard Toggle word wrap
인증서 신뢰가 올바르게 구성되지 않은 경우 이 오류와 함께 테스트가 실패합니다. 
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
Copy to Clipboard Toggle word wrap
인증서를 신뢰하려면 다음을 수행합니다.
  1. LDAP 서버 인증서에 서명하는 데 사용되는 인증 기관의 공용 CA 인증서 사본을 가져와 로컬 시스템에 저장합니다.
  2. 파일 시스템의 CA 인증서를 가리키는 sssd.conf 파일에 행을 추가합니다. 
    ldap_tls_cacert = /path/to/cacert
    Copy to Clipboard Toggle word wrap
  3. LDAP 서버에서 자체 서명된 인증서를 사용하는 경우 sssd.conf 파일에서 ldap_tls_reqcert 행을 제거합니다.
    이 매개변수는 자체 서명된 CA 인증서가 있는 보안 위험인 CA 인증서에서 발급한 인증서를 신뢰하도록 SSSD에 지시합니다.
질문
비표준 포트의 LDAP 서버에 연결하지 못했습니다.
답변
강제 모드에서 SELinux를 실행하는 경우 비표준 포트를 통해 LDAP 서버에 연결하도록 클라이언트의 SELinux 정책을 수정해야 합니다. 예를 들어 다음과 같습니다. 
# semanage port -a -t ldap_port_t -p tcp 1389
Copy to Clipboard Toggle word wrap
질문
NSS에서 사용자 정보를 반환하지 못했습니다
답변
일반적으로 SSSD는 NSS 서비스에 연결할 수 없음을 의미합니다.
  • NSS 서비스가 실행 중인지 확인합니다. 
    # service sssd status
Redirecting to /bin/systemctl status sssd.service
  sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: active (running) since Wed 2015-01-14 10:17:26 CET; 1min 30s ago
   Process: 683 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 745 (sssd)
   CGroup: /system.slice/sssd.service
            ├─745 /usr/sbin/sssd -D -f
	    ├─746 /usr/libexec/sssd/sssd_be --domain default --debug-to-files...
	    ├─804 /usr/libexec/sssd/sssd_nss --debug-to-files
	    └─805 /usr/libexec/sssd/sssd_pam --debug-to-files
    Copy to Clipboard Toggle word wrap
    SSSD가 활성(실행 중) 상태이고 출력에 sssd_nss 가 포함된 경우 NSS 서비스가 실행되고 있습니다.
  • NSS가 실행 중인 경우 /etc/sssd/sssd.conf 파일의 [nss] 섹션에 공급자가 올바르게 구성되었는지 확인합니다. 특히 filter_users 및 filter_groups 속성을 확인합니다.
  • NSS가 SSSD에서 사용하는 서비스 목록에 포함되어 있는지 확인합니다.
  • /etc/nsswitch.conf 파일에서 구성을 확인합니다. 자세한 내용은 “SSSD를 사용하도록 NSS 서비스 구성” 의 내용을 참조하십시오.
질문
NSS가 잘못된 사용자 정보를 반환합니다
답변
검색에서 잘못된 사용자 정보를 반환하는 경우 별도의 도메인에 사용자 이름과 충돌하지 않는지 확인합니다. 도메인이 여러 개인 경우 /etc/sssd/sssd.conf 파일에서 use_fully_qualified_domains 속성을 true 로 설정합니다. 이는 동일한 이름으로 다른 도메인의 여러 사용자 간에 구분됩니다.
질문
로컬 SSSD 사용자의 암호 설정에 대해 두 번 메시지가 표시됩니다.
답변
로컬 SSSD 사용자 암호를 변경하려고 할 때 암호를 두 번 입력하라는 메시지가 표시될 수 있습니다. 
[root@clientF11 tmp]# passwd user1000
Changing password for user user1000.
New password:
Retype new password:
New Password:
Reenter new Password:
passwd: all authentication tokens updated successfully.
Copy to Clipboard Toggle word wrap
이는 잘못된 PAM 구성의 결과입니다. use_authtok 옵션이 /etc/pam.d/system-auth 파일에 올바르게 구성되었는지 확인합니다. 올바른 구성의 예는 7.5.2절. “서비스 구성: PAM” 을 참조하십시오.
질문
Active Directory ID 공급자는 sssd.conf 파일에 올바르게 구성되어 있지만 SSSD가 GSS-API 오류와 함께 연결할 수 없습니다.
답변
SSSD는 호스트 이름을 사용하여 Active Directory 공급자만 연결할 수 있습니다. 호스트 이름을 지정하지 않으면 SSSD 클라이언트가 IP 주소를 호스트로 확인할 수 없으며 인증에 실패합니다.
예를 들어 이 구성은 다음과 같습니다. 
[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 172.16.0.1
ad_domain = example.com
krb5_canonicalize = False
Copy to Clipboard Toggle word wrap
SSSD 클라이언트는 이 GSS-API 오류를 반환하고 인증 요청이 실패합니다. 
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Cannot determine realm for numeric host address)]
Copy to Clipboard Toggle word wrap
이 오류를 방지하려면 ad_server 를 Active Directory 호스트의 이름으로 설정하거나 7.4.3절. “DNS 서비스 검색 구성” 에 설명된 대로 _srv_ 키워드를 사용하여 DNS 서비스 검색을 사용합니다.
질문
중앙 인증을 위해 SSSD를 구성했지만 이제 내 애플리케이션(예: Firefox 또는 Adobe)이 시작되지 않습니다.
답변
64비트 시스템에서도 32비트 애플리케이션에는 암호 및 ID 캐시에 액세스하는 데 사용할 32비트 버전의 SSSD 클라이언트 라이브러리가 필요합니다. 32비트 버전의 SSSD를 사용할 수 없지만 시스템이 SSSD 캐시를 사용하도록 구성된 경우 32비트 애플리케이션을 시작하지 못할 수 있습니다.
예를 들어 권한 거부 오류가 있는 Firefox가 실패할 수 있습니다. 
Failed to contact configuration server. See http://www.gnome.org/projects/gconf/
for information. (Details -  1: IOR file '/tmp/gconfd-somebody/lock/ior'
not opened successfully, no gconfd located: Permission denied 2: IOR
file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd
located: Permission denied)
Copy to Clipboard Toggle word wrap
Adobe Reader의 경우 오류에 현재 시스템 사용자가 인식되지 않음이 표시됩니다. 
[jsmith@server ~]$ acroread
(acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown
user id (366)
Copy to Clipboard Toggle word wrap
기타 애플리케이션에는 유사한 사용자 또는 권한 오류가 표시될 수 있습니다.
질문
SSSD에서 제거한 자동 마운트 위치를 보여줍니다.
답변
자동 마운트 위치에 대한 SSSD 캐시는 이후에 위치가 변경되거나 제거되어도 유지됩니다. SSSD에서 autofs 정보를 업데이트하려면 다음을 수행합니다.
  1. A.1.4절. “UID 또는 GID가 변경된 후에는 사용자가 로그인할 수 없습니다.” 에 설명된 대로 autofs 캐시를 제거합니다.
  2. SSSD를 다시 시작합니다. 
    # systemctl restart sssd
    Copy to Clipboard Toggle word wrap

A.1.4. UID 또는 GID가 변경된 후에는 사용자가 로그인할 수 없습니다.
링크 복사

사용자 또는 그룹 ID가 변경되면 SSSD에서 사용자가 로그인하지 못하도록 합니다.
이것이 의미하는 바:
SSSD는 UID(사용자 ID) 및 그룹 ID(GID)를 기반으로 사용자와 그룹을 인식합니다. 기존 사용자 또는 그룹의 UID 또는 GID가 변경되면 SSSD는 사용자 또는 그룹을 인식하지 못합니다.
문제를 해결하려면 다음을 수행합니다.
sss_cache 유틸리티를 사용하여 SSSD 캐시를 지웁니다.
  1. sssd-tools 가 설치되어 있는지 확인합니다.
  2. 특정 사용자에 대한 SSSD 캐시를 지우고 나머지 캐시 레코드를 그대로 두려면 다음을 수행합니다. 
    # sss_cache --user user_name
    Copy to Clipboard Toggle word wrap
    전체 도메인에 대한 캐시를 삭제하려면 다음을 수행합니다. 
    # sss_cache --domain domain_name
    Copy to Clipboard Toggle word wrap
유틸리티는 사용자, 그룹 또는 도메인에 대해 SSSD 캐시의 레코드를 무효화합니다. 이 후 SSSD는 ID 프로바이더에서 레코드를 검색하여 캐시를 새로 고칩니다.
sss_cache 에 대한 자세한 내용은 sss_cache(8) 도움말 페이지를 참조하십시오.

A.1.5. SSSD 제어 및 상태 유틸리티
링크 복사

SSSD는 sssctl 유틸리티를 제공하여 상태 정보를 가져오고, 문제 해결 중에 데이터 파일을 관리하며, 기타 SSSD 관련 작업을 수행합니다.
  1. sssctl 을 사용하려면 sssd-tools 패키지를 설치합니다. 
    [root@server ~]# yum install sssd-tools
    Copy to Clipboard Toggle word wrap
  2. sssctl 의 일부 옵션은 SSSD InfoPipe 응답자를 사용합니다. 이를 활성화하려면 /etc/sssd/sssd.conf 의 services 옵션에 ifp 를 추가합니다. 
    [sssd]
services = nss, sudo, pam, ssh, ifp
    Copy to Clipboard Toggle word wrap
  3. SSSD를 다시 시작합니다. 
    [root@server ~]# systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap
A.1.5.1. SSSD 설정 유효성 검사
링크 복사
sssctl config-check 명령은 SSSD 구성 파일에 대한 정적 분석을 수행합니다. 이를 통해 SSSD를 다시 시작하기 전에 /etc/sssd/sssd.conf 파일과 /etc/sssd/conf.d/* 파일을 검증하여 보고서를 수신할 수 있습니다.
명령은 SSSD 구성 파일에서 다음 검사를 수행합니다.
권한
소유자와 그룹 소유자는 root:root 로 설정하고 권한을 600 으로 설정해야 합니다.
파일 이름
/etc/sssd/conf.d/ 의 파일 이름은 접미사 .conf 를 사용해야 하며 마침표(히드된 파일)로 시작하지 않아야 합니다.
오타 오류
섹션 및 옵션 이름에서 오타 오류가 확인됩니다. 값은 확인되지 않습니다.
옵션
옵션은 올바른 섹션에 배치해야 합니다.
구성을 확인하려면 다음을 실행합니다. 
# sssctl config-check
Issues identified by validators: 3
[rule/allowed_sections]: Section [paM] is not allowed. Check for typos.
[rule/allowed_domain_options]: Attribute 'offline_timeoutX' is not allowed in section 'domain/idm.example.com'. Check for typos.
[rule/allowed_sudo_options]: Attribute 'homedir_substring' is not allowed in section 'sudo'. Check for typos.

Messages generated during configuration merging: 2
File /etc/sssd/conf.d/wrong-file-permissions.conf did not pass access check. Skipping.
File configuration.conf.disabled did not match provided patterns. Skipping.

Used configuration snippet files: 1
/etc/sssd/conf.d/sample.conf
Copy to Clipboard Toggle word wrap
A.1.5.2. 사용자 데이터 표시
링크 복사
sssctl user-checks 명령은 SSSD를 사용자 조회, 인증 및 권한 부여의 백엔드로 사용하는 애플리케이션의 문제를 디버깅하는 데 도움이 됩니다. 명령은 NSS를 통해 사용할 수 있는 사용자 데이터 및 D-Bus 인터페이스에 대한 InfoPipe 응답자를 표시합니다. 표시된 데이터는 사용자가 system-auth PAM 서비스를 사용하여 로그인할 권한이 있는지 여부를 표시합니다.
예를 들어 admin 사용자의 사용자 데이터를 표시하려면 다음을 수행합니다. 
# sssctl user-checks admin
user: admin
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: admin
 - user id: 1194200000
 - group id: 1194200000
 - gecos: Administrator
 - home directory: /home/admin
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: admin
 - uidNumber: 1194200000
 - gidNumber: 1194200000
 - gecos: Administrator
 - homeDirectory: /home/admin
 - loginShell: /bin/bash

testing pam_acct_mgmt

pam_acct_mgmt: Success

PAM Environment:
 - no env -
Copy to Clipboard Toggle word wrap
추가 옵션은 sssctl user-checks --help 명령의 출력을 참조하십시오.
A.1.5.3. 도메인 정보
링크 복사
도메인 상태에 도메인 SSSD 액세스 목록이 표시되고 해당 상태를 검색할 수 있습니다.
  1. 신뢰할 수 있는 도메인을 포함하여 SSSD 내에서 사용 가능한 모든 도메인을 나열합니다. 
    [root@server ~]# sssctl domain-list
idm.example.com
ad.example.com
    Copy to Clipboard Toggle word wrap
  2. 도메인 idm.example.com의 상태를 검색합니다. 
    [root@server ~]# sssctl domain-status idm.example.com
Online status: Online
    Copy to Clipboard Toggle word wrap
A.1.5.4. 캐시된 항목 정보
링크 복사
sssctl 명령을 사용하면 캐시된 항목에 대한 정보를 검색하여 캐시 관련 인증 문제를 조사하고 디버깅할 수 있습니다.
사용자 계정 관리자 의 캐시 정보를 쿼리하려면 다음을 실행합니다. 
[root@server ~]# sssctl user-show admin
Name: admin
Cache entry creation date: 07/10/16 16:09:18
Cache entry last update time: 07/14/16 10:13:32
Cache entry expiration time: 07/14/16 11:43:32
Initgroups expiration time: Expired
Cached in InfoPipe: No
Copy to Clipboard Toggle word wrap
그룹 또는 넷 그룹의 캐시 정보를 쿼리하려면 다음을 사용합니다. 
[root@server ~]# sssctl group-show groupname
[root@server ~]# sssctl netgroup-show netgroupname
Copy to Clipboard Toggle word wrap
A.1.5.5. 로그 파일 잘라내기
링크 복사
문제를 디버깅할 때 sssctl logs-remove 를 사용하여 /var/log/sssd/ 디렉토리의 모든 SSSD 로그 파일을 잘라 새로 생성된 항목만 캡처할 수 있습니다. 
[root@server ~]# sssctl logs-remove
Truncating log files...
Copy to Clipboard Toggle word wrap
A.1.5.6. SSSD 캐시 제거
링크 복사
SSSD 캐시 데이터베이스 파일을 제거하기 위해 sssctl 명령은 remove-cache 옵션을 제공합니다. 데이터베이스를 제거하기 전에 명령은 자동으로 백업을 생성합니다.
다음 명령을 사용하여 모든 로컬 데이터를 백업하고 SSSD 캐시를 제거합니다. 
[root@server ~]# sssctl cache-remove
SSSD must not be running. Stop SSSD now? (yes/no) [yes]
Creating backup of local data...
Removing cache files...
SSSD needs to be running. Start SSSD now? (yes/no) [yes]
Copy to Clipboard Toggle word wrap
참고
백업은 로컬 덮어쓰기와 같은 로컬 데이터만 /var/lib/sss/backup/ 디렉터리에 저장합니다.
백업된 콘텐츠를 자동으로 가져오려면 sssctl restore-local-data 를 실행합니다.
A.1.5.7. LDAP 그룹에 대한 정보 얻기에 걸림
링크 복사
LDAP 그룹에 대한 정보를 찾는 데 필요한 작업은 특히 대규모 그룹 또는 중첩 그룹의 경우 매우 오래 걸립니다.
이것이 의미하는 바:
기본적으로 LDAP 그룹 정보 조회는 그룹에 대한 모든 구성원을 반환합니다. 대규모 그룹 또는 중첩 그룹이 포함된 작업의 경우 모든 구성원을 반환하면 프로세스가 더 길어집니다.
문제를 해결하려면 다음을 수행합니다.
사용자가 그룹에 속하는지 평가할 때 그룹 조회에 반환된 멤버십 목록은 사용되지 않습니다. 특히 ID 조회의 경우 성능을 개선하려면 그룹 멤버십 조회를 비활성화합니다.
  1. /etc/sssd/sssd.conf 파일을 엽니다.
  2. [domain] 섹션에서 ignore_group_members 옵션을 true 로 설정합니다. 
    [domain/domain_name]
[... file truncated ...]
ignore_group_members = true
    Copy to Clipboard Toggle word wrap
참고
배포에 compat 트리가 있는 IdM 서버가 포함된 경우 이 옵션을 true 로 설정하지 않아야 합니다.

A.2. SSSD 및 sudo 디버깅 로그를 사용하여 sudo 문제 해결
링크 복사

A.2.1. SSSD 및 sudo 디버그 로깅
링크 복사

디버그 로깅 기능을 사용하면 SSSD 및 sudo에 대한 추가 정보를 로깅할 수 있습니다.
sudo 디버그 로그 파일
sudo 디버깅을 활성화하려면 다음을 수행합니다.
  1. /etc/sudo.conf 에 다음 행을 추가합니다. 
    Debug sudo /var/log/sudo_debug.log all@debug
Debug sudoers.so /var/log/sudo_debug.log all@debug
    Copy to Clipboard Toggle word wrap
  2. 디버그할 사용자로 sudo 명령을 실행합니다.
/var/log/sudo_debug.log 파일은 자동으로 생성되고 다음과 같은 질문에 답변할 수 있는 자세한 정보를 제공합니다.
  • sudo 명령을 실행할 때 사용자와 환경에 대해 사용할 수 있는 정보는 무엇입니까? 
    sudo[22259] settings: debug_flags=all@debug
sudo[22259] settings: run_shell=true
sudo[22259] settings: progname=sudo
sudo[22259] settings: network_addrs=192.0.2.1/255.255.255.0 fe80::250:56ff:feb9:7d6/ffff:ffff:ffff:ffff::
sudo[22259] user_info: user=user_name
sudo[22259] user_info: pid=22259
sudo[22259] user_info: ppid=22172
sudo[22259] user_info: pgid=22259
sudo[22259] user_info: tcpgid=22259
sudo[22259] user_info: sid=22172
sudo[22259] user_info: uid=10000
sudo[22259] user_info: euid=0
sudo[22259] user_info: gid=554801393
sudo[22259] user_info: egid=554801393
sudo[22259] user_info: groups=498,6004,6005,7001,106501,554800513,554801107,554801108,554801393,554801503,554802131,554802244,554807670
sudo[22259] user_info: cwd=/
sudo[22259] user_info: tty=/dev/pts/1
sudo[22259] user_info: host=client
sudo[22259] user_info: lines=31
sudo[22259] user_info: cols=237
    Copy to Clipboard Toggle word wrap
  • sudo 규칙을 가져오는 데 사용되는 데이터 소스는 무엇입니까? 
    sudo[22259] <- sudo_parseln @ ./fileops.c:178 := sudoers: files sss
    Copy to Clipboard Toggle word wrap
  • SSSD 플러그인은 다음 행으로 시작합니다. 
    sudo[22259] <- sudo_sss_open @ ./sssd.c:305 := 0
    Copy to Clipboard Toggle word wrap
  • SSSD가 반환된 규칙은 몇 개입니까? 
    sudo[22259] Received 3 rule(s)
    Copy to Clipboard Toggle word wrap
  • 규칙이 일치합니까? 
    sudo[22259] sssd/ldap sudoHost 'ALL' ... MATCH!
sudo[22259] <- user_in_group @ ./pwutil.c:1010 := false
    Copy to Clipboard Toggle word wrap
SSSD 디버그 로그 파일
SSSD 디버깅을 활성화하려면 다음을 수행합니다.
  1. /etc/sssd/sssd.conf 파일의 [sudo] 및 [domain/domain_name] 섹션에 debug_level 옵션을 추가합니다. 
    [domain/domain_name]
debug_level = 0x3ff0
...
[sudo]
debug_level = 0x3ff0
    Copy to Clipboard Toggle word wrap
  2. SSSD를 다시 시작합니다. 
    # systemctl restart sssd
    Copy to Clipboard Toggle word wrap
  3. sudo 명령을 실행하여 디버그 정보를 로그 파일에 작성합니다.
다음 로그 파일이 생성됩니다.
도메인 로그 파일: /var/log/sssd/sssd_domain_name.log
이 로그 파일은 다음과 같은 질문에 답하는 데 도움이 됩니다.
  • SSSD가 반환된 규칙은 몇 개입니까? 
    [sdap_sudo_refresh_load_done] (0x0400): Received 4-rules rules
    Copy to Clipboard Toggle word wrap
  • 서버에서 SSSD를 다운로드한 sudo 규칙은 무엇입니까? 
    [sssd[be[LDAP.PB]]] [sysdb_save_sudorule] (0x0400): Adding sudo rule demo-name
    Copy to Clipboard Toggle word wrap
  • 일치하는 규칙이 캐시에 저장됩니까? 
    [sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfully stored in cache
    Copy to Clipboard Toggle word wrap
  • 서버에서 규칙을 다운로드하는 데 어떤 필터가 사용되었습니까? 
    [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=client.example.com)(sudoHost=client)(sudoHost=192.0.2.1)(sudoHost=192.0.2.0/24)(sudoHost=2620:52:0:224e:21a:4aff:fe23:1394)(sudoHost=2620:52:0:224e::/64)(sudoHost=fe80::21a:4aff:fe23:1394)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*))))][dc=example,dc=com]
    Copy to Clipboard Toggle word wrap
    IdM 데이터베이스에서 규칙을 찾으려면 이 필터를 사용합니다. 
    # ldapsearch -x -D "cn=Directory Manager" -W -H ldap://server.example.com -b dc=example,dc=com '(&(objectClass=sudoRole)...)'
    Copy to Clipboard Toggle word wrap
sudo 응답자 로그 파일: /var/log/sssd/sssd_sudo.log
이 로그 파일은 다음과 같은 질문에 답하는 데 도움이 됩니다.
  • SSSD가 반환된 규칙은 몇 개입니까? 
    [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 4-rules rules for [user@idm.example.com]
    Copy to Clipboard Toggle word wrap
  • SSSD의 캐시 검색에 어떤 필터가 적용되었습니까? 
    [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=user)(sudoUser=#10001)(sudoUser=%group-1)(sudoUser=%user)(sudoUser=+*)))]
    Copy to Clipboard Toggle word wrap
  • SSSD 캐시에서 반환된 규칙을 어떻게 조회합니까? 다음 필터를 사용하여 규칙을 조회합니다. 
    # ldbsearch -H /var/lib/sss/db/cache_domain_name.ldb -b cn=sysdb '(&(objectClass=sudoRule)...)'
    Copy to Clipboard Toggle word wrap
    참고
    ldbsearch 유틸리티는 ldb-tools 패키지에 포함되어 있습니다.

A.3. Firefox Kerberos 구성 문제 해결
링크 복사

Kerberos 인증이 작동하지 않는 경우 인증 프로세스에 대한 자세한 로깅을 설정합니다.
  1. Firefox의 모든 인스턴스를 종료합니다.
  2. 명령 프롬프트에서 NSPR_LOG_* 변수의 값을 내보냅니다. 
    export NSPR_LOG_MODULES=negotiateauth:5
export NSPR_LOG_FILE=/tmp/moz.log
    Copy to Clipboard Toggle word wrap
  3. 해당 쉘에서 Firefox를 다시 시작하고 Kerberos 인증에 실패하는 웹 사이트를 방문합니다.
  4. 메시지에서 nsNegotiateAuth 를 사용하여 오류 메시지가 있는지 /tmp/moz.log 파일을 확인합니다.
Kerberos 인증에서 발생하는 몇 가지 일반적인 오류가 있습니다.
인증 정보를 찾을 수 없습니다
-1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken()
-1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure
No credentials cache found
Copy to Clipboard Toggle word wrap
즉, 사용할 수 있는 Kerberos 티켓이 없습니다(만료되었거나 생성되지 않았음). 이 문제를 해결하려면 kinit 를 실행하여 Kerberos 티켓을 생성한 다음 웹사이트를 다시 엽니다.
Kerberos 데이터베이스에서 서버를 찾을 수 없음
-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken()
-1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure
Server not found in Kerberos database
Copy to Clipboard Toggle word wrap
즉, 브라우저에서 KDC에 연결할 수 없습니다. 일반적으로 Kerberos 설정 문제입니다. 도메인을 확인하려면 /etc/krb5.conf 파일의 [domain_realm] 섹션에 올바른 항목이 있어야 합니다. 예를 들어 다음과 같습니다. 
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Copy to Clipboard Toggle word wrap
로그에 오류가 없습니다
HTTP 프록시 서버는 Kerberos 인증에 필요한 HTTP 헤더를 제거할 수 있습니다. HTTPS를 사용하여 사이트에 연결을 시도하면 요청이 수정되지 않은 상태로 전달할 수 있습니다.

부록 B. 개정 내역
링크 복사

버전 번호는 Red Hat Enterprise Linux 버전 번호와는 달리 이 설명서의 버전과 관련이 있습니다.

고친 과정
고침 7.0-31Wed Nov 11 2020Florian Delehaye
7.9 GA 게시에 대한 마이너 수정 사항으로 업데이트되었습니다.
고침 7.0-30Tue Aug 06 2019Marc Muehlfeld
7.7 GA 게시를 위한 문서 버전.
고침 7.0-29Tue Apr 08 2019Marc Muehlfeld
SSSD용 파일 공급업체 구성 및 사용자 데이터 표시 추가. 부차적인 픽스 및 업데이트.
고침 7.0-28Fri Oct 26 2018Filip Hanzelka
7.6 GA 게시 문서 준비.
고침 7.0-27Mon Jun 25 2018Filip Hanzelka
업데이트된 certmonger 작업.
고침 7.0-26Tue Apr 10 2018Filip Hanzelka
7.5 GA 게시 문서 준비.
고침 7.0-25Mon Mar 19 2018Lucie Maňásková
마이너 업데이트.
고침 7.0-24Mon Feb 12 2018Aneta Šteflová Petrová
부차적인 픽스 및 업데이트.
고침 7.0-23Mon Jan 29 2018Aneta Šteflová Petrová
부수적인 픽스.
고침 7.0-22Mon Dec 4 2017Aneta Šteflová Petrová
업데이트된 스마트 카드.
고침 7.0-21Mon Nov 20 2017Aneta Šteflová Petrová
부수적인 픽스.
고침 7.0-20Mon Nov 6 2017Aneta Šteflová Petrová
부수적인 픽스.
고침 7.0-19Mon Aug 14 2017Aneta Šteflová Petrová
coolkey 패키지를 참조한 업데이트된 섹션.
고침 7.0-18Tue Jul 18 2017Aneta Šteflová Petrová
7.4 GA 게시를 위한 문서 버전.
고침 7.0-17Mon Mar 27 2017Aneta Šteflová Petrová
고정 깨진 링크.
고침 7.0-16Mon Feb 27 2017Aneta Šteflová Petrová
업데이트된 Kerberos KDC 프록시. 기타 마이너 업데이트.
고침 7.0-15Wed Dec 7 2016Aneta Šteflová Petrová
SSSD 클라이언트측 뷰 추가. 기타 마이너 업데이트.
고침 7.0-14Tue Oct 18 2016Aneta Šteflová Petrová
7.3 GA 게시 버전.
고침 7.0-13Wed Jul 27 2016Marc Muehlfeld
HTTP(kdcproxy)를 통해 Kerberos가 추가되어 SCEP를 통해 인증서를 요청하는 기타 마이너 업데이트.
고침 7.0-11Thu Mar 03 2016Aneta Petrová
PAM 서비스에 대한 제한 도메인 추가.
고침 7.0-10Tue Feb 09 2016Aneta Petrová
authconfig 장을 더 작은 장, 기타 마이너 업데이트로 분할.
고침 7.0-9Thu Nov 12 2015Aneta Petrová
7.2 GA 릴리스 버전.
고침 7.0-8Fri Mar 13 2015Tomáš Čapek
7.1의 마지막 분 편집으로 비동기 업데이트.
고침 7.0-6Wed Feb 25 2015Tomáš Čapek
7.1 GA 릴리스 버전.
고침 7.0-4Fri Dec 05 2014Tomáš Čapek
시작 페이지에서 정렬 순서를 업데이트하도록 다시 빌드합니다.
고침 7.0-1July 16, 2014Ella Deon Ballard
RHEL 7.0의 초기 초안.

법적 공지
링크 복사

Copyright © 2020 Red Hat, Inc.
이 문서는 Red Hat이 Creative Commons Attribution-ShareAlike 3.0 Unported License 에 따라 라이센스가 부여됩니다. 이 문서 또는 수정된 버전을 배포하는 경우 Red Hat, Inc.에 attribution을 제공하고 원본 버전에 대한 링크를 제공해야 합니다. 문서가 수정되면 모든 Red Hat 상표를 제거해야 합니다.
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 마크 및 OpenStack 로고는 미국 및 기타 국가에서 OpenStack Foundation의 등록 상표/서비스 마크 또는 상표/서비스 마크이며 OpenStack Foundation의 권한과 함께 사용됩니다. 당사는 OpenStack Foundation 또는 OpenStack 커뮤니티와 제휴 관계가 아니며 보증 또는 후원을 받지 않습니다.
기타 모든 상표는 각각 해당 소유자의 자산입니다.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat