Windows Active Directory와 직접 RHEL 시스템 통합


Red Hat Enterprise Linux 10

RHEL 호스트를 AD에 가입하고 AD의 리소스에 액세스

Red Hat Customer Content Services

초록

SSSD(System Security Services Daemon) 또는 Samba Winbind 서비스를 사용하여 AD 리소스에 액세스하여 RHEL(Red Hat Enterprise Linux) 호스트를 AD(Active Directory) 도메인에 연결할 수 있습니다. 또는 MSA(Managed Service Account)를 사용하여 도메인 통합 없이 AD 리소스에 액세스할 수도 있습니다.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.

Jira를 통해 피드백 제출 (계정 필요)

  1. Jira 웹 사이트에 로그인합니다.
  2. 상단 탐색 바에서 생성을 클릭합니다.
  3. 요약 필드에 설명 제목을 입력합니다.
  4. 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
  5. 대화 상자 하단에서 생성 을 클릭합니다.

1장. SSSD를 사용하여 RHEL 시스템을 AD에 직접 연결

SSSD(System Security Services Daemon)는 RHEL(Red Hat Enterprise Linux) 시스템을 AD(Active Directory)와 연결하는 데 권장되는 구성 요소입니다. SSSD의 기본값인 POSIX ID 매핑을 사용하거나 AD에 정의된 POSIX 특성을 사용하여 AD와 직접 통합할 수 있습니다.

중요

RHEL 시스템을 AD(Active Directory)에 연결하려면 다음을 사용합니다.

  • ID 및 인증을 위한 SSSD(System Security Services Daemon)
  • 사용 가능한 도메인을 감지하고 기본 RHEL 시스템 서비스를 구성하는 realmd 입니다.

1.1. SSSD를 사용한 직접 통합 개요

SSSD를 사용하여 오프라인 로그인을 허용하도록 사용자 캐싱이 있는 공통 프레임워크를 통해 인증 및 권한 부여를 위해 사용자 디렉터리에 액세스합니다. SSSD는 구성할 수 있습니다. PAM(Pluggable Authentication Modules) 및 NSS(Name Switch Service) 통합 및 로컬 사용자를 저장하는 데이터베이스 및 중앙 서버에서 검색된 확장 사용자 데이터를 제공합니다. SSSD는 다음 유형의 ID 서버 중 하나로 RHEL 시스템을 연결하는 데 권장되는 구성 요소입니다.

  • Active Directory
  • RHEL의 IdM(Identity Management)
  • 일반 LDAP 또는 Kerberos 서버
참고

SSSD와의 직접 통합은 기본적으로 단일 AD 포리스트 내에서만 작동합니다.

Linux 시스템을 AD와 직접 통합하도록 SSSD를 구성하는 가장 편리한 방법은 realmd 서비스를 사용하는 것입니다. 호출자가 표준 방식으로 네트워크 인증 및 도메인 멤버십을 구성할 수 있도록 허용합니다. realmd 서비스는 액세스 가능한 도메인 및 영역에 대한 정보를 자동으로 검색하고 도메인 또는 영역에 가입하기 위해 고급 구성이 필요하지 않습니다.

AD와의 직접 및 간접 통합 모두에 SSSD를 사용하면 한 통합 방식에서 다른 통합 방식으로 전환할 수 있습니다. 직접 통합은 RHEL 시스템을 AD 환경에 도입하는 간단한 방법입니다. 그러나 RHEL 시스템의 공유가 증가함에 따라 배포에는 일반적으로 호스트 기반 액세스 제어, sudo 또는 SELinux 사용자 매핑과 같은 ID 관련 정책을 보다 효율적으로 관리해야 합니다. 처음에는 RHEL 시스템의 이러한 측면의 구성을 로컬 구성 파일에서 유지 관리할 수 있습니다. 그러나 시스템이 증가함에 따라 Red Hat Satellite와 같은 프로비저닝 시스템을 사용하면 구성 파일의 배포 및 관리가 더 쉬워집니다. 직접 통합이 더 이상 확장되지 않으면 간접 통합을 고려해야 합니다. 직접 통합(RHEL 클라이언트가 AD 도메인에 있음)에서 간접 통합( trust to AD로 IdM)으로 이동하는 방법에 대한 자세한 내용은 AD 도메인에서 IdM 서버로 RHEL 클라이언트 이동을 참조하십시오.

1.2. 직접 통합을 위해 지원되는 Windows 플랫폼

다음 포리스트 및 도메인 기능 수준을 사용하는 Active Directory 포리스트와 RHEL 시스템을 직접 통합할 수 있습니다.

  • 포리스트 기능 수준 범위: Windows Server 2008 - Windows Server 2016
  • 도메인 기능 수준 범위: Windows Server 2008 - Windows Server 2016

다음과 같은 지원되는 운영 체제에서 직접 통합이 테스트되었습니다.

  • Windows Server 2022 (RHEL 9.1 이상)
  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2
참고

Windows Server 2019 및 Windows Server 2022에는 새로운 기능 수준이 도입되지 않습니다. 가장 높은 기능 수준의 Windows Server 2019 및 Windows Server 2022 사용은 Windows Server 2016입니다.

1.3. AD와 통합하기 위한 옵션: POSIX ID 매핑 또는 POSIX 속성 사용

Linux 및 Windows 시스템은 사용자와 그룹에 대해 서로 다른 식별자를 사용합니다.

  • Linux는 UID( 사용자 ID ) 및 그룹 ID (GID)를 사용합니다. 기본 시스템 설정 구성에서 사용자 및 그룹 계정 관리 소개 참조하십시오. Linux UID 및 GID는 POSIX 표준을 준수합니다.
  • Windows에서는 SID( 보안 ID )를 사용합니다.
중요

RHEL 시스템을 AD에 연결한 후 AD 사용자 이름과 암호로 인증할 수 있습니다. 중복 이름으로 인해 충돌이 발생하여 인증 프로세스가 중단될 수 있으므로 Windows 사용자와 동일한 이름의 Linux 사용자를 생성하지 마십시오.

AD 사용자로 RHEL 시스템에 인증하려면 UID 및 GID가 할당되어 있어야 합니다. SSSD는 AD에서 POSIX ID 매핑 또는 POSIX 속성을 사용하여 AD와 통합할 수 있는 옵션을 제공합니다. 기본값은 POSIX ID 매핑을 사용하는 것입니다.

1.4. POSIX ID 매핑을 사용하여 AD에 연결

SSSD는 AD 사용자의 SID를 사용하여 POSIX ID 매핑이라는 프로세스에서 POSIX ID를 알고리즘 방식으로 생성합니다. POSIX ID 매핑은 AD의 SID와 Linux의 ID 간에 연결을 생성합니다.

  • SSSD가 새 AD 도메인을 감지하면 사용 가능한 ID 범위를 새 도메인에 할당합니다.
  • AD 사용자가 처음으로 SSSD 클라이언트 시스템에 로그인하면 SSSD는 사용자의 SID 및 해당 도메인의 ID 범위를 기반으로 UID를 포함하여 SSSD 캐시에서 사용자에 대한 항목을 만듭니다.
  • AD 사용자의 ID가 동일한 SID에서 일관된 방식으로 생성되므로 사용자는 RHEL 시스템에 로그인할 때 UID와 GID가 동일합니다.
참고

모든 클라이언트 시스템에서 SSSD를 사용하여 SID를 Linux ID에 매핑하면 매핑이 일관되게 유지됩니다. 일부 클라이언트가 다른 소프트웨어를 사용하는 경우 다음 중 하나를 선택합니다.

  • 모든 클라이언트에서 동일한 매핑 알고리즘이 사용되는지 확인합니다.
  • AD에 정의된 명시적 POSIX 속성을 사용합니다.

자세한 내용은 sssd-ad 도움말 페이지의 ID 매핑 섹션을 참조하십시오.

1.4.1. SSSD를 사용하여 AD 도메인 검색 및 가입

다음 절차에 따라 AD 도메인을 검색하고 SSSD를 사용하여 RHEL 시스템을 해당 도메인에 연결합니다.

사전 요구 사항

