Как включить ведение журнала событий Kerberos

В этой статье описывается, как включить ведение журнала событий Kerberos.

Исходная версия продукта: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10 версии 1809 и более поздних версий, Windows 7 Пакет обновления 1
Исходный номер КБ: 262177

Аннотация

Windows 7 Пакет обновления 1, Windows Server 2012 R2 и более поздних версий предоставляют возможность трассить подробные события Kerberos через журнал событий. Эти сведения можно использовать при устранении неполадок Kerberos.

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

Примеры ошибок ложного срабатываирования:

KDC_ERR_PREAUTH_REQUIRED возвращается по первоначальному запросу Kerberos AS. По умолчанию клиент Windows Kerberos не включит данные предварительной проверки подлинности в этот первый запрос. Ответ содержит сведения о поддерживаемых типах шифрования в KDC, а в случае AES — о солях, которые будут использоваться для шифрования хеш-кодов паролей.

Рекомендация: всегда игнорируйте этот код ошибки.

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

Рекомендация: если не возникла проблема делегирования, игнорируйте эту ошибку.

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

• Отсутствуют или дублируются SPNs, зарегистрированные в AD.
• Неправильные имена серверов или DNS-суффиксы, используемые клиентом, например, клиент использует записи DNS CNAME и использует итоговую запись A в SPN.
• Использование имен серверов без FQDN, которые необходимо разрешить за пределами леса AD.

Рекомендация: изучение использования имен серверов приложениями. Скорее всего, это проблема с конфигурацией клиента или сервера.

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

Рекомендация. Как и KDC_ERR_S_PRINCIPAL_UNKNOWN, проверьте правильность задаваемой spN.

Другие сценарии или ошибки требуют внимания системных администраторов или администраторов домена.

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

Включить ведение журнала событий Kerberos на определенном компьютере

Откройте редактор реестра.

Добавьте следующее значение реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Значение реестра: LogLevel
Тип значения: REG_DWORD
Значение: 0x1

Если подмайка Parameters не существует, создайте его.

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

Закройте редактор реестра. Этот параметр начнет действовать сразу в Windows Server 2012 R2, Windows 7 и более поздних версиях.

В системном журнале можно найти любые события, связанные с Kerberos.

Дополнительные сведения

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

С общей точки зрения вы можете получить дополнительные ошибки, которые правильно обрабатываются клиентом-принимающим клиентом без вмешательства пользователя или администратора. Переустанавлившиеся ошибки, захваченные в журнале Kerberos, не отражают серьезной проблемы, которую необходимо решить или даже можно решить.

Например, журнал событий 3 об ошибке Kerberos с кодом ошибки 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN for Server Name cifs/ будет регистрироваться при доступе к совместному доступу с IP-адресом сервера без имени сервера. Если эта ошибка зарегистрирована, клиент Windows автоматически пытается вернуться к проверке подлинности NTLM для учетной записи пользователя. Если эта операция работает, ошибка не будет.

Сбой проверки подлинности с серверов, не в том как Windows NTLM или Kerberos

В этой статье приводится решение нескольких проблем с ошибками проверки подлинности, при которых серверы NTLM и Kerberos не могут проверить подлинность Windows 7 и Windows Server 2008 R2 компьютеров. Это вызвано различиями в способе обработки маркеров привязки канала.

Исходная версия продукта: Windows 7 Пакет обновления 1, Windows Server 2012 R2
Исходный номер КБ: 976918

Симптомы

Windows 7 и Windows Server 2008 R2 поддерживают расширенную защиту для встроенной проверки подлинности, которая включает поддержку маркера привязки канала (CBT) по умолчанию.

У вас может возникнуть один или несколько из следующих симптомов:

• Клиенты Windows, поддерживаюающие привязку канала, не могут быть аутентификацией на сервере, не относяшемся к Windows Kerberos.
• Сбои проверки подлинности NTLM с прокси-серверов.
• Сбои проверки подлинности NTLM с серверов, не в том как Windows NTLM.
• Сбои проверки подлинности NTLM при разнице во времени между клиентом и dc или сервером группы.

Причина

Windows 7 и Windows Server 2008 R2 поддерживают расширенную защиту для встроенной проверки подлинности. Эта функция улучшает защиту и обработку учетных данных при проверке подлинности сетевых подключений с помощью встроенной проверки подлинности Windows (IWA).

По умолчанию этот режим находится в режиме «ON». Когда клиент пытается подключиться к серверу, запрос проверки подлинности привязан к используемому имени-службы.. Кроме того, если проверка подлинности проходит в канале TLS, ее можно привязить к этому каналу. NTLM и Kerberos предоставляют дополнительные сведения в своих сообщениях для поддержки этой функции.

Кроме того, компьютеры с Windows 7 и Windows 2008 R2 отключят LMv2.

Решение

При сбоях, в которых серверы, не в том или ином windows NTLM или Kerberos, не получают CBT, обратитесь к поставщику за версией, которая правильно обрабатывает CBT.

При сбоях, в которых серверы или прокси-серверы, не в которых не windows NTLM, требуют LMv2, обратитесь к поставщику за версией, которая поддерживает NTLMv2.

Обходной путь

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

Чтобы управлять поведением расширенной защиты, создайте следующий подмеек реестра:

• Имя ключа: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
• Имя значения: SuppressExtendedProtection
• Тип: DWORD

Для клиентов Windows, которые поддерживают привязку канала, которые не могут проверить подлинность серверов, не в том случае, если серверы Kerberos не обрабатывают CBT правильно:

1. Установите для записи реестра значение 0x01. В этом случае Kerberos не будет излучать маркеры CBT для невыгружаемых приложений.
2. Если это не устраняет проблему, установите для записи реестра значение 0x03. При этом Kerberos никогда не будет излучать маркеры CBT.

