Планирование методов проверки подлинности для пользователей в SharePoint Server

**Применимо к:**SharePoint Server 2013, SharePoint Server 2016

**Последнее изменение раздела:**2017-06-21

Сводка. Узнайте, как использовать различные способы проверки подлинности в SharePoint Server 2013 и SharePoint Server 2016 для обеспечения безопасного входа пользователей в веб-приложения.

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

В этой статье

• Введение

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

• Поддерживаемые типы и методы проверки подлинности

• Планирование проверки подлинности Windows

• Планирование проверки подлинности на основе форм

• Планирование проверки подлинности на основе маркеров SAML

• Планирование зон для веб-приложений

Введение

Проверка подлинности пользователя — это проверка личности пользователя у поставщика проверки подлинности, который представляет собой каталог или базу данных с учетными данными пользователей и может подтвердить, что пользователь указал их верно. Примером поставщика проверки подлинности являются доменные службы Active Directory (AD DS). Другим названием поставщика проверки подлинности является каталог пользователя и хранилище атрибутов.

Метод проверки подлинности — это конкретная процедура обмена учетными данными учетной записи и другими сведениями, которые подтверждают личность пользователя. Результатом работы метода проверки подлинности является доказательство (обычно в виде маркера с утверждениями) того, что поставщик проверки подлинности проверил подлинность пользователя.

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

После проверки удостоверения пользователя процесс авторизации определяет, к каким сайтам, контенту и другим компонентам может иметь доступ этот пользователь.

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

• типы и методы проверки подлинности пользователей для каждого веб-приложения и зоны;

• инфраструктуру проверки подлинности, необходимую для поддержки определенных типов и методов проверки подлинности;

  Примечание

  Классический режим проверки подлинности Windows больше не поддерживается в SharePoint Server 2016.

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

Идентификация пользователей в службах AD DS основана на учетной записи пользователя. Для успешной проверки подлинности пользователь предоставляет имя учетной записи и доказательство знания пароля. Для определения доступа к ресурсам приложениям может потребоваться обратиться к службам AD DS с запросом на получение атрибутов учетной записи и других сведений, таких как членство в группах или роль в сети. Это неплохо работает в средах Windows, но не подходит для горизонтального масштабирования с включением сторонних поставщиков проверки подлинности и сред разных поставщиков, поддерживающих вычислительные модели через Интернет, в партнерских системах и облаке.

При использовании удостоверений, основанных на утверждениях, пользователь получает цифровой подписанный маркер безопасности от доверенного поставщика удостоверений. Маркер содержит набор утверждений. Каждое утверждение представляет определенный элемент данных о пользователе, например его имя, членство в группах и роль в сети. Проверка подлинности на основе утверждений — это проверка подлинности пользователей, в которой используются технологии и инфраструктура удостоверений, основанных на утверждениях. Приложения, поддерживающие проверку подлинности на основе утверждений, получают маркер безопасности от сервера, а не учетные данные, и используют сведения из утверждений для определения доступа к ресурсам. Отдельного обращения к службе каталогов, например AD DS, не требуется.

Проверка подлинности на основе утверждений в Windows основана на платформе Windows Identity Foundation (WIF), которая представляет собой набор классов .NET Framework, используемых для реализации удостоверений, основанных на утверждениях. Проверка подлинности на основе утверждений основана на таких стандартах, как WS-Federation и WS-Trust, и таких протоколах, как SAML.

Дополнительные сведения о проверке подлинности на основе утверждений см. в указанных ниже ресурсах.

• Удостоверение, основанное на утверждениях для Windows (технический документ)

• Домашняя страница Windows Identity Foundation

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

При использовании проверки подлинности на основе утверждений SharePoint Server автоматически преобразует все учетные записи пользователей в удостоверения на основе утверждений. Это ведет к созданию токена безопасности (также называется токеном утверждений) для каждого пользователя. Токен утверждений содержит утверждения, относящиеся к пользователю. Учетные записи Windows преобразуются в утверждения Windows. Данные о пользователях с членством на основе форм преобразуются в утверждения для проверки подлинности на основе форм. В SharePoint Server можно использовать утверждения, входящие в токены SAML. Кроме того, разработчики и администраторы SharePoint могут включать в токены пользователей дополнительные утверждения. Например, учетные записи пользователей Windows и учетные записи на основе форм можно дополнить утверждениями, используемыми в SharePoint Server.

