13-2. Active Directory의 구조 및 이름 Windows Networking2008. 11. 22. 08:42
이번 장에서는 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의 일관성을 유지해 주는 단위가 된다. 회사가 한국, 미국, 일본 등 다국적 기업환경에 있다고 하더라도 하나의 도메인으로 구성하는 것이 가능하다. 도메인은 철저하게 논리적인 관점의 단위이다.
한 회사에서 네트워크 환경을 도메인으로 구성하여 전체 리소스에 대한 집중화된 관리가 가능하다. 도메인의 관리자는 도메인 내에서 모든 리소스에 대해서 완전한 통제권한을 가지고 있다. 조직이 관리자 혼자서 관리하기에 벅찰 정도로 규모가 크다거나, 혹은 지역적으로 멀리 떨어진 환경의 회사여서 상황에 대처하는데 효율성이 떨어진다거나, 관리업무 자체를 보다 세분화시켜서 여러 관리자가 전문화된 관리영역 등을 가지게 하고자 한다면 OU라는 논리적 구조를 이용할 수 있다.
OU는 Active Directory에 존재하는 사용자계정, 컴퓨터계정, 프린터, 폴더 등의 리소스등을 논리적으로 그룹화하여 관리하게 하기 위한 Active Directory의 또 하나의 구성요소이다. 예를 들면 관리자는 서울, 부산, 대전으로 나뉘어진 회사의 조직구조를 그대로 반영하여 서울OU, 부산OU, 대전OU 라는 형식으로 리소스를 조직화할 수 있다. 또한 부서를 반영하여 영업부OU, 관리부OU, 개발팀OU등의 OU를 이용할 수도 있다. 이것은 도메인이라는 커다란 단위를 사용함과 동시에 내부적으로 보다 작은 단위로써 유연한 관리방법을 제공하는 것이다.
실제로 OU를 사용하는 큰 이유중의 하나는 부서별, 지역별, 사용자유형별로 차별적인 그룹정책을 구현하기 위한 목적때문이다. AD의 그룹정책을 적용하기 위한 최소 단위가 OU이기 때문에 사용자 및 컴퓨터를 OU로 조직하면 원하는 차별화된 그룹정책을 구현할 수 있다. 물론 이렇게 OU로 구분한 경우에도 OU가 속한 도메인 전체적인 정책은 유지된다.
도메인의 Active Directory에 저장되는 하나하나의 구성요소를 object라고 부른다. 잘 알고 있는 사용자 계정, 컴퓨터 계정 등이 그것이다. NT4.0의 디렉터리 데이터베이스에 비해서 Active Directory에는 사용자, 그룹, 컴퓨터 외에도 연락처, 공유폴더, 프린터 등의 다양한 자원들까지도 Object로서 포함될 수가 있다. 이것은 큰 의미가 있다. 도메인이 구축된 기업환경에서 생각할 수 있는 많은 요소가 Active Directory에 저장됨으로써 사용자들을 Active Directory를 통해서 다양한 검색기능을 이용해서 자원에 훨씬 쉽게 접근할 수 있는 환경이 제공된다.
필요에 의해서 하나의 도메인만 가지고는 회사의 요구에 만족하지 못할 경우가 있다. 이런 경우 두 개 이상의 도메인을 사용하게 될 수도 있는데 아무래도 하나의 도메인만 사용할 때에 비해서는 고려해야 할 것이 많다. 도메인이 보안의 경계영역이라고 했으니 두 개의 도메인이면 서로 다른 보안의 영역이 생기는 것이 된다. 하지만 회사에서는 도메인과 도메인간의 자원들을 공유해야 할 필요성이 생기게 되고 이러한 것을 완전히 만족시켜야만 제대로 된 도메인 환경을 만들 수가 있게 되는 것이다. 가장 추천하는 도메인 모델은 "단일도메인(Single Domain)"이다. 하지만 단일 도메인 모델로서 회사의 환경과 요구를 충족시킬 수 없다면 당연히 복수 도메인 모델(Multi Domain Model)을 사용할 수밖에 없다. 처음 하나의 도메인이 있는 상태에서 새로운 도메인을 추가할 때 어떻게 추가하느냐에 따라서 트리와 포리스트라는 2가지 구조를 사용할 수 있다.
<그림13-6. Active Directory의 구조 – 트리 & 포리스트>
한 회사에서 서울에 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)"이 맺어지게 된다.
|
도메인의 Active Directory는 도메인 내에서 사용된다. 회사가 여러개의 도메인으로 구성되어 있는 환경을 고려해 보면 사용자가 Active Directory에서 특정한 Object를 찾고자 할 때 그러한 쿼리를 처리해 주는 것이 문제가 될 수 있다. A라는 도메인에 소속된 사용자가 "원석"이라는 이름을 이용해서 Active Directory에 쿼리를 던져서 wssong이라는 Object를 찾고자 할 때, 그러한 정보를 가지고 있는 A도메인의 도메인 컨트롤러는 "원석"이라는 이름을 검색해야 할 것이다. 만일 없다면 그 다음에 요청은 "B"도메인으로 가야 할 것이고 없다면 다시 "C"도메인으로 가야만 한다. 그렇게 해야만 사용자는 전체 도메인 환경에서 원하는 정보를 검색하는 것이 가능하다. 이러한 일들을 처리하기 위해 Active Directory는 포리스트 레벨의 도메인의 모든 Active Directory에 대한 Object들의 부분 복제본(전체 디렉터리 복제본이 아님)을 하나의 서버에 집중시켜 둔 별도의 저장소를 가지게 되었다. 그것을 가리켜서 "글로벌 카탈로그(Global Catalog)"라고 부른다.
<그림13-9. Active Directory 검색>
<그림13-9>를 보면 사용자는 "
<그림13-10. Active Directory 사이트 및 서비스 관리콘솔>
관리도구의 "Active Directory사이트 및 서비스"를 통해서 글로벌 카탈로그 서버를 확인하는 것이 가능하다. 관리도구를 실행한 다음, “SitesàDefault First Site NameàServersà서버이름àNTDS Settings”의 속성을 연다<그림13-10>
<그림13-11. 글로벌 카탈로그 확인>
등록정보를 열어보면 "글로벌 카탈로그"가 체크되어 있음을 확인할 수 있다. 추가로 글로벌 카탈로그 서버를 지정할 때도 같은 방법을 사용해서 접근한다.
앞에서 설명한 구조는 논리적인 관점의 Active Directory구조였다. 이것만으로는 부족하다. 실제 환경에서는 훨씬 더 다양한 요구가 있기 마련이기 때문이다. 한가지 상황을 가정해 보자. A회사는 서울에 본사를 두고 대전과 부산에 각각 지사를 두고 있다. 이 회사는 secure.pe.kr이라는 하나의 도메인을 구축했고 서울, 대전, 부산에 각각 5대, 3대, 3대씩 총 11개의 도메인 컨트롤러가 설치되어 있다. 서울과 대전, 부산간에는 WAN으로 연결이 되어 있고 모든 클라이언트는 Windows2000 Professional을 사용하고 있다. 관리자는 도메인 컨트롤러간의 복제, 사용자들의 도메인 로그온, Active Directory의 검색요청에 대한 빠른 응답시간 등 회사 전체의 네트워크 환경을 최적화하고자 한다. 각각의 지역간에 상대적으로 느린 WAN환경에서 어떤 방법을 고려해야 할까? 이때 다음의 ‘사이트’라는 물리적인 구조가 필요해진다.
도메인이라는 논리적인 단위로는 해결할 수 없는 부분이 바로 이러한 것이다. 마이크로소프트는 Active Directory에 사이트(Sites)라는 물리적인 단위를 제공함으로써 해결해 주고 있다. 결국 회사의 지리적인 측면을 반영하여 도메인과 사이트를 적절히 활용하여 논리적,물리적인 측면에서 최적화된 네트워크 환경을 제공하고 있는 것이다. 위와 같은 예제에서 우리는 회사 전체를 하나의 도메인으로 묶을 수 있고, 서울, 대전, 부산 등 각 지역을 각각의 사이트로 설정할 수 있다. 그렇게 설정을 하면 클라이언트들은 DNS통해서 자신의 사이트에 있는 도메인컨트롤러를 찾을 수 있게 되고, 사이트내에서와 사이트간에서의 도메인 컨트롤러간의 리플리케이션은 각각 다른 방법을 사용함으로써 최적화를 이뤄낼 수가 있게 된다.
사이트(Sites)는 잘 연결된 IP Subnet들의 집합이다. "잘 연결된"의 뜻은 "충분한 대역폭이 확보되는"이라는 뜻으로 해석하는 것이 좋겠다. 도대체 얼마큼 대역폭이 확보되어야 잘 연결되었다는 표현을 할 수 있을 것인가? 이것에 대한 정답은 없다. 회사마다 주관적인 설정이 가능할 것이기 때문이다. 56K모뎀으로 연결된 라인이더라도 쓰는데 불편함이 없다면 그 둘의 지역과 지역을 묶어서 하나의 사이트로 만들 수도 있는 것이다. 설사 T1으로 연결되어 있더라도 사용자가 많고 인터넷 액세스가 많아서 지역과 지역간에 제대로 연결이 되기 어렵다면 그들은 두 개의 사이트로 구분이 될 수도 있다. 어디까지나 관리자의 판단이 가장 중요한 요소가 될 수 있다.
<그림13-12. 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) CN=
(예2) CN=Kildong Hong,CN=Users,DC=secure,DC=pe,DC=kr à secure.pe.kr 도메인의 Users 기본 컨테이너에 저장된 "Kildong Hong"이라는 Displayname을 사용하는 Object.
<그림13-13. ADSI Editor를 통해서 확인한 CN>
ADSI Editor를 통해서 Active Directory를 들여다 보면 명확한 DN을 확인할 수 있다. ADSI Edit는 Windows Server원본CD에서 제공되는 Support tool을 설치하면 얻을 수 있다. "Windows Server 원본CD\SUPPORT\TOOLS\setup.exe"를 통해서 설치할 수 있다.
13-3-2
13-3-2
<그림13-14. Active Directory Object의 이름>
13-3-2
13-3-2
