Active Directory의 권한위임 기능은 관리작업에 대한 효율성을 극대화 시킬 수 있는 방법이다. 앞에서 OU의 용도에 대해서 언급한 바 있다. 이 하나의 단위 덕분에 NT4.0에서 여러 개의 도메인으로 어쩔수 없이 구성해야만 했던 많은 상황들이 Active Directory에서는 하나의 도메인으로 통합을 할 수도 있는 환경을 제공하게 되었다.

상황은 다음과 같다. Windowsnetwork.msft은 미국, 일본 등지에 지사를 가지고 있는데, 미국지사에 인사권이 별도로 있어서 직원의 인사가 직접 이루어지고 있다. 서울의 본사에서는 미국에서 근무하는 사용자들에 대한 계정관리를 미국에 있는 담당자 하나를 임명해서 맡기고자 한다. 새로운 직원이 들어오면 계정을 만들어 주고, 직원이 퇴사하면 계정을 삭제하고, 사용자들이 몇 차례 패스워드를 잘못 입력하여 잠긴 계정을 풀어주는 등의 계정관리를 미국지사에서 처리하도록 하고자 하는 것이다. 이와 같은 작업을 처리하기 위해서 NT4.0때는 미국지사를 위한 별도의 도메인을 생성해야만 했다. 계정관리를 할 수 있도록 미국지사의 사용자 하나를 ‘Account operators’ 그룹의 멤버로 포함시켜 주면 미국의 계정관리를 하게 할 수는 있었지만, 문제는 이 사용자가 관리자가 원하지 않는 일본지사나 본사의 계정까지도 관리가 가능해 지기 때문에 제한적인 권한을 부여하는 것이 불가능했기 때문이다. 계층적인 관리구조가 제공되지 못했기 때문이었다.

권한위임의 방법은 이와 같은 경우에 최상의 솔루션이 될 수 있다. 다음과 같은 절차를 거쳐서 접근할 수 있다. <그림13-55>을 보면 ‘전체조직’이라는 OU가 있고 하위에는 ‘미국’OU를 포함한 몇 개의 지사별로 구분해 놓은 OU들이 있다. 미국OU를 열어보니 몇 개의 그룹과 사용자계정이 보인다. 예제의 상황에서는 미국OU에 있는 ‘김수용’이라는 사용자에게 미국지사에 대한 사용자 계정관리를 위임하고자 한다.

<그림13-55. 권한 위임 구성 1>	ADUC관리콘솔을 통해 관리를 위임하고자 하는 곳을 클릭한다.
<그림13-56. 권한 위임 구성 2>	‘미국’OU를 마우스 오른쪽 클릭하여 ‘제어위임’메뉴를 선택한다.
<그림13-57. 권한 위임 구성 3>	‘사용자 또는 그룹’화면에서 [추가]버튼을 눌러서 관리를 위임받을 사용자 또는 그룹을 찾아서 추가한다.   다음의 ‘위임할 작업’화면에서는 ‘다음 일반 작업을 위임’과 ‘위임할 사용자 정의 작업 만들기’의 두개의 라디오 버튼을 볼 수 있다. 기본선택된 위의 버튼은 이미 정의된 많이 사용할 만한 관리작업들이 나열되어 있다.
<그림13-58. 권한 위임 구성 4>	위의 작업만으로 만족할만한 관리의 위임을 시키지 못할 경우, 예를 들면 사용자 계정을 생성할 수 있게 하고 싶지만 삭제는 하지 못하게 하기를 원한다거나 하는 경우는 아래의 ‘위임할 사용자 정의 작업 만들기’를 클릭하고 [다음]으로 진행하여 직접 보다 제한적인 작업을 결정해 줄 수도 있다. 예제에서는 기본설정을 두고 [다음]버튼을 눌렀다.
<그림13-59. 권한 위임 구성 5>	제어 위임 마법사가 완료되었음을 보여주는 화면이다. 내용을 잘 살펴보면 정보를 잘 요약해 주고 있다.

위와 같이 권한 위임을 마친다음 테스트를 해 보았다. 권한을 위임받은 ‘김수용’이라는 사용자로 로그온을 해서 Active Directory 사용자 및 컴퓨터 관리콘솔을 열어서 ‘미국’ OU를 클릭하고 ‘새로만들기’를 누르니 ‘사용자’를 생성할 수 있는 메뉴가 나타난다. 위에서 관리자로 로그온했을 때 모든 개체를 생성할 수 있었던 것과 비교해 보라.

Active Directory Database에 저장할 수 있는 하나하나의 단위를 가리켜서 Object(개체)라고 부른다. 종류로는 컴퓨터, 연락처, 그룹, 조직단위, 프린터, 사용자, 공유폴더 등이 있다. Active Directory를 설치한 후 생성되는 관리도구의 ‘Active Directory 사용자 및 컴퓨터’를 통해서 접근한다.

<그림13-50>에서 볼 수 있듯이 ‘새로 만들기’라는 메뉴를 통해서 Active Directory에 생성할 수 있는 개체들은 9가지가 있다. 각각이 무엇인지를 간단하게 정리를 해 보자.

①    사용자 (User Account) : 네트워크상에서 자원을 관리하기 위해 컴퓨터를 사용하는 사람에 해당하는 계정이다. 기본적으로 ‘사용자’는 네트워크 활동을 하는 사람이 이를 테면 회사의 직원인지 아닌지 등을 판단하는 근거가 되며 그 ‘사용자’의 진위여부를 가리기 위해 ‘암호’라는 기본보안조치를 취해 놓게 된다. 그런 이유로 우리가 네트워크 상에서 다른 서버에 접근하고자 할 때는 사용자이름과 암호가 필요한 것이다.

②    컴퓨터 (Computer Account) : Windows 9x 컴퓨터들과는 달리 NT기반의 컴퓨터들은 ‘컴퓨터 계정’이라는 것을 가진다. 사용자와 구분하여 컴퓨터를 네트워크에서 하나의 자원으로 관리하기 위한 방법이다. 도메인 환경에서 NT기반의 시스템들을 도메인에 참여시켜 사용(멤버서버)하기 위해서는 반드시 도메인의 Active Directory에 컴퓨터 계정을 가져야 한다.

③    그룹 (Group Account) : 사용자들을 효율적으로 조직하여 자원관리를 용이하게 하기 위해 사용된다. 글로벌 그룹, 도메인 로컬 그룹, 유니버설 그룹이 있다.

④    프린터 : 공유된 프린터를 Active Directory의 목록에 포함시킴으로써 사용자들이 프린터 자원에 보다 쉽게 접근하도록 제공한다.

⑤    연락처 (Contact) : 사용자계정과 구분해야 한다. 연락처는 사용자의 E-mail 주소를 저장할 목적으로 사용된다. Exchange Server 2000 버전은 이전의 5.5 버전과는 달리 별도로 디렉터리 데이터베이스를 유지하지 않는다. 완전하게 Active Directory와 통합이 되었는데, 회사에서 계정을 가진 사용자와 구분하여 도메인의 계정은 할당하지 않고 메일주소록에만 리스트 시킬 수 있는 형태의 ‘연락처’를 제공하고 있는 것이다. 이 연락처로써 계정이 생성되면 그 계정으로는 도메인에서 로그온을 한다거나 자원에 대한 권한을 가질 수는 없고 ‘아웃룩’에서 주소록으로 확인할 수 있을 뿐이다.

<그림13-51>을 보면 ‘wssong’이라는 이름의 사용자계정과 ‘thkim’이라는 이름의 연락처를 만들어 둔 것을 구분할 수 있다. 이름 옆의 아이콘이 서로 다른 것을 기억하자. ‘thkim’이라는 이름은 도메인에서 로그온을 한다거나 하는 것과는 무관하다. 다만 메일 클라이언트 프로그램으로 Outlook을 사용하는 클라이언트가 Exchange Server 에 연결하여 주소록을 클릭했을 때 ‘thkim’이라는 이름을 확인할 수 있게 할 것이다.

⑥    InetOrgPerson : 비 Microsoft LDAP 및 X.500 디렉터리 서비스에서 조직 내의 사람을 나타내는 데 사용되며 다른 LDAP디렉터리로부터 Active Directory로의 효율적인 마이그레이션을 지원하기 위해 Windows Server 2003 Active Directory에서 추가되었다.

⑦    MSMQ 대기열 별칭 : InetOrgPerson과 같이 Windows Server 2003의 Active Directory에서 추가된 개체이다. MSMQ를 사용하는 서버들이 설치시 특정개체를 생성하고 Message Queuing과 관련된 다양한 정보를 저장할 용도로 사용한다.

⑧    공유폴더 (Shared Folder) : 공유폴더를 Active Directory에 게시(publishing)함으로써 사용자들에게 자원을 쉽게 찾을 수 있도록 제공한다. 구체적인 사항에 대해서는 AD의 장점을 이야기 하면서 언급한 바 있다.

⑨    조직단위(Organizational Unit; OU) : 그룹과 많이 혼돈하여 사용하는 경향이 있는데 구분해야 한다. 그룹이 사용자를 관리하기 쉽도록 부서, 직급 등으로 조직화하는 것에 반하여 OU는 IT관리조직이 회사의 시스템을 보다 효율적으로 관리하도록 나누는 관리단위이다. 사용자와는 무관하다. 사용자들은 자신이 어떤 조직단위에 소속되었는지 알 지도 못하고 알 필요도 없다. 다만 IT관리자는 회사의 조직을 OU로 나눔으로써 그룹정책, 관리권한의 위임 등의 방법을 통하여 관리의 최적화를 이뤄낼 수가 있다.

이상으로 Active Directory에서 생성되는 9가지 개체들에 대해서 간단히 설명하였다. 지금부터는 간단한 예제를 통해서 개체를 생성해 보도록 하겠다. 예제에서 windowsnetwork.msft 도메인의 하위에는 Bulitin, Computers, Domain Controllers, ForeignSecurityPrincipals, Users 라는 5개의 서브폴더가 보인다. 각각 Active Directory에서 기본생성되는 로컬그룹, 멤버서버로 등록되는 컴퓨터계정, 도메인컨트롤러들, 트러스트관계를 맺었을때의 외부 컴퓨터들, 기본제공되는 글로벌 그룹과 Administrator 등과 같은 사용자들의 기본적인 저장위치가 된다. 이 기본적인 폴더는 그대로 두고 추가의 작업을 해 본다.

제일 먼저 조직단위(OU)를 먼저 추가할 것을 권장한다. 시행착오를 겪으면서 이해가 되겠지만 관리가 상당히 편해진다. 필자 개인적인 생각으로는 NT4.0의 도메인과 Active Directory 도메인과의 관리적인 측면에서 큰 변화라면 바로 이 조직단위(OU)의 유무를 이야기 하고 싶다. Active Directory에서는 이 OU를 제공함으로써 계층적인 도메인의 관리를 가능하게 만들었고, 관리의 효율성을 극대화 시키고, 도메인의 구조를 간소화 시키는 등 Active Directory가 돋보이게 만드는데 크게 기여를 하고 있기 때문이다. OU를 적절히 사용하는 것은 원활한 관리와 직결된다고 하겠다.