Чтобы использовать проверку подлинности на основе утверждений в SharePoint Server, не нужно быть архитектором утверждений. Однако для реализации проверки подлинности на основе токенов SAML требуется взаимодействие с администраторами среды, построенной на базе утверждений, как показано в разделе Планирование проверки подлинности на основе токенов SAML.

Классическая проверка подлинности в SharePoint Server 2013

В SharePoint 2013 при создании веб-приложения в центре администрирования можно указать только типы и методы для проверки подлинности на основе утверждений. В прошлых версиях SharePoint в центре администрирования также можно было задать классическую проверку подлинности для веб-приложений. При классической проверке подлинности используется проверка подлинности Windows, а SharePoint 2013 рассматривает учетные записи пользователей как учетные записи служб AD DS.

Чтобы использовать в веб-приложении классический режим проверки подлинности, необходимо создать проверку с помощью командлета PowerShellNew-SPWebApplication. В веб-приложениях продуктов Продукты SharePoint 2010, в которых используется классический режим проверки подлинности, при обновлении до SharePoint 2013 параметры проверки подлинности сохраняются. Однако перед обновлением до SharePoint 2013 рекомендуется перевести веб-приложения на проверку подлинности на основе утверждений.

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

Дополнительные сведения о миграции перед обновлением см. в статье Настройка проверки подлинности на основе утверждений для веб-приложения с классическим режимом проверки подлинности.

Дополнительные сведения о миграции после обновления см. в статье Настройка проверки подлинности на основе утверждений для веб-приложения с классическим режимом проверки подлинности в SharePoint 2013.

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

Поддерживаемые типы и методы проверки подлинности

SharePoint Server поддерживает различные методы и службы проверки подлинности для следующих типов проверки подлинности:

• Проверка подлинности Windows

• Проверка подлинности на основе форм

• Проверка подлинности на основе маркеров SAML

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

В проверке подлинности Windows применяется существующий поставщик проверки подлинности Windows (AD DS) и протоколы проверки подлинности, используемые в среде домена Windows для проверки учетных данных подключающихся клиентов. В проверке подлинности на основе утверждений используются следующие методы проверки подлинности Windows:

• NTLM

• Kerberos

• Дайджест-проверка

• Обычный

Дополнительные сведения см. в разделе Планирование проверки подлинности Windows в этой статье.

Посмотрите видео о проверке подлинности на основе утверждений Windows в SharePoint 2013 и SharePoint Server 2016

В SharePoint Server также поддерживается анонимная проверка подлинности, хотя она и не является типом проверки подлинности Windows. Пользователи могут обращаться к контенту SharePoint без проверки их учетных данных. Анонимная проверка подлинности по умолчанию отключена. Обычно анонимная проверка подлинности применяется при использовании SharePoint Server для публикации контента, не требующего обеспечения безопасности и доступного для всех пользователей, такого как общедоступный веб-сайт в Интернете.

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

Проверка подлинности на основе форм

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

• Доменные службы Active Directory

• база данных, например SQL Server;

• хранилище данных (LDAP), например Novell eDirectory, Novell Directory Services (NDS) или Sun ONE.

При проверке подлинности на основе форм пользователи проверяются по учетным данным, которые те вводят в форму входа (обычно на веб-странице). Запросы, не прошедшие проверку подлинности, перенаправляются на страницу входа, где пользователю необходимо указать действительные учетные данные и отправить форму. Для прошедших проверку подлинности запросов система создает cookie-файл с ключом для восстановления удостоверения при последующих запросах.

Посмотрите видео о проверке подлинности на основе форм в SharePoint 2013 и SharePoint Server 2016

Дополнительные сведения см. в разделе Планирование проверки подлинности на основе форм.

Проверка подлинности на основе маркеров SAML

