RHEL 또는 기타 Linux 머신을 Microsoft Active Directory에 직접 조인

네트워크 상의 시스템에 대한 액세스를 관리하는 것은 어려울 수 있습니다. 관리자가 모든 머신에서 모든 사용자를 생성하거나, SSH 키 또는 비밀번호를 사용하여 계정을 공유하는 경우도 있으며, LDAP 바인딩(때때로 기존 Active Directory 인프라 또는 별도 도메인 사용)을 사용하여 액세스를 필터링하기 위해 LDAP 쿼리를 작성해야 하는 경우도 있습니다.

이러한 모든 방법으로 인해 머신에 대한 액세스를 관리가 어려워지며, 누군가 팀을 옮기거나 새로 합류할 때 관리자에게 알려야 합니다. 공유 계정을 사용하면 모두가 동일한 사용자 이름을 갖게 되어 로깅이 대부분 무용지물이 될 수 있습니다. 인사 부서에서 팀의 변동 사항을 기술 팀에 알릴 때 불편을 겪은 경우가 저뿐만은 아닐 것입니다. 하지만 이 모든 것을 해결할 수 있는 솔루션이 있습니다. 이는 잘 작동하며 일반적인 엔터프라이즈 설정과도 통합됩니다.

제가 접해본 대부분의 기업은 Microsoft Active Directory(AD)에서 사용자 계정을 자동으로 생성, 비활성화 또는 삭제하는 일종의 ERP 시스템을 갖추고 있습니다. 따라서 다른 사람들이 하는 작업을 활용할 수 있습니다. 예를 들어, SSSD는 AD에 직접 연결할 수 있습니다.

AD를 신뢰하는 Linux용 인증 서버를 설정한 적이 있다면, SSSD가 AD 서버와 통신하도록 설정한 것입니다. 트러스트 작동 방식을 보면, 설정한 인증 서버가 참조를 AD 서버로 반환하여 SSSD가 AD 서버를 직접 쿼리하게 됩니다. 다음 설정에서는 추가 인증 서버 필요 없이 SSSD를 먼저 AD에 직접 연결하도록 구성합니다.

일반적으로 제기되는 다음 질문은 액세스를 어떻게 제어할 것인가입니다. 여기에서 역할 기반 액세스 제어(RBAC)가 필요합니다. RBAC를 사용하면 사용자에게 액세스 권한을 할당하는 대신 역할에 액세스 권한을 할당할 수 있습니다. 그룹을 구성한 후에는 이미 서버 그룹에 대한 적절한 액세스 권한을 가진 역할의 일부인 팀에 새로운 팀 구성원을 할당할 수 있습니다. 이렇게 하면 "새로 입사했는데 OOO와 동일한 액세스 권한이 필요합니다"라며 몇 달 전에 퇴사해 모든 액세스 권한이 제거된 사람을 참조하는 요청을 피할 수 있습니다.

대신 새 사용자를 팀의 그룹에 추가하면 필요한 액세스 권한을 갖게 됩니다. 또한 1년 전에 퇴사한 사람의 퇴사 사실을 아무도 관리자에게 알리지 않았기 때문에 퇴사자가 여전히 모든 서버에 액세스할 수 있다는 사실을 뒤늦게 알게 되는 일도 없습니다. ERP 시스템에서 AD 계정을 자동으로 업데이트하면 모든 액세스 권한이 제거됩니다.

한때는 Windows 이외의 운영 체제에서 AD를 관리하는 것이 어려웠습니다. 그러나 Microsoft가 Windows Admin Center를 릴리스하면서 어떤 운영 체제에서 실행되는 어떤 브라우저에서도 Active Directory 사용자 및 컴퓨터에 직접 액세스할 수 있게 되었습니다. 또한 다양한 기타 Windows 관리 툴에도 액세스할 수 있습니다. Windows 서버에 설치하면 세션 제한을 걱정할 필요가 없고 RemoteApp 사용에도 어려움이 없습니다. 브라우저를 시작하고 웹 인터페이스에 액세스하기만 하면 됩니다.