Active Directory사용자 및 컴퓨터 관리도구를 열고 도메인이름을 클릭한후 새로만들기 에서 ‘조직단위’를 클릭하여 OU를 생성한다.

예제에서 ‘전체조직’이라는 이름을 할당했다. ‘전체조직’이라는 이름의 OU를 먼저 생성한 다음 차례대로 그 아래에는 ‘서울, 미국, 대전, IT관리’등의 하위OU를 생성했다.

일단은 위와 같이 조직을 관리할 수 있도록 구성을 먼저 하고 그 다음에 사용자 및 그룹들을 생성하는 것이 바람직하다. 같은 방법으로 각각의 OU에서 사용자, 그룹 등의 개체들을 생성할 수 있다.

13-3-1. 첫 번째 도메인의 첫 번째 도메인 컨트롤러 설치 (포리스트 루트 도메인 생성)

Windows Server 2003에서는 NT4.0과 비교하여 도메인의 구성 측면에서 많은 변화를 보인다. Active Directory의 설치 역시 그러하다. NT Server 4.0을 셋업할 때 PDC, BDC, 독립실행형 서버등으로 역할을 미리 결정해야 했던 것과는 달리 Windows Server 2003에서는 OS의 설치와 도메인컨트롤러서비스의 설치가 분리되어 있다. 그렇기 때문에 모든 Windows Server 2003은 기본적으로 독립실행형 서버이고 나중에 Active Directory를 설치함으로써 도메인 컨트롤러로 동작하게 된다. 반대로 도메인 컨트롤러에서 Active Directory를 제거하면 언제든지 그 서버는 일반서버로 동작을 하게 된다.

Windows Server 2003은 Windows 2000 Server와 마찬가지로 이것을 가능하게 만들어주는 유틸리티인 "dcpromo"를 제공한다. dcpromo는 Domain controller promotion을 의미한다. 셋업을 시작하기 전에 먼저 고려해야 할 사항이 있다. 도메인이름과 DNS서버의 위치를 결정해야 한다. 도메인이름을 결정하는 일과, DNS는 아주 밀접한 관계가 있지만 이러한 사항들은 14장을 통해서 살펴보도록 하자. 지금부터 도메인을 구축해 보고자 한다. TCP/IP설정을 살펴서 DNS서버의 IP Address가 현재 셋업을 하는 컴퓨터의 IP Address로 되어 있도록 확인한다.

먼저 시작à실행창에 "dcpromo "를 입력하고 실행하면 Active Directory 설치마법사가 실행된다.

마법사를 실행하면 몇 가지 옵션을 결정하고 입력해 주어야 하는데 복수도메인 환경을 셋팅하기 위해서는 잘 이해해야 할 옵션이다. 이것을 명확히 이해하기 위해서는 먼저 Active Directory의 논리적인 구조에 대해서 잘 이해를 하고 있어야 한다. 아래의 <그림13-16>에서는 dcpromo.exe를 실행하여 Active Directory설치를 하는 동안에 선택해야 하는 옵션을 <그림13-6>의 도메인 구조와 연계하여 정리했다.

회사에서 도메인환경을 구축하고자 결정하고 첫 번째 도메인컨트롤러를 셋업하고 있다면 기본설정으로만 계속 넘어가면 그만이다. 새도메인의 도메인컨트롤러이고, 새로운 포리스트를 만드는 것이기 때문이다. 포리스트 루트 도메인의 첫 번째 도메인컨트롤러가 셋업되면 트리와 포리스트까지 함께 만들어 진다는 것을 생각하자. 이 점을 염두에 두면 추가로 도메인을 확장하는데 있어서 도메인 컨트롤러를 설치하는 것이 쉽다.

Windows Server 2003의 보안강화로 Windows 95, Windows NT 4.0 SP3 이전 버전에서는 로그온을 하지 못한다는 메시지를 보여준다.

도메인 컨트롤러의 종류를 결정해야 한다. 새로운 도메인 컨트롤러인지, 추가 도메인 컨트롤러인지를 묻는다. 당연히 처음 도메인을 만들 때는 기본옵션을 선택해야 할 것이고, 이미 만들어진 도메인에서 만일의 경우를 대비한 백업을 위해 혹은 성능향상을 위해 추가 도메인 컨트롤러를 셋업하고 있다면 두 번째 옵션을 선택한다.

다음의 그림은 "새 도메인 만들기" 선택 사항이다. 앞에서 첫 번째 도메인을 만들 때 새로운 트리가 만들어진다고 설명했다. 회사에서 설계된 최초의 도메인을 만들고 있는 과정이라면 첫번째 옵션인 “새 포리스트에 있는 도메인”을 선택한다. 이미 포리스트 루트 도메인이 있는 상황에서 추가로 복수도메인 환경을 요구할 때 트리로 확장할 것인지 포리스트로 확장할 것인지 둘중의 하나를 결정해야 한다. 포리스트 루트 도메인의 도메인 이름과 연속된 이름을 사용하는 트리레벨로 도메인을 추가한다면 "기존 도메인 트리에 자식 도메인"을 선택한다. 포리스트 루트 도메인의 도메인 이름과 연속되지 않은 독립된 도메인 이름을 사용하는 환경인 포리스트 레벨로 도메인을 추가하고자 한다면 세 번째 옵션인 "기존 포리스트에 있는 도메인 트리"를 선택한다. 예제에서는 첫 번째 도메인의 첫 번째 도메인 컨트롤러를 셋업하고 있으므로 첫 번째 옵션인 “새 포리스트에 있는 도메인”을 선택했다.

도메인 이름을 결정한다. 대부분의 회사는 도메인 이름을 가지고 있다. 만일 회사를 대표할 만한 DNS도메인이름이 없다면 미리 도메인을 등록할 것을 권장한다. Active Directory 도메인 이름은 DNS도메인 이름을 사용한다. 그렇기에 DNS는 Active Directory와 아주 밀접한 관계가 있다. Active Directory 환경에서 DNS는 필수적인 요소가 된 것이다. 클라이언트가 도메인 컨트롤러를 찾고자 할 때 DNS는 도메인 컨트롤러 역할을 하고 있는 서버의 이름(Hostname)과 위치(IP Address)를 제공한다.

다음엔 NetBIOS도메인 이름을 입력해야 한다. 이것은 Windows2000 이전버전인 NT4.0, Windows9x등의 시스템에서 사용되는 도메인 이름을 의미한다. 하위호환성을 위해서 Active Directory 도메인은 2가지의 이름을 유지하고 있다. DNS도메인 이름이 windowsnetwork.msft이지만 NetBIOS도메인이름은 windowsnetwork이 아니어도 상관없다. 전혀 다른 이름을 사용해도 되지만 아무래도 그것은 사용자들에게 상당한 혼란을 유발할 것이다.

Active Directory Database를 저장할 저장위치와 로그파일을 저장할 위치를 결정해 준다. 기본위치는 OS가 설치된 "WINDOWS"의 하위폴더인 NTDS 폴더이지만 최적의 성능 및 복구기능을 위해서는 이들을 각각 다른 하드디스크에 저장할 것을 권장한다.

<그림13-23>에서는 공유시스템볼륨을 저장할 폴더의 위치를 결정한다. 한 도메인에 여러대의 도메인 컨트롤러를 둘 수가 있는데 Active Directory를 제외하고서도 이들은 그룹정책, 로그온스크립트 등의 몇가지 정보를 공유해야 할 필요가 있다. 이러한 공용파일을 저장하는 위치가 Sysvol이라는 이름의 폴더인데 이것을 어느 위치에 저장할 것인지를 묻는 것이다. Sysvol폴더는 NTFS 파티션에서만 생성될 수 있다.

Active Directory설치 마법사는 지금 셋업하는 windowsnetwork.msft도메인 이름서비스를 해 주는 DNS서버를 찾을 수 없다는 메시지를 보여주고 있다. DNS서비스가 없거나, DNS서비스가 있더라도 해당 도메인이 구성이 되어 있지 않다면 이러한 메시지가 나타난다. 두번째 옵션인 “이 컴퓨터에 DNS서버를 설치하여 구성하고 이 DNS서버를 컴퓨터의 기본 DNS서버로 설정”을 선택하고 계속 진행한다. 최초의 도메인 컨트롤러 설치시 가장 쉽고 완벽하게 설치할 수 있는 방법이기도 하다.

<그림13-25>는 Active Directory를 읽을 수 있는 퍼미션을 결정하는 "사용권한"그림이다. Windows2000 이전버전의 서버에서 실행되는 RAS서비스 등의 프로그램이 Active Directory에 접근을 해야 하는 환경이라면 첫 번째 옵션을 선택한다. Windows2000, 2003서버로만 구성된 도메인 환경[1]이라면 기본값인 두 번째 옵션을 선택하는 것이 좋다. 이것은 도메인 컨트롤러에 보다 향상된 보안을 제공한다.

백업받은 Active Directory Database를 이용해서 복구를 해야 할 경우, 시스템 시작시 [F8]키를 이용해서 "Active Directory Restore Mode"로서 시스템을 시작할 수 있는 옵션을 지원한다. 이 경우 사용할 Administrator암호를 입력한다. 이것은 정상적인 경우 관리자가 사용하는 암호와는 별도의 암호이다. 백업을 위해서 잘 관리해 두어야 한다. 물론 관리자의 암호와 같은 암호를 사용할 수도 있다.

이제 설치를 위한 준비과정을 완료했다. <그림13-27>에서는 당신이 선택한 옵션을 보여주고 셋업이 끝났을 때 어떤 구성을 가지게 될 것인지를 보여주고 있다. 확인하고 잘못 설정한 부분이 있다면 [뒤로]버튼을 이용하여 옵션을 수정하는 것이 가능하다.

약 5~10분 정도의 시간 동안 Active Directory 설치작업이 진행되고 나면 완료되었음을 알리는 설치완료 화면을 만날 수 있다. 에러가 발생하지 않았다면 설치는 잘 된 것이다.

설치를 마치면 반드시 시스템을 다시 시작해야 한다. 설치를 마치고 처음 재시작시 상당한 시간이 걸릴 수가 있다. 보통 15분여 정도면 최초 로그온 화면을 만날 수 있다. 로그온 화면이 나올 때까지 참고 기다리자.

13-3-2. 설치 후 확인, 문제해결

13-3-2-1. DNS SRV레코드 등록 확인

설치가 완료된 후 처음 로그온을 한 다음, Active Directory가 제대로 설치되었는지 확인할 필요가 있다. 차근 차근 살펴보자.

