Kerberos в среде Sharepoint
Службы Microsoft Windows Sharepoint Services (WSS) 3.0 и Microsoft Office Sharepoint Server (MOSS) 2007 предназначены для централизации информации о компании и повышения эффективности совместной работы членов группы. Пользователи могут получить доступ ко всей информации, доступной для их индивидуальных учетных записей, с веб-сайтов Sharepoint. Из-за такого дизайна вам необходимо убедиться, что аутентификация выполняется быстро, безопасно и соответствует политикам компании.
В этой статье я расскажу об основах использования Kerberos в среде Sharepoint. В Интернете вы найдете множество руководств по настройке для различных сценариев, и я подготовил для вас несколько советов. Я надеюсь, что это может дать вам обзор для работы в вашей собственной среде.
Используете Kerberos в Sharepoint?
Kerberos — это безопасный протокол, который предоставляет билеты проверки подлинности, если запрос клиента к центру распространения ключей (KDC) содержит действительные учетные данные пользователя и действительное имя участника-службы (SPN). Kerberos является предпочтительным типом проверки подлинности для Sharepoint, поскольку он быстрее, безопаснее и снижает количество ошибок, которые вы можете получить с именем пользователя и паролем, чем NTLM. Если веб-сайт Sharepoint использует внешние данные (расположенные на серверах, отличных от вашего сервера Sharepoint), напр. к базам данных SQL через веб-части серверу Sharepoint требуется Kerberos для делегирования учетных данных клиента (учетные данные никогда не отправляются по сети, только билеты, которые отслеживает KDC).
Так что же происходит между клиентом и серверами, когда вы пытаетесь получить доступ к веб-сайту с поддержкой Kerberos? Я сделал небольшой наглядный обзор, чтобы показать, что происходит «за кулисами». Этот сценарий, показанный на рис. 1, состоит из служб Windows Sharepoint Services 3.0, которые также являются основой для MOSS. Технология Kerberos такая же — просто у нас больше сервисов и ролей в MOSS.
Рис. 1. Kerberos в потоке Sharepoint
- Клиент получает доступ к http://intranet.domain.local, используя анонимные учетные данные.
- Сервер WSS возвращает ошибку IIS 401.2, но также возвращает заголовок WWWAuthenticate.
- Клиент запрашивает билет для имени участника-службы, созданного локальным интернет-браузером: HTTP/intranet.domain.local.
- KDC возвращает билет, если имя участника-службы найдено. Это шифруется с помощью главного ключа зарегистрированной учетной записи для SPN (доменspcontentpool).
- Клиент аутентифицируется с помощью билета для веб-приложения.
- Учетная запись веб-приложения расшифровывает билет и проверяет его.
- Учетная запись веб-приложения запрашивает билет для имени участника-службы, созданного клиентом SQL: MSSqlSvc/sql1.domain.local:1433.
- KDC возвращает билет, если имя участника-службы найдено. Это шифруется с помощью главного ключа зарегистрированной учетной записи для имени участника-службы (доменsqlsvsacct).
- Служба веб-приложения выполняет аутентификацию в базе данных SQL с помощью билета учетной записи веб-приложения и олицетворяет пользователя, используя права делегирования.
- Учетная запись службы SQL расшифровывает билет и проверяет его.
- Сервер SQL возвращает данные запроса на сервер WSS.
- Сервер WSS возвращает веб-страницу.
Если Kerberos не настроен для связи SQL, шаг 6 переходит к шагу 12. И помните, что выдача билетов происходит только при первом входе в систему и длится до истечения времени ожидания. В разделе ссылок вы найдете блок-схему в большем масштабе со встроенным текстом на стрелках.
Настройка Kerberos для Sharepoint
Прежде всего позвольте мне призвать вас создать тестовую установку, прежде чем перенастраивать производственную среду. Я знаю, что это больно, но если вы используете виртуальные серверы, вы можете очень быстро создавать тестовые серверы. Это также позволяет вам сравнить окончательную конфигурацию с тем, если что-то работает не так, как ожидалось.
Поэтому нам нужно отказаться от NTLM в наших веб-приложениях и настроить их для использования Kerberos. Сначала вы включаете этот протокол для связи между внешним и внутренним серверами. Затем вы включаете Kerberos между клиентами и отдельными веб-приложениями для обработки аутентификации через сервер Sharepoint (некоторые называют это аутентификацией с двойным или двойным переходом).
Давайте взглянем на список дел для настройки.
- Соберите необходимую информацию и создайте пользователей Sharepoint
- Включить Kerberos для связи SQL
- Настройка имен участников службы (SPN) в Active Directory
- Настройте «Доверие для делегаций» для учетных записей компьютеров/пользователей.
- Настройка служб компонентов на серверах Sharepoint
- Включите Kerberos для веб-приложений и поставщика общих услуг (SSP).
- Протестируйте среду Sharepoint=
Соберите необходимую информацию
Чтобы сделать нашу реализацию максимально безболезненной, нам нужно подготовить все строительные блоки. Я предполагаю, что в вашей среде работает Active Directory, и каждый сервер имеет уникальный IP-адрес. Это должно быть зарегистрировано на вашем DNS-сервере, и для работы Kerberos не должно существовать его дубликатов в зоне прямого или обратного просмотра. Кроме того, все клиенты и серверы должны иметь правильную дату и время, поскольку Kerberos также использует их для проверки билетов и доступа к внутреннему DNS-серверу.
Перед установкой Sharepoint создайте соответствующих пользователей в Active Directory (см. раздел ссылок для ссылки на официальные рекомендации). Если вы уже создали необходимые учетные записи, продолжайте читать.
Вот список информации, необходимой для настройки Kerberos в среде Sharepoint.
- Класс обслуживания имени участника-службы
(HTTP для веб-приложений WSS/MOSS. MSSQLSvc для экземпляра SQL Server по умолчанию) - Имена хостов ваших SPN (только имя хоста. Обычно полное доменное имя без доменной части)
- Полное доменное имя (FQDN) всех веб-приложений и серверов.
- Номера портов или ваши имена участников-служб (нет порта для веб-приложений WSS и MOSS. 1433 для SQL).
- Учетные записи Active Directory для ваших SPN (учетные записи службы и пула приложений)
Включить Kerberos для связи SQL
Microsoft настоятельно рекомендует сделать это перед установкой Microsoft Sharepoint, чтобы убедиться, что ваша связь SQL работает. База данных конфигурации находится на вашем SQL Server, и если соединение разорвано, вам необходимо исправить его, прежде чем сайты Sharepoint снова заработают. Если вы измените аутентификацию после первоначальной установки, по крайней мере, сначала отключите службы Sharepoint, чтобы избежать потери данных.
Вы включаете Kerberos между внешними серверами Sharepoint и вашим SQL Server следующим образом:
- Настройка SPN для него
- Настройка доверия для делегирования, если вам нужно олицетворять пользователей для других служб.
Нет необходимости включать Kerberos для связи SQL, если вам нужно аутентифицировать клиентов только для внешнего интерфейса Sharepoint, а не для других подключений к данным/служб Excel/служб отчетов SQL.
Настройка имен участников службы (SPN) в Active Directory
Сопоставления имени субъекта-службы используются Kerberos, чтобы позволить делегированию службы олицетворять конкретную учетную запись пользователя. SPN содержит класс обслуживания, имя хоста и иногда номер порта. Некоторые примеры: HTTP/intranet.domain.local и MSSqlSvc/sql1.domain.local:1433. Хорошей практикой является регистрация как имени хоста, так и полного доменного имени ваших веб-приложений, даже если вы собираетесь использовать только одно из них.
Для настройки имен субъектов-служб можно использовать несколько инструментов. Я предпочитаю инструмент SetSPN, установленный в Windows Server 2008 по умолчанию. Для Windows Server 2003 его можно найти в инструментах поддержки на установочном компакт-диске или в наборе ресурсов, который можно загрузить с сайта Microsoft. Вы также можете использовать ADSIedit для настройки имен участников-служб, но для навигации по Active Directory, редактирования элементов и изменения их ServicePrincipalName требуется немного больше работы.
Команда для регистрации SPN: setspn.exe -A HTTP/intranet.domain.local DOMAINAccount
Команда для вывода списка SPN для учетной записи: setspn.exe -L DOMAINAccount
Команда для удаления SPN: setspn.exe -D HTTP/intranet.domain.local DOMAINAccount
Используйте таблицы на рис. 2 или 3, чтобы увидеть необходимые регистрации для вашего SQL в сценарии MOSS/WSS.
Рис. 2. Делегирование и имена участников-служб для MOSS
Рис. 3. Делегирование и имена участников-служб для WSS
Настройте «Доверие для делегаций» для учетных записей компьютеров/пользователей.
Теперь нам нужно обработать права делегирования в Active Directory. Это делается для компьютеров и учетных записей пользователей, которые вы можете увидеть в таблице выше. В разделе «Пользователи и компьютеры Active Directory» щелкните правой кнопкой мыши учетную запись, выберите свойства и проверьте доверие делегирования (см. снимки экрана 4 и 5 ниже). Текст/процедура могут различаться в разных версиях Windows Server.
Рисунок 4: Делегирование учетной записи компьютера
Рис . 5. Делегирование учетных записей пользователей
См. рис. 2 или 3, для каких учетных записей следует настроить делегирование в сценарии.
Настройка служб компонентов на серверах Sharepoint
Учетные записи пула веб-приложений должны иметь определенные права, иначе вы получите ошибку DCOM с идентификатором события 10017 в журнале событий, описанную в Microsoft KB920783:
«Параметры разрешений для конкретных приложений не предоставляют разрешение на локальную активацию для приложения COM-сервера с CLSID { CLSID } пользователю DomainName UserName SID { SID }. Это разрешение безопасности можно изменить с помощью инструмента администрирования Component Services».
Для правильной настройки безопасности учетных записей просто зайдите в Панель управления, Службы компонентов, Компьютеры, Мой компьютер, Конфигурация DCOM и отредактируйте свойства «Службы администратора IIS WAMReg». Отредактируйте «Запуск и активация» на вкладке «Безопасность» и предоставьте права «Локальная активация» для всех учетных записей пула приложений (см. рис. 2 или 3).
Пока вы находитесь в службах компонентов, установите «Уровень олицетворения по умолчанию» на «Делегирование», отредактировав свойства «Моего компьютера». Проверьте Microsoft KB917409 для получения дополнительной информации.
Включите Kerberos для веб-приложений и поставщика общих услуг (SSP).
Итак, ваша базовая конфигурация почти готова. Чтобы использовать Kerberos, вы должны включить его через центр администрирования для своих веб-приложений. Мы можем выбирать между NTLM и Kerberos для отдельных веб-приложений на странице «Поставщики аутентификации», которую вы найдете на панели «Управление приложениями». Следуйте по этому пути для конфигурации:
- Центральное администрирование, управление приложениями, поставщики аутентификации
- Выберите веб-приложение, для которого вам нужно использовать Kerberos, например:
- Нажмите «По умолчанию»
- Выберите/отметьте опцию Kerberos:
Не забудьте перезапустить IIS с помощью команды iisreset /noforce в командной строке на интерфейсных веб-серверах.
В MOSS также необходимо настроить поставщика общих услуг, и вы делаете это в командной строке. Команда SetSharedWebServiceAuthn не существует в WSS. Перейдите в каталог bin с 12 кустами (обычно он находится в C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12in ) и выполните команду: stsadm.exe -o SetSharedWebServiceAuthn -negotiate
Протестируйте среду Sharepoint
Теперь наступает захватывающая часть операции: убедиться, что все работает так, как мы ожидаем. Как и любой другой человек, я проверяю изменения конфигурации, пока выполняю процедуры. Прежде чем переходить к другим шагам, полезно знать, использует ли ваша связь SQL протокол Kerberos. Но как проверить отдельные части установки?
Вы просто проверяете журнал событий безопасности на наличие событий входа в систему Kerberos. Убедитесь, что используемая учетная запись домена работает успешно. Если учетная запись получает журнал об ошибке, проверьте следующее:
- Дата и время установлены правильно на всех серверах
- Что учетная запись не залочена в домене
- Служба или пул приложений работают с правильной учетной записью
- Делегирование настроено правильно на компьютерах и учетных записях пользователей.
- SPN правильно настроены в Active Directory
- В прямой и обратной зонах DNS не должно быть дубликатов на серверах.
- DNS-серверы указаны корректно на всех серверах
Известная проблема с Internet Explorer
Если вы используете порты не по умолчанию на своих виртуальных серверах IIS, убедитесь, что ваша версия Internet Explorer 6 или более ранняя версия исправлена и настроена для включения номеров портов в SPN. Центр администрирования будет содержать нестандартный номер порта. Вы не получите сообщение об ошибке, в котором говорится, что это ошибка, если вы используете старую или ненастроенную версию Internet Explorer. Прочтите статью Microsoft, которую я упомянул в разделе ссылок этой статьи, касающуюся этой проблемы. Мне сказали, что в Internet Explorer 7 была та же проблема, но она была исправлена.
Резюме
Microsoft Windows Sharepoint можно использовать в сложных средах, где требуется безопасная аутентификация с помощью Kerberos. В этой статье я надеюсь объяснить «общую картину» Kerberos в настройке Sharepoint. Инструменты и базовые конфигурации доступны, так что вы можете начать использовать замечательные функции аутентификации с двойным переходом Sharepoint самостоятельно.
Ссылки
Microsoft TechNet: планирование административных и сервисных учетных записей
Технет Майкрософт: Настроить аутентификацию Kerberos
Документация Microsoft TechNet SetSPN-Tool: Обзор SetSPN
Microsoft Download SetSPN-Tool: Windows 2000 Server и Windows Server 2003 SP2, 32-разрядная версия
Microsoft TechNet: устранение неполадок делегирования Kerberos
Служба поддержки Microsoft: устранение неполадок, связанных с сообщением об ошибке «Не удается создать контекст SSPI»
Поддержка Microsoft: Internet Explorer 6 не может использовать протокол проверки подлинности Kerberos для подключения к веб-сайту, который использует нестандартный порт в Windows XP и Windows Server 2003.
Блог Джеспера М. Кристенсена: Kerberos в потоке Sharepoint со встроенным текстом
Блог Джеспера М. Кристенсена: Устранение ошибки Kerberos KRP_AP_ERR_MODIFIED