Синхронизация времени Windows Server 2008 с сервером времени

Синхронизация времени Windows Server 2008 с сервером времени

Приветствую.
Имеется сервер визуализации (машина с установленной Windows Server 2008). Необходимо синхронизировать ее время с временем специального сервера точного времени (ССВ-1Г), который имеет IP-адрес 10.1.1.81

Сделал следующее:
w32tm /config /syncfromflags:manual /manualpeerlist:10.1.1.81
w32tm /config /update
net time /setsntp:10.1.1.81
net stop w32time && net start w32time
w32tm /resync

после этого получаю сообщение в командной строке "Синхронизация не выполнена, поскольку нет доступных данных о времени
"
также если использовать стандартными настройками даты и времени Windows для синхронизации по адресу 10.1.1.81, то ничего не получается.

Что нужно сделать чтобы заработало?

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Синхронизация времени с внешним NTP сервером в Windows Server 2008 R2
Доброго времени суток. Подскажите решение проблемы. Суть в том, что на домен контроллере (DC) часы.

Windows Server 2008 R2 синхронизация времени с сервером ntpd в локальной сети
Не работает синхронизация времени в WS 2008 R2. Настройки прилетают от dhcp-сервера на linux, на.

Синхронизация времени Windows server 2003
Подскажите, что может быть Каждые полчаса сервер выдает такие ошибки: NTP-клиент поставщика.

Синхронизация времени клиентов с сервером
Приветствую. Есть такая задача. "Пляшут" часики у меня на клиентах. Клиенты в основном на ХР, но.

Сообщение от turpal1988

1. Проверить (на настраиваемом сервере), что этот ntp сервер доступен:

Сообщение от turpal1988

Странный вопрос. От ntp-клиента к ntp-серверу (10.1.1.81), никакие фарволы и т.п., не должны блокировать UDP порт 123

Вы протестировали доступность 10.1.1.81 с клиента?

Проверил введя команду w32tm /monitor /Computers:10.1.1.81 в командную строку. Получил ответ:
10.1.1.81 [10.1.1.81:123]:
ICMP: 0ms задержка
NTP: +184.2651750s смещение относительно локального времени
RefID: ‘GPS [0x00535047]
Страта: 1

После этого попробовал выполнить net time \10.1.1.81 /set, получил ответ:
Служба не запущена.

Не понимаю чего не хватает для запуска.
еще в реестре HKLMSystemCurrentControlSetservicesW32TimeTimeProviders NtpClient выставил значение Enabled=1, так как если я правильно понимаю мой комп — это клиент для сервера точного времени

Добавлено через 38 минут
также зашел в консоль редактора локальной групповой политики — конфигурация компьютера — Система — Служба времени Windows. Там все три значения установлены как "not configured" (у меня в русскоязычной версии "Не задана")
Нужно задать "NTP клиент" что ли??

Добавлено через 1 минуту
также проверил еще здесь HKLMSystemCurrentControlSetServicesW32TimeParameters — тип синхронизации установлен NTP

Добавлено через 18 минут
В общем при текущих настройках описанных выше синхронизация не работает.
мыслей как заставить ее работать пока нет.
если кто сталкивался с подобным — буду благодарен за помощь

Сообщение от turpal1988

Сверьте свои настройки со всеми этими пунктами:

И для проверки всех настроек:

запрос w32tm /query /source -ответ -Local CMOS Clock

C:UsersАдминистратор>w32tm /query /computer:localhost /configuration
[Настройка]

EventLogFlags: 2 (Локально)
AnnounceFlags: 5 (Локально)
TimeJumpAuditOffset: 28800 (Локально)
MinPollInterval: 10 (Локально)
MaxPollInterval: 15 (Локально)
MaxNegPhaseCorrection: 4294967295 (Локально)
MaxPosPhaseCorrection: 4294967295 (Локально)
MaxAllowedPhaseOffset: 1 (Локально)

FrequencyCorrectRate: 3 (Локально)
PollAdjustFactor: 5 (Локально)
LargePhaseOffset: 50000000 (Локально)
SpikeWatchPeriod: 900 (Локально)
LocalClockDispersion: 10 (Локально)
HoldPeriod: 5 (Локально)
PhaseCorrectRate: 1 (Локально)
UpdateInterval: 5000 (Локально)

