Один із зовнішніх серверів NTP (основний - зараз), який ми використовуємо як джерело, схоже, не відповідає на дзвінки NTP. На жаль, на нашому основному маршрутизаторі (Cisco 6509) функціональність NTP не перейшла на вторинний зовнішній сервер NTP, як очікувалося. Як результат, наш основний маршрутизатор, який в основному є нашим основним внутрішнім джерелом NTP, затримується на 2 хвилини.

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

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

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

[Core Router 1 / Cisco 6509]:
пошук двох зовнішніх серверів NTP (в яких основний не відповідає на дзвінки NTP)

[Основний маршрутизатор 2]:
синхронізація з основним маршрутизатором 1 (основний), робочим зовнішнім маршрутизатором (вторинним)

[Інші мережеві пристрої Cisco]:
синхронізація з маршрутизатором Core 1 (основний), основний маршрутизатор 2 (вторинний)

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

[Усі клієнти / сервери Windows]:
синхронізація з контролерами домену

Якщо надзвичайно точна тривалість часу не є критичною для вас, не повинно бути помітного ефекту для ваших користувачів, окрім того, що їх годинник змінюється на 2 хвилини.

Можливий виняток, якщо вони оголосять ваш NTP-сервер "божевільним" внаслідок великої зміни (що вимагатиме від вас перезапустити службу NTP на постраждалих системах, щоб змусити синхронізувати годинник, хоча ви можете це зробити без відключення).

Хоча ви виправляєте це, ось декілька інших покажчиків:

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

• У такій конфігурації я би вказував Core Router 1і Core Router 2на зовнішні тактові джерела (не один на одного).
  Це дає вам два незалежно синхронізованих тактових годин, які повинні знаходитись в межах декількох мс один від одного, але якщо один з ваших маршрутизаторів втратить розум, він не може зашкодити іншому.

• У такій конфігурації я хотів би вказати контролери домену на ОСНОВНІ маршрутизатори BOTH (знову ж таки, щоб захистити їх від пониження).
  Якщо ви хочете захиститись від божевільних годин, вам слід додати третій авторитетний сервер 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 тут .

А у відповідь на іншу відповідь це не потребує простоїв. Просто вкажіть своє авторитетне джерело часу, а решта комп'ютерів, що приєдналися до домену, також синхронізуються.

EDIT: оскільки @ voretaq7 згадував про це, я повинен зазначити, що у нас є лише одна система, яка бачить зовнішнє джерело часу, наш емулятор PDC. Усі пристрої, включаючи мережеві передачі, синхронізуються з ним. Ми вважаємо це кращою домовленістю, оскільки мережевий механізм не відхилить автентифікацію через перекос часу, але комп'ютери, що приєдналися до домену, які використовують Kerberos (це все для нас). Тому в цьому плані не особливо важливо мати точний час на нашій мережевій передачі, але це в наших системах Windows, вдвічі, тому що ми також запускаємо своє програмне забезпечення для зберігання часу на працівників на сервері Windows.

Клієнти Windows насправді не матимуть жодних проблем із входом у систему. Опис Maximum tolerance for computer clock synchronizationполітики в ці дні є досить неточним.

Клієнт із сильно неправильним годинником отримає відповідь від сервера, встановивши перекос між їхніми годинниками - тоді аутентифікація проходить нормально (коли клієнт налаштовує себе на облік явного перекосу годинника).

Опис правильний про одне; політика все ще ефективно встановлює таймер для повторних атак - але, з точки зору законного трафіку, комунікація є надійною проти великих скатів годинника.

Додаткову інформацію див. У цій статті MS KB .

Ви можете поглянути на інший сервер (-ів) NTP, ніж на основне обладнання cisco: серйозний трафік NTP дає велике навантаження на процесор на обладнання cisco, що може призвести до проблем з мережею.

Очевидно, ви не можете запланувати невеликий час простою, чи не так? Я б наполягав на простої, щоб перезапустити службу ntp на всіх постраждалих серверах. Якщо це неможливо, то доведеться почекати деякий час.

(Я збирався зробити це коментуванням відповіді vortaq7, але я думаю, що це заслуговує на повторення саме по собі, оскільки багато людей роблять цю помилку.)

Вам потрібно щонайменше 3 (бажано 4-6) джерел часу для алгоритму NTP для точного зближення в потрібний час. Якщо у НТП є лише два первинних джерела, і обидва вони значну кількість, НТП не може знати, якому з них можна довіряти.

Найбільша допомога мені в розумінні цього була діаграма на сторінці 9 креслення ВС "Використання NTP для управління та синхронізації системних годин, частина III: Моніторинг та усунення несправностей з NTP". Цей документ зник з виду, коли Oracle придбав Sun, але ви все ще можете його знайти на машині Wayback . Якщо ви шукаєте заголовок, в Інтернеті також є багато звернень.