• 아티클

Windows Server

Active Directory 삭제 표시 개체 다시 애니메이션

Gil Kirkpatrick

 

한 눈에 보기:

  • 삭제된 개체가 Active Directory에 저장되는 방식
  • LDP 및 ADRESTORE를 사용하여 삭제 표시 찾기 및 복원
  • 개체 특성 및 systemFlags

생각하고 싶지 않은 주제겠지만 실수로 인한 데이터 손실은 언제라도 발생할 수 있으므로 IT 전문가는 모든 종류의 복구 시나리오에 대비해야 합니다. TechNet Magazine 2007년 4월호에서 필자는

Active Directory® 사용자 및 그룹 복구 계획 수립의 중요성을 설명했습니다. technetmagazine.com/issues/2007/04/ADRecovery에서 볼 수 있는 이 기사에서는 개체 연결, 복제, 삭제 및 정식 복원의 메커니즘을 다루었습니다. 하지만 정식 복원 기능을 사용하려면 DC(도메인 컨트롤러)를 DSRM(디렉터리 서비스 복원 모드)에서 시작해야 합니다. 이렇게 하면 복원 작업 동안에는 DC를 사용할 수 없습니다.

이 외에 알아두어야 할 다른 방법이 있습니다. 삭제 표시 다시 애니메이션은 DC를 오프라인으로 전환하지 않고 삭제된 개체를 복구할 수 있는 유일한 방법이며, 삭제된 개체의 objectGUID 및 objectSid 특성과 같은 식별 정보를 복구할 수 있는 유일한 방법입니다. 또한 삭제된 사용자 및 그룹을 다시 만들고 삭제된 개체의 objectSid가 포함된 이전 ACL(액세스 제어 목록) 참조를 모두 수정해야 하는 문제를 깔끔하게 해결합니다. 다만 삭제 표시 다시 애니메이션에는 자체적인 제한이 있으므로 정식 복원도 계속 사용해야 할 수 있다는 점만 기억해 두십시오. 삭제 표시 다시 애니메이션만의 제한 사항은 이후에 설명합니다.

삭제 표시 다시 애니메이션은 특정 데이터 복구 시나리오를 단순화하기 위해 Windows Server® 2003 Active Directory에 도입되었습니다. 이 기능은 Active Directory가 삭제된 개체를 물리적으로 제거하기 전에 일정 시간 동안 데이터베이스에 보관한다는 점을 이용합니다. 이 기사에서는 Active Directory가 개체를 삭제하고 다시 애니메이션하는 방법을 자세히 설명하고 표준 Microsoft 도구를 사용하여 삭제된 개체를 복구하는 방법을 설명합니다.

삭제 표시란?

Active Directory가 디렉터리에서 개체를 삭제할 때 이 개체는 데이터베이스에서 물리적으로 제거되는 것이 아닙니다. 대신 Active Directory는 개체의 isDeleted 특성을 TRUE로 설정하고, 개체에서 대부분의 특성을 제거하고, 개체 이름을 변경한 다음 개체의 NC(명명 컨텍스트)에 있는 특수 컨테이너(CN=Deleted Objects)로 개체를 이동하여 개체를 삭제된 것으로 표시합니다. 이렇게 삭제된 개체를 삭제 표시라고 하며 이 개체는 일반 디렉터리 작업에 표시되지 않습니다. 삭제 표시 개체는 또한 어떠한 MMC(Microsoft® Management Console) 스냅인에도 표시되지 않으며 대부분의 LDAP(Lightweight Directory Access Protocol) 유틸리티에서도 그 존재를 인식하지 못합니다. 즉, 의도와 용도에 관계없이 모든 경우에 삭제 표시가 표시되지 않습니다. 하지만 이러한 데이터는 보이지 않을 뿐 여전히 존재합니다. 그렇다면 Active Directory는 왜 삭제 표시 또는 삭제된 개체를 데이터베이스에 보관하는 것일까요?

삭제 표시는 다른 프로세스에서는 표시되지 않지만 Active Directory 복제 프로세스에서는 표시됩니다. 삭제할 개체를 호스트하는 모든 DC에서 삭제가 수행되도록 하기 위해 Active Directory는 삭제 표시를 다른 DC로 복제합니다. 따라서 삭제 표시는 Active Directory 환경 전체에서 삭제를 복제하는 데 사용됩니다.

삭제 표시의 수명

Active Directory는 일반적으로 LDAP 삭제 프로토콜 작업 또는 SAM(Security Accounts Manager) 삭제 작업에 대한 응답으로 디렉터리에서 개체를 삭제합니다. 이 작업을 원래 삭제라고 하며 이 삭제 작업은 Active Directory 복제 프로세스가 수행하는 삭제 작업과 구분됩니다. 여기에서는 삭제 메커니즘이 다르며 TTL(Time-To-Live)이 만료될 때 Active Directory에 의해 직접 삭제되는 동적 개체는 다루지 않습니다.

Active Directory는 삭제 작업을 수신하면 먼저 검사 목록을 통해 개체 삭제가 허용되는지 여부를 확인합니다. 이 프로세스는 놀랍게도 다음 조건이 모두 true인지 확인합니다.

  • 개체의 isDeleted 특성이 아직 TRUE로 설정되어 있지 않습니다. (이미 삭제된 개체는 삭제할 수 없습니다.)
  • "개인 개체" 리소스 특정 보안 설명자 제어 플래그가 개체의 보안 설명자에 설정되어 있지 않습니다. (이는 문서화되지 않은 "기능"으로 나타납니다. 개인 개체 플래그는 보안 설명자 구조의 Sbz1 바이트의 비트 1입니다.)
  • "삭제 허용 안 함" 비트(0x80000000)가 개체의 systemFlags 특성에 설정되어 있지 않습니다.
  • 개체의 isCriticalSystemObject 특성이 TRUE로 설정되어 있지 않습니다.
  • 개체의 보안 설명자가 개체를 삭제할 사용자에게 적절한 액세스 권한을 부여합니다. (좀 더 구체적으로 말하면 사용자가 개체 자체뿐만 아니라 부모 개체에서 자식 개체를 삭제할 수 있도록 허용됩니다.)
  • 개체가 기존 명명 컨텍스트에 대한 상호 참조 개체(objectClass = crossRef)가 아닙니다.
  • 개체에 하위 개체가 없습니다. (LDAP 삭제 작업에 LDAP "트리 삭제" 제어 개체 ID가 포함된 경우 Active Directory는 isCriticalSystemObject 특성이 TRUE로 설정된 개체 이외에는 하위 개체도 자동으로 삭제합니다. 이를 통해 트리 삭제 작업에서 중요한 시스템 개체가 실수로 삭제되는 것을 방지할 수 있습니다. 물론 이들 개체는 개별적으로 삭제할 수 있습니다.)
  • 개체가 중요한 내부 개체가 아닙니다. (예를 들어 DC의 nTDSDSA 개체 또는 NC 헤드 상위 개체에 대한 자리 표시자 개체가 아닙니다.)

이러한 조건이 true이어야 하지만 Active Directory도 삭제 작업을 처리할 적절한 상태에 있어야 합니다. 예를 들어 Active Directory가 도메인 이름 변경 프로세스를 수행 중일 때는 도메인 트러스트 계정 또는 crossRef 개체를 삭제하지 않습니다.

개체를 삭제할 수 있는 것으로 판별되면 Active Directory는 개체를 삭제 표시로 전환합니다. Active Directory는 먼저 개체에서 그림 1에 명시되어 있는 특성과 삭제 표시에 유지되도록 스키마에 정의된 특성은 남겨두고 불필요한 특성을 제거합니다자세한 내용은 "개체 특성 복구" 단원을 참조하십시오. 그런 다음 개체의 RDN(상대 고유 이름)을 CN=<old RDN>\0ADEL:<objectGUID>로 변경합니다. 여기서 \0A는 ASCII 줄 바꿈 문자이고 <objectGUID>는 문자열로 표현된 objectGUID입니다. 그런 후 lastKnownParent 특성을 개체의 부모 컨테이너의 DN(고유 이름)으로 설정하고 isDeleted 특성을 TRUE로 설정합니다. 이 작업을 마친 다음 Active Directory는 개체에서 모든 정방향 및 역방향 연결 특성을 제거합니다. 마지막으로 개체의 systemFlag 특성에 "삭제 시 이동 허용 안 함" 비트가 설정되지 않은 경우 Active Directory는 개체를 NC에 대한 CN=Deleted Objects 컨테이너로 이동합니다. 이 항목에 대한 자세한 내용은 "systemFlags 특성 및 개체 동작" 추가 기사를 참조하십시오.

Figure 1 삭제 표시에 저장된 특성

저장하도록 하드 코드된 특성
attributeID
attributeSyntax
dnReferenceUpdate
dNSHostName
flatName
governsID
groupType
instanceType
lDAPDisplayName
legacyExchangeDN
mS-DS-CreatorSID
mSMQOwnerID
nCName
objectClass
objectGUID
objectSid
oMSyntax
proxiedObejctName
replPropertyMetaData
sAMAccountName
securityIdentifier
sIDHistory
subClassOf
systemFlags
trustPartner
trustDirection
trustType
trustAttributes
userAccountControl
uSNChanged
uSNCreated
whenCreated
searchFlags 설정으로 인해 저장되는 특성
msDS-AdditionalSam-AccountName
msDS-Auxiliary-Classes
msDS-Entry-Time-To-Die
msDS-IntId
msSFU30NisDomain
nTSecurityDescriptor
uid

CN=Deleted Objects 폴더에는 개체 계층 구조가 없음을 알아두어야 합니다. 이로 인해 CN이 같은 두 개의 다른 개체를 삭제한 경우 이름 충돌이 발생한다고 생각할 수 있습니다. 하지만 실제로는 그렇지 않습니다. objectGUID는 각 삭제 표시의 RDN에 통합되기 때문에 각 삭제 표시의 RDN은 CN=Deleted Objects 컨테이너 내에서 고유합니다.

즉, 개체가 CN=Deleted Objects 컨테이너에 영구적으로 남아 있지 않습니다. 삭제 표시의 기본 수명은 Windows® 2000 및 Windows Server 2003을 사용하여 처음 구축된 포리스트의 경우 60일이고, Windows Server 2003 SP1을 사용하여 처음 구축된 포리스트의 경우에는 180일입니다. 삭제 표시의 수명은 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 개체의 tombstoneLifetime 특성을 설정하여 변경할 수 있습니다.

각 도메인 컨트롤러는 12시간마다 가비지 수집 프로세스를 시작합니다. 가비지 수집 간격은 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 개체의 garbageCollPeriod 특성에 새 값을 설정하여 변경할 수 있습니다. 이 가비지 수집은 DC에서 모든 삭제 표시를 검색하여 삭제 표시 수명보다 오래된 모든 삭제 표시를 물리적으로 삭제합니다.