NtpClient (Локально)
DllName: C:Windowssystem32w32time.dll (Локально)
Enabled: 1 (Локально)
InputProvider: 1 (Локально)
AllowNonstandardModeCombinations: 1 (Локально)
ResolvePeerBackoffMinutes: 15 (Локально)
ResolvePeerBackoffMaxTimes: 7 (Локально)
CompatibilityFlags: 2147483648 (Локально)
EventLogFlags: 1 (Локально)
LargeSampleSkew: 3 (Локально)
SpecialPollInterval: 10 (Локально)
Type: NTP (Локально)
NtpServer: 10.1.1.81 (Локально)

NtpServer (Локально)
DllName: C:Windowssystem32w32time.dll (Локально)
Enabled: 1 (Локально)
InputProvider: 1 (Локально)
AllowNonstandardModeCombinations: 1 (Локально)

VMICTimeProvider (Локально)
DllName: C:WindowsSystem32vmictimeprovider.dll (Локально)
Enabled: 0 (Локально)
InputProvider: 0 (Локально)

сверил все настройки, перейдя по указанной ссылке..осталось непонятно как выставить значение NTPServer
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32Time TimeProviders. — там несколько значений в папке NTPServer. в каком ключе я должен указать как миниму 3 NTP сервера? и почему 3 если у меня он 1? Указывать как 0х10.1.1.81 ??

Добавлено через 7 минут
вот ответ на запрос w32tm /query /status:

C:UsersАдминистратор>w32tm /query /status
Индикатор помех: 0(предупреждений нет)
Страта: 1 (основная ссылка — синхронизирована по радиочасам)
Точность: -6 (15.625ms за такт времени)
Задержка корня: 0.0000000s
Дисперсия корня: 10.0000000s
Идентификатор опорного времени: 0x4C4F434C (имя источника: "LOCL")
Время последней успешной синхронизации: 07.03.2019 12:38:18
Источник: Local CMOS Clock
Интервал опроса: 10 (1024s)

Туннель во времени. Выводим данные с компьютера через Network Time Protocol

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

Этот трюк могут использовать и вирусописатели — для вывода данных из зараженных систем, причем незаметно для стандартных средств защиты.

WARNING

Создание и распространение вредоносных программ карается по статье 273 УК РФ. Ни автор, ни редакция «Хакера» не несут ответственности ни за какой вред, принесенный использованием материалов этой статьи.

Что такое NTP

NTP (Network Time Protocol) — протокол, который работает поверх UDP и используется для синхронизации локальных часов с часами на сервере точного времени. При работе в интернете точность синхронизации составляет до 10 мс, а в локальных сетях — до 0,2 мс. При этом NTP нечувствителен к задержкам канала.

Актуальная версия протокола (по данным Википедии) — 4, но мы будем использовать версию 3, которой для наших целей предостаточно.

Для максимальной точности служба обновления времени постоянно должна работать в фоновом режиме, регулярно отправляя запросы на сервер точного времени, то есть генерируя довольно много трафика. Это нам на руку, так как из-за этой особенности IDS давно не обращают внимания на трафик NTP.

За синхронизацию в Windows отвечает служба W32Time, а в Linux — демон ntpd или chronyd. Также существует более простая реализация этого протокола, известная как SNTP (Simple Network Time Protocol) — простой протокол сетевого времени. Применяют его во встраиваемых системах и устройствах, которые не требуют высокой точности, как, например, системы умного дома.

Структура пакета NTP

Структура пакета NTP описана в RFC 958 (v1), 1119 (v2), 1305 (v3) и 5905 (v4). Нас интересует версия 3, как довольно распространенная и простая, хотя ты свободно можешь пользоваться версией 4, она почти не отличается.

Для прожженных программистов на C есть псевдокод:

Теперь немного о назначении этих полей.

