Windows: 워크스테이션과 주 도메인 간 트러스트 관계 실패(1789, trust relationship failed)

안녕하세요, BlueByte입니다. 월요일 아침 사용자가 로그온하려는데 Windows가 The trust relationship between this workstation and the primary domain failed.라고 답합니다. 사용자 암호도 맞고 네트워크도 정상이고 주말 동안 아무도 이 PC를 건드리지 않았습니다. 적어도 그렇게 보입니다. 도메인 쪽이 고장 난 것도, 데이터가 사라진 것도 아닙니다. 컴퓨터 자신의 계정 암호가 Active Directory와 어긋났을 뿐입니다. 오늘은 보안 채널이 무엇인지, 그것이 끊어지는 세 가지 경로, 확인하는 명령, 재가입 없이 한 줄로 끝나는 복구, 그리고 재발을 막는 법까지 하나씩 짚어보겠습니다.

메시지의 뜻: 더 이상 맞지 않는 컴퓨터 계정 암호

도메인에 가입한 컴퓨터는 저마다 Active Directory에 자기 계정과 암호를 갖고 있고, Netlogon 서비스는 사용자를 인증하기 전에 이것으로 도메인 컨트롤러와 보안 채널을 먼저 맺습니다. 이 대화상자 뒤의 Windows 오류는 ERROR_TRUSTED_RELATIONSHIP_FAILURE, 1789(0x6FD)입니다. 기본값으로 컴퓨터가 30일마다 새 암호를 제출하고("Domain member: Maximum machine account password age" 정책) DC가 그것을 기록합니다. 나중에 머신이 DC가 본 적 없는 암호를 내밀면 채널을 맺을 수 없고, 모든 도메인 로그온이 이 대화상자에서 멈춥니다. 랜선을 뽑으면 같은 사용자가 여전히 로그온된다면, 그것은 캐시된 자격 증명이지 살아 있는 트러스트가 아닙니다.

가까운 사촌으로 The security database on the server does not have a computer account for this workstation trust relationship.가 있습니다. ERROR_NO_TRUST_SAM_ACCOUNT, 1787(0x6FB)입니다. 이건 계정 자체가 없어졌다는 뜻이고, 해결법이 다릅니다.

암호가 어긋나는 세 가지 경로: 스냅샷, 복제본, 리셋된 계정

머신이 예전 상태로 되돌아갔다. VM 스냅샷, 백업 복원, 비영구 이미지는 캡처 시점 이후에 기록된 모든 것을 버립니다. 머신 암호 변경도 포함해서요. 비영구 VDI에 관한 Microsoft 안내가 분명히 말합니다. "a password change that was made during normal operations would be lost as soon as the session ends." DC에는 새 암호가, 되돌린 머신에는 옛 암호가 남습니다.

같은 이름의 복제본이 가입했다. 컴퓨터 계정 하나를 두 설치본이 나눠 쓰면 암호를 두고 싸웁니다. 정책 문서는 계정을 공유하지 말고 "give the two installations different computer names"라고 안내합니다. 가장 최근에 가입한 쪽이 이기고 다른 머신은 잠깁니다.

누군가 AD에서 계정을 리셋하거나 삭제했다. Active Directory Users and Computers의 "Reset Account"는 계정에 알려진 암호를 다시 넣고, 삭제하면 1789 대신 1787이 납니다.

버려도 되는 통념 하나. 몇 달 동안 꺼져 있던 머신은 이 이유로 깨지지 않습니다. 변경을 시작하는 쪽은 DC가 아니라 컴퓨터이고, 문서는 이 정책이 "stockpile pre-built computers that are put into production months later" 하는 조직이 재가입 없이 쓰라고 만든 것이라고 설명합니다.

먼저 보안 채널이 정말 끊겼는지 확인하기

로컬 관리자 계정(.\Administrator 또는 로컬 admin)으로 로그온하고, PowerShell을 관리자 권한으로 열어 Netlogon에 직접 물어봅니다:

Test-ComputerSecureChannel -Verbose

VERBOSE: Performing operation "Test-ComputerSecureChannel" on Target "WS-042".
False

False면 끊긴 것이 확인됩니다. nltest는 같은 결과에 상태 코드를 붙여 보여 주므로 1789와 1787을 가릴 수 있습니다:

nltest /sc_query:corp.example.com

정상 머신은 Trusted DC Connection Status Status = 0 0x0 NERR_Success를 출력합니다. 그 외는 모두 끊김이고, 거기 적힌 코드가 원인입니다. RSAT이 설치돼 있으면 DC가 기억하는 암호 변경 시각을 스냅샷이나 복원 날짜와 비교해 보세요:

Get-ADComputer WS-042 -Properties PasswordLastSet | Select-Object Name, PasswordLastSet

Name    PasswordLastSet
----    ---------------
WS-042  2026-09-14 08:12:41

PasswordLastSet이 스냅샷보다 나중이면 그것으로 설명이 끝납니다. DC는 변경을 봤는데 머신은 더 이상 기억하지 못하는 것입니다.

해결 1: 재가입 없이 그 자리에서 채널 복구하기

cmdlet 하나가 채널을 다시 세웁니다. 로컬 관리자 권한과, 컴퓨터 암호를 리셋할 권한이 있는 도메인 계정이 필요합니다:

$cred = Get-Credential CORP\svc-join
Test-ComputerSecureChannel -Repair -Credential $cred -Verbose

VERBOSE: Performing operation "Test-ComputerSecureChannel" on Target "WS-042".
True

-Repair는 문서대로 "removes and then rebuilds the channel established by the NetLogon service" 합니다. nltest /sc_reset이 하는 일과 같습니다. 새 암호를 명시적으로 설정하고 싶다면 형제 cmdlet이 그 일을 하고, 성공하면 아무것도 출력하지 않습니다:

Reset-ComputerMachinePassword -Server dc01.corp.example.com -Credential CORP\svc-join

로그아웃했다가 도메인 계정으로 다시 로그온하세요. cmdlet 문서에 재시작 요구는 없습니다. 컴퓨터의 정체성은 그대로이고 암호만 바뀌었으므로 프로필도 그대로입니다.

해결 2: 계정이 없어진 경우(1787)에는 도메인에 다시 가입하기

리셋으로는 삭제된 계정을 되살릴 수 없으니 이 경우는 탈퇴 후 재가입입니다. 2024년 8월부터 도메인 가입 보안 강화로 -Server에는 DC의 FQDN을 써야 합니다:

$cred = Get-Credential CORP\svc-join
Remove-Computer -UnjoinDomainCredential $cred -WorkgroupName WORKGROUP -Force -Restart
# 재부팅 뒤 로컬 관리자로:
Add-Computer -DomainName corp.example.com -Server dc01.corp.example.com -Credential $cred -Restart

Add-Computer는 "creates a domain account if the computer is added to the domain without an account" 하므로 객체가 같은 이름으로 돌아옵니다. Remove-Computer가 비활성화할 계정을 찾지 못해 오류를 내면 계정이 이미 없는 것이니, 재시작 뒤 Add-Computer로 그대로 진행하세요. 도메인 프로필도 살아남습니다. 도메인 SID는 바뀌지 않아 C:\Users\jane이 같은 계정에 다시 매핑됩니다.

실제 사례: 월요일 암호 변경을 덮어쓴 스냅샷 롤백

회계용 VM에 소프트웨어 업그레이드를 앞두고 9월 5일 스냅샷을 찍었습니다. Netlogon은 9월 14일 08:12에 머신 암호를 교체했고, 업그레이드가 15일에 실패해 VM을 스냅샷으로 되돌렸습니다. 월요일 로그온에서 1789 대화상자가 떴습니다. Get-ADComputer가 보여 준 PasswordLastSet은 9월 14일, 스냅샷보다 9일 뒤였고 그것으로 전부 설명됐습니다. 관리자는 로컬 관리자로 로그온해 Test-ComputerSecureChannel -Repair -Credential CORP\svc-join을 실행했고, True를 받았고, 사용자는 다음 시도에서 로그온했습니다. 5분이 안 걸렸고 재가입도 프로필 이전도 없었습니다.

끝까지 확인하고 다시 어긋나지 않게 하기

어느 쪽으로 고쳤든 그 머신에서 도메인 계정으로 로그온해 확인합니다:

Test-ComputerSecureChannel
nltest /sc_query:corp.example.com

True와 NERR_Success가 같이 나오면 채널이 살아 있는 것입니다. 재발을 막으려면, 도메인에 가입한 VM을 머신 암호 수명보다 오래된 스냅샷으로 절대 되돌리지 말고 30일 지난 스냅샷은 정리하세요. 골든 이미지나 오래 둘 스냅샷을 찍기 전에는 nltest /sc_change_pwd:corp.example.com으로 새 암호를 강제해 캡처된 상태를 최신으로 만드세요. 복제본은 sysprep으로 각자 이름과 계정을 갖게 하세요. 비영구 VDI라면 "Domain member: Disable machine account password changes" 정책을 그 이미지에만 적용하고, 문서가 권하는 대로 암호 변경을 유지보수 시간에 넣으세요.

"no logon servers"·도메인 컨트롤러의 경우와 어떻게 다른가

There are currently no logon servers available to service the logon request(1311)는 도달성 문제입니다. DNS나 네트워크가 DC를 찾지 못하는 것이고 트러스트는 멀쩡하니 이름 해석부터 고치세요. 오류 1787은 위의 계정 삭제 사례이고 재가입이 필요합니다. 그리고 오류를 보이는 머신이 도메인 컨트롤러 자신이라면 Test-ComputerSecureChannel을 쓰지 마세요. 문서는 DC에서 "returns false positive errors" 한다고 밝히고 있으니 Microsoft의 DC 절차대로 netdom resetpwd /s:<other DC> /ud:CORP\admin /pd:*를 쓰세요. 다음에 이 대화상자를 만나면 AD를 건드리기 전에 로컬 admin으로 Test-ComputerSecureChannel -Verbose부터 실행해 보세요. 한 줄짜리 복구로 끝날지 한 단어로 알려 줍니다.