Проверка подлинности на основе токенов SAML в SharePoint Server основана на протоколе SAML 1.1 и стандарте WS-Federation Passive Requestor Profile (WS-F PRP). Для нее требуется координация действий с администраторами среды на основе утверждений, как собственной внутренней среды, так и среды партнера. При использовании служб федерации Active Directory (AD FS) 2.0 имеется среда проверки подлинности на основе токенов SAML.

Среда проверки подлинности на основе маркеров SAML включает службу маркеров безопасности поставщика удостоверений. Служба маркеров безопасности поставщика удостоверений выдает маркеры SAML от имени пользователей, учетные записи которых включены в список связанного поставщика проверки подлинности. Маркеры могут включать любое число утверждений о пользователе, таких как имя пользователя и группы, в которые он входит. Примером службы маркеров безопасности поставщика удостоверений является сервер AD FS 2.0.

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

Посмотрите видео о проверке подлинности на основе утверждений SAML в SharePoint 2013 и SharePoint Server 2016

Набор поставщиков проверки подлинности для проверки подлинности на основе маркеров SAML зависит от службы маркеров безопасности поставщика удостоверений в среде на основе утверждений. При использовании AD FS 2.0 поставщиками проверки подлинности (которые называются хранилищами атрибутов для AD FS 2.0) могут быть:

• Windows Server 2003 Active Directory и доменные службы AD DS в Windows Server 2008;

• все выпуски SQL Server 2005 и SQL Server 2008;

• пользовательские хранилища атрибутов.

Дополнительные сведения см. в разделе Планирование проверки подлинности на основе маркеров SAML.

Выбор метода проверки подлинности для сред LDAP

Проверку подлинности на основе форм или токенов SAML можно использовать в средах LDAP. Следует использовать тип проверки подлинности, соответствующий текущей среде LDAP. Если среды LDAP еще нет, рекомендуется использовать проверку подлинности на основе форм, поскольку она менее сложна. Однако если среда проверки подлинности уже поддерживает стандарт WS-Federation 1.1 и протокол SAML 1.1, то рекомендуется SAML. В SharePoint Server есть встроенный поставщик LDAP.

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

Процесс планирования и реализации методов проверки подлинности Windows аналогичен для обоих методов проверки подлинности (на основе утверждений и классического режима). Если выбрать для веб-приложения проверку подлинности на основе утверждений, сложность реализации методов проверки подлинности Windows не повысится. В данном разделе приведены сводные данные для каждого метода.

NTLM и протокол Kerberos

И NTLM, и протокол Kerberos являются встроенными методами проверки подлинности Windows, что позволяет пользователям выполнять проверку подлинности без ввода учетных данных. Например:

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

• Службы и приложения, получающие доступ к ресурсам SharePoint с использованием методов встроенной проверки подлинности Windows, пытаются использовать учетные данные запущенного потока, которые по умолчанию представляют собой удостоверение процесса

NTLM — это самый простой в реализации вариант проверки подлинности Windows, который обычно не требует дополнительной настройки инфраструктуры проверки подлинности. Просто выберите этот параметр при создании или настройке веб-приложения.

Протокол Kerberos поддерживает проверку подлинности на основе билетов. Для использования протокола Kerberos требуется дополнительная настройка среды. Чтобы использовать проверку подлинности Kerberos, компьютеры сервера и клиента должны иметь доверенное подключение к центру распределения ключей домена. Настройка протокола Kerberos включает задание имен участников-служб в службах AD DS перед установкой SharePoint Server.

Ниже приводятся преимущества проверки подлинности Kerberos.

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

• Протокол Kerberos обеспечивает делегирование учетных данных клиентов.

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

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

Ниже приводятся причины, по которым проверка подлинности Kerberos может быть неприемлема.

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

• Проверка подлинности Kerberos требует подключения клиентского компьютера к центру распределения ключей и контроллеру домена доменных служб Active Directory (AD DS). В развертывании Windows центр распределения ключей является контроллером домена доменных служб Active Directory. Хотя такая конфигурация сети и распространена в интрасети предприятий, развертывания с выходом в Интернет обычно таким образом не настраиваются.