Существует известная проблема с Sun Java, которая была устранена в связи с возможностью того, что приемчик может игнорировать любые привязки канала, предоставленные инициатором, что возвращает успех, даже если инициатор передал привязки канала в зависимости от RFC 4121. Дополнительные сведения см. в привязок входящих каналов, если приемчик не настроит ее.

Рекомендуется установить следующее обновление с сайта Sun Java и повторно включить расширенную защиту: изменения в версии 1.6.0_19 (6u19).

Для клиентов Windows, которые поддерживают привязку канала, не прохождению проверки подлинности серверами, не относяющимися к Windows NTLM, которые неправильно обрабатывают CBT, установите для записи реестра значение 0x01. При этом NTLM не будет излучать маркеры CBT для невыплаченных приложений.

Для серверов без Windows NTLM или прокси-серверов, которые требуют LMv2, установите для записи реестра значение 0x01. Это позволит настроить NTLM для предоставления ответов LMv2.

Для сценария, в котором разница во времени слишком велика:

1. Исправьте часы клиента, чтобы отразить время на контроллере домена или сервере группы.
2. Если это не устраняет проблему, установите для записи реестра значение 0x01. Это позволит настроить NTLM для предоставления ответов LMv2, которые не имеют подмены времени.

Что такое CBT (маркер привязки канала)?

Маркер привязки канала (CBT) является частью расширенной защиты для проверки подлинности. CBT — это механизм привязки внешнего безопасного канала TLS к проверке подлинности внутреннего канала, например Kerberos или NTLM.

CBT — это свойство внешнего безопасного канала, используемого для привязки проверки подлинности к каналу.

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

Расширенная защита теперь поддерживается в Windows XP, Windows Vista, Windows Server 2003 и Windows Server 2008.

Заявление об отказе от ответственности

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

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

В максимальной степени, разрешенной применимым законодательством, Корпорация Майкрософт и/или ее поставщики отключают все представления, гарантии и условия, как экспресс-, подразумеваемые, так и предусмотренные законом, включая, но не ограничиваемые, представления, гарантии или условия названия, нена нарушение прав, удовлетворительное условие или качество, возможность продавца и пригодность для конкретной цели в отношении материалов.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Аутентификация в системах Windows. Часть 2 — Kerberos

Аутентификация в системах Windows. Часть 2 — Kerberos

В прошлой части нашего цикла мы рассмотрели работу протоколов семейства NTLM, отметив ряд их существенных недостатков, которые невозможно решить в рамках протокола. Поэтому вместе с Active Directory на смену им пришел более совершенный протокол Kerberos, который продолжает успешно применяться до сих пор. В данном материале мы рассмотрим общие принципы функционирования данного протокола, что позволит получить начальные знания в этой области самым широким массам читателей.

Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.

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

В доменных сетях протоколы NTLM вызывают повышенную нагрузку на контроллеры домена, так как всегда обращаются к ним для аутентификации пользователя. При этом также отсутствует взаимная идентификация узлов и существует возможность накопления пакетов для последующего анализа и атаки с их помощью.

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

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

Основой инфраструктуры Kerberos является Центр распространения ключей (Key Distribution Center, KDC), который является доверенным центром аутентификации для всех участников сети (принципалов). Область Kerberos (Realm) — пространство имен для которых данный KDC является доверенным, как правило это область ограниченная пространством имен домена DNS, в Active Directory область Kerberos совпадает с доменом AD. Область Kerberos записывается в виде соответствующего ему доменного имени DNS, но в верхнем регистре. Принципалом или учетной записью Kerberos является любой участник отношений безопасности: учетная запись пользователя, компьютер, сетевая служба и т.д.

Центр распространения ключей содержит долговременные ключи для всех принципалов, в большинстве практических реализаций Kerberos долговременные ключи формируются на основе пароля и являются так называемым «секретом для двоих». С помощью такого секрета каждый из его хранителей может легко удостовериться, что имеет дело со своим напарником. При этом долговременные ключи не при каких обстоятельствах не передаются по сети и располагаются в защищенных хранилищах (KDC), либо сохраняются только на время сеанса.

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

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

Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.

Желая пройти проверку подлинности в сети, клиент передает KDC открытым текстом свое имя, имя домена и метку времени (текущее время клиента), зашифрованное долговременным ключом клиента. Метка времени в данном случае выступает в роли аутентификатора — определенной последовательности данных, при помощи которой узлы могут подтвердить свою подлинность.

Получив эти данные KDC извлекает долговременный ключ данного пользователя и расшифровывает метку времени, которую сравнивает с собственным текущим временем, если оно отличается не более чем на 5 минут (значение по умолчанию), то метка считается действительной. Эта проверка является дополнительной защитой, так как не позволяет использовать для атаки перехваченные и сохраненные данные.

Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.

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

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

Успешно пройдя аутентификацию, клиент будет располагать сеансовым ключом, которым впоследствии он будет шифровать все сообщения для KDC и билетом на получение билета (TGT).

Теперь рассмотрим ситуацию, когда клиент хочет обратиться к серверу.

Для этого он снова обращается к KDC и посылает ему билет на получение билета, зашифрованную сеансовым ключом метку времени и имя сервера. Прежде всего KDC расшифровывает предоставленный ему TGT и извлекает оттуда данные о клиенте и его сеансовый ключ, обратите внимание, что сам KDC сеансовые ключи не хранит. Затем сеансовым ключом он расшифровывает данные от клиента и сравнивает метку времени с текущим. Если расхождения нет, то KDC формирует общий сеансовый ключ для клиента и сервера.

Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.

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

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

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

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

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

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал: