• 아티클

Windows Administration

Active Directory 복제 가이드

Laura E. Hunter

 

한 눈에 보기:

  • Active Directory로 전환
  • 일관성 유지 관리
  • 충돌 해결 처리
  • Windows Server 2008의 변경 내용

Windows 2000 Server 및 Active Directory가 출시되기 전에는 많은 회사 환경에서 서버 인프라와 ID 및 액세스 관리를 위해 Windows NT를

사용했습니다. Windows NT® 4.0이 발표될 당시에는 NOS(네트워크 운영 체제) 분야에서 입지를 확보했지만 몇 가지 단점 때문에 대규모 엔터프라이즈에 배포하기에는 어려움이 있었습니다.

Windows NT에서는 단일 구조 네임스페이스를 사용하여 네트워크 리소스를 저장했습니다. 즉, 리소스를 더 작은 하위 집합으로 분리하거나 관리를 원하는 대로 세분화하여 구성할 좋은 방법이 없었습니다. 예를 들어 마케팅 부서의 리소스에 사용할 부서 컨테이너를 구성하거나 해당 부서 사용자의 암호만 재설정할 수 있는 권한이 있는 로컬 관리자를 구성할 수 없었습니다. 따라서 Windows NT 보안은 대개 '전체적으로 적용되거나 아니면 아예 적용되지 않는 방식(all-or-nothing)'이라 할 수 있습니다. 관리 작업을 데스크톱 지원 엔지니어에게 위임하려는 경우 필요한 것보다 훨씬 많은 사용 권한을 부여해야 하는 경우가 많았습니다.

또한 Windows NT에서는 모든 정보를 크기가 40MB로 제한된 SAM(Security Accounts Manager) 데이터베이스에 저장했습니다. SAM 데이터베이스가 이 권장 최대 크기를 초과하면(구성에 따라 다르지만 개체가 약 25,000-40,000개일 때 발생함) 환경을 여러 별도의 도메인으로 분리해야 하며 이 경우 네트워크를 관리하고 사용자에게 리소스 액세스를 제공하는 작업이 복잡해졌습니다. 각 NT 도메인에는 SAM 데이터베이스의 읽기/쓰기 사본만 포함하는 하나의 PDC(주 도메인 컨트롤러)가 있었으며 사용자가 내결함성을 위해 BDC(백업 도메인 컨트롤러)를 하나 이상 배포할 수 있었습니다. 하지만 이러한 BDC는 읽기 전용이며 사용자 암호 변경과 같이 쓰기 작업이 필요한 업데이트를 전혀 수행할 수 없었습니다.

마지막으로, Windows NT에서는 NetBIOS 이름 확인을 사용했는데, 이 방식은 브로드캐스트 기반 방식이며 사용자가 네트워크 리소스를 탐색하는 경우, 특히 느리거나 사용량이 많은 WAN 링크를 통해 탐색해야 하는 경우에는 매우 많은 트래픽이 생성되는 경우가 종종 있었습니다.

새로운 모델 소개

2000년 Microsoft에서는 이전 NOS 제품에서 완전히 새로워진 Windows® 2000을 출시했습니다. 새로운 NOS 서비스인 Active Directory®도 Windows NT와 달라졌습니다. Active Directory는 단일 구조 네임스페이스를 사용하는 대신 계층적 조직 구조를 작성하는 X.500 표준을 기반으로 합니다. 이제 리소스를 단일 도메인 내에서 여러 조직 구성 단위로 구성하고 작업 기반 수준에서 각 OU에 대한 관리를 위임할 수 있습니다.

또 다른 Windows NT와의 차이점은 새로운 다중 마스터 복제 모델입니다. Active Directory에서는 하나의 PDC만 쓸 수 있고 관련 BDC를 여러 개 두는 이전 기능이 사라지고, 각 도메인 컨트롤러에서 Active Directory 데이터베이스에 쓸 수 있게 되었습니다.

하지만 이로 인해 대규모 및 분산 환경을 지원하는 측면에서는 유연성이 대폭 향상되었지만 Active Directory의 무결성 유지 관리라는 새로운 과제가 대두되었습니다. John Smith와 Jane Dow가 한 나라의 각기 반대쪽 끝에 있는 사무실에서 동일한 개체를 변경할 때 해당 변경이 서로 충돌하면 어떻게 될까요? Active Directory 복제 모델에서는 환경 내 모든 도메인 컨트롤러를 통해 업데이트를 주고받는 방법과 실질적으로 어디에서나 변경이 가능한 이 다중 마스터를 사용하는 데 따라 발생하는 모든 충돌을 처리하는 방법을 정의합니다.

