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

OSzone.net » Microsoft » Sharepoint » Диагностика Kerberos в среде Sharepoint (часть 3)
Автор: Джеспер Кристенсен
Иcточник: winsecurity.ru
Опубликована: 31.07.2009

Я бы хотел начать этот раздел с объяснения того, что собой представляет «Делегирование Kerberos (Kerberos Delegation)» и когда его нужно настраивать. В предыдущей части я рассказал о шагах конфигурации, но делегирование не всегда нужно, поскольку все зависит от вашей ситуации, от дизайна приложений и требований безопасности.

Kerberos Delegation позволяет продвигать аутентифицированные учетные записи через несколько серверов, используя заимствование прав (impersonation). Проблема обычно называется ‘double-hop issue’, и вы столкнетесь с ней при использовании Excel Calculation Services (ECS). Когда мы настроим доверие делегированию и воспользуемся заимствованием прав для мандатов учетной записи пользователя, мы тем самым обеспечим нужный уровень доступа по всей системе. Еще одним примером является ситуация, когда пользователь запрашивает данные с веб приложения. Веб приложение делает запрос в базу данных SQL на другом физическом сервере, и поэтому использует заимствование прав. Если используется делегирование и заимствование прав, сервер SQL возвращает только те данные, к которым у пользователя есть доступ.

*

Рисунок 22: Два физических транзитных участка, ведущих к проблеме double-hop issue

Давайте настроим тестовую среду и посмотрим, какие типы ошибок у нас будут в случае, когда делегирование не настроено должным образом. У меня есть рабочая страница aspx-page, отображающая данные пользовательской базы данных на сервере SQL.

*

Рисунок 23: Рабочий запрос на сервер SQL

Делегирование Kerberos уже настроено корректно в нашей демонстрационной среде, но давайте посмотрим, что произойдет, если мы удалим доверие для делегированных прав учетной записи пула приложений (Application Pool account); SPContentPoolAcct. На рисунке 24 показана текущая конфигурация этой учетной записи.

*

Рисунок 24: Корректная настройка ограниченного делегирования

Теперь я попробую удалить доверие правам службы MSSQLSvc, выделенной желтым на рисунке, и выполнить IISRESET /NOFORCE на сервере SharePoint WSS1. С отсутствием этих прав учетная запись SPContentPoolAcct больше не сможет заимствовать права пользовательских мандатов и представлять их серверу SQL. Теперь пользователь получит стандартную ошибку Microsoft SharePoint, как показано на рисунке 25.

*

Рисунок 25: SharePoint страница возвращает стандартное сообщение об ошибке

Итак, это статья по диагностированию, поэтому нам лучше приступить именно к нему. Прежде всего, мы не многое сможем сделать с этой стандартной ошибкой. Будучи администратором, я могу отключить ее в файле web.config, расположенном в системных файлах сервера Microsoft SharePoint Web FrontEnd (WFE).

В тестовой среде он расположен в: C:\inetpub\wwwroot\wss\VirtualDirectories\intranet.domain.local80

Отключение пользовательских сообщений об ошибке в Microsoft SharePoint

Примечание: Это нужно сделать на всех имеющихся у вас серверах Microsoft SharePoint WFE

  1. Сделайте копию файла web.config, прежде чем редактировать его (просто чтобы убедиться, что мы не сильно навредим)
  2. Откройте его в своем любимом текстовом редакторе, например блокноте
  3. Найдите строку <customErrors mode="Off" /> и измените ее на <customErrors mode="On" />
  4. Найдите строку CallStack="true" и измените ее на CallStack="false"
  5. Перезапустите свой сервер Internet Information Server (IIS) с помощью командной строки: IISRESET /NORFORCE

Теперь давайте еще раз посмотрим на страницу:

*
Увеличить

Рисунок 26: Страница SharePoint возвращает подробный отчет об ошибке

Это дает нам немного больше информации о проблеме, и страница четко указывает на то, что это ошибка входа клиента SQL: System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

Попытка анонимного входа была предпринята кодом .NET и поэтому наша пользовательская учетная запись (DOMAIN\Administrator вошел на рабочую станцию в попытке загрузить страницу) не использовалась в этом процессе. Для дополнительной информации об этой проблеме мы можем взглянуть на журнал регистрации событий (Application event log) на сервере SharePoint (в этом случае у нас есть только один, но если у вас есть несколько серверов WFE в Network Load balanced Network (NLB), вам нужно проверить каждый лог, чтобы найти сообщение об ошибке).

В Event Viewer на WSS1 мы нашли предупреждение:

Warning, ASP.NET 2.0.50727.0, Event ID: 1039, Category:Web EventEvent code: 3005 Event message: An unhandled exception has occurred ‘ ‘ User: DOMAIN\Administrator Is authenticated: True Authentication Type: Negotiate Thread account name: DOMAIN\spcontentpoolacct Thread information: Thread ID: 4 Thread account name: DOMAIN\spcontentpoolacct Is impersonating: False ‘ ‘

*

Рисунок 27: Предупреждение с журнала регистрации событий на сервере WSS1 SharePoint WFE

