Windows Active Directory와 직접 RHEL 시스템 통합
RHEL 호스트를 AD에 가입하고 AD의 리소스에 액세스
초록
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.
Jira를 통해 피드백 제출 (계정 필요)
- Jira 웹 사이트에 로그인합니다.
- 상단 탐색 바에서 생성을 클릭합니다.
- 요약 필드에 설명 제목을 입력합니다.
- 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
- 대화 상자 하단에서 생성 을 클릭합니다.
1장. SSSD를 사용하여 RHEL 시스템을 AD에 직접 연결
SSSD(System Security Services Daemon)는 RHEL(Red Hat Enterprise Linux) 시스템을 AD(Active Directory)와 연결하는 데 권장되는 구성 요소입니다. SSSD의 기본값인 POSIX ID 매핑을 사용하거나 AD에 정의된 POSIX 특성을 사용하여 AD와 직접 통합할 수 있습니다.
시스템에 AD에 가입하기 전에 Red Hat 지식베이스 솔루션 기본 사전 확인 단계의 절차에 따라 시스템을 올바르게 구성해야 합니다. RHEL은 'adcli', 'realm' 및 'net' 명령을 사용하여 Active Directory와 함께 참여하십시오.
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 시스템을 해당 도메인에 연결합니다.
사전 요구 사항
필요한 포트가 열려 있는지 확인합니다.
- DNS에 AD 도메인 컨트롤러 서버를 사용하고 있는지 확인합니다.
- 두 시스템의 시스템 시간이 동기화되었는지 확인합니다. 이렇게 하면 Kerberos가 올바르게 작동할 수 있습니다.
프로세스
다음 패키지를 설치합니다.
dnf install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
# dnf install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
Copy to Clipboard Copied! 특정 도메인에 대한 정보를 표시하려면
realm discover
을 실행하고 검색할 도메인의 이름을 추가합니다.realm discover ad.example.com
# 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 Copied! realmd
시스템은 DNS SRV 조회를 사용하여 이 도메인에서 도메인 컨트롤러를 자동으로 찾습니다.참고realmd
시스템은 Active Directory 및 Identity Management 도메인을 모두 검색할 수 있습니다. 두 도메인이 모두 환경에 있는 경우 검색 결과를--server-software=active-directory
옵션을 사용하여 특정 유형의 서버로 제한할 수 있습니다.realm join
명령을 사용하여 로컬 RHEL 시스템을 구성합니다.realmd
제품군은 필요한 모든 구성 파일을 자동으로 편집합니다. 예를 들어 이름이ad.example.com
인 도메인의 경우:realm join ad.example.com
# realm join ad.example.com
Copy to Clipboard Copied!
검증
관리자와 같은 AD 사용자 세부 정보를 표시합니다.
getent passwd administrator@ad.example.com
# getent passwd administrator@ad.example.com administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash
Copy to Clipboard Copied!
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 포트에서 직접 개별 도메인 컨트롤러에 연결합니다.
사전 요구 사항
필요한 포트가 열려 있는지 확인합니다.
- DNS에 AD 도메인 컨트롤러 서버를 사용하고 있는지 확인합니다.
- 두 시스템의 시스템 시간이 동기화되었는지 확인합니다. 이렇게 하면 Kerberos가 올바르게 작동할 수 있습니다.
프로세스
다음 패키지를 설치합니다.
dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
# dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
Copy to Clipboard Copied! realm join
명령을--automatic-id-mapping=no
옵션으로 사용하여 POSIX ID 매핑이 비활성화된 로컬 RHEL 시스템을 구성합니다.realmd
제품군은 필요한 모든 구성 파일을 자동으로 편집합니다. 예를 들어 이름이ad.example.com
인 도메인의 경우:realm join --automatic-id-mapping=no ad.example.com
# realm join --automatic-id-mapping=no ad.example.com
Copy to Clipboard Copied! 도메인에 이미 가입한 경우 SSSD에서 POSIX ID 매핑을 수동으로 비활성화할 수 있습니다.
-
/etc/sssd/sssd.conf
파일을 엽니다. -
AD domain 섹션에서
ldap_id_mapping = false
설정을 추가합니다. SSSD 캐시를 제거합니다.
rm -f /var/lib/sss/db/*
rm -f /var/lib/sss/db/*
Copy to Clipboard Copied! SSSD를 다시 시작하십시오.
systemctl restart sssd
systemctl restart sssd
Copy to Clipboard Copied!
-
SSSD는 이제 로컬에서 생성하는 대신 AD의 POSIX 속성을 사용합니다.
AD의 사용자에 대해 관련 POSIX 속성(uidNumber
,gidNumber
,unixHomeDirectory
, loginShell
)이 구성되어 있어야 합니다.
검증
관리자와 같은 AD 사용자 세부 정보를 표시합니다.
getent passwd administrator@ad.example.com
# getent passwd administrator@ad.example.com administrator@ad.example.com:*:10000:10000:Administrator:/home/Administrator:/bin/bash
Copy to Clipboard Copied!
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
권한이 필요합니다.
프로세스
-
텍스트 편집기에서
/etc/sssd/sssd.conf
구성 파일을 엽니다. 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
[domain/ad.example.com] id_provider = ad ... dyndns_refresh_interval = 43200 dyndns_update_ptr = false dyndns_ttl = 3600
Copy to Clipboard Copied! -
/etc/sssd/sssd.conf
구성 파일을 저장하고 종료합니다. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.
systemctl restart sssd
[root@client ~]# systemctl restart sssd
Copy to Clipboard Copied!
sssd.conf
파일에서 dyndns_update
옵션을 false
로 설정하여 동적 DNS 업데이트를 비활성화할 수 있습니다.
[domain/ad.example.com] id_provider = ad ... dyndns_update = false
[domain/ad.example.com]
id_provider = ad
...
dyndns_update = false
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 사이트를 찾아서 가장 가까운 도메인 컨트롤러에 연결합니다. 프로세스는 다음 단계로 구성됩니다.
-
SSSD는 SRV 쿼리를 수행하여 도메인에서 DC(Domain Controller)를 찾습니다. SSSD는 SSSD 구성 파일의
dns_discovery_domain
또는ad_domain
옵션에서 검색 도메인을 읽습니다. - SSSD는 너무 많은 DC를 ping하지 않고 연결할 수 없는 DC의 시간 초과를 방지하기 위해 3개의 일괄 처리로 이러한 DC에 대한 Connection-Less LDAP(CLDAP) ping을 수행합니다. SSSD가 이러한 배치 중 하나에서 사이트 및 포리스트 정보를 수신하는 경우 나머지 배치를 건너뜁니다.
- SSSD는 사이트별 및 백업 서버 목록을 생성하고 저장합니다.
1.10.2. AD 사이트 자동 검색 덮어쓰기
자동 검색 프로세스를 재정의하려면 ad_site
옵션을 ' /etc/sssd/sssd.conf 파일의 ' 섹션에
추가하여 클라이언트가 연결할 AD 사이트를 지정합니다. 이 예제에서는 클라이언트가 ExampleSite
AD 사이트에 연결하도록 구성합니다.
사전 요구 사항
- SSSD 서비스를 사용하여 RHEL 호스트를 Active Directory 환경에 연결했습니다.
-
/etc/sssd/sssd.conf
구성 파일을 편집할 수 있도록root
사용자로 인증할 수 있습니다.
프로세스
-
텍스트 편집기에서
/etc/sssd/sssd.conf
파일을 엽니다. AD 도메인의 '' 섹션에
ad_site
옵션을 추가합니다.[domain/ad.example.com] id_provider = ad ... ad_site = ExampleSite
[domain/ad.example.com] id_provider = ad ... ad_site = ExampleSite
Copy to Clipboard Copied! -
/etc/sssd/sssd.conf
구성 파일을 저장하고 종료합니다. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.
systemctl restart sssd
# systemctl restart sssd
Copy to Clipboard Copied!
1.11. realm 명령
realmd
시스템에는 두 가지 주요 작업 영역이 있습니다.
- 도메인의 시스템 등록 관리.
- 로컬 시스템 리소스에 액세스할 수 있는 도메인 사용자를 제어합니다.
realmd
에서 명령줄 툴 영역을
사용하여 명령을 실행합니다. 대부분의 realm
명령에서는 사용자가 유틸리티에서 수행해야 하는 작업과 작업을 수행할 도메인 또는 사용자 계정과 같은 엔터티를 지정해야 합니다.
명령 | 설명 |
---|---|
realm 명령 | |
Discover | 네트워크에서 도메인에 대한 검색 검사를 실행합니다. |
가입 | 시스템을 지정된 도메인에 추가합니다. |
leave | 지정된 도메인에서 시스템을 제거합니다. |
list | 시스템 또는 모든 검색 및 구성된 도메인에 대해 구성된 모든 도메인을 나열합니다. |
로그인 명령 | |
허용 | 특정 사용자에 대한 액세스 또는 구성된 도메인 내의 모든 사용자에 대해 액세스를 활성화하여 로컬 시스템에 액세스합니다. |
deny | 특정 사용자의 액세스 또는 구성된 도메인 내의 모든 사용자에 대해 로컬 시스템에 액세스하도록 액세스를 제한합니다. |
1.12. SSSD를 사용하여 RHEL 시스템을 AD로 직접 통합하는 데 필요한 포트
다음 포트가 열려 있어야 하며 AD 도메인 컨트롤러 및 RHEL 호스트에서 액세스할 수 있어야 합니다.
서비스 | 포트 | 프로토콜 | 참고 |
---|---|---|---|
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 |
|
LDAP 글로벌 카탈로그 | 3268 | TCP |
|
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 도메인에 연결할 수 있습니다.
프로세스
AD에 Kerberos 인증을 위한 더 이상 사용되지 않는 RC4 암호화 유형이 필요한 경우 RHEL에서 이러한 암호에 대한 지원을 활성화합니다.
update-crypto-policies --set DEFAULT:AD-SUPPORT
# update-crypto-policies --set DEFAULT:AD-SUPPORT
Copy to Clipboard Copied! 다음 패키지를 설치합니다.
dnf install realmd oddjob-mkhomedir oddjob samba-winbind-clients \ samba-winbind samba-common-tools samba-winbind-krb5-locator krb5-workstation
# dnf install realmd oddjob-mkhomedir oddjob samba-winbind-clients \ samba-winbind samba-common-tools samba-winbind-krb5-locator krb5-workstation
Copy to Clipboard Copied! 도메인 구성원에서 디렉터리 또는 프린터를 공유하려면
samba
패키지를 설치합니다.dnf install samba
# dnf install samba
Copy to Clipboard Copied! 기존
/etc/samba/smb.conf
Samba 구성 파일을 백업합니다.mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
# mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
Copy to Clipboard Copied! 도메인에 가입합니다. 예를 들어
ad.example.com
이라는 도메인에 가입하려면 다음을 수행합니다.realm join --membership-software=samba --client-software=winbind ad.example.com
# realm join --membership-software=samba --client-software=winbind ad.example.com
Copy to Clipboard Copied! 이전 명령을 사용하면
realm
유틸리티가 자동으로 수행됩니다.-
ad.example.com
도메인 멤버십에 대한/etc/samba/smb.conf
파일을 만듭니다. -
사용자 및 그룹 조회에 대한
winbind
모듈을/etc/nsswitch.conf
파일에 추가합니다. -
/etc/pam.d/
디렉토리에서 PAM(Pluggable Authentication Module) 구성 파일을 업데이트합니다. -
winbind
서비스를 시작하고 시스템이 부팅될 때 서비스가 시작됩니다.
-
선택 사항:
/etc/samba/smb.conf
파일에서 대체 ID 매핑 백엔드 또는 사용자 지정 ID 매핑 설정을 설정합니다.자세한 내용은 Samba ID 매핑 이해 및 구성을 참조하십시오.
/etc/krb5.conf
파일을 편집하고 다음 섹션을 추가합니다.[plugins] localauth = { module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so enable_only = winbind }
[plugins] localauth = { module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so enable_only = winbind }
Copy to Clipboard Copied! winbind
서비스가 실행 중인지 확인합니다.systemctl status winbind
# systemctl status winbind ... Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago
Copy to Clipboard Copied! 중요Samba를 활성화하여 도메인 사용자 및 그룹 정보를 쿼리하려면
smb
를 시작하기 전에winbind
서비스를 실행해야 합니다.디렉터리 및 프린터를 공유하는
samba
패키지를 설치한 경우smb
서비스를 활성화하고 시작합니다.systemctl enable --now smb
# systemctl enable --now smb
Copy to Clipboard Copied!
검증
AD 도메인의 AD 관리자 계정과 같은 AD 사용자의 세부 정보를 표시합니다.
getent passwd "AD\administrator"
# getent passwd "AD\administrator" AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bash
Copy to Clipboard Copied! AD 도메인에서 도메인 사용자 그룹의 멤버를 쿼리합니다.
getent group "AD\Domain Users"
# getent group "AD\Domain Users" AD\domain users:x:10000:user1,user2
Copy to Clipboard Copied! 선택 사항: 파일 및 디렉터리에 대한 권한을 설정할 때 도메인 사용자 및 그룹을 사용할 수 있는지 확인합니다. 예를 들어
/srv/samba/example.txt
파일의 소유자를AD\administrator
로 설정하고 그룹을AD\Domain Users
로 설정하려면 다음을 수행합니다.chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt
# chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt
Copy to Clipboard Copied! Kerberos 인증이 예상대로 작동하는지 확인합니다.
AD 도메인 멤버에서
administrator@AD.EXAMPLE.COM
주체에 대한 티켓을 받습니다.kinit administrator@AD.EXAMPLE.COM
# kinit administrator@AD.EXAMPLE.COM
Copy to Clipboard Copied! 캐시된 Kerberos 티켓을 표시합니다.
klist
# 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 Copied!
사용 가능한 도메인을 표시합니다.
wbinfo --all-domains
# wbinfo --all-domains BUILTIN SAMBA-SERVER AD
Copy to Clipboard Copied!
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(시간 동기화가 활성화된 경우)
프로세스
중요한 변수를 암호화된 파일에 저장합니다.
자격 증명 모음을 생성합니다.
ansible-vault create ~/vault.yml
$ ansible-vault create ~/vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
Copy to Clipboard Copied! ansible-vault create
명령이 편집기를 열고 <key > : < value
> 형식으로 중요한 데이터를 입력합니다.usr: administrator pwd: <password>
usr: administrator pwd: <password>
Copy to Clipboard Copied! - 변경 사항을 저장하고 편집기를 종료합니다. Ansible은 자격 증명 모음의 데이터를 암호화합니다.
다음 콘텐츠를 사용하여 플레이북 파일(예:
~/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"
--- - 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 Copied! 예제 플레이북에 지정된 설정은 다음과 같습니다.
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
파일을 참조하십시오.플레이북 구문을 확인합니다.
ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml
$ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml
Copy to Clipboard Copied! 이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.
Playbook을 실행합니다.
ansible-playbook --ask-vault-pass ~/playbook.yml
$ ansible-playbook --ask-vault-pass ~/playbook.yml
Copy to Clipboard Copied!
검증
관리 노드에서 AD 사용자(
관리자
)를 로컬로 사용할 수 있는지 확인합니다.ansible managed-node-01.example.com -m command -a 'getent passwd administrator@ad.example.com'
$ 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 Copied!
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일입니다. 기본값을 변경하려면 이 절차의 단계를 따릅니다.
프로세스
/etc/sssd/sssd.conf
파일의 AD 공급자에 다음 매개변수를 추가합니다.ad_maximum_machine_account_password_age = value_in_days
ad_maximum_machine_account_password_age = value_in_days
Copy to Clipboard Copied! SSSD를 다시 시작하십시오.
systemctl restart sssd
# systemctl restart sssd
Copy to Clipboard Copied! -
자동 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에 연결했습니다.
프로세스
realm leave
명령을 사용하여 ID 도메인에서 시스템을 제거합니다. 이 명령은 SSSD 및 로컬 시스템에서 도메인 구성을 제거합니다.realm leave ad.example.com
# realm leave ad.example.com
Copy to Clipboard Copied! 참고클라이언트가 도메인을 벗어나면 AD는 계정을 삭제하지 않고 로컬 클라이언트 구성만 제거합니다. AD 계정을 삭제하려면
--remove
옵션을 사용하여 명령을 실행합니다. 처음에 인증 정보 없이 연결을 시도하지만 유효한 Kerberos 티켓이 없는 경우 사용자 암호를 입력하라는 메시지가 표시됩니다. Active Directory에서 계정을 삭제할 수 있는 권한이 있어야 합니다.realm leave
명령과 함께-U
옵션을 사용하여 ID 도메인에서 시스템을 제거할 다른 사용자를 지정합니다.기본적으로
realm leave
명령은 기본 관리자로 실행됩니다. AD의 경우 관리자 계정을Administrator
라고 합니다. 다른 사용자가 도메인에 가입하는 데 사용된 경우 해당 사용자로 제거를 수행해야 할 수 있습니다.realm leave [ad.example.com] -U [AD.EXAMPLE.COM\user]'
# realm leave [ad.example.com] -U [AD.EXAMPLE.COM\user]'
Copy to Clipboard Copied! 명령은 먼저 자격 증명 없이 연결을 시도하지만 필요한 경우 암호를 입력하라는 메시지를 표시합니다.
검증
도메인이 더 이상 구성되지 않았는지 확인합니다.
realm discover [ad.example.com]
# 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 Copied!
4.3. 간단한 AD 사용자 이름 확인으로 SSSD에서 도메인 확인 순서 설정
기본적으로 SSSD 서비스를 사용하여 AD에 연결된 RHEL 호스트에서 AD(Active Directory) 사용자 및 그룹을 확인하려면 ad_username@ad.example.com
및 group@ad.example.com
와 같이 정규화된 사용자 이름을 지정해야 합니다.
이 절차에서는 ad_username
과 같은 짧은 이름으로 AD 사용자 및 그룹을 확인할 수 있도록 SSSD 구성에서 도메인 확인 순서를 설정합니다. 이 예제 구성은 다음과 같은 순서로 사용자와 그룹을 검색합니다.
-
Active Directory (AD) 하위 도메인
subdomain2.ad.example.com
-
AD 하위 도메인
subdomain1.ad.example.com
-
AD 루트 도메인
ad.example.com
사전 요구 사항
- SSSD 서비스를 사용하여 RHEL 호스트를 AD에 직접 연결했습니다.
프로세스
-
텍스트 편집기에서
/etc/sssd/sssd.conf
파일을 엽니다. 파일의 '' 섹션에
domain_resolution_order
옵션을 설정합니다.domain_resolution_order = subdomain2.ad.example.com, subdomain1.ad.example.com, ad.example.com
domain_resolution_order = subdomain2.ad.example.com, subdomain1.ad.example.com, ad.example.com
Copy to Clipboard Copied! - 파일을 저장하고 닫습니다.
SSSD 서비스를 다시 시작하여 새 구성 설정을 로드합니다.
systemctl restart sssd
[root@ad-client ~]# systemctl restart sssd
Copy to Clipboard Copied!
검증
짧은 이름만 사용하여 첫 번째 도메인에서 사용자의 사용자 정보를 검색할 수 있는지 확인합니다.
id <user_from_subdomain2>
[root@ad-client ~]# id <user_from_subdomain2> uid=1916901142(user_from_subdomain2) gid=1916900513(domain users) groups=1916900513(domain users)
Copy to Clipboard Copied!
4.4. 도메인 사용자의 로그인 권한 관리
기본적으로 도메인 측 액세스 제어가 적용되므로 AD(Active Directory) 사용자에 대한 로그인 정책이 AD 도메인 자체에 정의되어 있습니다. 이 기본 동작은 클라이언트 측 액세스 제어가 사용되도록 재정의할 수 있습니다. 클라이언트 측 액세스 제어를 사용하면 로그인 권한이 로컬 정책에서만 정의됩니다.
도메인이 클라이언트 측 액세스 제어를 적용하는 경우 realmd
를 사용하여 해당 도메인의 사용자에 대한 기본 허용 또는 액세스 규칙을 구성할 수 있습니다.
액세스 규칙은 시스템의 모든 서비스에 대한 액세스를 허용하거나 거부합니다. 특정 시스템 리소스 또는 도메인에 대해 보다 구체적인 액세스 규칙을 설정해야 합니다.
4.4.1. 도메인 내의 사용자에 대한 액세스 활성화
기본적으로 AD(Active Directory) 사용자에 대한 로그인 정책은 AD 도메인 자체에 정의됩니다. 이 기본 동작을 재정의하고 AD 도메인 내의 사용자에 대한 액세스를 활성화하도록 RHEL 호스트를 구성할 수 있습니다.
영역 허용 -x
가 있는 특정 사용자에게만 거부하면서 기본적으로 모두에 대한 액세스를 허용하지 않는 것이 좋습니다. 대신, Red Hat은 모든 사용자에 대해 기본 액세스 정책을 유지 관리하지 않고 realm 허용을 사용하여 선택한 사용자에게만 액세스 권한을 부여할 것을 권장합니다.
사전 요구 사항
- RHEL 시스템은 Active Directory 도메인의 멤버입니다.
프로세스
모든 사용자에게 액세스 권한을 부여합니다.
realm permit --all
# realm permit --all
Copy to Clipboard Copied! 특정 사용자에게 액세스 권한을 부여합니다.
realm permit aduser01@example.com realm permit 'AD.EXAMPLE.COM\aduser01'
$ realm permit aduser01@example.com $ realm permit 'AD.EXAMPLE.COM\aduser01'
Copy to Clipboard Copied!
현재는 신뢰할 수 있는 도메인의 사용자가 아닌 기본 도메인의 사용자에게만 액세스를 허용할 수 있습니다. 이는 사용자 로그인에 도메인 이름을 포함해야 하며 SSSD는 현재 사용 가능한 하위 도메인에 대한 정보를 제공할 수 없기 때문입니다.
검증
SSH를 사용하여
aduser01@example.com
사용자로 서버에 로그인합니다.ssh aduser01@example.com@server_name
$ ssh aduser01@example.com@server_name [aduser01@example.com@server_name ~]$
Copy to Clipboard Copied! ssh 명령을 두 번 사용하여
aduser02@example.com
사용자와 동일한 서버에 액세스합니다.ssh aduser02@example.com@server_name
$ ssh aduser02@example.com@server_name Authentication failed.
Copy to Clipboard Copied!
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 도메인의 멤버입니다.
프로세스
도메인 내의 모든 사용자에 대한 액세스를 거부합니다.
realm deny --all
# realm deny --all
Copy to Clipboard Copied! 이 명령은
영역
계정이 로컬 시스템에 로그인하지 못하도록 합니다.realm allow을
사용하여 특정 계정으로 로그인을 제한합니다.도메인 사용자의
login-policy
가deny-any-login
:으로 설정되어 있는지 확인합니다.realm list
[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 Copied! -x
옵션을 사용하여 특정 사용자에 대한 액세스를 거부합니다.realm permit -x 'AD.EXAMPLE.COM\aduser02'
$ realm permit -x 'AD.EXAMPLE.COM\aduser02'
Copy to Clipboard Copied!
검증
SSH를 사용하여
aduser01@example.net
사용자로 서버에 로그인합니다.ssh aduser01@example.net@server_name
$ ssh aduser01@example.net@server_name Authentication failed.
Copy to Clipboard Copied!
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 옵션을 보여줍니다.
GPO 옵션 | 해당 sssd.conf 옵션 |
---|---|
로컬에서 로그 허용 |
|
Remote Desktop Services |
|
네트워크에서 이 컴퓨터에 액세스 |
|
배치 작업으로 로그온 허용 |
|
Allow log on as a service |
|
4.5.3. GPO 적용을 제어하는 SSSD 옵션 목록
다음 SSSD 옵션을 설정하여 GPO 규칙 범위를 제한할 수 있습니다.
ad_gpo_access_control
옵션
/etc/sssd/sssd.conf
파일에서 ad_gpo_access_control
옵션을 설정하여 GPO 기반 액세스 제어가 작동하는 세 가지 모드 중 하나를 선택할 수 있습니다.
Value of ad_gpo_access_control | 동작 |
---|---|
|
GPO 기반 액세스 제어 규칙은 평가 및 적용됩니다. |
|
GPO 기반 액세스 제어 규칙은 평가되지만 적용되지 않습니다. 액세스 권한이 거부될 때마다 |
| GPO 기반 액세스 제어 규칙은 평가되거나 적용되지 않습니다. |
ad_gpo_implicit_deny
옵션
ad_gpo_implicit_deny
옵션은 기본적으로 False
로 설정됩니다. 이 기본 상태에서 해당 GPO를 찾을 수 없는 경우 사용자가 액세스할 수 있습니다. 이 옵션을 True
로 설정하는 경우 GPO 규칙을 사용하여 사용자를 명시적으로 허용해야 합니다.
이 기능을 사용하여 보안을 강화할 수 있지만 의도하지 않게 액세스를 거부하지 않도록 주의하십시오. ad_gpo_access_control
은 허용
으로 설정된 동안 이 기능을 테스트하는 것이 좋습니다.
다음 두 표는 AD 서버 측에 정의된 허용 및 거부 로그인 권한 및 ad_gpo_implicit_deny
값을 기반으로 사용자가 허용되거나 거부되는 경우를 보여줍니다.
allow-rules | deny-rules | 결과 |
---|---|---|
누락됨 | 누락됨 | 모든 사용자가 허용 |
누락됨 | 현재 | deny-rules에 없는 사용자만 허용됩니다. |
현재 | 누락됨 | allow-rules의 사용자만 허용됩니다. |
현재 | 현재 | allow-rules 및 deny-rules에 없는 사용자만 허용됩니다. |
allow-rules | deny-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]
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 Copied! 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.
(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 Copied!
이 동작이 바람직하지 않은 동작인 경우 AD의 적절한 GPO 설정 문제를 해결하는 동안 이 절차에 설명된 대로 ad_gpo_access_control
을 허용
으로 일시적으로 설정할 수 있습니다.
사전 요구 사항
- SSSD를 사용하여 AD 환경에 RHEL 호스트에 가입했습니다.
-
/etc/sssd/sssd.conf
구성 파일을 편집하려면root
권한이 필요합니다.
프로세스
SSSD 서비스를 중지합니다.
systemctl stop sssd
[root@server ~]# systemctl stop sssd
Copy to Clipboard Copied! -
텍스트 편집기에서
/etc/sssd/sssd.conf
파일을 엽니다. AD 도메인의
domain
섹션에서ad_gpo_access_control
을허용
으로 설정합니다.[domain/example.com] ad_gpo_access_control=permissive ...
[domain/example.com] ad_gpo_access_control=permissive ...
Copy to Clipboard Copied! -
/etc/sssd/sssd.conf
파일을 저장합니다. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.
systemctl restart sssd
[root@server ~]# systemctl restart sssd
Copy to Clipboard Copied!
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를 변경할 수 있습니다.
프로세스
Active Directory 사용자 및 컴퓨터에서 새 GPO와 연결할 조직 단위(OU)를 생성합니다.
- 도메인을 마우스 오른쪽 버튼으로 클릭합니다.
- 새로 만들기를 선택합니다.
- 조직 단위 를 선택합니다.
- RHEL 호스트를 나타내는 Computer Object의 이름을 클릭하고 (Active Directory에 가입했을 때 생성됨) 새 OU로 드래그합니다. 자체 OU에 RHEL 호스트를 사용하면 GPO가 이 호스트를 대상으로 합니다.
그룹 정책 관리 편집기에서 생성한 OU에 대한 새 GPO를 만듭니다.
- Forest 를 확장합니다.
- 도메인 을 확장합니다.
- 도메인을 확장합니다.
- 새 OU를 마우스 오른쪽 버튼으로 클릭합니다.
- 이 도메인에서 GPO 만들기를 선택합니다.
- SSH 액세스 허용 또는 콘솔/GUI 액세스 허용 과 같은 새 GPO의 이름을 지정하고 확인을 클릭합니다.
새 GPO를 편집합니다.
- 그룹 정책 관리 편집기에서 OU를 선택합니다.
- 마우스 오른쪽 버튼으로 클릭하고 편집을 선택합니다.
- 사용자 권한 할당 을 선택합니다.
- 컴퓨터 구성 을 선택합니다.
- Policies 를 선택합니다.
- Windows 설정을 선택합니다.
- 보안 설정을 선택합니다.
- 로컬 정책을 선택합니다.
- 사용자 권한 할당 을 선택합니다.
로그인 권한 할당:
- 로컬에서 로그를 두 번 클릭하여 로컬 콘솔/GUI 액세스 권한을 부여합니다.
- 원격 데스크탑 서비스를 통한 로그 허용을 두 번 클릭하여 SSH 액세스 권한을 부여합니다.
다음 정책 중 하나에 액세스하려는 사용자를 정책 자체에 추가합니다.
- 사용자 또는 그룹 추가를 클릭합니다.
- 빈 필드에 사용자 이름을 입력합니다.
- 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.com
에 lab.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
패키지가 설치되어 있습니다.
프로세스
production.example.com
AD 도메인에 호스트에 대한 MSA를 생성합니다.adcli create-msa --domain=production.example.com
[root@client ~]# adcli create-msa --domain=production.example.com
Copy to Clipboard Copied! 생성된 Kerberos 키탭에서 MSA에 대한 정보를 표시합니다. MSA 이름을 기록해 둡니다.
klist -k /etc/krb5.keytab.production.example.com
[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 Copied! /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 ...
[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 Copied! 주의기존의 신뢰 관계가 있더라도
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 ...
[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 Copied!
검증
MSA로 Kerberos 티켓(TGT)을 검색할 수 있는지 확인합니다.
kinit -k -t /etc/krb5.keytab.production.example.com 'CLIENT!S3A$' klist
[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 Copied! - 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
패키지가 설치되어 있습니다.
프로세스
선택 사항: Kerberos 키 탭에서 MSA의 현재 키 버전 번호(KVNO)를 표시합니다. 현재 KVNO는 2입니다.
klist -k /etc/krb5.keytab.production.example.com
[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 Copied! production.example.com
AD 도메인에서 MSA의 암호를 업데이트합니다.adcli update --domain=production.example.com --host-keytab=/etc/krb5.keytab.production.example.com --computer-password-lifetime=0
[root@client ~]# adcli update --domain=production.example.com --host-keytab=/etc/krb5.keytab.production.example.com --computer-password-lifetime=0
Copy to Clipboard Copied!
검증
Kerberos 키탭에서 KVNO가 증가했는지 확인합니다.
klist -k /etc/krb5.keytab.production.example.com
[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 Copied!
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 암호를 출력합니다.