한 달 오프라인 후 도메인 트러스트가 끊겼나요? 먼저 확인하세요

노트북이 육 주 동안 VPN 밖에 있다가 돌아왔는데 사용자가 도메인 계정으로 로그인할 수 없다. 오류가 트러스트 관계를 언급하므로 누군가 컴퓨터 계정을 재설정하거나 사용자를 전체 터널링으로 강제하고, 문제는 사라진 것처럼 보인다. 두 조치 모두 무엇이 고장 났는지 증명하지 못했다. Windows 멤버는 일반적인 컴퓨터 암호 간격을 훨씬 넘겨 오프라인 상태로 있어도 자동으로 트러스트를 잃지 않으므로, 첫 번째 작업은 연결 도달 실패와 실제 비밀 불일치를 구분하는 것이다.

오류는 트러스트처럼 보이지만 세 가지 상태가 비슷하다

사용자는 캐시된 도메인 정보로 로그인할 수 있고, 워크스테이션이 도메인 컨트롤러를 찾지 못할 수도 있으며, 멤버와 도메인이 컴퓨터 계정에 대해 정말로 의견이 다를 수도 있다. 엄밀한 의미에서 끊어진 트러스트 관계는 세 번째뿐이다.

AD 복제 상태는 네 번째 관찰이며 이 워크스테이션과는 전혀 관계가 없다. 그것은 도메인 컨트롤러 간의 합의를 설명하며, 건강한 복제 대시보드는 이 컴퓨터의 로컬 비밀이 컴퓨터 계정과 일치한다는 것을 증명하지 않는다.

잘 알려진 30일 기본값은 변경 정책이지 오프라인 만료 기한이 아니다. Microsoft의 컴퓨터 계정 암호에 대한 설명은 조정된 변경 프로세스를 설명하며, 조직은 다른 간격을 구성할 수 있다.

VPN 아이콘은 보안 채널에 대해 아무것도 증명하지 않는다

어떤 테스트든 의미가 있으려면 먼저 연결이 도메인 서비스에 도달할 만큼 충분히 좋아야 한다. 즉 의도한 도메인 DNS 확인자, 찾을 수 있는 컨트롤러, 도달 가능한 인증 서비스, Kerberos에 충분히 가까운 시계가 필요하다.

전체 터널링은 여기서 충분히 타당한 설계일 수 있다. 분할 터널링으로 바꾸는 것은 건강한 도메인 관계의 전제 조건이 아니며, 그렇게 취급하면 진단이 아키텍처 변경으로 바뀐다. 워크스테이션이 실제로 어느 컨트롤러를 선택하는지 확인하고, 그 이름을 오류와 함께 남겨라.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

DNS 서버, 확인된 컨트롤러, 오류의 정확한 문구를 기록하라. 연결되었다고 보고하는 VPN 클라이언트는 터널이 존재한다는 것을 알려줄 뿐, 도메인 경로가 작동한다는 것을 알려주지 않는다. Kerberos 포트에는 응답하지만 디렉터리 포트에는 응답하지 않는 컨트롤러는 방화벽 소견이지 트러스트 소견이 아니다.

복구하기 전에 멤버를 테스트하라

권한이 있는 Windows 도메인 멤버에서 Test-ComputerSecureChannel -Verbose는 컴퓨터와 도메인 사이 채널에 대한 읽기 전용 점검이다. 조사 중인 컴퓨터의 맥락에서 실행하고, 다른 역할과 다른 복구 규칙을 가진 도메인 컨트롤러에서 실행하지 마라. 통과 또는 실패라는 단어 대신 출력과 종료 상태를 기록하라. 해당 빌드에 cmdlet이 없다면 모듈은 별개의 문제다.

결과에는 여전히 맥락이 필요하다. 컴퓨터가 선택된 컨트롤러에 도달하거나 인증할 수 없다면, 실패한 테스트는 오프라인 암호가 만료되었다는 독립적 증거가 아니다. 실제 오류와 사용한 컨트롤러를 남기고, 경로가 알려진 정상이 된 뒤 테스트를 반복하라.

사고 전후의 멤버와 관련 컨트롤러에서 Netlogon 이벤트를 연관 지어라. 컴퓨터 이름, 원본 주소, 시간, 계정 변경의 모든 증거를 보존하라. 다른 사용자의 성공적인 로그인이나 건강한 컨트롤러 대시보드는 이 컴퓨터의 교환을 대신할 수 없다.

증명한 관계만 복구하라

연결이 안정되고 관리자가 복구가 적절하다고 확인하면, 권한 있는 자격 증명을 사용한 cmdlet의 -Repair 모드는 멤버 워크스테이션에서 지원되는 작업 중 하나다. 그것은 관계를 변경하며, 또 하나의 읽기 전용 테스트가 아니다.

변경 전에 승인된 로컬 복구 계정과 관리 경로를 준비하라. 도메인 컨트롤러는 복구 역할이 다르며 이 절차에서 일반 워크스테이션으로 취급해서는 안 된다. 여러 재설정 도구를 연달아 실행하며 그중 하나가 맞기를 바라기보다 조직의 복구 워크플로를 사용하라.

복구 후 새 보안 채널 테스트와 원래 도메인 작업을 검증하라. 사용자 프로필과 애플리케이션 상태를 보존하고, 제거 후 다시 참가를 첫 번째 설명되지 않는 조치로 만들지 마라.

실패가 다시 나타날 때 확인할 것

실패가 다시 나타나면 같은 계정을 또 재설정하는 대신 롤백, 중복 ID, 계정 변경 시점을 살펴보라. 복원된 이미지, 스냅숏, 복제된 컴퓨터 ID, 다른 곳에서 수행된 컴퓨터 계정 재설정은 모두 조사할 가치가 있다.

일시적으로 성공한 재설정은 유용한 복구 증거이지만, 간헐적인 VPN이 원래 불일치를 일으켰다는 증거는 아니다. 원인이 실제로 제거되었는지는 다음 발생이 알려준다.

컨트롤러, DNS 서버, 테스트 출력을 티켓에 적어라. 그 기록이 진짜 트러스트 실패와 도메인을 찾지 못한 노트북을 구분한다.