Информация в логе говорит нам о том, что .NET сгенерировал веб предупреждение. Пользователь, активировавший его, был аутентифицированным пользователем DOMAIN\Administrator, а учетная запись процесса – это DOMAIN\spcontentpoolacct (наш пользователь пула веб приложений). Здесь мы также видим, что пользователь-процесс не заимствует права учетной записи действительного пользователя. Итак, заимствование прав не использовалось для кода .NET и в этом заключается проблема (Is impersonating: False).

Проверка конфигурации делегирования Kerberos, включающая:

Примечание:обратите внимание, что я пропустил конфигурацию делегирования на DOMAIN\SPContentPoolAcct. Просто добавьте информацию и перезапустите службу IIS на сервере SharePoint WFE.

Kerberos для Shared Service Provider (SSP)

До того как обновление Infrastructure Update (июль 2008) для Microsoft Office Servers было выпущено, аутентификация Kerberos не полностью поддерживалась для Shared Service Provider. Это вызывало определенные проблемы с несколькими SSPs и функцией поиска. Поэтому я рекомендую вам установить это обновление на свои системы, если вы еще этого не сделали. Компания Microsoft позже опубликовала некоторые кумулятивные обновления, которые включают это обновление инфраструктуры, поэтому вы можете обратиться к веб-сайту Microsoft Team Blog за самыми свежими рекомендуемыми обновлениями. Ссылка на этот сайт приведена в конце статьи.

В этом обновлении компания Microsoft добавила специальный формат Service Principal Name (SPN): MSSP/<host:port>/<SSP name>.

Для подробной информации о настройке SSP с помощью этого формата SSP посетите веб сайт TechNet, ссылка на который приведена в конце статьи. Я лишь приведу краткий обзор шагов по настройке Kerberos, которые были указаны в статье на TechNet о Shared Services Provider.

Shared Services Provider (SSP)

*

Рисунок 28: Service Principal Name регистрация для SSP

Различные проблемы и заметки

Учетные записи пользователей и служб SharePoint

Нужно проверить, не заблокированы ли учетные записи пользователей или SharePoint в домене, а также проверить истечение срока действия пароля. Политика компании в этом случае должна применяться в вашей среде.

Безопасное соединение учетных записей компьютера

Некоторые клиенты/серверы не могут установить корректное защищенное соединение с доменом, а Kerberos построена на таком типе безопасной инфраструктуры. Если это случается, вам нужно обновить и заново создать эти взаимоотношения. В статье Microsoft Knowledgebase KB216393 (смотреть раздел дополнительных ссылок в конце статьи) предоставлены инструкции по данной процедуре.

Если ваш сервер/клиент был клонирован, вам нужно сгенерировать новый ID безопасности (SID), и рекомендуемым способом сделать это является использование утилиты Microsoft sysprep. Еще одним способом сделать это является использование ранее известной утилиты Sysinternals, которая теперь называется Microsoft NewSID.

Проблемы с размерами MTU

Сетевые пакеты, передаваемые по проводам, имеют определенную длину. Если учетная запись является членом большого количества групп, это может быть заметно. Еще одним способом исправления проблемы MTU является принуждение Kerberos на использование TCP. Информацию об этом можно найти в статье базы знаний Microsoft KB244474 (смотреть раздел ссылок в конце статьи).

Несколько веб приложений с различными способами аутентификации

Отключите согласование на веб приложениях, если они не нуждаются в использовании аутентификации Kerberos. Если у вас есть несколько веб приложений на одном сервере, и вы используете Kerberos на некоторых веб приложениях и NTLM, у вас могут возникать проблемы. Особенно если приложения используют одно имя сервера и разные номера портов, а использование различных учетных записей пулов приложений обычно заставляет прибегать к нескольким часам диагностирования систем. Хотя я встречался с такими типами конфигураций в малых установках.

Я бы хотел дать несколько советов по веб приложениям

Проверьте, настроено ли Kerberos для ваших веб приложений

Запустите интерпретатора команд.

cd c:\inetpub\adminscripts cscript adsutil.vbs get w3svc/<id of your website>/root/NTAuthenticationProviders (вы найдете I.D своего веб сайта через IIS Management в identifier) Для Kerberos результат будет: NTAuthenticationProviders : (STRING) "Negotiate,NTLM"Для NTLM результат будет: NTAuthenticationProviders : (STRING) ‘NTLM"

Настройте IIS веб сайт на другой способ (в этом примере Kerberos), используя следующую команду:

cd c:\inetpub\adminscripts cscript adsutil.vbs set w3svc/<id of your website>/root/NTAuthenticationProviders ‘Negotiate,NTLM’

Это нужно на каждом сервере SharePoint, граничащем с web.

SQL Server 2005 сценарий для проверки метода аутентификации пользователей

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

SELECT DB_NAME(dbid) AS DatabaseName, loginame AS LoginName, sys.dm_exec_connections.auth_scheme as AuthMethod FROM sys.sysprocesses JOIN sys.dm_exec_connections ON sys.sysprocesses.spid=sys.dm_exec_connections.session_id WHERE dbid > 0 GROUP BY dbid, loginame, spid,sys.dm_exec_connections.auth_scheme

Результаты этой команды в моей тестовой среде (включая вышеприведенный пример CompanyDatabase) показаны на рисунке 29 ниже.

*

Рисунок 29: Результаты использования сценария в SQL Management Studio

Заключение

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

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

Ссылки


Ссылка: http://www.oszone.net/9502/Kerberos_SharePoint