Далее приводится сводка по настройке проверки подлинности Kerberos.

1. Настройте проверку подлинности Kerberos для соединений SQL Server, создав имена участников-служб в службах AD DS для учетной записи службы SQL Server.

2. Создайте имена участников-служб для веб-приложений, которые будут использовать проверку подлинности Kerberos.

3. Установите ферму SharePoint Server.

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

5. Создайте веб-приложения, которые будут использовать проверку подлинности Kerberos.

Дайджест-проверка подлинности и обычная проверка подлинности

При дайджест-проверке подлинности учетные данные учетной записи пользователя передаются в виде дайджест-сообщения MD5 службе IIS на веб-сервере, на котором размещается веб-приложение или зона. При обычной проверке подлинности учетные данные учетной записи пользователя передаются в виде обычного текста. Поэтому не следует использовать базовую проверку подлинности, если не используется протокол SSL для шифрования трафика на веб-сайте.

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

В отличие от NTLM, анонимной проверки подлинности и проверки подлинности Kerberos, дайджест-проверка подлинности и обычная проверка подлинности настраиваются в свойствах веб-сайта, соответствующего веб-приложению или зоне, в оснастке IIS.

При использовании проверки подлинности на основе утверждений, см.:

• Настройка дайджест-проверки подлинности на основе утверждений для веб-приложения в SharePoint 2013

• Настройка обычной проверки подлинности на основе утверждений для веб-приложения в SharePoint Server 2013

Планирование проверки подлинности на основе форм

Чтобы использовать проверку подлинности на основе форм для проверки подлинности пользователей во внешней или не основанной на технологиях Windows системе управления удостоверениями, необходимо зарегистрировать поставщик членства и диспетчер ролей в файле Web.config. SharePoint Server использует стандартный интерфейс диспетчера ролей ASP.NET для сбора сведений о группе текущего пользователя. Каждая роль ASP.NET обрабатывается процессом авторизации SharePoint Server как доменная группа. Диспетчеры ролей в файле Web.config регистрируются так же, как регистрируются поставщики членства для проверки подлинности.

При необходимости управлять авторизованными пользователями или ролями через веб-сайт центра Центр администрирования нужно зарегистрировать поставщик членства и диспетчер ролей для центра Центр администрирования в файле Web.config. Поставщик членства и диспетчер ролей также необходимо зарегистрировать в файле Web.config для веб-приложения, которое предоставляет удаленный доступ к контенту.

Подробные действия по настройке проверки подлинности на основе форм см. в статье Настройка проверки подлинности на основе форм для веб-приложения на основе утверждений в SharePoint 2013

Планирование проверки подлинности на основе маркеров SAML

Архитектура для реализации поставщиков проверки подлинности на основе маркеров SAML включает следующие компоненты:

• Служба маркеров безопасности SharePoint   Эта служба создает маркеры SAML, которые используются в ферме. Служба автоматически создается и запускается на всех серверах в ферме серверов. Служба используется для взаимодействия между фермами, поскольку для любой связи между фермами используется проверка подлинности на основе утверждений. Эта служба также используется для методов проверки подлинности, реализованных для веб-приложений с проверкой подлинности на основе утверждений, включая проверку подлинности Windows, проверку подлинности на основе форм и маркеров SAML.

• Сертификат для подписи маркера (ImportTrustCertificate)   Это сертификат, который экспортируется из службы маркеров безопасности поставщика удостоверений и затем копируется на один сервер в ферме и добавляется в список доверенных корневых центров сертификации для фермы. После использования этого сертификата для создания объекта SPTrustedIdentityTokenIssuer, использовать его для создания другого объекта нельзя. При необходимости использовать сертификат для создания другого объекта SPTrustedIdentityTokenIssuer сначала нужно удалить первый объект. Перед удалением необходимо отменить его связи со всеми веб-приложениями, которые могут его использовать.

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

• Другие утверждения. Эти утверждения состоят из дополнительных утверждений из билета SAML, которые описывают пользователей. Среди них могут быть указание ролей пользователей, групп пользователей и другие виды утверждений, например указание возраста. Все сопоставления утверждений создаются в виде объектов, которые реплицируются на серверах в ферме SharePoint Server.

