시스템 수준 인증 가이드 | Red Hat Product Documentation (2024)

• 모든 명령에 --update 또는 -- test 옵션을 사용합니다. 명령을 성공적으로 실행하려면 해당 옵션 중 하나가 필요합니다. update를 사용하면 구성 변경 사항을 씁니다. test 옵션은 변경 사항을 표시하지만 변경 사항을 구성에 적용하지 않습니다.

  update 옵션을 사용하지 않으면 변경 사항이 시스템 구성 파일에 작성되지 않습니다.

• 명령줄을 사용하여 기존 구성을 업데이트하고 새 구성을 설정할 수 있습니다. 이로 인해 명령 행은 지정된 호출과 함께 필요한 속성을 사용하도록 강제 적용하지 않습니다(명령은 완전한 설정 업데이트일 수 있기 때문입니다).

  인증 구성을 편집할 때는 구성이 완료되고 정확해야 합니다. 인증 설정을 불완전하거나 잘못된 값으로 변경하면 사용자가 시스템에서 잠길 수 있습니다. --test 옵션을 사용하여 --update 옵션을 사용하여 쓰기 전에 설정이 적절한지 확인합니다.

• 각 활성화 옵션에는 해당 비활성화 옵션이 있습니다.

1. 터미널을 열고 root로 로그인합니다.

2. system-config-authentication 명령을 실행합니다.

• ID 및 인증: ID 저장소로 사용되는 리소스(사용자 ID 및 해당 인증 정보가 저장된 데이터 리포지토리)를 구성합니다.

• 고급 옵션: 스마트 카드 및 지문과 같은 암호 또는 인증서 이외의 인증 방법을 구성합니다.

• 암호 인증 방법을 구성하는 암호 옵션.

그림 2.1. authconfig 창

1. authconfig UI를 엽니다.

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

   그림 3.1. 인증 설정

   

3. IdM 서버에 연결하는 데 필요한 정보를 설정합니다.

   • IPA 도메인 은 IdM 도메인의 DNS 도메인을 제공합니다.

   • IPA Cryo stat는 IdM 도메인의 Kerberos 도메인을 제공합니다.

   • IPA 서버는 IdM 도메인 토폴로지 내의 모든 IdM 서버의 호스트 이름을 제공합니다.

   • 클라이언트가 구성된 경우 NTP 서비스를 선택적으로 비활성화 하지 마십시오. IdM 서버와 모든 클라이언트가 Kerberos 인증 및 인증서가 제대로 작동하려면 클록을 동기화해야 하므로 이 방법은 일반적으로 권장되지 않습니다. IdM 서버가 도메인 내에서 호스팅하지 않고 다른 NTP 서버를 사용하는 경우 비활성화할 수 있습니다.

4. 도메인 참여 버튼을 클릭합니다.

   그러면 ipa-client-install 명령을 실행하고 필요한 경우 ipa-client 패키지를 설치합니다. 설치 스크립트는 로컬 시스템에 필요한 모든 시스템 파일을 자동으로 구성하고 도메인 서버에 연결하여 도메인 정보를 업데이트합니다.

1. 2.2.3절. “authconfig UI 시작” 에서와 같이 authconfig UI를 엽니다.

2. User Account Database 드롭다운 메뉴에서 LDAP 를 선택합니다.

   

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 서버에 연결함으로써 보안 연결을 설정해야 합니다.

1. 2.2.3절. “authconfig UI 시작” 에서와 같이 authconfig UI를 엽니다.

2. User Account Database 드롭다운 메뉴에서 NIS 를 선택합니다.

   

3. NIS 도메인 이름과 서버 호스트 이름을 의미하는 NIS 서버에 연결할 정보를 설정합니다. NIS 서버를 지정하지 않으면 authconfig 데몬은 NIS 서버에서 검색합니다.

4. 인증 방법을 선택합니다. NIS는 단순한 암호 인증 또는 Kerberos 인증을 허용합니다.

   Kerberos 사용은 4.3.1절. “UI에서 Kerberos 인증 구성” 에 설명되어 있습니다.

1. samba-winbind 패키지를 설치합니다. 이는 Samba 서비스의 Windows 통합 기능에 필요하지만 기본적으로 설치되지 않습니다.

   [root@server ~]# yum install samba-winbind

2. authconfig UI를 엽니다.

   [root2server ~]# authconfig-gtk

3. ID 및 인증 탭의 사용자 계정 데이터베이스 드롭다운 메뉴에서 Winbind 를 선택합니다.

   

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

       기본 옵션입니다.

   • winbind ADS Cryostat 는 Samba 서버가 참여할 Active Directory 영역을 제공합니다. 이는 광고 보안 모델에만 사용됩니다.

   • winbind 도메인 컨트롤러는 시스템을 등록하는 데 사용할 도메인 컨트롤러의 호스트 이름 또는 IP 주소를 제공합니다.

   • 템플릿 쉘 은 Windows 사용자 계정 설정에 사용할 로그인 쉘을 설정합니다.

   • 오프라인 로그인을 허용 하면 인증 정보를 로컬 캐시에 저장할 수 있습니다. 사용자가 시스템이 오프라인 상태인 상태에서 시스템 리소스를 인증하려고 할 때 캐시를 참조합니다.

