Обзор проверки подлинности Kerberos для продуктов Microsoft SharePoint 2010

 

Применимо к: SharePoint Server 2010

Последнее изменение раздела: 2016-11-30

В Продукты Microsoft SharePoint 2013 представлены значительные улучшения управления удостоверениями в платформе. Очень важно понимать, как эти изменения влияют на разработку решений и настройку платформы, чтобы включить сценарии, для которых требуется делегировать удостоверение пользователя интегрированным системам. Протокол Kerberos версии 5 играет ключевую роль для делегирования и иногда требуется в подобных ситуациях.

В данных статьях представлены сведения, которые позволят выполнять следующие задачи:

  • понять концепцию удостоверений в продуктах SharePoint 2010;

  • узнать, как проверка подлинности Kerberos играет важную роль в сценариях проверки подлинности и делегирования;

  • выявить ситуации, в которых следует использовать проверку подлинности Kerberos при разработке решений;

  • настраивать проверку подлинности Kerberos во всей среде, в том числе в сценариях с использованием различных приложений-служб в SharePoint Server;

  • тестировать и проверять правильную настройку и работу проверки подлинности Kerberos;

  • находить дополнительные средства и ресурсы для настройки проверки подлинности Kerberos в среде.

Данный набор статей разбит на два раздела:

  • Этот обзор проверки подлинности Kerberos в продуктах SharePoint 2010.

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

  • Пошаговая настройка

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

Кто должен прочитать эти статьи о проверке подлинности Kerberos?

Удостоверения и делегирование в Продукты SharePoint 2010 — это широкая тема для обсуждения со многими гранями и уровнями понимания. В данном наборе статей описываются как концептуальные, так и технические уровни. Статьи предназначены для разной аудитории.

От начала до конца

"Расскажите мне все, что нужно знать об удостоверениях и проверке подлинности Kerberos в Продукты SharePoint 2010"

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

Обновление версии Office SharePoint Server 2007

"Расскажите, что изменилось по сравнению с версией 2007 и что нужно подготовить для обновления до версии 2010"

Если существующая среда Microsoft Office SharePoint Server 2007 уже настроена для использования проверки подлинности и делегирования Kerberos, прочитайте следующие статьи:

  • Сценарии работы с удостоверениями в продуктах SharePoint 2010

  • Основные сведения об утверждениях

  • Изменения проверки подлинности Kerberos в Windows 2008 R2 и Windows 7

  • Изменения настройки Kerberos в продуктах SharePoint 2010

  • Рекомендации по обновлению SharePoint Server 2007

Если у вас есть дополнительные вопросы по настройке делегирования для определенного компонента или сценария, прочитайте статьи о пошаговой настройке, в частности контрольные списки настройки. Это позволит правильно настроить среду после обновления.

Пошаговое руководство

"Мне нужны подробные пошаговые инструкции по настройке делегирования Kerberos в SharePoint Server и соответствующих приложениях службы SharePoint Server "

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

Изучите первый сценарий базовой настройки, так как он является обязательным для всех последующих сценариев.

Примечание

В сценариях используются команды "SetSPN", которые можно скопировать из этого документа и вставить в командной строке. Данные команды содержат символы дефиса. В Microsoft Word есть компонент автоформатирования, которые преобразует дефисы в тире. Если этот компонент включен в Word и команды будут скопированы и вставлены, они не будут правильно работать. Измените тире на дефисы, чтобы исправить эту ошибку. Чтобы отключить компонент автоформатировния в Word, выберите пункт Параметры в меню Файл, щелкните вкладку Правописание и откройте диалоговое окно Автозамена.

Существующие среды продуктов SharePoint 2010

"У меня есть существующая среда SharePoint 2010, и я не могу заставить проверку подлинности Kerberos работать. Как проверить и отладить конфигурацию?"

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

Сценарии работы с удостоверениями в продуктах SharePoint 2010

При изучении удостоверений в контексте проверки подлинности в Продукты SharePoint 2010 можно концептуально рассмотреть, как платформа обрабатывает удостоверения в трех основных сценариях: входящие запросы проверки подлинности, запросы проверки подлинности внутри фермы и между фермами, а также исходящие запросы проверки подлинности.