Active Directory 복제의 원리

이 예의 목적상 여기에서는 사이트 내 복제에 대해서만 설명하겠습니다. 기본적으로 사이트 내 복제는 변경 내용을 같은 사이트 내의 DC로 빠르게 복제하도록 설계되었으며 이는 변경 알림을 통해 수행됩니다. 사이트 내 복제에서 DC1은 복제가 필요한 변경이 있음을 DC2에게 알리고 DC2는 해당 변경 내용을 DC1에서 가져옵니다. 마찬가지로 DC2는 DC2에 변경이 있을 때 이를 DC1에 알리며 DC1은 해당 변경 내용을 DC2에서 가져옵니다. 여기서 볼 수 있듯이 모든 Active Directory 복제는 내보내기가 아닌 가져오기 방식으로 수행됩니다.

Active Directory는 수백, 수천 또는 수백만 개의 개체로 확장될 수 있으므로 Active Directory 데이터베이스를 명명 컨텍스트라고 하는 섹션으로 나누는 것이 필요합니다. 최소한 각 도메인 컨트롤러는 Active Directory 데이터베이스의 자체 로컬 사본에 세 개의 NC를 저장합니다.

스키마 NC 이 NC는 포리스트의 다른 모든 도메인 컨트롤러로 복제됩니다. 여기에는 Active Directory 스키마에 대한 정보가 포함되며, 이 스키마는 Active Directory 내의 여러 개체 클래스 및 특성을 정의합니다.

구성 NC 이 NC 또한 포리스트의 다른 모든 DC로 복제되며 여기에는 Active Directory의 물리적 레이아웃과 관련된 포리스트 전체 구성 정보뿐만 아니라 표시 지정자 및 포리스트 전체 Active Directory 할당량에 대한 정보가 포함됩니다.

도메인 NC 이 NC는 단일 Active Directory 도메인 내의 다른 모든 DC로 복제됩니다. 이 NC에는 가장 자주 액세스되는 Active Directory 데이터, 즉 실제 사용자, 그룹, 컴퓨터 및 특정 Active Directory 도메인 내에 있는 다른 개체가 포함됩니다.

복제 트래픽을 더욱 최적화하기 위해 각 명명 컨텍스트는 개별적으로 복제됩니다. 따라서 스키마 NC와 같이 자주 변경되지 않는 NC가 더 자주 변경되는 도메인 NC에 필요한 네트워크 대역폭을 사용하는 일이 없습니다.

디렉터리 변경은 모든 Active Directory DC에서 수행될 수 있기 때문에 Active Directory 복제가 추적해야 하는 쓰기 작업에는 두 가지 유형이 있습니다. 한 가지 유형은 특정 변경이 특정 DC에서 직접 수행된 때의 원래 쓰기 작업입니다. 예를 들어 DC1에 연결하여 사용자의 암호를 변경하면 이 변경 내용은 DC1의 원래 쓰기 작업으로 간주됩니다. Active Directory는 복제된 쓰기도 추적해야 합니다. 여기서 알 수 있듯이 특정 변경은 다른 도메인 컨트롤러로부터 복제됩니다. DC1에서 원래 쓰기 작업으로 간주된 변경은 해당 변경이 DC2, DC3 및 다른 모든 DC로 복제된 경우 복제된 쓰기 작업으로 간주됩니다.

Active Directory 도메인 컨트롤러에서는 복제 메타데이터를 사용하여 디렉터리 변경에 대한 전송을 관리합니다. 즉, Active Directory는 한 DC에서 다른 DC로 변경된 실제 데이터(John Smith의 설명이 'HR Director'로 변경됨)를 전달할 뿐만 아니라 도메인 컨트롤러가 복제를 가장 효과적으로 관리할 수 있도록 이 변경에 대한 추가 정보도 전송합니다. 이러한 정보로는 변경이 수행된 DC, 변경 시간, 기타 주요 정보 등이 있습니다.

