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"이라는 로그온 이름을 통해서 도메인에 로그온을 하지만, 관리자는 "송 원석"이라는 이름으로서 관리업무를 수행하게 된다.

마이크로소프트의 Windows 뿐만이 아니라 다른 벤더의 OS도 마찬가지고, 회사 내부의 인트라넷 어플리케이션, 우리가 사용하는 E-mail서버 등, 수많은 어플리케이션이 디렉터리를 요구한다. 이러한 디렉터리를 보다 효율적으로 사용하기 위한 노력이 존재하고 마이크로소프트 역시 효율적인 디렉터리 관리를 위해서 상당한 노력을 기울이고 있다. 디렉터리가 어떻게 관리되는지에 따라서 네트워크 관리모델을 결정할 수가 있게 된다. 마이크로소프트는 관리모델로써 Workgroup과 Domain이라고 하는 두가지 모델을 제공한다.

두 모델의 가장 큰 차이점이라면 디렉터리 데이터베이스의 위치라고 할 수 있다. 먼저 첫번째 그림을 보자. 네트워크에 Windows 2000 server, professional, NT4.0 Server, Workstation 의 서로 다른 4개의 컴퓨터가 있고, 각각의 시스템이 고유한 디렉터리 데이터 베이스를 유지하고 있는 모델이다. 

이러한 형태로 네트워크를 운영할 때 어떤 일이 발생할 것인지를 생각해 보자.

‘홍길동’이라는 사용자가 특정 서버의 공유자원에 접속을 원한다면 해당 서버의 디렉터리 데이터베이스에 사용자 계정이 존재해야 한다. 만일 홍길동이 4대의 서버에 각각 접속을 원한다면 홍길동은 4대의 서버마다 자신의 사용자 계정을 가지고 있어야 하고 또한 그 계정과 각각의 암호를 기억하고 있어야 전체 서버의 자원을 이용할 수 있게 될 것이다.

서버 입장에서는 어떤가? 만일 홍길동이 자신의 공유자원에 접속하기를 원한다면 서버의 관리자는 홍길동을 위해 공유자원에 대한 접근허가를 주기 위해서 자신의 디렉터리 데이터베이스 안에 홍길동이 사용할 계정을 생성해 주어야 한다. 서버가 추가된다면 역시 홍길동의 계정은 추가된 서버의 디렉터리 데이터베이스에 새롭게 생성이 되어야만 한다.

결과적으로는 하나의 사용자가 서버들의 자원에 접근하도록 하기 위해서 각 서버에는 사용자 계정이 생성되어야 하는 번거로움을 감수해야 할 것이다. 이들 4대의 서버를 관리하는 관리자도 마찬가지이다. 관리자 역시 각각의 서버를 관리하기 위해서는 각 서버에서 관리권한을 가진 사용자 계정과 암호를 알고 있어야만 관리가 가능해 지는 것이다. Workgroup을 사용하는데 있어서 불편한 점을 정리해 보면 다음과 같다.

  ① 한 사용자가 자원을 가진 서버마다 별도의 사용자 계정을 가지고 있어야 한다.

  ② 하나의 사용자를 위해서 서버마다 계정을 만들어야 하는 번거로움

  ③ 중앙집중적인 관리의 어려움

서버의 수도 많아지고 사용자의 숫자도 증가하여 네트워크에서 관리해야 할 자원들이 늘어간다면 워크그룹 모델은 분명히 한계가 있다. 제대로 관리를 한다는 것은 너무나 많은 노력을 필요로 하는 일이다.

이것을 해결할 방법은 없는가? 마이크로소프트는 도메인이라는 모델을 제시하고 있다. 생각을 조금만 바꾸면 된다. 회사에 있는 모든 서버들이 자신의 디렉터리 데이터베이스에 사용자 계정을 각각 관리할 것이 아니라, 하나의 마스터 디렉터리 데이터베이스를 두고 모든 서버들은 그 디렉터리 데이터베이스에 접근하여 사용자 계정을 공유한다면 될 것이 아닌가?

이것을 가능하도록 하기 위하여 마이크로소프트는 네트워크 환경에서 특별한 서버를 지정하여 마스터 디렉터리 데이터베이스를 관리하도록 하였고, 이 서버를 도메인 컨트롤러 (Domain Controller, DC)라고 부른다. 그리고 이 도메인 컨트롤러의 마스터 디렉터리를 사용할 수 있는 서버나 클라이언트들을 묶어서 '도메인(Domain)'이라는 논리적인 관리단위를 만들었다. 정리하자면 워크그룹이 가졌던 단점을 해결하고자 한다면 도메인이라는 그룹을 만들고 모든 서버들을 이 도메인의 멤버로 만들고, 클라이언트 역시 도메인으로 로그온하도록 구성을 하면 되는 것이다. 그렇게 하면 도메인의 모든 멤버들은 디렉터리 서비스에 적용을 받고 각각의 계정이 아니라 도메인의 마스터 디렉터리 계정으로서 자원관리를 할 수가 있게 된다.

아래의 그림에서는 디렉터리 데이터베이스가 DC에 집중되어 있는 것을 볼 수 있다.

도메인 환경에서는 앞에서 홍길동의 계정이 서버마다 생성될 필요가 없다. 도메인 컨트롤러의 마스터 디렉터리 데이터베이스에서 한번만 생성이 되면 그뿐이다. 다른 모든 멤버서버들은 도메인 컨트롤러에 접근하여 마스터 디렉터리 데이터베이스에 저장된 홍길동에게 직접 자원에 대한 접근허가를 줄 수 있다.

사용자 입장에서도 자원에 접근하기가 수월해졌다. 자원을 가진 모든 서버마다 별도의 사용자계정과 암호를 기억할 필요가 없이 도메인 컨트롤러의 마스터 디렉터리 데이터베이스에 저장된 사용자 계정과 암호만 기억한다면 그 정보를 이용해서 모든 서버에 접근을 할 수 있다.

도메인 환경에서 새로운 서버가 추가되고 그 서버의 자원에 모든 사용자들이 접근할 수 있게 하려면? 간단해 진다. 새로운 서버를 도메인의 멤버서버로 설정하기만 하면 된다. 그러면 그 서버는 기존에 이미 존재하는 도메인의 디렉터리 데이터베이스에 접근하여 사용자 정보를 사용하는 것이 가능해 지기 때문이다.

관리적인 측면으로 본다면 워크그룹모델은 컴퓨터와 컴퓨터 즉, 자원과 자원간에 아무런 연관성이 없는 개별적인 관리모델이고, 도메인 모델은 도메인에 참여하여 도메인을 구성하고 있는 서버 및 PC들이 도메인이라는 범위내에서 관리정책, 보안정책 등을 서로간에 공유할 수 있는 모델을 말한다.

도메인 모델의 장점을 굳이 언급할 필요는 없다. 워크그룹 모델을 사용하는데 불편했던 점들을 고려한다면 그것들 중의 대부분은 도메인 모델을 채택함으로써 해결될 수 있는 단점이 될 것이다.

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를 잘 이해하기는 쉽지 않기 때문인 것으로 보인다.