• Область   В архитектуре утверждений SharePoint URI или URL-адрес, связанный с веб-приложением SharePoint, использующим поставщик на основе маркеров SAML, представляет область. При создании поставщика проверки подлинности на основе маркеров SAML в ферме по одной указываются области (URL-адреса веб-приложения), которые должны распознаваться службой маркеров безопасности поставщика удостоверений. Первая область указывается при создании объекта SPTrustedIdentityTokenIssuer. Дополнительные области можно включить после создания SPTrustedIdentityTokenIssuer. Области создаются с использованием синтаксиса вида: $realm = "urn:sharepoint:mysites". После добавления области в объект SPTrustedIdentityTokenIssuer необходимо создать отношение доверия для проверяющей стороны службы маркеров безопасности и идентификатора области на сервере службы маркеров безопасности поставщика удостоверений. Это включает указание URL-адреса для веб-приложения.

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

• Проверяющая сторона службы токенов безопасности. В SharePoint Server каждое веб-приложение, в котором настроено использование поставщика SAML, добавляется на сервер службы токенов безопасности поставщика удостоверений в качестве записи проверяющей стороны службы токенов безопасности. Ферма SharePoint Server может содержать несколько записей проверяющей стороны службы токенов безопасности.

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

На следующей схеме показана архитектура утверждений SharePoint Server на основе токенов SAML.

Архитектура утверждений на основе маркеров SAML

Объект SPTrustedIdentityTokenIssuer создается с несколькими параметрами:

• Одно утверждение удостоверения.

• Один параметр SignInURL.

  Параметр SignInURL задает URL-адрес для перенаправления запроса пользователя при проверке подлинности для IP-STS.

• Один параметр Wreply.

  Для некоторых серверов IP-STS требуется указать параметры Wreply, который может принимать значение true или false. Значение по умолчанию: false. Используйте параметр Wreply, только если он требуется IP-STS.

• Несколько областей.

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

Для реализации проверки подлинности на основе токенов SAML в SharePoint Server выполните следующие действия, для которых требуется предварительное планирование:

1. Экспортируйте сертификат для подписи токена из службы токенов безопасности поставщика удостоверений. Скопируйте сертификат на сервер в ферме SharePoint Server.

2. Определите утверждение, которое будет использоваться в качестве уникального идентификатора пользователя. Оно называется идентификационным утверждением. В качестве идентификатора пользователя часто используется имя участника-пользователя или его адрес электронной почты. Для определения правильного идентификатора свяжитесь с администратором службы маркеров безопасности поставщика удостоверений, поскольку только владелец этой службы знает, какое значение в маркере является уникальным для каждого пользователя. Определение уникального идентификатора для пользователя является частью процесса сопоставления утверждений. Сопоставления утверждений создаются с помощью Microsoft PowerShell.

3. Определите дополнительные сопоставления утверждений. Определите, какие дополнительные утверждения из входящего токена будут использоваться в ферме SharePoint Server. Роли пользователя являются примером утверждения, которое можно использовать для предоставления разрешений на ресурсы в ферме SharePoint Server. Все утверждения из входящего токена, для которых нет сопоставления, отклоняются.

4. Создайте новый поставщик проверки подлинности для импорта сертификата для подписи токена с помощью PowerShell. В результате будет создан объект SPTrustedIdentityTokenIssuer. Во время этого процесса нужно указать идентификационное утверждение и дополнительные сопоставленные утверждения. Также необходимо создать и указать область, связанную с первыми веб-приложениями SharePoint, для которых настраивается использование проверки подлинности на основе токенов SAML. После создания объекта SPTrustedIdentityTokenIssuer можно создать и добавить дополнительные области для других веб-приложений SharePoint. Таким образом в нескольких веб-приложениях задается использование одного объекта SPTrustedIdentityTokenIssuer.

5. Для каждой области, добавленной в объект SPTrustedIdentityTokenIssuer, необходимо создать запись проверяющей стороны службы токенов безопасности в службе токенов безопасности поставщика удостоверений. Это можно сделать до создания веб-приложения SharePoint. Независимо от этого, запланировать URL-адрес необходимо до создания веб-приложений.

6. Для существующего или нового веб-приложения SharePoint настройте в нем использование только что созданного поставщика проверки подлинности. Поставщик проверки подлинности отображается в виде доверенного поставщика удостоверений в центре Центр администрирования при создании веб-приложения.

Можно настроить несколько поставщиков проверки подлинности на основе маркеров SAML. Однако использовать сертификат для подписи маркера в ферме можно только один раз. Все настроенные поставщики появятся в качестве вариантов в центре Центр администрирования. Утверждения из разных доверенных сред службы маркеров безопасности не конфликтуют.

Если проверка подлинности на основе токенов SAML реализуется совместно с партнерской компанией и используемая среда включает службу токенов безопасности поставщика удостоверений, рекомендуется связаться с администратором внутренней среды проверки подлинности на основе утверждений, чтобы установить одностороннее доверенное отношение между внутренней службой токенов безопасности поставщика удостоверений и службой токенов безопасности партнера. При таком подходе добавлять дополнительный поставщик проверки подлинности в ферму SharePoint Server не нужно. Он также позволяет администраторам среды утверждений управлять всей средой.

Подробные инструкции по настройке проверки подлинности на основе маркеров SAML с использованием служб AD FS см. в статье Настройка проверки подлинности на основе утверждений SAML с помощью AD FS в SharePoint 2013.

Планирование зон для веб-приложений

Зоны представляют собой разные логические пути для получения доступа к одним сайтам в веб-приложении. Каждое веб-приложение может включать до пяти зон. При создании веб-приложения центр Центр администрирования создает зону с именем default. Дополнительные зоны создаются путем расширения веб-приложения и выбора одной из оставшихся зон: интрасеть, экстрасеть, Интернет или другая.

План создания зон зависит от следующих аспектов:

• Проверка подлинности на основе утверждений (рекомендуется) — в одной зоне реализуется несколько поставщиков проверки подлинности. Также можно использовать несколько зон.

Реализация нескольких типов проверки подлинности в одной зоне

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

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

• В одной зоне можно реализовать только один экземпляр проверки подлинности на основе форм.

• Центр Центр администрирования позволяет одновременно использовать встроенную и обычную проверку подлинности Windows. В других случаях реализовывать в одной зоне более одного типа проверки подлинности Windows нельзя.

Если для фермы задано несколько поставщиков проверки подлинности на основе маркеров SAML, при создании веб-приложения или новой зоны можно выбрать одну из них. В одной зоне можно настроить несколько поставщиков SAML.

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

Несколько типов проверки подлинности, реализованных в зоне по умолчанию

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

Планирование обхода контента

Компоненту обхода для доступа к контенту требуется проверка подлинности NTLM. По крайней мере для одной зоны должна быть настроена проверка подлинности NTLM. Если проверка подлинности NTLM не задана для зоны по умолчанию, то компонент обхода может использовать другую зону, в которой настроена проверка подлинности NTLM.

Реализация нескольких зон

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

• Для реализации проверки подлинности с наиболее безопасными параметрами используйте зону по умолчанию. Если запрос невозможно связать с определенной зоной, применяются параметры проверки подлинности и другие политики безопасности зоны по умолчанию. Зона по умолчанию — это зона, созданная при создании веб-приложения. Обычно наиболее безопасные параметры проверки подлинности предназначены для доступа конечных пользователей. Таким образом, конечные пользователи, как правило, будут использовать зону по умолчанию.

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

• Убедитесь, что хотя бы в одной зоне для компонента обхода контента настроено использование проверки подлинности NTLM. Не следует без необходимости создавать выделенную зону для компонента индексирования.

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

Одна зона для каждого типа проверки подлинности

На схеме зона по умолчанию используется для удаленных сотрудников. У каждой зоны имеется свой связанный с ней URL-адрес. Сотрудники используют разные зоны в зависимости от того, работают они из офиса или на выезде.