여기서 설명할 복제 메타데이터의 첫 번째 항목은 USN(업데이트 시퀀스 번호)입니다. 각 도메인 컨트롤러는 해당 도메인 컨트롤러에 특정한 USN을 유지 관리합니다. 해당 DC에서 Active Directory를 변경할 때마다 USN이 1씩 증가됩니다. 따라서 오전 11:00에 DC의 USN이 1000이었고 오전 11:30에는 1005였다면 해당 DC에서 Active Directory 데이터베이스에 5번의 변경 작업이 수행되었음을 알 수 있습니다. USN과 관련해서는 이러한 변경이 정확히 무엇인지는 중요하지 않습니다. 5개의 개체를 수정했거나, 5개의 개체를 생성했거나, 5개의 개체를 삭제했거나, 이런 작업을 섞어 수행했을 수 있으며 이 모든 경우에 USN은 5가 증가됩니다. 또한 USN은 특정 도메인 컨트롤러에만 해당하는 요소로 다른 DC와 비교할 때는 아무런 관련이 없습니다. 즉, 특정 도메인의 한 DC가 오전 11:30에 변경 작업을 수행하는 경우 1051인 USN이 할당되고, 같은 도메인에서 다른 DC가 정확하게 동시에 변경 작업을 수행하는 경우 5084인 USN이 할당될 수 있습니다. 이 두 DC는 거의 동시에 수행된 변경에 대해 근본적으로 상이한 USN을 가지지만, 이 사실은 이러한 변경이 복제되는 방식과는 관계가 없습니다. 변경을 서로 비교할 때 한 DC의 업데이트 시퀀스 번호는 다른 모든 DC에 대해서는 어떠한 의미도 갖지 않습니다.

하지만 DC의 USN은 이외 다른 방법으로도 증가될 수 있습니다. 앞서 말했듯이 Active Directory 데이터베이스에 대한 변경은 원래 쓰기 작업 또는 복제된 쓰기 작업으로 구성될 수 있습니다. 도메인 컨트롤러의 업데이트 시퀀스 번호는 두 가지 유형 모두의 쓰기 작업을 통해 증가됩니다. 즉, 다른 DC에서 변경이 복제될 때마다 증가됩니다. 이제 각 DC에는 이미 복제된 변경을 추적할 방법이 있어야 합니다. 그렇지 않으면 각 DC는 복제할 때마다 쓰기 작업과 관련된 전체 Active Directory 데이터베이스를 보내야 합니다. 이를 방지하기 위해 각 Active Directory 도메인 컨트롤러는 복제하는 다른 도메인 컨트롤러에 대해 HWMV(High Watermark Vector)라는 값을 유지 관리합니다. 각 DC는 이 HWMV를 원격 DC의 GUID(Globally Unique Identifier)와 연결하여 원격 도메인 컨트롤러의 이름이 변경되거나 이 원격 도메인 컨트롤러가 디렉터리에서 제거될 때의 혼동을 방지합니다.

먼저 contoso.com 도메인에서 구성된 두 개의 도메인 컨트롤러인 dc1.contoso.com 및 dc2.contoso.com이 있는 간단한 예를 살펴보겠습니다. contoso.com 도메인에는 두 개의 DC만 있으므로 DC1과 DC2는 서로 간에만 복제합니다. 이 예는 Active Directory 복제 전체를 다루는 것이 아닌 단순화된 예입니다. 자세한 예는 이후 더 자세히 설명할 때 추가합니다.

이제 DC1의 현재 USN이 3000이고, DC2의 현재 USN이 4500이며 이 두 DC는 현재 서로 완전히 최신 상태에 있다고 가정해 보겠습니다.

1단계: DC1과 DC2가 서로 간에 최신 상태를 유지합니다. 그림 1에서 볼 수 있듯이 DC1의 D2에 대한 HWMV는 4500이며, DC2의 DC1에 대한 HWMV는 3000입니다.

그림 1 두 DC의 현재 상태

그림 1** 두 DC의 현재 상태 **

2단계: 관리자가 DC1에서 새 개체를 만들고 그림 2에서와 같이 DC1의 USN이 3001로 증가됩니다. DC1은 대기 중인 변경 작업이 있음을 아직 DC2에 알리지 않았으므로 DC2에서 DC1의 HWMV는 변경되지 않았습니다.

그림 2 새 개체가 추가됨

그림 2** 새 개체가 추가됨 **

3단계: DC1에서 사용 가능한 변경이 있음을 DC2에 알립니다. 그러면 DC2가 DC1과의 복제를 시작하여 사용 가능한 모든 업데이트를 요청합니다. 이 요청 과정에서 DC2는 그림 3에서와 같이 DC1에 대해 저장된 HWMV를 DC1에 전송합니다.

