Конфигурирование аутентификации Kerberos для Office SharePoint Server 2007

Использование аутентификации Kerberos все больше набирает популярность. Основные причины этому две:

• NTLM (а именно этот протокол используется по умолчанию) создает более высокую нагрузку на котроллер домена
• При использовании Kerberos возможна поддержка различных схем аутентификации, в том числе и тех, которые подразумевают отсутствие процесса ввода пароля (например, аутентификация по смарт-картам)

За подробностями относительно самого протокола, как обычно, добро пожаловать на TechNet – "What Is Kerberos Authentication?" Те, кто хочет узнать больше, могут также почитать блог команды Active Directory.

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

Мы же вернемся к MOSS. Как выясняется на практике, включение Kerberos для использования с этим продуктом – не такой уж тривиальный процесс. С выпуском же Windows Server 2008 и Infrastucture Updates проявились особенности, о которых раньше большинство людей, занимающихся SharePoint, даже не подозревало. Для начала опишем, что же мы хотим сделать.

А хотим мы сконфигурировать Kerberos на ферме MOSS2007 из трёх машин: два Web Front End-а (WFE) и один сервер индексирования. Работают под Windows Server 2008 (а как же!). Не забываем, конечно, и про SQL Server.

Взглянув на таблицу, можно догадаться, что имя домена у нас COMPANY.COM (или в старинной записи COMPANY).

Оба Web Front End-а объединены в NLB-кластер с DNS-именем PORTAL (portal.company.com). PORTAL-INDEX используется только для индексирования, в качестве Query-серверов используются WFE-серверы.

В процесс развертывания портала были созданы следующие веб-приложения:

Полагаю, назначение первых трех понятно всем, кто работает с MOSS. Четвертое же – как раз тот самый корпоративный портал.

Обратите внимание на альтернативные имена для приложений на 80-ом порту. Во-первых, нельзя забывать по Alternate Access Mapping, во-вторых, DNS-записи для этих имен следует создавать только как DNS A-records (а не CNAME, как многие любят). Причины таких требований описаны здесь и здесь.

Считаем, что имя Shared Services Provider: "SharedServices1". В 99% случаев оно именно такое. Если в вашем случае это не так, соответствующем образом поправьте команды из этой статьи, когда будете их копипастить ;-)

Поскольку Kerberos сильно завязан на аккаунты сервисов приложений, перечислим их.

Теперь просто действия по шагам.

1. Установите необходимые обновления для WSS и MOSS.

    На сегодняшний день таковых накопилось порядочно. Позволю себе процитировать (а заодно и перевести) пост моего коллеги из SharePoint Team.

• Windows SharePoint Services 3.0 Service Pack 1
• The 2007 Microsoft Office Servers Service Pack 1
• The Windows SharePoint Services Infrastructure Update x86 x64
• The Microsoft Office Servers Infrastructure Update x86 x64
• KB 953397: Excel Server Security Update x86 x64
• KB 955586: Document Lifecycle Workflow Update
• August Cumulative Update for Windows SharePoint Services 3.0 (Global)
• August Cumulative Update for Windows SharePoint Services 3.0 (Local)
• August Cumulative Update for Microsoft Office Servers

После установки всех апдейтов на всех трех компьютерах фермы следует выполнить команду «psconfig -cmd upgrade -inplace b2b». Это «прочистит мозг» SharePoint и он поймет наконец, что апдейты установлены везде, где положено. J Вообще же, прежде чем ставить какие-либо обновления для SharePoint, советую один раз прочитать две статьи: Deploy software updates for Windows SharePoint Services 3.0 и Deploy software updates for Office SharePoint Server 2007.

Небольшая подсказка. Перед установкой Infrastructure Update на индекс-сервер скопируйте файл web.config из папки %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\Config в папку %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\Template\Layouts. Это необходимо из-за того, что установщик ожидает обнаружить на сервере хотя бы одно веб-приложение SharePoint, но на индекс-сервере таковых нет. Подобный trick проблему решает.

2. Если вы еще не сделали это, сконфигурируйте должным образом Component Services (сервис IIS WAMREG Admin Service).

• Откройте Component Services (dcomconfig.exe)
• Откройте свойства сервиса «IIS WAMREG Admin Service»
• Перейдите на вкладку Security
• Откройте Launch and Activation Permissions
• Добавьте локальные группы WSS_WPG и WSS_ADMIN_WPG с разрешением Local Activation

3. Включите использование Application Pool Identity для веб-приложений

В Windows Server 2008, а точнее в IIS7, появилась новая фича – аутентификация непосредственно ядром через HTTP.sys. Однако, особенность этой фичи в том, что по умолчанию аутентификация проводится под аккаунтом Local System, что сводит на нет функционирование Kerberos в условиях его использования на ферме SharePoint.

Для включения использования Application Pool Identity нужно сделать следующее:

• Откройте файл %windir%\System32\inetsrv\config\applicationHost.config.
• Найдите секцию <system.webServer> . Убедитесь, что вы нашли именно «живую» секцию system.webServer в корневой секции security/authentication/windowsAuthentication, а не комментарий в xml или соответствующую секцию для отдельных веб-приложений. Кстати, о последнем предупреждении. В принципе эту настройку можно модифицировать и на уровне веб-приложения. Если для вас такой сценарий более предпочтителен, используйте его.
• Установите атрибут useAppPoolCredentials в ключе system.webServer/security/authentication/windowsAuthentication в значение true

    В результате секция <system.webServer> должна быть похожа на это:

• Убедитесь также, что атрибут enabled также установлен в true
• Сохраните applicationHost.config

4. Создайте Service Principal Names (SPN).

Вот мы и дошли непосредственно до Kerberos. SPN-это краеугольный камень процесса аутентификации. Для их создания проще всего использовать утилиту SetSPN. Администраторы домена, если используют Kerberos, должны знать о ней. Если что, грузите отсюда.

4.1. Убедитесь в том, что Kerberos сконфигурирован для сервера баз данных

SQL Server отлично работает с Kerberos. Существует несколько способов конфигурирования SQL Server для использования Kerberos. Все они, так или иначе, приводят к созданию SPN. Подробности здесь и здесь.

Если Kerberos для SQL Server еще не конфигурировался, то необходимо создать SPN и для него.

В общем случае SPN для SQL Server создается в форе Setspn.exe –A MSSqlSvc/FQDNServerName:PORT DOMAIN\Account. Порт обычно 1433. FQDNServerName – это полное FQDN-имя сервера, включая суффикс company.com. DOMAIN-имя домена, Account-имя аккаунта, под которым работает Database Service. Если предположить, что у нас он работает под аккаунтом COMPANY\svc_sql_dbs, то команда будет выглядеть так:

Setspn.exe –A MSSqlSvc/sqldb.company.com:133COMPANY\svc_sql_dbs

После этого необходимо включить доверительные отношения делегирования для акакаунта Database Service и самого сервера баз данных:

Откройте оснастку Active Directory Users and Computers.

• найдите аккаунт в иерархии AD (в нашем примере это аккаунт svc_sql_dbs).
• откройте его свойства
• на вкладке Delegation выберите Trust this user/computer for delegation to any service (Kerberos)
• убедитесь, что опция Account is sensitive and cannot be delegated отключена

Аналогично выставите эту опцию в Active Directory для сервера баз данных (sqldb).

4.2. Создайте SPN-ы для веб-приложений

В общем случае SPN-ы для веб-приложений создаются в форме Setspn.exe –A HTTP /ServerName:PORT DOMAIN\Account. Необходимо создвать SPN-ы для всех вариантов обращения к серверам, включая FQDN-имена, имена обоих WFE и имя WFE-клстера. В таблице ниже SPN-ы для нашего случая.

4.3. Создайте SPN-ы для сервисов Shared Services

Создайте SPN-ы в новом формате с помощью следующих команд.

Для обоих WFE-серверов:

• Setspn.exe -A MSSP/servername:56737/SharedServices1 COMPANY\svc_sp_ssp_service
• Setspn.exe -A MSSP/servername:56738/SharedServices1 COMPANY\svc_sp_ssp_service
• Setspn.exe -A MSSP/serverFQDNname:56737/SharedServices1 COMPANY\svc_sp_ssp_service
• Setspn.exe -A MSSP/serverFQDNname:56738/SharedServices1 COMPANY\svc_sp_ssp_service

где servername -это pre-Windows2000 (netbios) имя сервера, а serverFQDNname - это полное FQDN-имя сервера (с суффиксов company.com)

Затем эти же команды, но для имен кластера:

• Setspn.exe -A MSSP/portal:56737/SharedServices1 COMPANY\svc_sp_ssp_service
• Setspn.exe -A MSSP/portal.company.com:56737/SharedServices1 COMPANY\svc_sp_ssp_service
• Setspn.exe -A MSSP/portal:56738/SharedServices1 COMPANY\svc_sp_ssp_service
• Setspn.exe -A MSSP/portal.company.com:56738/SharedServices1 COMPANY\svc_sp_ssp_service

5. Включите использование нового формата SPN.

Одним из новшеств, привносимых Infrastructure Update, является поддержка нового формата SPN для SharePoint. Без этого раньше было весьма проблематично включить использование Kerberos на Shared Services. По умолчанию такая поддержка отключена. Чтобы ее активировать нужно в реестре, в ключе HKLM\Software\Microsoft\Office Server\12.0 создать числовое (REG_DWORD) значение KerberosSpnFormat и выставить его в 1.

6. Включите доверительные отношения делегирования для компьютеров фермы и аккаунтов сервисов и пулов приложений.

Для аккаунта SQL Server Database Service мы уже делали это.

Откройте оснастку Active Directory Users and Computers. Для обоих WFE фермы необходимо сделать следующее:

• найдите компьютер в иерархии AD
• откройте его свойства
• на вкладке Delegation выберите Trust this user/computer for delegation to any service (Kerberos)

Затем сделайте то же самое для всех аккаунтов пулов приложений, включая svc_sp_dbacc (убедитесь, что опция Account is sensitive and cannot be delegated отключена).

7. Перезагрузите серверы фермы.

Здесь, пожалуй, пора перезагрузить оба WFE и Index-сервер, чтобы многочисленные настройки (а особенно последняя) применились, как следует.

8. Включите Kerberos для Shared Services.

Делается это через stsadm двумя командами:

• stsadm -o SetSharedWebServiceAuthn -negotiate
• stsadm -o execadmsvcjobs

9. Включите Kerberos для Excel Services.

Опять же используем stsadm. Парочка команд

• stsadm.exe -o set-ecssecurity -ssp SharedServices1 -accessmodel delegation
• stsadm.exe -o execadmsvcjobs

10. Установите исправление для IE 6.

Установите на пользовательские компьютеры, использующие Internet Explorer версии 6, исправление, позволяющее IE корректно работать с Kerberos. Об исправлении можно почитать здесь: https://support.microsoft.com/kb/908209.

Хотя, конечно самый правильный способ – использовать Internet Explorer 7.

11. Включите использование Kerberos для веб-приложений.

Итак, последний шаг!

Открываем Central Administration и для каждого веб-приложения делаем следующее:

• На вкладке Application Management открываем Authentication Providers (раздел Application Security).
• Выбираем в «выпадающем» списке очередное веб-приложение.
• Выбираем зону, в которой хотим включить Kerberos (обычно Default).
• На странице Edit Authentication в IIS Authentication Settings, выбираем Integrated Windows authentication, затем Negotiate (Kerberos) . В ответ на запрос подтверждения нажимаем OK.
• Чтобы все это применилось, жмем Save.

12. IISRESET.

Выполните команду IISRESET.

Вот и все! Теперь ваш SharePoint работает с Kerberos! Добавлю только, что весьма и весьма подробно все эти шаги описаны в статье Configure Kerberos authentication (Office SharePoint Server). Если появляются проблемы, связанные с Kerberos, поищите их здесь или здесь - возможно найдете способ, как их устранить.

В следующий раз я расскажу о некоторых особенностях развертывания Office SharePoint Server 2007 в NLB-кластере под Windows Server 2008.