Схема проверки подлинности фермы

Входящее удостоверение

Сценарий входящей проверки подлинности представляет средства, с помощью которых клиент предоставляет свое удостоверение платформе, т. е. проверяет подлинность в веб-приложении или веб-службе. SharePoint Server использует удостоверение клиента для авторизации доступа к защищенным ресурсам SharePoint Server, таким как веб-страницы, документы и т. д.

Продукты SharePoint 2010 поддерживает два режима проверки подлинности клиента: классический режим и режим утверждений.

Классический режим

В классическом режиме разрешены обычные методы проверки подлинности служб IIS, с которыми вы можете быть знакомы по предыдущим версиям SharePoint Server. Если веб-приложение SharePoint Server 2010 настроено для использования классического режима, можно применять следующие проверки подлинности служб IIS:

Встроенная проверка подлинности Windows

Встроенная проверка подлинности Windows позволяет клиентам Windows выполнять проверку подлинности без ввода учетных данных (имени пользователя и пароля) в SharePoint Server. Пользователи, получающие доступ к SharePoint Serverчерез Internet Explorer, проходят проверку подлинности с использованием учетных данных, с которыми был запущен процесс Internet Explorer. По умолчанию это учетные данные пользователя, вошедшего в систему на компьютере. Службы и приложения, получающие доступ к SharePoint Server в режиме встроенной проверки подлинности Windows, проходят проверку с использованием учетных данных запущенного потока, которые по умолчанию представляют собой удостоверение процесса.

NTLM

NTLM — это протокол, используемый по умолчанию при выборе встроенной проверки подлинности Windows. Данный протокол использует преимущества последовательности с запросом и подтверждением из трех этапов для проверки подлинности клиентов. Дополнительные сведения о протоколе NTLM см. в статье, посвященной Microsoft NTLM (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196643&clcid=0x419) (Возможно, на английском языке).

Плюсы.

  • Данный тип протокола легко настроить и для его работы не требуются дополнительные настройки инфраструктуры или среды.

  • Он работает, если клиент не входит в домен или не расположен в домене, которому доверяет домен с SharePoint Server.

Минусы.

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

  • Этот протокол не разрешает делегирование клиентских учетных данных серверным системам, что также называют правилом "двойного прыжка".

  • Это собственный протокол.

  • Он не поддерживает проверку подлинности сервера.

  • Он считается менее безопасным, чем проверка подлинности Kerberos.

Протокол Kerberos

Kerberos — это более безопасный протокол, поддерживающий проверку подлинности на основе билетов. Сервер проверки подлинности Kerberos выдает билет в ответ на запрос проверки подлинности с клиентского компьютера, если запрос содержит действительные учетные данные пользователя и действительное имя участника-службы (SPN). Этот билет затем используется клиентским компьютером для доступа к сетевым ресурсам. Чтобы включить проверку подлинности Kerberos, клиентский компьютер и сервер должны иметь доверенное подключение к Центру распространения ключей (KDC). Центр распространения ключей распространяет общие секретные ключи для шифрования. Клиентский компьютер и сервер также должны иметь доступ к доменным службам Active Directory (AD DS). Для доменных служб Active Directory корневой домен леса является центром для ссылок проверки подлинности Kerberos. Дополнительные сведения о протоколе Kerberos см. в статьях, посвященных работе протокола проверки подлинности Kerberos версии 5 (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196644&clcid=0x419) (Возможно, на английском языке) и Microsoft Kerberos (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x419) (Возможно, на английском языке).

Плюсы.

  • Самый безопасный протокол встроенной проверки подлинности Windows.

  • Разрешает делегирование клиентских учетных данных.

  • Поддерживает взаимную проверку подлинности клиентов и серверов.

  • Генерирует меньше трафика на контроллеры домена.

  • Открытый протокол, поддерживаемый многими платформами и производителями.

Минусы.

  • Для правильной работы требуется дополнительная настройка инфраструктуры и среды.

  • У клиентов должна быть возможность подключения к KDC (контроллеру домена Active Directory в средах Windows) по протоколу TCP/UDP через порт 88 (Kerberos) и TCP/UDP через порт 464 (протокол смены пароля Kerberos — Windows).

Другие методы