그림 4.1. 로컬 계정 필드

그림 4.2. Kerberos 필드

• realm 은 Kerberos 서버의 영역 이름을 제공합니다. 영역은 하나 이상의 KDC(키 배포 센터 ) 및 잠재적으로 많은 클라이언트로 구성된 Kerberos를 사용하는 네트워크입니다.

• KDCs 는 Kerberos 티켓을 발행하는 쉼표로 구분된 서버 목록을 제공합니다.

• 관리 서버는 영역에서 kadmind 프로세스를 실행하는 관리 서버 목록을 제공합니다.

• 선택적으로 DNS를 사용하여 서버 호스트 이름을 확인하고 영역 내에서 추가 KDC를 찾습니다.

그림 4.3. 스마트 카드 옵션

스마트 카드

• 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.4. 지문 옵션

1. 클라이언트를 ID 저장소에 연결하여 인증 정보를 검색합니다.

2. 가져온 인증 정보를 사용하여 클라이언트에서 사용자 및 자격 증명의 로컬 캐시를 생성합니다.

그림 7.1. SSSD 작동 방식

ID 및 인증 서버에 대한 로드 감소

정보를 요청할 때 SSSD 클라이언트는 캐시를 확인하는 SSSD에 문의합니다. SSSD는 캐시에서 정보를 사용할 수 없는 경우에만 서버에 연결합니다.

오프라인 인증

SSSD는 선택적으로 원격 서비스에서 검색된 사용자 ID 및 자격 증명의 캐시를 유지합니다. 이 설정에서는 원격 서버 또는 SSSD 클라이언트가 오프라인 상태인 경우에도 사용자가 리소스에 성공적으로 인증할 수 있습니다.

단일 사용자 계정: 인증 프로세스의 일관성 향상

SSSD에서는 오프라인 인증을 위해 중앙 계정과 로컬 사용자 계정을 모두 유지 관리할 필요가 없습니다.

원격 사용자에게는 종종 여러 사용자 계정이 있습니다. 예를 들어 VPN(가상 사설 네트워크)에 연결하려면 원격 사용자는 로컬 시스템을 위한 하나의 계정과 VPN 시스템의 다른 계정을 보유합니다.

원격 사용자는 캐싱 및 오프라인 인증으로 간단하게 로컬 시스템에 인증하여 네트워크 리소스에 연결할 수 있습니다. 그런 다음 SSSD에서 네트워크 자격 증명을 유지합니다.

• ID 공급자 (사용자 정보용)

• 인증 공급자 (인증 요청용)

• 액세스 제어 공급자 (허용 요청용)

• 이러한 공급자의 조합 (모든 해당 작업이 단일 서버 내에서 수행되는 경우)

• 지문 스캐너와 같은 대체 인증 방법

• NIS와 같은 레거시 시스템

• /etc/passwd 및 원격 인증에 정의된 로컬 시스템 계정

• Identity Management를 위해 SSSD 클라이언트를 구성하려면 ipa-client-install 유틸리티를 사용하는 것이 좋습니다. Linux 도메인 ID, 인증 및 정책 가이드에서 ID 관리 클라이언트 설치 및 제거를 참조하십시오.

• ipa-client-install 없이 수동으로 Identity Management용 SSSD 클라이언트를 구성하려면 Red Hat 지식 베이스에서 수동으로 Identity Management 클라이언트 설치 및 설치 제거를 참조하십시오.

• SSSD와 함께 사용할 Active Directory 를 구성하려면 Windows 통합 가이드에서 Active Directory를 SSSD의 ID 공급자로 사용을 참조하십시오.

• SSSD 설치.

  # yum install sssd

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. LDAP 도메인에 대한 [domain] 섹션을 생성합니다.

   [domain/LDAP_domain_name]

3. LDAP 서버를 ID 공급자, 인증 공급자 또는 둘 다로 사용하려는 경우 를 지정합니다.

   1. LDAP 서버를 ID 공급자로 사용하려면 id_provider 옵션을 ldap 로 설정합니다.

   2. LDAP 서버를 인증 공급자로 사용하려면 auth_provider 옵션을 ldap 로 설정합니다.

   예를 들어 LDAP 서버를 둘 다 사용하려면 다음을 수행합니다.

   [domain/LDAP_domain_name]id_provider = ldapauth_provider = ldap

4. LDAP 서버를 지정합니다. 다음 중 하나를 선택합니다.

   1. 서버를 명시적으로 정의하려면 ldap_uri 옵션을 사용하여 서버의 URI를 지정합니다.

      [domain/LDAP_domain_name]id_provider = ldapauth_provider = ldapldap_uri = ldap://ldap.example.com

      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 = ldapauth_provider = ldapldap_uri = ldap://ldap.example.comldap_search_base = dc=example,dc=com