• Leap indicator (LI), 2 бита — число, предупреждающее о секунде координации. Может быть от 0 до 3, где 0 — нет коррекции, 1 — последняя минута дня содержит 61 с, 2 — последняя минута дня содержит 59 с, 3 — неисправность сервера. При значении 3 полученным данным доверять не следует. Вместо этого нужно обратиться к другому серверу. Наш псевдосервер будет всегда возвращать 0.
• Version number (VN), 2 бита — номер версии протокола NTP (1–4). Мы поставим туда 3.
• Mode — режим работы отправителя пакета. Значение от 0 до 7, где 3 — клиент, а 4 — сервер.
• Stratum — сколько посредников между клиентом и эталонными часами (включая сам NTP-сервер). 1 — сервер берет данные непосредственно с атомных (или других точных) часов, то есть между клиентом и часами только один посредник (сам сервер); 2 — сервер берет данные с сервера со значением Stratum 1 и так далее.
• Poll — целое число, задающее интервал в секундах между последовательными обращениями. Клиент может указать здесь интервал, с которым он хочет отправлять запросы на сервер, а сервер — интервал, с которым он разрешает, чтобы его опрашивали.
• Precision (точность) — число, которое сообщает точность локальных системных часов. Значение равно двоичному логарифму секунд.
• Root delay (задержка сервера) — время, за которое показания эталонных часов доходят до сервера NTP. Задается как число секунд с фиксированной запятой.
• Root dispersion — разброс показаний сервера.
• RefID (идентификатор источника) — ID часов. Если поле Stratum равно единице, то RefID — имя атомных часов (четыре символа ASCII). Если текущий сервер NTP использует показания другого сервера, то в RefID записан IP-адрес этого сервера.
• Reference — последние показания часов сервера.
• Originate — время, когда пакет был отправлен, по версии сервера.
• Receive — время получения запроса сервером.
• Transmit — время отправки ответа сервера клиенту, которое заполняет клиент.

В целом процесс крайне прост и понятен, если изучить картинку. Клиент посылает запрос на сервер, запоминая, когда этот запрос был отправлен. Сервер принимает пакет, запоминает и записывает в пакет время приема, заполняет время отправки и отвечает клиенту. Клиент запоминает, когда он получил ответ, и получает нечто вроде RTT (Round-Trip Time, в простонародье — пинг) до сервера. Дальше он определяет, сколько времени понадобилось пакету, чтобы дойти от сервера обратно ему (время между запросом и ответом клиента минус время обработки пакета на сервере, деленное на два).

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

Ограничения на трафик по порту UDP-123

Системы обнаружения вторжений не такие глупые, какими могут показаться, так что просто пустить трафик, например, OpenVPN по 123-му порту UDP мы не сможем, по крайней мере без риска спалиться. Соответствие RFC все же проверяется. Это можно посмотреть на примере Wireshark.

Один из NTP-пакетов, пойманных Wireshark

Придется нам заставить наши пакеты соответствовать RFC. Проще всего это сделать, назначая некоторые поля по своему усмотрению. Мы можем внедрить свои данные в поля Transmit и Originate . Последнее не вполне соответствует RFC, но так глубоко проверки обычно не добираются.

Концепт

Идея проста: мы составляем собственный «заряженный» пакет NTP и пытаемся синхронизировать время со своим сервером. Чтобы не привлекать лишнего внимания к своей передаче, на каждый запрос должен отправляться внешне валидный ответ, в котором могут быть инструкции для клиента (читай: бота).

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

Для передачи данных с клиента на сервер подходят поля Poll , Originate и Transmit . Из них Poll пригоден ограниченно, но мы на этом останавливаться не будем. Если ты задумаешь учесть его ограничение, то имей в виду, что использовать в этом поле можно только младшие три бита (как я понял из документации). Без учета этого мы можем использовать 17 байт из 48 (35% всего объема пакета) на отправку данных, что уже неплохо.

А что на прием? Сервер заполняет поля Precision , Root delay , Root dispersion , Reference , RefID , Receive и, ограниченно, Poll . На ответ сервера в этом поле распространяются такие же ограничения, как на клиента. Итого имеем 29 (28 без Poll ) байт из 48 (60% пакета). Полезный объем пакета — 46 из 48 байт (96%). Оставшиеся два байта — флаги и заголовки, которые мы менять не можем без вреда для скрытности.

Реализация

Писать код и дебажить наше творение мы будем в Visual Studio. Я использую версию 2019 Community, благо она бесплатная, а скачать ее можно с сайта Microsoft.

