Диагностирование Kerberos в среде Sharepoint (часть 2)

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

• SPN конфигурация - для IIS 7
• Дубликаты имен Service Principal Names
• Несоответствие конфигурации DNS

Конфигурация SPN - для IIS 7

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

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

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

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

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

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

1. В диспетчере IIS 7 Manager выберите ‘Sites/<имя вашего веб сайта SharePoint>’ и выберите ‘Аутентификация’.

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

1. Я отметил опцию ‘Включить Kernel-mode аутентификацию’, которая является параметром по умолчанию

1. Затем перезапустил свой IIS с помощью команды: IISRESET /NOFORCE

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

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

Если мы посмотрим на пакеты и ошибку компьютера PC1 с помощью Wireshark, то увидим ту же ошибку:

В журнале Windows Event Log и в снимке пакетов мы получили KRB_AP_ERR_MODIFIED, а учетная запись, с которой отправлен ответ – wss1$. Мы знаем, что сервер WSS1 создает отчет об этой ошибке, когда мы входим на веб сайт. Это также видно по IP адресу, если посмотреть на информацию IP адреса источника/приемника в Wireshark. Давайте рассмотрим этот сервер. Отчет KRB_AP_ERR_MODIFIED означает, что компьютер думает, что обмен пакетами Client/Service изменен и проверяемыми параметрами является дата/время, IP адреса, имена хостов, а также работа ключа дешифровки. Мы быстро проверяем дату/время, IP адреса и имена хостов (смотреть раздел конфигурации DNS), и все эти параметры (скорее всего) верны. Ключ шифрования/дешифровки определяется именем SPN – соотнесением учетных записей (account mapping). Эта учетная запись должна быть той учетной записью, которую использует IIS веб сайт на сервере WSS1.

Выполняем проверку с помощью следующей команды:

Имя Service Principal Name сопоставляется с учетной записью домена SPContentPoolAcct и позволяет нам проверить пул приложений IIS Application Pool, который используется веб сайтом. В диспетчере IIS найдите Пул приложения (Application Pool), используемый веб сайтом IIS. Затем перейдите во вкладку Дополнительные параметры ‘ на рисунке 14 показано, что учетная запись настроена правильно.

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

Мы проверим и исправим файл конфигурации следующим образом:

1. Сначала откроем файл конфигурации на каждом сервере, граничащем с SharePoint: %WinDir%\System32\inetsrv\config\ApplicationHost.config
2. Затем убедимся, что параметр useAppPoolCredentials присутствует. Если нет, мы добавим этот атрибут, как на примере, выделенном зеленым цветом ниже (ОБЯЗАТЕЛЬНО введите этот текст в точности, как в примере, только буквы A, P и C будут заглавными): <system.webServer> <security> <authentication> <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" /> </authentication> </security> </system.webServer>
3. Наконец мы сбрасываем Internet Information Server с помощью команды: IISRESET /NOFORCE

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

Поиск дубликатов имен Service Principal Names

Очень легко создать одинаковые имена SPN в Active Directory, если вы не используете команду setspn.exe с переключателями ‘-S’ или ‘‘F’ (только для setspn.exe в Windows Server 2008 или выше). Для лучшего понимания того, как хранятся имена Service Principal Names и как KDC ищет учетную запись на основе имени SPN я нарисовал схему на рисунке 16. Пример дубликата имени SPN, зарегистрированного в SPWrongAcct, выделен красным цветом.

Наличие одинаковых SPN имен может вызвать отчеты об ошибках, говорящие KRB_AP_ERR_MODIFIED, поскольку KDC мог зашифровать мандат службы с помощью публичного ключа учетной записи, которая была найдена в имени SPN, но пул приложения мог использовать другую учетную запись, которая использовалась для расшифровки пакета. Проверка на наличие одинаковых имен 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 SPN: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 ‘ вручную просмотрите одну за другой учетные записи пользователей и компьютеров, и убедитесь, что одинаковое значение отсутствует в нескольких учетных записях. Это слишком трудный способ, поэтому я бы предпочел другой метод.

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

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

• ‘setspn.exe ‘S‘ для регистрации имени SPN на учетной записи и поиска дубликатов в домене
• ‘setspn.exe ‘F ‘S‘ для регистрации имени SPN в учетной записи и проверки на наличие дубликатов по всему лесу

Я сделал снимок поиска дубликатов и настроил имя Service Principal Name (рисунок 18) в учетной записи DOMAIN\SPContentPoolAcct

На следующем рисунке показана попытка создания дубликата имени SPN. Команда setspn.exe находит этот дубликат, как показано на рисунке 19, и даже говорит вам, с каким объектом Active Directory возник этот конфликт.

Конфигурация DNS

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

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

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

Зона прямого поиска (Forward Lookup Zone) для domain.local:

Зона обратного поиска (Reverse Lookup Zone) для domain.local:

Заключение

Итак мы рассмотрели большинство ключевых элементов типичных ошибок в SharePoint и Kerberos, к которым относятся DNS конфигурация, дубликаты имен SPN и IIS7 в Windows Server 2008. В третьей части этой серии мы подробно рассмотрим мандаты и ту информацию, которую можно использовать. Мы также рассмотрим делегирование и Shared Service Provider в работе, в нерабочем состоянии, проанализируем проблемы и исправим их.