Kerberos в среде Sharepoint

Microsoft Windows Sharepoint Services (WSS) 3.0 и Microsoft Office Sharepoint Server (MOSS) 2007 созданы для централизации информации компании и помощи членам команды в более успешном сотрудничестве. Пользователи имеют доступ ко всей информации, к которой разрешен доступ их учетным записям, с веб сайтов Sharepoint. В силу особенностей конструкции, вы должны убедиться, что аутентификация быстрая, безопасная и отвечает требованиям политики вашей компании.

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

Использовать Kerberos в Sharepoint?

Kerberos – это протокол безопасности, предоставляющий билеты аутентификации, если запрос клиента на Key Distribution Center (KDC) содержит действительные мандаты и действительное имя Service Principal Name (SPN). Kerberos является предпочтительным типом аутентификации для Sharepoint, так как он быстрее, безопаснее и снижает количество ошибок, которые вы можете получить с именем пользователя и паролем по сравнению с NTLM. Если веб сайт Sharepoint использует внешние данные (расположенные не на том сервере, на котором расположен сам сервер Sharepoint), к примеру, SQL базы данных через веб части, то сервер Sharepoint нуждается в Kerberos для делегирования клиентских мандатов (мандаты, которые никогда не посылаются по проводу, только билеты, которые отслеживает KDC).

Так что же происходит между клиентом и сервером, когда вы пытаетесь получить доступ к веб сайту с поддержкой Kerberos? Я сделал небольшое визуальное пособие, чтобы показать, что происходит «за кулисами». Сценарий, показанный на рисунке 1, состоит из Windows Sharepoint Services 3.0, которая также является базой для MOSS. Технология Kerberos остается той же ' у нас просто есть больше служб и ролей в MOSS.

Рисунок 1: Kerberos в потоке Sharepoint

1. Клиент входит на http://intranet.domain.local, используя анонимные мандаты.
2. WSS сервер возвращает IIS ошибку 401.2
, а также возвращает WWWAuthenticate заголовок.
3. Клиент запрашивает билет для SPN, созданный локальным интернет обозревателем: HTTP/intranet.domain.local
4. KDC возвращает билет, если SPN обнаружен. Это зашифровано с помощью ключа зарегистрированной учетной записи для SPN (domain\spcontentpool).
5. Клиент аутентифицируется с билетом для веб приложений.
6. Учетная запись Web App расшифровывает билет и подтверждает его.
7. Web App учетная запись запрашивает билет для SPN, созданный SQL клиентом: MSSqlSvc/sql1.domain.local:1433.
8. KDC возвращает билет, если SPN найден. Это зашифровано с помощью ключа зарегистрированной учетной записи для SPN (domain\sqlsvsacct).
9. Служба веб приложения аутентифицируется в базе данных SQL, используя билет учетной записи Web App, и олицетворяет пользователя с помощью делегирования прав.
10. Учетная запись службы SQL расшифровывает билет и подтверждает его.
11. SQL сервер возвращает запрос данных на WSS сервер.
12. WSS сервер возвращается на веб страницу.

Если Kerberos не настроен для SQL взаимодействий, шаг 6 переходит на шаг 12. И запомните, что принятие билета происходит только при первом входе и длиться до истечения срока. Сопоставьте номера стрелок структурной схемы с пунктами представленными ниже.

Настройка Kerberos для Sharepoint

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

Итак, нам нужно отключить NTLM на наших веб приложениях и настроить их на использование Kerberos. Для начала включите этот протокол для соединений между внешним и внутренним серверами. Затем вы включаете Kerberos между клиентами и отдельными веб приложениями, чтобы управлять аутентификацией через Sharepoint сервер (некоторые называют ее dual- или double-hop аутентификацией).

Сначала давайте посмотрим на список того, что нужно для настройки.

• Сбор необходимой информации и создание Sharepoint пользователей
• Включение Kerberos для SQL взаимодействий
• Настройка Service Principal Names (SPNs) в Active Directory
• Настройка 'Доверия для делегирования' в учетных записях компьютера /пользователя
• Настройка Служб компонентов на Sharepoint серверах
• Включение Kerberos для веб приложений и Shared Service Provider (SSP)
• Тестирование Sharepoint среды

Сбор необходимой информации