Помимо NTLM и проверки подлинности Kerberos, SharePoint Server поддерживает другие типы проверки подлинности служб IIS, такие как базовая, дайджест-проверка подлинности и проверка подлинности на основе сертификатов, которые не описаны в данном документе. Дополнительные сведения о работе этих протоколов см. в статье, посвященной методам проверки подлинности, поддерживаемым в службах IIS 6.0 (IIS 6.0) (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196646&clcid=0x419) (Возможно, на английском языке).

Проверка подлинности на основе утверждений

Поддержка проверки подлинности на основе утверждений — это новая возможность Продукты SharePoint 2010, основанная на Windows Identity Foundation (WIF). В модели на основе утверждений SharePoint Server принимает одно или несколько утверждений о клиенте, проходящем проверку подлинности, для идентификации и авторизации клиента. Утверждения передаются в форме маркеров SAML и представляют собой факты о клиенте, полученные от доверенного центра сертификации. Например, утверждение может сообщать следующее: "Иван входит в группу администраторов предприятия в домене Contoso.com". Если это утверждение поступило от поставщика, которому доверяют службы SharePoint Server, платформа может использовать эту информацию для проверки подлинности Ивана и авторизации доступа к ресурсам SharePoint Server. Дополнительные сведения о проверке подлинности на основе утверждений см. в руководстве по удостоверению, основанному на утверждениях, и управлению доступом (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=187911&clcid=0x419) (Возможно, на английском языке).

К типам утверждений, поддерживаемых Продукты SharePoint 2010 для входящей проверки подлинности, относятся утверждения Windows, утверждения проверки подлинности на основе форм и утверждения SAML.

Утверждения Windows

В режиме входа на основе утверждений Windows служба SharePoint Server проверяет подлинность клиента с помощью стандартной встроенной проверки подлинности Windows (NTLM/Kerberos) и затем преобразует полученное удостоверение Windows в удостоверение на основе утверждений.

Утверждения проверки подлинности на основе форм

В режиме утверждений проверки подлинности на основе форм SharePoint Server перенаправляет клиента на страницу входа со стандартными элементами управления входом ASP.NET. На этой странице происходит проверка подлинности клиента с использованием членства ASP.NET и поставщиков ролей (так же, как проверка подлинности на основе форм работала в Office SharePoint Server 2007). После создания объекта удостоверения, представляющего пользователя, SharePoint Server преобразует это удостоверение в объект удостоверения утверждений.

Утверждения SAML

В режиме утверждений SAML SharePoint Server принимает маркеры SAML от доверенного поставщика маркеров безопасности (STS). Если пользователи пытаются войти, они перенаправляются к внешнему поставщику утверждений (например, поставщику утверждений Windows Live ID), который выполняет проверку подлинности и создает маркер SAML. SharePoint Server принимает и обрабатывает этот маркер, дополняя утверждения и создавая объект удостоверения утверждений для пользователя.

Дополнительные сведения о проверке подлинности на основе утверждений в Продукты SharePoint 2010 см. в статье, посвященной удостоверению SharePoint на основе утверждений.

Примечание о входящих утверждениях проверки подлинности и утверждениях службы маркеров Windows (C2WTS)

Некоторые приложения-службы требуют использования утверждений Windows Identity Foundation (WIF) для службы маркеров Windows (C2WTS), чтобы преобразовать утверждения в ферме в учетные данные Windows для исходящей проверки подлинности. Важно понимать, что служба C2WTS работает, только если в качестве входящей проверки подлинности используется классический режим или режим утверждений Windows. В последнем случае для службы C2WTS необходимы только утверждения Windows. Веб-приложение не может использовать множество форм утверждений, так как при этом служба C2WTS не будет работать.

Удостоверение в среде продуктов SharePoint 2010

В средах Продукты SharePoint 2010 проверка подлинности на основе утверждений используется для взаимодействий внутри фермы и между фермами с большинством приложений-служб SharePoint и встроенных продуктов SharePoint независимо от используемого механизма входящей проверки подлинности. Это означает, что, даже если для проверки подлинности в определенном веб-приложении используется классический режим, продукты SharePoint преобразуют входящее удостоверение в удостоверение утверждений для проверки подлинности в приложениях-службах и продуктах SharePoint, поддерживающих утверждения. Стандартизируя модель утверждений для взаимодействий внутри фермы и между фермами, платформа может абстрагироваться от используемых протоколов входящей проверки подлинности.