그림 3 변경 알림

그림 3** 변경 알림 **(더 크게 보려면 이미지를 클릭하십시오.)

4단계: DC1이 USN 3001에 해당하는 변경(즉, 단계2에서 DC1에 작성된 개체)을 DC2에 보냅니다. DC2는 그림 4에서와 같이 자신의 USN을 4501로 업데이트하고 DC1에 대한 HWMV를 3001로 업데이트합니다.

그림 4 변경 및 업데이트

그림 4** 변경 및 업데이트 **(더 크게 보려면 이미지를 클릭하십시오.)

지금까지는 별 문제가 없는 것 같죠? 하지만 여기에는 한 가지 문제가 있습니다. DC2에 복제가 필요한 변경이 있습니다. USN과 HWMV만 있다면 이 시점에 DC2는 DC1에 연결하여 DC1이 DC2로 복제한 것과 같은 변경을 다시 DC1로 복제하여 무한 복제 주기가 생성되고 결국 사용되는 대역폭이 점점 빠르게 증가할 것입니다. 이 문제를 해결하기 위해 몇 가지 대책이 더 필요하며 그 중 첫 번째가 UTDV(최신 벡터, UTD 벡터)입니다.

UTDV는 불필요한 전파 방지에 사용되는 또 다른 복제 메타데이터입니다. 즉, 동일한 변경이 네트워크를 통해 계속 복제되어 대역폭이 낭비되는 것을 방지하는 것이 목적입니다. 각 DC는 다른 모든 DC에 대해 최신 명명 컨텍스트의 복제본을 저장하는 UTDV 테이블을 유지 관리합니다. 도메인 NC의 경우 도메인의 각 DC는 도메인의 모든 DC에 대한 UTDV를 유지 관리합니다. 구성 및 스키마 NC의 경우에는 포리스트의 모든 DC에 대해 UTDV를 유지 관리합니다. UTDV는 각 DC가 복제 파트너로부터 수신한 가장 높은 USN뿐만 아니라 해당 NC를 복제하는 모든 DC에서 수신한 가장 높은 USN 값도 추적합니다. 이를 가능하게 하기 위해 각 복제된 변경에는 다음 정보도 포함됩니다.

  • 변경을 복제하는 DC의 GUID. 원래 쓰기 작업 또는 복제된 쓰기 작업으로 복제되는 변경일 수 있습니다.
  • 변경을 복제하는 DC의 USN. 원래 쓰기 작업 또는 복제된 쓰기 작업의 USN일 수 있습니다.
  • 변경이 시작된 DC의 GUID. 이 GUID가 변경을 복제하는 DC의 GUID와 같은 경우 이것은 원래 쓰기 작업입니다. 그렇지 않은 경우에는 UTDV 테이블이 작용합니다.
  • 변경이 시작된 DC의 USN. 이 USN이 변경을 복제하는 DC의 USN과 같은 경우 이것은 원래 쓰기 작업입니다. 그렇지 않은 경우에는 UTDV 테이블에서 제거됩니다.

이 프로세스의 이해를 돕기 위해 세 번째 도메인 컨트롤러인 DC3을 추가하여 예의 복잡성을 높여보겠습니다. 이 경우 DC1, DC2 및 DC3은 모두 서로 간의 복제 파트너입니다. DC1은 DC2 및 DC3과 복제되고, DC2는 DC1 및 DC3과 복제되고, DC3은 DC1 및 DC2와 복제됩니다.

1단계: DC1, DC2 및 DC3 모두 서로 간에 최신 상태를 유지합니다.

2단계: DC3이 jsmith 사용자 계정의 암호를 재설정하여 하나의 원래 쓰기 작업을 수행합니다. DC3에서 사용 가능한 변경이 있음을 DC1 및 DC2에 알립니다. 그림 5에서와 같이 DC1과 DC2는 DC3에서 원래 쓰기 작업을 가져온 다음 HWMV 및 UTDV 테이블을 DC3에 맞게 업데이트합니다.

그림 5 HWMV 및 UTDV 테이블 업데이트

그림 5** HWMV 및 UTDV 테이블 업데이트 **(더 크게 보려면 이미지를 클릭하십시오.)

