Ошибка проверки подлинности kerberos windows server 2016

Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

• Она должна хранить информацию, о всех объектах Active Directory, среди которых: пользователи, группы безопасности, компьютеры, принтеры и другие объекты идентификации. Под объектом идентификации (identity) подразумевается, некое представление сущности, в задачи которой входит выполнение каких-либо действий в корпоративной сети. Простой пример, есть пользователь Вася и он работает с документами в общей папке на сервере. Эти документы имеют защиту на доступ, который определяет список контроля доступа (Access Contro l List, ACL). Доступом у нужным файлам, управляет подсистема безопасности сервера, где лежит папка, и при обращении к ней он производит сравнение объекта идентификации пользователя с теми объектами, которые присутствуют в его списке ACL, и уже на основании этого, он принимает решение предоставить или запретить пользователю доступ. Так как службы, компьютеры, группы и другие объекты выполняют определенные вещи в локальной сети, то у каждого из них есть свой объект идентификации. Данный объект содержит много информации, уникальной для каждого из них, например, имя пользователя, его идентификатор безопасности (Security Identifier, SID), пароль. Так, что хранилище объектов идентификации, является неотъемлемой частью Identity and Access. Все данные в Active Directory, располагаются в каталоге AD, которым управляет контроллер домена.
• Проверка подлинности объекта идентификации. Тут общий принцип такой, когда пользователь обращается к документу, то сервер его ему не покажет, пока тот, не подтвердит подлинность объекта идентификации, который фигурирует в запросе. Чтобы все это сделать, у пользователя есть некая секретная информация, которая известна ему и инфраструктуре IDA, вот эти данные как раз и сравниваются с теми, что есть в хранилище объектов идентификации в момент проверки подлинности.

Протокол аутентификации kerberos

Чем хороша операционная система Windows, так это тем, что она очень унифицированная, за счет интерфейса SSPI (Security Support Provider Interface). SSPI — это механизм операционной системы Windows в задачи которого идет, предоставление приложениям не зависеть от различных решений протоколов аутентификации, позволяя работать абсолютно с любыми из них, если перефразировать, то любое приложение может использовать любой протокол аутентификации. Еще очень большой плюс интерфейса SSPI, то что он позволяет изолировать сетевой транспорт от протоколов аутентификации, если по простому, то эти протоколы становятся независимыми от протоколов передачи данных по сети, и приложению вообще до лампочки, какой из них использовать.

Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI

Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.

Пользовательский ключ — когда системный администратор заводит новую учетную запись пользователя, значение его пароля используется при создании ключа, он хранится рядом с самим объектом пользователя AD. И как написано выше, это ключ знают контроллер домена и пользователь, две стороны.

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

Ключ службы (service key) — тут все просто, очень часто системные администраторы для запуска службы создают отдельного доменного пользователя, в следствии чего служба получит его ключ, но если она запускается под учетной записью системы (LocalSystem), то получит ключ компьютера.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.

• Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.

• Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.

Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.

Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

Как производится настройка SPN мною уже была описана в одной из статей.

Детальная проверка kerberos от начала логирования

Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:

• Человек видит поля ввода логина и пароля у себя на компьютере
• Компьютер получив от пользователя первичные данные делает запрос к контроллеру домена, а точнее к службе Key Distribution Center, где передает KDC имя пользователя в открытом виде, имя домена и текущее время на рабочей станции, еще раз напоминаю, что оно не должно отличаться от времени на контроллере домена более ,чем на 5 минут. Значение текущего времени передается в зашифрованном виде, и будет выступать аутентификатором. Напоминаю, что ключ шифрования (пользовательский ключ) формируется из пароля пользователя, как результат хеширования.

• Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
• Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.

• Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
• Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
• KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

• Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs — это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
• Теперь все это дело шифруется сессионным ключом и передается клиенту.

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

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

• Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
• Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.

Сбой проверки подлинности с серверов, не в том как 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.

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

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

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

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