Назад | Перейти на главную страницу

Что ломается в домене Windows, если у члена высокий временной перекос?

Большинство ИТ-специалистов считают само собой разумеющимся, что в домене Windows, если часы рядового сервера отстают более чем на 5 минут (или на сколько минут, на которое вы их настроили) от часов его контроллера домена, вход в систему и проверка подлинности завершатся ошибкой. .

Но это не обязательно так. По крайней мере, не для всех процессов аутентификации во всех версиях Windows. Например, я могу настроить свое время на моем клиенте Windows 7 так, чтобы оно было искажено до чертиков - выход из системы / вход в систему по-прежнему работает нормально. Что происходит, так это то, что мой клиент отправляет AS_REQ (со своей меткой времени) контроллеру домена, а контроллер домена отвечает KRB_AP_ERR_SKEW. Но волшебство в том, что, когда DC отвечает вышеупомянутой ошибкой Kerberos, DC также включает его отметка времени, которую клиент, в свою очередь, использует для настройки своего времени и повторно отправляет AS_REQ, который затем утверждается.

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

Это тоже не только дело Microsoft. RFC 4430 описывает это поведение.

Итак, мой вопрос: кто-нибудь знает, когда это изменилось? И почему другие вещи терпят неудачу? Например, Office Communicator выгонит меня, если мои часы начнут уходить слишком далеко. Я действительно хочу получить более подробную информацию об этом.

edit: Вот фрагмент из RFC 4430, о котором я говорю:

Если часы сервера и клиента отстают более чем на
установленный политикой предел рассогласования часов (обычно 5 минут), сервер
ДОЛЖЕН возвращать KRB_AP_ERR_SKEW. Необязательное время клиента в
KRB-ERROR ДОЛЖЕН быть заполнен. Если сервер защищает ошибку с помощью
добавив поле Cksum и вернув правильное время клиента,

клиент ДОЛЖЕН вычислить разницу (в секундах) между двумя
часы на основе времени клиента и сервера, содержащегося в
Сообщение KRB-ERROR. Клиенту СЛЕДУЕТ сохранить эту разницу часов и использовать ее для настройки своих часов в последующих сообщениях. Если ошибка
не защищен, клиент НЕ ДОЛЖЕН использовать разницу для настройки
последующие сообщения, потому что это позволит злоумышленнику
создавать аутентификаторы, которые можно использовать для проведения атак с повторением.