Сервер

Как только IDE установлена, включена темная тема и любимый плей-лист, можно приступать. Для начала создадим новый проект типа «консольное приложение» (мы ведь не прячемся от юзера) с названием NtpTun_SERVER .

Создание проекта

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

Весь код, используемый в статье, есть в моем репозитории на GitHub. Он намеренно подпорчен и для промышленного использования не годится, но для демонстрации работы вполне сойдет.

Объявляем структуру пакета. Не смотри на странные суффиксы в названиях функций, так задумано

Уже из этого кода видно, что мы будем притворяться сервером Stratum 3. Если бы мы были Stratum 1, то нужно было бы в поле RefID указывать ID атомных часов, которых у нас нет. А список серверов первого уровня общеизвестен, и, если IP нашего псевдосервера не окажется в таких публичных списках, обман быстро будет раскрыт.

Stratum 2 не следует использовать, потому что тогда RefID должен был бы содержать IP сервера первого уровня, список которых опять же известен. А вот третий уровень позволяет указывать в RefID IP сервера второго уровня, полного списка которых нет. То есть мы сможем в RefID передавать еще четыре байта произвольных данных.

Код методов упаковки и распаковки на скриншот не поместился, к тому же нам надо разобрать его отдельно. Вот он:

Тут никаких сложностей: принимаем массив байтов и при помощи BitConverter получаем оттуда данные.

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

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Ошибка синхронизации с сервером ntp

Продолжая просмотр сайта и(или) нажимая X , я соглашаюсь с использованием файлов cookie владельцем сайта в соответствии с Политикой в отношении файлов cookie в том числе на передачу данных, указанных в Политике, третьим лицам (статистическим службам сети Интернет), в соответствии с Пользовательским соглашением >X

Your browser version is too early. Some functions of the website may be unavailable. To obtain better user experience, upgrade the browser to the latest version.

Продукты, решения и услуги для организаций

• Most people search for
• SwitchesRoutersServersStorageData Center EnergyCloud Computing

Поддержка Центр документации

Настройка NTP для синхронизации времени

Поддерживаемые продукты и версии

Этот пример применим ко всем моделям и версиям.

Требования к сети

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

Как показано на Figure 2-26, настроены IP-адреса SwitchA и SwitchB. SwitchA синхронизировал свои часы с авторитетными часами, например, с системой глобального позиционирования (GPS). SwitchA функционирует как сервер времени SwitchB.

План конфигурации

1. Настройка IP-адресов для SwitchA и SwitchB
2. Конфигурирование SwitchA в качестве основных тактовых часов, чтобы локальные часы SwitchA могли использоваться в качестве опорных часов
3. Настройка SwitchB для синхронизации времени с SwitchA и настройки аутентификации NTP для обеспечения безопасности синхронизации времени

Procedure

1. Настройте IP-адреса для SwitchA и SwitchB

# Настройте IP-адрес для SwitchA.

# Настройте IP-адрес для SwitchB.

Значение полосы уровня синхронизации составляет от 1 до 15. Часы в подсети синхронизируются в порядке возрастания уровней. Можно установить уровень синхронизации. В этом примере уровень синхронизации составляет 1.

В реальных обстоятельствах сервер NTP, синхронизированный с авторитетными часами, задается как stratum 1 и используется как источник синхронизации. Другие устройства в сети синхронизируют свои часы с часами NTP-сервера, что означает, что локальные часы NTP-сервера настроены как основные часы NTP.

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

Проверка конфигурации

Проверьте конфигурации на SwitchA.

Запустите команду display ntp status на SwitchA, чтобы просмотреть статус NTP.

Запустите команду display clock на SwitchA, чтобы просмотреть состояние часов.

Проверьте конфигурации на SwitchB.

Запустите команду display ntp status на SwitchB, чтобы просмотреть статус NTP.

Запустите команду display clock на SwitchB, чтобы просмотреть состояние часов.

Ошибка синхронизации с сервером ntp

0: Splinter:

Проверяй у проблемных устройств, чтобы был выставлен верный часовой пояс и галочку «переводить на летнее время автоматически»

• Цитата

• Цитата

