Active Directory USN 추적: 동기화 갭 분석 가이드

⚠️
배경
이 글은 Oracle OID와 Active Directory(AD) 연동에서 동기화 체크포인트와 AD USN의 차이를 조사한 사례를 다룹니다. 비교에 앞서 LACN이 가리키는 변경 원본과 조회한 DC·invocationID가 같은 기준인지 확인해야 합니다.
  • 사례에서 수백만 단위의 번호 차이가 관찰됐지만, 이를 누락 오브젝트 수나 미적용 변경 건수로 환산할 수는 없습니다.
  • 2022~2025년의 동기화 공백과 계정 불일치를 조사한 사례입니다. 실제 미적용 기간과 영향 범위는 당시 로그·체크포인트·대상 데이터로 확인해야 합니다.
  • 복구 방식은 원본과 대상의 현재 상태, 삭제 정보 보존 범위, 동기화 필터와 매핑을 대조한 뒤 결정합니다.

1. USN과 오브젝트 메타데이터

DC는 조회를 받는 도메인 컨트롤러를 뜻합니다. 아래 번호를 비교할 때는 어느 DC에서 조회했는지 함께 기록해야 합니다.

USN(Update Sequence Number)

USN은 DC가 로컬 변경을 식별하는 번호입니다. 다른 DC에서 같은 오브젝트를 읽어도 값이 다를 수 있으며, USN 자체는 전체 변경 이력이나 시각을 담은 감사 로그가 아닙니다.
▶주요 특징
  • uSNCreated: 해당 DC에서 오브젝트 생성 시 부여한 로컬 USN; 생성 시각은 별도 속성으로 확인
  • msDS-ReplAttributeMetaData: 속성별 복제 메타데이터 확인; 모든 과거 값을 보관한 이력은 아님
  • uSNChanged: 해당 DC에서 오브젝트가 마지막으로 변경됐을 때 부여한 로컬 USN
  • 복제 상태와 변경 후보 분석에 활용하되, USN만으로 롤백 지점을 지정하거나 데이터를 복원하지 않음

추적이 필요한 이유

  1. 동기화 서비스 장애: 동기화 장애 시 변경 원본·DC·프로파일 기준을 맞추고, 처리 로그와 대상 상태를 함께 확인
  2. 무결성 검증: 번호 비교를 보조 지표로 사용하고, 필터·매핑에 따른 대상 오브젝트와 속성 값을 대조
  3. 복구 지점 설정: 보존된 체크포인트·백업·감사 로그로 복구 기준 검토; 현재 USN만으로 과거 상태를 재현할 수 없음
  4. 액션 플랜 수립: DC·invocationID·조회 범위를 기록하고 오브젝트별 차이와 삭제 처리 여부를 정리

2. 사례의 진단 질문

문제 진단

💡
고객 질문
"AD에서 최신 Change Number(USN)를 확인하고, 구간별 영향 오브젝트나 속성의 USN값, 변경시간을 파악하는 방법은?"
✅
분석 접근
  • LDAP 조회와 repadmin 메타데이터를 진단 자료로 활용합니다. 예제는 LDAP 클라이언트·권한·암호화 조건을 확인한 뒤 사용해야 하며, 그대로 실행할 복구 절차는 아닙니다.
  • 로컬 USN과 원본 DC의 USN·변경 시각을 구분하고, 로그 및 현재 대상 값과 대조합니다.
  • 체크포인트 변경이나 Bootstrap은 제품 버전과 프로파일에 맞는 별도 복구 계획으로 검증합니다. 번호를 되돌린다고 데이터가 롤백되지는 않습니다.

3. 사례에 대한 조사 절차