3단계: 여기서 UTDV가 작동합니다. DC2에서 사용 가능한 변경이 있음을 DC1에 알립니다. 그러면 DC1은 DC2에 연결하고 DC2에 다음 정보를 보냄으로써 모든 새 변경을 요청합니다.

  • DC1의 DC2에 대한 가장 높은 HWMV(이 경우 4501)
  • DC3을 포함하여 모든 DC에서 수신한 가장 높은 원래 USN을 나타내는 DC1의 UTDV 테이블(그림 6)

Figure 6 UTDV 테이블

이 NC를 복제하는 모든 DC UTDV
<DC2의 GUID> 4501
<DC3의 GUID> 7002
   

HWMV가 4501임을 참고하여 DC2에서 해당 변경이 DC1에 복제되지 않았음을 인식합니다(그림 7 참조).

Figure 7 복제해야 하는 변경

속성 값 로컬 DC의 GUID 로컬 USN 원래 DC의 GUID 원래 USN
jsmith 암호 속성 %#FH%2rfg2 <DC2의 GUID> 4501 <DC3의 GUID> 7002
           

하지만 복제가 시작되기 전에 DC1이 전송한 UTDV 테이블에 따라 DC2는 DC1이 이미 DC3에서 이 변경을 수신했기 때문에 DC1에 실제로 이 변경이 필요하지 않은 것으로 판단합니다. 그림 8에서와 같이 이 시점에서 DC1은 DC2에 대한 HWMV 항목을 업데이트하여 증가된 USN을 반영합니다. 하지만 대역폭을 절약하기 위해 실제 데이터는 네트워크를 통해 전송되지 않습니다.

그림 8 불필요한 전파 방지

그림 8** 불필요한 전파 방지 **(더 크게 보려면 이미지를 클릭하십시오.)

4단계: DC2에서 DC3에 사용 가능한 변경이 있음을 알릴 때뿐만 아니라 DC1에서 유사한 방식으로 DC2와 DC3에 알릴 때에도 같은 불필요한 전파 방지가 적용됩니다. 이들 세 가지 DC는 모두 그림 8에서와 같이 복제 파트너에 대한 각 HWMV 항목을 업데이트하지만 실제 데이터는 단계2에서 각 DC로 이미 전송되었으므로 네트워크를 통해 다시 전송되지 않습니다.

다중 마스터 환경에서의 충돌 해결

지금까지의 예는 한 명의 관리자가 한 번에 하나의 DC를 변경하고, 이 작업을 수행하는 동안 다른 관리자는 아무런 작업도 하지 않는 이상적인 경우였습니다. 하지만 실제로는 이런 경우가 거의 없습니다. Active Directory 개체에 대한 업데이트는 도메인의 모든 도메인 컨트롤러에서 수행될 수 있기 때문입니다. 두 관리자가 두 도메인 컨트롤러에서 서로 충돌하는 업데이트를 수행하면 어떻게 될까요? Active Directory 환경에서는 세 가지 유형의 충돌이 발생할 수 있으며, 각 유형에 따라 서로 다른 충돌 해결 방법이 사용됩니다.

속성 변경 충돌 . 이 충돌은 두 관리자가 서로 충돌하는 방식으로 동일한 개체를 업데이트하는 경우에 발생합니다. 즉, 한 관리자가 사용자의 설명을 "Marketing"으로 설정할 때 다른 DC의 다른 관리자가 해당 사용자의 설명을 "Sales and Marketing"으로 설정하는 경우입니다.

새 개체 작성 충돌 . 두 관리자가 이름이 jsmith인 두 사용자와 같이 이름이 같은 개체를 동시에 만드는 경우에 이 충돌이 발생합니다.

개체를 삭제된 컨테이너로 이동 . 이러한 유형의 충돌은 꽤 드물게 발생하며, 한 관리자가 OU와 같은 컨테이너 내에서 개체를 만들거나 이동할 때 다른 DC의 다른 관리자가 동시에 이 컨테이너를 삭제하는 경우에 발생합니다.

처음 두 유형의 충돌을 해결하기 위해서는 충돌 해결에 주로 사용되는 두 개의 복제 메타데이터가 필요합니다. versionID 값은 개체의 개별적인 각 특성에 할당되며 개체가 처음 작성될 때 1부터 시작하여 DC에서 개별 특성이 수정될 때마다 1씩 증가합니다. 따라서 특정 사용자의 설명 특성이 기본값(공백 또는 <설정되지 않음>)에서 "Marketing Department"로 업데이트되면 설명 특성의 versionID는 2가 되고, 나중에 설명이 "Sales and Marketing Department"로 수정되면 설명 특성의 versionID는 3이 됩니다. 이 versionID는 앞서 설명한 다른 메타데이터와 함께 모든 복제 항목에 포함됩니다.