9: Toell пишет:
> У нас в Москве такая же фигня в офисе — часть компов перешло на новое время, часть-нет.
> Беда была сильная, а админ-сука, отсутствовал. системное время сменить не было прав.

Граждане, при чём тут NTP?
Бург же ж уже расписал. Разжёвываю.

Определение локального времени компом и другими девайсами состоит из двух частей:

1. Определить время UTC (Лондонское).
2. Прибавить к UTC (если ты находишься к востоку от Лондона) или отнять от UTC (если ты находишься к западу от Лондона) смещение согласно выставленному в настройках операционки часовому поясу.

Синхронизация по NTP отвечает за пункт 1, но никак не за пункт 2.

А вот пункт 2 зависит уже от операционки.
В случае с 26 октября для XP вроде надо было ставить панч, для луникса скачивать обновленные файлы timezone — всё это для того, чтобы операционка знала, что Europe/Moscow теперь не UTC+4, а UTC+3.
У некоторых некоторые операционки сами умеют обновлять расклад по часовым поясам — они-то и перевели свои стрелки.

Синхронизация NTP тут вообще никаким боком.

• Цитата

4: Splinter пишет:
> Но на отдельном ноуте, которому по сети синхронизироваться запрещено, было точно с теми же самыми настройками.
> И он время скорректировал, несмотря на «Москва +4».

Т.е сейчас у этого ноута пояс «Москва +4», но он показывает правильное время?
А ты в 2011 на него вообще патчи с изменением timezone накатывал? Такое ощущение что он у тебя еще с тех времен UTC +4 переводит на зимнее время(час назад) каждое послед.воскресенье октября

И чтоб уж совсем снять твои заблуждения об ntр. По ntp раздается время по Гринвичу (UTC), для простоты понимания тупо в секундах с 1970г. Всё! NTP сервер знать не знает про перевод стрелок на каждой твоей железке. А вот сами железки поймав по ntp это точное время в секундах интерпретируют его в местное время согласно своих системных файлов с описанием всех временных зон и алгоритмов перевода стрелок на зиму/лето для каждого пояса. Благодаря Диме Айфону в 2011 Россия накатывала патчи для отмены перевода стрелок заложенных ранее в Windows, а неделю назад патчи для перехода на новый часовой пояс.

• Цитата

11: Gerhard:
> По ntp раздается время по Гринвичу (UTC)

10: BadBlock:
> Определение локального времени компом и другими девайсами состоит из двух частей:
>
> 1. Определить время UTC (Лондонское).

Вы меня совсем уже за дитё принимаете. В курсе я, что по UTC, в курсе.
Вопрос в другом совсем.

В чем может быть разница между двумя ноутами, один из которых синхронизируется по сети, а второй нет.

11: Gerhard:
> Т.е сейчас у этого ноута пояс «Москва +4»

Только завтра смогу посмотреть: жена с этим ноутом уехала в командировку.
Но, полагаю, нет, скорее всего он перешел на «Москва +3».
Винды одинаковые, лицензионные, обновляются и скачивают патчи сами, я не заморачиваюсь когда и какие.
И как же тогда так получается, что один скачал патч, а другой нет?
Она оба в одной сетке работают, с одного роутера инет получают: одна винда патч получила, а вторая нет?
Если так, то тогда вопросов нет.

• Цитата

12: Splinter пишет:
> Но, полагаю, нет, скорее всего он перешел на «Москва +3».

Операционка какая на нем?

Тут главное понять так это итоговое время «Москва +3» на нем получилось. По «православному» накатыванием патча с заменой часового пояса и отменой перевода стрелок или это еще «староверский» UTC+4 с автоматическим переводом стрелок весна-осень.
При правильном методе на Windows к названиям поясов должно прибавиться (RTZ <номер пояса>), т.е что-то типа «UTC + 03:00) Москва, Санкт-Петербург, Волгоград (РТЗ 2) «.

• Цитата

13: Gerhard:
> Операционка какая на нем?

Семерка.

> или это еще «староверский» UTC+4 с автоматическим переводом стрелок весна-осень.

Он бы тогда долбал меня с 2011 года неправильным временем, «переводя» стрелки два раза в год.
А этого не было.