6. LDAP 서버에 대한 보안 연결을 설정하는 방법을 지정합니다. 권장되는 방법은 TLS 연결을 사용하는 것입니다. 이렇게 하려면 ldap_id_use_start_tls 옵션을 활성화하고 이러한 CA 인증서 관련 옵션을 사용합니다.

   • ldap_tls_reqcert 는 클라이언트가 서버 인증서를 요청하는지 및 인증서에서 수행되는 검사를 지정합니다.

   • ldap_tls_cacert 는 인증서가 포함된 파일을 지정합니다.

   [domain/LDAP_domain_name]id_provider = ldapauth_provider = ldapldap_uri = ldap://ldap.example.comldap_search_base = dc=example,dc=comldap_id_use_start_tls = trueldap_tls_reqcert = demandldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

   참고

   SSSD는 항상 암호화된 채널을 인증을 위해 사용하므로 암호가 암호화되지 않은 네트워크를 통해 전송되지 않습니다. ldap_id_use_start_tls = true 에서는 ID 조회(예: id 또는 getent 유틸리티를 기반으로 하는 명령)도 암호화됩니다.

7. [sssd] 섹션의 domain 옵션에 새 도메인을 추가합니다. 옵션은 SSSD에서 쿼리하는 도메인을 나열합니다. 예를 들어 다음과 같습니다.

   domains = LDAP_domain_name, domain2

• sssd.conf(5) 도움말 페이지: 모든 유형의 도메인에 사용 가능한 글로벌 옵션을 설명합니다.

• LDAP와 관련된 옵션을 설명하는 sssd-ldap(5) 도움말 페이지

• SSSD 설치.

  # yum install sssd

1. /etc/sssd/sssd.conf 파일에 다음 섹션을 추가합니다.

   [domain/files]id_provider = files

2. 선택적으로 /etc/sssd/sssd.conf 파일에서 사용자 및 그룹 조회의 첫 번째 소스로 sss 데이터베이스를 설정합니다.

   passwd: sss filesgroup: sss files

3. 시스템이 부팅될 때 sssd 서비스가 시작되는 방식으로 시스템을 구성합니다.

   # systemctl enable sssd

4. sssd 서비스를 다시 시작합니다.

   # systemctl restart sssd

• sssd.conf(5) 도움말 페이지: 모든 유형의 도메인에 사용 가능한 글로벌 옵션을 설명합니다.

• 파일 공급자와 관련된 옵션을 설명하는 sssd-files(5) 도움말 페이지

• SSSD 설치.

  # yum install sssd

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. 프록시 공급자에 대한 [domain] 섹션을 생성합니다.

   [domain/proxy_name]

3. 인증 공급자를 지정하려면 다음을 수행합니다.

   1. auth_provider 옵션을 proxy 로 설정합니다.

   2. proxy_pam_target 옵션을 사용하여 PAM 서비스를 인증 프록시로 지정합니다.

   예를 들어 다음과 같습니다.

   [domain/proxy_name]auth_provider = proxyproxy_pam_target = sssdpamproxy

   중요

   프록시 PAM 스택에 pam_sss.so 가 재귀적으로 포함되지 않는지 확인합니다.

4. ID 공급자를 지정하려면 다음을 수행합니다.

   1. id_provider 옵션을 proxy 로 설정합니다.

   2. proxy_lib_name 옵션을 사용하여 NSS 라이브러리를 ID 프록시로 지정합니다.

   예를 들어 다음과 같습니다.

   [domain/proxy_name]id_provider = proxyproxy_lib_name = nis

5. [sssd] 섹션의 domain 옵션에 새 도메인을 추가합니다. 옵션은 SSSD에서 쿼리하는 도메인을 나열합니다. 예를 들어 다음과 같습니다.

   domains = proxy_name, domain2

• SSSD 설치.

  # yum install sssd

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. SSSD 도메인의 [domain] 섹션을 생성합니다.

   [domain/Kerberos_domain_name]

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 = ldapauth_provider = krb5

   2. Kerberos 서버를 지정합니다.

      1. 서버를 명시적으로 정의하려면 krb5_server 옵션을 사용합니다. 옵션은 서버의 호스트 이름 또는 IP 주소를 허용합니다.

         [domain/Kerberos_domain_name]id_provider = ldapauth_provider = krb5krb5_server = kdc.example.com

      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 = ldapauth_provider = krb5krb5_server = kdc.example.comkrb5_backup_server = kerberos.example.comkrb5_passwd = kerberos.admin.example.com

      krb5_passwd 를 사용하지 않는 경우 SSSD는 krb5_server 또는 krb5_backup_server 에 지정된 KDC를 사용합니다.

   4. krb5_realm 옵션을 사용하여 Kerberos 영역의 이름을 지정합니다.

      [domain/Kerberos_domain_name]id_provider = ldapauth_provider = krb5krb5_server = kerberos.example.comkrb5_backup_server = kerberos2.example.comkrb5_passwd = kerberos.admin.example.comkrb5_realm = EXAMPLE.COM

5. [sssd] 섹션의 domain 옵션에 새 도메인을 추가합니다. 옵션은 SSSD에서 쿼리하는 도메인을 나열합니다. 예를 들어 다음과 같습니다.

   domains = Kerberos_domain_name, domain2

• sssd.conf(5) 도움말 페이지: 모든 유형의 도메인에 사용 가능한 글로벌 옵션을 설명합니다.

