Сервер Windows 2008 на Домене 2003 года, приводя к сбою kerberos предавтора

Вы думали о резервировании сети? Кластеры GFS очень уязвимы для пропущенных heartbeat. Мы используем интерфейс, связывающийся для всего нашего кластера и ссылок iSCSI, подключенных к отдельным коммутаторам.

0
задан 17 November 2009 в 14:24
4 ответа

0x19 соответствует 19 в шестнадцатеричной нотации, которая является 25 в десятичном числе: "Дополнительная предварительная аутентификация, требуемая*"

1
ответ дан 23 November 2019 в 13:30
  • 1
    Хорошая выгода. I' d upvote это как комментарий, но не как ответ. –  sh-beta 3 December 2009 в 07:57

Я думаю, что с Windows 2008, NTLM был устранен как метод аутентификации. Это оставляет Kerberos как единственную опцию. У нас была подобная проблема, когда мы выставили 2 008 машин в нашей тестовой среде. Оказалось, что часы были достаточно вне синхронизации (т.е.>. 5 минут) с доменного времени. Машины 2003 хорошо работали, так как они просто отступили к NTLM, когда Kerberos перестал работать. Обеспечение, что машины все имели общий источник NTP (набор через GPO) устранило нашу проблему.

0
ответ дан 23 November 2019 в 13:30
  • 1
    Примите во внимание, что эти ошибки зарегистрированы моим доменом controller' s аудит политик - я слышу об этом, когда мои 2 003 поля перестали работать, kerberos подлинное время настроено правильно. –  sh-beta 17 November 2009 в 14:28

Поскольку Kerberos обменивается сообщениями, я всегда проверяю, что SPN's сервера (Сервисные Имена Принципала) не дублирован. Kerberos, кажется, использует SPN's для присоединения к пользователю/учетным записям компьютера, не name/CN/samaccountname. ADSIEdit может использоваться для наблюдения SPN's и поиск простофиль.

0
ответ дан 23 November 2019 в 13:30

Ошибка Kerberos (0x) 19 на самом деле соответствует 'учетным данным для сервера, были отменены' - посмотрите RFC для списка kerberos кодов ошибок - очень полезный для поиска и устранения неисправностей. Дополнительная предварительная аутентификация (0x25) средства существует более определенные ошибочные доступные данные в поле ошибочного типа (можно относиться для разделения 5.9.1 из RFC), но снова, 0x19 указывает, что учетные данные сервера не функционируют правильно.

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

0
ответ дан 23 November 2019 в 13:30
  • 1
    Добавленный ссылка к MS' s сайт, где они маркировка 0x19 как дополнительный предавтор потребовали. Интересное несоответствие, все же. Время правильно настроено на этих полях. I' тест ll, удаляющий/воссоединяющийся их к домену, но, учитывая, что it' s происходящий со ВСЕМИ моими 2 008 полями that' s маловероятная фиксация. –  sh-beta 17 November 2009 в 14:26
  • 2
    См. David' s объяснение выше - десятичное число по сравнению с шестнадцатеричным числом. –  sh-beta 3 December 2009 в 07:58

Теги

Похожие вопросы