프로세스

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

    # dnf install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
    Copy to Clipboard
  2. 특정 도메인에 대한 정보를 표시하려면 realm discover 을 실행하고 검색할 도메인의 이름을 추가합니다.

    # realm discover ad.example.com
    ad.example.com
      type: kerberos
      realm-name: AD.EXAMPLE.COM
      domain-name: ad.example.com
      configured: no
      server-software: active-directory
      client-software: sssd
      required-package: oddjob
      required-package: oddjob-mkhomedir
      required-package: sssd
      required-package: adcli
      required-package: samba-common
    Copy to Clipboard

    realmd 시스템은 DNS SRV 조회를 사용하여 이 도메인에서 도메인 컨트롤러를 자동으로 찾습니다.

    참고

    realmd 시스템은 Active Directory 및 Identity Management 도메인을 모두 검색할 수 있습니다. 두 도메인이 모두 환경에 있는 경우 검색 결과를 --server-software=active-directory 옵션을 사용하여 특정 유형의 서버로 제한할 수 있습니다.

  3. realm join 명령을 사용하여 로컬 RHEL 시스템을 구성합니다. realmd 제품군은 필요한 모든 구성 파일을 자동으로 편집합니다. 예를 들어 이름이 ad.example.com 인 도메인의 경우:

    # realm join ad.example.com
    Copy to Clipboard

검증

  • 관리자와 같은 AD 사용자 세부 정보를 표시합니다.

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash
    Copy to Clipboard

1.5. Active Directory에 정의된 POSIX 특성을 사용하여 AD에 연결

AD는 uidNumber,gidNumber,unixHomeDirectory 또는 loginShell 과 같은 POSIX 속성을 생성하고 저장할 수 있습니다.

POSIX ID 매핑을 사용하는 경우 SSSD는 새 UID 및 GID를 생성하여 AD에 정의된 값을 재정의합니다. AD 정의 값을 유지하려면 SSSD에서 POSIX ID 매핑을 비활성화해야 합니다.

최상의 성능을 위해 POSIX 속성을 AD 글로벌 카탈로그에 게시합니다. POSIX 속성이 글로벌 카탈로그에 없는 경우 SSSD는 LDAP 포트에서 직접 개별 도메인 컨트롤러에 연결합니다.

사전 요구 사항

프로세스

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

    # dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
    Copy to Clipboard
  2. realm join 명령을 --automatic-id-mapping=no 옵션으로 사용하여 POSIX ID 매핑이 비활성화된 로컬 RHEL 시스템을 구성합니다. realmd 제품군은 필요한 모든 구성 파일을 자동으로 편집합니다. 예를 들어 이름이 ad.example.com 인 도메인의 경우:

    # realm join --automatic-id-mapping=no ad.example.com
    Copy to Clipboard
  3. 도메인에 이미 가입한 경우 SSSD에서 POSIX ID 매핑을 수동으로 비활성화할 수 있습니다.

    1. /etc/sssd/sssd.conf 파일을 엽니다.
    2. AD domain 섹션에서 ldap_id_mapping = false 설정을 추가합니다.
    3. SSSD 캐시를 제거합니다.

      rm -f /var/lib/sss/db/*
      Copy to Clipboard
    4. SSSD를 다시 시작하십시오.

      systemctl restart sssd
      Copy to Clipboard

SSSD는 이제 로컬에서 생성하는 대신 AD의 POSIX 속성을 사용합니다.

참고

AD의 사용자에 대해 관련 POSIX 속성(uidNumber,gidNumber,unixHomeDirectory, loginShell)이 구성되어 있어야 합니다.

검증

  • 관리자와 같은 AD 사용자 세부 정보를 표시합니다.

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:10000:10000:Administrator:/home/Administrator:/bin/bash
    Copy to Clipboard

1.6. SSSD를 사용하여 다른 AD 포리스트의 여러 도메인에 연결

AD(Active Directory) Managed Service Account(MSA)를 사용하여 신뢰할 수 없는 다른 포리스트의 AD 도메인에 액세스할 수 있습니다.

관리 서비스 계정을 사용하여 AD 액세스를 참조하십시오.

1.7. AD 공급자가 동적 DNS 업데이트를 처리하는 방법

Active Directory(AD)는 시간 초과(후기) 및 비활성 레코드 제거(스케줄링)를 통해 DNS 레코드를 적극적으로 유지 관리합니다.

기본적으로 SSSD 서비스는 다음과 같은 간격으로 RHEL 클라이언트의 DNS 레코드를 새로 고칩니다.

  • ID 공급자가 온라인 상태가 될 때마다
  • RHEL 시스템이 재부팅될 때마다
  • /etc/sssd/sssd.conf 구성 파일의 dyndns_refresh_interval 옵션에 지정된 간격입니다. 기본값은 86400 초(24시간)입니다.

    참고

    dyndns_refresh_interval 옵션을 DHCP 리스와 동일한 간격으로 설정하면 IP 리스가 갱신된 후 DNS 레코드를 업데이트할 수 있습니다.

SSSD는 DNS(GSS-TSIG)용 Kerberos/GSSAPI를 사용하여 동적 DNS 업데이트를 AD 서버로 보냅니다. 즉, AD에 대한 보안 연결만 활성화해야 합니다.

1.8. AD 공급자의 동적 DNS 설정 수정

SSSD(System Security Services Daemon) 서비스는 기본적으로 AD 환경에 연결된 RHEL(Red Hat Enterprise Linux) 클라이언트의 DNS 레코드를 새로 고칩니다. 다음 절차는 이러한 간격을 조정합니다.

사전 요구 사항

  • SSSD 서비스를 사용하여 RHEL 호스트를 Active Directory 환경에 연결했습니다.
  • /etc/sssd/sssd.conf 구성 파일을 편집하려면 root 권한이 필요합니다.

프로세스

  1. 텍스트 편집기에서 /etc/sssd/sssd.conf 구성 파일을 엽니다.
  2. AD 도메인의 '' 섹션에 다음 옵션을 추가하여 DNS 레코드 새로 고침 간격을 12시간으로 설정하고, PTR 레코드 업데이트를 비활성화하고, TTL(DNS 레코드 Time To Live)을 1시간으로 설정합니다.

    [domain/ad.example.com]
    id_provider = ad
    ...
    dyndns_refresh_interval = 43200
    dyndns_update_ptr = false
    dyndns_ttl = 3600
    Copy to Clipboard
  3. /etc/sssd/sssd.conf 구성 파일을 저장하고 종료합니다.
  4. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.

    [root@client ~]# systemctl restart sssd
    Copy to Clipboard
참고

sssd.conf 파일에서 dyndns_update 옵션을 false 로 설정하여 동적 DNS 업데이트를 비활성화할 수 있습니다.

[domain/ad.example.com]
id_provider = ad
...

dyndns_update = false
Copy to Clipboard

1.9. AD 공급자가 신뢰할 수 있는 도메인을 처리하는 방법

/etc/sssd/sssd.conf 구성 파일에서 id_provider = ad 옵션을 설정하면 SSSD가 신뢰할 수 있는 도메인을 다음과 같이 처리합니다.

  • SSSD는 단일 AD 포리스트의 도메인만 지원합니다. SSSD가 여러 포리스트에서 여러 도메인에 액세스해야 하는 경우 SSSD 대신 신뢰(preferred) 또는 winbindd 서비스와 함께 IPA를 사용하는 것이 좋습니다.
  • 기본적으로 SSSD는 포리스트의 모든 도메인을 검색하고 신뢰할 수 있는 도메인의 개체에 대한 요청이 도착하면 SSSD에서 문제를 해결하려고 합니다.

    신뢰할 수 있는 도메인에 도달할 수 없거나 지리적으로 멀리 떨어져 있는 경우 /etc/sssd/sssd.conf 에서 ad_enabled_domains 매개변수를 설정하여 SSSD가 오브젝트를 확인하는 것을 제한할 수 있습니다.

  • 기본적으로 정규화된 사용자 이름을 사용하여 신뢰할 수 있는 도메인에서 사용자를 확인해야 합니다.

1.10. SSSD를 사용하여 Active Directory 사이트 자동 검색 덮어쓰기

Active Directory(AD) 포리스트는 다양한 도메인 컨트롤러, 도메인, 하위 도메인 및 물리적 사이트를 통해 매우 커질 수 있습니다. AD는 사이트의 개념을 사용하여 도메인 컨트롤러의 물리적 위치를 식별합니다. 이를 통해 클라이언트는 지리적으로 가장 가까운 도메인 컨트롤러에 연결하여 클라이언트 성능이 향상됩니다.

이 섹션에서는 SSSD에서 자동 검색을 사용하여 연결할 AD 사이트를 찾는 방법과 자동 검색을 재정의하고 사이트를 수동으로 지정하는 방법을 설명합니다.

1.10.1. SSSD에서 AD 사이트 자동 검색 처리 방법

기본적으로 SSSD 클라이언트는 자동 검색을 사용하여 AD 사이트를 찾아서 가장 가까운 도메인 컨트롤러에 연결합니다. 프로세스는 다음 단계로 구성됩니다.

  1. SSSD는 SRV 쿼리를 수행하여 도메인에서 DC(Domain Controller)를 찾습니다. SSSD는 SSSD 구성 파일의 dns_discovery_domain 또는 ad_domain 옵션에서 검색 도메인을 읽습니다.
  2. SSSD는 너무 많은 DC를 ping하지 않고 연결할 수 없는 DC의 시간 초과를 방지하기 위해 3개의 일괄 처리로 이러한 DC에 대한 Connection-Less LDAP(CLDAP) ping을 수행합니다. SSSD가 이러한 배치 중 하나에서 사이트 및 포리스트 정보를 수신하는 경우 나머지 배치를 건너뜁니다.
  3. SSSD는 사이트별 및 백업 서버 목록을 생성하고 저장합니다.

1.10.2. AD 사이트 자동 검색 덮어쓰기

자동 검색 프로세스를 재정의하려면 ad_site 옵션을 ' /etc/sssd/sssd.conf 파일의 ' 섹션에 추가하여 클라이언트가 연결할 AD 사이트를 지정합니다. 이 예제에서는 클라이언트가 ExampleSite AD 사이트에 연결하도록 구성합니다.

사전 요구 사항

  • SSSD 서비스를 사용하여 RHEL 호스트를 Active Directory 환경에 연결했습니다.
  • /etc/sssd/sssd.conf 구성 파일을 편집할 수 있도록 root 사용자로 인증할 수 있습니다.

프로세스

  1. 텍스트 편집기에서 /etc/sssd/sssd.conf 파일을 엽니다.
  2. AD 도메인의 '' 섹션에 ad_site 옵션을 추가합니다.

    [domain/ad.example.com]
    id_provider = ad
    ...
    ad_site = ExampleSite
    Copy to Clipboard
  3. /etc/sssd/sssd.conf 구성 파일을 저장하고 종료합니다.
  4. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.

    # systemctl restart sssd
    Copy to Clipboard

1.11. realm 명령

realmd 시스템에는 두 가지 주요 작업 영역이 있습니다.

  • 도메인의 시스템 등록 관리.
  • 로컬 시스템 리소스에 액세스할 수 있는 도메인 사용자를 제어합니다.

realmd 에서 명령줄 툴 영역을 사용하여 명령을 실행합니다. 대부분의 realm 명령에서는 사용자가 유틸리티에서 수행해야 하는 작업과 작업을 수행할 도메인 또는 사용자 계정과 같은 엔터티를 지정해야 합니다.

표 1.1. realmd 명령
명령설명

realm 명령

Discover

네트워크에서 도메인에 대한 검색 검사를 실행합니다.

가입

시스템을 지정된 도메인에 추가합니다.

leave

지정된 도메인에서 시스템을 제거합니다.

list

시스템 또는 모든 검색 및 구성된 도메인에 대해 구성된 모든 도메인을 나열합니다.

로그인 명령

허용

특정 사용자에 대한 액세스 또는 구성된 도메인 내의 모든 사용자에 대해 액세스를 활성화하여 로컬 시스템에 액세스합니다.

deny

특정 사용자의 액세스 또는 구성된 도메인 내의 모든 사용자에 대해 로컬 시스템에 액세스하도록 액세스를 제한합니다.

1.12. SSSD를 사용하여 RHEL 시스템을 AD로 직접 통합하는 데 필요한 포트

다음 포트가 열려 있어야 하며 AD 도메인 컨트롤러 및 RHEL 호스트에서 액세스할 수 있어야 합니다.

표 1.2. SSSD를 사용하여 Linux 시스템을 AD로 직접 통합하는 데 필요한 포트
서비스포트프로토콜참고

DNS

53

UDP 및 TCP

 

LDAP

389

UDP 및 TCP

 

LDAPS

636

TCP

선택 사항

samba

445

UDP 및 TCP

AD 그룹 정책 오브젝트(GPO)의 경우

Kerberos

88

UDP 및 TCP

 

Kerberos

464

UDP 및 TCP

kadmin 에서 암호를 설정 및 변경하는 데 사용됩니다.

LDAP 글로벌 카탈로그

3268

TCP

id_provider = ad 옵션이 사용되는 경우

LDAPS 글로벌 카탈로그

3269

TCP

선택 사항

NTP

123

UDP

선택 사항

NTP

323

UDP

선택 사항

2장. Samba Winbind를 사용하여 AD에 RHEL 시스템 직접 연결

RHEL 시스템을 AD(Active Directory)에 연결하려면 다음을 사용합니다.

  • AD ID 및 인증 소스와 상호 작용하는 Samba Winbind
  • 사용 가능한 도메인을 감지하고 기본 RHEL 시스템 서비스를 구성하는 realmd 입니다.

2.1. Samba Winbind를 사용한 직접 통합 개요

Samba Winbind는 Linux 시스템에서 Windows 클라이언트를 에뮬레이션하고 AD 서버와 통신합니다.

realmd 서비스를 사용하여 다음을 통해 Samba Winbind를 구성할 수 있습니다.

  • 표준 방식으로 네트워크 인증 및 도메인 멤버십 구성.
  • 액세스 가능한 도메인 및 영역에 대한 정보를 자동으로 검색합니다.
  • 도메인 또는 영역에 가입하기 위해 고급 구성이 필요하지 않습니다.

다음 사항에 유의하십시오.

  • 다중 포리스트 AD 설정에서 Winbind와 직접 통합하려면 양방향 신뢰가 필요합니다.
  • 원격 포리스트는 idmap_ad 플러그인이 원격 포리스트 사용자를 올바르게 처리할 수 있도록 로컬 포리스트를 신뢰해야 합니다.

Samba의 winbindd 서비스는 NSS(Name Service Switch)에 대한 인터페이스를 제공하며 도메인 사용자가 로컬 시스템에 로그인할 때 AD에 인증할 수 있습니다.

winbindd 를 사용하면 추가 소프트웨어를 설치하지 않고도 디렉터리 및 프린터를 공유하도록 구성을 향상시킬 수 있습니다.

2.2. Samba Windbind를 사용하여 AD에 RHEL 시스템 직접 연결

Samba Winbind는 RHEL(Red Hat Enterprise Linux) 시스템을 AD(Active Directory)와 연결하기 위한 SSSD(System Security Services Daemon)의 대안입니다. realmd 를 사용하여 Samba Winbind를 구성하여 RHEL 시스템을 AD 도메인에 연결할 수 있습니다.

프로세스

  1. AD에 Kerberos 인증을 위한 더 이상 사용되지 않는 RC4 암호화 유형이 필요한 경우 RHEL에서 이러한 암호에 대한 지원을 활성화합니다.

    # update-crypto-policies --set DEFAULT:AD-SUPPORT
    Copy to Clipboard
  2. 다음 패키지를 설치합니다.

    # dnf install realmd oddjob-mkhomedir oddjob samba-winbind-clients \
           samba-winbind samba-common-tools samba-winbind-krb5-locator krb5-workstation
    Copy to Clipboard
  3. 도메인 구성원에서 디렉터리 또는 프린터를 공유하려면 samba 패키지를 설치합니다.

    # dnf install samba
    Copy to Clipboard
  4. 기존 /etc/samba/smb.conf Samba 구성 파일을 백업합니다.

    # mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
    Copy to Clipboard
  5. 도메인에 가입합니다. 예를 들어 ad.example.com이라는 도메인에 가입하려면 다음을 수행합니다.

    # realm join --membership-software=samba --client-software=winbind ad.example.com
    Copy to Clipboard

    이전 명령을 사용하면 realm 유틸리티가 자동으로 수행됩니다.

    • ad.example.com 도메인 멤버십에 대한 /etc/samba/smb.conf 파일을 만듭니다.
    • 사용자 및 그룹 조회에 대한 winbind 모듈을 /etc/nsswitch.conf 파일에 추가합니다.
    • /etc/pam.d/ 디렉토리에서 PAM(Pluggable Authentication Module) 구성 파일을 업데이트합니다.
    • winbind 서비스를 시작하고 시스템이 부팅될 때 서비스가 시작됩니다.
  6. 선택 사항: /etc/samba/smb.conf 파일에서 대체 ID 매핑 백엔드 또는 사용자 지정 ID 매핑 설정을 설정합니다.

    자세한 내용은 Samba ID 매핑 이해 및 구성을 참조하십시오.

  7. /etc/krb5.conf 파일을 편집하고 다음 섹션을 추가합니다.

    [plugins]
        localauth = {
            module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
            enable_only = winbind
        }
    Copy to Clipboard
  8. winbind 서비스가 실행 중인지 확인합니다.

    # systemctl status winbind
    ...
       Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago
    Copy to Clipboard
    중요

    Samba를 활성화하여 도메인 사용자 및 그룹 정보를 쿼리하려면 smb 를 시작하기 전에 winbind 서비스를 실행해야 합니다.

  9. 디렉터리 및 프린터를 공유하는 samba 패키지를 설치한 경우 smb 서비스를 활성화하고 시작합니다.

    # systemctl enable --now smb
    Copy to Clipboard

검증

  1. AD 도메인의 AD 관리자 계정과 같은 AD 사용자의 세부 정보를 표시합니다.

    # getent passwd "AD\administrator"
    AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bash
    Copy to Clipboard
  2. AD 도메인에서 도메인 사용자 그룹의 멤버를 쿼리합니다.

    # getent group "AD\Domain Users"
        AD\domain users:x:10000:user1,user2
    Copy to Clipboard
  3. 선택 사항: 파일 및 디렉터리에 대한 권한을 설정할 때 도메인 사용자 및 그룹을 사용할 수 있는지 확인합니다. 예를 들어 /srv/samba/example.txt 파일의 소유자를 AD\administrator로 설정하고 그룹을 AD\Domain Users로 설정하려면 다음을 수행합니다.

    # chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt
    Copy to Clipboard
  4. Kerberos 인증이 예상대로 작동하는지 확인합니다.

    1. AD 도메인 멤버에서 administrator@AD.EXAMPLE.COM 주체에 대한 티켓을 받습니다.

      # kinit administrator@AD.EXAMPLE.COM
      Copy to Clipboard
    2. 캐시된 Kerberos 티켓을 표시합니다.

      # klist
      Ticket cache: KCM:0
      Default principal: administrator@AD.EXAMPLE.COM
      
      Valid starting       Expires              Service principal
      01.11.2018 10:00:00  01.11.2018 20:00:00  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
              renew until 08.11.2018 05:00:00
      Copy to Clipboard
  5. 사용 가능한 도메인을 표시합니다.

    # wbinfo --all-domains
    BUILTIN
    SAMBA-SERVER
    AD
    Copy to Clipboard

3장. RHEL 시스템 역할을 사용하여 RHEL 시스템을 Active Directory에 연결

조직에서 Microsoft AD(Active Directory)를 사용하여 사용자, 그룹 및 기타 리소스를 중앙에서 관리하는 경우 RHEL(Red Hat Enterprise Linux) 호스트를 이 AD에 결합할 수 있습니다. 예를 들어 AD 사용자는 RHEL에 로그인하여 RHEL 호스트에서 인증된 AD 사용자가 서비스를 사용할 수 있도록 할 수 있습니다. ad_integration RHEL 시스템 역할을 사용하면 Red Hat Enterprise Linux 시스템을 AD(Active Directory) 도메인으로 통합을 자동화할 수 있습니다.

참고

ad_integration 역할은 IdM(Identity Management) 환경 없이 직접 AD 통합을 사용하는 배포용입니다. IdM 환경의 경우 ansible-freeipa 역할을 사용합니다.

3.1. ad_integration RHEL 시스템 역할을 사용하여 RHEL을 Active Directory 도메인에 가입

ad_integration RHEL 시스템 역할을 사용하여 RHEL을 AD(Active Directory) 도메인에 연결하는 프로세스를 자동화할 수 있습니다.

사전 요구 사항

  • 컨트롤 노드 및 관리형 노드를 준비했습니다.
  • 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
  • 관리 노드에 연결하는 데 사용하는 계정에는 sudo 권한이 있습니다.
  • 관리형 노드는 AD DNS 항목을 확인할 수 있는 DNS 서버를 사용합니다.
  • 컴퓨터에 도메인에 연결할 수 있는 권한이 있는 AD 계정의 자격 증명입니다.
  • 관리형 노드는 다음 포트를 사용하여 AD 도메인 컨트롤러에 대한 연결을 설정할 수 있습니다.

    소스 포트대상 포트프로토콜서비스

    1024 - 65535

    53

    UDP 및 TCP

    DNS

    1024 - 65535

    389

    UDP 및 TCP

    LDAP

    1024 - 65535

    636

    TCP

    LDAPS

    1024 - 65535

    88

    UDP 및 TCP

    Kerberos

    1024 - 65535

    464

    UDP 및 TCP

    Kerberos 암호 변경 요청

    1024 - 65535

    3268

    TCP

    LDAP 글로벌 카탈로그

    1024 - 65535

    3269

    TCP

    LDAPS 글로벌 카탈로그

    1024 - 65535

    123

    UDP

    NTP(시간 동기화가 활성화된 경우)

    1024 - 65535

    323

    UDP

    NTP(시간 동기화가 활성화된 경우)

프로세스

  1. 중요한 변수를 암호화된 파일에 저장합니다.

    1. 자격 증명 모음을 생성합니다.

      $ ansible-vault create ~/vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>
      Copy to Clipboard
    2. ansible-vault create 명령이 편집기를 열고 < key > : < value > 형식으로 중요한 데이터를 입력합니다.

      usr: administrator
      pwd: <password>
      Copy to Clipboard
    3. 변경 사항을 저장하고 편집기를 종료합니다. Ansible은 자격 증명 모음의 데이터를 암호화합니다.
  2. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

    ---
    - name: Active Directory integration
      hosts: managed-node-01.example.com
      vars_files:
        - ~/vault.yml
      tasks:
        - name: Join an Active Directory
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.ad_integration
          vars:
            ad_integration_user: "{{ usr }}"
            ad_integration_password: "{{ pwd }}"
            ad_integration_realm: "ad.example.com"
            ad_integration_allow_rc4_crypto: false
            ad_integration_timesync_source: "time_server.ad.example.com"
    Copy to Clipboard

    예제 플레이북에 지정된 설정은 다음과 같습니다.

    ad_integration_allow_rc4_crypto: <true|false>

    역할이 관리 노드에서 AD-SUPPORT 암호화 정책을 활성화할지 여부를 구성합니다. 기본적으로 RHEL은 약한 RC4 암호화를 지원하지 않지만 AD의 Kerberos에 RC4가 필요한 경우 ad_integration_allow_rc4_crypto: true 를 설정하여 이 암호화 유형을 활성화할 수 있습니다.

    Kerberos에서 AES 암호화를 사용하는 경우 이 변수를 생략하거나 false 로 설정합니다.

    ad_integration_timesync_source: <time_server>
    시간 동기화에 사용할 NTP 서버를 지정합니다. Kerberos는 재생 공격을 방지하기 위해 AD 도메인 컨트롤러 및 도메인 멤버 간에 동기화된 시간이 필요합니다. 이 변수를 생략하면 ad_integration 역할은 timesync RHEL 시스템 역할을 활용하여 관리 노드에서 시간 동기화를 구성하지 않습니다.

    플레이북에 사용되는 모든 변수에 대한 자세한 내용은 제어 노드의 /usr/share/ansible/roles/rhel-system-roles.ad_integration/README.md 파일을 참조하십시오.

  3. 플레이북 구문을 확인합니다.

    $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml
    Copy to Clipboard

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  4. Playbook을 실행합니다.

    $ ansible-playbook --ask-vault-pass ~/playbook.yml
    Copy to Clipboard

검증

  • 관리 노드에서 AD 사용자( 관리자 )를 로컬로 사용할 수 있는지 확인합니다.

    $ ansible managed-node-01.example.com -m command -a 'getent passwd administrator@ad.example.com'
    administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash
    Copy to Clipboard

4장. AD에 대한 직접 연결 관리

SSSD(System Security Services Daemon) 또는 Samba Winbind를 사용하여 RHEL(Red Hat Enterprise Linux) 시스템을 AD(Active Directory) 도메인에 연결하면 Kerberos 갱신, 도메인 멤버십, 사용자 액세스 권한, GPO(그룹 정책 오브젝트)와 같은 키 설정을 관리할 수 있습니다.

사전 요구 사항

  • SSSD 또는 Samba Winbind를 사용하여 RHEL 시스템을 Active Directory 도메인에 연결했습니다.

4.1. 기본 Kerberos 호스트 키탭 갱신 간격 수정

adcli 패키지가 설치된 경우 SSSD가 AD 환경에서 Kerberos 호스트 키탭 파일을 자동으로 갱신합니다. 데몬은 머신 계정 암호가 구성된 값보다 오래된 경우 매일 확인하고 필요한 경우 갱신합니다.

기본 갱신 간격은 30일입니다. 기본값을 변경하려면 이 절차의 단계를 따릅니다.

프로세스

  1. /etc/sssd/sssd.conf 파일의 AD 공급자에 다음 매개변수를 추가합니다.

    ad_maximum_machine_account_password_age = value_in_days
    Copy to Clipboard
  2. SSSD를 다시 시작하십시오.

    # systemctl restart sssd
    Copy to Clipboard
  3. 자동 Kerberos 호스트 키탭 갱신을 비활성화하려면 ad_maximum_machine_account_password_age = 0 을 설정합니다.

4.2. AD 도메인에서 RHEL 시스템 제거

AD 도메인에서 직접 AD(Active Directory)에 통합된 RHEL(Red Hat Enterprise Linux) 시스템을 제거하려면 다음 절차를 따르십시오.

사전 요구 사항

  • SSSD(System Security Services Daemon) 또는 Samba Winbind를 사용하여 RHEL 시스템을 AD에 연결했습니다.

프로세스

  1. realm leave 명령을 사용하여 ID 도메인에서 시스템을 제거합니다. 이 명령은 SSSD 및 로컬 시스템에서 도메인 구성을 제거합니다.

    # realm leave ad.example.com
    Copy to Clipboard
    참고

    클라이언트가 도메인을 벗어나면 AD는 계정을 삭제하지 않고 로컬 클라이언트 구성만 제거합니다. AD 계정을 삭제하려면 --remove 옵션을 사용하여 명령을 실행합니다. 처음에 인증 정보 없이 연결을 시도하지만 유효한 Kerberos 티켓이 없는 경우 사용자 암호를 입력하라는 메시지가 표시됩니다. Active Directory에서 계정을 삭제할 수 있는 권한이 있어야 합니다.

  2. realm leave 명령과 함께 -U 옵션을 사용하여 ID 도메인에서 시스템을 제거할 다른 사용자를 지정합니다.

    기본적으로 realm leave 명령은 기본 관리자로 실행됩니다. AD의 경우 관리자 계정을 Administrator 라고 합니다. 다른 사용자가 도메인에 가입하는 데 사용된 경우 해당 사용자로 제거를 수행해야 할 수 있습니다.

    # realm leave [ad.example.com] -U [AD.EXAMPLE.COM\user]'
    Copy to Clipboard

    명령은 먼저 자격 증명 없이 연결을 시도하지만 필요한 경우 암호를 입력하라는 메시지를 표시합니다.

검증

  • 도메인이 더 이상 구성되지 않았는지 확인합니다.

    # realm discover [ad.example.com]
    ad.example.com
        type: kerberos
        realm-name: EXAMPLE.COM
        domain-name: example.com
        configured: no
        server-software: active-directory
        client-software: sssd
        required-package: oddjob
        required-package: oddjob-mkhomedir
        required-package: sssd
        required-package: adcli
        required-package: samba-common-tools
    Copy to Clipboard

4.3. 간단한 AD 사용자 이름 확인으로 SSSD에서 도메인 확인 순서 설정

기본적으로 SSSD 서비스를 사용하여 AD에 연결된 RHEL 호스트에서 AD(Active Directory) 사용자 및 그룹을 확인하려면 ad_username@ad.example.comgroup@ad.example.com 와 같이 정규화된 사용자 이름을 지정해야 합니다.

이 절차에서는 ad_username 과 같은 짧은 이름으로 AD 사용자 및 그룹을 확인할 수 있도록 SSSD 구성에서 도메인 확인 순서를 설정합니다. 이 예제 구성은 다음과 같은 순서로 사용자와 그룹을 검색합니다.

  1. Active Directory (AD) 하위 도메인 subdomain2.ad.example.com
  2. AD 하위 도메인 subdomain1.ad.example.com
  3. AD 루트 도메인 ad.example.com

사전 요구 사항

  • SSSD 서비스를 사용하여 RHEL 호스트를 AD에 직접 연결했습니다.

프로세스

  1. 텍스트 편집기에서 /etc/sssd/sssd.conf 파일을 엽니다.
  2. 파일의 '' 섹션에 domain_resolution_order 옵션을 설정합니다.

    domain_resolution_order = subdomain2.ad.example.com, subdomain1.ad.example.com, ad.example.com
    Copy to Clipboard
  3. 파일을 저장하고 닫습니다.
  4. SSSD 서비스를 다시 시작하여 새 구성 설정을 로드합니다.

    [root@ad-client ~]# systemctl restart sssd
    Copy to Clipboard

검증

  • 짧은 이름만 사용하여 첫 번째 도메인에서 사용자의 사용자 정보를 검색할 수 있는지 확인합니다.

    [root@ad-client ~]# id <user_from_subdomain2>
    uid=1916901142(user_from_subdomain2) gid=1916900513(domain users) groups=1916900513(domain users)
    Copy to Clipboard

4.4. 도메인 사용자의 로그인 권한 관리

기본적으로 도메인 측 액세스 제어가 적용되므로 AD(Active Directory) 사용자에 대한 로그인 정책이 AD 도메인 자체에 정의되어 있습니다. 이 기본 동작은 클라이언트 측 액세스 제어가 사용되도록 재정의할 수 있습니다. 클라이언트 측 액세스 제어를 사용하면 로그인 권한이 로컬 정책에서만 정의됩니다.

도메인이 클라이언트 측 액세스 제어를 적용하는 경우 realmd 를 사용하여 해당 도메인의 사용자에 대한 기본 허용 또는 액세스 규칙을 구성할 수 있습니다.

참고

액세스 규칙은 시스템의 모든 서비스에 대한 액세스를 허용하거나 거부합니다. 특정 시스템 리소스 또는 도메인에 대해 보다 구체적인 액세스 규칙을 설정해야 합니다.

4.4.1. 도메인 내의 사용자에 대한 액세스 활성화

기본적으로 AD(Active Directory) 사용자에 대한 로그인 정책은 AD 도메인 자체에 정의됩니다. 이 기본 동작을 재정의하고 AD 도메인 내의 사용자에 대한 액세스를 활성화하도록 RHEL 호스트를 구성할 수 있습니다.

중요

영역 허용 -x 가 있는 특정 사용자에게만 거부하면서 기본적으로 모두에 대한 액세스를 허용하지 않는 것이 좋습니다. 대신, Red Hat은 모든 사용자에 대해 기본 액세스 정책을 유지 관리하지 않고 realm 허용을 사용하여 선택한 사용자에게만 액세스 권한을 부여할 것을 권장합니다.

사전 요구 사항

  • RHEL 시스템은 Active Directory 도메인의 멤버입니다.

프로세스

  1. 모든 사용자에게 액세스 권한을 부여합니다.

    # realm permit --all
    Copy to Clipboard
  2. 특정 사용자에게 액세스 권한을 부여합니다.

    $ realm permit aduser01@example.com
    $ realm permit 'AD.EXAMPLE.COM\aduser01'
    Copy to Clipboard

현재는 신뢰할 수 있는 도메인의 사용자가 아닌 기본 도메인의 사용자에게만 액세스를 허용할 수 있습니다. 이는 사용자 로그인에 도메인 이름을 포함해야 하며 SSSD는 현재 사용 가능한 하위 도메인에 대한 정보를 제공할 수 없기 때문입니다.

검증

  1. SSH를 사용하여 aduser01@example.com 사용자로 서버에 로그인합니다.

    $ ssh aduser01@example.com@server_name
    [aduser01@example.com@server_name ~]$
    Copy to Clipboard
  2. ssh 명령을 두 번 사용하여 aduser02@example.com 사용자와 동일한 서버에 액세스합니다.

    $ ssh aduser02@example.com@server_name
    Authentication failed.
    Copy to Clipboard

aduser02@example.com 사용자가 시스템에 대한 액세스를 거부하는 방법을 확인합니다. aduser01@example.com 사용자에게만 시스템에 로그인할 수 있는 권한이 부여되었습니다. 지정된 로그인 정책으로 인해 해당 Active Directory 도메인의 다른 모든 사용자가 거부됩니다.

참고

sssd.conf 파일에서 use_fully_qualified_names 를 true로 설정하면 모든 요청에서 정규화된 도메인 이름을 사용해야 합니다. 그러나 use_fully_qualified_names 를 false로 설정하면 요청에 정규화된 이름을 사용할 수 있지만 단순화된 버전만 출력에 표시됩니다.

4.4.2. 도메인 내 사용자에 대한 액세스 거부

기본적으로 AD(Active Directory) 사용자에 대한 로그인 정책은 AD 도메인 자체에 정의됩니다. 이 기본 동작을 재정의하고 AD 도메인 내의 사용자에 대한 액세스를 거부하도록 RHEL 호스트를 구성할 수 있습니다.

중요

특정 사용자 또는 그룹에 대한 액세스를 허용하는 것보다 다른 모든 사용자에게 액세스를 허용하는 것이 더 안전합니다. 따라서 영역 허용 -x 가 있는 특정 사용자에게만 거부되는 동안 기본적으로 모두에 대한 액세스를 허용하지 않는 것이 좋습니다. 대신, Red Hat은 모든 사용자에 대해 기본 액세스 정책을 유지 관리하지 않고 realm 허용을 사용하여 선택한 사용자에게만 액세스 권한을 부여할 것을 권장합니다.

사전 요구 사항

  • RHEL 시스템은 Active Directory 도메인의 멤버입니다.

프로세스

  1. 도메인 내의 모든 사용자에 대한 액세스를 거부합니다.

    # realm deny --all
    Copy to Clipboard

    이 명령은 영역 계정이 로컬 시스템에 로그인하지 못하도록 합니다. realm allow을 사용하여 특정 계정으로 로그인을 제한합니다.

  2. 도메인 사용자의 login-policydeny-any-login:으로 설정되어 있는지 확인합니다.

    [root@replica1 ~]# realm list
    example.net
      type: kerberos
      realm-name: EXAMPLE.NET
      domain-name: example.net
      configured: kerberos-member
      server-software: active-directory
      client-software: sssd
      required-package: oddjob
      required-package: oddjob-mkhomedir
      required-package: sssd
      required-package: adcli
      required-package: samba-common-tools
      login-formats: %U@example.net
      login-policy: deny-any-login
    Copy to Clipboard
  3. -x 옵션을 사용하여 특정 사용자에 대한 액세스를 거부합니다.

    $ realm permit -x 'AD.EXAMPLE.COM\aduser02'
    Copy to Clipboard

검증

  • SSH를 사용하여 aduser01@example.net 사용자로 서버에 로그인합니다.

    $ ssh aduser01@example.net@server_name
    Authentication failed.
    Copy to Clipboard
참고

sssd.conf 파일에서 use_fully_qualified_names 를 true로 설정하면 모든 요청에서 정규화된 도메인 이름을 사용해야 합니다. 그러나 use_fully_qualified_names 를 false로 설정하면 요청에 정규화된 이름을 사용할 수 있지만 단순화된 버전만 출력에 표시됩니다.

4.5. RHEL에서 그룹 정책 오브젝트 액세스 제어 적용

그룹 정책 개체(GPO)는 AD(Microsoft Active Directory)에 저장된 액세스 제어 설정 컬렉션입니다.A Group Policy Object (GPO) is a collection of access control settings stored in Microsoft Active Directory (AD) that can apply to computers and users in an AD environment. AD에 GPO를 지정하면 관리자는 AD에 연결된 Windows 클라이언트와 RHEL(Red Hat Enterprise Linux) 호스트 둘 다에서 적용되는 로그인 정책을 정의할 수 있습니다.

4.5.1. SSSD가 GPO 액세스 제어 규칙을 해석하는 방법

기본적으로 SSSD는 AD(Active Directory) 도메인 컨트롤러에서 그룹 정책 오브젝트(GPO)를 검색하고 이를 평가하여 사용자가 AD에 연결된 특정 RHEL 호스트에 로그인할 수 있는지 확인합니다.

SSSD는 AD Windows Logon 권한을 PAM(Pluggable Authentication Module) 서비스 이름에 매핑하여 GNU/Linux 환경에서 이러한 권한을 적용합니다.

AD 관리자는 보안 필터에 나열하여 GPO 규칙의 범위를 특정 사용자, 그룹 또는 호스트로 제한할 수 있습니다.

그룹별 필터링 제한

SSSD는 현재 SID(Security Identifier) S-1-5-32-544 와 같은 Active Directory의 내장 그룹을 지원하지 않습니다. Red Hat은 RHEL 호스트를 대상으로 하는 AD GPO에서 AD 기본 제공 그룹을 사용하지 않는 것이 좋습니다.

4.5.2. SSSD에서 지원하는 GPO 설정 목록

다음 표에서는 Windows의 그룹 정책 관리 편집기 에 지정된 대로 Active Directory GPO 옵션에 해당하는 SSSD 옵션을 보여줍니다.

표 4.1. SSSD에서 검색한 GPO 액세스 제어 옵션
GPO 옵션해당 sssd.conf 옵션

로컬에서 로그 허용
로컬에서 로그 거부

ad_gpo_map_interactive

Remote Desktop Services
Deny log on through Remote Desktop Services를 통해 로그인 허용

ad_gpo_map_remote_interactive

네트워크에서 이 컴퓨터에 액세스
네트워크에서 이 컴퓨터에 대한 액세스 거부

ad_gpo_map_network

배치 작업으로 로그온 허용
배치 작업으로 로그 거부

ad_gpo_map_batch

Allow log on as a service
Deny log on as a service

ad_gpo_map_service

4.5.3. GPO 적용을 제어하는 SSSD 옵션 목록

다음 SSSD 옵션을 설정하여 GPO 규칙 범위를 제한할 수 있습니다.

ad_gpo_access_control 옵션

/etc/sssd/sssd.conf 파일에서 ad_gpo_access_control 옵션을 설정하여 GPO 기반 액세스 제어가 작동하는 세 가지 모드 중 하나를 선택할 수 있습니다.

표 4.2. ad_gpo_access_control 값 테이블
Value of
ad_gpo_access_control
동작

강제

GPO 기반 액세스 제어 규칙은 평가 및 적용됩니다.
RHEL 8의 기본 설정입니다.

허용

GPO 기반 액세스 제어 규칙은 평가되지만 적용되지 않습니다. 액세스 권한이 거부될 때마다 syslog 메시지가 기록됩니다. 이는 RHEL 7의 기본 설정입니다.
이 모드는 사용자가 계속 로그인할 수 있도록 하는 동안 정책 조정을 테스트하는 데 이상적입니다.

비활성화됨

GPO 기반 액세스 제어 규칙은 평가되거나 적용되지 않습니다.

ad_gpo_implicit_deny 옵션

ad_gpo_implicit_deny 옵션은 기본적으로 False 로 설정됩니다. 이 기본 상태에서 해당 GPO를 찾을 수 없는 경우 사용자가 액세스할 수 있습니다. 이 옵션을 True 로 설정하는 경우 GPO 규칙을 사용하여 사용자를 명시적으로 허용해야 합니다.

이 기능을 사용하여 보안을 강화할 수 있지만 의도하지 않게 액세스를 거부하지 않도록 주의하십시오. ad_gpo_access_control허용 으로 설정된 동안 이 기능을 테스트하는 것이 좋습니다.

다음 두 표는 AD 서버 측에 정의된 허용 및 거부 로그인 권한 및 ad_gpo_implicit_deny 값을 기반으로 사용자가 허용되거나 거부되는 경우를 보여줍니다.

표 4.3. ad_gpo_implicit_deny 를 False 로 설정하여 로그인 동작 (기본값)
allow-rulesdeny-rules결과

누락됨

누락됨

모든 사용자가 허용

누락됨

현재

deny-rules에 없는 사용자만 허용됩니다.

현재

누락됨

allow-rules의 사용자만 허용됩니다.

현재

현재

allow-rules 및 deny-rules에 없는 사용자만 허용됩니다.

표 4.4. ad_gpo_implicit_deny 를 True로 설정하여 로그인 동작
allow-rulesdeny-rules결과

누락됨

누락됨

사용자가 허용되지 않음

누락됨

현재

사용자가 허용되지 않음

현재

누락됨

allow-rules의 사용자만 허용됩니다.

현재

현재

allow-rules 및 deny-rules에 없는 사용자만 허용됩니다.

4.5.4. GPO 액세스 제어 모드 변경

다음 절차에서는 AD(Active Directory) 환경에 연결된 RHEL 호스트에서 GPO 기반 액세스 제어 규칙을 평가하고 적용하는 방식을 변경합니다.

이 예제에서는 GPO 작업 모드를 테스트 목적으로 강제 (기본값)에서 허용 으로 변경합니다.

중요

다음 오류가 표시되면 GPO 기반 액세스 제어로 인해 Active Directory 사용자가 로그인할 수 없습니다.

  • /var/log/secure 에서 :

    Oct 31 03:00:13 client1 sshd[124914]: pam_sss(sshd:account): Access denied for user aduser1: 6 (Permission denied)
    Oct 31 03:00:13 client1 sshd[124914]: Failed password for aduser1 from 127.0.0.1 port 60509 ssh2
    Oct 31 03:00:13 client1 sshd[124914]: fatal: Access denied for user aduser1 by PAM account configuration [preauth]
    Copy to Clipboard
  • In /var/log/sssd/sssd__example.com_.log:

    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_perform_hbac_processing] (0x0040): GPO access check failed: [1432158236](Host Access Denied)
    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_cse_done] (0x0040): HBAC processing failed: [1432158236](Host Access Denied}
    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
    Copy to Clipboard

이 동작이 바람직하지 않은 동작인 경우 AD의 적절한 GPO 설정 문제를 해결하는 동안 이 절차에 설명된 대로 ad_gpo_access_control허용 으로 일시적으로 설정할 수 있습니다.

사전 요구 사항

  • SSSD를 사용하여 AD 환경에 RHEL 호스트에 가입했습니다.
  • /etc/sssd/sssd.conf 구성 파일을 편집하려면 root 권한이 필요합니다.

프로세스

  1. SSSD 서비스를 중지합니다.

    [root@server ~]# systemctl stop sssd
    Copy to Clipboard
  2. 텍스트 편집기에서 /etc/sssd/sssd.conf 파일을 엽니다.
  3. AD 도메인의 domain 섹션에서 ad_gpo_access_control허용 으로 설정합니다.

    [domain/example.com]
    ad_gpo_access_control=permissive
    ...
    Copy to Clipboard
  4. /etc/sssd/sssd.conf 파일을 저장합니다.
  5. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.

    [root@server ~]# systemctl restart sssd
    Copy to Clipboard

4.5.5. AD GUI에서 RHEL 호스트에 대한 GPO 생성 및 구성

그룹 정책 개체(GPO)는 AD(Microsoft Active Directory)에 저장된 액세스 제어 설정 컬렉션입니다.A Group Policy Object (GPO) is a collection of access control settings stored in Microsoft Active Directory (AD) that can apply to computers and users in an AD environment. 다음 절차에서는 AD GUI(그래픽 사용자 인터페이스)에 GPO를 생성하여 AD 도메인에 직접 통합된 RHEL 호스트에 대한 로그인 액세스를 제어합니다.

사전 요구 사항

  • SSSD를 사용하여 AD 환경에 RHEL 호스트에 가입했습니다.
  • GUI를 사용하여 AD 관리자 권한을 사용하여 AD를 변경할 수 있습니다.

프로세스

  1. Active Directory 사용자 및 컴퓨터에서 새 GPO와 연결할 조직 단위(OU)를 생성합니다.

    1. 도메인을 마우스 오른쪽 버튼으로 클릭합니다.
    2. 새로 만들기를 선택합니다.
    3. 조직 단위 를 선택합니다.
  2. RHEL 호스트를 나타내는 Computer Object의 이름을 클릭하고 (Active Directory에 가입했을 때 생성됨) 새 OU로 드래그합니다. 자체 OU에 RHEL 호스트를 사용하면 GPO가 이 호스트를 대상으로 합니다.
  3. 그룹 정책 관리 편집기에서 생성한 OU에 대한 새 GPO를 만듭니다.

    1. Forest 를 확장합니다.
    2. 도메인 을 확장합니다.
    3. 도메인을 확장합니다.
    4. 새 OU를 마우스 오른쪽 버튼으로 클릭합니다.
    5. 이 도메인에서 GPO 만들기를 선택합니다.
  4. SSH 액세스 허용 또는 콘솔/GUI 액세스 허용 과 같은 새 GPO의 이름을 지정하고 확인을 클릭합니다.
  5. 새 GPO를 편집합니다.

    1. 그룹 정책 관리 편집기에서 OU를 선택합니다.
    2. 마우스 오른쪽 버튼으로 클릭하고 편집을 선택합니다.
    3. 사용자 권한 할당 을 선택합니다.
    4. 컴퓨터 구성 을 선택합니다.
    5. Policies 를 선택합니다.
    6. Windows 설정을 선택합니다.
    7. 보안 설정을 선택합니다.
    8. 로컬 정책을 선택합니다.
    9. 사용자 권한 할당 을 선택합니다.
  6. 로그인 권한 할당:

    1. 로컬에서 로그를 두 번 클릭하여 로컬 콘솔/GUI 액세스 권한을 부여합니다.
    2. 원격 데스크탑 서비스를 통한 로그 허용을 두 번 클릭하여 SSH 액세스 권한을 부여합니다.
  7. 다음 정책 중 하나에 액세스하려는 사용자를 정책 자체에 추가합니다.

    1. 사용자 또는 그룹 추가를 클릭합니다.
    2. 빈 필드에 사용자 이름을 입력합니다.
    3. OK를 클릭합니다.

5장. 관리 서비스 계정으로 AD 액세스

Active Directory (AD) Managed Service Accounts (MSAs)를 사용하면 AD에서 특정 컴퓨터에 해당하는 계정을 만들 수 있습니다. MSA를 사용하여 RHEL 호스트를 AD 도메인에 가입하지 않고도 AD 리소스에 특정 사용자 주체로 연결할 수 있습니다.

5.1. 관리형 서비스 계정의 이점

RHEL 호스트가 Active Directory(AD) 도메인에 가입하지 않고 액세스하도록 허용하려면 MSA(Managed Service Account)를 사용하여 해당 도메인에 액세스할 수 있습니다. MSA는 AD의 계정이며 특정 사용자 주체로 AD 리소스에 연결하는 데 사용할 수 있습니다.

예를 들어 AD 도메인 production.example.comlab.example.com AD 도메인과의 단방향 신뢰 관계가 있는 경우 다음 조건이 적용됩니다.

  • 도메인은 production 도메인에서 사용자와 호스트를 신뢰합니다.
  • production 도메인은 도메인의 사용자와 호스트를 신뢰하지 않습니다.

즉, client. lab.example.com 과 같은 랩 도메인에 연결된 호스트는 신뢰로 프로덕션 도메인의 리소스에 액세스할 수 없습니다.

client.lab.example.com 호스트에 대한 예외를 생성하려면 adcli 유틸리티를 사용하여 production.example.com 도메인에 클라이언트 호스트에 대한 MSA를 생성할 수 있습니다. MSA의 Kerberos 주체로 인증하면 클라이언트 호스트의 production 도메인에서 보안 LDAP 검색을 수행할 수 있습니다.

5.2. RHEL 호스트의 관리형 서비스 계정 구성

이 절차에서는 lab.example.com AD(Active Directory) 도메인에서 호스트에 대한 MSA(관리 서비스 계정)를 생성하고 production.example.com AD 도메인에 액세스하고 인증할 수 있도록 SSSD를 구성합니다.

참고

RHEL 호스트에서 AD 리소스에 액세스해야 하는 경우 realm 명령을 사용하여 RHEL 호스트를 AD 도메인에 연결하는 것이 좋습니다. SSSD를 사용하여 RHEL 시스템을 AD에 직접 연결을 참조하십시오.

다음 조건 중 하나가 적용되는 경우에만 이 절차를 수행합니다.

  • RHEL 호스트를 AD 도메인에 연결할 수 없으며 AD에서 해당 호스트에 대한 계정을 생성하려고 합니다.
  • RHEL 호스트를 AD 도메인에 가입했으며 가입한 도메인의 호스트 자격 증명이 유효하지 않은 다른 AD 도메인에 액세스해야 합니다(예: 단방향 신뢰 사용).

사전 요구 사항

  • RHEL 호스트의 다음 포트가 열려 있고 AD 도메인 컨트롤러에서 액세스할 수 있는지 확인합니다.

    서비스포트프로토콜

    DNS

    53

    TCP, UDP

    LDAP

    389

    TCP, UDP

    LDAPS(선택 사항)

    636

    TCP, UDP

    Kerberos

    88

    TCP, UDP

  • production.example.com 도메인에서 MSAs를 생성할 수 있는 권한이 있는 AD 관리자의 암호가 있습니다.
  • adcli 명령을 실행하고 /etc/sssd/sssd.conf 구성 파일을 수정하는 데 필요한 root 권한이 있습니다.
  • 선택 사항: klist 진단 유틸리티를 포함하는 krb5-workstation 패키지가 설치되어 있습니다.

프로세스

  1. production.example.com AD 도메인에 호스트에 대한 MSA를 생성합니다.

    [root@client ~]# adcli create-msa --domain=production.example.com
    Copy to Clipboard
  2. 생성된 Kerberos 키탭에서 MSA에 대한 정보를 표시합니다. MSA 이름을 기록해 둡니다.

    [root@client ~]# klist -k /etc/krb5.keytab.production.example.com
    Keytab name: FILE:/etc/krb5.keytab.production.example.com
    KVNO Principal
    ---- ------------------------------------------------------------
       2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
    Copy to Clipboard
  3. /etc/sssd/sssd.conf 파일을 열고 추가할 적절한 SSSD 도메인 구성을 선택합니다.

    • MSA가 다른 포리스트의 AD 도메인에 해당하는 경우 [domain /<name_of_domain>] 이라는 새 도메인 섹션을 생성하고 MSA 및 keytab에 대한 정보를 입력합니다. 가장 중요한 옵션은 ldap_sasl_authid,ldap_krb5_keytab, krb5_keytab:입니다.

      [domain/production.example.com]
      ldap_sasl_authid = CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
      ldap_krb5_keytab = /etc/krb5.keytab.production.example.com
      krb5_keytab = /etc/krb5.keytab.production.example.com
      ad_domain = production.example.com
      krb5_realm = PRODUCTION.EXAMPLE.COM
      access_provider = ad
      ...
      Copy to Clipboard
      주의

      기존의 신뢰 관계가 있더라도 sssd-ad 에는 두 번째 포리스트의 MSA가 필요합니다.

    • MSA가 로컬 포리스트의 AD 도메인에 해당하는 경우 [domain /root.example.com/sub-domain.example.com] 형식으로 새 하위 도메인 섹션을 생성하고 MSA 및 keytab에 대한 정보를 입력합니다. 가장 중요한 옵션은 ldap_sasl_authid,ldap_krb5_keytab, krb5_keytab:입니다.

      [domain/ad.example.com/production.example.com]
      ldap_sasl_authid = CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
      ldap_krb5_keytab = /etc/krb5.keytab.production.example.com
      krb5_keytab = /etc/krb5.keytab.production.example.com
      ad_domain = production.example.com
      krb5_realm = PRODUCTION.EXAMPLE.COM
      access_provider = ad
      ...
      Copy to Clipboard

검증

  • MSA로 Kerberos 티켓(TGT)을 검색할 수 있는지 확인합니다.

    [root@client ~]# kinit -k -t /etc/krb5.keytab.production.example.com 'CLIENT!S3A$'
    [root@client ~]# klist
    Ticket cache: KCM:0:54655
    Default principal: CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    11/22/2021 15:48:03  11/23/2021 15:48:03  krbtgt/PRODUCTION.EXAMPLE.COM@PRODUCTION.EXAMPLE.COM
    Copy to Clipboard
  • AD에서 관리 서비스 계정 조직 단위(OU)에 호스트에 대한 MSA가 있는지 확인합니다.

5.3. 관리 서비스 계정의 암호 업데이트

MSA(관리 서비스 계정)에는 AD(Active Directory)에서 자동으로 유지 관리하는 복잡한 암호가 있습니다. 기본적으로 SSSD(System Services Security Daemon)는 30일이 지난 경우 Kerberos 키탭에서 MSA 암호를 자동으로 업데이트하여 AD의 암호를 사용하여 최신 상태로 유지합니다. 다음 절차에서는 MSA의 암호를 수동으로 업데이트하는 방법을 설명합니다.

사전 요구 사항

  • 이전에 production.example.com AD 도메인에 호스트에 대한 MSA를 생성했습니다.
  • 선택 사항: klist 진단 유틸리티를 포함하는 krb5-workstation 패키지가 설치되어 있습니다.

프로세스

  1. 선택 사항: Kerberos 키 탭에서 MSA의 현재 키 버전 번호(KVNO)를 표시합니다. 현재 KVNO는 2입니다.

    [root@client ~]# klist -k /etc/krb5.keytab.production.example.com
    Keytab name: FILE:/etc/krb5.keytab.production.example.com
    KVNO Principal
    ---- ------------------------------------------------------------
       2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
    Copy to Clipboard
  2. production.example.com AD 도메인에서 MSA의 암호를 업데이트합니다.

    [root@client ~]# adcli update --domain=production.example.com --host-keytab=/etc/krb5.keytab.production.example.com --computer-password-lifetime=0
    Copy to Clipboard

검증

  • Kerberos 키탭에서 KVNO가 증가했는지 확인합니다.

    [root@client ~]# klist -k /etc/krb5.keytab.production.example.com
    Keytab name: FILE:/etc/krb5.keytab.production.example.com
    KVNO Principal
    ---- ------------------------------------------------------------
       3 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       3 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
    Copy to Clipboard

5.4. 관리형 서비스 계정 사양

adcli 유틸리티에서 생성하는 관리 서비스 계정(MSAs)에는 다음과 같은 사양이 있습니다.

  • 추가 서비스 주체 이름(SPN)이 있을 수 없습니다.
  • 기본적으로 MSA의 Kerberos 주체는 /etc/krb5.production.example.com과 같이 < default_keytab_location>.<Active_Directory_domain > 이라는 Kerberos keytab 에 저장됩니다.
  • 이름은 20자 이하로 제한됩니다. 마지막 4 문자는 구분 기호를 사용하여 제공하는 짧은 호스트 이름에 추가되는 숫자 및 대문자에서 3개의 임의 문자의 접미사입니다. 예를 들어, 짧은 이름 myhost 가 있는 호스트는 다음 사양을 사용하여 MSA를 수신합니다.

    사양현재의

    CN(일반 이름) 속성

    myhost!A2c

    NetBIOS 이름

    myhost!A2c$

    sAMAccountName

    myhost!A2c$

    production.example.com AD 도메인의 Kerberos 주체

    myhost!A2c$@PRODUCTION.EXAMPLE.COM

5.5. adcli create-msa 명령의 옵션

adcli 유틸리티에 전달할 수 있는 글로벌 옵션 외에도 다음 옵션을 지정하여 MSAs(Managed Service Accounts)를 처리하는 방법을 구체적으로 제어할 수 있습니다.

-N, --computer-name
Active Directory (AD) 도메인에서 생성될 MSA의 짧은 점화되지 않은 이름입니다. 이름을 지정하지 않으면 --host-fqdn 또는 기본값의 첫 번째 부분은 임의의 접미사와 함께 사용됩니다.
-O, --domain-ou=OU=<path_to_OU>
MSA를 생성할 OU(조직 단위)의 전체 고유 이름입니다. 이 값을 지정하지 않으면 기본 위치 OU=CN=Managed 서비스 계정,DC=EXAMPLE,DC=COM 에 MSA가 생성됩니다.
-H, --host-fqdn=host
로컬 시스템의 정규화된 DNS 도메인 이름을 재정의합니다. 이 옵션을 지정하지 않으면 로컬 시스템의 호스트 이름이 사용됩니다.
-K, --host-keytab=<path_to_keytab>
MSA 자격 증명을 저장할 호스트 키 탭의 경로입니다. 이 값을 지정하지 않으면 기본 위치 /etc/krb5.keytab 은 소문자인 Active Directory 도메인 이름이 접미사(예: /etc/krb5.keytab.domain.example.com )와 함께 사용됩니다.
--use-ldaps
보안 LDAP(LDAPS) 채널을 통해 MSA를 생성합니다.
--verbose
MSA를 생성하는 동안 자세한 정보를 출력합니다.
--show-details
MSA를 생성한 후 해당 MSA에 대한 정보를 출력합니다.
--show-password
MSA를 생성한 후 MSA 암호를 출력합니다.

법적 공지

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat