Диагностика Kerberos в среде SharePoint (часть 1)

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

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

Установка

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

DC1 Контроллер домена (KDC) SQL1 SQL Server 2008 WSS1 Windows Sharepoint Services 3.0 SP1 (+обновление инфраструктуры) PC1 Windows Vista

Главные имена служб (Service Principal Names - SPNs) и делегирование настроено в соответствии с нижеприведенной таблицей.

Где инструменты?

Когда мы диагностируем ошибки, нам необходим набор инструментов. В этой серии статей мы будем использовать лишь некоторые из них, но для вас я приведу список инструментов диагностирования:

• Журнал регистрации событий Windows на клиентах и серверах
• Файлы логов IIS на внешних веб серверах, SQL серверах и контроллерах домена
• Файлы логов SharePoint
• Инструменты командной строки - setspn (из пакета ресурсов Windows Server, Windows Server 2008 имеет такой инструмент по умолчанию) - ldifde - KList (из пакета ресурсов Windows Server, Windows Server 2008 имеет такой инструмент по умолчанию)
• Инструменты GUI - KerbTray (из пакета ресурсов Windows 200 Server, работает на всех версиях Windows) - ADSIEdit - Network Monitor - WireShark анализатор сетевых пакетов

Некоторые полезные команды отчистки для тестирования:

• DNS кэш: Ipconfig /flushdns
• NetBIOS кэш, который вы вводите: Nbtstat ‘R
• Мандаты Kerberos: Klist purge (Мы также можем просматривать зарегистрированные интерактивные мандаты пользователя Kerberos с помощью KerbTray)

При анализе процедуры входа в Kerberos очень удобно иметь следующую таблицу действий.

Проблемы для рассмотрения

Есть некоторые проблемы, с которыми я сталкиваюсь чаще чем с другими на потребительских серверах, поэтому ниже приведен список проблем, которые будут рассмотрены в этой статье:

• Дата и время
• Учетные записи пула приложений (Application pool accounts)
• SPN конфигурация

В этой части серии мы поговорим о том, что можно увидеть в журнале регистрации событий Windows и в анализаторе сетевых протоколов для каждой проблемы, которую мы создадим.

Время и дата

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

Разница времени на сервере SharePoint

Я настроил сервер SharePoint WSS1 так, что он имеет разницу во времени на 24 часа, и ошибки возникают в системном журнале регистрации событий Windows System.

Предупреждение, W32Time, Event ID: 52, Category: None Служба времени установила время со смещением в 86391 секунд (The time service has set the time with offset -86391 seconds)

Обычно серверы синхронизируют время автоматически и ошибки исчезают. Так было и здесь ‘ поэтому не потребовалось никакого вмешательства со стороны администратора.

Иногда у контроллеров домена могут возникать проблемы синхронизации времени. Я тестировал такую ситуацию путем изменения времени на контроллере домена, и Kerberos выдал мне отчет в журнале LSASRV event id 40960.

Warning, LSASRV, Event ID: 40960, Category: SPNEGO (Negotiator) Система безопасности обнаружила ошибку аутентификации для сервера MSSQLSvc/sql1.domain.local:1433. Код ошибки аутентификации протокола Kerberos был следующим: «Время на основном контроллере домена отличается от времени на резервном контроллере домена или сервере-участнике слишком сильно (0xc0000133). (The security System detected an authentication error for the server MSSQLSvc/sql1.domain.local:1433. The failure code from authentication protocol Kerberos was ‘The time at the Primary Domain Controller is different than the time at the Backup Domain Controller or member server by too large an amount. (0xc0000133))’.

Ошибки времени и даты легко обнаружить и исправить ‘ просто настройте время или откройте требуемый порт брандмауэров, если пакеты синхронизации времени не проходят. В виртуальных средах проблемы синхронизации времени могут вызывать более серьезные трудности, поскольку виртуальные аппаратные часы виртуальной машины могут отличаться от других виртуальных узлов сервера.

Учетные записи пула приложений (Application pool accounts)

Веб сайты IIS для веб приложений автоматически настраиваются в SharePoint и при их создании нужно выбрать/добавить Пулы приложения (Application Pools). Веб приложение запускается в этом пуле и с его настроенной идентификацией (пользователем).

Изменение учетной записи пула приложений вручную

Веб сайты запускаются в пулах приложений IIS, и они не предназначены для ручной настройки. Если администратор меняет идентификацию пула приложения на неправильную учетную запись, это может сделать веб сайт недоступным. Может потребоваться настройка, если изменяется пользователь.

Я попытаюсь изменить учетную запись пула приложения на domain\spwrongacct для нашего веб сайта http://intranet.domain.local.

Это вызовет следующие ошибки в журнале регистрации событий Windows System на сервере SharePoint:

Warning, W3SVC, Event ID: 1012, Category: None Идентификация пула приложения 'SharePoint - intranet.domain.local - 80' недействительна. Если она останется недействительной во время обработки первого запроса на пул приложения, то пул приложения будет отключен. Поле данных содержит номер ошибки. (The identity of application pool, 'SharePoint - intranet.domain.local - 80' is invalid. If it remains invalid when the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.)

Warning, W3SVC, Event ID: 1057, Category: None Идентификация пула приложения 'SharePoint - intranet.domain.local ‘ 80' недействительна, поэтому служба публикации World Wide Web Publishing Service не может создать рабочий процесс для обслуживания этого пула приложения. Поэтому пул приложения был отключен. (The identity of application pool 'SharePoint - intranet.domain.local ‘ 80' is invalid, so the World Wide Web Publishing Service cannot create a worker process to serve the application pool. Therefore, the application pool has been disabled.)

Error, W3SVC, Event ID: 1059 Во время запуска процесса обслуживания пула приложения 'SharePoint - intranet.hendriksen.dk80' была обнаружена ошибка. Пул приложения был отключен. (A failure was encountered while launching the process serving application pool 'SharePoint - intranet.hendriksen.dk80'. The application pool has been disabled.)

-а ошибка на клиентских компьютерах, пытающихся получить доступ к веб сайту, будет следующая: Служба недоступна (Service Unavailable)

Для исправления этой ошибки нужно изменить учетную запись на ту, которая настроена в конфигурации SharePoint и снова запустить пул приложения из консоли управления IIS. Если вам нужно изменить пользователя/пароль в конфигурации SharePoint, следуйте шагам, описанным в следующей статье базы знаний Microsoft Knowledgebase.

Конфигурация Service Principle Name (SPN)

Конфигурации SPNs также очень важны для работы аутентификации Kerberos. Сначала я вкратце опишу, как они используются между клиентами и серверами.

