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

Article
10/23/2008

Использование аутентификации 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.

Роль	Имя	FQDN
WFE1	PORTAL-WFE1	portal-wfe1.company.com
WFE2	PORTAL-WFE2	portal-wfe2.company.com
Index	PORTAL-INDEX	portal-index.company.com
Database	SQLDB	sqldb.company.com

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

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

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

Приложение	Порт	Альтернативное DNS-имя на порту 80 (через host header-ы)
Central Administration	999	portal-sca.company.com
Shared Services Provider	888	portal-ssp.company.com
Personal Sites	777	my.company.com
Portal	80	portal.company.com

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

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

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

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

Роль	Имя	Описание
Аккаунт фермы или аккаунт базы даных	svc_sp_dbacc	Этот аккаунт используется для доступа всех приложений SharePoint к серверу БД. Под ним также работают пул приложений Центра администрирования и сервис SharePoint Timer (OWSTIMER)
Аккаунт пула приложений Shared Services	svc_sp_ssp_p
Аккаунт сервиса Shared Services	svc_sp_ssp_service	Под этим аккаунтом работает пул приложений веб-сервисов Shared Services
Office SharePoint Server Search	svc_sp_serversearch	Под этим пользователем запускается сервис MSSEARCH, отвечающий за функционирование Office Server Search (главным образом – за индексирование)
Application Pool process account (Portal)	svc_sp_portal_p	Аккаунт пула приложений веб-приложения "Portal"
Application Pool process account (Personal Sites)	svc_sp_personalsites_p	Аккаунт пула приложений веб-приложения "Personal Sites"

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

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

В нескольких статьях встречается шаг, на котором необходимо в том же Component Services установить для всего компьютера (Component Services -> Computers -> My Computer -> Default Properties) Default Impersonation Level в значение Delegate. Этого делать нельзя! В лучшем случае такая настройка ничего не даст, в худшем – после включения Kerberos перестанет работать provisioning в ферме SharePoint, а в Event Log-ах будет появляться много «красненьких» сообщений, stack trace-ы которых указывают на невозможность обновления метабазы IIS-а.

При этом не нужно путать такую ситуацию с описанной в статье https://support.microsoft.com/kb/946517. Возможно исправление из этой статьи вам понадобится, но будем надеяться, что нет.

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> должна быть похожа на это:

<system.webServer>

…

</authentication>

</security>

</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-ы для нашего случая.

Account	SPN Name
svc_sp_dbacc	http/portal-wfe1:999
svc_sp_dbacc	http/portal-wfe2:999
svc_sp_dbacc	http/portal:999
svc_sp_dbacc	http/portal-wfe1.company.com:999
svc_sp_dbacc	http/portal-wfe2.company.com:999
svc_sp_dbacc	http/portal.company.com:999
svc_sp_dbacc	http/portal-sca.company.com

svc_sp_ssp_p	http/portal-wfe1:888
svc_sp_ssp_p	http/portal-wfe2:888
svc_sp_ssp_p	http/portal:888
svc_sp_ssp_p	http/portal-wfe1.company.com:888
svc_sp_ssp_p	http/portal-wfe2.company.com:888
svc_sp_ssp_p	http/portal.company.com:888
svc_sp_ssp_p	http/portal-ssp.company.com

svc_sp_portal_p	http/portal-wfe1
svc_sp_portal_p	http/portal-wfe2
svc_sp_portal_p	http/portal
svc_sp_portal_p	http/portal-wfe1.company.com
svc_sp_portal_p	http/portal-wfe2.company.com
svc_sp_portal_p	http/portal.company.com

svc_sp_mysites_p	http/portal-wfe1:777
svc_sp_mysites_p	http/portal-wfe2:777
svc_sp_mysites_p	http/portal:777
svc_sp_mysites_p	http/portal-wfe1.company.com:777
svc_sp_mysites_p	http/portal-wfe2.company.com:777
svc_sp_mysites_p	http/portal.company.com:777
svc_sp_mysites_p	http/my.company.com

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.

Comments