• Kerberos와 관련된 옵션을 설명하는 sssd-krb5(5) 도움말 페이지

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. domain 섹션에서 cache_credentials = true 설정을 추가합니다.

   [domain/domain_name]cache_credentials = true

3. 선택 사항이지만 권장되는 옵션입니다. ID 공급자를 사용할 수 없는 경우 SSSD에서 오프라인 인증을 허용하는 기간을 설정합니다.

   1. SSSD에서 작동하도록 PAM 서비스를 구성합니다. 7.5.2절. “서비스 구성: PAM” 참조하십시오.

   2. offline_credentials_expiration 옵션을 사용하여 시간 제한을 지정합니다. 예를 들어 마지막으로 로그인한 후 사용자가 3일 동안 오프라인 인증을 받을 수 있도록 지정하려면 다음을 수행합니다.

      [pam]offline_credentials_expiration = 3

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. 기본 서버 값을 _srv_ 로 설정합니다. LDAP 공급자의 경우 기본 서버는 ldap_uri 옵션을 사용하여 설정됩니다.

   [domain/domain_name]id_provider = ldapldap_uri = _srv_

3. 서비스 유형을 설정하여 암호 변경 공급자에서 서비스 검색을 활성화합니다.

   [domain/domain_name]id_provider = ldapldap_uri = _srv_chpass_provider = ldapldap_chpass_dns_service_name = ldap

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

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. access_provider 옵션을 simple 로 설정합니다.

   [domain/domain_name]access_provider = simple

3. 사용자에 대한 액세스 제어 규칙을 정의합니다. 다음 중 하나를 선택합니다.

   1. 사용자에 대한 액세스를 허용하려면 simple_allow_users 옵션을 사용합니다.

   2. 사용자에 대한 액세스를 거부하려면 simple_deny_users 옵션을 사용합니다.

      중요

      특정 사용자에 대한 액세스 허용은 거부하는 것보다 더 안전하다고 간주됩니다. 특정 사용자에 대한 액세스를 거부하면 다른 모든 사용자에 대한 액세스를 자동으로 허용합니다.

4. 그룹에 대한 액세스 제어 규칙을 정의합니다. 다음 중 하나를 선택합니다.

   1. 그룹에 대한 액세스를 허용하려면 simple_allow_groups 옵션을 사용합니다.

   2. 그룹에 대한 액세스를 거부하려면 simple_deny_groups 옵션을 사용합니다.

      중요

      특정 그룹에 대한 액세스 허용은 거부하는 것보다 더 안전하다고 간주됩니다. 특정 그룹에 대한 액세스를 거부하면 다른 모든 사용자에 대한 액세스를 자동으로 허용합니다.

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=*))

• 사용자 정보( passwd 맵)

• 그룹( 그룹 맵)

• netgroups( netgroups 맵)

• 서비스( 서비스 맵)

• SSSD 설치.

  # yum install sssd

1. authconfig 유틸리티를 사용하여 SSSD를 활성화합니다.

   [root@server ~]# authconfig --enablesssd --update

   이렇게 하면 /etc/nsswitch.conf 파일이 업데이트되어 다음 NSS 맵에서 SSSD를 사용할 수 있습니다.

   passwd: files sssshadow: files sssgroup: files sssnetgroup: files sss

2. /etc/nsswitch.conf 를 열고 sss 를 서비스 맵 줄에 추가합니다.

   services: files sss

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. [sssd] 섹션에서 NSS가 SSSD와 함께 작동하는 서비스 중 하나로 나열되어 있는지 확인합니다.

   [sssd][... file truncated ...]services = nss, pam

3. [nss] 섹션에서 SSSD가 NSS와 상호 작용하는 방법을 구성합니다. 예를 들어 다음과 같습니다.

   [nss]filter_groups = rootfilter_users = rootentry_cache_timeout = 300entry_cache_nowait_percentage = 75

   사용 가능한 옵션의 전체 목록은 sssd.conf(5) 도움말 페이지의 NSS 구성 옵션을 참조하십시오.

4. SSSD를 다시 시작합니다.

   # systemctl restart sssd.service

• ID 사용자

• getent passwd 사용자

• authconfig 유틸리티를 사용하여 SSSD를 활성화합니다.

  # authconfig --enablesssdauth --update

  이렇게 하면 PAM 구성이 업데이트되어 일반적으로 /etc/pam.d/system-auth 및 /etc/pam.d/password-auth 파일에서 SSSD 모듈을 참조합니다. 예를 들어 다음과 같습니다.

  [... file truncated ...]authrequiredpam_env.soauthsufficientpam_unix.so nullok try_first_passauthrequisitepam_succeed_if.so uid >= 500 quietauth sufficientpam_sss.so use_first_passauthrequiredpam_deny.so[... file truncated ...]

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. [sssd] 섹션에서 PAM이 SSSD와 함께 작동하는 서비스 중 하나로 나열되어 있는지 확인합니다.

   [sssd][... file truncated ...]services = nss, pam