LDP를 사용하여 삭제 표시 찾기

LDP는 Active Directory를 사용하기 위한 Windows 탐색기와 비슷한 유형의 유틸리티입니다. LDP는 원래 Active Directory 개발 팀에서 Active Directory를 개발할 때 LDAP 코드를 테스트하기 위해 설계했습니다. 이제 Windows Server 2003 지원 도구의 일부로 제공되는 LDP는 Active Directory를 작업하는 데 필요한 강력한 도구로 발전했습니다.

삭제 표시는 일반 디렉터리 작업에서는 표시되지 않지만 LDAP 검색 작업 및 컨트롤이라고 하는 특별한 LDAP 확장을 사용하면 Active Directory에서 삭제 표시 개체를 찾을 수 있습니다. 컨트롤은 LDAP 표준에 정의된 메커니즘으로 다른 LDAP 호환 소프트웨어와의 호환성을 유지하면서 LDAP 표준 정의를 넘어서는 추가 기능을 제공하기 위해 LDAP 프로토콜을 확장하는 데 사용됩니다. Active Directory는 Return Deleted Objects 컨트롤을 포함하여 22개의 컨트롤을 지원합니다. 이 컨트롤을 사용하여 LDAP 검색 작업을 확장하면 컨트롤이 다른 경우에는 표시되지 않는 삭제된 개체를 검색합니다.

이 컨트롤의 작동 방식을 설명하기 위해 필자는 Enterprise Administrator 자격 증명으로 foo.local 도메인에 로그인한 다음 ADUC(Active Directory 사용자 및 컴퓨터) MMC 스냅인을 사용하여 사용자 개체(CN=John Smith,CN=Users,DC=foo,DC=local)를 만들었습니다. 이는 그림 2에서 확인할 수 있습니다. 그런 다음 다시 ADUC를 사용하여 사용자 개체를 삭제합니다.

그림 2 ADUC를 사용하여 사용자 만들기

그림 2** ADUC를 사용하여 사용자 만들기 **(더 크게 보려면 이미지를 클릭하십시오.)

이제 LDP 프로그램을 실행하고 이를 사용하여 삭제된 사용자에 대한 삭제 표시를 표시할 수 있습니다. 첫 번째 단계로 LDP를 특정 DC에 연결하고 적절한 자격 증명을 사용하여 인증합니다. Connection(연결) 메뉴의 Connect(연결) 옵션을 선택하여 DC에 간단하게 연결합니다. LDP를 DC에서 실행하고 있으므로 OK(확인)를 눌러 로컬 DC에 연결합니다. LDP를 원격으로 실행할 때는 연결할 DC의 이름을 지정해야 합니다. 연결에 성공하면 LDP에서 rootDSE의 특성을 표시합니다. 여기에서는 DC 자체의 상태와 구성을 설명하는 특성을 볼 수 있습니다(그림 3 참조).

그림 3 DC에 연결된 LDP

그림 3** DC에 연결된 LDP **(더 크게 보려면 이미지를 클릭하십시오.)

이제 도메인 또는 엔터프라이즈 관리자 자격 증명을 사용하여 DC에 인증하기 위해 Connection(연결) 메뉴에서 Bind(바인딩)를 선택합니다. 이미 포리스트의 Enterprise Administrator로 로그인했기 때문에(Domain Administrators 및 Enterprise Administrators에는 기본적으로 CN=Deleted Objects 컨테이너의 개체를 나열하고 다시 애니메이션할 권한이 있음) Bind(바인딩) 대화 상자의 Username(사용자 이름)과 Password(암호)를 비워두고 OK(확인)를 누릅니다. 그렇지 않은 경우에는 Bind(바인딩) 대화 상자에 적절한 자격 증명을 입력합니다.

다음으로 CN=Deleted Objects,DC=foo,DC=local 컨테이너의 내용을 나열하고자 합니다. 컨테이너 자체가 삭제된 것으로 표시되었기 때문에 일반적으로는 CN=Deleted Objects 컨테이너를 볼 수 없습니다. CN=Deleted Objects 컨테이너를 검색할 수 있는 유일한 방법은 Return Deleted Objects LDAP 컨트롤을 사용하는 것입니다.

LDP에 이 컨트롤을 사용하려면 Browse(찾아보기) 메뉴로 이동하여 Search(검색)를 선택합니다. 그림 4와 같은 Search(검색) 대화 상자가 나타납니다. Base Dn(기본 Dn) 필드에서는 디렉터리 트리에서 검색을 시작할 위치를 지정할 수 있습니다. 도메인에 대한 Deleted Objects 컨테이너의 DN을 입력합니다. 이 예제에서 DN은 CN=Deleted Objects,DC=foo,DC=local입니다.

그림 4 LDP Search(검색) 대화 상자

그림 4** LDP Search(검색) 대화 상자 **

Filter(필터) 필드에는 LDP가 사용할 검색 조건을 지정합니다. 기본값은 (objectClass=*)로, 이 경우 objectClass 특성 값이 있는 모든 개체가 반환됩니다. Active Directory에서 삭제된 개체도 objectClass 값은 갖고 있기 때문에 기본 필터에서는 검색 범위 내의 모든 개체가 반환됩니다. 이 예제에서는 필터를 (objectClass=user)로 변경하여 사용자 개체만 검색되도록 제한합니다. 이렇게 하면 CN=Deleted Objects 컨테이너에 있는 어쩌면 수천 개에 달할 수 있는 삭제 표시 중에서 삭제된 John Smith 사용자를 더 쉽게 찾을 수 있습니다.