Примечание

Некоторые продукты, интегрированные в SharePoint Server, такие как Службы SQL Server Reporting Services, не поддерживают утверждения и не используют преимущества проверки подлинности на основе утверждений внутри фермы. SharePoint Server также может использовать классическое делегирование Kerberos и утверждения в других сценариях, например если веб-часть просмотра RSS настроена на использование веб-канала, прошедшего проверку подлинности. Сведения о поддержке проверки подлинности на основе утверждений и делегирования удостоверений см. в документации соответствующего продукта или приложения-службы.

Исходящее удостоверение

Исходящее удостоверение в Продукты SharePoint 2010 представляет сценарии, в которых службы в ферме должны проверять подлинность внешних бизнес-систем и служб. В зависимости от сценария проверка подлинности может выполняться с использованием одной из двух базовых концептуальных моделей:

Доверенная подсистема

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

Схема доверенной подсистемы

В SharePoint Server эта модель может быть реализована разными способами:

  • Используя удостоверение пула приложений IIS — обычно это реализуется за счет выполнения кода в веб-приложении, который повышает уровень разрешений при вызове внешней системы. Другие методы, такие как использование режима RevertToSelf, также могут использовать удостоверение пула приложений для проверки подлинности во внешних системах.

  • Используя служебную учетную запись — обычно это реализуется за счет сохранения учетных данных приложения в безопасном хранилище и последующем их использовании для проверки подлинности во внешней системе. К другим методам относится хранение учетных данных служебной учетной записи другими способами, например с помощью встроенных строк подключения.

  • Анонимная проверка подлинности — это случай, когда внешняя система не требует проверки подлинности. Поэтому интерфейсная служба SharePoint Server не должна передавать удостоверения серверной системе.

Делегирование

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

Схема процесса делегирования

В Продукты SharePoint 2010 эта модель может быть реализована разными способами:

  • делегирование Kerberos — если клиент проходит проверку подлинности в интерфейсной службе с помощью проверки подлинности Kerberos, делегирование Kerberos можно использовать для передачи удостоверения клиента серверной системе;

  • утверждения — проверка подлинности на основе утверждений позволяет передавать утверждения клиента между службами, если они доверяют друг другу и поддерживают утверждения.

Примечание

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

Делегирование за пределами домена и леса

Для сценариев в этом наборе статей о проверке подлинности Kerberos необходимо, чтобы служба SharePoint Server и внешние источника данных размещались в одном домене Windows, что обязательно для ограниченного делегирования Kerberos. Протокол Kerberos поддерживает два вида делегирования: базовый (неограниченный) и ограниченный. Базовое делегирование Kerberos может выходить за пределы домена в одном лесу, но не может пересекать границы леса независимо от отношения доверия. Ограниченное делегирование Kerberos не позволяет переходить границы домена или леса в любой ситуации.

Некоторые службы SharePoint Server можно настроить для использования базового делегирования Kerberos, но другие службы требуют применения ограниченного делегирования. Любая служба, передающая утверждения в службу маркеров Windows (C2WTS), должна использовать ограниченное делегирование Kerberos, чтобы разрешить службе C2WTS использовать протокол Kerberos для преобразования утверждений в учетные данные Windows.

Следующие приложения-службы и продукты требуют использования C2WTS и ограниченного делегирования Kerberos:

  • Службы Excel

  • PerformancePoint Services

  • InfoPath Forms Services

  • Службы Visio

К следующим приложениям-службам и продуктам эти требования не относятся, поэтому они могут использовать базовое делегирование, если это необходимо:

  • Служба подключения к бизнес-данным и Microsoft Business Connectivity Services.

  • Службы Access

  • отчетов Microsoft SQL Server (SSRS)

  • Microsoft Project Server 2010

Следующие приложения-службы не разрешают делегирование клиентских учетных данных и, следовательно, к ним эти требования не применяются:

  • Microsoft SQL Server PowerPivot для Microsoft SharePoint

Основные сведения об утверждениях

Основные сведения об утверждениях и проверке подлинности на основе утверждений см. в введении в утверждения (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196648&clcid=0x419) (Возможно, на английском языке) и в статье, посвященной удостоверению SharePoint на основе утверждений (https://go.microsoft.com/fwlink/?linkid=196647&clcid=0x419).

Основные сведения о протоколе Kerberos

Концептуальный обзор протокола Kerberos см. в статьях, посвященных Microsoft Kerberos (Windows) (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x419) (Возможно, на английском языке), описанию протокола Kerberos (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196649&clcid=0x419) (Возможно, на английском языке) и вопросам группе разработчиков служб каталогов: Kerberos для занятого администратора (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196650&clcid=0x419) (Возможно, на английском языке).

Преимущества протокола Kerberos

Перед изучением настройки SharePoint Server (или любого другого веб-приложения) для использования протокола Kerberos рассмотрим общие сведения о протоколе Kerberos и причины для его использования.

Обычно есть три основных причины для применения протокола Kerberos:

  1. Делегирование клиентских учетных данных — протокол Kerberos позволяет службе выполнять олицетворение удостоверения клиента, чтобы позволить соответствующей службе передать это удостоверение другим сетевым службам от лица клиента. Протокол NTLM не поддерживает такое делегирование. (Это ограничение NTLM называется "правилом двойного прыжка".) Проверка подлинности на основе утверждений, такая как проверка подлинности Kerberos, может использоваться для делегирования учетных данных клиента, но для этого серверное приложение должно поддерживать утверждения.

  2. Безопасность — такие возможности, как шифрование AES, взаимная проверка подлинности, поддержка целостности и конфиденциальности данных и другие, делают протокол Kerberos более безопасным, чем NTLM.

  3. Потенциально более высокая производительность — для проверки подлинности Kerberos требуется передавать меньше трафика контроллерам домена по сравнению с использованием NTLM (в зависимости от проверки PAC, см. записи блога группы поддержки Microsoft Open Specification: основные сведения о проверке PAC Microsoft Kerberos (Возможно, на английском языке)). Если проверка PAC отключена или не нужна, служба, проверяющая подлинность клиента, не должна выполнять RPC-вызов контроллера домена (см. статью, посвященную возникновению задержек при проверке подлинности пользователя и запуске ресурсоемкой серверной программы на участнике домена в Windows 2000 или Windows Server 2003). Для проверки подлинности Kerberos также требуется меньше трафика между клиентом и сервером по сравнению с использованием NTLM. Клиенты могут проходить проверку подлинности на веб-серверах за два этапа запроса и утверждения по сравнению с трехэтапным процессом NTLM. Однако это улучшение обычно не заметно в скоростных сетях для отдельных транзакций, но ощутимо для общей пропускной способности системы. Помните, что многие факторы могут влиять на скорость проверки подлинности, поэтому проверку подлинности Kerberos и NTLM следует проверить в собственной среде перед тем, как решить, какой из этих методов работает быстрее.

Это неполный список преимуществ протокола Kerberos. Есть и другие причины, такие как взаимная проверка подлинности, кроссплатформенность, транзитивность за пределы домена и многие другие. Но в большинстве случаев делегирование и безопасность являются основными причинами внедрения протокола Kerberos.

Делегирование Kerberos, ограниченное делегирование и перенос протокола

Протокол Kerberos версии 5 для платформы Windows поддерживает два вида делегирования удостоверений: базовое (неограниченное) и ограниченное делегирование:

Тип Преимущества Недостатки

Базовое делегирование

  • Позволяет пересекать границы домена в одном лесу

  • Требует меньше настройки, чем ограниченное делегирование

  • Не поддерживает перенос протокола

  • Безопасное. При компрометации интерфейсной службы удостоверение клиента можно делегировать любой службе в лесу, поддерживающей проверку подлинности Kerberos.

Ограниченное делегирование

  • Может переносить протокол входящей проверки подлинности, отличный от Kerberos, в Kerberos (например: NTLM в Kerberos, утверждения в Kerberos)

  • Более безопасное. Удостоверения можно делегировать только определенной службе.

  • Не может пересекать границы домена

  • Требует дополнительной настройки

Службы, поддерживающие Kerberos, могут делегировать удостоверение несколько раз между несколькими службами и множеством "прыжков". По мере перемещения удостоверения от службы к службе метод делегирования может измениться с базового на ограниченный, но не наоборот. Этот момент необходимо обязательно запомнить: если для серверной службы требуется базовое делегирование (например, для делегирования за пределы домена), все службы, расположенные перед серверной службой, должны использовать базовое делегирование. Если какая-то интерфейсная служба использует ограниченное делегирование, серверная служба не может изменить ограниченный маркер на неограниченный, чтобы пересечь границы домена.

Перенос протокола позволяет службе проверки подлинности с поддержкой Kerberos (интерфейсной службе) преобразовать удостоверение, отличное от Kerberos, в удостоверение Kerberos, которое можно делегировать другим службам, поддерживающим Kerberos (серверной службе). Для переноса протокола требуется ограниченное делегирование Kerberos, поэтому удостоверения с переносом протокола не могут выходить за пределы домена. В зависимости от прав пользователя для интерфейсной службы билет Kerberos, возвращаемый при переносе протокола, может быть маркером идентификации или олицетворенным маркером. Дополнительные сведения об ограниченном делегировании и переносе протокола см. в следующих статьях:

Если требуется использовать делегирование Kerberos, рекомендуется применять ограниченное делегирование, если это возможно. Если требуется делегирование за пределы домена, все службы в пути делегирования должны использовать базовое делегирование.

Изменения проверки подлинности Kerberos в Windows 2008 R2 и Windows 7

В Windows Server 2008 R2 и Windows 7 представлены новые возможности проверки подлинности Kerberos. Обзор этих изменений см. в статьях, посвященных изменениям проверки подлинности Kerberos (https://go.microsoft.com/fwlink/?linkid=196655&clcid=0x419) и улучшениям Kerberos (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196656&clcid=0x419) (Возможно, на английском языке). Кроме того, следует ознакомиться с проверкой подлинности режима ядра IIS 7.0 (статья, посвященная настройкам проверки подлинности режима ядра служб IIS 7.0 (Возможно, на английском языке), (https://go.microsoft.com/fwlink/?linkid=196657&clcid=0x419) (Возможно, на английском языке)), даже несмотря на то, что она не поддерживается в фермах SharePoint Server.

Изменения настройки Kerberos в продуктах SharePoint 2010

Большинство базовых концепций настройки проверки подлинности Kerberos в Продукты SharePoint 2010 не изменились. Все еще нужно настроить имена участников-служб, параметры делегирования на компьютере и служебные учетные записи. Но есть несколько изменений, о которых нужно знать.

  • Ограниченное делегирование — требуется для служб, использующих утверждения для службы маркеров Windows. Ограниченное делегирование необходимо, чтобы разрешить перенос протокола для преобразования утверждений в маркеры Windows.

  • Приложения-службы — в Office SharePoint Server 2007 службам SSP требовались специальные имена участников-служб и изменения в реестре для поддержки делегирования. В Продукты SharePoint 2010 приложения-службы используют проверку подлинности на основе утверждений и утверждения для службы маркеров Windows, поэтому изменения больше не нужны.

  • Windows Identity Foundation (WIF) — C2WTS WIF — новая служба, используемая Продукты SharePoint 2010 для преобразования утверждений в маркеры Windows в сценариях делегирования.

Рекомендации при обновлении от Office SharePoint Server 2007

При обновлении фермы Office SharePoint Server 2007 до SharePoint Server 2010 есть несколько моментов, которые нужно учесть после завершения обновления.

  • Если URL-адреса веб-приложений изменяются, необходимо убедиться, что будут обновлены имена участников-служб в соответствии с именами DNS.

  • Удалите имена участников-служб SSP, так как в SharePoint Server 2010 они больше не нужны.

  • Запустите службы C2WT на серверах с приложениями-службами, использующими делегирование (например, Службы Excel, Служба графики Visio).

  • Настройте ограниченное делегирование Kerberos для использования любого протокола проверки подлинности, чтобы разрешить ограниченное делегирование Kerberos для службы C2WTS.

  • Убедитесь, что проверка подлинности режима ядра отключена в службах IIS.