3. [pam] 섹션에서 SSSD가 PAM과 상호 작용하는 방법을 구성합니다. 예를 들어 다음과 같습니다.

   [pam]offline_credentials_expiration = 2offline_failed_login_attempts = 3offline_failed_login_delay = 5

   사용 가능한 옵션의 전체 목록은 sssd.conf(5) 도움말 페이지의 PAM 구성 옵션을 참조하십시오.

4. SSSD를 다시 시작합니다.

   # systemctl restart sssd.service

• 사용자로 로그인해 봅니다.

• sssctl user-checks user_name auth 명령을 사용하여 SSSD 구성을 확인합니다. 자세한 내용은 sssctl user-checks --help 명령을 사용합니다.

mount 유틸리티는 시스템 리소스를 절약하기 위해 자동으로 NFS 파일 시스템을 마운트 및 마운트 해제할 수 있습니다. 에 대한 자세한 내용은 스토리지 관리 가이드의 내용을 참조하십시오. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/storage_administration_guide/index#nfs-autofs

1. 사용자가 디렉토리를 마운트하려고 하면 SSSD에서 LDAP에 연결하여 현재 meta2 구성에 대한 필요한 정보를 가져옵니다.

2. SSSD는 LDAP 서버가 오프라인 상태인 경우에도 사용자가 디렉토리를 마운트할 수 있도록 캐시에 필요한 정보를 저장합니다.

1. autofs 패키지를 설치합니다.

   # yum install autofs

2. /etc/nsswitch.conf 파일을 엽니다.

3. lines 에서 ldap 에서 sss 로 map 정보를 찾을 위치를 변경합니다.

   automount: files sss

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. [sssd] 섹션에서 SSSD가 관리하는 서비스 목록에 Cryostat를 추가합니다.

   [sssd]services = nss,pam,autofs

3. 새 [autofs] 섹션을 만듭니다. 비워 둘 수 있습니다.

   [autofs]

   사용 가능한 옵션 목록은 sssd.conf(5) 도움말 페이지의 AUTOFS 구성 옵션을 참조하십시오.

4. SSSD가 LDAP에서 정보를 읽을 수 있도록 sssd.conf 에서 LDAP 도메인을 사용할 수 있는지 확인합니다. 7.3.2절. “SSSD의 LDAP 도메인 구성” 참조하십시오.

   sssd.conf 의 [domain] 섹션에는 다음과 같은 여러 가지 관련옵션을 사용할 수 있습니다. 예를 들어 다음과 같습니다.

   [domain/LDAP][... file truncated ...]autofs_provider=ldapldap_autofs_search_base=cn=automount,dc=example,dc=comldap_autofs_map_object_class=automountMapldap_autofs_entry_object_class=automountldap_autofs_map_name=automountMapNameldap_autofs_entry_key=automountKeyldap_autofs_entry_value=automountInformation

   사용 가능한 옵션의 전체 목록은 sssd.conf(5) 도움말 페이지의 DOMAINEngineTIONS 를 참조하십시오.

   추가 Cryostat 옵션을 제공하지 않으면 구성은 ID 공급자 설정에 따라 다릅니다.

5. SSSD를 다시 시작합니다.

   # systemctl restart sssd.service

• SSSD에서 맵을 인쇄하려면 -m 명령을 사용합니다.

1. 사용자가 sudo 작업을 시도하면 SSSD에서 LDAP 또는 AD에 연결하여 현재 sudo 구성에 대한 필요한 정보를 가져옵니다.

2. SSSD는 sudo 정보를 캐시에 저장하므로 사용자가 LDAP 또는 AD 서버가 오프라인 상태인 경우에도 sudo 작업을 수행할 수 있습니다.

1. /etc/nsswitch.conf 파일을 엽니다.

2. sudoers 행의 목록에 SSSD를 추가합니다.

   sudoers: files sss

1. /etc/sssd/sssd.conf 파일을 엽니다.

2. [sssd] 섹션에서 SSSD가 관리하는 서비스 목록에 sudo 를 추가합니다.

   [sssd]services = nss,pam,sudo

3. 새 [sudo] 섹션을 생성합니다. 비워 둘 수 있습니다.

   [sudo]

   사용 가능한 옵션 목록은 sssd.conf(5) 도움말 페이지의 SUDO 구성 옵션을 참조하십시오.

4. SSSD가 디렉터리에서 sudo 정보를 읽을 수 있도록 LDAP 또는 AD 도메인을 sssd.conf 에서 사용할 수 있는지 확인합니다. 자세한 내용은 다음을 참조하십시오.

   • 7.3.2절. “SSSD의 LDAP 도메인 구성”

   • Windows 통합 가이드 의 SSSD용 ID 프로바이더로 Active Directory 사용 섹션.

   LDAP 또는 AD 도메인의 [domain] 섹션에는 다음과 같은 sudo관련 매개변수가 포함되어야 합니다.

   [domain/LDAP_or_AD_domain]...sudo_provider = ldapldap_sudo_search_base = ou=sudoers,dc=example,dc=com

   참고

   ID 공급자로 Identity Management 또는 AD를 설정하면 sudo 공급자가 자동으로 활성화됩니다. 이 경우 sudo_provider 매개 변수를 지정할 필요가 없습니다.

   사용 가능한 옵션의 전체 목록은 sssd.conf(5) 도움말 페이지의 DOMAINEngineTIONS 를 참조하십시오.

   sudo 공급자에 사용할 수 있는 옵션은 sssd-ldap(5) 도움말 페이지를 참조하십시오.

