Устранение неполадок Kerberos в среде Sharepoint (часть 2)

Опубликовано: 9 Апреля, 2023

Продолжение расследования

В первой части мы рассмотрели устранение неполадок со временем и датой, учетными записями пула приложений и базовой конфигурацией имени субъекта-службы (SPN). В этой части рассмотрим следующие темы:

Конфигурация SPN — примечание для IIS 7
Повторяющиеся имена участников службы
Несоответствие конфигурации DNS

Конфигурация SPN — примечание для IIS 7

Всегда приятно получать отзывы о статьях, и пара упомянула, что они не могли заставить веб-сайты работать с Kerberos, если использовали Internet Information Server 7 на Windows Server 2008. Учетная запись пула приложений и регистрация SPN были настроены правильно, но это хорошо. старое сообщение об ошибке по-прежнему появляется в журнале системных событий Windows: KRB_AP_ERR_MODIFIED.

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

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

Информация об используемых IP-адресах:

172.16.189.11 — это контроллер домена (и KDC) DC1.
172.16.189.15 — это SQL Server (и KDC) SQL1.
172.16.189.20 — это сайт http://intranet.domain.local
172.16.189.21 — это сервер SharePoint WSS1.
172.16.189.22 — это сервер SharePoint WSS2.
172.16.189.101 — это компьютер PC1, который обращается к веб-сайту.

Я отключил аутентификацию в режиме ядра в своей среде и для этого теста просто снова включил ее (поскольку это режим по умолчанию) в Internet Information Manager 7:

В диспетчере IIS 7 выберите «Сайты/<имя вашего веб-сайта SharePoint>» и выберите «Аутентификация».

Рис . 7

Выберите «Аутентификация Windows» и нажмите «Дополнительные параметры».

Рис . 8

Я поставил галочку «Включить аутентификацию в режиме ядра», которая была настройкой по умолчанию.

Рисунок 9

Затем я сбрасываю свой IIS с помощью команды: IISRESET/NOFORCE

Мы хотим увидеть больше подробностей о пакете, поэтому, прежде чем пытаться получить доступ к веб-сайту, я запускаю Wireshark, анализатор сетевых протоколов, на DC1 и PC1, чтобы мы могли исследовать ошибки Kerberos в сети. Я рекомендую установить фильтр для отображения только пакетов Kerberos:

Рисунок 10

Теперь я получу доступ к веб-сайту: http://intranet.domain.local — здесь я получу окно входа из-за неудачной попытки входа. Первый шаг — проверить журнал событий на компьютере, с которого осуществляется доступ к веб-сайту. Это событие из журнала системных событий Windows на компьютере, обращающемся к веб-сайту, проверено на ПК1:

Рисунок 11

Если мы посмотрим на пакеты и ошибки, захваченные на ПК1 с помощью Wireshark, мы увидим ту же ошибку:

Рисунок 12

Как в журнале событий Windows, так и в захваченных пакетах мы видим, что мы получаем KRB_AP_ERR_MODIFIED, а ответ учетной записи — wss1$. Мы знаем, что сервер WSS1 сообщает об этой ошибке при доступе к веб-сайту. Мы также можем увидеть это по IP-адресу, если посмотрим на информацию об IP-адресе источника/назначения в Wireshark. Давайте посмотрим на этот сервер. KRB_AP_ERR_MODIFIED означает, что компьютер считает, что пакет обмена Клиент/Сервис изменился, и проверяются следующие параметры: дата/время, IP-адреса, имена хостов и работает ли ключ дешифрования. Мы быстро проверяем дату/время, IP-адреса и имена хостов (см. раздел конфигурации DNS), и они (предположительно) верны. Ключ шифрования/дешифрования определяется сопоставлением имени участника-службы и учетной записи. Эта учетная запись должна быть учетной записью, которую использует веб-сайт IIS на сервере WSS1.

Проверяем это следующей командой:

Рисунок 13

Имя субъекта-службы сопоставляется с учетной записью домена SPContentPoolAcct и позволяет нам проверить пул приложений IIS, который использует веб-сайт. В диспетчере IIS найдите пул приложений, используемый на веб-сайте IIS. Затем проверьте дополнительные настройки для этого — на рисунке 14 это показывает, что учетная запись настроена правильно.

Рисунок 14

Но из-за новой структуры IIS 7 в Windows Server 2008 это используется только в том случае, если проверка подлинности в режиме ядра деактивирована или конфигурация хоста изменена.

Проверяем и правим конфигурационный файл таким методом:

Сначала мы открываем файл конфигурации на каждом сервере веб-интерфейса SharePoint: %WinDir%System32inetsrvconfigApplicationHost.config.
Затем мы проверяем наличие параметра useAppPoolCredentials. Если нет, мы добавим этот атрибут, как в примере, выделенном зеленым цветом ниже (НЕ ЗАБУДЬТЕ набирать точно так же, как текст, и только A, P и C должны быть заглавными буквами):
<системный.веб-сервер>
<безопасность>
<аутентификация>
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
</аутентификация>
</ безопасность>
</system.веб-сервер>
Наконец, мы сбрасываем Internet Information Server из командной строки:
IISRESET/NOFORCE

