상호 운용성
Active Directory를 사용하여 Linux 클라이언트 인증
공화당원과 민주당원. 치약과 오렌지 주스. Linux와 Windows. 도저히 어울리지 않는 관계로 인식되어 있습니다. 제가 지금까지 겪어 본 모든 IT 환경은 두 진영으로 양분되었습니다. 바로 Windows 팀과 Linux 팀입니다. 사실 이들은 서로 경쟁 관계가 아니지만 협력하지도 않습니다. 심지어 어떤 곳에서는 두 그룹 간의 교제를 철저하게 차단하는 것처럼 바닥에 노란색 선으로 갈라 놓은 곳도 있습니다.
저는 Windows 편이므로 Linux 지향적인 동료들을 놀린 적도 있지만, 우리 모두는 품질이 우수하고 비용 효과적인 IT 서비스를 회사에 공급하겠다는 동일한 목표를 갖고 있습니다. 그 목표를 실현할 수 있는 방법 중 하나는 Active Directory와 같은 핵심 소프트웨어 인프라를 공유하는 것입니다. 거의 모든 IT 조직이 Windows 데스크톱 및 서버에 인증 서비스를 제공하기 위해 Active Directory를 선택했습니다. Linux 환경을 위해 별도의 인증 인프라(및 별도의 사용자 이름 및 암호 집합)를 유지할 필요 없이 Linux 컴퓨터에서도 Active Directory를 사용한다면 좋지 않을까요? 저는 그렇다고 생각합니다. 그래서 이번 기사에서는 그 방법을 소개할까 합니다.
Windows 인증
Windows는 상당히 오래 전부터 통합 네트워크 인증 및 Single Sign-On 시스템을 제공해 왔습니다. Windows 2000이 등장하기 전, Windows NT DC(도메인 컨트롤러)는 NTLM(NT LAN Manager) 프로토콜을 사용하는 Windows 클라이언트에 인증 서비스를 제공했습니다. NTLM이 애초 기대한 만큼의 보안성은 갖추지 못했으나 네트워크상의 여러 서버에서 중복 사용자 계정을 유지 관리해야 하는 문제를 거의 해결했기 때문에 매우 유용했습니다.
Windows 2000부터 Microsoft는 NTLM에서 Active Directory 및 통합 Kerberos 인증 서비스로 옮겨갔습니다. Kerberos는 NTLM보다 훨씬 더 안전했고 확장성도 더 우수했습니다. 게다가 Kerberos는 이미 Linux와 UNIX 시스템에서 사용하던 산업 표준이었던 만큼 이 플랫폼을 Windows와 통합할 수 있는 기회가 열린 셈이었습니다.
Linux 인증
원래 Linux와 Linux에서 실행되는 GNU 도구 및 라이브러리는 단일 인증 메커니즘을 염두에 두고 만들어지지 않았습니다. 그로 인해 Linux 응용 프로그램 개발자들은 인증 체계를 각자 개발하곤 했습니다. 이를 위해 /etc/passwd(Linux 사용자 자격 증명이 포함된 기존 텍스트 파일)에서 이름 및 암호 해시를 조회하거나 전혀 다른(별개의) 메커니즘을 제공하는 방법을 채택했습니다. 그 결과 등장한 각종 인증 메커니즘을 관리하기란 사실상 불가능했습니다. 1995년에 Sun은 PAM(Pluggable Authentication Modules)이라는 메커니즘을 내놓았습니다. PAM은 모든 응용 프로그램 개발자가 사용할 수 있는 공통의 인증 API 집합 그리고 여러 개의 "플러그형" 인증 체계를 허용하는 관리자 구성 가능한 백 엔드를 제공했습니다. 인증에 PAM API를 그리고 사용자 정보 조회에 NSS(Name Server Switch) API를 사용함으로써 Linux 응용 프로그램 개발자는 작성해야 하는 코드의 양을 줄이고 Linux 관리자는 하나의 장소에서 인증 프로세스를 구성하고 관리할 수 있었습니다.
대부분의 Linux 배포판은 몇 개의 PAM 인증 모듈을 함께 제공하며, 그 중에는 LDAP 디렉터리에 대한 인증 그리고 Kerberos를 사용한 인증을 지원하는 모듈도 있습니다. Active Directory에 대한 인증에 이러한 모듈을 사용할 수 있으나, 여기에는 몇 가지 심각한 제한이 있습니다. 그에 관해서는 이 기사의 후반부에서 다루겠습니다.
Samba와 Winbind
Samba는 Windows 및 Linux 환경 간의 통합을 제공하기 위한 공개 소스 프로젝트입니다. Samba는 Linux 컴퓨터에 Windows 파일 및 인쇄 서비스에 대한 액세스를 제공할 뿐 아니라 Windows NT 4.0 DC를 에뮬레이션하는 Linux 기반 서비스까지 제공하는 구성 요소를 포함합니다. Linux 컴퓨터에서는 Samba 클라이언트 구성 요소를 활용하여 Windows NT 및 Active Directory DC에서 제공하는 Windows 인증 서비스를 활용할 수 있습니다.
이 프로젝트에서 가장 흥미를 끄는 Samba 구성 요소가 Winbind입니다. Winbind는 Samba 클라이언트에서 실행되는 데몬(Windows 용어로 표현하면 서비스)으로서 Linux 컴퓨터에서 실행되는 PAM/NSS와 DC에서 실행되는 Active Directory 간의 통신용 프록시 역할을 합니다. 특히 Winbind에서는 Active Directory 및 LDAP 인증에 Kerberos를 사용하여 사용자 및 그룹 정보를 검색합니다. 또한 Winbind는 Active Directory의 DCLOCATOR와 비슷한 알고리즘을 사용하여 DC를 찾는 기능 그리고 RPC를 사용하는 DC와의 통신으로 Active Directory 암호를 재설정하는 기능 등의 추가 서비스도 제공합니다.
Winbind는 Kerberos와 PAM을 함께 사용하는 것으로는 해결할 수 없는 문제 몇 가지를 해결합니다. 특히 PAM Kerberos 모듈의 방식대로 인증하기 위해 DC를 하드코딩할 필요 없이 Winbind가 Microsoft DC LOCATOR 모듈과 비슷한 방식으로 DNS 로케이터 레코드를 검색하여 DC를 선택합니다.
세 가지 인증 전략
Linux 시스템에서 LDAP, Kerberos와 Winbind가 지원됨에 따라 Linux 컴퓨터에서 Active Directory를 통한 인증이 가능하도록 세 가지 구현 전략을 적용할 수 있습니다.
LDAP 인증 사용 인증에 Active Directory를 사용하는 가장 쉬운 방법은 그림 1과 같이 LDAP 인증을 사용하도록 PAM을 구성하는 것입니다. 이 방법은 만족도가 낮습니다. Active Directory는 LDAPv3 서비스이지만, Windows 클라이언트는 인증에 LDAP가 아니라 Kerberos(NTLM에 의존)를 사용합니다.
LDAP 인증(LDAP 바인딩)은 네트워크를 통해 일반 텍스트 형태로 사용자 이름과 암호를 전달합니다. 대부분의 경우 이는 위험하고 바람직하지 않은 방법입니다.
그림 1 LDAP를 사용한 Active Directory 인증
여기서 일반 텍스트 형태로 자격 증명을 전달할 위험성을 줄일 수 있는 유일한 방법은 SSL 등을 사용하여 클라이언트-Active Directory 통신 채널을 암호화하는 것입니다. 해볼 만한 방법이지만, DC와 Linux 컴퓨터 모두에서 SSL 인증서를 관리해야 하는 부담이 추가로 생깁니다. 게다가 PAM LDAP 모듈 사용 시 재설정되거나 만료된 암호의 변경을 지원하지 않습니다. LDAP 및 Kerberos 사용 Linux 인증에 Active Directory를 활용하는 또 다른 전략은 그림 2처럼 PAM이 Kerberos 인증을 사용하고 NSS가 LDAP을 사용하여 사용자 및 그룹 정보를 조회하도록 구성하는 것입니다. 이는 상대적으로 더 안전하다는 장점이 있으며, Linux의 "기본" 기능을 활용합니다. 그러나 Active Directory DC가 게시하는 DNS 서비스 위치(SRV) 레코드를 활용하지 않으므로, 인증할 특정 DC 집합을 선택할 수 밖에 없습니다. 또한 만료되는 Active Directory 암호를 관리하거나 (최근까지는) 적절한 그룹 구성원 조회를 지원하는 직관적인 방법을 제공하지 않습니다.
그림 2 LDAP 및 Kerberos를 사용한 Active Directory 인증
Winbind 사용 Linux 인증에 Active Directory를 사용하는 세 번째 방법은 Winbind 데몬을 호출하도록 PAM과 NSS를 구성하는 것입니다. Winbind는 LDAP, Kerberos 또는 RPC 중 가장 적합한 것을 사용하여 여러 PAM 및 NSS 요청을 해당 Active Directory 호출로 변환합니다. 그림 3에서 이 전략을 보여 줍니다.
그림 3 Winbind를 사용한 Active Directory 인증
구현 계획
Active Directory와의 통합이 향상되었으므로 저는 Linux-Active Directory 통합 프로젝트를 위해 Red Hat Enterprise Linux 5(RHEL5)에서 Windbind를 사용하기로 했습니다. RHEL5는 상용 Red Hat Linux 배포판의 최신 버전이며, 기업 데이터 센터에서 특히 인기가 높습니다.
RHEL5에서 Active Directory 인증을 수행하려면 기본적으로 다음과 같은 5단계를 거쳐야 합니다.
- 알맞은 Samba 및 기타 종속 구성 요소를 찾아 다운로드합니다.
- Samba를 빌드합니다.
- Samba를 설치하고 구성합니다.
- Linux, 즉 PAM과 NSS를 구성합니다.
- Active Directory를 구성합니다.
이 기사의 다음 몇 개 단원에서는 이 단계를 더 자세히 살펴보겠습니다.
최적의 소프트웨어 찾기
Linux와 Windows의 가장 큰 차이점 중 하나는 Linux의 경우 하나의 작은 운영 체제 커널과 개별적으로 다운로드하고 설정할 수 있는 수많은 구성 요소 모음으로 이루어져 있다는 것입니다. 따라서 어떤 작업에 최적화되고 고도로 특수한 Linux 구성을 만드는 것이 가능하나, 다른 한편으로 서버의 구성과 관리가 매우 복잡해질 수도 있습니다. 배포판마다 각기 다른 방법으로 이 문제를 해결합니다. Red Hat(및 비상용 제품인 Fedora)에서는 그러한 구성 요소의 설치 및 관리에 RPM(Red Hat Package Manager)을 사용합니다.
Red Hat의 Linux 구성 요소는 두 가지 형태로 제공됩니다. RPM 파일은 특정 구성 요소 버전, Linux 배포판 및 CPU 아키테게처의 조합에 맞게 미리 컴파일되고 빌드된 이진 파일로 구성됩니다. 따라서 이를테면 Intel x86 아키텍처 CPU에서 실행되는 Fedora 버전 10용 CUPS(Common UNIX Printing System) 1.3.8-5 버전을 다운로드하고 설치할 수 있습니다. 수십 개의 각기 다른 CPU 아키텍처, 100여 개의 Linux 배포판 그리고 수천 개의 패키지와 버전이 존재하는 만큼 엄청나게 많은 수의 이진 RPM 중에서 선택하게 됩니다.
한편 소스 RPM 파일은 어떤 패키지의 실제 소스 코드로 구성됩니다. 예상대로라면 소스를 다운로드하여 설치하고 빌드 옵션을 구성한 다음 이진 파일을 직접 컴파일하고 연결하게 됩니다. 운영 체제 구성 요소를 직접 빌드한다는 사실은, Microsoft에서 CD 형태로 제공하여 Windows를 설치하는 데 익숙한 Windows 사용자들에게는 부담스러운 개념이지만, RPM 덕분에 이 프로세스는 별 어려움 없이 그리고 놀랄 만큼 안정적으로 이루어집니다. Samba 그룹은 엄청난 속도로 업데이트와 보안 패치를 발표합니다. 2008년 7월과 8월만 보더라도 Samba 3.2 릴리스 4개가 나왔으며, 총 100개가 넘는 버그 및 보안 픽스가 제공되었습니다. 이번 프로젝트에서 저는 가장 최신의 안정적인 버전인 Samba 버전 3.0.31의 소스를 다운로드했습니다. 미리 컴파일된 이진 파일 집합 대신 Samba 소스를 다운로드한 까닭은 무엇입니까? 사실 처음에는 컴파일된 이진 파일 집합을 다운로드하려 했습니다. 몇 시간 동안 디버거와 씨름한 끝에 제가 다운로드한 이진 파일이 Active Directory 인증을 지원하는 올바른 옵션으로 빌드되지 않았음을 알게 되었습니다. 특히 Active Directory에서 Linux ID 매핑을 지원하는 코드가 기본 빌드에서는 해제된 상태였습니다. 따라서 알맞은 빌드 옵션으로 Samba를 다시 빌드해야 했습니다. ID 매핑에 대해서는 이 기사의 후반부에서 더 자세히 다루겠습니다.
Linux가 기본적으로는 작은 커널이지만 Red Hat Enterprise 배포판은 여러 패키지가 미리 설치된 상태로 공급됩니다. 따라서 제대로 작동하는 완전한 운영 체제로 시작할 수 있으므로 일반적으로 더 편리합니다. 그러나 미리 설치된 패키지가 나중에 설치하려는 소프트웨어와 충돌하는 경우가 가끔 있습니다.
저는 Red Hat을 설치할 때 기본적으로 설치되는 Samba를 포함시키지 않았습니다. 더 최신 버전을 사용하려고 했기 때문입니다. 그러나 최신 Samba 버전에서는 이미 설치된 다른 라이브러리와 유틸리티의 새 버전을 필요로 합니다. 이러한 종속성 문제는 꽤 성가신 편이지만, RPM을 사용하면 손쉽게 해결됩니다.
이진 RPM 패키지를 호스팅하는 웹 사이트는 많습니다. 제가 이용한 곳은 rpm.pbone.net에 있는 PBONE이었습니다. 별 다른 이유는 없고 가장 먼저 찾은 곳이었기 때문입니다. 이 곳에서는 패키지를 검색하는 편리한 방법을 제공하며, CPU 아키텍처(i386) 및 운영 체제 배포판(Red Hat Enterprise Linux 5/Fedora 7&8)에 필요한 모든 이진 파일을 갖추고 있었습니다.
최신 3.0 버전의 Samba를 빌드하고 설치하기 위해(3.2버전 트리도 있으나 시도하지 않았음) 그림 4에 나열된 패키지를 다운로드하고 업데이트해야 했습니다. 이 패키지는 Fedora Core(fc) 배포판을 대상으로 합니다. Red Hat은 Fedora가 사용하는 동일한 소스를 기반으로 하므로, Fedora와 완벽하게 상호 운용됩니다. Fedora Core 7 이상을 위해 빌드된 패키지는 수정 없이 RHEL5에서 실행됩니다. 다운로드한 RPM 파일을 /usr/src/redhat/RPMS 디렉터리에 배치합니다.
그림 4 Samba 3.0.31 빌드 및 설치에 필요한 패키지
|
samba-3.031-0.fc8.src.rpm |
Samba 3.0.31 소스 RPM |
|
gnutls1.6.3-3.fc7.i386 |
GNU TLS(Transport Layer Security) 라이브러리 |
|
gnutils-devel-1.6.3-3.fc7.i386 |
GNU TLS 개발 파일 |
|
popt-1.12-3.fc8.i386 |
명령줄 인수 구문 분석 라이브러리 |
|
popt-devel-1.12-3.fc8.i386 |
명령줄 인수 구문 분석 개발 파일 |
|
cups-libs-1.2.12-11.fc7.i386 |
일반 UNIX 프린터 시스템 라이브러리 |
|
cups-devel-1.2.12-11.fc7.i386 |
일반 UNIX 프린터 시스템 개발 파일 |
|
cups-1.2.12.11.fc7.i386 |
일반 UNIX 프린터 시스템 이진 파일 |
Samba 빌드
Samba 빌드 작업의 첫 번째 단계는 적합한 소스 RPM을 다운로드하는 것입니다. 저는 PBONE 사이트에서 Samba 3.0.31용 소스 RPM을 다운로드했습니다. 그 다음에는 다운로드한 소스 RPM을 /usr/src/redhat/SRPMS에 배치합니다. 이는 빌드 프로세스 중 소스 RPM의 표준 디렉터리입니다.
터미널 세션(Windows의 명령줄 창)을 열고 SRPMS 폴더로 이동합니다. 이 작업을 마쳤으면 그림 5와 같이 명령을 사용하여 소스 패키지를 설치합니다.
그림 5 Samba 소스 RPM 설치
"user mockbuild does not exist—using root"라는 오류 경고가 표시되더라도 걱정하지 마십시오. 이 오류는 Mock build 유틸리티가 설치되지 않았음을 알려 주는 것입니다. 이 유틸리티가 없어도 빌드 프로세스는 진행됩니다.
그 다음에는 /usr/src/redhat/SPECS 디렉터리로 이동하여 Samba 빌드 옵션이 있는 SAMBA.SPEC 파일을 편집합니다.
"CFLAGS="로 시작하는 줄을 찾아 "--with-shared-modules=idmap_ad,idmap_rid" 옵션이 있는지 확인합니다. 이 옵션을 통해 빌드 프로세스는 Linux UID(고유 식별자)를 Active Directory로 제대로 변환하는 코드를 포함하게 됩니다. 그림 6에서 이 옵션을 보여 줍니다.
그림 6 with-shared-modules 빌드 옵션
그 다음에는 Samba를 제대로 빌드하고 설치하도록 컴퓨터의 일부 라이브러리를 업데이트해야 합니다. 이는 설치한 라이브러리의 버전에 따라 달라집니다. 제 경우에는 그림 4에 나열된 패키지를 rpm --install 명령으로 설치했습니다. 어떤 경우에는 일부 종속성 문제를 피하기 위해 --force 옵션을 사용해야 했습니다.
Samba를 빌드하려면 /usr/src/redhat 디렉터리로 이동하고 rpmbuild –bb SPECS/samba.spec 명령을 실행합니다. 그림 7과 같습니다. 이 프로세스로 새로운 samba-3.0.31-0.i386 RPM 파일이 /usr/src/redhat/RPMS 디렉터리에 생깁니다. 이 RPM 파일은 프로젝트의 후반부에 설치하겠습니다.
그림 7 Samba 이진 RPM 파일 만들기
Linux 네트워킹 구성
Active Directory와 인증하려면 Linux 컴퓨터가 DC와 통신할 수 있어야 합니다. 그러기 위해서는 세 가지 네트워킹 설정의 구성이 필요합니다.
먼저 DHCP(Dynamic Host Configuration Protocol)를 사용하거나 ifconfig 명령을 사용하여 알맞은 IP 주소와 넷마스크를 지정함으로써 Linux 컴퓨터를 위한 네트워크 인터페이스가 제대로 구성되었는지 확인하는 것이 중요합니다. RHEL5에서는System | Administration 메뉴에서 Network를 선택하여 네트워크를 구성합니다. 그림 8과 같습니다.
그림 8 네트워크 구성
이제 Linux 컴퓨터의 DNS 확인자가 해당 DC와 동일한 DNS 이름 서버를 사용하도록 설정되었는지 확인합니다. Active Directory 통합 DNS를 사용하고 있다는 가정 하에 대부분의 경우 이는 Linux 시스템을 참가시키려는 도메인의 DC입니다. 그림 9와 같이 네트워크 구성에 사용한 네트워크 구성 유틸리티의 DNS 탭에서 DNS 확인자를 구성합니다.
그림 9 기본 DNS 확인자 설정
위 단계를 마쳤다면 마지막으로 도메인에서의 이름을 반영하여 Linux 컴퓨터의 호스트 이름을 설정해야 합니다. 네트워크 구성 응용 프로그램을 사용하여 호스트 이름을 설정할 수도 있으나 이 방법이 항상 제대로 작동하는 것은 아닙니다.
따라서 /etc/hosts 파일을 직접 편집하여 localhost.localdomain 항목 아래에 <IP 주소> <FQDN> <호스트 이름> 형태의 항목을 추가합니다. 예를 들어, "10.7.5.2 rhel5.linuxauth.local linuxauth"라고 추가합니다. 이 작업을 하지 않으면 Linux 컴퓨터를 도메인에 포함시킨 후 디렉터리에 잘못된 컴퓨터 개체가 생성됩니다.
Linux 시간 동기화 구성
Kerberos 프로토콜의 기반이 되는 인증 시스템에는 상대적으로 작은 값 범위에서 동기화되는 클럭이 있습니다. 기본적으로 Active Directory에서는 최대 5분의 시간차를 허용합니다. Linux 시스템과 DC의 시스템 클럭이 이 값의 범위를 유지하도록 Linux 시스템이 DC의 NTP(Network Time Protocol) 서비스를 사용하도록 구성해야 합니다.
그런 다음 Linux 서버에서 System | Administration 메뉴의 Date & Time 유틸리티를 실행한 다음 Network Time Protocol 탭을 클릭합니다. Enable Network Time Protocol 상자를 선택하고 네트워크 시간 소스로 사용하려는 DC의 IP 주소를 추가합니다. 일반적으로 이는 도메인에서 PDC(Primary Domain Controller) 에뮬레이터 FSMO(Flexible Single Master Operations) 역할을 하는 DC입니다. 그림 10은 Linux 네트워크 시간 소스를 설정하는 방법의 예입니다.
그림 10 Network Time Protocol 구성
PAM 및 NSS 구성
PAM 및 NSS는 데스크톱과 같은 Linux 응용 프로그램과 Windbind를 연결합니다. 여러 Linux 서비스처럼 PAM과 NSS도 텍스트 파일을 통해 구성합니다. 먼저 PAM 구성을 살펴보겠습니다.
PAM은 PAM을 사용하는 응용 프로그램에 네 가지 인증 관련 기능을 제공합니다. 이 인증 기능을 통해 응용 프로그램에서는 누가 사용하고 있는지 확인할 수 있습니다. 계정 기능은 인증과 특별히 관련 없는 계정 관리 기능(예: 로그인 시간 제한)을 제공합니다. 암호 기능은 암호를 요청하고 관리하는 메커니즘을 제공합니다. 세션 기능은 응용 프로그램에 대한 사용자 관련 설정 및 종료 작업(예: 로깅, 사용자별 디렉터리에 파일 만들기)을 담당합니다.
Red Hat 환경의 PAM은 /etc/pam.d 디렉터리에 구성 파일을 저장합니다. 여기에는 인증에 PAM을 사용하는 각 응용 프로그램용 텍스트 파일이 포함됩니다. 예를 들어, /etc/pam.d/gdm 파일은 Red Hat의 기본 창 작업 환경인 GDM(Gnome Desktop Manager)의 PAM 구성 정보를 포함합니다. 각 PAM 구성 파일은 여러 줄로 구성되며, 각 줄은 PAM 인증 프로세스의 특정 측면을 정의합니다. 그림 11은 GDM을 위한 PAM 구성의 내용을 보여 줍니다.
그림 11 Gnome Desktop Manager를 위한 PAM 구성 파일
PAM 구성 파일의 각 항목은 <관리 그룹> <제어> <모듈> <매개 변수>의 형태를 가지며, 여기서 <관리 그룹>은 해당 구성 항목과 관련된 기능, 즉 auth, account, password 또는 session입니다. 그림 12에서 설명하는 제어 키워드는 PAM에게 구성 항목의 처리 방법을 알려 줍니다. 이 파일의 세 번째 열은 /lib/security 디렉터리에 있는 PAM 공유 디렉터리의 이름을 포함합니다. 공유 라이브러리는 Windows의 DLL과 비슷한, 동적 로딩이 가능한 실행 코드를 포함합니다. 모듈 이름 다음에 나오는 추가 용어는 PAM이 공유 라이브러리에 전달하는 매개 변수입니다.
그림 12 PAM 제어 키워드
|
키워드 |
설명 |
|
필수 |
모듈이 성공할 경우 PAM은 관리 그룹의 나머지 항목을 계속 평가하며, 그 결과는 나머지 모듈의 결과에 의해 결정됩니다. 모듈이 실패할 경우 PAM은 평가를 계속하지만 호출하는 응용 프로그램에 실패를 반환합니다. |
|
Requisite |
모듈이 성공할 경우 PAM은 관리 그룹 항목의 평가를 계속합니다. 모듈이 실패할 경우 PAM은 더 이상 처리하지 않고 호출 응용 프로그램으로 돌아갑니다. |
|
Sufficient |
모듈이 성공할 경우 PAM은 호출 응용 프로그램에 성공을 반환합니다. 모듈이 실패할 경우 PAM은 평가를 계속하지만, 후속 모듈에 의해 결과가 결정됩니다. |
|
Optional |
관리 그룹에 대해 지정된 유일한 모듈이 아닌 한 PAM은 그 모듈의 결과를 무시합니다. |
|
Include |
PAM은 참조된 PAM 구성 파일의 내용을 포함시키고 여기에 포함된 항목을 처리합니다. |
각 관리 그룹에 몇 개의 항목이 있음을 알 수 있습니다. PAM은 명명된 모듈을 호출하면서 이 항목을 순서대로 처리합니다. 그러면 모듈은 성공이나 실패를 반환하며, PAM은 제어 키워드에 따라 진행됩니다.
GDM용 PAM 구성 파일은 모든 관리 그룹에서 system-auth를 포함합니다. 이는 PAM이 GDM에 대한 기본 인증 동작을 설정하는 방법입니다. system-auth를 수정하는 방법으로 PAM 구성에 system-auth 파일이 포함된 모든 응용 프로그램의 인증 동작을 수정할 수 있습니다. 기본 system-auth 파일은 그림 13과 같습니다.
그림 13 PAM system-auth 파일
NSS(Name Service Switch) 모듈은 시스템 데이터 저장소의 세부 사항을 응용 프로그램 개발자에게 숨기며, 이는 PAM이 인증의 세부 사항을 숨기는 것과 거의 동일한 방법입니다. NSS를 통해 관리자는 시스템 데이터베이스가 저장되는 방법을 지정할 수 있습니다. 특히 관리자는 사용자 이름과 암호 정보가 저장되는 방법을 지정할 수 있습니다. 응용 프로그램에서 Windbind를 사용하여 Active Directory의 사용자 정보를 조회하게 할 것이므로 NSS 구성 파일이 이 정보를 표시하도록 수정해야 합니다.
Red Hat은 PAM 및 NSS 호출 시스템 구성 인증을 구성하기 위한 작은 그래픽 애플릿 하나를 포함합니다. 이 애플릿은 system-auth 및 nss.conf 파일에 필요한 변경의 전부는 아니지만 대부분을 담당합니다.
시스템 구성 인증 응용 프로그램을 실행하면 그림 14와 같은 대화 상자가 나타납니다. User Information 탭(nss.conf 파일 구성)과 Authentication 탭(system-auth 파일 수정) 모두에서 Windbind 옵션을 선택합니다.
그림 14 시스템 구성 인증 대화 상자
Configure Winbind 단추를 클릭하면 그림 15와 같은 대화 상자가 나타납니다. 사용자가 인증할 도메인의 이름을 Winbind Domain 필드에 입력하고 보안 모델로 "ads"를 선택합니다. Winbind ADS Realm 필드에서는 Active Directory 도메인의 DNS 도메인 이름을 입력합니다. Winbind Domain Controllers 필드에서는 이 Linux 시스템이 인증할 DC의 이름을 입력합니다. 또는 별표(*)를 입력하여 Windbind가 DNS SRV 레코드를 쿼리하여 DC를 선택하게 합니다.
그림 15 Winbind 구성 대화 상자
Active Directory 사용자가 갖게 될 알맞은 기본 명령 셸을 선택합니다. 여기서는 Bourne-again Shell, 즉 BASH를 선택했습니다. 여기서는 "Join Domain" 단추를 사용하지 마십시오. 컴퓨터를 도메인에 참가시키는 작업은 나중에 합니다.
/etc/pam.d/system-auth 파일이 Windbind를 지원하도록 수정한 후 한 가지 더 변경해야 합니다. Linux 사용자가 로그인할 때 그 사용자는 시스템에 홈 디렉터리가 있어야 합니다. 홈 디렉터리는 Windows 레지스트리처럼 여러 사용자별 기본 설정과 구성 항목을 포함합니다. Active Directory에서 사용자를 만들고 있으므로 Linux가 그 사용자의 홈 디렉터리를 자동으로 작성하지 않는다는 것이 문제입니다. 다행히 PAM에서 세션 구성의 일부로 이 작업을 수행하도록 구성할 수 있습니다.
/etc/pam.d/system-auth 파일을 연 다음 맨 아래까지 스크롤하고 세션 섹션의 마지막 줄 앞에 "session optional map_mkhomedir.so skel=/etc/skel umask=0644"라는 줄을 삽입합니다(그림 16 참조). 이 줄은 어떤 사용자의 홈 디렉터리가 없을 경우 PAM에서 그 디렉터리를 만들도록 구성합니다. /etc/skel 디렉터리를 "기본 구조(skeleton)", 즉 템플릿으로 사용하며, 권한 마스크 0644(소유자의 경우 읽기 및 쓰기 권한, 기본 그룹은 읽기 권한 그리고 그 밖의 모든 사람은 읽기 권한)를 새 폴더에 지정합니다.
그림 16 사용자용 홈 디렉터리 만들기
Samba 설치 및 구성
방금 만든 Samba 이진 파일을 설치하려면 /usr/src/redhat/RPMS 디렉터리로 이동합니다. rpmbuild 명령으로 만든 모든 RPM 파일이 이 디렉터리에 나타납니다. Samba에는 Linux의 Windows(또는 Samba) 파일 공유 액세스를 허용하는 이진 파일 그리고 Linux 시스템이 Windows 파일 서버, Windows 프린터 서버 및 Windows NT 4.0 스타일 DC 역할을 하게 해주는 코드가 포함되어 있습니다.
Linux가 Active Directory에 인증하는 데 이 구성 요소가 모두 필요하지는 않습니다. Samba 일반 파일과 Samba 클라이언트 이진 파일만 있으면 됩니다. 이 파일들은 편의를 위해 samba-client-3.0.31-0.i386.rpm과 samba-common-3.0.31-0.i386.rpm이라는 두 개의 RPM 파일로 나뉩니다. rpm --install 명령을 사용하여 RPM 파일을 설치합니다. 예를 들면, rpm --install samba-common-3.0.31-0.i386.rpm 등의 명령을 사용할 수 있습니다. 단, –common RPM 파일을 먼저 설치해야 합니다.
Samba 클라이언트 이진 파일을 설치했다면 Windbind가 Active Directory와의 인증을 제대로 처리하도록 기본 Samba 구성을 수정해야 합니다. 모든 Samba 구성 정보(클라이언트와 서버)는 smb.conf 텍스트 파일에 있으며, 이 파일은 기본적으로 /etc/samba 디렉터리에 위치합니다. smb.conf는 수많은 구성 옵션을 포함할 수 있으므로, 그 내용에 대한 자세한 설명은 이번 기사의 범위에 해당되지 않습니다. samba.org 웹 사이트와 Linux man 페이지에서 smb.conf를 더 자세히 소개합니다.
첫 번째 단계는 인증에 Active Directory를 사용하도록 Windbind를 구성하는 것입니다. smb.conf에서 보안 모델을 "ads"로 설정해야 합니다. 시스템 구성 인증 유틸리티가 이 설정을 대신 해주었겠지만, 그래도 항상 확인해 보는 것이 좋습니다. smb.conf 파일을 편집하여 Domain Member Options라고 표시된 섹션을 검색합니다. "security"로 시작하는 줄을 찾아 "security = ads"인지 확인합니다. 다음 구성 단계에서는 Winbind가 사용자 및 그룹과 같은 Windows 보안 주체를 Linux 식별자에 매핑하는 방법을 결정하는데, 이와 관련하여 약간의 추가 설명이 필요합니다.
ID 매핑 문제
Linux 사용자를 Active Directory에 인증하는 것과 관련하여 아직 언급하지 않은 심각한 문제가 하나 있는데, 바로 사용자 및 그룹의 UID 문제입니다. 내부적으로 Linux나 Windows 모두 사용자 이름으로 사용자를 참조하지 않습니다. 고유한 내부 식별자를 사용합니다. Windows에서는 보안 식별자, 즉 SID를 사용하는데, 이는 가변 길이의 구조로서 Windows 도메인 내에서 각 사용자를 고유하게 식별합니다. 또한 SID는 Windows에서 서로 다른 도메인의 사용자를 구별할 수 있도록 고유한 도메인 식별자를 포함합니다.
Linux의 체계가 훨씬 더 간단합니다. Linux 컴퓨터의 각 사용자는 32비트 정수의 UID를 갖습니다. 그러나 UID의 범위는 해당 컴퓨터 자체로 제한됩니다. 어떤 Linux 컴퓨터에서 UID가 436인 사용자가 다른 Linux 컴퓨터에서 UID가 436인 사용자와 동일하다고 보장할 수 없습니다. 따라서 사용자는 액세스해야 하는 컴퓨터마다 로그인해야 하는데, 이는 분명 바람직한 상황이 아닙니다.
일반적으로 Linux 네트워크 관리자는 NIS(Network Information System)나 공유 LDAP 디렉터리 중 하나를 사용하여 네트워크 인증을 제공하는 방법으로 이 문제를 해결합니다. 네트워크 인증 시스템에서 사용자에게 UID를 제공하며, 그 인증 시스템을 사용하는 모든 Linux 컴퓨터는 동일한 사용자 및 그룹 식별자를 공유합니다. 필자는 Active Directory를 사용하여 고유한 사용자 및 그룹 식별자를 제공하겠습니다.
두 가지 전략을 활용하여 이 문제를 해결할 수 있습니다. 첫 번째이자 가장 알기 쉬운 전략은 각 사용자 및 그룹에 대해 UID를 만들고 그 식별자를 해당 개체와 함께 Active Directory에 저장하는 것입니다. 그렇게 하면 Windbind가 사용자를 인증할 때 그 사용자의 UID를 조회하고 이를 사용자의 내부 식별자로 Linux에 제공할 수 있습니다. Winbind에서는 이 체계를 Active Directory ID 매핑, 즉 idmap_ad라고 부릅니다. 그림 17에서는 Active Directory ID 매핑의 프로세스를 보여 줍니다.
그림 17 Active Directory ID 매핑
Active Directory ID 매핑의 유일한 단점은 각 사용자와 그룹이 식별자를 갖는지 그리고 이 식별자가 해당 포리스트에서 모두 고유한지 확인하는 메커니즘을 제공해야 한다는 것입니다. 자세한 내용은 "Active Directory ID 매핑을 위한 Active Directory 구성" 추가 기사를 참조하십시오.
다행히 관리 오버헤드가 훨씬 적은 또 다른 ID 매핑 전략이 있습니다. 아시다시피 Windows SID는 도메인 자체뿐 아니라 도메인 내 사용자도 고유하게 식별합니다. 도메인 내에서 사용자를 고유하게 식별하는 SID 부분을 RID(Relative Identifier)라고 하며, 이는 사실 32비트 정수입니다. 따라서 Winbind는 사용자가 로그인할 때 SID에서 RID를 추출하고 이를 고유한 내부 UID로 사용하면 됩니다. Winbind에서는 이 전략을 RID 매핑, 즉 idmap_rid라고 부릅니다. 그림 18에서는 RID 매핑이 실제로 어떻게 작동하는지를 보여 줍니다.
그림 18 RID 매핑
RID 매핑은 관리 오버헤드가 전혀 없다는 장점이 있으나, 다중 도메인 환경에서는 이를 사용할 수 없습니다. 서로 다른 도메인의 사용자가 동일한 RID 값을 가질 가능성이 있기 때문입니다. 그러나 Active Directory 도메인이 하나뿐이라면 RID 매핑이 효과적입니다.
Winbind ID 매핑 전략을 구성하기 위해 /etc/samba/smb.conf 파일을 다시 편집합니다. Active Directory 매핑 전략을 사용하려면 "idmap backend = ad"를 사용하고, RID 매핑 전략을 사용하려면 "idmap backend = rid"를 추가합니다. 파일에서 매핑 전략을 지정하는 다른 줄이 없어야 합니다.
그 밖에도 Windbind를 위해 smb.conf 파일에 두 가지 구성 옵션을 추가해야 합니다. 사용자가 로그인할 때 사용자별로 홈 디렉터리를 만들도록 PAM을 설정했지만 그 홈 디렉터리의 이름이 무엇인지 Windbind에 알려 줘야 합니다. 그러기 위해 smb.conf에 "template homedir = /home/%U"를 추가합니다(그림 19 참조). 이 줄은 Active Directory를 사용하여 인증하는 사용자별 홈 디렉터리가 /home/<사용자 이름>임을 Windbind에 알려 줍니다. 먼저 /home 디렉터리를 만들어야 합니다.
그림 19 홈 디렉터리 이름 지정
도메인 가입 및 로그인
네트워크, PAM, NSS 및 Samba Windbind가 모두 제대로 구성되었으므로 이제 Linux 컴퓨터를 도메인에 가입시킬 차례입니다.
이를 위해 Samba NET 명령을 사용합니다. 셸 프롬프트에서 "net ads join –U <관리자 이름>"을 실행합니다. <관리자 이름>에는 컴퓨터를 도메인에 포함시킬 수 있는 권한을 가진 계정의 이름을 넣습니다.
net 명령은 사용자 암호를 묻습니다. 모두 정상적으로 작동할 경우 net 명령은 해당 컴퓨터를 도메인에 포함시킵니다. 새로 만들어진 컴퓨터 계정을 Active Directory 사용자 및 컴퓨터를 사용하여 찾을 수 있습니다.
wbinfo라는 Windbind 테스트 도구를 사용하여 가입 상태를 테스트할 수 있습니다. wbinfo –t를 실행하면 컴퓨터와 도메인 간의 트러스트 관계를 테스트합니다. wbinfo –u를 실행하면 도메인의 모든 사용자를 나열하며, wbinfo –g는 모든 그룹을 나열합니다. Linux 컴퓨터를 도메인에 성공적으로 가입시켰으면 이제 Active Directory 사용자 계정과 암호를 사용하여 로그인해 볼 차례입니다. Linux 컴퓨터에서 로그오프한 다음 Active Directory 사용자 이름으로 로그인합니다. 모두 제대로 작동한다면 로그인이 가능해야 합니다.
|
Active Directory ID 매핑을 위한 Active Directory 구성
이 정보는 Active Directory ID 매핑을 사용하는 경우에만 적용됩니다. RID 매핑을 사용하기로 한 경우 이 추가 기사를 건너뛰어도 좋습니다.
Active Directory 계정을 사용한 Red Hat 서버 로그인을 시작하기 전에 Active Directory 자체에서 몇 가지 변경을 수행해야 합니다. 먼저 Active Directory 스키마는 Windbind가 사용자 정보를 저장하는 데 쓰는 특성을 수용해야 합니다. Windows Server 2003 R2를 실행 중인 경우 스키마는 즉시 실행 가능합니다. 이전 버전의 Active Directory 스키마가 있는 경우 Microsoft SFU(Services for UNIX) 패키지를 사용하여 이를 확장해야 합니다.
자세한 내용은 TechNet의 SFU(Services for UNIX)를 참조하십시오. SFU는 Active Directory 사용자 및 컴퓨터 MMC(Microsoft Management Console) 스냅인용 추가 속성 페이지도 포함하는데, 여기서는 Linux에서 필요로 하는 사용자 ID 및 그룹 ID 정보를 관리할 수 있습니다.
스키마가 제대로 설정되었다면 Linux 컴퓨터에 로그인할 가능성이 있는 모든 사용자(및 그 사용자가 속한 그룹)에 대해 Linux 식별자를 제공해야 합니다. 즉 Linux 컴퓨터에 로그인할 사용자 및 그룹의 uidNumber 및 gidNumber 특성 값을 정의해야 합니다. 그러나 이 특성의 일부 요구 사항은 알고 있어야 합니다.
|
작동하지 않을 경우
Linux 컴퓨터가 Windbind를 사용하여 Active Directory와 인증하도록 설정하는 것은 간단한 프로젝트가 아닙니다. 많은 사항을 구성해야 하므로, 잘못될 수 있는 영역도 많습니다. 각 Linux 버전과 Samba 버전이 약간씩 다르다는 사실도 어느 정도 문제가 됩니다. 그러나 상황을 파악하기 위해 살펴볼 수 있는 곳이 몇 군데 있습니다.
첫 번째로 /var/log/messages에 저장되는 Linux 시스템 로그 파일이 있습니다. Samba는 누락된 파일, 잘못된 구성과 같은 중대한 이벤트에 대한 메시지를 이 파일에 저장합니다. 시스템 로그 파일 외에 Samba 및 Windbind 로그 파일도 있습니다. 이 파일들은 /var/log/samba에 있으며, 몇 가지 추가 정보를 제공할 것입니다.
Windbind에서 보내는 로그 메시지의 상세 수준(및 그 볼륨)을 늘릴 수 있습니다. 시작 스크립트를 수정하여 디버그 수준을 설정하면 됩니다. /etc/init.d/winbind shell 스크립트를 편집하여 winbindd 명령에 "-d 5"를 추가합니다. 그러면 디버그 수준이 5로 증가하며(가능한 값의 범위는 1 ~ 10), 따라서 Windbind는 더 자세한 오류 메시지를 생성하게 됩니다.
Windbind가 DC와 통신하는 수준까지 이르게 되면 Netmon 3.1과 같은 네트워크 패킷 캡처 유틸리티를 실행할 수 있습니다. 그러면 Windbind가 정확하게 무엇을 수행하려고 하는지 분석할 수 있습니다. 또한 인증 시도를 보여 주는 DC의 Windows 보안 로그를 조사할 수도 있습니다.
작동될 경우 갖춰야 할 사항
모두 제대로 작동하게 했다면 이제 Active Directory에서 관리하는 자격 증명을 사용하여 Linux 시스템에 로그인할 수 있습니다. 이는 로컬의 Linux 컴퓨터에서 ID를 관리하거나 NIS와 같이 안전하지 않은 시스템을 사용하는 것보다 크게 향상된 방식입니다. 사용자 관리를 하나의 ID 저장소, 즉 Active Directory에서 중앙 집중화할 수 있기 때문입니다.
그러나 이 솔루션을 완벽하게 활용하기 위해 다소 부족한 부분이 몇 가지 있습니다. 첫 번째로 기술 지원이 다소 소홀합니다.대부분의 Linux 조직들은 Active Directory와 관련하여 불분명한 태도를 취하고 있으며, Linux 커뮤니티에서 받을 수 있는 지원도 어쩌다가 여러분의 게시글을 읽은 사람 그리고 그 사람의 그날 컨디션에 따라 달라집니다.
또한 Samba와 관련된 마이그레이션 또는 배포 도구도 없습니다. 사용자 ID와 권한이 있는 기존 Linux 계정을 갖고 있는 경우 이를 Active Directory로 마이그레이션할 때 UID가 있는지 수동으로 확인해야 합니다.
마지막으로, 가장 중요한 Active Directory 응용 프로그램 중 하나인 Group Policy가 아직 Samba를 지원하지 않습니다(지원하기 위한 작업 진행 중). Samba를 사용하여 Linux 시스템을 Active Directory에 가입시키는 것은 가능하나 Group Policy를 사용하여 관리할 수는 없습니다.
타사 솔루션
Linux 컴퓨터를 Active Directory에 인증하는 것은 분명 좋은 일이지만, Samba Windbind를 사용하여 직접 솔루션을 운영하는 것은 힘들지 않더라도 번거로운 일입니다. 일부 혁신적인 소프트웨어 공급업체들이 더 사용하기 쉬운 솔루션 개발에 착수할 것으로 기대할 수도 있는데, 그렇습니다.
제가 이 기사에서 소개한 솔루션을 설치 및 사용이 용이한 버전으로 개발한 상용 소프트웨어 공급업체가 네 군데 있습니다. 이들은 널리 쓰이는 거의 대부분의 Linux, UNIX 및 Apple Macintosh 버전을 위한 코드와 마이그레이션 도구를 제공할 뿐 아니라 Group Policy를 사용한 Linux 컴퓨터 관리도 지원합니다.
이 4개 업체는 Centrify , Likewise Software, Quest Software 그리고 Symark 입니다. 이들 업체 모두 다양한 Linux 배포판을 망라하여 Group Policy 관리를 비롯한 비슷한 기능을 제공합니다. Likewise Software에서는 최근 Likewise Open이라는 이름으로 공개 소스를 내놓았습니다. 다만 Group Policy 구성 요소는 아직 상용 제품으로 남아 있습니다. Likewise Open은 몇 가지 주요 Linux 배포판에서 사용 가능합니다 (완전 공시: 이 기사를 작성하는 중에 필자의 회사인 NetPro가 Quest Software에 인수되었음을 밝힙니다.)
이용 가능한 상용 옵션이 있는데 Samba와 Windbind를 사용하여 직접 인증 시스템을 구축할 필요가 있을까요? 통합 소프트웨어 투자가 예산에 편성되지 않은 경우 Samba를 사용하는 공개 소스 방법은 비용이 들지 않는다는 이점이 있습니다. 또한 모든 소스 코드도 얻게 되므로 이는 강력한 이점이 될 수 있습니다. 그러나 기존 Linux 컴퓨터와 기존 UID를 마이그레이션하는 작업이 만만치 않습니다.
한편 설치 및 구현 시간을 절약해야 하거나 마이그레이션해야 할 기존 Linux 컴퓨터가 있거나 궁금한 사항에 대해 신뢰할 만한 답을 줄 누군가가 필요한 경우 상용 솔루션 중 하나를 선택할 만합니다. 또한 Group Policy 관리가 필요한 경우 상용 솔루션이 유일한 선택일 것입니다.
그러나 어떤 방식을 택하든지 간에 Linux 인증과 Active Directory를 통합하면 여러 사용자 계정을 관리하고 시스템 보안을 향상시키며 관리 및 감사 작업을 위한 단일 ID 저장소를 마련하는 데 드는 수고를 덜 수 있습니다. 게다가 한번 시도해 볼 만한 이유가 충분합니다.
필자소개
Gil Kirkpatrick 는 수십 여 개의 성공적인 상용 소프트웨어 제품을 설계하거나 개발하면서 30여 년의 경력을 쌓아 왔으며, Directory Experts Conference(현 Experts Conference)의 설립자이기도 합니다. Gil은 Active Directory Programming 을 저술했으며, Windows IT Pro 및 TechNet Magazine 에도 자주 기고하고 있습니다. 현재 NetPro(Quest Software에 인수됨)에서 Expert-in-Residence로 재직 중인 Gil은 여러 보안, ID 및 마케팅 프로젝트에서 컨설팅을 수행하는 한편 전세계의 기술 세미나 및 컨퍼런스에서 발표자로 활동하고 있습니다.
김린님 블로그
http://blog.naver.com/PostView.nhn?blogId=mirnae&logNo=100060619531
'Windows Server' 카테고리의 다른 글
| Windows 2008 Remote App (0) | 2015.05.12 |
|---|---|
| Active Directory 삭제방법 (0) | 2013.11.05 |
| Active Directory를 사용하여 Linux 클라이언트 인증-도메인 가입 및 로그인 (0) | 2013.11.05 |
| 기존 AD에 복제된 DC구성하기 (0) | 2013.10.29 |
| FreeNAS 설정방법 (1) | 2013.10.29 |