CN=Deleted Objects 컨테이너에는 한 번의 검색 작업으로 Active Directory가 반환하는 것보다 많은 개체가 있음을 볼 수 있습니다. 일반적으로 이 문제를 해결하기 위해 결과를 한 번에 하나의 그룹으로 반환하는 페이지 형식의 LDAP 검색을 사용합니다. 하지만 LDP에서는 페이지 형식의 검색과 확장 검색을 모두 지정할 수 없습니다. 따라서 원하는 개체를 찾기 위해서는 LDAP 필터를 세밀하게 조정해야 합니다.

Scope(범위)의 라디오 단추를 사용하여 검색할 디렉터리 트리의 범위를 지정할 수 있습니다. Base(기본) 검색에서는 Base Dn(기준 Dn) 필드에 지정된 개체만 반환됩니다. One Level(한 수준) 검색에서는 Base Dn(기준 Dn) 개체 바로 아래에 있는 개체가 반환됩니다. Subtree(하위 트리) 검색에서는 Base Dn(기준 Dn) 개체의 모든 하위 개체가 반환됩니다. CN=Deleted Objects 폴더는 단일 구조이기 때문에 모든 삭제 표시를 검색하기 위해 One Level(한 수준) 검색을 사용합니다.

지금까지 일반적인 LDAP 검색을 개괄적으로 설명했습니다. 지금 LDP를 실행하면 CN=Deleted Objects,DC=foo,DC=com이 삭제된 것으로 표시되어 있기 때문에 존재하지 않는다는 오류를 표시합니다. 따라서 검색 작업에 Return Deleted Objects LDAP 컨트롤을 포함해야 합니다. 이렇게 하려면 Search(검색) 대화 상자에서 Options(옵션) 단추를 클릭하고 그림 5에서와 같이 Search Call Type(검색 호출 형식)에 Extended(확장)를 선택합니다. 이 옵션을 사용하면 검색 작업에 대한 컨트롤을 지정할 수 있습니다. 여기에서는 Attributes(특성) 목록도 *로 변경합니다. 이렇게 하면 LDP가 LDP의 기본 특성 집합 대신 검색하는 각 개체에 대한 일반 특성을 모두 표시합니다.

그림 5 LDP Search Options(검색 옵션) 대화 상자

그림 5** LDP Search Options(검색 옵션) 대화 상자 **

이제 Controls(컨트롤) 단추를 누르면 Controls(컨트롤) 대화 상자가 표시됩니다. LDP의 Controls(컨트롤) 대화 상자는 다소 불편하기 때문에 다음 단계를 신중하게 수행하여 Return Deleted Objects 컨트롤을 추가하십시오.

Load Predefined(로드할 미리 정의된 컨트롤) 드롭다운 목록에서 Return deleted objects를 선택하고 Check in(체크 인) 단추를 누릅니다. 그러면 그림 6에서와 같이 Return Deleted Objects 컨트롤에 대한 OID(개체 식별자) 1.2.840.113556.1.4.417이 Active Controls(활성 컨트롤) 목록에 추가됩니다. 이제 LDP에서 이 컨트롤을 이후의 모든 확장 검색 작업에 추가합니다. OK(확인)를 눌러 컨트롤 설정을 저장하고 다시 OK(확인)를 눌러 Search Options(검색 옵션) 대화 상자를 닫습니다.

그림 6 Return Deleted Objects 컨트롤 추가

그림 6** Return Deleted Objects 컨트롤 추가 **

Controls(컨트롤) 대화 상자에는 몇 가지 독특한 동작이 있습니다. 자세히 설명하자면 OID가 Active Controls(활성 컨트롤) 목록에 표시되어 있다고 해서 컨트롤이 실제로 적용되는 것은 아닙니다. 경우에 따라서는 컨트롤이 다음 LDAP 작업에 사용되도록 컨트롤을 체크 아웃한 다음 다시 체크 인해야 합니다.

이제 검색을 실행할 준비가 되었습니다. LDP Search(검색) 대화 상자에서 OK(확인) 단추를 누르면 LDP가 도메인의 CN=Deleted Objects 컨테이너에서 모든 사용자 개체를 검색합니다. 그림 7에서 결과를 볼 수 있습니다.

그림 7 CN=Deleted Objects 컨테이너에서 검색한 결과

그림 7** CN=Deleted Objects 컨테이너에서 검색한 결과 **(더 크게 보려면 이미지를 클릭하십시오.)

LDP 결과 검토

여기에서 설명한 검색을 수행한 결과 두 개의 삭제 표시 개체가 반환되었습니다. 먼저 첫 번째 삭제 표시의 DN인 CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local을 볼 수 있습니다. 삭제된 개체의 objectGUID는 문자열(41800281-6bc4-42c3-a99b-b283022b3af8)로 표현됩니다. DN 아래에는 objectClass, cn, distinguishedName 등에 대한 값이 표시되는 특성 목록이 표시됩니다. isDeleted 특성의 값이 TRUE이므로 개체가 실제로 삭제되었음을 알 수 있습니다. 또한 objectSid가 삭제 표시에서 유지되는 것도 볼 수 있습니다. 이후에 설명하겠지만 이것은 사용자 및 그룹 삭제 표시를 복구하는 데 있어 중요한 항목입니다. 삭제 표시가 되기 전에 개체에 포함되어 있던 개체의 DN을 나타내는 lastKnownParent 특성도 삭제 표시 복구에 있어 매우 중요한 항목입니다.