먼저 DNS관리콘솔을 열어서 Active Directory설치시 입력했던 도메인 영역을 찾아본다. <그림13-29>에서 보면 windowsnetwork.msft 영역이 있고, 이 영역으로부터 위임된 _msdcs.windowsnetwork.msft 영역이 보인다. _msdcs.windowsnetwork.msft 영역아래에서 dc, domains, gc, pdc라는 네 개의 서브도메인이 보인다. 이들은 SRV(Service)레코드를 담고 있는 서브도메인들이다. 이들이 없다면 클라이언트들이 로그온을 위해 도메인에 접근할 수 없다. 이들의 생성을 확인해 주어야 한다. 만일 위와 같은 DNS영역을 찾을 수 없다면 다음과 같은 순서로 접근해 보자.

① TCP/IP등록정보를 살펴서 DNS서버의 IP가 자신의 IP Address로 되어 있는지 확인한다.

② DNS관리콘솔을 열고, 도메인이름을 마우스 오른쪽 클릭하여 등록정보로 접근한 다음 "동적업데이트 "가 "예"이거나 "보안된 업데이트만"으로 되어 있는지 확인한다. <그림13-30>

③ 명령프롬프트를 열고 <그림13-31>에서처럼 netlogon service를 재시작하고, ipconfig/registerdns를 이용해서 DNS에 자신의 IP를 동적업데이트하도록 시도한다.

위의 ①②③ 절차를 진행한 후 다시 DNS관리콘솔을 열고 [F5]키를 사용하여 ‘새로고침’을 해 보면 업데이트된 레코드를 확인할 수 있을 것이다.

13-3-2-2. Active Directory 관리도구 생성 확인

관리도구를 열어 Active Directory 관리도구가 생성되었는지 확인한다. 만일 생성되지 않았다면 서버의 %windir%\System32폴더나 Windows Server 2003 원본CD의 i386폴더 아래에 있는 "Adminpak.msi"를 통하여 관리도구를 설치할 수 있다.

13-3-3. 첫 번째 도메인의 추가 도메인 컨트롤러 설치 (Replica)

도메인에 하나의 도메인 컨트롤러(DC)만 있어서는 아무래도 불안하다. 규모가 작은 회사라고 하더라도 적어도 하나의 추가 도메인컨트롤러는 있어야 만일의 경우에 문제가 없다. 또, 회사가 본사가 서울이고, 지사가 부산쯤 있는 두 지역으로 나뉘어진 조직구조라면 서울에 하나만 DC를 둬서는 부산의 사용자들에게 빠른 응답시간을 제공하기 어렵다. 이럴 경우에는 부산에 추가 DC를 두는 것도 하나의 방법이다. 추가 도메인 컨트롤러를 설치하는 방법에 대해서 알아본다. 역시 dcpromo를 이용하지만 몇가지 옵션이 달라지게 된다. 먼저 추가DC가 되고자 하는 시스템의 TCP/IP설정을 살펴서 DNS의 IP Address를 확인한다. 그 DNS는 첫 번째 도메인의 정보를 담고 있어야만 설치가 진행될 수 있다. 예제에서는 windowsnetwork.msft 도메인의 추가도메인컨트롤러를 셋업하는 그림을 보여준다.

