Подробный гайд: Решение синхронизации времени в Active Directory (AD) — одна из самых критичных

Разница в 5 секунд между контроллером домена и сетью — признак сбоя NTP или гипервизора. Настройте правильную синхронизацию времени в Active Directory.

2026.07.25                  


Подробный гайд: Решение синхронизации времени в Active Directory (AD) — одна из самых критичныхПодробный гайд: Решение синхронизации времени в Active Directory (AD) — одна из самых критичных Тема синхронизации времени в Active Directory (AD) — одна из самых критичных. Хотя протокол аутентификации Kerberos по умолчанию допускает рассинхронизацию до 5 минут, разница даже в 5 секунд между контроллером домена (DC) и другими устройствами является «желтым флагом». Сама по себе она не обрушит домен, но она указывает на нарушение иерархии синхронизации, проблемы виртуализации или сбои службы времени, что в перспективе может привести к серьезным сбоям.


Часть 1. Почему разница в 5 секунд — это проблема?

1. Нарушение иерархии времени:

В AD время должно распространяться строго по иерархии. Если вы видите стабильную разницу в несколько секунд, это почти всегда означает, что устройство синхронизируется не с тем источником (например, виртуальная машина берет время от хоста, а не от домена).


2. Проблемы с кластеризацией и специфичным ПО:

Такие системы, как MS SQL Server (AlwaysOn), Exchange, SCCM или кластеры файловых серверов, требуют высокой точности времени. Рассинхронизация в несколько секунд может вызывать сбои кворума или ошибки репликации баз данных.


3. Координация логов (Log Correlation):

При расследовании инцидентов (Security) разница в 5 секунд делает невозможным точное построение цепочки событий между контроллером домена и рабочими станциями.


4. Накопление дрейфа (Time Drift):

Если разница составляет 5 секунд сегодня, завтра она может составить 15 секунд, а через неделю — превысить порог в 5 минут, что мгновенно сломает аутентификацию Kerberos.


Часть 2. Правильная иерархия времени в Active Directory

Прежде чем чинить, нужно понимать, как время должно течь в сети:

  1. Корневой контроллер домена (владелец роли PDC Emulator) — синхронизируется с внешним источником времени (внешний NTP-сервер в интернете или аппаратные часы Stratum 1).
  2. Остальные контроллеры домена (DC) — синхронизируются только с PDC Emulator (или другими DC в домене).
  3. Рядовые серверы и рабочие станции (клиенты) — синхронизируются с любым доступным контроллером домена.

Никакое устройство не должно синхронизироваться с BIOS/CMOS или с хостом виртуализации, если оно является членом домена.


Часть 3. Диагностика: как найти источник рассинхронизации

Откройте PowerShell или CMD от имени администратора на проблемном устройстве и выполните следующие команды:

1. Проверка текущего статуса службы времени:

w32tm /query /status

Обратите внимание на строки Stratum (должен быть > 1, если это не корневой DC), Source (источник, с которого берется время) и Last Successful Sync Time.


2. Проверка источников (пиров):

w32tm /query /peers

Показывает, к каким серверам устройство пытается подключиться.


3. Точное измерение дрейфа (разницы во времени):

w32tm /stripchart /computer:<Имя_Контроллера_Домена> /samples:5 /dataonly

Эта команда 5 раз опросит контроллер домена и покажет точную разницу в миллисекундах. Если разница стабильно держится на уровне ~5000 мс (5 секунд), проблема в настройках. Если она постоянно растет (1с, 2с, 3с...) — проблема в аппаратных часах или гипервизоре.


Часть 4. Пошаговое устранение проблемы

Шаг 1. Настройка корневого контроллера домена (PDC Emulator)

Сначала нужно найти, какой DC держит роль PDC Emulator.

Выполните на любом DC:

netdom query fsmo

Зайдите на сервер, указанный в строке PDC, и настройте его на синхронизацию с внешним NTP (например, российским пулом ru.pool.ntp.org):

# Останавливаем службу времени
net stop w32time

# Настраиваем внешние NTP-серверы и помечаем сервер как надежный источник времени
w32tm /config /manualpeerlist:"0.ru.pool.ntp.org 1.ru.pool.ntp.org 2.ru.pool.ntp.org" /syncfromflags:manual /reliable:yes /update

# Запускаем службу времени
net start w32time

# Принудительно синхронизируем время
w32tm /resync

Шаг 2. Настройка остальных контроллеров домена

На всех остальных DC время должно браться от доменной иерархии.

Выполните на них:

net stop w32time
# Сбрасываем настройки к доменным по умолчанию
w32tm /config /syncfromflags:domhier /reliable:no /update
net start w32time
w32tm /resync

Шаг 3. Настройка рядовых серверов и рабочих станций

Обычно они делают это автоматически.

Если на конкретном ПК/сервере разница в 5 секунд сохраняется, выполните на нем:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /resync

Часть 5. Главная причина стабильной разницы в 1-10 секунд: Виртуализация

Если вы перепробовали всё, а разница в 5 секунд остается стабильной (не растет, а просто всегда равна 5 секундам), в 90% случаев виновата гипервизор (Hyper-V или VMware).

Виртуальные машины по умолчанию синхронизируют своё время с физическим хостом. Если хост рассинхронизирован с доменом, виртуалка будет иметь ту же разницу.


Как исправить для Hyper-V:

  1. Откройте Hyper-V Manager.
  2. Выберите виртуальную машину -> Settings (Параметры).
  3. Перейдите в Integration Services (Службы интеграции).
  4. Снимите галочку с Time synchronization (Синхронизация времени).
  5. Внутри гостевой ОС (Windows) выполните команду w32tm /resync, чтобы она забрала правильное время от контроллера домена.

Как исправить для VMware vSphere / ESXi:

  1. Выключите виртуальную машину.
  2. Edit Settings -> VM Options -> VMware Tools.
  3. Снимите галочку с Synchronize guest time with host (Синхронизировать время гостя с хостом).
  4. Включите машину и внутри ОС выполните w32tm /resync.

Примечание:

Хосты виртуализации (сами ESXi или Windows Server с ролью Hyper-V) должны синхронизироваться с внешним NTP-сервером на уровне своего hypervisor/BIOS, а не от домена, если они не являются членами домена.


Часть 6. Чек-лист

1. Батарейки CMOS:

Если рассинхронизация происходит на физических серверах после перезагрузки и время сбрасывается на несколько лет/секунд назад — замените батарейку CR2032 на материнской плате.


2. Брандмауэр:

Убедитесь, что на контроллерах домена и клиентах открыт UDP порт 123 (NTP). Если порт закрыт, служба времени будет брать время из BIOS, что вызовет дрейф.


3. Мониторинг:

Настройте мониторинг (Zabbix, SCOM, PRTG) на проверку Event ID 37, 142, 143, 5719 в журнале System (Система) на контроллерах домена. Эти события прямо указывают на сбои синхронизации времени.


4. Региональные пулы NTP:

Используйте только региональные пулы (например, ru.pool.ntp.org или pool.ntp.org), чтобы избежать задержек сети при опросе серверов на другом континенте.


Важно

Разница в 5 секунд не является фатальной для базовой работы Kerberos, но это симптом нарушенной архитектуры. Убедитесь, что PDC Emulator смотрит во внешний NTP, остальные машины смотрят на PDC Emulator, а в настройках виртуализации отключена синхронизация времени гостевых ОС с хостом.


Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.


Статью подготовил: Денис Аверко @Nymexis г. Омск

Комментарии

Загрузка...
Если комментарии не загружаются, можете попробовать отключить блокировщик рекламы для этого сайта