이 샘플에서 LDP는 두 개의 삭제 표시 개체를 표시하며 이 두 개는 모두 원래 CN=Users,dc=foo,dc=local 컨테이너에 있던 CN=John Smith라는 이름의 사용자 개체였습니다. 어떻게 RDN이 같은 두 개의 서로 다른 개체가 같은 컨테이너에서 올 수 있을까요? 그 이유는 간단하게 설명할 수 있습니다. LDP를 실행하여 삭제 표시를 검색하기 전에 필자는 CN=John Smith 사용자 개체를 CN=Users,DC=foo,DC=local 컨테이너에 만들고 이를 삭제했습니다. 그런 다음 모든 특성이 동일한 다른 사용자 개체를 만든 다음 이 개체도 삭제했습니다. 첫 번째 CN=John Smith 사용자 개체를 이미 삭제했기 때문에 이름이 같더라도 두 번째 개체를 만들 수 있었습니다. 하지만 이들은 objectGUID로 구분되는 별도의 고유한 개체입니다. Active Directory는 objectGUID를 삭제 표시의 DN에 통합하기 때문에 CN=Deleted Objects 컨테이너에서 별도의 개체로 나타납니다.

삭제 표시가 다시 애니메이션되는 방법

Active Directory는 삭제 표시를 다시 일반 개체로 복원하는 메커니즘을 제공합니다. 이 메커니즘은 삭제된 개체에 대한 효과적인 삭제 취소 기능입니다. 이 기능은 두 개의 특정 특성을 수정해야 하는 특별한 형태의 LDAP 수정 작업입니다. 즉, isDeleted 특성을 FALSE로 설정하는 것이 아니라 제거해야 하고 개체의 distinguishedName을 변경하여 개체를 다른 컨테이너로 이동해야 합니다. 새 distinguishedName은 반드시 그런 것은 아니지만 일반적으로 lastKnownParent 특성을 컨테이너로 사용하고 Active Directory가 삭제 표시를 만들 때 추가한 RDN에서 \0ADEL:<objectGUID> 부분을 제외하고는 같은 RDN을 유지합니다.

Active Directory는 삭제 표시를 다시 애니메이션하기 전에 특정 필수 조건이 모두 true인지 검사합니다. 사용자는 삭제 표시가 포함된 NC의 NC 헤드에 대해 정의된 삭제 표시 다시 애니메이션 확장 액세스 권한을 갖고 있어야 합니다. 사용자는 자신이 소유한 개체를 다시 애니메이션할 수 없습니다. 삭제 표시의 isDeleted 특성은 TRUE로 설정되어 있어야 합니다. 또한 보안 설명자에 정의된 대로 개체의 소유자 SID(보안 식별자)는 포리스트 또는 트러스트된 도메인에 있는 도메인 중 하나의 SID를 갖고 있어야 합니다.

해당 개체가 구성 또는 스키마 NC에 있는 경우에는 삭제 표시의 systemFlags 특성에 FLAG_CONFIG_ALLOW_RENAME 및 FLAG_ CONFIG_ALLOW_MOVE 비트가 설정되어 있어야 합니다. 개체가 구성 또는 스키마 NC에 있고 FLAG_CONFIG_ALLOW_LIMITED_MOVE 플래그가 설정되어 있으면 개체는 최상위 컨테이너가 같은 컨테이너로만 이동될 수 있습니다. 즉, 개체는 이동된 뒤에도 최상위 컨테이너를 그대로 유지해야 합니다. 또한 개체가 도메인 NC 또는 응용 프로그램 파티션에 있는 경우에는 삭제 표시의 systemFlags 특성에 FLAG_DOMAIN_DISALLOW_RENAME 및 FLAG_DOMAIN_DISALLOW_MOVE 비트가 설정되어 있지 않아야 합니다.

사용자는 보안 설명자에 정의된 대로 RDN(항상은 아니지만 일반적으로 CN)을 수정하고 새 부모 컨테이너에 개체를 추가할 수 있는 권리를 갖고 있어야 합니다. 또한 새 부모 컨테이너는 스키마 정의대로 삭제 표시의 objectClass에 대한 상위 항목이어야 합니다. Unlock 시스템 하위 트리 레지스트리 값 키가 0 이외의 값인 경우를 제외하고는 시스템 컨테이너 내외로의 이동은 일반적으로 허용되지 않지만 삭제 표시를 시스템 컨테이너로 다시 애니메이션하는 것은 허용됩니다.

스키마 개체를 다시 애니메이션하는 작업은 허용되지 않습니다. 하지만 스키마 NC에서 개체를 합법적으로 삭제할 수 없기 때문에 이 점은 사실상 문제가 되지 않습니다.

모든 검사를 통과하고 필수 요구 조건을 만족하는 경우 Active Directory에서는 삭제 표시에 다음 단계를 수행하여 개체를 다시 애니메이션합니다.

  • isDeleted 특성을 제거합니다.
  • 수정 작업에 미리 지정된 경우가 아니면 objectCategory는 삭제 표시에 지정된 가장 구체적인 objectClass로 설정됩니다.
  • RDN을 변경하고 개체를 새 부모 컨테이너에 씁니다.

다시 애니메이션된 개체는 삭제되기 전 원래 갖고 있던 objectGUID와 objectSid 특성을 동일하게 갖습니다. 따라서 삭제된 개체를 다시 만들 때처럼 ACL 등에서 개체 외부 참조를 다시 설정하지 않아도 됩니다. 다시 애니메이션된 개체는 삭제되기 전과 동일한 모습으로 동일하게 동작합니다. 하지만 한 가지 중요한 차이점이 있습니다. 이는 바로 삭제 표시에 저장되지 않은 특성은 복원된 개체에서 누락된다는 점입니다.

LDP를 사용하여 삭제 표시 다시 애니메이션

systemFlags 특성 및 개체 동작

systemFlags 특성은 이 특성을 모든 Active Directory 클래스에 대한 선택적 특성으로 만드는 최상위 클래스에 대해 정의된 선택적 특성입니다. 이 특성은 개체 이동 및 삭제 동작을 제어하는 32비트 정수 비트 마스크입니다. 다음은 중요 플래그에 대한 간단한 설명입니다.

FLAG_DISALLOW_DELETE (0x80000000)

이 플래그를 설정하면 개체의 삭제 또는 다른 도메인으로의 이동이 허용되지 않습니다.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

systemFlags 특성에 이 플래그가 설정되어 있지 않으면 구성 및 스키마 NC에 속한 개체의 이름을 변경할 수 없습니다.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

systemFlags 특성에 이 플래그가 설정되어 있지 않으면 구성 및 스키마 NC에 속한 개체를 이동할 수 없습니다.

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

systemFlags 특성에 이 플래그가 설정되어 있지 않으면 구성 및 스키마 NC에 속한 개체를 이동할 수 없습니다. 이 플래그는 이동 작업의 대상 컨테이너를 더욱 제한합니다. 즉, 대상 컨테이너의 최상위 컨테이너가 현재 컨테이너와 동일해야 합니다.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

기본적으로 도메인 NC 또는 응용 프로그램 NC에 속한 개체 이름은 변경할 수 있습니다. 하지만 개체의 systemFlags 특성에 이 플래그가 설정되어 있으면 개체 이름을 변경할 수 없습니다.

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

기본적으로 도메인 NC 또는 응용 프로그램 NC의 개체는 다른 컨테이너로 이동할 수 있습니다. 하지만 개체의 systemFlags 특성에 이 플래그가 설정되어 있으면 개체를 이동할 수 없습니다.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

이 플래그가 설정되어 있으면 개체를 명명 컨텍스트의 CN=Deleted Objects 컨테이너로 이동할 수 없습니다. 대신 isDeleted 특성을 설정하고, 개체 이름을 변경하고, 스키마에서 저장되도록 지정되지 않은 특성을 제거합니다. 따라서 삭제된 개체가 모두 명명 컨텍스트의 CN=Deleted Objects 컨테이너에 표시되는 것이 아니라 일부는 원래 부모 컨테이너에 남게 됩니다.

지금까지 삭제 표시의 다시 애니메이션 작동 방식을 개괄적으로 살펴보았으므로 LDP를 사용하여 앞서 삭제한 CN=John Smith 사용자를 복원하는 방법을 설명하겠습니다. 먼저 DC에 연결하고 인증합니다. 이제 LDP를 사용하여 수정 작업을 수행할 수 있습니다. 수정 작업 매개 변수를 통해 isDeleted 특성을 제거하고 동시에 새 DN을 지정할 수 있습니다.

삭제 표시에 대해 작업을 하고 있으므로 Return Deleted Objects LDAP 컨트롤을 지정해야 합니다. LDP에서 수정 작업에 사용할 이 컨트롤을 설정하려면 옵션 메뉴에서 Controls(컨트롤)를 선택하고, Load Predefined(로드할 미리 정의된 컨트롤) 드롭다운 목록에서 Return deleted objects를 선택하고, Check in(체크 인) 단추를 누른 다음 OK(확인)를 눌러 컨트롤 설정을 저장합니다.

이제 Browse(찾아보기) 메뉴에서 Modify(수정)를 선택하여 Modify(수정) 대화 상자를 열고 복원할 삭제 표시 개체의 DN을 입력합니다. DN은 앞서 수행한 검색 작업의 결과에서 DN을 복사한 다음 붙여 넣는 방법으로 쉽게 입력할 수 있습니다.

그런 다음 수행할 특성 작업의 목록을 입력해야 합니다. 삭제 표시를 다시 애니메이션하려면 두 가지 특성 작업이 필요합니다. 즉, isDeleted 특성을 삭제하고 distinguishedName 특성을 다시 애니메이션된 삭제 표시에 대해 원하는 DN으로 바꿉니다. 따라서 Attribute(특성) 필드에는 isDeleted를 입력하고 Delete(삭제) 라디오 단추를 선택합니다. Enter(입력) 단추를 누르면 그림 8에서와 같이 특성 작업이 Entry List(항목 목록)에 추가됩니다.

그림 8 수행할 특성 작업 지정

그림 8** 수행할 특성 작업 지정 **

그런 다음 distinguishedName을 Attribute(특성) 필드에 입력하고 Replace(바꾸기) 라디오 단추를 선택한 다음 Values(값) 필드에 개체의 새 DN을 입력합니다. 이 예제에서는 사용자의 원래 distuiguishedName인 CN=John Smith,CN=Users,DC=foo,DC=local을 사용합니다. Enter(입력) 단추를 누르면 수정 작업이 Entry List(항목 목록)에 추가됩니다.

