가상화된 Active Directory 인프라에서 정확한 시간 유지 보장

마이크로소프트 윈도우즈 워크로드를 가상화하려는 관리자에게 가장 일반적인 우려 사항 중 하나는 가상 환경에서 시간(또는 시계) 변동이 발생하는 것으로 잘 알려진 문제다. 현대적인 운영 환경에서 정확한 시간 유지가 매우 중요하다는 점을 고려할 때, 이는 정당한 우려 사항으로, 일부 관리자가 인프라에 가상화를 도입하고 채택하는 것을 막은 것이다.

최신 애플리케이션, 인증 및 인증 도구 및 프로토콜은 정확한 시간 유지를 기반으로 한다. 어떤 것들은 매우 엄격한 정확성을 요구하는 반면, 다른 것들은 일부 분산을 용인할 수 있다. 우리의 목적을 위해 우리는 마이크로소프트 Active Directory 도메인 서비스에서 구현된 Kerberos 프로토콜에 초점을 맞출 것이다.

윈도우즈 Active Directory 포리스트에 있는 클라이언트와 서버는 도메인 컨트롤러가 포리스트 내에서 적절한 보안 Kerberos 인증을 제공할 수 있도록 시간 동기화 및 최신 데이터베이스화가 필요하다. 윈도우즈의 Kerberos 버전 5는 인증 클라이언트와 도메인 컨트롤러 간에 기본 최대 허용오차가 5분이다. 이 값은 구성할 수 있지만 표준 Windows Administration and Security Practice는 이러한 모범 사례에서 벗어나는 것을 방지한다. 허용 범위 확장에 따른 가장 일반적인 보안 영향 중 하나는 악명 높은 “인Authentication Credentials Replay Attack”이다. 시간 유지 위생에 대한 주요 목표는 가능한 경우 특정 포리스트의 모든 장치, 클라이언트, 서버 및 도메인 컨트롤러가 동기화되거나 (최악의 경우) 5분 이상 이탈하지 않도록 하는 것이다.

Active Directory 도메인 서비스는 다음과 같이 나타낼 수 있는 기본 시간 동기화 계층을 제공한다.

위의 다이어그램에서 설명한 것처럼PDC Emulator Operations Master Role (PDCe)를 포리스트의 루트에 보관하는 도메인 컨트롤러는 포리스트에서 정확한 시간 유지를 보장할 책임이 있다. 포리스트의 모든 하위 도메인에 있는 다른 PDC 에뮬레이터에게 이 책임을 전가한다. 이러한 하위 PDCe는 각 도메인의 다른 도메인 컨트롤러와 책임을 공유한다. 이러한 다른 도메인 컨트롤러는 PDCe를 정확한 시간 동안 정기적으로 참조하고 이 정보를 도메인 가입 클라이언트로 전파한다. 따라서 루트 PDCe는 외부 신뢰할 수 있는 시간 소스와 동기화해야 하는 유일한 도메인 컨트롤러로, 엔터프라이즈의 다른 모든 사용자에게 Time-Keeping Marshall 역할을 한다. 루트 PDCe가 정상이고 외부 시간 소스로부터 시간 업데이트를 받는 한, 적어도 타임스탬프 관련 인증 관점에서 AD 인프라에서의 생활은 순탄하다.

만약 “무슨 일이 일어나면?” 루트 PDCe가 정확한 시간을 수신하지 못하는 경우? 만약 그것이 부정확한 시간을 받는다면? 만약 그것의 시계가 몇 가지 이유 때문에 삐뚤어지면 어떻게 될까?

도메인 컨트롤러가 물리적 서버에서 실행되는 물리적 환경에서, 왜곡된 시계의 가장 일반적인 원인은 불량 CMOS 배터리 때문이다. 이로 인해 서버의 EPROM에 저장된 시간이 부정확해질 수 있다. 다시 부팅하거나 시작할 때 서버가 이 잘못된 시간을 읽고 W32Time Service가 사용할 W32Time Service에 의해 저장된다. 시계가 어느 방향(앞으로 또는 뒤로)에서 48시간 이상 기울지 않는 한 PDCe는 신뢰할 수 있는 외부 소스로부터 정확한 시간을 받아 그에 따라 시계를 조정할 수 있을 것이다. 인생은 여전히 행복하다. 시계가 48시간 이상 꺼지고 동작을 제어하는 두 개의 레지스트리 키(MaxPosPhaseCorremation 및 MaxNegueCorremation)에서 이 기본값이 변경되지 않은 경우 Windows는 신뢰할 수 있는 소스로부터 정확한 시간을 받기 시작하더라도 잘못된 시간을 조정할 수 없게 된다. 순효과는 시간 동기화, 인증, 복제, 암호 만료 및 기타 심각한 문제가 환경에서 발생하는 것이다. 문제가 발견된 시기와 시정 조치가 얼마나 신속하게 이행되는지에 따라 복구는 비용이 많이 드는 행정 연습이 될 수 있다.

이러한 문제가 있는 시나리오는 가상화된 AD 인프라에서도 적용된다. 현대의 서버 하드웨어는 위에서 설명한 “Bad CMOS” 클럭 장애 시나리오와 자주 마주치지 않지만, 가상화된 PDCe는 어떤 이유로든 자신이 상주하는 ESXi 호스트가 가상 시스템에 잘못된 시간을 제공하면 장애가 발생한다.

그래, 그래, 네가 무슨 생각을 하는지 알아.

그러나 우리는 VM의 시계를 호스트와 동기화하지 않고 있으며, VMware의 KB 기사 Disabling Time Synchronization (1189)에 제공된 권장 사항을 읽고 구현했다.

적절한 아키텍처가 구축되었고 사전 예방적이었고 최적의 시간 동기화 옵션을 선택했으며 KB 1189에서 권장한 변경 사항을 적용했다는 점에 동의한다. 그러나 이러한 설정은 특정 VM 작동 시나리오를 다루기 위한 것임을 잊지 마십시오. ESXi 호스트와의 시간 동기화를 사용하지 않도록 설정하고 참조된 KB에서 VM 고급 구성 옵션을 구현하면 실제로 이러한 옵션의 용도에 맞게 작동하는 것이다. 나중에 다시 가겠지만, 이 생각을 마칠게…

KB 1189의 설정은 물리적 시스템의 시계에 영향을 미치는 호스트 EPROM 오류/오류 상황에 맞게 설계되지 않았다. 위에서 설명한 것처럼 호스트 클럭이 잘못된 경우 윈도우즈 VM이 재부팅되거나 해당 호스트에서 시작될 때 VM의 BIOS가 물리적 호스트에서 제공하는 잘못된 시간을 에뮬레이트하고 상속하며 VM의 윈도우즈 게스트 운영 체제가 이를 하드웨어 클럭으로 충실히 수용한다. VM이 루트 PDCe인 경우 위에 표시된 것과 동일한 장애가 포리스트에서 발생할 것이다.

다시 요약하기 위해 물리적 호스트의 시간 장애는 가상/하이퍼바이저 계층에 적용되는 방어 메커니즘이나 구성에 관계없이 가상화된지 여부에 관계없이 윈도우즈에 의해 상속된다.

그러면, 다른 환경들은 무엇을 할까?

물어봐 줘서 기뻐. KB 1189에서 언급한 바와 같이, 특정 VM 작업으로 인해 VMware Tools는 게스트 VM 내의 게스트 운영 체제 시간과 호스트 시간을 동기화하게 된다. 나는 이 작전들을 여기서 다시 열거하지 않을 것이다. 호스트에 잘못된 클럭이 있는 경우 VM 고급 구성 설정을 사용하지 않는 한 KB에 나열된 가상 시스템 작업을 수행할 때마다 vSphere 기반 VM이 잘못된 시간을 상속한다는 점을 간단히 말씀드리고자 한다. 이러한 설정을 사용하면 매일, 아무 걱정 없이, 하루 종일 이러한 모든 작업을 수행할 수 있다. VM의 전원을 켜거나 다시 시작하는 것은 “가상 시스템 작업”이 아님을 지금 여기서 언급해야겠습니다. 즉, 이러한 설정은 호스트 CMOS 시간/시계가 잘못된 상황에서 전원 이벤트 중에 VM이 물리적 서버처럼 동작하는 것을 막을 수 없다. 이 동작에 대한 자세한 설명은 Timekeeping in VMware Virtual Machines의 “Virtual CMOS RTC” 섹션을 참조하기 바란다.

그럼, 이제 어쩌지? 아무것도 아니야, 정말. 이 기록은 KB 1189의 권장 사항이 시간 왜곡이나 손상으로부터 보호할 수 없는 코너 사례 시나리오에 대해 독자와 모든 VM 및 AD 관리자에게 경고하기 위한 것이다. 그리고 이것이 가상화 부족이나 문제가 아니라는 사실을 강조하기 위해서다. 문제는 물리적 영역에도 존재한다. Microsoft는 Windows Administrator가 Active Directory 인프라 내에서 정확한 시간 유지를 가장 잘 보장하는 방법(예: Configuring Systems for High Accuracy)에 대한 몇 가지 지침 문서를 발표했다. 이 문서의 권장사항은 가상화의 여부와 상관없이 모든 윈도우즈 운영 체제 인스턴스에 적용된다.

요약:

• 호스트의 정확하고 정확한 시간 보관은 Active Directory 인프라의 가상화 여부와 관계없이 매우 중요하다. 잘못된 호스트 시계는 복잡한 복구 노력이 필요한 불안정을 유발할 수 있다.
• vSphere 인프라에서 VMware는 모든 호스트를 신뢰할 수 있는 시간 소스와 동기화할 것과 관리자가 정확성을 보장하기 위해 정기적인 시간 검사 프로세스를 구현할 것을 적극 권장한다.
• VM의 BIOS 시계는 다음 패턴에 따라 전원이 켜지거나 다시 시작될 때마다 호스트와 일치하도록 설정됨:
• 새로운 전원을 켤 때(즉, VM의 전원이 처음 켜질 때) 해당 BIOS는 호스트의 시간을 상속한다.
• 이후에 게스트는 BIOS 시계에 시간 정보를 다시 기록한다. 이동성을 위해 실제로 저장되는 것은 호스트 시간과의 오프셋이다.
  • VM BIOS Time = ESXi host time (UTC) + Offset
  • 따라서 윈도우즈 VM을 esxi에서 처음으로 부팅(정확한 utc 시간)하면 호스트 시간과 일치하는 초기 시간이 나온다고 가정해 봅시다. 그런 다음 W32Time은 외부 소스와 동기화되며 시간대를 PST로 조정한다고 말한다. 이후 윈도우가 다음과 같이 바이오스 시계에 다시 기록된다.
  • VM BIOS Time = ESXi host time (UTC) + -8:00(여기서 8:00은 PST에서 UTC로 오프셋됨)
  • 즉, 시간은 항상 UTC로부터 오프셋으로 저장되며, 따라서 ESXi를 NTP와 동기화하는 것이 중요한 것이다.
• 윈도우즈 게스트 운영 체제를 실행하는 VM에서 상속된 시간이 어느 방향으로든 48시간을 초과하여 치우치면 W32Time이 왜곡을 수정할 수 없음(그런 수정을 수용하도록 적절한 레지스트리 키 또는 그룹 정책을 조정하지 않은 경우)
• VM에서 KB 1189에 언급된 가상 시스템 작업 중 하나 이상이 수행되지 않는 한 상속된 시간은 VMware Tools에 의해 재설정되지 않는다.
• KB 1189에 나열된 VM 고급 구성 설정을 VM에 적용하지 않은 경우 VMware Tools는 가상 시스템 작업이 수행될 때 VM 시계를 호스트 시간과 동기화한다.
• 기본적으로 VMware Tools는 다음과 같은 경우를 제외하고 VM의 시계를 재설정하지 않는다.
  • KB 1189의 고급 구성 설정이 VM에 적용되지 않았으며
  • VM에는 다음과 같은 고급 구성 설정(KB 1189에 언급되지 않음)이 적용됨:
    • synchronize.restore.backward = TRUE
    • synchronize.resume.disk.backward = TRUE
    • synchronize.tools.startup.backward = TRUE
• Active Directory 포리스트의 시간 유지 요구 사항에서 Root PDC Emulator의 중요성 때문에 도메인 관리자가 vSphere 관리자와 협력하여 KB 1189에서 권장되는 설정을 모든 도메인 컨트롤러에 적용하여 가상 시스템 작업에 방해가 되지 않도록 하는 것이 중요하다. 운영 체제의 시간 유지 메커니즘.
• 호스트의 잘못된 시간으로 인해 가상화된 도메인 컨트롤러의 시계가 왜곡되는 경우 가장 빠른 해결 방법은 정상 시계가 있는 다른 호스트로 VM을 마이그레이션하고 VM을 다시 시작하는 것이다.

이 정보가 유용하다는 것을 알았으면 좋겠어. 이 게시물의 내용과 관련된 것은 언제든지 물어봐 줘. 수시로 체크인을 하고 적시에 대응하겠다고 약속한다.