Один из внешних серверов NTP (основной - в настоящее время), который мы используем в качестве источника, похоже, не отвечает на вызовы NTP. К сожалению, на нашем основном маршрутизаторе (Cisco 6509) функциональность NTP не переключилась на дополнительный внешний NTP-сервер, как ожидалось. В результате наш основной маршрутизатор, который является главным внутренним источником NTP, опаздывает на 2 минуты.

Я планирую исправить проблему с внешним маршрутизатором, сделав внешний источник NTP рабочим. Мне интересно, насколько 2-минутные изменения повлияют на моих пользователей и сервисы? Специально с тех пор мы в значительной степени полагаемся на аутентификацию на основе сертификатов.

Мы магазин Windows / Cisco.

Внутренняя настройка NTP:

[Базовый маршрутизатор 1 / Cisco 6509]:
наблюдение за двумя внешними NTP-серверами (в которых основной не отвечает на вызовы NTP)

[Core Router 2]:
синхронизация с Core router 1 (основной), рабочий внешний маршрутизатор (дополнительный)

[Другие сетевые устройства Cisco]:
синхронизация с основным маршрутизатором 1 (основным), основным маршрутизатором 2 (дополнительным)

[Контроллер (ы) домена]:
синхронизация с основным маршрутизатором 1

[Все клиенты / серверы Windows]:
синхронизация с контроллерами домена

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

Возможное исключение - если они объявят ваш NTP-сервер «безумным» в результате большого изменения (что потребует от вас перезапустить службу NTP в уязвимых системах, чтобы заставить их синхронизировать часы - хотя вы можете сделать это без отключение).

Пока вы исправляете это, вот несколько других указателей:

• Вы должны настроить свои системы, которые смотрят на внешние источники NTP, для просмотра нескольких (4-5) серверов из проекта общего пула NTP - предпочтительно географически соответствующих.
  Наличие большего количества серверов NTP позволяет алгоритму выбора игнорировать те, которые ломаются / сходят с ума и сохраняют ваши часы точными.

• В конфигурации, подобной вашей, я бы указывал Core Router 1и Core Router 2на внешние источники синхронизации (а не друг на друга).
  Это дает вам два независимо синхронизированных тактовых генератора, которые должны быть в пределах нескольких мс друг от друга, но если один из ваших маршрутизаторов сходит с ума, он не может повредить другому.

• В такой конфигурации, как ваша, я бы указывал контроллеры домена на ОБОИХ основных маршрутизаторах (опять же для защиты от одного отказа).
  Если вы хотите защитить себя от сумасшедших часов, вам следует добавить третий авторитетный NTP-сервер (или дважды перечислить один из ваших маршрутизаторов и надеяться, что он не сходит с ума…)

Настройки домена по умолчанию для Windows позволяют отключить время +/- 300 секунд, прежде чем перестает работать аутентификация, так что все будет в порядке. Вот довольно исчерпывающая статья на эту тему , в которой даже упоминается, как изменить допустимое отклонение от времени с помощью GPO на уровне домена. Это в Computer Configuration-> Policies-> Windows Settings-> Security Settings-> Account Policies-> Kerberos Policy-> Maximum tolerance for computer clock synchronization.

Тем не менее, ваш авторитетный источник времени (обычно это контроллер домена, выполняющий роль эмулятора PDC в домене Windows) синхронизируется с внешним ntpисточником, например pool.ntp.org. Больше информации от Technet, здесь .

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

РЕДАКТИРОВАТЬ: поскольку @ voretaq7 упомянул об этом, я должен отметить, что у нас только одна система видит внешний источник времени, наш эмулятор PDC. Все устройства, включая сетевое устройство, синхронизируются с ним. Мы считаем, что это лучшее решение, поскольку сетевой механизм не будет отклонять проверку подлинности из-за перекоса времени, но присоединенные к домену компьютеры, использующие Kerberos (что для нас все), будут. Таким образом, в этом отношении не особенно важно иметь точное время на нашем сетевом оборудовании, но это на наших системах Windows, вдвойне потому, что мы также запускаем наше программное обеспечение для учета рабочего времени для почасовых сотрудников на сервере Windows.

Клиенты Windows на самом деле не будут иметь проблем с входом в систему вообще. Описание Maximum tolerance for computer clock synchronizationполитики довольно неточно в наши дни.

Клиент с сильно неправильными часами получит ответ от сервера, устанавливающий перекос между его часами - аутентификация затем проходит нормально (клиент настраивается так, чтобы учесть очевидный перекос часов).

Описание верно в одном; политика по-прежнему эффективно устанавливает таймер для атак воспроизведения, но с точки зрения легитимного трафика связь устойчива к большим перекосам часов.

Смотрите эту статью MS KB для получения дополнительной информации.

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

Очевидно, вы не можете запланировать небольшое время простоя, не так ли? Я бы настаивал на простое, чтобы перезапустить службу ntp на всех затронутых серверах. Если это невозможно, вам придется подождать некоторое время.

(Я собирался сделать это комментарием к ответу vortaq7, но я думаю, что он заслуживает повторения само по себе, так как многие люди делают эту ошибку.)

Вам нужно как минимум 3 (предпочтительно 4-6) источника времени, чтобы алгоритм NTP точно сходился в нужное время. Если у NTP есть только два первичных источника, и они оба значительны, у NTP нет возможности узнать, какому из них доверять.

Самым большим подспорьем для меня в понимании этого была диаграмма на странице 9 проекта Sun «Использование NTP для управления и синхронизации системных часов, часть III: Мониторинг и устранение неполадок NTP». Этот документ исчез из поля зрения, когда Oracle купил Sun, но вы все равно можете найти его на Wayback Machine . Есть также много хитов в Интернете, если вы ищете по названию.