1. Типы пользователей в URL в обозревателе Internet Explorer (например, http://intranet.domain.local)
2. Клиентский браузер строит SPN, которое содержит имя узла и тип службы (SPN: http/intranet.domain.local ‘ Service type: HTTP Name: intranet.domain.local)
3. Клиент отправляет запрос в KDC на получение мандата для этого SPN
4. Сервер KDC шифрует мандат, используя публичный ключ регистрированной учетной записи (domain\spcontentpoolacct) и отправляет мандат клиенту
5. Клиент аутентифицируется на сервере SharePoint, отправляя мандат
6. Сервер SharePoint дешифрует мандат на учетной записи пула приложения (его идентификации) и проверяет содержимое
7. Пользователь аутентифицируется или на клиентский браузер/журнал регистрации событий отправляется отчет об ошибке
8. Если пользователь не проходит аутентификацию Kerberos, предпринимается попытка NTLM аутентификации

Отсутствие SPN для веб приложения

Сейчас, путем удаления сопоставления SPN с учетной записью, мы посмотрим, что произойдет, если клиент не может получить мандат с KDC.

Удаляем неправильную учетную запись: SETSPN ‘D HTTP/intranet.domain.local domain\spwrongpoolacct

Затем входим на веб сайт с PC1, http://intranet.domain.local, и у нас открывается стандартная страница веб сайта. ‘но как мы аутентифицировались?

Если мы проверим журнал регистрации событий клиента Windows, мы не найдем там никаких записей. Однако, в журнале регистрации событий безопасности Windows Security на сервере SharePoint у нас будет следующий отчет:

Audit Success, Event ID: 4624, Category: Logon‘ Logon process: NtLmSsp Authentication Package: NTLM ‘

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

Поскольку SPN отсутствует, Active Directory отправит KDC_ERR_S_PRINCIPAL_UNKNOWN. Это сообщение, говорящее о том, что Active Directory не может найти соответствующее SPN для данного веб сайта.

Настройка неправильной учетной записи в Active Directory для SPN

Если ключ дешифровки не соответствует шагу 6, это означает, что ключ шифрования идет с другой учетной записи и где-то в конфигурации есть ошибка. Давайте настроим SPN на использование неправильной учетной записи и посмотрим результаты этого

Удаляем правильную учетную запись: SETSPN ‘D HTTP/intranet.domain.local domain\spcontentpoolacct Добавляем неправильную учетную запись: SETSPN ‘A HTTP/intranet.domain.local domain\spwrongpoolacct

Если мы проанализируем пакеты с сервера SharePoint, то увидим эту коммуникацию при выполнении iisreset /noforce и входе в веб приложение.

Сервер SharePoint получает информацию Kerberos с KDC и использует ее для дешифровки мандата. Если она не соответствует, то генерируется ошибка, которая отправляется клиенту.

В журнале Windows System клиента мы видим ошибку:

Error, Event ID: 4, Category: NoneКлиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера wss1$. Целевое имя, которое использовалось, было HTTP/intranet.domain.local. Это указывает на то, что целевой сервер не смог расшифровать мандат, предоставленный клиентом. Такое возникает, когда SPN целевого сервера зарегистрировано на учетной записи, отличной о той, которая используется целевой службой. Пожалуйста, убедитесь, что целевое SPN зарегистрировано на той учетной записи, которая используется сервером, и только на ней. Такая ошибка может возникать, когда целевая служба использует иной пароль для учетной записи целевой службы, а не тот пароль, который Kerberos KDC имеет для учетной записи целевой службы. Пожалуйста, убедитесь, что служба на сервере и KDC обновлены для использования текущего пароля. Если имя сервера не является полным именем, а целевой домен (DOMAIN.LOCAL) отличается от клиентского домена (DOMAIN.LOCAL), проверьте наличие двух учетных записей с идентичными именами в этих двух доменах, или используйте полное имя(fully-qualified name) для идентификации сервера.

Когда внешний веб сервер пытается расшифровать мандат службы, ключ является неправильным, так как мандат был зашифрован с помощью ключа учетных записей SPN (domain\spcontentpoolacct) и расшифровывается с помощью частного ключа учетной записи пула приложений (domain\spwrongacct). Ошибка KRB_AP_ERR_MODIFIED будет отправлена клиенту и появится в журнале Windows System.

Среда корректно перенастроена для учетной записи domain\spcontentpoolacct:

Удаляем неправильную учетную запись : SETSPN ‘D HTTP/intranet.domain.local domain\spwrongpoolacct Добавляем правильную учетную запись: SETSPN ‘A HTTP/intranet.domain.local domain\spcontentpoolacct

Заметка: Ошибка KRB_AP_ERR_MODIFIED может быть вызвана прочими неточностями в конфигурации.

Заключение

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

В следующих частях этой серии мы рассмотрим следующие типичные проблемы:

• Дупликация имен SPN
• Несоответствие конфигурации DNS
• Делегирование, когда оно используется и как его проверять
• Shared Service Provider (SSP), является ли он Kerborized?
• Дополнительная работа с анализатором сетевых пакетов

Дополнительные ссылки

• Microsoft Knowledge base: How to enable Kerberos event logging (KB262177)
• Microsoft Knowledge base: How to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0 (KB 934838)
• Network Protocol Analyzer: http://www.wireshark.org/