▶장기 동기화 공백 조사 절차
  1. LACN의 변경 원본과 조회 DC·invocationID를 확인합니다. highestCommittedUSN과의 차이는 같은 번호 체계일 때만 해석하며, 누락 건수로 단정해서는 안 됩니다.
  2. AD 담당자와 당시 DC·invocationID 및 보존된 체크포인트를 확인합니다. 2022년 말의 USN은 현재 오브젝트에서 역산하지 않고 당시 기록이 있을 때만 기준으로 사용합니다.
  3. 같은 DC에서 uSNCreated·uSNChanged와 필요한 메타데이터를 수집합니다.
    현재 값은 과거의 모든 중간 변경을 보여주지 않습니다.
  4. 조회 권한·검색 범위·페이지 처리를 확인하고 현재 변경 후보를 대조합니다. 이동·삭제 오브젝트는 objectGUID와 별도 삭제 조회 또는 보존 기록으로 확인합니다.
  5. 체크포인트를 임의로 되돌리는 rewind를 안전한 복구 방법으로 봐서는 안 됩니다. 필터·매핑·삭제 처리와 재처리 영향을 검증한 뒤 제품이 지원하는 복구 방식과 승인 절차를 따릅니다.
  6. 보존 기간이 지나 제거된 삭제 정보는 현재 AD 조회로 되살릴 수 없습니다. 남은 백업·감사 기록과 대상 시스템을 대조하고, 증거가 없는 부분은 미확인으로 남깁니다.
▶USN과 시각 정보를 이용한 변경 후보 조사
  • 생성 시각이 확인된 오브젝트의 메타데이터를 참고하되, 그 USN을 전체 DC·오브젝트에 적용할 정확한 시간 경계로 사용하지 않습니다.
  • 같은 DC의 현재 변경 후보를 조사하고, 원본 변경 시각과 감사 로그를 함께 대조합니다.
  • 복제·동기화 진단 자료로 활용합니다. 과거의 모든 변경을 재생하거나 복구가 완료됐음을 증명하는 자료는 아닙니다.

4. 명령어 가이드

ldapsearch
repadmin

ldapsearch 기반 USN 정보 추출

ldapsearch -x -LLL -h <AD-HOST> -p <AD-PORT> \ -D "<읽기권한 계정 DN>" -w "<PASSWORD>" \ -b "<확인할 사용자 DN>" \ "(objectClass=*)" \ whenCreated whenChanged uSNCreated uSNChanged creatorsName msDS-ReplAttributeMetaData

실제 예시

ldapsearch -x -LLL -h 172.16.0.1 -p 389 \ -D "CN=Administrator,CN=Users,DC=example,DC=com" -w "ObiAdmin##11" \ -b "CN=Seed Beater,OU=_USERS,DC=example,DC=com" \ "(objectClass=*)" \ whenCreated whenChanged uSNCreated uSNChanged creatorsName msDS-ReplAttributeMetaData

repadmin 상세 분석

repadmin /showobjmeta <DC-NAME> "<User DN>"

실제 예시

repadmin /showobjmeta DOM-CON "CN=Seed Beater,OU=_USERS,DC=example,DC=com"

출력 예시

Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute ======= ============================= ======= ================ === ========= 32825 Default-First-Site-Name\DOM-CON 32825 2025-07-08 04:55:09 1 objectClass 36882 Default-First-Site-Name\DOM-CON 36882 2025-07-08 19:55:39 4 userPrincipalName

주요 속성

속성명 의미
whenCreated 오브젝트 생성 시각; LDAP Generalized-Time 표기를 확인
uSNCreated 해당 DC에서 생성 시 부여한 로컬 USN; 날짜 구간의 공통 하한은 아님
whenChanged 해당 DC의 마지막 변경 시각; 복제되지 않는 값
uSNChanged 해당 DC의 마지막 변경에 부여한 로컬 USN
msDS-ReplAttributeMetaData 속성별 버전·원본 변경 시각·로컬/원본 USN 등; 완전한 감사 이력은 아님
creatorsName AD에서 제공된다고 가정하지 말고 실제 스키마·응답을 확인; 생성자는 감사 로그 등 별도 근거로 확인

5. 분석 활용 시나리오

▶날짜 단서와 USN의 교차 확인
  1. 생성 시각과 해당 DC의 로컬 USN을 함께 기록합니다. 이것만으로 특정 날짜의 모든 변경에 대한 경계를 산출하지 않습니다.
  2. 현재 uSNChanged로 변경 후보를 찾되, 반복 변경으로 덮인 중간 이력과 삭제·이동 누락 가능성을 별도로 확인합니다.
  3. 속성 메타데이터에서 로컬/원본 USN·원본 DC·시각을 구분해 읽습니다. 수치 비교에는 해당 DC와 데이터베이스 이력 기준을 맞춥니다.
💡
실무 활용
생성 시각이 명확한 오브젝트는 조사 단서입니다. 과거 체크포인트와 당시 로그가 없으면 정확한 기간이나 누락 건수를 확정할 수는 없습니다.
▶포렌식 단서와 복구 조건 검토
  • USN과 메타데이터로 영향 후보를 좁히고, 감사 로그·백업·대상 데이터를 대조합니다. USN만으로 전체 피해 범위를 확정하지 않습니다.
  • 복제 장애와 데이터 불일치의 원인을 조사합니다. AD 복원과 동기화 체크포인트 조정은 별도 검증이 필요한 운영 작업입니다.

6. 명령어 비교

구분 ldapsearch repadmin
동작 환경 LDAP 클라이언트 구현·버전에 따라 옵션 확인 Windows의 AD DS/RSAT 도구; 설치 버전 확인
복제 메타데이터 권한과 스키마가 허용하는 속성; 응답 표현 확인 오브젝트별 복제 메타데이터 표시
USN 추출 범위 조회 시 페이지 처리·필터·권한 필요 로컬/원본 USN·버전·시각 대조에 활용
✅
사용 권장
일반 단일 값/간단 범위 추적: ldapsearch
상세 복제/속성 단위 추적: repadmin /showobjmeta

7. 주의사항

⚠️
USN 값은 DC 단위로 관리
uSNChanged는 DC 간 복제되지 않습니다. 같은 DC에 연결하고 invocationID를 함께 기록합니다. DC 변경이나 복원으로 기준이 달라졌다면 기존 체크포인트를 그대로 비교하지 않습니다.
⚠️
msDS-ReplAttributeMetaData 형태
LDAP 출력의 Base64는 전송 표기일 수 있으므로 실제 값과 구분합니다. 메타데이터는 repadmin이나 지원 도구로 확인할 수 있으며, Python·PowerShell 자동화가 필수인 것은 아닙니다.
⚠️
USN → 시간 변환 불가
USN을 날짜로 직접 변환할 수는 없습니다. whenChanged는 해당 DC의 값이고, 속성 메타데이터의 원본 변경 시각과도 구분해야 합니다. 두 값 모두 모든 과거 변경을 보관한 이력은 아닙니다.
⚠️
복구 시점 산정
현재 USN만으로 복구 시점을 정해서는 안 됩니다. 같은 DC·invocationID의 보존된 체크포인트, 삭제 정보 보존 상태, 대상 데이터와 복구 방식의 영향을 먼저 확인합니다.
예제의 -w 비밀번호는 명령 인자에 노출될 수 있으며, 389 포트 자체는 암호화를 보장하지 않습니다.

8. 현장 활용 예시

  1. 사고 시점 USN 범위 계산: 변경 후보 범위를 조사하고 감사 로그·삭제 정보·백업으로 보완; 피해 전체 범위로 단정하지 않음
  2. AD 장애 복구 타임라인: 사고 당시 기록을 보존하고 별도 검증된 복구 절차 수립
  3. 이관/동기화 검증: 동일 원본 기준의 체크포인트와 실제 오브젝트·속성·삭제 처리 결과를 함께 비교
  4. 포렌식 분석: 현재 메타데이터는 조사 단서로 사용하고 행위자·중간 변경 이력은 감사 기록 등으로 확인

결론

AD USN과 복제 메타데이터는 변경 후보와 동기화 기준을 조사하는 자료입니다. 특정 날짜 구간의 모든 변경이나 누락 건수를 현재 값만으로 확정할 수는 없습니다. ldapsearch와 repadmin, msDS-ReplAttributeMetaData, uSNCreated/uSNChanged 등을 사용할 때는 같은 DC·invocationID, 조회 권한과 범위를 기록하고 감사 로그·보존된 체크포인트·대상 데이터와 대조해야 합니다. 분석 결과와 복구 완료 판정은 구분합니다.

향후 계획

🔄
진행 중인 프로젝트
원문 작성 당시에는 분석 후 실제 복구 방식을 결정하고 실행하는 단계가 남아 있었습니다. 이 글에는 이후 결과를 확인할 자료가 없으므로 현재 진행 상태나 복구 완료를 단정하지 않습니다.
증분 재처리와 Bootstrap 중 어떤 방식이 적절한지는 제품 버전·프로파일·삭제 처리·원본/대상 상태를 검증한 뒤 결정해야 합니다. 추가 사례 기록이 확보되면 실제 적용 조건과 결과를 구분해 보완할 수 있습니다.