versionID는 복제 트래픽을 줄이는 용도로도 사용될 수 있습니다. 예를 들어 DC2의 관리자가 실수로 변경 내용을 여러 번 잘못 입력하여 하나의 특성을 여러 번 변경한 경우, 즉 DC2에 versionID 2, 3, 4, 5에 해당하는 원래 쓰기 작업이 있는 등의 경우에 DC2는 마지막 versionID인 5에 해당하는 쓰기 작업만 복제합니다. 이를 통해 이전 변경은 간단히 덮어써지므로 불필요한 대역폭 사용을 줄일 수 있습니다.

Active Directory에 대한 모든 변경에는 충돌 해결을 위한 두 번째 메타데이터인 타임스탬프도 포함됩니다. 타임스탬프는 수정 시간을 나타내는 복제 메타데이터의 일부입니다.

타임스탬프 특성은 Active Directory 복제 상태를 사전 측정하는 용도로도 사용됩니다. DC가 특정 DC에서 비교적 최근인 타임스탬프를 가진 변경을 찾지 못하면 해당 DC에 문제가 있을 수 있음을 알리는 오류 메시지가 생성됩니다.

그렇다면 이 두 특성이 충돌 해결에 어떻게 이용될까요? 각 충돌 유형을 하나씩 살펴보겠습니다.

속성 변경 충돌 해결

contoso.com 도메인의 jsmith 사용자 개체를 예로 들겠습니다. DC1의 관리자가 jsmith의 설명을 "Marketing"으로 변경합니다. 이와 거의 동시에 DC3의 관리자가 같은 사용자의 설명을 "Sales and Marketing"으로 변경합니다. 이 시점에서 그림 9와 같이 jsmith의 설명 특성에 대한 DC1 및 DC3의 정보를 비교합니다.

Figure 9 거의 동시에 수행되는 변경

서버 속성 값 VersionID 타임스탬프 로컬 DC의 GUID 로컬 USN 원래 DC의 GUID 원래 USN
DC1 jsmith 설명 속성 "Marketing" 2 2007-06-07 14:03:25 <DC1의 GUID> 3003 <DC1의 GUID> 3003
DC3 jsmith 설명 속성 "Sales and Marketing" 2 2007-06-07 14:04:57 <DC3의 GUID> 7003 <DC3의 GUID> 7003

DC2가 이 두 변경을 동시에 수신한 경우 DC2는 둘 중 우선적인 변경을 결정해야 합니다. 충돌 해결을 위한 우선 순위는 다음과 같이 결정됩니다.

  1. versionID가 더 높은 수정 사항이 우선권을 가지며 다른 변경 사항은 덮어써집니다. 이 경우 두 레코드의 versionID가 모두 2이기 때문에 다음 결정 기준으로 넘어가야 합니다.
  2. 두 레코드의 versionID가 같은 경우에는 타임스탬프가 더 최신인 변경이 선택되고 다른 변경은 덮어써집니다. 이 경우 DC3의 원래 쓰기 작업의 타임스탬프가 더 최신이므로 jsmith의 설명은 "Sales and Marketing"으로 설정됩니다. 드문 경우지만 versionID와 타임스탬프가 모두 동일하면 세 번째 결정 기준이 필요합니다.
  3. 두 레코드의 versionID와 타임스탬프가 같은 경우에는 GUID가 낮은 DC에서 시작된 쓰기 작업이 선택되고 GUID가 높은 쓰기 작업은 덮어써집니다. 따라서 DC1의 GUID가 1234567890이고 DC3의 GUID가 2345678901인 경우, versionID와 타임스탬프가 모두 동일하면 DC1의 원래 쓰기 작업이 선택됩니다.

아마도 "타임스탬프를 첫 번째 결정 기준으로 사용하는 것이 적당하지 않을까?"라는 생각을 할 수도 있겠지만 생각처럼 단순하지 않습니다. 타임스탬프가 Active Directory 충돌 해결의 우선적인 결정 기준이라면 악의적 관리자가 특정 DC의 시계를 뒤로 돌려서 항상 선택되도록 하여 자신의 변경 내용을 전파할 가능성이 있습니다.

개체 작성 충돌 해결

