티스토리 뷰

카테고리 없음

도메인 가입 PC의 시간 오차로 인증이 실패할 때 확인할 항목

생각방 2026. 10. 28. 22:51

목차


    도메인 계정으로 파일 서버에 접속하지 못할 때 비밀번호나 권한만 확인하면 시간 문제를 놓칠 수 있습니다. 특히 오류에 시계 차이가 언급된다면 PC와 인증에 사용되는 도메인 컨트롤러의 시각을 비교해야 합니다. 다만 인증 실패만으로 시간 오차를 원인으로 확정해서는 안 됩니다.

    PC와 인증서버 상대 시간 차이 비교

    화면의 시계보다 인증 상대와의 실제 차이를 확인

    Kerberos는 인증 메시지의 타임스탬프를 검증하므로 관련 컴퓨터의 시각이 맞아야 합니다. Microsoft가 안내하는 기본 허용값은 5분이지만, 실제 판단에는 도메인에 적용된 정책값을 확인해야 합니다. 이 값은 동기화 주기나 운영상 목표 오차를 뜻하지 않습니다. 시간 오차 허용 정책

    먼저 오류 문구, 발생 시각, 실패한 대상 서버를 기록합니다. 화면에 표시되는 현지 시각만 보지 말고 날짜·시간대와 상대 장비의 실제 시각 차이를 구분합니다. 시간대 표시가 다르다는 사실만으로 Kerberos 장애라고 판단하지 않습니다.

    관리자 권한 명령 프롬프트에서 아래 값을 수집합니다. 먼저 현재 상태를 남겨 두면 조치 후 무엇이 달라졌는지 비교할 수 있습니다.

    w32tm /tz
    w32tm /query /source
    w32tm /query /status
    w32tm /query /configuration

    source는 시간 원본, status는 최근 성공한 동기화 시각 등을 보여 줍니다. configuration은 실행 중인 설정과 설정 출처를 확인하는 데 씁니다. 출력 항목과 명령 의미는 공식 도구 문서에서 확인할 수 있습니다.

    요약: 화면의 시각과 시간 원본·최근 성공 기록을 함께 확인합니다.

    PC가 도메인 시간 계층을 따르는지 확인

    일반적인 도메인 구성에서 멤버 PC는 도메인 계층을 따라 시간을 받습니다. 포리스트 루트 도메인의 PDC 에뮬레이터는 이 계층의 상위 기준 역할을 합니다. 모든 PC가 PDC에 직접 접속하는 단일 구조로 이해하면 안 됩니다. 시간 서비스 동작 원리

    configuration에서 동기화 유형이 NT5DS인지 살펴보고 회사의 설계와 대조합니다. 의도하지 않은 수동 NTP 설정이나 로컬 시계 원본이 보이면 조사 대상입니다. 별도 시간 제품이나 정책을 쓰는 환경이라면 값이 다르다는 이유만으로 변경하지 않습니다.

    비교할 도메인 컨트롤러가 확인되면 다음 명령으로 오프셋을 관찰합니다. 아래 이름은 예시이므로 실제 점검 대상의 DNS 이름으로 바꿉니다.

    w32tm /stripchart /computer:dc01.example.com /dataonly /samples:5

    stripchart는 상대와의 차이를 관찰하는 도구이며 시계를 맞추는 명령이 아닙니다. 시간 원본인 DC와 실제 인증에 관여한 DC가 다르다면 양쪽을 확인합니다. Kerberos 점검 가이드도 관련 장비 사이의 시간 차이를 확인하도록 안내합니다.

    요약: 도메인 가입 여부와 실제로 선택된 시간 원본을 따로 확인합니다.
    상위 시간 기준 서버에서 도메인 컨트롤러와 PC로 이어지는 동기화

    한 PC의 문제와 여러 PC의 공통 문제를 나눠서 판단

    같은 도메인의 정상 PC와 결과를 비교하면 점검 범위를 줄일 수 있습니다. 아래 표는 원인 확정표가 아니라 다음 확인 대상을 정하는 기준입니다.

    관찰 결과 우선 확인할 대상
    한 PC만 오차가 크고 정상 PC는 같은 DC와 동기화됨 해당 PC의 W32Time 상태·유효 설정·최근 동기화 실패 기록
    여러 PC가 같은 원본을 사용하며 함께 어긋남 공통 원본 DC와 그 상위 시간 원본
    원본을 찾지 못하거나 측정이 시간 초과됨 대상 이름 해석·도메인 연결·UDP 123 경로
    오차가 해소됐지만 같은 인증이 계속 실패함 계정·DNS·대상 서비스 등 별도 인증 원인

    PC와 관련 DC의 시스템 로그에서 Time-Service 기록을 발생 시각과 대조합니다. 재택 단말이라면 필요한 도메인·시간 서버 경로가 VPN에서 제공되는지도 확인합니다. ping 성공만으로 NTP 통신이 가능하다고 결론내리지 않습니다.

    특히 stripchart는 임시 UDP 출발지 포트를 쓰지만 일반 W32Time 동기화는 UDP 123 출발지 포트를 사용합니다. 따라서 측정 성공이 실제 동기화 성공을 보장하지 않습니다. 방화벽·NAT 확인 시 이 차이를 반영합니다. 통신·명령 조건

    요약: 단말에서 시작하되 여러 대의 공통 증상이면 상위 원본으로 범위를 넓힙니다.
    메인 타임 서버의 시간이 달라지면 그에 연계된 모든 시스템의 시간이 틀어짐

    4. 재동기화 후 원본과 실제 인증을 다시 검증합니다

    회사 정책상 도메인 계층 사용이 맞고, 유효 설정과 통신 경로가 확인된 PC에서 재동기화를 요청합니다. 서비스가 중지되어 있다면 중지 이유와 관리 정책을 먼저 확인합니다.

    w32tm /resync /rediscover

    수동 원본 설정이 잘못된 것으로 확인된 일반 멤버 PC는 도메인 계층으로 복원할 수 있습니다. 이 경우 공식 절차의 domhier 설정과 W32Time 재시작을 적용하고 다시 동기화합니다. GPO가 관리하는 값이면 정책을 수정해야 하며, PDC에 단말용 설정을 그대로 적용하지 않습니다.

    조치 후 source와 status, 오프셋을 다시 확인한 뒤 처음 실패한 인증을 재시험합니다. 시간이 크게 어긋난 환경에서는 보정 제한 때문에 요청만으로 맞춰지지 않을 수 있습니다. 큰 오차 처리 문서를 참고해 관리자와 보정 방법을 결정합니다. 허용 오차를 늘려 증상을 감추는 방식은 복구 기준으로 삼지 않습니다.

    요약: 재동기화 후 시간 원본·최근 성공 시각·실제 오차를 확인하고, 처음 실패한 인증까지 다시 검증합니다.

    자주 묻는 질문

    재동기화에서 시간 데이터를 사용할 수 없다고 나오면 방화벽 문제인가요?

    그 메시지만으로 방화벽을 원인으로 확정할 수 없습니다. 원본 검색, 서비스 상태, 응답 제공 여부와 관련 로그를 함께 확인해야 합니다.

    PC끼리 시간이 같으면 정상인가요?

    여러 PC가 같은 잘못된 원본을 따라갈 수 있습니다. PC 간 일치뿐 아니라 DC의 상위 원본과 회사가 승인한 기준 시각도 확인해야 합니다.

    조치 후 곧바로 재부팅해야 하나요?

    재부팅을 일괄적인 첫 조치로 삼을 필요는 없습니다. 먼저 재동기화 결과와 실제 접속을 확인하고, 남은 증상에 따라 세션 재연결 등 후속 조치를 정합니다.

    결론

    제 판단으로는 이 문제의 복구 기준을 “시계를 한 번 맞췄다”에 두면 재발을 놓치기 쉽습니다. 시간 원본이 설계와 맞고, 최근 동기화가 성공했으며, 관련 장비의 오차가 줄고, 실패했던 인증이 다시 동작하는지까지 확인해야 합니다. 점검 이력에는 조치 전후의 원본·오프셋·성공 시각·인증 결과를 남기는 것이 좋습니다.

    참고자료