Return Deleted objects LDAP 컨트롤을 수정 작업에 포함해야 하므로 확장된 LDAP 수정을 사용해야 합니다. 이를 위해 Extended(확장) 확인란을 선택합니다. 그림 9에서와 같이 설정을 마쳤으면 Run(실행) 단추를 눌러 변경 내용을 적용합니다. LDP는 큰 텍스트 창에 결과를 표시합니다.

그림 9 distinguishedName 변경

그림 9** distinguishedName 변경 **

이제 Active Directory 사용자 및 컴퓨터 MMC 스냅인으로 돌아가서 CN=Users 컨테이너를 보면 삭제된 사용자 개체가 다시 원래 위치로 복원된 것을 볼 수 있습니다. 하지만 이 개체는 원래 상태와 몇 가지 중요한 차이점을 보이는데 이에 대해 잠깐 살펴보겠습니다.

ADRESTORE를 사용하여 삭제 표시 다시 애니메이션

LDP를 사용하는 방법을 알고 나면 삭제 표시를 다시 애니메이션하는 작업은 그리 어렵지 않습니다. 하지만 그다지 편리하지도 않습니다. 다행히도 지금은 Microsoft의 일부가 된 Sysinternals에서 다시 애니메이션 실행 프로세스를 단순화하는 명령줄 도구를 개발했습니다. ADRESTORE라는 이 도구는 Microsoft 웹 사이트(microsoft.com/technet/sysinternals/utilities/AdRestore.mspx)에서 얻을 수 있습니다. 설치는 간단하게 할 수 있습니다. 실행 파일을 C:\WINDOWS\SYSTEM32 디렉터리와 같은 시스템의 적절한 디렉터리로 복사하기만 하면 됩니다.

ADRESTORE는 두 가지 모드에서 실행됩니다. 매개 변수를 지정하지 않고 실행하면 기본 도메인의 CN=Deleted Objects 컨테이너에 있는 모든 삭제 표시가 나열됩니다. 명령줄에 검색 문자열을 추가하여 표시할 개체를 선택할 수도 있습니다. 예를 들면 다음과 같습니다.

C:\> adrestore John

이렇게 하면 CN=Deleted Objects 컨테이너에서 CN 또는 OU 특성에 "John"이라는 문자열이 포함된 모든 삭제 표시 개체가 표시됩니다. 여기에는 LDAP 검색 필터 cn=*John* 및 ou=*John*이 사용됩니다. 이 방법이 삭제 표시 개체를 검색하는 가장 유연한 방법은 아니지만 대부분의 상황에 적합합니다. 그림 10에서는 ADRESTORE에서 반환된 검색 결과를 보여 줍니다.

그림 10 삭제 표시에 저장된 특성

그림 10** 삭제 표시에 저장된 특성 **(더 크게 보려면 이미지를 클릭하십시오.)

삭제 표시를 찾는 것만이 아니라 다시 애니메이션하려면 다음과 같이 선택적 문자열과 함께 -r 스위치를 지정해야 합니다.

C:\> adrestore –r John

이 명령을 실행하면 일치하는 각 삭제 표시 개체를 다시 애니메이션할지 묻는 메시지가 표시됩니다. ADRESTORE는 항상 삭제 표시의 lastKnownParent 특성으로 지정된 컨테이너로 개체를 다시 애니메이션합니다. 다른 컨테이너를 지정할 수는 없습니다.

ADRESTORE는 Active Directory 다시 애니메이션 기능을 사용하기 위한 편리한 명령줄 인터페이스를 제공합니다. 유연성이 뛰어나지는 않지만 LDP보다는 사용하기가 조금 더 쉽습니다. 하지만 ADRESTORE도 삭제 표시 다시 애니메이션과 관련하여 나타나는 두 가지 중요한 문제인 처음 삭제될 때 개체에서 제거된 특성의 복구와 구성 NC에서 삭제된 개체의 복구 문제는 해결하지 못합니다.

개체 특성 복구

데이터 복구의 측면에서 보면 삭제 표시 다시 애니메이션은 정식 복원을 수행하는 것보다 더 큰 장점을 제공합니다. 삭제 표시 다시 애니메이션의 경우 DC를 오프라인으로 전환할 필요가 없기 때문입니다. 또한 삭제 표시 다시 애니메이션은 삭제된 개체의 새 버전을 간단하게 다시 만드는 것보다 훨씬 편리합니다. 개체를 새로 만들려면 항상 새 objectGUID 및 objectSid(사용자와 같은 보안 주체인 경우) 특성을 가져와야 합니다. 그 결과 ACL과 같은 경우 개체에 대한 모든 외부 참조를 업데이트하여 새 개체의 ID를 반영해야 합니다. 이렇게 하려면 작업이 매우 복잡할 수 있습니다.

개체가 삭제될 때는 일부 특성이 제거되는데 이러한 특성은 삭제 표시 다시 애니메이션으로 복구되지 않습니다. 하지만 Active Directory는 일부 중요한 특성을 삭제 표시에 저장하는데 여기서 가장 중요한 것은 objectGUID와 objectSid와 같은 ID 관련 특성입니다. 또한 기본적으로 여러 가지 다른 특성도 저장합니다(그림 1 참조). 저장되도록 하드 코드된 대부분의 특성은 그리 중요하지 않으며 삭제된 사용자 개체의 복구를 이야기할 때는 더욱 그렇습니다. 하지만 Active Directory 스키마에 있는 해당 attributeSchema 개체의 searchFlags 특성을 비트 3(0x00000008)으로 설정하여 삭제 표시에 저장할 추가적인 특성을 지정할 수 있습니다. Windows Server 2003 R2의 경우 스키마의 일부 특성에는 이미 이 비트가 설정되어 있습니다(그림 1 참조).

