Netwrix 1Secure는 데이터와 아이덴티티 전반에 걸쳐 통합된 가시성을 제공합니다 - 14일간 무료로 전체 액세스가 가능합니다.무료 평가판 시작

리소스 센터블로그

Active Directory 연결된 속성 가이드

Active Directory 연결된 속성 가이드

Mar 17, 2023

연결된 Active Directory 속성은 개체 간의 관계를 설명하는 데 사용되는 특수 유형의 Active Directory 속성입니다. 이 글에서는 연결된 속성이 무엇인지, 그리고 어떻게 작동하는지 설명합니다.

엄선한 관련 콘텐츠:

어떤 속성을 연결된 속성(linked attribute)으로 만드는 것은 무엇인가요?

Active Directory의 모든 속성은 Active Directory 스키마 파티션에 있는 AttributeSchema 개체로 정의됩니다. 연결된 속성을 정의하는 AttributeSchema 개체는 LinkID 속성이 값으로 채워져 있는 유일한 스키마 개체입니다. 따라서 도메인에서 연결된 속성을 모두 식별하려면 다음과 같이 PowerShell을 사용해 LinkID가 값으로 채워진 개체를 스키마에서 검색하면 됩니다:

      Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -LDAPFilter "(LinkID=*)"
      

연결된 속성은 일반적으로 한 쌍으로 존재합니다. 즉, 포워드 링크(forward link)와 백 링크(back link)가 있으며, 이는 LinkID 속성의 값으로 정의됩니다:

  • 포워드 링크 — LinkID 값은 항상 양수인 짝수 정수입니다.
  • 백 링크 — LinkID 값은 항상 양수인 홀수 정수입니다. 사실, 이는 연결된 포워드 링크의 LinkID 값에 1을 더한 값입니다.

가장 작은 LinkID 값을 가진 속성은 Member 속성과 MemberOf 속성입니다. 이 두 속성은 Active Directory에서 그룹 멤버십을 추적하는 데 사용됩니다. 따라서 PowerShell 스크립트를 수정하여 출력이 이 두 속성에만 제한되도록 해봅시다:

Image

출력 결과를 통해 이 두 속성에 대해 몇 가지 중요한 사실을 알 수 있습니다:

  • Member 속성의 LinkID 값은 2인데, 이는 짝수 정수입니다. 즉, Member 속성은 순방향 링크(forward link)입니다.
  • MemberOf 속성의 LinkID 값은 3인데, 이는 홀수 정수입니다. 즉, MemberOf 속성은 역방향 링크(back link)입니다.
  • 역방향 링크(back link)인 MemberOf의 LinkID 값은 순방향 링크(forward link)인 Member 속성의 LinkID 값에 1을 더한 값입니다(3 = 2 + 1). 즉, Member 속성과 MemberOf 속성은 연결(연관)된 링크 속성(associated linked attributes)입니다.

약간 다른 PowerShell 스크립트를 사용하면 연결된 특성의 연결된 포워드 링크 또는 백 링크의 이름을 직접 가져올 수 있습니다. 다만 해당 특성이 포워드 링크인지 백 링크인지가 명시적으로 알려주지는 않습니다. LinkID 값을 확인하고 스스로 판단해야 합니다.

A PowerShell console displays Active Directory schema queries for 'member' and 'memberOf' properties, showing their LinkId, Name, and inverse Link attributes.

Active Directory 연결 특성은 어떻게 동작하나요?

이제 연결 특성이 무엇인지, 그리고 이를 식별하는 방법을 정리했으니, 이제는 그 동작 방식을 살펴볼 시간입니다.

연결 특성은 두 개체 간의 관계에 대한 정보를 저장하는 반면, 일반적인 Active Directory 특성은 개체에 대한 정보를 저장합니다. 이러한 기능적 차이는 Active Directory가 연결 특성의 값을 다른 특성의 값과 다르게 저장한다는 사실에서도 드러납니다.

연결 특성은 어떻게 저장되나요

Active Directory 데이터는 ntds.dit 데이터베이스 파일에 저장됩니다. 일반 속성의 값은 datatable 라는 테이블에 저장됩니다. 연결(Linked) 속성은 전용 테이블을 가지며, 그 이름이 link_table 입니다. 제 랩의 ntds.dit 데이터베이스 파일 스냅샷을 살짝 들여다보면 Active Directory가 연결된 속성 값을 어떻게 저장하는지 확인할 수 있습니다:

A screenshot of the DIT Snapshot Viewer application displaying data from the 'link_table', with the 'backlink_DNT' and 'link_DNT' columns highlighted.

link_table의 개체 참조는 개체의 distinguished name 태그(DNT)를 사용합니다. 이 DNT는 실제로 ntds.dit datatable에 있는 레코드의 내부 기본 키입니다. 따라서 개체의 distinguished name이 변경되어도, 연결된 link_table 항목을 모두 업데이트해야 하는 것을 방지합니다.

스크린샷은 link_table의 3가지 중요한 필드를 강조 표시합니다:

  • link_DNT — 순방향 링크 개체에 대한 참조입니다.
  • backlink_DN — 연결된 역방향(back) 링크 개체에 대한 참조입니다.
  • link_base — 전달 링크 속성의 LinkID에 대한 참조입니다. 이 필드는 두 개체 사이에서 추적 중인 관계를 식별하기 위해 전달 링크의 LinkID 값(앞 링크의 LinkID)을 사용합니다(표의 값은 스크린샷에서 볼 수 있듯이 실제로 LinkID 값을 2로 나눈 값입니다).

연결된 속성을 저장하는 이 접근 방식의 실질적 결과

이러한 저장 방식은 조금 이상하게 보일 수 있지만, 중요한 실질적 결과를 만들어내는 정말 훌륭한 설계입니다:

  • 전달 링크 값은 저장되고, 백 링크 값은 구성됩니다. 이 대화에서 반드시 가져가야 할 가장 중요한 개념은 다음과 같습니다: 백 링크는 실제로 정보를 저장하지 않습니다. 두 개체 간의 연결(association)은 하나의 단일 개체이므로 Active Directory는 연결의 사본을 하나 이상 저장할 필요가 없습니다. 전달 링크를 조회할 때 Active Directory는 조회된 개체의 DNT 값이 link_DNT 필드의 값과 일치하고, 전달 링크의 LinkID 값이 link_base 필드의 값과 일치하는 link_table 항목을 그대로 반환하면 됩니다. 백 링크를 조회할 때 Active Directory는 조회된 개체의 DNT 값이 backlink_DNT 필드의 값과 일치하고, 연결된(associated) 전달 링크의 LinkID(백 링크의 LinkID에서 1을 뺀 값으로 계산됨)가 link_base 필드의 값과 일치하는 link_table 항목을 반환함으로써 해당 값을 계산할 수 있습니다.
  • 전달 링크 값은 기록(쓰기) 가능하고, 백 링크 값은 읽기 전용입니다. 일단 Active Directory가 전달 링크의 값만 저장한다는 것을 알게 되면, 이것은 아마도 당연해 보일 것입니다. 하지만 중요한 결과가 있습니다. 즉, 연결된 속성이 수정되면 Active Directory는 전달 링크를 업데이트하고, 그 전달 링크를 보유한 개체가 수정됩니다. 구성된 읽기 전용 값을 지닌 백 링크는 결코 수정될 수 없으므로, 백 링크를 보유한 개체 역시 보유한 개체는 수정되지 않습니다.

    이것이 왜 중요한지 설명하기 위해, 사용자를 그룹에 추가하는 상황을 생각해 봅시다. 이 업데이트는 그룹의 Member 속성만 수정하며, 사용자의 MemberOf 속성은 수정하지 않습니다. 그룹 개체가 실질적인 변경을 겪었기 때문에, 해당 변경을 반영하는 메타데이터 필드(예: “ModifyTimeStamp” 및 “WhenChanged” 속성)는 업데이트됩니다. 동일한 메타데이터 필드가 사용자 개체에는 업데이트되지 않습니다. 그 이유는, 이제 사용자의 MemberOf 속성이 다른 값을 반환하게 되더라도 MemberOf 속성 자체는 수정되지 않았기 때문입니다.
  • 전방 링크는 필수이며, 후방 링크는 선택 사항입니다. 연결된 특성(Linked attributes)에 관한 일부 글에서는 연결된 특성에 항상 전방 링크와 후방 링크가 모두 있다고 말합니다. 이는 대체로 사실이지만, 후방 링크의 존재가 엄격히 필수인 것은 아닙니다. 실제로 PowerShell을 사용해 연결된 특성 쌍을 검색해 보면, 제 실험 환경의 모든 전방 링크에 항상 연결된 후방 링크가 있는 것은 아니라는 것을 확인할 수 있습니다:
Windows PowerShell output showing Active Directory linked attribute pairs.

연결된 특성을 저장하는 이 방식의 이점

제가 연결된 특성을 저장하는 방식이 꽤 똑똑하다고 말했던 것 기억하시나요? Active Directory가 연결된 특성 값(Linked attribute values)을 저장하는 방식은 실제로 아주 중요한 두 가지 이점을 제공합니다.

첫째, 전방 링크 값만 저장하고 이를 사용해 연결된 후방 링크 값(Back link values)을 계산하면 Active Directory database의 크기를 줄일 수 있습니다.

다른 핵심 이점(조금 덜 직관적인 부분)은 Active Directory가 각 연결(association)을 개별적으로 저장한다는 사실에서 비롯됩니다. 각 전방 링크의 associations는 link_table에 고유한 항목을 가지므로, 각 항목은 자기 고유의 Update Sequence Number(USN)를 유지할 수 있습니다. 이러한 동작을 Linked Value Replication(LVR)이라고 하며, Active Directory가 각 개별 association을 독립적으로 복제(replicate)할 수 있게 해줍니다. 예를 들어, 기존 구성원이 100명인 그룹에 사용자를 추가하면 새로 추가된 사용자에 대한 항목만 복제됩니다. 이로 인해 연결된 특성에 대한 변경 사항을 전파하는 데 필요한 복제(replication) 양을 크게 줄일 수 있습니다.

추가 사실

이 모든 내용을 정리하기 전에 한 가지 더 언급할 만한 동작이 있습니다:AD Recycle Bin이 활성화되어 있지 않으면 연결된 속성 값은 삭제된 개체에서 제거됩니다.연결된 속성을 가진 개체를 삭제하면, Active Directory가 해당 개체 자체를 한동안 tombstone으로 유지하더라도 개체와 연결된 link_table 항목도 함께 삭제됩니다. Active Directory Recycle Bin을 활성화하면 이러한 동작이 변경되어, 삭제된 개체의 tombstone 기간 동안 연결된 link_table 항목이 유지됩니다.

결론

Active Directory의 연결된 속성은 다른 Active Directory 속성과 저장 방식이 다르기 때문에 동작도 다릅니다. 이는 특히 back link 속성에서 더 두드러집니다. 이 글에서 하나만 기억해야 한다면, back link는 “구성(constructed)된 속성”이라는 사실입니다. 즉, 값이 직접 저장되지 않으며, 그 결과 특히 업데이트와 관련해서는 다른 속성들과 전혀 같은 방식으로 동작하지 않습니다. Active Directory는 일관된 사용자 경험을 위해 백엔드 동작을 잘 숨기는 편이지만, 속성에 내재된 이러한 차이와 그 결과를 이해하면 문제를 예방할 수 있습니다.

Netwrix가 도울 수 있는 방법

전체 범위에서 Active Directory를 끝부터 끝까지 안전하게 보호하는 Netwrix Active Directory security solution. 이를 통해 다음을 수행할 수 있습니다:

  • Active Directory에서 보안 위험을 파악하고, 대응 우선순위를 정하세요.
  • IT 인프라 전반에 걸쳐 보안 구성을 강화하세요.
  • DCSync와 같은 고도화된 위협을 신속하게 탐지하고 차단하며, DCSyncGolden Ticket 공격에 대응하세요.
  • 자동화된 응답 옵션으로 알려진 위협에 즉시 대응하세요.

빠른 Active Directory 복구로 업무 중단을 최소화하세요.

공유하기

더 알아보기

저자 소개

Asset Not Found

Joe Dibley

보안 연구원

Netwrix의 보안 연구원이며 Netwrix Security Research Team의 일원입니다. Joe는 Active Directory, Windows 및 다양한 엔터프라이즈 소프트웨어 플랫폼과 기술 분야의 전문가로, 새로운 보안 위험, 복잡한 공격 기법, 그리고 이에 대한 대응(완화)과 탐지 방법을 연구합니다.