Чтобы сделать наше применение максимально безболезненным, нам нужно подготовить весь строительный материал. Полагаю, что ваша среда использует Active Directory, и каждый сервер имеет уникальный IP адрес. Они должны быть зарегистрированы в вашем DNS сервере, и для работы Kerberos не должно существовать никаких дубликатов в зонах прямого и обратного просмотра. Также, все клиенты и серверы должны иметь правильное время и дату, так как Kerberos использует и эти параметры для утверждения билетов и доступа к внутреннему DNS серверу.

Прежде чем вы установите Sharepoint, создайте соответствующих пользователей в Active Directory (смотреть ссылки на официальное руководство). Если вы уже создали необходимые учетные записи, пожалуйста, продолжайте читать.

Вот список информации, необходимой для настройки Kerberos в Sharepoint окружении.

• Класс службы SPN (HTTP для WSS/MOSS веб приложений. MSSQLSvc для стандартного объекта SQL сервера)
• Имена хостов ваших SPNs (только имена хостов, обычно FQDN без части домена)
• FQDN всех веб приложений и серверов
• Номера портов или ваших SPNs (никаких портов для WSS и MOSS веб приложений. 1433 для SQL)
• Учетные записи Active Directory для ваших SPNs (учетные записи пула служб и приложений)

Включение Kerberos для SQL взаимодействий

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

Включите Kerberos между Sharepoint внешним сервером для вашего SQL сервера путем:

• Настройки SPNs для него
• Настройки «Доверия для делегирования», если вам нужно олицетворять пользователей для других служб.

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

Настройка Service Principal Names (SPNs) в Active Directory

Сопоставление Service Principal Name используется технологией Kerberos для разрешения делегирования службы, чтобы олицетворять определенную пользовательскую учетную запись. SPN содержит класс службы (Service Class), имя хоста и иногда номер порта. Вот пара примеров: HTTP/intranet.domain.local и MSSqlSvc/sql1.domain.local:1433. Хорошей практикой является регистрация имени хоста и FQDN веб приложений, даже, несмотря на то, что вы собираетесь использовать только одно из них.

Чтобы настроить Service Principal Names, вы можете использовать различные инструменты. Я предпочитаю SetSPN-инструмент, который установлен в Windows Server 2008 по умолчанию. Для Windows Server 2003 его можно найти в инструментах поддержки (Support) на установочном CD-ROM или пакете ресурсов, который можно скачать с сайта Microsoft. Вы также можете использовать ADSIedit для настройки SPNs, но он требует немного больше времени на просмотр вашей Active Directory и редактирование элементов, а также изменение их ServicePrincipalName.

Команда для регистрации SPN: setspn.exe 'A HTTP/intranet.domain.local DOMAIN\Account Команда для перечисления SPN учетной записи: setspn.exe 'L DOMAIN\Account Команда для удаления SPN: setspn.exe 'D HTTP/intranet.domain.local DOMAIN\Account

Используйте таблицы на рисунках 2 или 3, чтобы посмотреть регистрации, необходимые для вашего SQL в сценарии MOSS/WSS.

Рисунок 2: Делегирование и SPNs для MOSS

Рисунок 3: Делегирование и SPNs для WSS

Настройка 'Доверия для делегирования' на учетных записях компьютера/пользователя

Теперь нам нужно разобраться с делегированием прав в Active Directory. Это делается для учетных записей компьютеров и пользователей, как видно в таблице выше. В Пользователи и компьютеры Active Directory правой клавишей нажмите на учетной записи, выберите свойства и отметьте флажком строку доверия делегирования (смотреть рисунки 4 и 5 ниже). Текст/процедура может отличаться в разных версиях Windows Server.

Рисунок 4: Делегирование для учетной записи компьютера

Рисунок 5: Делегирование для учетной записи пользователя

Смотрите рисунки 2 или 3 для того, каким учетным записям нужно настроить делегирование в этом сценарии.

Настройка служб компонентов на Sharepoint серверах

Пул учетных записей веб приложений должен иметь определенные права, или вы получите DCOM ошибку с id 10017 в журнале регистрации событий, описанную в Microsoft KB920783:

'Параметры разрешений приложения не дают разрешения локальной активации для COM Server приложения с CLSID {CLSID} пользователю DomainName\UserName SID {SID}. Это разрешение безопасности можно изменить, используя инструмент администрирования службы компонентов.'