특정 응용 프로그램을 설치하면 기존 특성의 searchFlags에 설정된 비트 3이 변경되거나 비트 3이 설정된 특성이 새로 추가될 수도 있습니다. 예를 들어 Exchange Server는 몇 가지 추가 특성이 삭제 표시에 저장되도록 구성합니다.

Active Directory는 스키마 개체의 searchFlags 특성에서 지정하더라도 정방향 연결 또는 역방향 연결 특성을 삭제 표시에 저장하지 않습니다. 특히 Active Directory는 그룹의 member 특성 또는 사용자의 memberOf 특성과 같은 항목을 저장하지 않습니다. 따라서 삭제 표시 다시 애니메이션을 사용해서는 Active Directory에서 이와 같은 그룹 구성원 데이터를 복구할 수 없습니다. 필자의 기사인 "재해 복구: Active Directory 사용자 및 그룹"(technetmagazine.com/issues/2007/04/ADRecovery) 기사를 참조하십시오. 따라서 삭제 표시를 다시 애니메이션할 때 이 정보를 복구하기 위한 다른 메커니즘을 제공해야 합니다.

삭제 표시 다시 애니메이션을 데이터 복구 전략의 일부로 사용하려면 중요한 특성이 삭제 표시에 저장되도록 하거나 LDIFDE나 다른 백업/복원 스키마를 사용하는 것처럼 중요한 특성을 저장하고 복구할 다른 방법을 제공해야 합니다. 다른 방법으로 삭제 표시에 저장되거나 삭제 표시에서 복구되지 않는 특성을 백업하고 복원하는 자동화된 메커니즘을 제공하는 타사 Active Directory 데이터 복구 제품을 사용할 수도 있습니다.

구성 명명 컨텍스트에서 개체 다시 애니메이션

삭제 표시 다시 애니메이션의 또 다른 제한은 일반적으로 구성 NC에서 삭제된 개체는 다시 애니메이션할 수 없다는 점입니다. 이러한 개체는 개체의 systemFlags 특성에 정의된 대로 이동 및 이름 변경에 대한 특별한 규칙을 따릅니다. systemFlags 특성을 사용하여 별도로 지정한 경우 이외에는 구성 NC의 개체를 이동하거나 개체의 이름을 변경할 수 없기 때문에 삭제 표시를 다시 애니메이션할 수 없습니다. Active Directory에서는 그림 11에 정의된 것처럼 특정 클래스의 개체를 만들 때 systemFlags 특성에 특정 값을 설정합니다. Active Directory는 추가 작업에서 지정된 모든 systemFlags 값과 함께 해당 값에 비트 논리 OR 연산을 적용합니다. 응용 프로그램이 systemFlags 특성에 다른 값을 지정한 경우에도 이 방법을 통해 필수 비트가 적절하게 설정됩니다.

Figure 11 기본 systemFlags 설정

클래스 기본 설정
server FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA FLAG_DISALLOW_MOVE_ON_DELETE
siteLink FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge FLAG_CONFIG_ALLOW_RENAME
nTDSConnection FLAG_CONFIG_ALLOW_RENAME

일반적으로 구성 NC에서 다시 애니메이션할 수 있는 유일한 개체는 서버 개체입니다. 흥미롭게도 Active Directory가 서버 개체를 삭제할 때는 삭제 표시가 구성 NC의 CN=Deleted Objects 컨테이너로 이동되지 않습니다. 즉, 삭제 표시는 개체의 원래 위치에 남아 있습니다. 이를 통해 Active Directory 복제 토폴로지 계산을 담당하는 KCC(정보 일관성 검사기)가 삭제된 서버 개체가 적절한 복제를 억제했을 수 있는 특정 시나리오에서 자동으로 복구할 수 있습니다. 따라서 서버 개체를 다시 애니메이션하려는 경우에는 해당 개체를 CN=Deleted Objects 컨테이너에서 찾을 수 없음을 기억하십시오.

복구 계획에서의 다시 애니메이션

삭제 표시 다시 애니메이션은 데이터 복구 도구 키트의 핵심 부분입니다. 이 메커니즘은 DC를 오프라인으로 전환하지 않고 삭제된 개체를 복구할 수 있는 유일한 방법이며 삭제된 개체의 ID 정보를 복구할 수 있는 유일한 방법입니다. 이를 통해 삭제된 사용자나 그룹을 다시 만들고 이전 ACL 참조를 모두 수정해야 하는 문제점이 해결됩니다.

하지만 삭제 표시 다시 애니메이션도 완전한 솔루션은 아닙니다. Active Directory가 삭제 표시 개체에 저장하지 않는 특성을 복구할 수 있는 자체 메커니즘을 제공해야 하며 구성 NC에서 삭제된 개체를 복구하는 기능도 제한적입니다. 삭제된 사용자나 그룹을 다시 애니메이션하려고 결정한 경우에도 필요할 수 있는 다른 연결된 특성 및 그룹 구성원을 복구해야 한다는 점을 기억하십시오.

Gil Kirkpatrick은 NetPro의 CTO로서 1996년부터 Active Directory용 소프트웨어를 개발해오고 있으며, HP의 Guido Grillenmeier와 함께 인기 있는 Active Directory 재해 복구 워크샵을 진행하고 있습니다. 또한 Directory Experts Conference(www.dec2007.com)의 창립자이기도 합니다.

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