5. SSSD를 다시 시작합니다.

   # systemctl restart sssd.service

1. 선택 사항입니다. 사용자 계정의 현재 UID를 표시합니다.

   # id useruid=1241400014(user_name) gid=1241400014(user_name) Groups=1241400014(user_name)

2. 계정의 UID를 6666 으로 재정의합니다.

   # sss_override user-add user -u 6666

3. 메모리 내 캐시가 만료될 때까지 기다립니다. 수동으로 만료하려면 다음을 수행합니다.

   # sss_cache --users

4. 새 UID가 적용되었는지 확인합니다.

   # id useruid=6666(user_name) gid=1241400014(user_name) Groups=1241400014(user_name)

5. 선택 사항입니다. 사용자에 대한 덮어쓰기를 표시합니다.

   # sss_override user-show useruser@ldap.example.com::6666:::::

슬퍼된 구성은 계층 구조로 구성된 LDIF 항목으로 구성되며 이러한 항목을 편집하는 권장 방법은 9.2.2.1절. “OpenLDAP 서버 유틸리티 개요” 에 설명된 서버 유틸리티를 사용하는 것입니다.

P 옵션을 사용하면 시스템 재부팅 시 이 설정이 지속됩니다. SELinux에 대한 자세한 내용은 Red Hat Enterprise Linux 7 SELinux 사용자 및 관리자 가이드를 참조하십시오.

OpenLDAP를 사용하여 인증할 시스템을 구성하려면 적절한 패키지가 LDAP 서버 및 클라이언트 시스템에 모두 설치되어 있는지 확인합니다. 서버 설정 방법에 대한 자세한 내용은 9.2.2절. “OpenLDAP 제품군 설치” 및 9.2.3절. “OpenLDAP 서버 구성” 의 지침을 따르십시오. 클라이언트의 쉘 프롬프트에서 다음을 입력합니다.

• /usr/share/doc/openldap-servers-버전/guide.html - OpenLDAP 소프트웨어 관리자 가이드의 사본 .

• /usr/share/doc/openldap-servers-버전/README.schema - 설치된 스키마 파일에 대한 설명이 포함된 README 파일입니다.

클라이언트 애플리케이션

• 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 구성 디렉터리 내에서 사용할 수 있는 형식 및 옵션을 설명합니다.

• OpenLDAP 및 Mozilla NSS 호환성 계층 구현 세부 정보 NSS 데이터베이스 이전 버전과의 호환성.

• TLS/SSL을 사용하려면 어떻게 해야 합니까? OpenSSL을 사용하도록 OpenLDAP를 구성하는 방법에 대한 정보입니다.

• auth - 이 모듈 인터페이스는 사용자를 인증합니다. 예를 들어 암호의 유효성을 요청하고 확인합니다. 이 인터페이스의 모듈은 그룹 멤버십과 같은 자격 증명을 설정할 수도 있습니다.

• account - 이 모듈 인터페이스는 액세스가 허용되는지 확인합니다. 예를 들어 사용자 계정이 만료되었는지 또는 사용자가 특정 시간에 로그인할 수 있는지 확인합니다.

• password - 이 모듈 인터페이스는 사용자 암호를 변경하는 데 사용됩니다.

• 세션 - 이 모듈 인터페이스는 사용자 세션을 구성하고 관리합니다. 이 인터페이스의 모듈은 사용자의 홈 디렉터리를 마운트하고 사용자의 사서함을 사용할 수 있도록 액세스를 허용하는 데 필요한 추가 작업도 수행할 수 있습니다.

• required - 인증을 계속하려면 모듈 결과가 성공해야 합니다. 이 시점에서 테스트가 실패하면 해당 인터페이스를 참조하는 모든 모듈의 결과가 완료될 때까지 사용자에게 알리지 않습니다.

• 필수 조건 - 모듈 결과가 인증을 계속하려면 성공해야 합니다. 그러나 이 시점에서 테스트에 실패하면 첫 번째 실패 또는 필수 모듈 테스트를 반영하는 메시지와 함께 사용자에게 즉시 알림을 받습니다.

• sufficient - 모듈 결과가 실패하는 경우 무시됩니다. 그러나 모듈 결과에 sufficient 으로 플래그가 지정되어 있고 필요한 이전 모듈이 실패한 경우 다른 결과가 필요하지 않으며 사용자가 서비스에 인증됩니다.

• 선택 사항 - 모듈 결과가 무시됩니다. 다른 모듈이 인터페이스를 참조하지 않는 경우 성공적인 인증에만 선택 옵션으로 플래그가 지정됩니다.

• include - 다른 제어와 달리 모듈 결과가 처리되는 방법과 관련이 없습니다. 이 플래그는 지정된 매개 변수와 일치하는 구성 파일의 모든 행을 가져와 모듈에 인수로 추가합니다.

• 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 를 사용하면 설정 유틸리티가 실패하지 않습니다.

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

예 10.1. 간단한 PAM 구성

#%PAM-1.0authrequiredpam_securetty.soauthrequiredpam_unix.so nullokauthrequiredpam_nologin.soaccountrequiredpam_unix.sopasswordrequiredpam_pwquality.so retry=3passwordrequiredpam_unix.so shadow nullok use_authtoksessionrequiredpam_unix.so

• 첫 번째 줄은 행 시작 부분에 해시 표시(#)로 표시된 주석입니다.

• 로그인 인증을 위해 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 에 기록합니다. 이 모듈은 추가 기능을 위해 다른 세션 모듈과 스택하여 보완할 수 있습니다.

• auth

• 세션

• timestamp_timeout: 타임스탬프 파일의 유효 기간(초)을 기본적으로 300분(five 분)으로 지정합니다.

• timestampdir: 기본적으로 /var/run/sudo/ )로 타임스탬프 파일이 저장되는 디렉터리를 지정합니다.

• 자세한 메시지는 verbose 또는 debug 를 사용할 수도 있습니다.

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

• 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

  다른 모든 메서드는 명령이 실행된 PTY에서 자격 증명만 제거합니다.

그림 11.1. Kerberos 인증

• 영구 KEYRING ccache 유형, Red Hat Enterprise Linux 7의 기본 캐시

• Red Hat Enterprise Linux 7.4 이후의 대안 옵션인 KCM(System Security Services Daemon) KCM

• 파일

• DIR

• 메모리

• 데몬은 상태를 저장하므로 Kerberos 자격 증명 캐시 갱신 또는 이전 ccache 가져오기와 같은 작업을 수행할 수 있습니다. 갱신 및 추적은 SSSD 자체에서 얻은 티켓뿐만 아니라 pam_sss.so 를 통해 로그인을 통해 얻을 수 있을 뿐만 아니라 kinit 와 같이 얻은 티켓에도 사용할 수 있습니다.

• 프로세스가 사용자 공간에서 실행되므로 커널 KEYRING과 달리 UID 이름 붙여넣기가 적용됩니다.

• 호출자의 UID와 컨테이너화된 환경에서는 모든 컨테이너에서 공유되는 커널 KEYRING 기반 캐시와 달리 KCM 서버의 진입점은 선택한 컨테이너에만 바인딩 마운트할 수 있는 UNIX 소켓입니다.

• Kerberos는 각 사용자가 신뢰할 수 있지만 신뢰할 수 없는 네트워크에서 신뢰할 수 없는 호스트를 사용하고 있다고 가정합니다. 기본 목표는 암호화되지 않은 암호가 해당 네트워크에서 전송되지 않도록 하는 것입니다. 그러나 적절한 사용자 이외의 사용자가 인증에 사용되는 티켓을 발행하는 하나의 호스트에 액세스할 수 있는 경우, KDC - 전체 Kerberos 인증 시스템이 위험합니다.

• 애플리케이션이 Kerberos 라이브러리를 사용하려면 해당 소스를 수정하여 Kerberos 라이브러리를 적절하게 호출해야 합니다. 이러한 방식으로 수정된 애플리케이션은 Kerberos 인식으로 간주됩니다. 일부 애플리케이션의 경우 애플리케이션 크기 또는 설계로 인해 문제가 될 수 있습니다. 호환되지 않는 다른 애플리케이션의 경우 서버와 클라이언트에서 통신하는 방식을 변경해야 합니다. 이 작업에도 광범위한 프로그래밍이 필요할 수 있습니다. 기본적으로 Kerberos 지원이 없는 클로즈드 소스 애플리케이션이 가장 문제가 되는 경우가 많습니다.

• Kerberos로 네트워크를 보호하려면 암호화되지 않은 암호를 전송하는 모든 클라이언트 및 서버 애플리케이션의 Kerberos 인식 버전을 사용하거나 해당 클라이언트 및 서버 애플리케이션을 사용하지 않아야 합니다.

• /etc/passwd 또는 /etc/shadow 와 같은 표준 UNIX 암호 데이터베이스에서 사용자 암호를 Kerberos 암호 데이터베이스로 마이그레이션하는 것은 번거로울 수 있습니다. 이 작업을 수행하는 자동화된 메커니즘은 없습니다. 마이그레이션 방법은 Kerberos를 배포하는 특정 방식에 따라 크게 달라질 수 있습니다. 따라서 ID 관리 기능을 사용하는 것이 좋습니다. 이 기능에는 특수화된 툴과 마이그레이션 방법이 있습니다.

Kerberos는 배포 방법에 있어 많은 유연성을 통해 구현하는 복잡한 서비스일 수 있습니다. 표11.1. “외부 Kerberos 문서” 및 표11.2. “중요한 Kerberos man 페이지” 는 Kerberos 사용에 대한 자세한 정보를 위해 가장 중요한 소스 또는 가장 유용한 소스 중 몇 가지 목록입니다.