Для настройки корректной безопасности учетной записи просто перейдите в панель управления, Службы компонентов, Компьютеры, Мой компьютер, DCOM настройка и редактирование свойств 'IIS WAMReg Admin Service'. Установите 'Запускать и активировать' во вкладке Безопасность и назначьте права 'Локальная активация' для всех учетных записей в пуле приложений (смотреть рисунок 2 или 3).

Будучи в Службах компонентов установите 'Стандартный уровень олицетворения' на значение 'Делегировать' изменив свойства в 'Мой компьютер'. Для дополнительной информации прочтите статью Microsoft KB917409.

Включение Kerberos для веб приложений и Shared Service Provider (SSP)

Итак, ваша основная настройка должна быть почти завершена. Чтобы использовать Kerberos, вы должны включить его с помощью панели Центральное администрирование (Central Administration) для ваших веб приложений. Теперь мы можем выбирать между NTLM и Kerberos для отдельных веб приложений на странице Провайдеры аутентификации, которую вы найдете в панели Управление приложениями. Для настройки следуйте этому пути:

• Центральное администрирование, управление приложениями, провайдеры аутентификации
• Выберите свои веб приложения для которых нужно использовать Kerberos, например:

• Нажмите 'По умолчанию'
• Выберите/отметьте опцию Kerberos:

Не забудьте перезапустить вашу IIS с помощью команды iisreset /noforce в интерпретаторе команд на ваших внешних веб серверах.

В MOSS провайдера совместных служб (Shared Service Provider) также нужно настроить, и делается это из командной строки. Команда SetSharedWebServiceAuthn не существует в WSS. Перейдите к 12-hive bin директории (обычно расположенной в C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin) и запустите команду: stsadm.exe -o SetSharedWebServiceAuthn -negotiate

Тестирование Sharepoint окружения

Теперь подошел волнующий момент операции: нужно убедиться, что все работает так, как мы ожидали. Как любой другой человек, я проверяю изменения конфигурации по мере выполнения процедур. Очень полезно знать, использует ли ваше SQL взаимодействие Kerberos, прежде чем двигаться к следующему шагу. Но как проверять отдельные части нашей настройки?

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

• Дата и время установлены корректно на всех серверах
• Учетная запись не заперта в домене
• Пул приложения или службы работает от имени соответствующей учетной записи
• Делегирование на учетных записях компьютера и пользователя настроено правильно
• SPNs настроены правильно в Active Directory
• Никаких дубликатов на серверах не должно существовать в DNS зонах прямого и обратного просмотра
• DNS серверы указаны верно на всех серверах

Известные проблемы с Internet Explorer Если вы используете нестандартные порты на ваших IIS виртуальных серверах, пожалуйста, убедитесь в том, что ваша версия Internet Explorer 6 или более ранняя версия обновлена и настроена на включение номеров порта в SPNs. Центральное администрирование будет содержать нестандартные номера портов. Вы не получите сообщения об ошибке, если используете старые ненастроенные версии Internet Explorer. Прочтите статью Microsoft, о которой я упоминал в разделе ссылок, относительно этой проблемы. Мне сказали, что у Internet Explorer 7 была такая же проблема, но она была исправлена.

Резюме

Microsoft Windows Sharepoint можно использовать в комплексных средах, где требуется надежная аутентификация с Kerberos. С помощью этой статьи я надеялся показать вам 'общую картину' Kerberos в установке Sharepoint. Инструменты и базовые настройки уже доступны, так что вы можете начинать использовать отличные функции Sharepoint dual-hop аутентификации самостоятельно.

Ссылки

• Microsoft TechNet: Plan for administrative and service accounts
• Microsoft TechNet: Configure Kerberos authentication
• Microsoft TechNet SetSPN-Tool documentation: SetSPN Overview
• Microsoft Download SetSPN-Tool: Windows 2000 Server and Windows Server 2003 SP2 32-bit
• Microsoft TechNet: Troubleshooting Kerberos Delegation
• Microsoft Support: How to troubleshoot the "Cannot generate SSPI context" error message
• Microsoft Support: Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003
• Jesper M. Christensen blog: Kerberos in Sharepoint flow with build-in text
• Jesper M. Christensen blog: Troubleshooting the Kerberos error KRP_AP_ERR_MODIFIED