Windows Active Directory와 RHEL 시스템을 직접 통합
AD에 RHEL 호스트에 가입하고 AD에서 리소스에 액세스
초록
Red Hat 문서에 관한 피드백 제공 링크 복사링크가 클립보드에 복사되었습니다!
문서에 대한 피드백에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.
Jira를 통해 피드백 제출 (등록 필요)
- Jira 웹 사이트에 로그인합니다.
- 상단 탐색 모음에서 생성 을 클릭합니다.
- Summary (요약) 필드에 설명 제목을 입력합니다.
- Description (설명) 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
- 대화 상자 하단에서 생성 을 클릭합니다.
1장. SSSD를 사용하여 RHEL 시스템을 AD에 직접 연결 링크 복사링크가 클립보드에 복사되었습니다!
RHEL 시스템을 AD(Active Directory)에 연결하려면 두 가지 구성 요소가 필요합니다. SSSD는 중앙 ID 및 인증 소스와 상호 작용하며 다른 구성 요소인 realmd 는 사용 가능한 도메인을 감지하고 기본 RHEL 시스템 서비스(이 경우 SSSD)를 구성하여 도메인에 연결합니다.
이 섹션에서는 SSSD(System Security Services Daemon)를 사용하여 RHEL 시스템을 AD(Active Directory)에 연결하는 방법을 설명합니다.
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 forest 내에서만 작동합니다.
AD와 Linux 시스템을 직접 통합하도록 SSSD를 구성하는 가장 편리한 방법은 realmd 서비스를 사용하는 것입니다. 호출자는 네트워크 인증 및 도메인 멤버십을 표준 방식으로 구성할 수 있습니다. realmd 서비스는 액세스 가능한 도메인 및 영역에 대한 정보를 자동으로 검색하고 도메인 또는 영역에 조인하기 위해 고급 구성이 필요하지 않습니다.
SSSD를 AD와 직접 및 간접 통합에 모두 사용할 수 있으며 하나의 통합 방법에서 다른 방법으로 전환할 수 있습니다. 직접 통합은 RHEL 시스템을 AD 환경에 소개하는 간단한 방법입니다. 그러나 RHEL 시스템의 공유가 증가함에 따라 배포 시 호스트 기반 액세스 제어, sudo 또는 SELinux 사용자 매핑과 같은 ID 관련 정책을 보다 효율적으로 관리해야 합니다. 처음에 RHEL 시스템의 이러한 측면을 로컬 구성 파일에서 유지 관리할 수 있습니다. 그러나 시스템의 수가 증가함에 따라 Red Hat Satellite와 같은 프로비저닝 시스템을 사용하면 구성 파일의 배포 및 관리가 쉬워집니다. 직접 통합이 더 이상 확장되지 않는 경우 간접 통합을 고려해야 합니다. 직접 통합(RHEL 클라이언트가 AD 도메인에 있음)에서 간접 통합( trust to AD로 IdM)으로 이동하는 방법에 대한 자세한 내용은 AD 도메인에서 IdM 서버로 RHEL 클라이언트 이동을 참조하십시오.
IdM이 FIPS 모드인 경우 IdM-AD 통합은 RC4 또는 AES HMAC-SHA1 암호화만 지원하는 경우에만 AD로 인해 작동하지 않지만 FIPS 모드의 RHEL 9에서는 기본적으로 AES HMAC-SHA2만 허용합니다. 자세한 내용은 Red Hat Knowledgebase 솔루션 AD 도메인 사용자가 FIPS 호환 환경에 로그인할 수 없는 것을 참조하십시오.
IdM은 Common Criteria 평가 시스템에서만 사용해야 하는 보다 제한적인 FIPS:OSPP 암호화 정책을 지원하지 않습니다.
사용 사례에 맞는 통합 유형에 대한 자세한 내용은 간접 통합 및 직접 통합 정의를 참조하십시오.
1.2. 직접 통합을 위해 지원되는 Windows 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
다음 Specest 및 도메인 기능 수준을 사용하는 Active Directoryest와 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에 직접 연결 링크 복사링크가 클립보드에 복사되었습니다!
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와 함께 참여하십시오.
1.3.1. 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.3.2. 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를 포함하여 사용자에 대한 항목을 만듭니다.
- AD 사용자의 ID가 동일한 SID에서 일관된 방식으로 생성되므로 사용자는 RHEL 시스템에 로그인할 때 UID와 GID가 동일합니다.
모든 클라이언트 시스템에서 SSSD를 사용하여 SID를 Linux ID에 매핑하면 매핑이 일관되게 유지됩니다. 일부 클라이언트가 다른 소프트웨어를 사용하는 경우 다음 중 하나를 선택합니다.
- 모든 클라이언트에서 동일한 매핑 알고리즘이 사용되는지 확인합니다.
- AD에 정의된 명시적 POSIX 특성을 사용합니다.
자세한 내용은 sssd-ad 도움말 페이지의 ID 매핑 섹션을 참조하십시오.
1.3.2.1. SSSD를 사용하여 AD 도메인 검색 및 참여 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 AD 도메인을 검색하고 SSSD를 사용하여 RHEL 시스템을 해당 도메인에 연결합니다.
사전 요구 사항
AD 도메인 컨트롤러에서 다음 포트가 열려 있고 RHEL 호스트에서 액세스할 수 있는지 확인합니다.
Expand 표 1.1. SSSD를 사용하여 Linux 시스템을 AD로 직접 통합하는 데 필요한 포트 서비스 포트 프로토콜 참고 DNS
53
UDP 및 TCP
LDAP
389
UDP 및 TCP
samba
445
UDP 및 TCP
AD Group Policy Objects(GPO)의 경우
Kerberos
88
UDP 및 TCP
Kerberos
464
UDP 및 TCP
kadmin에서 암호 설정 및 변경에 사용LDAP 글로벌 카탈로그
3268
TCP
id_provider = ad옵션을 사용하는 경우NTP
123
UDP
선택 사항
- 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-workstationCopy to Clipboard Copied! Toggle word wrap Toggle overflow 특정 도메인에 대한 정보를 표시하려면
영역 검색을 실행하고 검색할도메인의 이름을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow realmd시스템은 DNS SRV lookups를 사용하여 이 도메인의 도메인 컨트롤러를 자동으로 찾습니다.참고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.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
관리자와 같은 AD 사용자 세부 정보를 표시합니다.
getent passwd administrator@ad.example.com administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash
# getent passwd administrator@ad.example.com administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bashCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.3.3. 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 포트의 개별 도메인 컨트롤러에 직접 연결합니다.
사전 요구 사항
RHEL 호스트의 다음 포트가 열려 있고 AD 도메인 컨트롤러에서 액세스할 수 있는지 확인합니다.
Expand 표 1.2. SSSD를 사용하여 Linux 시스템을 AD로 직접 통합하는 데 필요한 포트 서비스 포트 프로토콜 참고 DNS
53
UDP 및 TCP
LDAP
389
UDP 및 TCP
Kerberos
88
UDP 및 TCP
Kerberos
464
UDP 및 TCP
kadmin에서 암호 설정 및 변경에 사용
LDAP 글로벌 카탈로그
3268
TCP
id_provider = ad옵션을 사용하는 경우NTP
123
UDP
선택 사항
- DNS에 AD 도메인 컨트롤러 서버를 사용하고 있는지 확인합니다.
- 두 시스템의 시스템 시간이 동기화되었는지 확인합니다. 이렇게 하면 Kerberos가 올바르게 작동할 수 있습니다.
절차
다음 패키지를 설치합니다.
dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
# dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstationCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 도메인에 이미 가입한 경우 SSSD에서 POSIX ID 매핑을 수동으로 비활성화할 수 있습니다.
-
/etc/sssd/sssd.conf파일을 엽니다. -
AD 도메인 섹션에서
ldap_id_mapping = false설정을 추가합니다. SSSD 캐시를 제거합니다.
rm -f /var/lib/sss/db/*
rm -f /var/lib/sss/db/*Copy to Clipboard Copied! Toggle word wrap Toggle overflow SSSD를 다시 시작합니다.
systemctl restart sssd
systemctl restart sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
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
# getent passwd administrator@ad.example.com administrator@ad.example.com:*:10000:10000:Administrator:/home/Administrator:/bin/bashCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.3.4. SSSD를 사용하여 다양한 AD forest의 여러 도메인에 연결 링크 복사링크가 클립보드에 복사되었습니다!
AD(Active Directory) 관리 서비스 계정(MSA)을 사용하여 서로 다른 포리스트의 AD 도메인에 액세스할 수 있습니다.You can use an Active Directory (AD) Managed Service Account (MSA) to access AD domains from different forests where there is no trust between them.
관리 서비스 계정을 사용하여 AD 액세스 단원을 참조하십시오.
1.4. 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를 사용하여 AD 서버로 동적 DNS 업데이트를 보냅니다. 즉, AD에 대한 보안 연결을 사용하도록 설정해야 합니다.
1.5. AD 공급자의 동적 DNS 설정 수정 링크 복사링크가 클립보드에 복사되었습니다!
SSSD(System Security Services Daemon) 서비스는 기본 간격으로 AD 환경에 연결된 RHEL(Red Hat Enterprise Linux) 클라이언트의 DNS 레코드를 새로 고칩니다. 다음 절차에서는 이러한 간격을 조정합니다.
사전 요구 사항
- SSSD 서비스를 사용하여 Active Directory 환경에 RHEL 호스트에 참여했습니다.
-
/etc/sssd/sssd.conf설정 파일을 편집하려면루트권한이 필요합니다.
절차
-
텍스트 편집기에서
/etc/sssd/sssd.conf설정 파일을 엽니다. AD 도메인의
[domain]섹션에 DNS 레코드 새로 고침 간격을 12시간으로 설정하고, PTR 레코드 업데이트를 비활성화하며, DNS 레코드 TTL(TTL)을 1시간으로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
/etc/sssd/sssd.conf설정 파일을 저장하고 닫습니다. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.
systemctl restart sssd
[root@client ~]# systemctl restart sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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.6. AD 공급자가 신뢰할 수 있는 도메인을 처리하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
/etc/sssd/sssd.conf 구성 파일에서 id_provider = ad 옵션을 설정하면 SSSD가 신뢰할 수 있는 도메인을 다음과 같이 처리합니다.
-
SSSD는 단일 AD forest의 도메인만 지원합니다. SSSD에서 여러 개의 포리스트에서 여러 도메인에 액세스해야 하는 경우 SSSD 대신 신뢰(preferred) 또는
winbindd서비스를 사용하는 것이 좋습니다. 기본적으로 SSSD는 버스트에 있는 모든 도메인을 검색하고, 신뢰할 수 있는 도메인의 개체에 대한 요청이 도착하면 SSSD에서 이 도메인을 해결합니다.
신뢰할 수 있는 도메인에 연결할 수 없거나 지리적으로 멀리 있지 않으면 속도가 느려지면
/etc/sssd/sssd.conf에서ad_enabled_domains매개변수를 설정하여 신뢰할 수 있는 도메인 SSSD에서 개체를 확인할 수 있습니다.- 기본적으로 정규화된 사용자 이름을 사용하여 신뢰할 수 있는 도메인에서 사용자를 확인해야 합니다.
1.7. SSSD를 사용하여 Active Directory 사이트 자동 검색 재정의 링크 복사링크가 클립보드에 복사되었습니다!
Active Directory (AD) 는 매우 클 수 있으며, 다양한 도메인 컨트롤러, 도메인, 하위 도메인 및 물리적 사이트와 함께 매우 클 수 있습니다. AD는 사이트 개념을 사용하여 도메인 컨트롤러의 물리적 위치를 식별합니다. 이를 통해 클라이언트는 지리적으로 가장 가까운 도메인 컨트롤러에 연결할 수 있으므로 클라이언트 성능이 향상됩니다.
이 섹션에서는 SSSD에서 자동 검색을 사용하여 AD 사이트를 찾아 연결하는 방법과 자동 검색을 재정의하고 사이트를 수동으로 지정하는 방법을 설명합니다.
1.7.1. SSSD에서 AD 사이트 자동 검색을 처리하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 SSSD 클라이언트는 자동 검색을 사용하여 AD 사이트를 찾고 가장 가까운 도메인 컨트롤러에 연결합니다. 프로세스는 다음 단계로 구성됩니다.
-
SSSD는 SRV 쿼리를 수행하여 도메인에서 도메인 컨트롤러(DC)를 찾습니다. SSSD는 SSSD 구성 파일의
dns_discovery_domain또는ad_domain옵션에서 검색 도메인을 읽습니다. - SSSD는 너무 많은 DC를 ping하고 연결할 수 없는 DC에서 이 DC에 대해 CLDAP(Connection-Less LDAP) ping을 수행합니다. SSSD가 이러한 배치 중 사이트 및 색인 정보를 수신하는 경우 나머지 배치를 건너뜁니다.
- SSSD는 사이트별 및 백업 서버 목록을 생성하고 저장합니다.
1.7.2. AD 사이트 자동 검색 덮어쓰기 링크 복사링크가 클립보드에 복사되었습니다!
자동 검색 프로세스를 재정의하려면 ad_site 옵션을 /etc/sssd/sssd.conf 파일의 [domain] 섹션에 추가하여 클라이언트를 연결할 AD 사이트를 지정합니다. 이 예에서는 클라이언트가 ExampleSite AD 사이트에 연결하도록 구성합니다.
사전 요구 사항
- SSSD 서비스를 사용하여 RHEL 호스트에 Active Directory 환경에 가입했습니다.
-
/etc/sssd/sssd.conf구성 파일을 편집할 수 있도록root사용자로 인증할 수 있습니다.
절차
-
텍스트 편집기에서
/etc/sssd/sssd.conf파일을 엽니다. AD 도메인의
[domain]섹션에ad_site옵션을 추가합니다.[domain/ad.example.com] id_provider = ad ... ad_site = ExampleSite
[domain/ad.example.com] id_provider = ad ... ad_site = ExampleSiteCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
/etc/sssd/sssd.conf설정 파일을 저장하고 닫습니다. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.
systemctl restart sssd
# systemctl restart sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.8. 영역 명령 링크 복사링크가 클립보드에 복사되었습니다!
realmd 시스템에는 두 가지 주요 작업 영역이 있습니다.
- 도메인의 시스템 등록 관리.
- 로컬 시스템 리소스에 액세스할 수 있는 도메인 사용자를 제어합니다.
realmd 에서 명령줄 툴 영역을 사용하여 명령을 실행합니다. 대부분의 realm 명령을 실행하려면 유틸리티에서 수행해야 하는 작업과 작업을 수행할 도메인 또는 사용자 계정과 같은 엔터티를 지정해야 합니다.
| 명령 | 설명 |
|---|---|
| 영역 명령 | |
| discover | 네트워크에서 도메인에 대한 검색 검사를 실행합니다. |
| join | 지정된 도메인에 시스템을 추가합니다. |
| 자주 묻는 질문 | 지정된 도메인에서 시스템을 제거합니다. |
| list | 시스템에 대해 구성된 모든 도메인 또는 검색 및 구성된 모든 도메인을 나열합니다. |
| 로그인 명령 | |
| 허용 | 특정 사용자 또는 구성된 도메인 내 모든 사용자에 대한 액세스를 활성화하여 로컬 시스템에 액세스합니다. |
| deny | 특정 사용자 또는 구성된 도메인 내 모든 사용자에 대한 액세스 권한을 제한하여 로컬 시스템에 액세스합니다. |
2장. Samba Winbind를 사용하여 AD에 RHEL 시스템 직접 연결 링크 복사링크가 클립보드에 복사되었습니다!
RHEL 시스템을 AD에 연결하려면 두 가지 구성 요소가 필요합니다. 하나의 구성 요소인 Samba Winbind는 AD ID 및 인증 소스와 상호 작용하고, 사용 가능한 도메인을 감지하여 기본 RHEL 시스템 서비스를 구성하고 기본 RHEL 시스템 서비스를 구성하여 AD 도메인에 연결합니다.
이 섹션에서는 Samba Winbind를 사용하여 RHEL 시스템을 AD(Active Directory)에 연결하는 방법을 설명합니다.
2.1. Samba Winbind를 사용한 직접 통합 개요 링크 복사링크가 클립보드에 복사되었습니다!
Samba Winbind는 Linux 시스템에서 Windows 클라이언트를 에뮬레이션하고 AD 서버와 통신합니다.
realmd 서비스를 사용하여 다음을 통해 Samba Winbind를 구성할 수 있습니다.
- 표준 방식으로 네트워크 인증 및 도메인 멤버십 구성.
- 액세스 가능한 도메인 및 영역에 대한 정보를 자동으로 검색합니다.
- 고급 구성이 도메인 또는 영역에 가입할 필요가 없습니다.
다음 사항에 유의하십시오.
- 다중 Forest AD 설정에서 Winbind와 직접 통합하려면 양방향 신뢰가 필요합니다.
-
remote forests는 local forests를 신뢰하여
idmap_ad플러그인이 원격 forest 사용자를 올바르게 처리할 수 있도록 해야 합니다.
Samba의 winbindd 서비스는 NSS(Name Service Switch)에 대한 인터페이스를 제공하고 도메인 사용자가 로컬 시스템에 로그인할 때 AD를 인증할 수 있도록 합니다.
winbindd 를 사용하면 추가 소프트웨어를 설치하지 않고도 디렉터리 및 프린터를 공유하는 구성을 향상시킬 수 있는 이점이 있습니다. 자세한 내용은 다른 유형의 서버 배포 가이드의 Samba를 서버로 사용하는 방법에 대한 섹션을 참조하십시오.
2.2. 직접 통합을 위해 지원되는 Windows 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
다음 Specest 및 도메인 기능 수준을 사용하는 Active Directoryest와 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입니다.
2.3. 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-SUPPORTCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 패키지를 설치합니다.
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-workstationCopy to Clipboard Copied! Toggle word wrap Toggle overflow 도메인 구성원에서 디렉터리 또는 프린터를 공유하려면
samba패키지를 설치합니다.dnf install samba
# dnf install sambaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 기존
/etc/samba/smb.confSamba 구성 파일을 백업합니다.mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
# mv /etc/samba/smb.conf /etc/samba/smb.conf.bakCopy to Clipboard Copied! Toggle word wrap Toggle overflow 도메인에 가입합니다. 예를 들어
ad.example.com이라는 도메인에 가입하려면 다음을 수행합니다.realm join --membership-software=samba --client-software=winbind ad.example.com
# realm join --membership-software=samba --client-software=winbind ad.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 명령을 사용하면
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! Toggle word wrap Toggle overflow winbind서비스가 실행 중인지 확인합니다.systemctl status winbind ... Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago
# systemctl status winbind ... Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s agoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 중요Samba를 활성화하여 도메인 사용자 및 그룹 정보를 쿼리하려면
smb를 시작하기 전에winbind서비스를 실행해야 합니다.디렉터리 및 프린터를 공유하는
samba패키지를 설치한 경우smb서비스를 활성화하고 시작합니다.systemctl enable --now smb
# systemctl enable --now smbCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
AD 도메인의 AD 관리자 계정과 같은 AD 사용자의 세부 정보를 표시합니다.
getent passwd "AD\administrator" AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bash
# getent passwd "AD\administrator" AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bashCopy to Clipboard Copied! Toggle word wrap Toggle overflow AD 도메인에서 도메인 사용자 그룹의 멤버를 쿼리합니다.
getent group "AD\Domain Users" AD\domain users:x:10000:user1,user2# getent group "AD\Domain Users" AD\domain users:x:10000:user1,user2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 파일 및 디렉터리에 대한 권한을 설정할 때 도메인 사용자 및 그룹을 사용할 수 있는지 확인합니다. 예를 들어
/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.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow Kerberos 인증이 예상대로 작동하는지 확인합니다.
AD 도메인 멤버에서
administrator@AD.EXAMPLE.COM주체의 티켓을 받습니다.kinit administrator@AD.EXAMPLE.COM
# kinit administrator@AD.EXAMPLE.COMCopy to Clipboard Copied! Toggle word wrap Toggle overflow 캐시된 Kerberos 티켓을 표시합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
사용 가능한 도메인을 표시합니다.
wbinfo --all-domains BUILTIN SAMBA-SERVER AD
# wbinfo --all-domains BUILTIN SAMBA-SERVER ADCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. 영역 명령 링크 복사링크가 클립보드에 복사되었습니다!
realmd 시스템에는 두 가지 주요 작업 영역이 있습니다.
- 도메인의 시스템 등록 관리.
- 로컬 시스템 리소스에 액세스할 수 있는 도메인 사용자를 제어합니다.
realmd 에서 명령줄 툴 영역을 사용하여 명령을 실행합니다. 대부분의 realm 명령을 실행하려면 유틸리티에서 수행해야 하는 작업과 작업을 수행할 도메인 또는 사용자 계정과 같은 엔터티를 지정해야 합니다.
| 명령 | 설명 |
|---|---|
| 영역 명령 | |
| discover | 네트워크에서 도메인에 대한 검색 검사를 실행합니다. |
| join | 지정된 도메인에 시스템을 추가합니다. |
| 자주 묻는 질문 | 지정된 도메인에서 시스템을 제거합니다. |
| list | 시스템에 대해 구성된 모든 도메인 또는 검색 및 구성된 모든 도메인을 나열합니다. |
| 로그인 명령 | |
| 허용 | 특정 사용자 또는 구성된 도메인 내 모든 사용자에 대한 액세스를 활성화하여 로컬 시스템에 액세스합니다. |
| deny | 특정 사용자 또는 구성된 도메인 내 모든 사용자에 대한 액세스 권한을 제한하여 로컬 시스템에 액세스합니다. |
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 도메인 컨트롤러에 대한 연결을 설정할 수 있습니다.
Expand 소스 포트 대상 포트 프로토콜 서비스 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 New Vault password: <vault_password> Confirm New Vault password: <vault_password>
$ ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ansible-vault create명령이 편집기를 열고 <key > : < value> 형식으로 중요한 데이터를 입력합니다.usr: administrator pwd: <password>
usr: administrator pwd: <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 변경 사항을 저장하고 편집기를 종료합니다. Ansible은 자격 증명 모음의 데이터를 암호화합니다.
다음 콘텐츠를 사용하여 플레이북 파일(예:
~/playbook.yml)을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예제 플레이북에 지정된 설정은 다음과 같습니다.
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역할은timesyncRHEL 시스템 역할을 활용하여 관리 노드에서 시간 동기화를 구성하지 않습니다.
플레이북에 사용되는 모든 변수에 대한 자세한 내용은 제어 노드의
/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.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.
Playbook을 실행합니다.
ansible-playbook --ask-vault-pass ~/playbook.yml
$ ansible-playbook --ask-vault-pass ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
관리 노드에서 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
$ 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/bashCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4장. AD에 대한 직접 연결 관리 링크 복사링크가 클립보드에 복사되었습니다!
SSSD(System Security Services Daemon) 또는 Samba Winbind를 사용하여 RHEL(Red Hat Enterprise Linux) 시스템을 AD(Active Directory)에 연결할 수 있습니다. 이 섹션에서는 RHEL 시스템이 AD 클라이언트로 이미 구성된 경우 AD 연결을 수정하고 관리하는 방법을 설명합니다.
사전 요구 사항
- 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_daysCopy to Clipboard Copied! Toggle word wrap Toggle overflow SSSD를 다시 시작합니다.
systemctl restart sssd
# systemctl restart sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
자동 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.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고클라이언트가 도메인을 벗어나면 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! Toggle word wrap Toggle overflow
명령은 먼저 자격 증명 없이 연결을 시도하지만 필요한 경우 암호를 입력하라는 메시지가 표시됩니다.
검증
도메인이 더 이상 구성되지 않았는지 확인합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3. SSSD에서 짧은 AD 사용자 이름을 확인하도록 도메인 확인 순서 설정 링크 복사링크가 클립보드에 복사되었습니다!
SSSD 서비스를 사용하여 AD에 연결된 RHEL 호스트의 AD(Active Directory) 사용자 및 그룹을 해결하려면 기본적으로 정규화된 사용자 이름(예: ad_username@ad.example.com 및 group@ad.example.com )을 지정해야 합니다.
이 절차에서는 SSSD 구성에서 도메인 확인 순서를 설정하여 ad_username 과 같은 짧은 이름을 사용하여 AD 사용자 및 그룹을 확인할 수 있도록 합니다. 이 예제 구성은 다음과 같은 순서로 사용자 및 그룹을 검색합니다.
-
Active Directory (AD) 하위 도메인
subdomain2.ad.example.com -
AD 하위 도메인
subdomain1.ad.example.com -
AD root 도메인
ad.example.com
사전 요구 사항
- SSSD 서비스를 사용하여 RHEL 호스트를 AD에 직접 연결합니다.
절차
-
텍스트 편집기에서
/etc/sssd/sssd.conf파일을 엽니다. 파일의
[sssd]섹션에서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.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 파일을 저장한 후 닫습니다.
SSSD 서비스를 다시 시작하여 새 구성 설정을 로드합니다.
systemctl restart sssd
[root@ad-client ~]# systemctl restart sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
짧은 이름만 사용하여 첫 번째 도메인에서 사용자에 대한 사용자 정보를 검색할 수 있는지 확인합니다.
id <user_from_subdomain2> uid=1916901142(user_from_subdomain2) gid=1916900513(domain users) groups=1916900513(domain users)
[root@ad-client ~]# id <user_from_subdomain2> uid=1916901142(user_from_subdomain2) gid=1916900513(domain users) groups=1916900513(domain users)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4. 도메인 사용자의 로그인 권한 관리 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 도메인 측 액세스 제어가 적용되므로 AD(Active Directory) 사용자에 대한 로그인 정책이 AD 도메인 자체에 정의되어 있습니다. 클라이언트 쪽 액세스 제어를 사용하도록 이 기본 동작을 재정의할 수 있습니다. 클라이언트 측 액세스 제어를 사용하면 로컬 정책에 의해서만 로그인 권한을 정의합니다.
도메인이 클라이언트 측 액세스 제어를 적용하는 경우 realmd 를 사용하여 해당 도메인에서 사용자에 대한 기본 허용 또는 액세스 규칙을 구성할 수 있습니다.
액세스 규칙은 시스템의 모든 서비스에 대한 액세스를 허용하거나 거부합니다. 특정 시스템 리소스 또는 도메인에 더 구체적인 액세스 규칙을 설정해야 합니다.
4.4.1. 도메인 내 사용자에 대한 액세스 활성화 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 AD(Active Directory) 사용자에 대한 로그인 정책은 AD 도메인 자체에 정의되어 있습니다. 이 기본 동작을 재정의하고 AD 도메인 내의 사용자에 대한 액세스를 활성화하도록 RHEL 호스트를 구성하려면 다음 절차를 따르십시오.
realm permit -x.x를 사용하는 특정 사용자에게만 거부하면서 기본적으로 모두에 대한 액세스를 허용하지 않는 것이 좋습니다. 대신 모든 사용자에 대해 기본 액세스 정책 없음 정책을 유지하고 영역 허용 권한을 사용하여 선택한 사용자에게만 액세스 권한을 부여할 것을 권장합니다.
사전 요구 사항
- RHEL 시스템은 Active Directory 도메인의 멤버입니다.
절차
모든 사용자에게 액세스 권한을 부여합니다.
realm permit --all
# realm permit --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 특정 사용자에게 액세스 권한을 부여합니다.
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! Toggle word wrap Toggle overflow
현재는 신뢰할 수 있는 도메인의 사용자가 아닌 기본 도메인의 사용자에 대한 액세스만 허용할 수 있습니다. 사용자 로그인에 도메인 이름이 포함되어 있어야 하고 SSSD가 현재 사용 가능한 하위 도메인에 대한 정보를 제공할 수 없기 때문입니다.
검증
SSH를 사용하여 서버에
aduser01@example.com사용자로 로그인합니다.ssh aduser01@example.com@server_name [aduser01@example.com@server_name ~]$
$ ssh aduser01@example.com@server_name [aduser01@example.com@server_name ~]$Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh 명령을 두 번째로 사용하여 이번에는
aduser02@example.com사용자와 동일한 서버에 액세스합니다.ssh aduser02@example.com@server_name Authentication failed.
$ ssh aduser02@example.com@server_name Authentication failed.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 호스트를 구성하려면 다음 절차를 따르십시오.
특정 사용자 또는 그룹에 대한 액세스만 허용하는 것보다 일부에 대한 액세스를 거부하는 것 외에도 다른 사용자 또는 그룹에 대한 액세스만 허용하는 것이 더 안전합니다. 따라서 realm permit -x 가 있는 특정 사용자에게만 거부하고 기본적으로 모든 액세스 권한을 허용하지 않는 것이 좋습니다. 대신 모든 사용자에 대해 기본 액세스 정책 없음 정책을 유지하고 영역 허용 권한을 사용하여 선택한 사용자에게만 액세스 권한을 부여할 것을 권장합니다.
사전 요구 사항
- RHEL 시스템은 Active Directory 도메인의 멤버입니다.
절차
도메인 내 모든 사용자에 대한 액세스를 거부합니다.
realm deny --all
# realm deny --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은
영역계정이 로컬 시스템에 로그인하지 못하도록 합니다.realm permit을 사용하여 특정 계정에 대한 로그인을 제한합니다.도메인 사용자의
login-policy가deny-any-login으로 설정되어 있는지 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -x옵션을 사용하여 특정 사용자에 대한 액세스를 거부합니다.realm permit -x 'AD.EXAMPLE.COM\aduser02'
$ realm permit -x 'AD.EXAMPLE.COM\aduser02'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
SSH를 사용하여 서버에
aduser01@example.net사용자로 로그인합니다.ssh aduser01@example.net@server_name Authentication failed.
$ ssh aduser01@example.net@server_name Authentication failed.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
sssd.conf 파일에서 use_fully_qualified_names 를 true로 설정하면 모든 요청이 정규화된 도메인 이름을 사용해야 합니다. 그러나 use_fully_qualified_names 를 false로 설정하면 요청에 정규화된 이름을 사용할 수 있지만 간소화된 버전만 출력에 표시됩니다.
4.5. RHEL에서 그룹 정책 오브젝트 액세스 제어 적용 링크 복사링크가 클립보드에 복사되었습니다!
그룹 정책 개체 (GPO)는 AD(Microsoft Active Directory)에 저장된 액세스 제어 설정 컬렉션입니다. administrators는 AD에 EgressIPs를 지정하면 관리자가 AD에 가입한 Windows 클라이언트와 RHEL(Red Hat Enterprise Linux) 호스트 둘 다에서 준수하는 로그인 정책을 정의할 수 있습니다.
다음 섹션에서는 사용자 환경에서 GPO를 관리하는 방법에 대해 설명합니다.
4.5.1. SSSD에서 EgressIP 액세스 제어 규칙을 해석하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 SSSD는 AD(Active Directory) 도메인 컨트롤러에서 GPG(그룹 정책 개체)를 검색하고 이를 평가하여 사용자가 AD에 결합된 특정 RHEL 호스트에 로그인할 수 있는지 확인합니다.
SSSD는 AD Windows Logon Rights 를 PAM(Plugable Authentication Module) 서비스 이름에 매핑하여 GNU/Linux 환경에서 이러한 권한을 적용합니다.
AD Administrator는 EgressIP 규칙의 범위를 보안 필터에 나열하여 특정 사용자, 그룹 또는 호스트로 제한할 수 있습니다.
호스트 필터링에 대한 제한
이전 버전의 SSSD는 AD EgressIP 보안 필터의 호스트를 평가하지 않습니다.
- RHEL 8.3.0 이상: SSSD는 보안 필터의 사용자, 그룹 및 호스트를 지원합니다.
-
8.3.0 이전의 RHEL 버전: SSSD는 호스트 항목을 무시하고 보안 필터의 사용자 및 그룹만 지원합니다.
SSSD가 fsGroup 기반 액세스 제어를 특정 호스트에 적용하도록 하려면 AD 도메인에서 새 OU(조직 단위)를 만들고 시스템을 새 OU로 이동한 다음 EgressIP를 이 OU에 연결합니다.
그룹 필터링에 대한 제한 사항
SSSD는 현재 SID(Security Identifier) S-1-5-32-544 와 같은 Active Directory의 기본 제공 그룹을 지원하지 않습니다. Red Hat은 RHEL 호스트를 대상으로 하는 AD EgressIPs에서 AD 기본 제공 그룹을 사용하지 않는 것이 좋습니다.
4.5.2. SSSD에서 지원하는 EgressIP 설정 목록 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 Windows의 그룹 정책 관리 편집기에 지정된 대로 Active Directory options에 해당하는 SSSD 옵션을 보여줍니다.
| EgressIP 옵션 | 해당 sssd.conf 옵션 |
|---|---|
|
로컬에 대한 로그 허용 |
|
|
원격 데스크톱 서비스를 통해 로그온 허용 |
|
|
네트워크에서 이 컴퓨터에 액세스 |
|
|
배치 작업으로 로그인 허용 |
|
|
서비스로 로그인 허용 |
|
4.5.3. nmap 적용 제어를 위한 SSSD 옵션 목록 링크 복사링크가 클립보드에 복사되었습니다!
다음 SSSD 옵션을 설정하여 EgressIP 규칙의 범위를 제한할 수 있습니다.
ad_gpo_access_control 옵션
/etc/sssd/sssd.conf 파일에서 ad_gpo_access_control 옵션을 설정하여 usually 기반 액세스 제어가 작동하는 세 가지 모드 중에서 선택할 수 있습니다.
| 값 of ad_gpo_access_control | 동작 |
|---|---|
|
|
CloudEvent 기반 액세스 제어 규칙이 평가되고 적용됩니다. |
|
|
EgressIP 기반 액세스 제어 규칙은 평가되지만 적용되지 않습니다. 액세스가 거부될 때마다 |
|
| EgressIP 기반 액세스 제어 규칙은 평가되거나 적용되지 않습니다. |
ad_gpo_implicit_deny 옵션
ad_gpo_implicit_deny 옵션은 기본적으로 False 로 설정됩니다. 이 기본 상태에서는 해당하는 EgressIPs를 찾을 수 없는 경우 사용자가 액세스가 허용됩니다. 이 옵션을 True 로 설정하면 EgressIP 규칙이 있는 사용자의 액세스를 명시적으로 허용해야 합니다.
이 기능을 사용하여 보안을 강화할 수 있지만 의도하지 않게 액세스를 거부하지 않도록 주의하십시오. ad_gpo_access_control 이 허용 으로 설정되어 있는 동안 이 기능을 테스트하는 것이 좋습니다.
다음 두 테이블은 사용자가 AD 서버 측에 정의된 허용 및 거부 권한 및 ad_gpo_implicit_deny 의 값을 기반으로 사용자가 허용되거나 거부되는 경우를 보여줍니다.
| allow-rules | deny-rules | 결과 |
|---|---|---|
| 누락됨 | 누락됨 | 모든 사용자가 허용됩니다. |
| 누락됨 | Exists | 거부 규칙에 없는 사용자만 허용됩니다. |
| Exists | 누락됨 | allow-rules의 사용자만 허용 |
| Exists | Exists | allow-rules에 있는 사용자와 deny-rules에 포함되지 않은 사용자만 허용됩니다. |
| allow-rules | deny-rules | 결과 |
|---|---|---|
| 누락됨 | 누락됨 | 사용자가 허용되지 않음 |
| 누락됨 | Exists | 사용자가 허용되지 않음 |
| Exists | 누락됨 | allow-rules의 사용자만 허용 |
| Exists | Exists | allow-rules에 있는 사용자와 deny-rules에 포함되지 않은 사용자만 허용됩니다. |
4.5.4. EgressIP 액세스 제어 모드 변경 링크 복사링크가 클립보드에 복사되었습니다!
이 절차에서는 EgressIP 기반 액세스 제어 규칙을 평가하여 RHEL 호스트에 AD(Active Directory) 환경에 적용하는 방법을 변경합니다.
이 예제에서는 tests의 작업 모드를 강제 (기본값)에서 테스트 목적으로 허용으로 변경합니다.In this example, you will change the EgressIP operation mode from enforcing (the default) to permissive for testing purposes.
다음과 같은 오류가 표시되면 Active Directory 사용자가 GPO 기반 액세스 제어로 인해 로그인할 수 없습니다.
/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! Toggle word wrap Toggle overflow /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! Toggle word wrap Toggle overflow
바람직하지 않은 동작인 경우 AD의 적절한 EgressIP 설정 문제를 해결하는 동안 이 절차에 설명된 대로 ad_gpo_access_control 을 일시적으로 허용 으로 설정할 수 있습니다.
사전 요구 사항
- SSSD를 사용하여 AD 환경에 RHEL 호스트에 참여했습니다.
-
/etc/sssd/sssd.conf설정 파일을 편집하려면root권한이 필요합니다.
절차
SSSD 서비스를 중지합니다.
systemctl stop sssd
[root@server ~]# systemctl stop sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
텍스트 편집기에서
/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! Toggle word wrap Toggle overflow -
/etc/sssd/sssd.conf파일을 저장합니다. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.
systemctl restart sssd
[root@server ~]# systemctl restart sssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.5. AD GUI에서 RHEL 호스트에 대한 EgressIP 생성 및 구성 링크 복사링크가 클립보드에 복사되었습니다!
그룹 정책 개체(GPO)는 AD(Microsoft Active Directory)에 저장된 액세스 제어 설정 컬렉션입니다. 다음 절차에서는 AD GUI(그래픽 사용자 인터페이스)에 EgressIP을 생성하여 AD 도메인에 직접 통합된 RHEL 호스트에 대한 로그온 액세스를 제어합니다.
사전 요구 사항
- SSSD를 사용하여 AD 환경에 RHEL 호스트에 참여했습니다.
- GUI를 사용하여 AD를 변경할 수 있는 AD 관리자 권한이 있어야 합니다.
절차
Active Directory 사용자 및 컴퓨터내에서 OU(Organizational Unit)를 만들어 새 EgressIP과 연결합니다.- 도메인을 마우스 오른쪽 버튼으로 클릭합니다.
-
새로 생성을선택합니다. -
조직 단위를 선택합니다.
- RHEL 호스트(Active Directory에 참여할 때 생성된)를 나타내는 Computer Object의 이름을 클릭하고 새 OU로 끌어 옵니다. 자체 OU에 RHEL 호스트를 보유함으로써 EgressIP는 이 호스트를 대상으로 합니다.
그룹 정책 관리 편집기에서 만든 OU에 대한 새 GPO를 만듭니다.-
Forest펼치기입니다. -
도메인을 확장합니다. - 도메인을 확장합니다.
- 새 OU를 마우스 오른쪽 버튼으로 클릭합니다.
-
이 도메인에서
Create a EgressIP in this domain을 선택합니다.
-
-
Allow SSH 액세스 또는권한과 같은 새 EgressIP의 이름을 지정하고Allow Console/GUI 액세스확인을클릭합니다. 새 EgressIP을 편집합니다.
-
그룹 정책 관리편집기에서 OU를 선택합니다. -
마우스 오른쪽 버튼으로 클릭하고
편집을 선택합니다. -
사용자 권한 할당을 선택합니다. -
컴퓨터 구성선택 -
정책을선택합니다. -
Windows 설정을선택합니다. -
보안 설정을선택합니다. -
로컬 정책을선택합니다. -
사용자 권한 할당을 선택합니다.
-
로그인 권한을 할당합니다.
-
로컬 콘솔/GUI에
대한 액세스 권한을 부여하려면 허용 로그를 두 번 클릭합니다. -
원격 데스크탑 서비스를 통해 로그를두 번 클릭하여 SSH 액세스 권한을 부여합니다.
-
로컬 콘솔/GUI에
이러한 정책 중 하나에 액세스하려는 사용자를 정책 자체에 추가합니다.
-
사용자 또는 그룹 추가를클릭합니다. - 빈 필드 내에 사용자 이름을 입력합니다.
-
OK를 클릭합니다.
-
5장. 관리 서비스 계정을 사용하여 AD에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
Active Directory (AD) 관리 서비스 계정 (MSAs)을 사용하면 특정 컴퓨터에 해당하는 AD에서 계정을 만들 수 있습니다. RHEL 호스트를 AD 도메인에 가입하지 않고 MSA를 사용하여 특정 사용자 주체로 AD 리소스에 연결할 수 있습니다.
이 섹션에서는 다음 항목에 대해 설명합니다.
5.1. 관리형 서비스 계정의 이점 링크 복사링크가 클립보드에 복사되었습니다!
RHEL 호스트가 가입하지 않고 AD(Active Directory) 도메인에 액세스하도록 허용하려면 MSA(관리 서비스 계정)를 사용하여 해당 도메인에 액세스할 수 있습니다. MSA는 특정 컴퓨터에 해당하는 AD 계정이며 특정 사용자 보안 주체로 AD 리소스에 연결하는 데 사용할 수 있습니다.An MSA is an account in AD that corresponds to a specific computer, which you can use to connect to AD resources as a specific user principal.
예를 들어 AD 도메인 production.example.com 에 lab.example.com AD 도메인과의 단방향 신뢰 관계가 있는 경우 다음 조건이 적용됩니다.
-
랩도메인은production도메인에서 사용자 및 호스트를 신뢰합니다. -
production도메인은랩도메인에서 사용자 및 호스트를 신뢰하지 않습니다.
즉, client. 과 같은 랩 도메인에 연결된 호스트는 신뢰를 통해 lab.example.comproduction 도메인의 리소스에 액세스할 수 없습니다.
client.lab.example.com 호스트에 대한 예외를 생성하려면 adcli 유틸리티를 사용하여 production.example.com 도메인에서 클라이언트 호스트에 대한 MSA를 생성할 수 있습니다. MSA의 Kerberos 주체로 인증하면 클라이언트 호스트에서 프로덕션 도메인에서 보안 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 도메인 컨트롤러에서 액세스할 수 있는지 확인합니다.
Expand 서비스 포트 프로토콜 DNS
53
TCP, UDP
LDAP
389
TCP, UDP
LDAPS(선택 사항)
636
TCP, UDP
Kerberos
88
TCP, UDP
-
production.example.com도메인에 MSA를 생성할 수 있는 권한이 있는 AD Administrator의 암호가 있습니다. -
adcli명령을 실행하고/etc/sssd/sssd.conf구성 파일을 수정하는 데 필요한 루트 권한이 있습니다. -
(선택 사항)
klist진단 유틸리티를 포함하는krb5- workstation패키지가 설치되어 있습니다.
절차
production.example.comAD 도메인에 호스트에 대한 MSA를 생성합니다.adcli create-msa --domain=production.example.com
[root@client ~]# adcli create-msa --domain=production.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 생성된 Kerberos 키 탭에서 MSA에 대한 정보를 표시합니다. MSA 이름을 기록해 둡니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/sssd/sssd.conf파일을 열고 다음을 추가할 적절한 SSSD 도메인 구성을 선택합니다.MSA가 다른 포리스트의 AD 도메인에 해당하는 경우
[domain/<name_of_domain>] 이라는 새 도메인 섹션을 만들고 MSA 및 keytab에 대한 정보를 입력합니다. 가장 중요한 옵션은ldap_sasl_authid,ldap_krb5_keytab,krb5_keytab입니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow MSA가 지역 산포의 AD 도메인에 해당하는 경우
[domain/root.example.com/sub-domain.example.com]형식으로 새 하위 도메인 섹션을 만들고 MSA 및 키 탭에 대한 정보를 입력합니다. 가장 중요한 옵션은ldap_sasl_authid,ldap_krb5_keytab,krb5_keytab입니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
Kerberos 티켓 확장 티켓(TGT)을 MSA로 검색할 수 있는지 확인합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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입니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow production.example.comAD 도메인에서 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=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
Kerberos 키 탭에서 KVNO가 증가했는지 확인합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. 관리형 서비스 계정 사양 링크 복사링크가 클립보드에 복사되었습니다!
adcli 유틸리티에서 생성하는 MSA(관리형 서비스 계정)에는 다음과 같은 사양이 있습니다.
- 추가 서비스 주체 이름(SPN)을 사용할 수 없습니다.
-
기본적으로 MSA의 Kerberos 주체는
/etc/krb5.저장됩니다.keytab.example.com과 같이 <default_keytab_location>.<Active_Directory_domain>이라는 Kerberos 키 탭에 이름은 20자로 제한됩니다.Names are limited to 20 characters. 마지막 4자의 접미사는 숫자와 대문자 및 소문자 ASCII 범위로, 입력한 짧은 호스트 이름에 추가되는 ASCII 범위이며 구분 기호로
!문자를 사용합니다. 예를 들어, 짧은 이름이myhost인 호스트는 다음 사양으로 MSA를 수신합니다.Expand 사양 값 CN(Common Name) 특성
myhost!A2cNetBIOS 이름
myhost!A2c$sAMAccountName
myhost!A2c$production.example.comAD 도메인의 Kerberos 사용자myhost!A2c$@PRODUCTION.EXAMPLE.COM
5.5. adcli create-msa 명령의 옵션 링크 복사링크가 클립보드에 복사되었습니다!
adcli 유틸리티에 전달할 수 있는 글로벌 옵션 외에도 다음 옵션을 지정하여 MSA(관리 서비스 계정)를 구체적으로 제어할 수 있습니다.
-N,--computer-name-
Active Directory (AD) 도메인에 생성되는 MSA의 짧은 이름. 이름을 지정하지 않으면
--host-fqdn의 첫 번째 부분이 임의의 접미사와 함께 사용됩니다. -O,--domain-ou=OU=<path_to_OU>-
MSA를 만드는 OU(조직 단위)의 전체 고유 이름입니다. 이 값을 지정하지 않으면 MSA가 기본 위치
OU=CN=Managed Service Accounts,DC=EXAMPLE,DC=COM에 생성됩니다. -H,--host-fqdn=host- 로컬 시스템의 정규화된 DNS 도메인 이름을 재정의합니다. 이 옵션을 지정하지 않으면 로컬 시스템의 호스트 이름이 사용됩니다.
-K,--host-keytab=<path_to_keytab>-
MSA 자격 증명을 저장할 호스트 키탭의 경로입니다. 이 값을 지정하지 않으면 기본 위치
/etc/krb5.keytab이 /etc/krb5.keytab.com과 같이 접미사로 추가된 소문자 Active Directory 도메인이름과 함께 사용됩니다. --use-ldaps- LDAP(Secure LDAP) 채널을 통해 MSA를 생성합니다.
--verbose- MSA를 만드는 동안 자세한 정보를 인쇄합니다.
--show-details- MSA를 생성한 후 MSA에 대한 정보를 출력합니다.
--show-password- MSA를 만든 후 MSA 암호를 인쇄합니다.