<그림13-33. 추가 도메인 컨트롤러 설치 - 도메인 컨트롤러의 종류>	"도메인 컨트롤러 종류”화면에서 "기존도메인의 추가 도메인 컨트롤러"옵션을 선택한다.
<그림13-34. 추가 도메인 컨트롤러 설치 - 네트워크 자격(Credential) 제공>	추가도메인 컨트롤러가 되기 위해서는 기존 도메인의 관리자계정과 암호가 필요하다. 암호가 맞지 않다면 역시 더 이상 셋업을 진행할 수 없다.
<그림13-35. 추가 도메인 컨트롤러 설치 –도메인 선택>	도메인 컨트롤러로서 참여하고자 하는 도메인의 이름을 입력한다. [찾아보기>버튼을 이용할 수도 있다. 예제에서는 windowsnetwork.msft 라는 먼저 설치된 도메인의 이름을 입력했다. [다음]버튼을 클릭하면 DNS서버에 연결해서 도메인을 확인하게 되는데 여기서 DNS서버상에 문제가 있다면 더 이상 셋업을 진행할 수 없다. DNS를 먼저 확인해 봐야 한다.
<그림13-36.추가 도메인 컨트롤러 설치 -요약>	다음 과정부터는 첫 번째 DC의 셋업과 크게 다르지 않다. 두 가지만 주의하면 문제가 없을 것이다. 바로 DNS서버와 정확한 관리자계정과 암호이다. 설치마법사가 선택한 옵션들을 보여주고 있다. 내용을 읽어서 첫 번째 도메인 컨트롤러의 설정과 비교해 보자.
<그림13-37.추가 도메인 컨트롤러 설치 -요약>	추가 도메인 컨트롤러가 설치되는 과정이 보인다. <그림13-37>을 보면 첫번째 도메인 컨트롤러로부터 디렉터리를 복제해 오고 있는 것을 볼 수 있다. 이 과정을 마치면 추가 도메인 컨트롤러 설치는 완료된다.
<그림13-38. Active Directory Users and Computers 관리콘솔 >	추가도메인 컨트롤러의 설치가 완료되면 Active Directory 사용자 및 컴퓨터(ADUC) 관리콘솔의 Domain Controllers 컨테이너를 확인하면 추가 도메인 컨트롤러인 Goguma가 도메인 컨트롤러로 추가된 것을 확인할 수 있다.

13-3-4. 자식(Child) 도메인 설치

지금까지 위에서 설명한 두가지 설치만 하더라도 단일도메인을 구성하는데는 충분하겠지만 추가로 보다 확장된 도메인을 구성하기 위한 설치방법이라도 익혀두자는 의미로 확장되는 도메인의 설치를 다루었다. 아직 도메인모델 자체를 쓰지 않고 있다거나, 전반적인 공부를 위해서 책을 읽는 독자라면 아래의 설치는 일단 넘어가자.

다음에는 포리스트 루트 도메인의 트리로서 확장하는 자식도메인을 구축하기 위한 Active Directory설치옵션을 살펴본다. 역시 두가지 조건이 필요하다. 올바른 DNS서버의 IP Address와 포리스트 루트도메인의 관리자계정과 암호를 알고 있어야 한다. 예제에서는 windowsnetwork.msft 이라는 이름의 루트도메인에 china라는 지사의 도메인을 만드는 과정이다. 

<그림13-39. Child domain 설치 - 도메인 컨트롤러의 종류 결정>	자식 도메인을 만들기 위해서는 "새 도메인의 도메인 컨트롤러"를 선택해야 한다. 트리라는 형태로 만들어지기는 하지만 엄연히 새로운 도메인이 생성되는 것이다.
<그림13-40. Child domain 설치 - 트리 또는 자식도메인 만들기>	새 도메인 만들기 화면에서 "기존 도메인 트리에 자식 도메인"을 선택한다. Windowsnetwork.msft의 트리에 연결하겠다는 것을 의미한다.
<그림13-41. Child domain 설치 - 네트워크 자격>	이 작업을 할 수 있는 권한이 있는 사용자계정과 패스워드를 요구하고 있다. 루트도메인의 관리자계정과 패스워드, 그리고 루트도메인의 도메인이름을 입력한다. 여기서 계정이 맞지 않다거나 DNS에 제대로 연결이 되지 않는다면 더 이상 셋업이 진행될 수 없다. 대부분의 경우 DNS에서 문제점이 발견된다. DNS설정을 살펴보아야 할 것이다.
<그림13-42. Child domain 설치 - 자식 도메인 설치>	부모 도메인이름이 " windowsnetwork.msft "이다. 자식 도메인에는 "china"를 입력했다. 세 번째 창을 보면 새로운 도메인의 이름이 "china.windowsnetwork.msft"이 됨을 보여준다. 이것은 windowsnetwork.msft 루트 도메인과 연속된 이름을 사용함을 보여준다.
<그림13-43. Child domain 설치 - NetBIOS도메인 이름>	NetBIOS 도메인이름을 입력한다. 필수적인 것은 아니지만 DNS의 도메인 이름과 일치하는 이름을 사용하는 편이 좋을 것이다. 예제에서는 "china"를 사용했다. 다음 과정부터는 첫 번째 도메인과 다를바가 없다.
<그림13-44. Child domain 설치 -요약>	요약된 정보를 확인한다.

 13-3-5. 포리스트(Forest) 도메인 설치

다음에는 포리스트 레벨의 도메인을 설치하는 과정이다. 회사에서 Windowsnetwork.msft라는 루트도메인을 설치한 후에 추가로 secure.pe.kr이라는 도메인을 구성하려고 한다.  

<그림13-45. Forest domain 설치 -도메인 컨트롤러의 종류>	역시 새로운 도메인을 만드는 것이므로 "새 도메인의 도메인 컨트롤러"를 선택한다.
<그림13-46. Forest domain 설치 -트리 또는 자식도메인 만들기>	Windowsnetwork.msft 포리스트 루트도메인에서새로운 트리를 만드는 과정이므로, 세번째 옵션인 ‘기존 포리스트에 있는 도메인 트리’를 선택한다.
<그림13-47. Forest domain 설치 - 네트워크 자격 제공>	이러한 작업을 할 수 있는 네트워크 자격증명을 요구하고 있다. 포리스트 루트 도메인인 windowsnetwork.msft 도메인의 관리자계정과 암호, 도메인 이름을 입력한다.
<그림13-48. Forest domain 설치 - 새 도메인 트리>	다음 과정부터는 첫 번째 도메인의 첫 번째 도메인 컨트롤러를 셋업하는 것과 동일하다.
<그림13-49. Forest domain 설치 - NetBIOS 도메인 이름>	NetBIOS 도메인 이름으로 SECURE를 입력했다.

첫 번째 도메인을 셋업하고 추가의 작업들을 진행하다 보면 종종 설치가 잘 되지 않는 경우가 발생하는데, 필자의 경험으로는 문제의 거의 대부분은 DNS의 SRV레코드 미등록, 잘못된 네트워크 자격증명에 있다. 이들을 먼저 살펴볼 것을 권장한다. 이상으로 Active Directory의 셋업을 마치고 다음 장에서는 Active Directory의 몇가지 관리방법에 대해서 이야기한다.

13-2-1. Active Directory의 구조

13-2-1-1. 도메인

이번 장에서는 Active Directory가 어떻게 구성이 되어 있는지를 살펴보고, 각각의 구성요소에 대해서 이해를 필요로 하는 내용들을 설명하도록 한다. 가장 먼저 생각할 수 있는 구성요소는 Active Directory환경에서 핵심이 될 수 있는 "도메인"을 들 수 있다.

도메인은 Active Directory의 영향이 미치는 범위를 논리적으로 정의한 단위이다. 도메인에 소속된 서버 및 클라이언트 컴퓨터들은 도메인에 존재하는 Active Directory가 제공하는 디렉터리 서비스의 영향권 안에 놓이게 된다. 기본적으로 Active Directory는 도메인 내에서 제공되며 사용되고 유지된다. 회사의 필요에 의해 여러개의 도메인이 생성되었다면 각각의 도메인마다 자신들의 고유한 Active Directory를 가지게 되는 것이다.

그렇다면 도메인은 어떻게 만들 수가 있을까? 도메인을 관리하는 특별한 서버가 제공된다. 바로 "도메인 컨트롤러(Domain Controller; DC)"라는 이름으로 불리우는 서버이다. Microsoft의 도메인을 구현하기 위해서 가장 먼저 해야 할 일은 도메인컨트롤러를 셋업하는 일이다. 도메인 컨트롤러가 하나 셋업이 되었다는 것은 "도메인"이 하나 생겼다는 것과 동일한 의미이다. 도메인 컨트롤러는 Active Directory라는 이름의 데이터베이스를 가지고 있으며 이것은 도메인의 영역내에서 쓰일 수 있는 공통의 정보를 담고 있게 된다. 만일 도메인이 구성되고 나서 도메인 컨트롤러가 손상되는 일이 생긴다면 도메인의 Active Directory는 심각한 문제가 생길 수밖에 없다. 이를 대비하기 위하여 우리는 한 도메인에 추가 도메인컨트롤러를 셋업하는 것이 가능하다. 이렇게 추가되는 도메인 컨트롤러 역시 개별적인 Active Directory를 가지기는 하지만, 새로운 Active Directory를 가지는 것이 아니라 첫 번째 생성된 도메인 컨트롤러의 Active Directory에 대한 복제본을 가지게 된다. 결국 한 도메인에는 하나의 Active Directory만 있게 된다. 이 경우 두 개의 도메인 컨트롤러들은 Active Directory에 새롭게 생성되는 내용이 있을 경우 다른 도메인 컨트롤러에 그 내용을 전파하여 도메인내에서의 일관성을 보장해 주어야 한다. 이러한 작업을 가리켜 "Active Directory 복제"라고 부른다. 이러한 복제도 도메인 내에서 행해지는 작업이다. [1]

정리하면, 도메인은 디렉터리 서비스의 영향이 미치는 보안의 경계이며 한 도메인내의 도메인 컨트롤러들이 복제라는 프로세스에 의해 Active Directory의 일관성을 유지해 주는 단위가 된다. 회사가 한국, 미국, 일본 등 다국적 기업환경에 있다고 하더라도 하나의 도메인으로 구성하는 것이 가능하다. 도메인은 철저하게 논리적인 관점의 단위이다.

13-2-1-2. OU (Organizational Unit)

한 회사에서 네트워크 환경을 도메인으로 구성하여 전체 리소스에 대한 집중화된 관리가 가능하다. 도메인의 관리자는 도메인 내에서 모든 리소스에 대해서 완전한 통제권한을 가지고 있다. 조직이 관리자 혼자서 관리하기에 벅찰 정도로 규모가 크다거나, 혹은 지역적으로 멀리 떨어진 환경의 회사여서 상황에 대처하는데 효율성이 떨어진다거나, 관리업무 자체를 보다 세분화시켜서 여러 관리자가 전문화된 관리영역 등을 가지게 하고자 한다면 OU라는 논리적 구조를 이용할 수 있다.

OU는 Active Directory에 존재하는 사용자계정, 컴퓨터계정, 프린터, 폴더 등의 리소스등을 논리적으로 그룹화하여 관리하게 하기 위한 Active Directory의 또 하나의 구성요소이다. 예를 들면 관리자는 서울, 부산, 대전으로 나뉘어진 회사의 조직구조를 그대로 반영하여 서울OU, 부산OU, 대전OU 라는 형식으로 리소스를 조직화할 수 있다. 또한 부서를 반영하여 영업부OU, 관리부OU, 개발팀OU등의 OU를 이용할 수도 있다. 이것은 도메인이라는 커다란 단위를 사용함과 동시에 내부적으로 보다 작은 단위로써 유연한 관리방법을 제공하는 것이다.

실제로 OU를 사용하는 큰 이유중의 하나는 부서별, 지역별, 사용자유형별로 차별적인 그룹정책을 구현하기 위한 목적때문이다. AD의 그룹정책을 적용하기 위한 최소 단위가 OU이기 때문에 사용자 및 컴퓨터를 OU로 조직하면 원하는 차별화된 그룹정책을 구현할 수 있다. 물론 이렇게 OU로 구분한 경우에도 OU가 속한 도메인 전체적인 정책은 유지된다.

<그림13-5. Active Directory Domain의 구조>

13-2-1-3. Object (개체)

도메인의 Active Directory에 저장되는 하나하나의 구성요소를 object라고 부른다. 잘 알고 있는 사용자 계정, 컴퓨터 계정 등이 그것이다. NT4.0의 디렉터리 데이터베이스에 비해서 Active Directory에는 사용자, 그룹, 컴퓨터 외에도 연락처, 공유폴더, 프린터 등의 다양한 자원들까지도 Object로서 포함될 수가 있다. 이것은 큰 의미가 있다. 도메인이 구축된 기업환경에서 생각할 수 있는 많은 요소가 Active Directory에 저장됨으로써 사용자들을 Active Directory를 통해서 다양한 검색기능을 이용해서 자원에 훨씬 쉽게 접근할 수 있는 환경이 제공된다.

13-2-1-4. Tree, Forest (트리, 포리스트)

필요에 의해서 하나의 도메인만 가지고는 회사의 요구에 만족하지 못할 경우가 있다. 이런 경우 두 개 이상의 도메인을 사용하게 될 수도 있는데 아무래도 하나의 도메인만 사용할 때에 비해서는 고려해야 할 것이 많다. 도메인이 보안의 경계영역이라고 했으니 두 개의 도메인이면 서로 다른 보안의 영역이 생기는 것이 된다. 하지만 회사에서는 도메인과 도메인간의 자원들을 공유해야 할 필요성이 생기게 되고 이러한 것을 완전히 만족시켜야만 제대로 된 도메인 환경을 만들 수가 있게 되는 것이다. 가장 추천하는 도메인 모델은 "단일도메인(Single Domain)"이다. 하지만 단일 도메인 모델로서 회사의 환경과 요구를 충족시킬 수 없다면 당연히 복수 도메인 모델(Multi Domain Model)을 사용할 수밖에 없다. 처음 하나의 도메인이 있는 상태에서 새로운 도메인을 추가할 때 어떻게 추가하느냐에 따라서 트리와 포리스트라는 2가지 구조를 사용할 수 있다.

한 회사에서 서울에 secure.pe.kr 이라는 이름을 가진 첫 번째 도메인이 있다고 가정한다<그림13-5>. 이렇게 첫 번째 만들어진 도메인을 가리켜서 "포리스트 루트 도메인(Forest Root Domain)"이라고 한다.

회사에서 새롭게 대전지역에 지사를 하나 냈는데 그곳에는 별도의 IT관리조직이 있는 독립된 성격의 회사라고 가정을 한다. 대전지사를 위해서 하나의 도메인을 구축하려고 할 때 무작정 만들 수는 없는 노릇이다. 서울에 있는 포리스트 루트 도메인과 연관성을 가져야 할 것이다. IT관리는 분리가 되었다고 하지만 한 회사이고 그러다 보면 서울과 대전간의 수많은 자원의 교류가 있어야 할 것이기 때문이다. 서울의 직원이 대전으로 파견을 나온다던가 하는 형태의 업무환경 역시 얼마든지 생길 것이다. 이러한 요구를 필요로 할 때 당신은 Forest Root Domain처럼 전혀 새로운 도메인을 만드는 것이 아니라 포리스트 루트 도메인과 특별한 관계인 트러스트(Trust relationshop)를 가지는 도메인을 만들 것을 고려해야 한다. 그 방법으로서 두 가지 방법이 제시된다. 트리와 포리스트가 그것인데, 이들의 가장 두드러진 차이점은 도메인이름의 연속성에서 찾아볼 수 있다. 추가 도메인을 만들 때 기존의 포리스트 루트 도메인이 사용하는 이름과의 연속적인 이름을 선택했다면 트리구조가 되는 것이고 포리스트 루트 도메인과 다른 도메인 이름을 사용했다면 포리스트구조가 된다.

트리에 대한 이해는 "본사와 지사"의 형태로 이해하면 쉽다. Secure.pe.kr이라는 이름의 본사 도메인이 있는데 추가로 지사에 도메인을 설치하고자 할 때 Secure.pe.kr의 이름을 연속해서 사용하는 Daejun.Secure.pe.kr이라는 이름을 선택했다면 secure.pe.kr 도메인의 하위도메인이 생성되는 것이다. 이 경우는 Secure.pe.kr이라는 이름의 포리스트 루트 도메인의 하위 도메인으로서 도메인을 확장하는 것을 의미한다. Active Directory에서는 이것을 "포리스트 루트 도메인의 트리에 자식 도메인(Child Domain)을 추가했다"라고 표현한다. 이때 Secure.pe.kr도메인은 부모 도메인(Parents domain), Daejun.secure.pe.kr은 자식 도메인이 된다. 말 그대로 부모, 자식간의 관계로서 도메인을 확장하는 것을 트리구조라고 부르는 것이다. 이들은 한 나무(Tree)에서 뻗어나온 것이기 때문에 당연히 이름을 같이 사용한다.

회사가 Secure.pe.kr 도메인 외에 이미 확보한 DNS도메인이 있어서 반드시 그것을 사용해야 한다면, 혹은 최근에 다른 회사 하나를 M&A에 의해서 취득을 했는데 그 회사의 대외적인 인지도를 이용하기 위해서 기존의 이름을 그대로 사용해야 할 필요성이 있다면, 이런 경우 당신은 트리 구조로 도메인을 확장한다는 것이 적합하지 않다는 것을 알 수 있다. 트리 구조의 도메인 이름 연속성이 현재의 요구사항에 부합되지 않는다는 것을 알기 때문이다. 이 경우 포리스트 루트 도메인의 트리에 새로운 도메인을 추가하는 것이 아니라 포리스트에 새로운 트리를 만드는 것으로 도메인을 추가하는 것이 가능하다. 이것은 트리와는 달리 포리스트 루트 도메인의 이름에 대해 연속성을 가지지 않는다. 예를 들어 회사에서 가지고 있는 또 하나의 이름이 windowsnetwork.msft라면 추가 도메인의 이름으로서 windowsnetwork.msft를 그대로 사용할 수 있다. 이러한 구조를 가리켜서 포리스트라고 부른다. 포리스트 루트 도메인의 트리에 도메인을 추가한 것이 아니라 새로운 트리를 만들어 낸 것이다. 결국 회사의 환경에서 두 개의 트리가 생긴 것이니 "나무(tree)가 여러 그루 모여 있으니 바로 숲(forest)을 이룬다"라는 것이다. 재미있는 용어선택이다. 트리와 포리스트는 단일 도메인 환경이 아닌 복수 도메인환경에서 사용되는 용어이다. 만일 회사가 Single Domain Model만으로 조직의 요구를 충분히 만족시킬 수 있다면 이것은 전혀 필요가 없는 구조가 될 것이다.

정리하면, Active Directory는 여러개의 도메인을 지원하기 위한 방법으로 트리(tree)와 포리스트(forest)라는 두가지 구조를 제공하고 있는데 이들의 가장 큰 차이점은 첫번째 도메인인 포리스트 루트 도메인의 이름과의 연속성의 유무에 있다고 할 것이다.

회사에 secure.pe.kr이라는 이름의 포리스트 루트 도메인이 하나 있고, daejun.secure.pe.kr과 japan.secure.pe.kr이라는 이름을 사용하는 자식도메인이 각각 있고 windowsnetwork.msft라는 이름의 도메인이 하나 있다면 이 회사에는 총 4개의 도메인이 있는 복수도메인 환경에 있는 것이다. 이 4개의 도메인들은 각각 트리와 포리스트라는 특별한 구조로서 묶여 있지만 엄연히 별개의 도메인이다. 이 회사에서는 도메인마다 하나씩 총 4개의 Active Directory를 가지게 된다. 이 각각의 Active Directory는 자신의 도메인 내에서 복제프로세스에 의해서 도메인 컨트롤러마다 복제를 하게 되고, 자신의 도메인 내에서 리소스에 할당되어 사용되게 된다. 하지만 이 4개의 도메인은 어디까지나 논리적인 개념일 뿐이다. 지역적으로는 한군데에 있다고 하더라도 여러개의 도메인으로 구성이 되어 있을 수 있기 때문에, 그러다 보니 서로 다른 도메인에 속해 있는 사용자들끼리의 자원의 교류가 필수적으로 따라오기 마련이다. 이것은 결국 도메인과 도메인간의 보안의 경계 영역을 넘게 되는 것을 의미한다. 바로 이러한 점 때문에 우리는 4개의 도메인을 만드는데 완전하게 독립된 도메인을 만든 것이 아니라 트리나 포리스트 등의 구조를 이용해서 도메인을 확장했던 것이다. 그렇다면 이러한 구조를 이용해서 도메인을 확장하면 뭔가 특별한 점이 있다는 것일텐데, 그것이 무엇일까?

기본적으로 디렉터리 서비스는 도메인 내에서 동작한다. 서로 다른 도메인으로 디렉터리 서비스를 확장시켜 주는 것이 바로 도메인과 도메인간의 관계인 "트러스트 관계(Trust Relationship)"이다. 트리나 포리스트 구조로써 도메인을 확장했을 때는 자동적으로 이들 도메인간에는 "양방향 전이 트러스트 관계 (Two-way transitive trust relationship)"이 맺어지게 된다.

☞ 양방향 전이 트러스트 관계 (Two-way transitive trust relationship) Windows NT 4.0 도메인 환경에서는 도메인과 도메인간의 트러스트 관계를 수동으로 맺어야만 했다. A와 B라는 두 개의 도메인이 있을 때 A도메인의 회사의 모든 사용자들이 있고, B도메인에는 파일서버,프린트서버등의 리소스를 가진 서버들이 있다고 가정하면 A도메인의 사용자가 B도메인의 자원에 접근하도록 하기 위해서 B도메인에서는 A도메인으로 트러스트 관계를 설립해야 한다. 이 경우 B도메인은 "Trusting Domain"이 되고 A도메인은 "Trusted Domain"이 된다. B도메인이 A도메인을 트러스트(trust)하고 있는 것이다. 이것은 단방향 트러스트 관계(One way trust relationship)이다. <그림13-7. Trust Relationship> 이러한 상황에서 거꾸로 B도메인의 사용자가 A도메인에 있는 자원에 접근을 하고자 한다면 반대로 A도메인에서도 역시 B도메인으로 트러스트를 해야 한다. 그렇게 되면 양방향 트러스트 관계가 설립된다.   만일 하나의 도메인이 더 있다고 가정을 해 보자<그림13-8>. <그림13-8. Non-transitive Trust relationship> B도메인이 A도메인을 트러스트하고, A도메인이 C도메인을 trust하고 있다고 하더라도 B도메인과 C도메인은 아무런 연관성이 없다. 만일 B도메인과 C도메인간의 자원의공유를 위해서는 별도의 트러스트 관계를 맺어야만 하는 것이다. 바로 Non-transitive(비전이)하다는 것이다. 이것이 NT4.0에서의 도메인의 트러스트 관계이다. Active Directory 도메인은 다르다. <그림13-8>의 B도메인과 C도메인간에도 자원의 공유가 가능하다. 바로 트러스트 관계가 전이(transitive)되는 것이다. 위에서 설명한 트리나 포리스트관계로 도메인을 확장하게 되면 그들 도메인 사이에는 자동으로 양방향 전이 트러스트 관계가 설립된다.

13-2-1-5. Global Catalog

도메인의 Active Directory는 도메인 내에서 사용된다. 회사가 여러개의 도메인으로 구성되어 있는 환경을 고려해 보면 사용자가 Active Directory에서 특정한 Object를 찾고자 할 때 그러한 쿼리를 처리해 주는 것이 문제가 될 수 있다. A라는 도메인에 소속된 사용자가 "원석"이라는 이름을 이용해서 Active Directory에 쿼리를 던져서 wssong이라는 Object를 찾고자 할 때, 그러한 정보를 가지고 있는 A도메인의 도메인 컨트롤러는 "원석"이라는 이름을 검색해야 할 것이다. 만일 없다면 그 다음에 요청은 "B"도메인으로 가야 할 것이고 없다면 다시 "C"도메인으로 가야만 한다. 그렇게 해야만 사용자는 전체 도메인 환경에서 원하는 정보를 검색하는 것이 가능하다. 이러한 일들을 처리하기 위해 Active Directory는 포리스트 레벨의 도메인의 모든 Active Directory에 대한 Object들의 부분 복제본(전체 디렉터리 복제본이 아님)을 하나의 서버에 집중시켜 둔 별도의 저장소를 가지게 되었다. 그것을 가리켜서 "글로벌 카탈로그(Global Catalog)"라고 부른다.

<그림13-9>를 보면 사용자는 "송원석"이라는 이름만으로 Active Directory에서 "wssong"이라는 이름의 object(개체)를 검색하였다. 이때 이 검색을 처리해 준 서버는 글로벌 카탈로그를 가진 서버이다. 즉, 글로벌 카탈로그 서버가 사용자의 검색요청을 처리한다는 것을 의미한다. 포리스트 환경에서 첫 번째 도메인의 첫 번째 도메인 컨트롤러는 글로벌 카탈로그 서버역할을 맡고 있다.

관리도구의 "Active Directory사이트 및 서비스"를 통해서 글로벌 카탈로그 서버를 확인하는 것이 가능하다. 관리도구를 실행한 다음, “SitesàDefault First Site NameàServersà서버이름àNTDS Settings”의 속성을 연다<그림13-10>

등록정보를 열어보면 "글로벌 카탈로그"가 체크되어 있음을 확인할 수 있다. 추가로 글로벌 카탈로그 서버를 지정할 때도 같은 방법을 사용해서 접근한다.

앞에서 설명한 구조는 논리적인 관점의 Active Directory구조였다. 이것만으로는 부족하다. 실제 환경에서는 훨씬 더 다양한 요구가 있기 마련이기 때문이다. 한가지 상황을 가정해 보자. A회사는 서울에 본사를 두고 대전과 부산에 각각 지사를 두고 있다. 이 회사는 secure.pe.kr이라는 하나의 도메인을 구축했고 서울, 대전, 부산에 각각 5대, 3대, 3대씩 총 11개의 도메인 컨트롤러가 설치되어 있다. 서울과 대전, 부산간에는 WAN으로 연결이 되어 있고 모든 클라이언트는 Windows2000 Professional을 사용하고 있다. 관리자는 도메인 컨트롤러간의 복제, 사용자들의 도메인 로그온, Active Directory의 검색요청에 대한 빠른 응답시간 등 회사 전체의 네트워크 환경을 최적화하고자 한다. 각각의 지역간에 상대적으로 느린 WAN환경에서 어떤 방법을 고려해야 할까? 이때 다음의 ‘사이트’라는 물리적인 구조가 필요해진다.

13-2-1-6. 사이트 (Sites)

도메인이라는 논리적인 단위로는 해결할 수 없는 부분이 바로 이러한 것이다. 마이크로소프트는 Active Directory에 사이트(Sites)라는 물리적인 단위를 제공함으로써 해결해 주고 있다. 결국 회사의 지리적인 측면을 반영하여 도메인과 사이트를 적절히 활용하여 논리적,물리적인 측면에서 최적화된 네트워크 환경을 제공하고 있는 것이다. 위와 같은 예제에서 우리는 회사 전체를 하나의 도메인으로 묶을 수 있고, 서울, 대전, 부산 등 각 지역을 각각의 사이트로 설정할 수 있다. 그렇게 설정을 하면 클라이언트들은 DNS통해서 자신의 사이트에 있는 도메인컨트롤러를 찾을 수 있게 되고, 사이트내에서와 사이트간에서의 도메인 컨트롤러간의 리플리케이션은 각각 다른 방법을 사용함으로써 최적화를 이뤄낼 수가 있게 된다.

사이트(Sites)는 잘 연결된 IP Subnet들의 집합이다. "잘 연결된"의 뜻은 "충분한 대역폭이 확보되는"이라는 뜻으로 해석하는 것이 좋겠다. 도대체 얼마큼 대역폭이 확보되어야 잘 연결되었다는 표현을 할 수 있을 것인가? 이것에 대한 정답은 없다. 회사마다 주관적인 설정이 가능할 것이기 때문이다. 56K모뎀으로 연결된 라인이더라도 쓰는데 불편함이 없다면 그 둘의 지역과 지역을 묶어서 하나의 사이트로 만들 수도 있는 것이다. 설사 T1으로 연결되어 있더라도 사용자가 많고 인터넷 액세스가 많아서 지역과 지역간에 제대로 연결이 되기 어렵다면 그들은 두 개의 사이트로 구분이 될 수도 있다. 어디까지나 관리자의 판단이 가장 중요한 요소가 될 수 있다.

13-2-2. Active Directory의 이름

Active Directory에서 사용하는 이름체계에 대해서 공부할 필요가 있다. Active Directory를 처음 접하는 관리자라면 Active Directory의 몇 가지 이름이 다소 생소할 수도 있을 것이다. Active Directory를 쿼리하는데는 LDAP프로토콜을 사용한다. 이름을 짓는 방법 역시 LDAP의 표준에 맞게 구현되어 있다. 다만 Microsoft는 Active Directory Object들의 이름을 짓는데 정통 LDAP이 아닌 특별한 방법을 따라서 구현했다. LDAP Name과 DNS Name체계를 결합시킨 것이다. Active Directory내에서는 LDAP체계를 이용하고, 회사를 구별하는 방법으로는 DNS Name을 이용했다.

13-2-2-1. DN (Distinguished Name) :   Active Directory내에서 User, Computer등 각각의 Object를 유일하게 구분해 줄 수 있는 이름이다.

  (예1) CN=송원석,OU=미국,OU=전체조직,DC=windowsnetwork,DC=msft à windowsnetwork.msft 도메인의 ‘전체조직’OU하위의 ‘미국’OU에 저장된 "송원석"이라는 Displayname을 사용하는 Object.

  (예2) CN=Kildong Hong,CN=Users,DC=secure,DC=pe,DC=kr à secure.pe.kr 도메인의 Users 기본 컨테이너에 저장된 "Kildong Hong"이라는 Displayname을 사용하는 Object.

ADSI Editor를 통해서 Active Directory를 들여다 보면 명확한 DN을 확인할 수 있다. ADSI Edit는 Windows Server원본CD에서 제공되는 Support tool을 설치하면 얻을 수 있다. "Windows Server 원본CD\SUPPORT\TOOLS\setup.exe"를 통해서 설치할 수 있다.

13-3-2-2. RDN (Relative Distinguished Name) : DN은 디렉터리 전체에서가 아닌 특정 컨테이너에서 Object를 구별할 수 있는 이름이다. 위의 (예2)에서 kdhong계정의 RDN은 "Kildong Hong"이다.

13-3-2-3. UPN(User Principal Name) : Active Directory에서의 로그온 이름. 전자메일주소의 이름형태와 동일하다. 사용자계정에 "@secure.pe.kr"이라는 형태의 접미사가 붙어서 하나의 이름을 만들어 낸다. (예) wssong@secure.pe.kr

13-3-2-4. SamAccountName : Window 2000 이전버전의 OS사용자들이 사용할 로그온 이름이다. UPN의 이름과 달라도 상관없지만 상당한 혼란이 있을 것이다.

13-3-2-5. 전체이름(displayName) : 성과 이름이 결합된 이름을 의미한다. 사용자 계정과는 분명히 다르다. 로그온 할 때 사용하는 이름이 아닌, Active Directory에서 보여지기 위한 이름이다. 자원관리를 할 때 사용자 계정이 보이는 것이 아니라 이 전체이름을 가지고 사용자를 구별해서 관리를 하게 된다. <그림13-14>의 예제에서 "송 원석"이라는 이름의 사용자는 "wonsuk"이라는 로그온 이름을 통해서 도메인에 로그온을 하지만, 관리자는 "송 원석"이라는 이름으로서 관리업무를 수행하게 된다.

Active Directory를 단적으로 표현한다면 'Windows Server 2003 이상의 서버에서 제공하는 디렉터리 데이터베이스'^[1]라고 할 수 있다. Active Directory를 하나의 메이커 형태로 생각하면 이해가 쉽다. 이를 테면 'Active Directory는 마이크로소프트가 Windows Server에서 제공하는 디렉터리'라고 정의를 하자.

그렇다면 디렉터리라는 것이 마이크로소프트만 제공하는 것도 아니고 SUN, IBM, Novell등 다양한 벤더가 모두 지원하고 있는데 왜 유독 Active Directory가 많은 관리자들에게 회자되고 있는 것일까? AD는 무엇인가에 대한 원론적인 개념은 단순하지만 AD를 가지고 무엇을 할 수 있는가? 여러분들은 AD를 가지고 무엇을 할 것인가? 라는 측면은 상당히 고민스러운 부분이다.

왜 Active Directory를 사용해야 할까?

네트워킹에서 디렉터리라고 하는 것은 필수적인 요소이다. 서버가 자신의 자원에 접근을 원하는 사용자들에게 권한을 부여하고자 한다면 서버는 디렉터리를 필요로 한다. 사용자가 네트워크상의 자원에 접근을 하고자 한다면 역시 디렉터리를 필요로 한다. 디렉터리는 “정보저장소”의 역할을 제공한다.

Active Directory는 디렉터리로서 어떤 정보를 저장하고 있을까? Active Directory는 사용자, 그룹, 컴퓨터, 공유폴더, 프린터, 연락처, 조직구성단위(OU) 등의 다양한 정보를 Object(개체)로 저장할 수 있다. 컴퓨터, 공유폴더, 프린터 등까지 디렉터리에 포함하고 있음을 주목하자. 이것은 관리자에게 상당한 편의성을 제공하는 기반이 된다.

Active Directory에 자원을 가진 서버나 자원에 접근하기를 원하는 사용자가 네트워크에서 이들 자원을 찾고자 한다면 사용자들은 Active Directory를 검색함으로써 원하는 자원의 위치정보를 얻어낼 수 있다.

‘그렇구나. 유용한 디렉터리인 것 같긴 하구나.’ 하지만 이 정도 가지고는 특별히 다른 디렉터리와의 차별화된 장점을 제공한다고 보기는 어렵다.

관리편의성과 확장성 2가지 측면에서 AD의 장점을 살펴보자.

Active Directory가 주는 장점 중 가장 큰 부분이라고 할 수 있는 것이 관리편의성 측면이다. <그림13-1>에서 Active Directory에 저장되는 정보중에는 사용자, 컴퓨터가 포함되어 있음을 확인했다. 여기서 컴퓨터라 함은 우리가 사용하는 데스크톱PC뿐이 아니라 서버들도 포함된다. 이것은 무엇을 의미할까?

Active Directory는 마이크로소프트에서 제공하는 디렉터리 서비스이고, 우리가 업무를 위해 사용하는 PC의 대다수 운영체제는 역시 마이크로소프트의 Windows운영체제이다. 필자는 Active Directory가 많은 기업의 핵심 인프라로 자리할 수 있는 배경의 가장 큰 힘이라면 Active Directory가 컴퓨터 정보를 포함함으로써 사용자 및 컴퓨터에 대한 효율적인 관리를 제공할 수 있는 기반을 제공하고, 그 기반위에서 적절하게 사용할 수 있는 수많은 정책들을 함께 제공함으로써 최상의 관리방안을 제시하고 있기 때문이라고 말하고 싶다.

그 관리방안의 핵심은 Active Directory가 제공해 주는 기능중의 꽃이라고 할 수 있는 ‘그룹정책(Group policy)’에 있다. 그룹정책은 참으로 많은 능력을 가지고 있다. 도메인환경에서 다수의 컴퓨터, 다수의 사용자들에 대한 상당부분의 관리 및 지원기능을 그룹정책 하나를 가지고 자동화시킬 수 있어서 이러한 그룹 정책을 잘 사용하는 것은 관리자의 업무부담을 상당부분 줄여줄 수 있다. 그룹정책을 이용해서 할 수 있는 일을 간단히 정리하였다.

-          사용자의 데스크탑 환경 설정

-          사용자의 데스크탑 제어 (Lock down)

-          레지스트리 수정

-          스크립트 자동 실행 (로그온, 로그오프, 시작, 종료)

-          보안설정

-          소프트웨어 관리 (설치, 업그레이드, 제한, 재설치, 복구, 삭제)

그룹정책을 적용할 수 있는 Active Directory 구조단위는 사이트, 도메인, OU이며, OU(조직단위)는 그룹정책을 적용할 수 있는 최소단위이다. 마이크로소프트는 Windows Server 2003의 Active Directory에서 무려 1,300가지 이상의 그룹정책설정 항목을 제공함으로써 관리자의 편의를 돕고 있다. 스크립트 자동실행 기능이 제공되기 때문에 기본정책만으로 부족하다면 개발자의 프로그래밍 능력에 따라 얼마든지 커스터마이징된 그룹정책을 배포할 수도 있다.

또한 그룹정책은 기본적으로 상속성을 가지고 있다. 도메인의 그룹정책은 OU에 속한 모든 사용자 및 컴퓨터에 적용되고, 상위OU에 설정된 그룹정책은 하위OU에 상속된다. 이를 통해 관리자는 전사적인 레벨의 보안설정 등의 관리항목은 도메인에 그룹정책으로 설정하고, 부서별, 위치별, 업무성격별로 OU에 설정함으로써 차별적인 정책기반의 사용자 및 컴퓨터 관리가 가능하다.

사용자 및 컴퓨터를 정책으로 관리하기 위해서는 이미 기본인프라는 갖춰져 있다는 것을 가정한다. 기본인프라라고 하면 AD가 구성되고 디렉터리에는 사용자가 생성되어야 하며, 컴퓨터는 AD도메인에 참여함으로써 디렉터리에 개체로서 포함되어 있는 것을 의미한다.

이번에는 Active Directory의 확장성 측면을 살펴보자. 먼저 Active Directory가 지원하는 프로토콜에 대해 살펴보면 Active Directory는 대부분의 산업표준 프로토콜을 채택했다. 이것은 큰 의미가 있다. 산업 표준 프로토콜을 채택했다는 것은 마이크로소프트의 솔루션이 아닌 다른 벤더의 OS 및 제품들과의 호환성 측면이 한층 강화되었다는 것을 의미하기 때문이다.

디렉터리라고 하는 것은 마이크로소프트뿐만이 아니라 모든 벤더가 고려해야할 부분이 될 것이므로 한 기업이 전체 기업환경에서의 '글로벌 디렉터리(Global Directory)'를 필요로 한다면 여러 가지 시스템이 섞여 있는 이기종(異機種)에서도 Active Directory는 만족할만한 성능을 발휘해 줄 것이다. 또 다른 측면으로는 기업내에서 개발되는 인트라넷 어플리케이션의 경우 역시 디렉터리를 필요로 하는데, Active Directory는 표준 프로토콜을 채택함으로써 이러한 경우에도 예전에 비해 보다 용이하게 기업이 Active Directory를 선택하도록 유도할 것이다.

Active Directory로 구현할 수 있는 그리고 현재 기업들이 구현하고 있는 확장성을 그림으로 표현해 보았다.

<그림13-2>에 언급된 하나하나의 요소들을 살펴보면 우리가 기업네트워크에서 필요로 하는 대부분의 업무 및 시스템들이 Active Directory와의 연관성을 가진 것을 알 수 있을 것이다. 바꿔 말하면 Active Directory는 이러한 업무들과 연계하는 기업의 통합디렉터리 서비스를 제공함으로써 핵심 인프라가 될 수 있으며 관리자는 통합 디렉터리의 장점을 최대한 활용할 수 있을 것이다.

 이처럼 Active Directory는 단지 Windows 서버 및 PC 만을 관리하기 위한 것은 아니다. 기업의 IT인프라의 핵심 디렉터리 역할을 충분히 제공할 만한 무한한 확장성을 가지고 있다. Active Directory가 인프라로서 다방면에 걸쳐 연관성을 가지고 있기 때문에 도대체 AD가 무엇인가? AD를 가지고 무엇을 할 수 있을 것인가? 에 대한 해답을 찾는 것이 오히려 어려운 일이 되었다는 생각도 든다.

현재 AD를 사용하고 있다면 이것을 어떻게 더 확장해 볼 것인가에 대해 고민을 해야 할 것이고, AD를 사용하고 있지 않다면 먼저 기본인프라를 구축하는 것이 다른 어떠한 솔루션을 도입하는 것보다는 선행되어야 할 첫번째 과제이다.

이를 테면 그룹웨어가 도입 또는 재구축되는 시점이라면 당장은 AD가 관리적인 측면에서 도입되지 않더라도 그룹웨어용 디렉터리를 선정함에 있어 Active Directory를 물망에 올려야 할 것이라는 것은 관리자의 당연한 선택이다.

시스템 관리자 K씨는 요즘 Active Directory에 대해 다음의 고민을 하고 있다.

K씨는 AD에 대해서 전혀 모르지는 않지만 고민스럽기만 하다. AD에 대해서 자료를 찾아보았지만 막연함을 커지고 확신이 서질 않는다. 그러다 보니 K씨는 당면한 문제를 해결하기 손쉬운 해결을 하려고 한다. 00사의 00만 깔면 보안관리가 된다더라. △△사의 △△를 구매하면 윈도우 패치관리가 된다더라… 이렇듯 몇 가지 솔루션을 도입하여 당장 문제점을 해결한 듯 하지만 솔루션 도입후 채 1년이 지나지 않아 많은 돈을 들여서 도입한 솔루션이 그다지 제기능을 해 주지 못함을 알게 되는 경우가 많다. 그러는 와중에 또 다른 이슈를 해결하기 위해 검토하는 과정에서 AD 는 또 다시 언급이 될 것이다. 이제 K씨는 또 다시 같은 고민을 해야 한다.

지금 K씨에게는 단일문제점을 그때 그때 해결해 줄 포인트 솔루션과는 차별적으로 ‘인프라’측면의 인식이 필요한 것이며, 이를 위해서 AD에 대해 보다 명확한 이해가 필요한 상황이다.

이것은 비단 K씨의 경우만이 아니다.  “AD가 뭔가요? 우리 회사에 AD를 도입하면 어떤 효과를 가져다 줄까요? “ 요즘 필자가 고객들을 만나면서 가장 많이 듣는 질문중 하나이다. 간단한 듯 하지만 참 답을 내리기는 쉽지 않아서 늘 고민인 질문이기도 하다.

사실 이러한 질문을 하는 회사의 실무자들은 상당수가 AD에 대해서 비교적 이해를 잘 하고 있는 경우가 많다. 이 질문에 대한 배경에는 AD를 도입하기 위해서는 우선 담당자가 AD를 도입했을 때 과연 효과적일 것인지에 대한 확신이 있어야 하고, AD구축을 추진하기 위해서는 의사결정권자의 결재를 얻어야 할 것인데 그럴 수 있을만큼 AD를 잘 이해하기는 쉽지 않기 때문인 것으로 보인다.

1. 관리자 계정과 암호는 안전한가?

또한 작업을 마친후에 Administrator라는 일반 사용자 권한을 가진 계정을 하나 만들고 아주 어려운 패스워드를 할당해 두라. 패스워드를 기억할 필요도 없다. 당신이 사용할 계정이 아니다. 이 계정은 실제로 사용되기 위한 계정이 아니라 “감사(Audit)”를 통해서 모니터링 할 대상이다. 감사를 통해서 누군가가 이 계정을 공격하는 것을 발견했다면 당신은 해킹의 흔적이 있었음을 알 수 있을 것이다. 

2. 서비스팩, 핫픽스 패치에 인색하지 않는다.

3. 서버용 백신 프로그램을 설치한다.

바이러스는 데스크탑의 전용이 아니다 서버에게도 바이러스는 잘 동작한다. 그것도 아주 잘. 보통 흔히 구할 수 있는 백신프로그램들은 서버에서 동작하지 않는 경우가 많다. 서버용 백신 프로그램을 구입해야 할 것이다. 백신 프로그램의 특성상 지속적인 업데이트가 이루어지지 않으면 무용지물인 경우가 많으므로 신중하게 선택해야 한다. 트렌드마이크로, 안철수연구소, 하우리 등의 회사들이 개발한 백신 소프트웨어가 많이 사용된다.

4. 익명액세스 허용하지 말 것

당신의 서버에 대해서 다른 컴퓨터를 통해서 아래의 테스트를 해 보자. 아래의 내용은 명령프롬프트를 통해서 192.168.10.1 IPAddress를 사용하는 서버에 접근해 본 것이다.

서버에서 익명액세스를 허용하지 않기 위해서는 레지스트리를 편집함으로써 가능해진다. 레지스트리 편집기(regedt32.exe)를 열고 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 키로 접근한다. 오른쪽 패널에서 Restricanonymous 값을 찾은다음 “0”으로 되어 있는 데이터를 “2”로 변경한다. (Windows NT 4.0 = 1, Windows 2000, 2003 = 2 를 사용)

5. 반드시 NTFS 파일시스템을 사용하자.

Windows NT기반의 시스템에서는 FAT와 NTFS파일시스템을 지원한다. FAT파일시스템에 비해서 NTFS파일시스템은 여러가지 장점을 제공한다. 또한 NTFS파일시스템의 퍼미션은 로컬에서 사용하는 파일서버 등에서만 적용되는 것이 아니다. 사용자가 HTTP나 FTP를 이용해서 웹을 통한 접근을 하더라도 IIS서버는 가장 마지막에 서버의 파일에 접근하는 사용자가 NTFS퍼미션이 있는지를 체크하기 때문에 보다 안전한 서버를 운영할 수 있도록 해 준다. 특정폴더의 모든 파일은 공개되지만 특별한 파일 몇 개는 접근을 거부시키는 방법은 바로 NTFS 퍼미션을 통해서 가능하다는 것을 상기하라.

6. 서버에 불필요한 소프트웨어는 설치하지 않는다.

서버는 서버용도로 사용해야 할 것이다. 서버에서 관리자가 일부 작업을 한다고 해서 관리자가 개인적으로 필요한 소프트웨어를 사용한다든가 하는 등의 일은 서버를 아프게 해서 빨리 죽게 하는데는 좋은(?) 방법이다.

 

7. DNS서버의 보안을 고려하자.

DNS서비스를 등한시 하는 경우가 있다. DNS서버가 문제가 발생하면 웹서비스, 메일서비스 등 전반적인 서비스가 동작하는데 문제가 생긴다. DNS에서 고려해야 할 보안을 제대로 챙기는 것도 전반적인 서버의 건강과 직결되는 문제이다.

 

-DNS 영역전송 보안 : 기본적으로 Windows 2000 DNS서버는 아무 서버에게나 영역전송이 허용되도록 되어 있다. 이것은 DNS가 가진 전체 레코드를 한꺼번에 외부로 유출시키는 결과를 초래할 수 있다. DNS영역전송을 보조DNS서버로만 제한하는 것이 필요하다. Windows Server 2003 DNS의 기본설정은 ‘영역전송 허용안함’이다. 좋은 설정이다.

 

-DNS 동적 업데이트 허용 않음 : DNS 동적업데이트는 관리상 유용한 기능인 것은 분명하지만 외부에 공개된 DNS서버가 동적업데이트를 허용하도록 구성되어 있으면 물리적인 방법에 의해 외부의 제3자가 의도하는 레코드로 업데이트가 일어날 수 있다. 회사의 www 호스트레코드가 엉뚱하게도 음란사이트가 운영되는 서버의 IP로 바뀌었다고 생각해 보라. 어처구니 없는 노릇이지만 얼마든지 일어날 수 있는 일이다. 외부DNS서버는 동적 업데이트를 허용하지 말아야 할 것이다.

 

-내, 외부 DNS영역설정 : DNS서버에 있어서는 최상위의 보안을 제공할 수 있는 방법이다. 외부에서 접근해야 하는 리소스들의 레코드를 가진 외부DNS와 내부의 사용자들만이 접근하는 리소스들의 레코드를 가진 내부DNS서버를 분리시킴으로써 보다 안전하게 DNS서버를 운영하는 방법이 될 수 있다.

 

8. 반드시 필요한 서비스만 오픈시킨다.

 

이것은 중요한 의미를 가진다. 웹서버를 구동중이라면 웹서비스를 정상적으로 운영하는데 필요하지 않은 그밖의 서비스들은 돌고 있지 않아야 한다. 웹서버를 철통같이 방어했다고 하더라고 해커가 다른 서비스에서 발견된 버그를 통해서 접근한다면 결국 서버는 안전하지 못하기 때문이다.

<참고> 일반적으로 시작되어 있는 서비스들중 꼭 필요하지는 않은 서비스들 Aleter Service Computer Browser Service DHCP Client DHCP Server Distributed File System FTP Publishing Service Messenger Indexing Service Remote Registry Service Routing and Remote Access Service Server Service Simple TCP/IP Service SMTP Service SNMP Service Task Scheduler Service Telnet Service Terminal Service Windows Media Services   * 서비스별 역할 및 사용하지 않을 때의 영향 참고 자료 http://www.microsoft.com/korea/technet/prodtechnol/windows2000serv/deploy/prodspecs/win2ksvc.asp )

 

9. IIS와 SQL서버는 분리시킨다.

 

많은 관리자들이 IIS에 대한 보안을 상당히 신경쓰면서도 그밖의 서비스에 대해서는 무관심한 경우가 있다. IIS에서 ASP를 사용하고 SQL서버가 하나의 서버에서 동작하고 있다면 IIS가 아닌 SQL서버에 대한 공격이 시도될 수 있다. 데이터베이스가 공격을 받게 되었을 때 그 영향은 상당히 치명적이다. IIS와 SQL서버를 분리시키고 SQL서버는 개인네트워크로 구성하면 그만큼 SQL서버에 대한 직접적인 공격에 대한 위험요소가 감소한다.

 

10. 웹서비스 폴더에서 불필요한 파일들을 제거한다.

 

- IISLockDown을 통하여 IIS의 반드시 필요하지 않은 서비스나 가상디렉터리를 삭제한다.

- 웹서비스 폴더내에 불필요한 파일을 삭제한다.(예, *.bak 등) 웹저작도구로써 많이 사용하는 몇몇 프로그램들은 html 파일을 생성하면 자동적으로 *.bak 라는 백업파일을 만들게 되는데, 이것을 그대로 방치하면 IIS서버에서 SQL서버의 ODBC연결에 사용되는 SQL로그인ID와 암호 등의 정보를 너무나 쉽게 알려주는 결과를 초래한다. IIS LockDown 툴은 IIS서버에서 사용하지 않는 서비스들과 폴더 등을 제거하여 보안에 도움을 줄 수 있는 도구이다.(관련자료 : http://www.microsoft.com/korea/technet/security/tools/locktool.asp ) 파일을 다운로드 받은 다음 테스트해 보자.

 

11. 계정 및 자원에 대한 감사정책을 구현하자.

소잃고 외양간 고치는 경우가 많은데 그중에 하나가 바로 감사정책이다. 시스템이 엉망이 된 후에 도대체 누가 언제 이런 일을 한 것인지 알고자 하지만 뒤늦은 후회일 뿐이다. 감사정책은 그러한 위험요소를 사전에 점검해 보고, 문제발생시 이벤트뷰어를 통한 보안로그를 통해서 로깅된 정보를 확인할 수 있다.

 

12. FTP서버 운영시 신중을 기하자.

- FTP를 사용하는 경우 쓰기권한을 제한하여 업로드를 하지 못하도록 설정한다.

- FTP를 사용하는 경우는 익명 계정 서비스만 권장한다. FTP 로그온 인증에 암호화가 이루어지지 않음을 고려해야 한다.

- FTP를 사용하는 경우 VPN 사용을 고려한다.

 

13. 주기적으로 점검하는 것을 잊지 않는다.

MBSA(Microsoft Baseline Security Analyzer)는 보안관련된 각종 구성정보들을 점검하고 대비할 수 방법을 제공하는 효율적인 도구이다. 시스템을 전체적으로 점검해 볼 수 있는 좋은 도구이니 활용할 수 있도록 한다.(참고: http://www.microsoft.com/korea/technet/security/tools/tools/mbsahome.asp)

<그림10-123. Microsoft Baseline Security Analyzer (MBSA) 도구>

서버에서 동작하고 있는 서비스를 모니터링 한다. 관리자가 의도하지 않은 서비스나 프로그램이 동작하고 있어서 서버에서 동작하는 프로세스가 있다면 바이러스나 백도어 해킹프로그램일 확률이 높다.

è  작업관리자, Fport ( http://www.foundstone.com http://www.securityfocus.com )

 

14. 무엇보다 가장 중요한 것은?

당신이 관리하는 서버에 대해 끊임없는 관심만이 상대적으로 안전한 서버를 운영할 수 있는 유일한 방법이라는 생각이 필요하다. 당신이 회사의 서버를 관리하는 동안 한차례도 해킹 등의 사고가 없었다면? 자랑할만한 기분 좋은 일이다.

10-8-1. FTP서비스

FTP(File Transfer Protocol)서비스는 대용량 파일전송을 위해 지원되는 서비스이다. 주로 사용자들은 웹호스트팅을 받는 서버에 자신의 홈페이지 데이터를 업로드 한다거나 자료실을 관리하는 용도로 사용하고 있다. 마이크로소프트의 IIS서버는 FTP서비스를 포함하고 있다. FTP서비스는 꼭 필요하지 않다면 보안상의 이유로 서비스를 제거하는 것이 바람직하다고 생각한다. IIS서버의 FTP서비스에 대한 기본구성을 살펴보도록 하자.

<그림10-105. FTP서버 등록정보1 >	인터넷 서비스 관리자 (ISM)를 열고 기본FTP사이트의 등록정보를 열었다. 몇가지 정보가 보인다. 인터페이스는 기본 웹사이트와 유사하므로 쉽게 접근할 수 있을 것이다. FTP서비스의 기본포트인 TCP포트21번이 설정되어 있다. FTP서버에서 이 TCP포트를 변경하였다면 FTP사용자는 바뀐 포트를 알아야만 FTP서버에 연결할 수 있다.
<그림10-106. FTP서버 등록정보 2 >	‘보안계정’탭을 열어보니 ‘익명연결허용’이 선택되어 있는 것이 보인다. 기본적으로 FTP서버에는 어느 누구나 접근하도록 설정되어 있다. 이것을 해제시키라는 것이 아니다. FTP사용을 할 때 보안을 필요로 하다면 ‘디렉터리 보안’ 탭을 이용하여 Access List 를 관리하는 것이 바람직하다.
<그림10-107. FTP서버 등록정보 3 >	‘메시지’탭에는 간단한 설정을 할 수 있도록 해 준다. 사용자가 로그인했을때의 메시지, 로그오프할때의 메시지, 허용된 연결을 초과했을때의 메시지 등을 설정한다.
<그림10-108. FTP서버 등록정보 4 >	‘홈 디렉터리’탭에서는 FTP서비스를 제공할 폴더를 지정할 수 있고, 해당 디렉터리에 대해서 어떤 권한이 할당되었는지를 보여준다. ‘쓰기’권한은 기본적으로 없다. FTP사용자가 파일 업로드를 할 수 있도록 하기 위해서는 ‘쓰기’를 허용해 주어야 한다. ‘쓰기’허용이 되어 있다고 무조건 FTP사용자가 파일 업로드를 할 수 있는 것은 아니다. FTP사용자는 최종적으로 NTFS파일시스템에 주어진 권한을 따르게 되기 때문에 NTFS파일시스템에 쓰기 권한이 없다면 파일 업로드는 불가능하다.   ‘쓰기’권한을 설정할때는 신중을 기해야 한다. NTFS허가, 디스크 할당량 관리 등을 통해서 피해를 최소화할 기본방안은 마련이 되어야 할 것이다.
<그림10-109. FTP서버 등록정보 5>	마지막으로 ‘디렉터리 보안’탭에서는 접근하는 클라이언트의 IP주소에 대해 접근제어를 관리할 수 있다.

FTP클라이언트로 접근하여 FTP서버에 접근해 보자. WS_FTP, CUTE_FTP등 사용자 인터페이스가 편리한 많은 FTP 클라이언트가 존재하지만, Windows2000에서 기본제공되는 클라이언트 유틸리티도 사용법을 익혀두는 것이 좋다. 어차피 모든 클라이언트 유틸리티는 결국 이러한 명령어 들을 보다 쉽게 구현하도록 만들어진 것이니 테스트 환경에서 편리하다.

10-8-2. FTP서버로 계정 서비스

IIS서비스에 포함된 FTP서버를 이용해서 회사의 직원들에게 각각 특정용량의 디스크 공간을 할당하고, FTP 클라이언트로서 접근해서 파일을 업로드할 수 있도록 하기를 원한다. 당연히 각각 자신의 데이터에만 접근할 수 있어야 하며 다른 사용자들은 접근할 수 없도록 해야 할 것이다. 많은 인터넷 서비스 회사들이 가입을 하면 사용자 계정별로 홈페이지 공간을 할당 받고, 자신의 홈페이지 관리를 위해서 FTP를 이용해서 파일을 업로드 하는 경우가 있다. 그러한 서비스를 별도의 써드파티툴을 이용하지 않고, IIS 의 기본기능으로 제공할 수 있다.

몇 가지 설정만 한다면 방법은 간단하다. 차근차근 접근해 보자.

일단 FTP사용자를 생성해 보자. 일반서버라면 '관리도구à컴퓨터관리'를 이용하고 도메인 컨트롤러라면 '관리도구àActive Directory 사용자 및 컴퓨터'를 이용하게 된다. 예제에서는 홍길동이라는 이름의 사용자를 'kdhong' 이라는 계정으로 생성하였다. 테스트 환경에서 사용자가 도메인컨트롤러에 구성된 FTP서버로 로그인을 하기 위해서는 서버측의 로컬정책을 수정해 주어야 한다. 이 내용에 대해서는 13장의 “대화형으로 로그온 할 수 없습니다.” 를 참고하라.
FTP 사용자들이 접근하게 될 폴더는 NTFS 파티션에 존재해야 한다. 만일 NTFS파티션이 없다면 새롭게 만들거나, 기존의 FAT 파티션을 NTFS 로 변경해야 한다. 명령프롬프트에서 convert 명령을 사용하여 변경할 수 있다. 테스트 환경에서 D: 는 NTFS 파티션으로 포맷이 되어 있다.
<그림10-110. FTP 계정서비스3>	FTP서버의 FTP루트 폴더는 기본적으로 C:\Inetpub\ftproot 폴더이다. Ftproot 의 NTFS퍼미션을 조정하여 Users 그룹을 제거시킨다. 이것은 사용자들이 자신의 FTP홈폴더로 접근한 다음 상위로 이동하여 FTP루트에 접근하는 것을 막아준다.   먼저 NTFS 파티션으로 포맷된 드라이브에 각 사용자별로 폴더를 생성하기 전에 FTP에서 사용자 홈폴더 저장소로 사용될 폴더를 하나 생성한다. 예제에서는 "ftpuser"라는 이름으로 폴더를 생성하였다.
<그림10-111. FTP 계정서비스4>	[확인]을 눌러서 설정을 마친다음 'ftpuser'아래에 FTP 사용자 계정과 같은 폴더이름을 생성한다. 홍길동의 사용자 계정이 'kdhong'이었으므로 폴더이름도 'kdhong'이 되어야 한다. 이것이 일치하지 않으면 사용자는 홈폴더를 사용할 수 없게 된다.
<그림10-112. FTP 계정서비스5>	위에서 생성한 사용자의 홈폴더인 kdhong의 등록정보를 열어서 모든 기본 사용권한을 제거하고, 홍길동(kdhong@windowsnetwork.msft)에게만 '모든 권한'이 주어질 수 있도록 사용권한 설정을 한다.
<그림10-113. FTP 계정서비스6>	폴더설정을 마쳤다. 이제는 IIS의 FTP 서비스 설정을 해야 한다. 관리도구-인터넷 서비스 관리자(ISM)을 실행하고, 기본 FTP사이트를 클릭한 다음 '새로 만들기à가상 디렉터리'를 선택한다.
<그림10-114. FTP 계정서비스7>	가상 디렉터리 별칭을 입력한다. 예제에서는 홍길동의 사용자 계정에 해당하는 kdhong을 입력했다.
<그림10-115. FTP 계정서비스8>	'FTP사이트 컨텐트 디렉터리'창에서 사용자를 위해 설정했던 물리적인 폴더가 있는 경로를 [찾아보기]를 이용하여 지정해 준다.
<그림10-116. FTP 계정서비스9>	가상 디렉터리에 대한 기본 권한은 '읽기(R)'로 되어 있다. 사용자가 파일을 업로드 할 수 있도록 '쓰기(W)'옵션을 체크해 준다. NTFS 퍼미션이 '모든 권한'으로 되어 있더라도 가상 디렉터리에 대한 액세스 권한이 '읽기(R) '만 지정되어 있으면 사용자가 FTP로써 서버에 접속하면 읽기 권한만 가지게 된다.
<그림10-117. FTP 계정서비스10>	구성이 완료되었다. [마침]을 눌러서 마법사를 마친다.
<그림10-118. FTP 계정서비스11>	마법사를 완료하면 기본 FTP 사이트 아래에 kdhong 의 가상 디렉터리가 생성된 것을 확인할 수 있다. FTP 사이트는 기본적으로 '익명 연결 (Anonymous Access)'을 허용하고 있다. 사용자별로 계정관리를 하려고 하기 때문에 익명연결을 허용하지 않도록 구성해야 한다. 기본 사이트의 등록정보로 접근하여 '보안계정'탭을 누른후 '익명 연결 허용'옵션의 체크박스를 해제한다.
<그림10-119. FTP 계정서비스12>	암호화를 하지 않는다는 메시지를 보여준다. 아쉽지만 그렇다. 네트워크 채널 보안을 위해서는 IPSec, VPN 등의 구현을 검토해야 한다. 계속해서 [예]를 선택한다.

이제 테스트를 해 보자. 이번에는 인터넷 익스플로어를 통해서 FTP 서버로 연결해 보자. 간단하게 웹 브라우저를 가지고 접근해 보자. 인터넷 익스플로러를 실행하고 ftp://ftp.windowsnetwork.msft 로 접근을 시도했다. 익명 연결이 허용되지 않으므로 사용자 인증을 위한 창이 뜬다. kdhong 으로서 로그인을 시도해 보았다.