Теперь мы снова можем получить доступ к веб-сайту без запросов на вход или ошибок в журнале событий. Для записи я просто включаю правильные данные протокола Wireshark, полученные с клиентского компьютера PC1:

Рисунок 15

Проверка дубликатов имен участников службы

В Active Directory легко создать повторяющиеся имена участников-служб, если только вы не используете команду setspn.exe с переключателем «-S» или «-F» (только setspn.exe из Windows Server 2008 и выше). Для лучшего понимания того, как хранятся имена участников-служб и как KDC ищет учетную запись на основе имени участника-службы, я сделал схему на рисунке 16. Пример дублирующегося имени участника-службы, зарегистрированного в SPWrongAcct, выделен красным.

Рисунок 16

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

ldifde — извлекать SPN напрямую и фильтровать из Active Directory
Получение учетных записей, в которых определены HTTP-имена SPN:
ldifde -d "dc=domain,dc=local" -r "servicePrincipalName=http*" -p subtree -l "dn,servicePrincipalName" -f output.txt
Получение учетных записей, в которых определены имена участников-служб MSSQLSvc:
ldifde -d "dc=domain,dc=local" -r "servicePrincipalName=mssqlsvc*" -p subtree -l "dn,servicePrincipalName" -f output.txt
setspn.exe — в Windows Server 2008 можно проверить наличие дубликатов
Получение учетной записи, в которой определен HTTP SPN:
setspn.exe -Q http/intranet.domain.local
Проверка HTTP SPN, зарегистрированного в нескольких учетных записях (дубликаты SPN):
setspn.exe -X http/intranet.domain.local
ADSIEdit — вручную просмотрите учетные записи пользователей и компьютеров одну за другой и убедитесь, что значение не существует в нескольких учетных записях. Этот подход требует тяжелой работы, поэтому я бы выбрал один из других методов.

Рис . 17

В выводе любой из вышеперечисленных процедур следует обращать внимание на то, что имя участника-службы (например, HTTP/intranet.domain.local) не указано более чем в одной учетной записи. Сама учетная запись может без проблем иметь несколько имен SPN (см. рис. 17).

Я рекомендую использовать следующие команды, если вы используете Windows Server 2008:

« setspn.exe -S » для регистрации имени участника-службы в учетной записи и проверки наличия дубликатов в домене
« setspn.exe -F -S » для регистрации имени участника-службы в учетной записи и проверки наличия дубликатов по всему лесу.

Я сделал снимок экрана с проверкой дубликатов и настроил имя участника-службы (рис. 18) для учетной записи DOMAINSPContentPoolAcct.

Рисунок 18

На следующем снимке экрана показана попытка создать дубликат имени участника-службы. Программа setspn.exe находит этот дубликат (рис. 19) и даже сообщает, с каким объектом Active Directory он конфликтует.

Рисунок 19

DNS-конфигурация

Сегодня хорошая и надежная конфигурация DNS должна быть установлена в каждом домене, и при использовании Kerberos это не исключение. Все имена хостов должны быть созданы в зонах прямого и обратного просмотра, и не допускается дублирование ни имени хоста, ни IP-адреса. В зоне прямого просмотра записи должны создаваться как A-записи — также в заголовках узлов, которые указывают на серверы. Если используется CNAME, иногда Kerberos будет создавать билеты, используя неправильное имя хоста — так что, по сути, это правило противоречит лучшим практикам настройки DNS, чтобы заставить его работать.

Отправляемая и получаемая информация будет проверяться как с прямым, так и с обратным просмотром. Сначала я проверю свою конфигурацию, чтобы увидеть, правильно ли DNS реагирует на имя хоста моего веб-сайта.

Рисунок 20

Обе команды должны возвращать правильное имя хоста и IP-адрес, но рекомендуется проверить конфигурацию DNS вручную. Вы должны быть уверены, что все имена хостов в вашей настройке (серверы DC1, SQL1, WSS1 и компьютер PC1) и используемые заголовки хостов (intranet.domain.local) созданы и уникальны. Ниже приведены снимки экрана с нашей конфигурацией DNS, показанной на рисунках 21 и 22.

Зона прямого просмотра для domain.local:

Рисунок 21

Зона обратного просмотра для domain.local:

Рисунок 22

Вывод

В третьей части мы более подробно рассмотрим делегирование Kerberos. Мы посмотрим, как это работает, разберем, проанализируем и снова исправим. Я также расскажу о Shared Service Provider (SSP) и поделюсь своими заметками по разным заданиям по устранению неполадок.