1. KDC에 필요한 패키지를 설치합니다.

   [root@server ~]# yum install krb5-server krb5-libs krb5-workstation

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

   EXAMPLE.COM 및 example. com 의 인스턴스를 올바른 도메인 이름으로 교체하여 간단한 영역을 생성할 수 있습니다. 올바른 형식으로 대문자 및 소문자를 유지하고 KDC를 kerberos.example.com 에서 Kerberos 서버의 이름으로 변경하여 만들 수 있습니다. 관례적으로 모든 영역 이름은 대문자이며 모든 DNS 호스트 이름과 도메인 이름은 소문자가 됩니다. 이러한 구성 파일의 도움말 페이지에는 파일 형식에 대한 전체 세부 정보가 있습니다.

3. kdb5_util 유틸리티를 사용하여 데이터베이스를 생성합니다.

   [root@server ~]# kdb5_util create -s

   create 명령은 Kerberos 영역의 키를 저장하는 데이터베이스를 생성합니다. -s 인수는 마스터 서버 키가 저장되는 stash 파일을 생성합니다. 키를 읽을 stash 파일이 없는 경우 Kerberos 서버(krb5kdc)는 시작할 때마다 마스터 서버 암호(키를 다시 생성하는 데 사용할 수 있음)를 묻는 메시지를 표시합니다.

4. /var/kerberos/krb5kdc/kadm5.acl 파일을 편집합니다. 이 파일은 kadmind 에서 Kerberos 데이터베이스에 대한 관리 액세스 권한과 해당 액세스 수준을 결정하는 데 사용됩니다. 예를 들어 다음과 같습니다.

   */admin@EXAMPLE.COM*

   대부분의 사용자는 데이터베이스에 단일 주체(예: 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"

6. 다음 명령을 사용하여 Kerberos를 시작합니다.

   [root@server ~]# systemctl start krb5kdc.service[root@server ~]# systemctl start kadmin.service

7. kadmin. kadmin 및 kadmin.local에서 addprinc 명령을 사용하여 사용자의 주체를 추가합니다. kadmin.local 은 KDC에 대한 명령줄 인터페이스입니다. 따라서 addprinc 와 같은 많은 명령을 kadmin 프로그램을 시작한 후 사용할 수 있습니다. 자세한 내용은 kadmin 도움말 페이지를 참조하십시오.

8. KDC에서 티켓을 발행하고 있는지 확인합니다. 먼저 kinit 를 실행하여 티켓을 가져와서 인증 정보 캐시 파일에 저장합니다. 다음으로 klist 를 사용하여 캐시의 인증 정보 목록을 보고 kdestroy 를 사용하여 포함된 캐시 및 인증 정보를 삭제합니다.

   참고

   기본적으로 kinit 는 Kerberos 서버가 아닌 동일한 시스템 로그인 사용자 이름을 사용하여 인증을 시도합니다. 해당 사용자 이름이 Kerberos 데이터베이스의 주체에 해당하지 않으면 kinit 에서 오류 메시지를 발행합니다. 이 경우 명령줄에서 인수로 올바른 주체 이름을 kinit 에 제공합니다.

   kinit principal

1. KDC에 필요한 패키지를 설치합니다.

   [root@slavekdc ~]# yum install krb5-server krb5-libs krb5-workstation

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.comPrincipal "host/masterkdc.example.com@EXAMPLE.COM" created.kadmin: ktadd host/masterkdc.example.comEntry 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

   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.COMAuthenticating as principal jsmith/admin@EXAMPLE.COM with password.Password for jsmith/admin@EXAMPLE.COM:kadmin: add_principal -randkey host/slavekdc.example.comPrincipal "host/slavekdc.example.com@EXAMPLE.COM" created.kadmin: ktadd host/slavekdc.example.com@EXAMPLE.COMEntry 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

   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

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

10. kprop 명령을 사용하여 콘텐츠를 보조 KDC로 전송합니다.

    [root@masterkdc ~]# kprop slavekdc.example.com

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 }

12. realm 데이터베이스를 덤프하고 kprop 명령을 실행하여 데이터베이스를 차례로 각 보조 KDC로 전송하는 스크립트를 생성하고 주기적으로 스크립트를 실행하도록 cron 서비스를 구성합니다.

예 11.1. KKDCP 서버 구성 I

예 11.2. KKDCP 서버 II 구성

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}

2. /etc/sssd/sssd.conf 파일을 열고 krb5_use_kdcinfo = False 행을 IdM 도메인 섹션에 추가합니다.

   [domain/example.com]krb5_use_kdcinfo = False

3. SSSD 서비스를 다시 시작하십시오.

   # systemctl restart sssd.service

• Active Directory 영역에 대한 KKDCP 구성에 대한 자세한 내용은 Red Hat Knowledgebase의 AD Kerberos 통신에 대한 KDC 프록시로 IPA 서버 구성을 참조하십시오.

그림 11.2. 기본 신뢰

• 두 영역에 모두 존재합니다.

• 키가 생성되면 두 영역에서 동일한 암호가 사용됩니다.

• 키의 키 버전 번호(kvno)가 같습니다.

그림 11.3. 전향적인 신뢰

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

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

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

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의 서비스 주체에 대한 티켓을 요청합니다.