В первой части мы разглядели диагностирование заморочек, связанных с датой и временем, учетными записями пула приложений и базисной конфигурацией имен 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:

В диспетчере IIS 7 Manager изберите ‘Sites/’ и изберите ‘Аутентификация’.

Набросок 7

Изберите ‘Аутентификация Windows’ и нажмите ‘Дополнительные характеристики’

Набросок 8

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

Набросок 9

Потом перезапустил собственный IIS при помощи команды: IISRESET /NOFORCE

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

Набросок 10

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

Набросок 11

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

Прирастить

Набросок 12

В журнальчике 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.

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

Набросок 13

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

Набросок 14

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

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

Поначалу откроем файл конфигурации на каждом сервере, граничащем с SharePoint: %WinDir%System32inetsrvconfigApplicationHost.config
Потом убедимся, что параметр useAppPoolCredentials находится. Если нет, мы добавим этот атрибут, как на примере, выделенном зеленоватым цветом ниже (Непременно введите этот текст в точности, как в примере, только буковкы A, P и C будут большими): useAppPoolCredentials=»true» />
В конце концов мы сбрасываем Internet Information Server при помощи команды: IISRESET /NOFORCE

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

Прирастить

Набросок 15

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

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

Набросок 16

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

Набросок 17

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

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

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

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

Набросок 18

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

Набросок 19

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

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

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

Прирастить

Набросок 20

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

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

Набросок 21

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

Набросок 22

Заключение

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