DDAMNOTE 블로그 입니다.

5 minute read

[장애복구] 도메인 컨트롤러 이름을 실수로 바꿨다 — netdom 복구와 복제 오류 8524 해결 전 과정

요약: 클라이언트용 Rename-Computer를 DC에서 실행 → DC가 “WIN11-CL01”로 개명 + Domain Controllers OU 이탈 → netdom으로 이름 복원 → 잔여 복제 오류 8524(_msdcs GUID CNAME 조회 실패) → DNS 캐시 정리 + 강제 복제로 완전 복구. 검색 키워드: netdom computername, 복제 오류 8524, _msdcs CNAME, DC 이름 변경

1. 사고 발생

홈랩에서 Win10/Win11 클라이언트의 컴퓨터 이름을 정리하던 중이었다. “각 VM 콘솔에서 실행”해야 할 명령을, 계속 작업하던 DC01 창에 그대로 붙여넣었다.

Rename-Computer -NewName "WIN11-CL01" -DomainCredential AZLAB\adm-jmpark -Restart -Force

DC01이 WIN11-CL01로 개명되고 재부팅됐다. 문제는 여기서 끝이 아니었다 — 사고를 인지하지 못한 채, “새로 이름 바뀐 클라이언트를 OU로 옮기는” 다음 단계를 실행했고, DC 컴퓨터 개체가 Domain Controllers OU에서 Workstations OU로 이동해버렸다.

이상함을 감지한 건 확인 명령의 출력이었다:

Name       OperatingSystem
----       ---------------
WIN11-CL01 Windows Server 2022 Standard Evaluation   ← Win11 Pro여야 하는데?

전체 컴퓨터 목록을 보니 그림이 나왔다:

WIN11-CL01      Windows Server 2022 ...  OU=Workstations,...   ← 개명된 DC01
WIN-RFQOQTNHTS0 Windows Server 2025 ...  OU=Domain Controllers ← DC02만 남음
DESKTOP-9BDUGO8 Windows 10 Pro           CN=Computers          ← 진짜 클라이언트 (그대로)
DESKTOP-T6MR55F Windows 11 Pro           CN=Computers          ← 진짜 클라이언트 (그대로)

확진 방법: 그 머신에서 NTDS 서비스가 돌고 있으면 DC다.

PS> hostname
WIN11-CL01
PS> Get-Service NTDS, DNS
Running  DNS   DNS Server
Running  NTDS  Active Directory Domain Services   ← DC 확정

2. 왜 심각한가

DC 이름은 단순 레이블이 아니다. SPN(Kerberos), DNS SRV 레코드, 복제 파트너 참조가 전부 이름에 묶여 있다. 게다가 Domain Controllers OU를 벗어난 DC는 Default Domain Controllers Policy를 받지 못한다 — DC 전용 보안 정책(사용자 권한 할당 등)이 빠지는 상태라 OU 원위치가 최우선이다.

3. 복구 절차

3-1. DC 개체를 Domain Controllers OU로 원위치 (최우선)

Get-ADComputer WIN11-CL01 |
    Move-ADObject -TargetPath "OU=Domain Controllers,DC=azlab,DC=istn,DC=co,DC=kr"

3-2. netdom으로 이름 복원

DC 이름 변경은 Rename-Computer가 아니라 netdom 3단계 절차가 정석이다. 대체 이름을 먼저 추가하고 전환하는 방식이라, SPN/DNS가 새 이름으로 준비된 후에 주 이름이 바뀐다.

# ① 대체 이름 추가
netdom computername WIN11-CL01 /add:DC01.azlab.istn.co.kr

# ② 확인 — 양쪽 이름이 모두 보여야 함
netdom computername WIN11-CL01 /enumerate

# ③ 주 이름 전환 (재부팅 필요 안내가 나옴 — 전환 전까지 인증 불안정 경고 포함)
netdom computername WIN11-CL01 /makeprimary:DC01.azlab.istn.co.kr

Restart-Computer

주의: makeprimary를 실행하기 전에 재부팅하면 이름이 안 바뀐 채 올라온다. add → enumerate 확인 → makeprimary → 재부팅 순서.

재부팅 전 체크: 다른 DC(DC02)가 켜져 있어야 한다. DC01이 내려간 동안의 도메인 인증과, 재부팅 후 SRV 레코드 갱신 복제를 DC02가 받아준다. 평소 클라이언트 보조 DNS로 DC02를 넣어둔 것도 이 상황에서 빛을 봤다.

3-3. 재부팅 후 정리

hostname                                              # DC01 확인
netdom computername DC01 /remove:WIN11-CL01.azlab.istn.co.kr   # 옛 이름 제거
ipconfig /registerdns                                 # A + SRV 재등록
Restart-Service Netlogon                              # SRV 레코드 갱신 트리거

4. 잔여 증상 — 복제 오류 8524

이름은 복원됐지만 dcdiag/repadmin에서 복제 실패가 남았다:

repadmin /replsummary
Source DSA          largest delta  fails/total %%   error
 WIN-RFQOQTNHTS0        51m:13s     2 /   5   40  (8524) The DSA operation is
                                        unable to proceed because of a DNS lookup failure.

The guid-based DNS name
c250bd0e-1667-4f6a-840a-072d42f19e12._msdcs.azlab.istn.co.kr
is not registered on one or more DNS servers.

4-1. 8524의 정체 — DC는 서로를 GUID CNAME으로 찾는다

DC 간 복제는 호스트명이 아니라 _msdcs 존의 DSA GUID 기반 CNAME으로 상대를 찾는다:

<DSA-GUID>._msdcs.<forest>  →  CNAME  →  상대 DC의 FQDN  →  A 레코드

8524는 이 체인 어딘가가 끊겼다는 뜻이다. 이름 변경/재부팅 직후에는 레코드 등록이 복제/등록 타이밍을 못 따라와 일시적으로 발생할 수 있다.

4-2. 진단

# 문제의 GUID CNAME이 조회되는가
Resolve-DnsName c250bd0e-1667-4f6a-840a-072d42f19e12._msdcs.azlab.istn.co.kr

# _msdcs 존의 CNAME 전수 확인
Get-DnsServerResourceRecord -ZoneName "_msdcs.azlab.istn.co.kr" -RRType CName

내 경우 이 시점엔 CNAME이 정상 조회됐다 (GUID는 DC02의 DSA GUID → win-rfqoqtnhts0 → A 레코드까지 완전). 레코드는 살아났는데 replsummary는 계속 40% 실패 — 여기서 가능성은 둘이다.

  1. 네거티브 DNS 캐시: 조회 실패 시점의 “없음” 응답이 리졸버/DNS 서버 캐시에 남아, 복제 엔진이 캐시된 실패를 계속 받는 경우
  2. 단순히 재시도가 없었던 것: replsummary의 fails 카운트는 “마지막 시도” 기준이라, 실패 이후 새 복제 시도가 없으면 숫자가 그대로 남는다 (largest delta가 계속 늘고 있으면 이 경우)

어느 쪽이든 대응은 같다 — 캐시를 비우고 즉시 강제 복제로 재시도하면 두 가능성을 한 번에 해소하면서 결과를 바로 확인할 수 있다.

4-3. 해결 — 캐시 정리 + 강제 복제

# 캐시 정리 (실패한 쪽 DC에서)
ipconfig /flushdns            # 리졸버 캐시
Clear-DnsServerCache -Force   # DNS 서버 캐시

# 실패 중인 파티션 직접 강제 복제 (문법: repadmin /replicate <대상DC> <소스DC> <파티션>)
repadmin /replicate DC01 WIN-RFQOQTNHTS0 "CN=Schema,CN=Configuration,DC=azlab,DC=istn,DC=co,DC=kr"
repadmin /replicate DC01 WIN-RFQOQTNHTS0 "CN=Configuration,DC=azlab,DC=istn,DC=co,DC=kr"

결과:

Sync from WIN-RFQOQTNHTS0 to DC01 completed successfully.
Sync from WIN-RFQOQTNHTS0 to DC01 completed successfully.

repadmin /replsummary
Source DSA          largest delta  fails/total %%
 DC01                    01m:21s    0 /   5    0
 WIN-RFQOQTNHTS0         02m:46s    0 /   5    0     ← 완전 복구

참고: 실패 시각과 largest delta를 보면 어느 가설이 유력한지 가늠할 수 있다. 내 경우 delta가 51분째 계속 늘고 있었고, 캐시 정리 + 강제 복제 직후 즉시 성공한 것으로 보아 재시도 부재가 컸던 것으로 보인다.

5. 8524 트러블슈팅 요약 (치트시트)

1. repadmin /replsummary            → 실패 방향/파티션 파악
2. dcdiag 출력의 GUID CNAME 확보    → <GUID>._msdcs.<forest>
3. Resolve-DnsName <GUID CNAME>     → 조회되나?
   ├─ 안 됨 → 소스 DC에서 ipconfig /registerdns + Restart-Service Netlogon
   └─ 됨   → 캐시/재시도 문제 → flushdns + Clear-DnsServerCache 후 강제 복제
4. repadmin /replicate <대상> <소스> <파티션>  → 즉시 재시도
5. repadmin /replsummary → 0% 확인, dcdiag /q 마무리
6. (이름 변경이 원인이었다면) setspn -L <DC이름> → SPN이 올바른 호스트명 기준인지 확인

6. 재발 방지 — 스크립트에 가드를 넣자

이번 사고의 근본 원인은 “어느 창인지 확인하지 않고 붙여넣기”다. 사람의 주의력에 기대는 대신 스크립트가 스스로 거부하게 만들었다:

# 클라이언트 대상 스크립트 공통 헤더
if (Get-Service NTDS -ErrorAction SilentlyContinue) {
    Write-Host "이 머신은 도메인 컨트롤러입니다! 실행을 중단합니다." -ForegroundColor Red
    return
}
# + 대상 머신 화이트리스트(hostname 매핑)에 없으면 중단

교훈 정리:

  1. 원격/다중 머신 작업 전 hostname 확인은 습관이 아니라 절차로 만들 것 (스크립트 가드)
  2. DC 이름 변경은 netdom add → makeprimary → 재부팅 → remove 순서
  3. DC가 Domain Controllers OU를 벗어나면 정책 공백 — 발견 즉시 원위치
  4. 8524 = DNS 문제. GUID CNAME 체인을 확인하되, 레코드가 정상인데 실패가 유지되면 캐시 또는 재시도 부재 — 캐시 정리 + 강제 복제로 한 번에 해소
  5. DC 2대 + 클라이언트 보조 DNS 구성이 사고 시 생존성을 만든다

홈랩에서 저지른 사고였지만, 복구 과정에서 배운 것(netdom 절차, _msdcs 구조, repadmin 진단 흐름)은 운영 환경 장애 대응에 그대로 쓰이는 지식이다. 사고 한 번이 LAB 실습 몇 개 분량이었다.

Comments

You May Also Enjoy