Устранение неполадок Kerberos в среде Sharepoint (часть 2)
Продолжение расследования
В первой части мы рассмотрели устранение неполадок со временем и датой, учетными записями пула приложений и базовой конфигурацией имени субъекта-службы (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
Вывод