역할 기반 액세스 제어를 위한 AD 그룹 구성

각 기업의 명명 체계는 이 문서의 예시와 다를 수 있습니다. 그룹 이름은 중요하지 않습니다. 각 그룹의 용도가 중요합니다.

SSSD는 AD 그룹을 동기화하지 않고 로그인 프로세스 중에 사용자가 속한 그룹 목록만 가져오기 때문에, 누락된 그룹이 있어도 이 설정이 작동하는 데는 문제가 없습니다. 그러나 AD 내에 위임된 권한을 가진 팀이 여러 개인 경우, 잘못된 조직 단위(Organizational Unit, OU)에 그룹이 생성되어 잘못된 팀이 액세스 제어 권한을 갖게 되는 것을 방지하기 위해 모든 그룹을 생성하는 것이 좋습니다.

특정 머신에 대한 액세스

각 머신에 대해 Active Directory 내에 두 개의 그룹을 생성합니다. 두 그룹 모두 머신의 짧은 이름을 포함해야 합니다. 

한 그룹은 머신별 SSH 액세스를 위한 그룹입니다(이 문서에서는 Machine_SSH_Access로 지칭).

다른 그룹은 머신별 sudo 액세스를 제공합니다(이 문서에서는 Machine_SUDO_Access로 지칭).

그룹 포맷의 예는 다음과 같습니다.

<DOMAIN> Linux <hostname> ssh access
<DOMAIN> Linux <hostname> sudo access

• <hostname>은 머신의 짧은 이름입니다.
• <DOMAIN>은 도메인의 짧은 이름이며 선택 사항입니다.

모든 머신에 대한 액세스

글로벌 머신 액세스를 위해 Active Directory 내에 두 개의 그룹을 생성합니다.

한 그룹은 모든 머신에 대한 SSH 액세스(이 문서에서는 Global_SSH_Access로 지칭)를 위한 그룹입니다.

다른 그룹은 모든 머신에 대한 sudo 액세스(이 문서에서는 Global_SUDO_Access로 지칭)를 위한 그룹입니다.

그룹 포맷의 예는 다음과 같습니다.

<DOMAIN> Linux ssh access
<DOMAIN> Linux sudo access

<DOMAIN>은 도메인의 짧은 이름이며 선택 사항입니다.

중첩(Nesting)

AD 그룹 내에서 중첩이 허용됩니다. 여러 머신에 대한 액세스 권한을 가진 그룹을 생성하려면 RHEL 머신의 구성을 변경할 필요가 없습니다. 대신 새 그룹을 특정 머신에 대한 액세스 그룹의 구성원으로 만들 수 있습니다. 이렇게 하면 AD에서 직접 액세스를 제어할 수 있습니다.

중첩 예시:

• CONTOSO Linux Webserver1 ssh access
  • CONTOSO Linux Webservers ssh access
    • CONTOSO Web Developers
      • User1
      • User2

이 중첩을 사용하면 특정 머신에 사용자를 할당하는 대신 역할(CONTOSO Web Developers)을 머신 그룹(CONTOSO Linux Webservers ssh access)에 할당할 수 있습니다.

Linux 머신의 도메인 조인

현재 환경에서 RC4가 활성화되어 있는 경우, Microsoft의 보안 권고에 따라 지금 비활성화하세요.

Linux 머신을 도메인에 조인하려면 다음을 수행합니다.

1. 필수 패키지를 설치합니다.

$ sudo dnf install -y chrony krb5-workstation \
samba-common-tools oddjob-mkhomedir samba-common \
sssd authselect

2. /etc/sssd/pki/sssd_auth_ca_db.pem을 생성하고 도메인의 CA 체인을 작성하여 도메인의 CA 체인을 추가합니다. 여기에는 도메인 컨트롤러(Domain Controllers, DC) 자체에 대한 인증서를 포함하지 않아도 됩니다. 해당 인증서를 서명한 인증서로 시작할 수 있습니다.
3. CA 체인을 시스템의 트러스트 앵커에 추가합니다.

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

4. /etc/sssd/sssd.conf 또는 /etc/sssd/conf.d/<DOMAIN>.conf를 편집하여 SSSD를 구성하고 다음 줄과 일치시킵니다.

/etc/sssd/conf.d/<DOMAIN>.conf를 편집하는 것이 현대적이고 선호되는 방법이지만 /etc/sssd/sssd.conf를 편집해도 됩니다.

[domain/<DOMAIN>]
access_provider = simple
auth_provider = ad
chpass_provider = ad
id_provider = ad
dyndns_update = true
override_homedir = /home/%u
override_shell = /bin/bash
default_shell = /bin/bash
ldap_idmap_range_size = 4000000
cache_credentials = true
simple_allow_groups = Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access, Machine_SUDO_Access
ignore_group_members = true
ad_gpo_access_control = disabled
ad_enable_gc = false
ad_use_ldaps = true
[sssd]
services = nss, pam
config_file_version = 2
domains = <DOMAIN>

• <DOMAIN>은 도메인의 FQDN이며 모두 대문자로 입력한 것입니다. 모두 대문자로 사용하지 않으면 인증 문제가 발생할 수 있습니다.
• ldap_idmap_range_size는 선택 사항입니다. 이는 대규모 AD 환경이 있는 경우 필요합니다. 이 값을 변경하면 UID 해시가 변경되므로 머신이 도메인에 조인된 후에는 변경하지 말고, 모든 머신에서 동일한 값을 사용해야 합니다.
• Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access, Machine_SUDO_Access는 위에서 RBAC에 대해 생성한 AD 그룹입니다.

5. 방금 작성한 파일에 대한 권한을 설정합니다. /etc/sssd/sssd.conf 또는 /etc/sssd/conf.d/<DOMAIN>.conf:

$ sudo chmod 400 /etc/sssd/sssd.conf

또는

$ sudo chmod 400 /etc/sssd/conf.d/*.conf

6. /etc/krb5.conf를 편집하여 KRB5를 구성하고 다음 줄과 일치시킵니다.

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = true
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = <DOMAIN>
[realms]
[domain_realm]

[realms] 또는 [domain_realm]에 아무것도 지정할 필요가 없습니다. SSSD는 DNS에서 해당 정보를 자동으로 검색합니다.

7. /etc/sudoers.d에 파일을 생성하여 SUDO 액세스를 구성합니다.

$ sudo visudo -f /etc/sudoers.d/<DOMAIN>

AD sudo 그룹의 구성원에 대한 기본 sudo 액세스 권한을 지정합니다. 파일 이름은 원하는 대로 지정할 수 있으며 DOMAIN으로 지정할 필요는 없습니다.

공백은 백슬래시(\)를 사용하여 이스케이프해야 합니다. 예를 들어, "Linux sudo access"는 "Linux\ sudo\ access"로 작성해야 합니다.

%Global_SUDO_Access  ALL=(ALL) ALL
%Machine_SUDO_Access  ALL=(ALL) ALL

Global_SUDO_Access 및 Machine_SUDO_Access는 RBAC에 대해 생성한 AD 그룹입니다. 그룹 이름 앞에 있는 백분율 기호(%)는 그룹임을 나타냅니다.

AD 그룹에 다른 sudo 액세스를 부여하려는 경우 별도의 파일이나 동일한 파일에서 동일한 방식으로 정의할 수 있습니다.

8. 머신의 호스트 이름이 FQDN으로 설정되어 있는지 확인합니다. 머신 호스트 이름은 짧은 이름일 수 없습니다.

$ sudo hostnamectl set-hostname $(hostname -f)

9. 다음 명령 중 하나를 사용하여 머신을 조인합니다(adcli는 SMBv1 및 SMBv2와 호환됨). 조인하는 동안 AD 내에 OS 정보를 설정하려면 다음 명령을 사용합니다.

$ source /etc/os-release
$ sudo adcli join -U <join_user> --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

또는 OS 정보를 설정하지 않고 조인할 수도 있습니다.

$ sudo adcli join -U <join_user>

<join_user> 는 머신을 도메인에 조인하는 데 사용되는 AD 계정입니다. adcli에서 요청하는 비밀번호는 저장되지 않습니다. 위임된 권한은 조인에 필요한 권한을 설명합니다.

10. SSSD 및 oddjobd를 활성화하고 시작합니다.

$ sudo systemctl enable sssd oddjobd
$ sudo systemctl restart sssd oddjobd

11. AD로 로그인하도록 활성화합니다.

$ sudo authselect select sssd with-mkhomedir --force

계정이 사용자가 생성한 그룹 중 하나의 구성원이라면 이제 머신에 로그인할 수 있습니다. 도메인을 지정할 필요가 없습니다. /etc/krb5.conf에서 default_realm으로 지정된 도메인이 사용됩니다. GNOME을 재시작해야 할 수 있지만, sshd는 일반적으로 재시작 없이도 변경 사항을 수락합니다.

OS 정보를 최신 상태로 유지

기본적으로 컴퓨터 오브젝트에는 자체 OS 정보를 업데이트할 수 있는 권한이 없습니다. Active Directory Users and Computers(ADUAC)로 이동하여 컴퓨터 오브젝트의 각 OS 필드에 대한 쓰기 권한을 SELF에 부여합니다(OU 수준에서 수행할 수 있음). 추가한 후에는 AD 오브젝트를 최신 OS 정보로 업데이트합니다.

$ source /etc/os-release
$ sudo /usr/sbin/adcli update --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

이 작업은 cron 작업 또는 systemd 서비스로 추가할 수 있습니다. 예를 들면 다음과 같습니다.

[Unit]
Description=Updates AD with current OS information
After=sssd.service
[Service]
Type=oneshot
EnvironmentFile=/etc/os-release
ExecStart=/usr/sbin/adcli update --os-name="${NAME}" --os-version="${VERSION}" --os-service-pack="${VERSION_ID}"
[Install]
WantedBy=multi-user.target

스마트 카드 인증 활성화

이 섹션에서는 Windows 머신에서 스마트 카드 인증이 작동한다고 가정합니다. 그렇지 않은 경우 계속하기 전에 Windows 머신에서 스마트 카드 인증을 구성하세요.

1. 도메인의 인증서 체인을 /etc/sssd/pki/sssd_auth_ca_db.pem에 작성합니다. 여기에는 도메인 컨트롤러(DC) 자체에 대한 인증서를 포함하지 않아도 됩니다. 해당 인증서를 서명한 인증서로 시작할 수 있습니다.
2. 머신의 신뢰할 수 있는 CA 목록에 인증서를 추가합니다.

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

3. 시스템을 도메인에 조인할 때 사용한 파일에 따라 /etc/sssd/sssd.conf 또는 /etc/sssd/conf.d/<DOMAIN>.conf를 편집하고, [domain/<DOMAIN>] 섹션 내에 다음 줄을 추가합니다. 이 항목은 SSSD에 사용자 인증서를 찾을 위치를 알려줍니다. Windows는 userCertificate 속성을 사용하므로, 동일한 속성을 사용하면 동일한 스마트 카드가 Linux와 Windows에서 모두 작동합니다.

ldap_user_certificate = userCertificate;binary

동일한 구성 파일의 끝에 다음 줄을 추가합니다.

[pam]
pam_cert_auth = true

4. /etc/krb5.conf를 편집하고 [realms] 아래에 다음 줄을 추가합니다. <DOMAIN>을 도메인의 모두 대문자로 된 FQDN으로 바꿉니다. 이는 Windows는 대소문자를 구분하지 않지만 Linux는 대소문자를 구분하기 때문에 발생할 수 있는 불일치를 해결하기 위한 것입니다.

<DOMAIN> = {
pkinit_anchors = DIR:/etc/sssd/pki
  pkinit_kdc_hostname = <DOMAIN>
}

5. 다음 명령 중 하나를 사용하여 PAM에서 스마트 카드 인증을 활성화합니다.

• authselect enable-feature with-smartcard: 스마트 카드 인증을 옵션으로 허용합니다.
• authselect enable-feature with-smartcard-required: 스마트 카드 인증이 필요합니다. 기본적으로 sshd는 SSH 키로 인증할 때 PAM을 호출하지 않습니다.
• authselect enable-feature with-smartcard-lock-on-removal: 스마트 카드 인증이 필요하며 스마트 카드를 제거하면 머신이 잠깁니다.

스마트 카드 인증서를 사용하여 SSH 액세스 활성화

RHEL 8 이상에서는 스마트 카드를 사용하여 SSH 액세스를 활성화할 수 있습니다.

1. AD에서 스마트 카드 인증서를 올바르게 읽는지 확인합니다.

sss_ssh_authorizedkeys ${USER}

공개 키가 반환되지 않는 경우, 스마트 카드 인증이 올바르게 구성되었는지 확인합니다.

2. /etc/ssh/sshd_config를 편집하여 다음 줄을 추가합니다.

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

3. sshd를 다시 시작합니다.

$ sudo systemctl restart sshd

SSH를 사용하여 클라이언트에서 로그인하려면 PKCS11Provider=/usr/lib64/opensc-pkcs11.so 옵션을 사용합니다. 스마트 카드가 사용자의 공개 키와 일치하면 스마트 카드 PIN 또는 비밀번호를 입력하라는 메시지가 표시됩니다.

$ ssh -o PKCS11Provider=/usr/lib64/opensc-pkcs11.so <host>

추가 정보

이제 도메인에 조인한 머신이 있으며, 역할 기반 액세스 제어를 사용하여 누가 로그인하거나 권한 있는 명령을 실행할 수 있는지를 제어할 수 있습니다. 다른 사람들이 이미 수행하고 있는 작업을 활용할 수 있기 때문에 관리가 훨씬 쉬워집니다. 다음은 몇 가지 주의해야 할 사항입니다.

• AD 내에서 사용자를 비활성화하면 머신에 대한 액세스가 즉시 차단됩니다. Windows와 마찬가지로 이미 로그인한 사용자는 로그인 상태로 유지됩니다.
• 사용자 그룹에 대한 수정 사항은 Windows와 마찬가지로 로그인 중에 업데이트됩니다. 이 작업은 로그인 허용 여부를 확인하기 전에 수행됩니다.
• SSSD는 사이트를 인식합니다. AD 사이트 및 서비스 내에서 사이트를 구성하는 경우 SSSD는 적절한 DC에 연결합니다.
• SSSD는 머신 비밀번호를 자동으로 순환합니다.
• 동적 업데이트(보안 또는 비보안)가 활성화된 경우 SSSD는 머신의 DNS 레코드를 자동으로 생성하고 관리합니다.

저는 보통 Windows 툴을 사용하여 Linux 시스템을 관리하고 Linux 툴을 사용하여 Windows를 관리하는 방법을 권장하지 않습니다. 대개는 중요한 기능이 손실되거나, 보안이 누락되거나, 네이티브 툴로 동일한 작업을 훨씬 더 쉽게 수행할 수 있는 방법이 있기 때문입니다. 그러나 AD에서는 다릅니다. SSSD 개발자들은 AD와 호환되도록 많은 노력을 기울였으며, 결과적으로 작업이 훨씬 수월해졌습니다.