Anonymous
January 01, 2003
Владимир, спасибо! Действительно актуально и более чем наглядно, особенно приятно, что речь идет о Win2008. Выходит, особых различий в настройке/возможным issue по сравнению с 2003 не выявлено? (Вопрос от того, что все ссылки на настройки и возможные issue в статье идут не на 2008 сервер).
Anonymous
January 01, 2003
Виктор, конечно же описываемый сценарий подразумевает SP1 вместе с Infrastructure Updates. До Infrastructure Updates из-за проблем с работой Kerberos в SharedServices нельзя было корректно настроить SharedServices так, чтобы они поддерживали Kerberos. В остальном ничего не изменилось. В любом случае настоятельно рекомендую устанавливать Inf.Updates.
Anonymous
January 01, 2003
Отличий действительно немного (и это хорошо :-). В настройке поддержки Kerberos их два:

включение использования Application Pool Identity
ни в коем случае на выставлять "Default Impersonation Level" в Delegate

Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
У нас появился новый блоггер: Владимир Колесников . Володя работает в Питерском офисе МС и будем рассказывать
Anonymous
January 01, 2003
Да, Виктор, Вы правы. Трасты нужно выставлять и для SQL-сервера тоже. Спасибо за замечание, добавлю в пункт 4.1. По поводу конфигурирования сразу с Kerberos. Действительно, если все заранее спланировать и сконфигурировать можно начать работать с Kerberos прямо с этапа Configuration Wizard после установки. Я намеренно описал другую ситуацию, так как к сожалению очень редко перед развертыванием MOSS люди уделяют достаточно внимания планированию веб-приложений и аккаунтов.
Anonymous
January 01, 2003
В SPN в данном случае обязательно дожно присутствовать DNS-имя, по которому вы будете обращаться к сервису. Если у вас два сайта на одном порту, то они очевидно должны отличаться DNS-именами - иначе нельзя будет корректно создать host header. Вот записи: svc_sp_portal_p http/portal svc_sp_portal_p http/portal:443 так можно, но не забудьте создать записи для FQDN-имен сайтов (portal.company.com) svc_sp_mysites_p http/portal svc_sp_mysites_p http/portal:443 так уже нельзя! нужно вместо portal указывать другое имя, например my ну, и обязательно добавьте еще два SPN для FQDN-имени (my.company.com)
Anonymous
January 01, 2003
Виктор, действительно для разных дублирование SPN для разных аккаунтов ситуация недопустимая. SPN-записи для компьютеров, если я не ошибаюсь, используются в тех случаях, когда сервис запускается от имени встроенного аккаунта (такого как NETWORK SERVICE). За подробностями лучше обратиться к соответствующей документации.
Anonymous
January 01, 2003
Илья, два SPN-а, отличающиеся только аккаунтом, не имеют смысла. Чтобы понять, нужны ли они, представьте себе, как вы будете обращаться к этим двум веб-приложениям, когда они привязаны к одному порту. Представили? Правильно, с указанием host header-а. SPN-ы не создаются просто так. Для функционирования сервиса они не нужны, они нужны для возможности ОБРАЩЕНИЯ к сервису. А обращаясь к веб-приложениям, которые на одном сервере завязаны на один порт, мы всегда должны использовать host header, иначе IIS не сможет понять, какое веб-приложение нам нужно.
Anonymous
October 24, 2008
Владимир! Спасибо за подробную инструкцию. Но что делать, если My (My Site) живет так же как и Portal на 80-ом порту и более того - оба веб-приложения доступны по 443-порту? Как в таком случае прописать SPN? svc_sp_portal_p http/portal-wfe1 svc_sp_portal_p http/portal-wfe2 svc_sp_portal_p http/portal svc_sp_mysites_p http/portal-wfe1 svc_sp_mysites_p http/portal-wfe2 svc_sp_mysites_p http/portal Получается - делать необходимо так!? И ко всему прочему добавить по строке для доступа по SSL: svc_sp_portal_p http/portal:443 svc_sp_mysites_p http/portal:443
Anonymous
October 27, 2008
Почему же это "не так"?! В ситуации когда есть два веб-приложения (в Вашем случае Portal - http/portal.company.com и MySites - http/my.company.com) опубликованные на 80/443 портах и разделенные host-header`ами (про wild-сертификаты вкурсе - они же и используются), необходимо для двух учетных записей от которых запускаются пулы создать/добавить несколько SPN с одинаковыми значениями: svc_sp_portal_p http/portal-wfe1 svc_sp_portal_p http/portal-wfe2 svc_sp_portal_p http/portal svc_sp_portal_p http/portal:443 svc_sp_mysites_p http/portal-wfe1 svc_sp_mysites_p http/portal-wfe2 svc_sp_mysites_p http/portal svc_sp_mysites_p http/portal:443 На практике все работает - и ни что не ругается, но до сего момента !думалось!, что SPN должен быть уникальным!
Anonymous
October 27, 2008
Безусловно SPN должно содержать DNS-имя ресурса, но если говорить о NLB-кластере... Предлагаю взять более явный пример: Есть два "железных" WFE-сервера: PORTAL-WFE1 и PORTAL-WFE2 с FQDN portal-wfe1.company.com и portal-wfe2.company.com соответственно. На каждом из них запущено два веб-приложения, каждое из которых "сидит" на 80-ом порту. Для учетных записей необходимо так же добавить SPN этих WFE-серверов. В Вашем примере веб-приложения разнесены по разным портам, поэтому мы видем записи SPN с указанием портов (например HTTP/portal-wfe1.company.com:777 и HTTP/portal-wfe1:777) и у учетных записей SPN пересекаться не будут. Но если приложения опубликованы на одинаковых портах и находяться в NLB-кластере то ведь все равно необходимо указать SPN, содержащие упоминание о физических WFE-серверах?!
Anonymous
October 27, 2008
Владимир! Фраза "нужны для возможности ОБРАЩЕНИЯ к сервису" вернула меня в правильное русло. Спасибо!
Anonymous
November 24, 2008
Владимир, спасибо за информацию по KERBEROS и MOSS2007. Скажите, пожалуйста, возможно инициализация KERBEROS для MOSS 2007 SP1?На сайте Microsoft была информация о настройках KERBEROS для MOSS 2007 еще до Infrastructure Update. Или на данный момент без установки Inf. Update включить KERBEROS для MOSS 2007 невозможно? Проясните , пожалуйста, ситуацию. Заранее спасибо.
Anonymous
November 25, 2008
Здравствуйте, Владимир. Вопрос по установке св-ва "Trust for delegation" для учетных записей серверов (SQL,IIS). Для IIS(WFE) понятно, что это св-во должно быть установленно. Для SQL ? В некоторых блогах (http://blogs.msdn.com/martinkearn)говорится об установке "Trust for delegation" для учетной записи SQL сервера. И если предварительно созданны SPN для сервисных аккаунтов и выставленны св-ва , можно ли указывать на использование механизма Kerberos при запуске Configuration Wizard для MOSS 2007? В Вашем описании, как я понимаю, предполается что установка MOSS 2007 была выполнена для NTLM аутентификации и потом был выполнен переход на KERBEROS. Заранее спасибо.
Anonymous
November 25, 2008
Добрый день, Владимир. Вопрос по SPN. Для механизма KERBEROS ,как я понимаю, критической является ситуация, когда у разных учетных записей в AD одинаковые SPN. Например для SQL сервера и для сервисного аккаунта, под которым запущен сервис DB Engine. Т.е. SPN запись для аккаунта компьютера, на котором установлен SQL, надо удалить из св-в этого компьютера в AD?
Anonymous
November 25, 2008
Да, Владимир, Вы абсолютно правы , когда говорите о том в какой степени уделяется внимание этапу планирования для развертывания решения на базе MOSS 2007. Хотя все, что необходимо для этого есть на сайте производителя. Как правило, когда требуется человек для проекта по MOSS 2007 все ограничивается требованиями к разработке webparts и дизайну страниц, а подход к организации инфраструктуры на уровне "Next->Next->Next->..->Finish".

Share via