두 개체가 같은 이름으로 작성된 경우 Active Directory는 이전 단원에서 설명한 것과 같은 세 가지 결정 기준을 사용하여 우선적으로 선택할 개체를 결정합니다. 하지만 이전 단원에서처럼 선택되지 않은 개체를 덮어쓰지는 않습니다. 대신 충돌 개체에 대한 문자 CNF와 콜론 및 선택되지 않은 개체의 GUID를 사용하여 선택되지 않은 개체의 이름을 변경합니다. 이를 통해 관리자는 보존할 개체와 삭제할 개체를 더 체계적으로 판단할 수 있습니다.

삭제된 컨테이너로의 개체 이동 문제 해결

앞서 설명했듯이 삭제된 컨테이너로 개체를 이동하는 충돌 문제는 두 시나리오 중 하나에서만 발생하는 매우 드문 충돌입니다. 첫 번째 시나리오는 한 DC의 관리자가 Training OU와 같은 특정 컨테이너 안에 개체를 만들었을 때 이와 동시에 다른 DC의 관리자가 Training OU를 삭제한 경우입니다. 두 번째 시나리오는 한 DC의 관리자가 개체를 컨테이너로 이동할 때 이와 동시에 다른 DC의 관리자가 해당 컨테이너를 삭제하는 경우입니다.

이 경우의 해결 방법은 비교적 간단합니다. Active Directory는 "고아" 개체를 이런 용도로 설계된 Active Directory 내의 특별한 컨테이너인 LostAndFound 컨테이너로 이동합니다. 이 컨테이너는 각 Active Directory 도메인의 루트에 존재합니다. contoso.com 도메인의 경우 LostAndFound 컨테이너는 LDAP 경로인 LDAP://cn=LostAndFound,dc=contoso,dc=com에서 찾을 수 있습니다. Active Directory 사용자 및 컴퓨터 스냅인을 열었을 때 LostAndFound 컨테이너가 표시되지 않으면 보기 | 고급 기능을 클릭하십시오.

USN 롤백으로부터 보호

Active Directory 환경에서 접할 수 있는 가장 난감한 상황 중 하나는 그 원인과 해결 방법을 알기만 하면 가장 간단하게 피할 수 있기도 합니다. USN 롤백은 네트워크에서의 복제 작업을 완전히 종료시킬 수 있는 오류 상태이며, 도메인 컨트롤러를 너무 오랫동안 오프라인 상태로 유지하고 다시 서비스를 시작하도록 허용하거나 지원되지 않는 방법으로 도메인 컨트롤러를 복원할 때 발생할 수 있습니다.

USN 롤백의 기본 원인 중 하나는 Active Directory 다중 마스터 환경에서 개체 삭제가 처리되는 방식과 관련이 있습니다. 개체는 DC에서 삭제될 때 완전히 제거되는 것이 아니라 삭제 표시됩니다. 삭제 표시된 개체는 다른 DC에 삭제를 통보하여 복제될 수 있습니다. 삭제 표시된 개체는 TRUE로 설정된 isDeleted 특성을 갖습니다. 삭제 표시된 개체의 크기를 줄이기 위해 설명, 개인 정보, 사용자 개체의 그룹 구성원 등과 같이 개체에 포함된 대부분의 값은 제거됩니다. 이 프로세스에 대한 자세한 내용은 technetmagazine.com/issues/2007/09에서 볼 수 있는 Gil Kirkpatrick의 기사 "Active Directory 삭제 표시 개체 다시 애니메이션"을 참조하십시오.

USN 롤백은 이러한 삭제 표시된 개체가 일정 시간이 지나면 제거되기 때문에 발생할 수 있습니다. 기본적으로 이런 개체는 60일 또는 180일(Active Directory 환경을 처음 만들 때 실행 중이던 Windows Server®의 버전에 따라 다름) 후 Active Directory 데이터베이스에서 완전히 삭제됩니다. 이 60일 또는 180일 기간을 삭제 표시 수명이라고 합니다. 모든 도메인 컨트롤러는 이 기간 동안 최소 한 번 복제할 수 있어야 하며 그렇지 않은 경우에는 USN 롤백이 발생할 수 있습니다. 기본적으로 USN 롤백은 도메인 컨트롤러가 너무 오래 업데이트되지 않아 하나 이상의 삭제 표시된 개체가 "누락"되어 있고 이로 인해 다른 DC에서 최신 상태인 Active Directory 데이터베이스의 로컬 복사본을 가져올 수 없는 경우에 발생합니다. 이 문제를 방지하려면 삭제 표시 수명보다 길게 오프라인 상태였던 모든 도메인 컨트롤러는 다시 서비스를 개시하지 않아야 합니다. 대신 Microsoft 기술 자료 문서 216498(support.microsoft.com/kb/216498)의 단계를 사용하여 Active Directory에서 오래된 DC의 메타데이터를 제거한 후 처음부터 다시 빌드해야 합니다.

USN 롤백이 발생하는 두 번째 이유는 도메인 컨트롤러가 지원되지 않는 방법(대부분 디스크 복제 또는 이미징 도구 사용)으로 복원된 경우입니다. 이 경우 복원 방법에서 Active Directory를 인식하지 않기 때문에 복원된 Active Directory 데이터베이스는 "기존 시점"으로 복원된 것임을 인식하지 못합니다. Windows 2000 및 Windows Server 2003의 초기 릴리스에서는 USN 롤백을 감지하기 어려웠지만 Windows Server 2003 SP1(그리고 곧 출시될 Windows Server 2008)에는 DC가 부적절하게 복원된 것을 감지하는 컨트롤이 기본 제공됩니다. 이러한 최신 OS 버전에서 DC는 디렉터리 서비스 이벤트 로그에 이벤트 ID 1115, 2095, 2103 및 2110을 기록합니다. 이러한 이벤트의 텍스트와 USN 롤백을 복구하는 데 수행해야 하는 단계는 Windows Server 2003에 대해 설명하는 기술 자료 문서 875495(support.microsoft.com/kb/875495)에서 볼 수 있습니다. Windows 2000에서 USN 롤백을 다루는 방법에 대해서는 기술 자료 문서 885875(support.microsoft.com/kb/885875)를 참조하십시오.

2008에서의 다중 마스터 모델 업데이트

Microsoft에서는 곧 출시될 Windows Server 2008에 RODC(읽기 전용 도메인 컨트롤러)를 도입하여 다중 마스터 모델을 약간 변경했습니다. RODC는 기본적으로 지점 배포를 위해 설계되었으며 특정 위치에 파견된 IT 전담 직원이 없으며 특정 DC의 무결성을 보장할 추가적인 단계가 필요한 시나리오를 위해서도 설계되었습니다. RODC의 기술 세부 사항을 모두 설명하는 전체 기사를 제공할 수도 있지만 여기서는 알아야 하는 핵심 사항만 검토하겠습니다.

그 이름에서 알 수 있듯이 RODC에 있는 Active Directory 데이터베이스의 사본은 읽기 전용입니다. RODC에 연결하여 필요한 거의 모든 정보를 읽을 수 있지만 RODC에서는 쓰기 작업을 수행할 수 없습니다.

두 번째로 RODC는 아웃바운드 복제를 수행하지 않습니다. 이는 지금까지 설명한 다중 마스터 복제 모델에서 근본적으로 변경된 내용입니다. RODC는 쓰기 가능한 다른 Windows Server 2008 DC에서 인바운드 복제를 수신하기는 하지만 다른 DC로 정보를 복제하지 않습니다. 이를 통해 악의적 사용자가 RODC에서 어떤 식으로든 Active Directory를 수정할 수는 있더라도 이 수정 내용이 환경의 다른 부분으로 전파되지 않으므로 추가적인 보안 계층이 형성됩니다.

또한 가장 흥미로운 기능일 수 있겠지만 RODC는 기본적으로 사용자 암호를 복제하지 않습니다. Active Directory 데이터베이스가 쓰기 가능한 DC에서 RODC로 인바운드 복제될 때 모든 사용자 개체는 사용자 암호 정보 없이 복제됩니다. 따라서 DC가 외부에 연결되더라도 DC의 하드 드라이브에 암호 정보가 없기 때문에 지점 환경에 추가적인 보안 계층을 제공합니다. 전체적으로 봤을 때 다중 마스터 Active Directory 복제는 원래 개념이 위에 설명한 것과 같이 변경됨으로써 지점 또는 기타 원격 위치에서의 도메인 컨트롤러 보안을 위한 더욱 향상된 모델로 재탄생했습니다.

Laura E. Hunter는 Windows Server 네트워킹 분야에서 Microsoft MVP를 네 차례 수상했으며 IT 분야에서 10년 동안 일해 온 전문가입니다. Active Directory Cookbook, Second Edition(O'Reilly, 2006)을 포함하여 많은 서적, 기사 및 백서를 집필 또는 공동 집필했습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..