Планирование методов проверки подлинности для пользователей в SharePoint Server
ОБЛАСТЬ ПРИМЕНЕНИЯ:
2013 2016 2019 Subscription Edition 
SharePoint в Microsoft 365
Примечание.
Упомянутые здесь методы проверки подлинности пользователей применяются к SharePoint Server 2013, SharePoint Server 2016, SharePoint Server 2019 и SharePoint Server по подписке.
Узнайте, какие типы и методы проверки подлинности пользователей поддерживаются в SharePoint Server, а также как определить, какие из них следует использовать для веб-приложений и зон.
Сведения о проверке подлинности SharePoint в Microsoft 365.
Примечание.
В SharePoint Server по подписке теперь поддерживается проверка подлинности OIDC 1.0. Дополнительные сведения о том, как работать с этим новым типом проверки подлинности, см. в статье Проверка подлинности OpenID Connect 1.0.
Введение
Проверка подлинности пользователя это проверка личности пользователя у поставщика проверки подлинности, который представляет собой каталог или базу данных с учетными данными пользователей и может подтвердить, что пользователь указал их верно. Примером поставщика проверки подлинности являются доменные службы Active Directory (AD DS). Другим названием поставщика проверки подлинности является каталог пользователя и хранилище атрибутов.
Метод проверки подлинности — это конкретный обмен учетными данными учетной записи и другими сведениями, которые подтверждают удостоверение пользователя. Результатом работы метода проверки подлинности является доказательство (обычно в виде маркера с утверждениями) того, что поставщик проверки подлинности проверил подлинность пользователя.
Тип проверки подлинности это конкретный способ проверки учетных данных у одного или нескольких поставщиков проверки подлинности, иногда с помощью стандартного отраслевого протокола. В одном типе проверки подлинности может использоваться несколько методов проверки подлинности.
После проверки удостоверения пользователя процесс авторизации определяет, к каким сайтам, контенту и другим компонентам может иметь доступ этот пользователь.
Планирование типов и методов проверки подлинности пользователей должно определять следующее:
типы и методы проверки подлинности пользователей для каждого веб-приложения и зоны;
инфраструктуру проверки подлинности, необходимую для поддержки определенных типов и методов проверки подлинности;
Примечание.
Проверка подлинности в классическом режиме Windows больше не поддерживается в SharePoint Server 2016, SharePoint Server 2019 и SharePoint Server по подписке.
Проверка подлинности на основе утверждений
Идентификация пользователей в службах AD DS основана на учетной записи пользователя. Для успешной проверки подлинности пользователь предоставляет имя учетной записи и доказательство знания пароля. Для определения доступа к ресурсам приложениям может потребоваться обратиться к службам AD DS с запросом на получение атрибутов учетной записи и других сведений, таких как членство в группах или роль в сети. Хотя эта функция хорошо подходит для сред Windows, она не масштабируется для сторонних поставщиков проверки подлинности и сред с несколькими поставщиками, которые поддерживают модели интернет-, партнерских или облачных вычислений.
При использовании удостоверений, основанных на утверждениях, пользователь получает цифровой подписанный маркер безопасности от доверенного поставщика удостоверений. Маркер содержит набор утверждений. Каждое утверждение представляет определенный элемент данных о пользователях, например их имена, членство в группах и роль в сети. Проверка подлинности на основе утверждений это проверка подлинности пользователей, в которой используются технологии и инфраструктура удостоверений, основанных на утверждениях. Приложения, поддерживающие проверку подлинности на основе утверждений, получают маркер безопасности от сервера, а не учетные данные, и используют сведения из утверждений для определения доступа к ресурсам. Отдельного обращения к службе каталогов, например AD DS, не требуется.
Проверка подлинности на основе утверждений в Windows основана на платформе Windows Identity Foundation (WIF), которая представляет собой набор классов .NET Framework, используемых для реализации удостоверений, основанных на утверждениях. Проверка подлинности на основе утверждений основана на таких стандартах, как WS-Federation и WS-Trust, и таких протоколах, как SAML.
Дополнительные сведения о проверке подлинности на основе утверждений см. в указанных ниже ресурсах.
Так как проверку подлинности на основе утверждений часто используют для проверки подлинности пользователей, межсерверной проверки подлинности и проверки подлинности приложений, ее рекомендуется использовать для всех веб-приложений и зон фермы 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.
Чтобы настроить веб-приложение для использования проверки подлинности в классическом режиме, необходимо создать его с помощью командлета PowerShell New-SPWebApplication . В веб-приложениях продуктов Продукты SharePoint 2010, в которых используется классический режим проверки подлинности, при обновлении до SharePoint 2013 параметры проверки подлинности сохраняются. Однако перед обновлением до SharePoint 2013 рекомендуется перевести веб-приложения на проверку подлинности на основе утверждений.
В ферме SharePoint 2013 могут быть размещены веб-приложения, использующие оба режима проверки подлинности. Некоторые службы не различают учетные записи пользователей, которые являются традиционными учетными записями Windows, и учетными записями утверждений Windows.
Дополнительные сведения о миграции перед обновлением см. в статье Настройка проверки подлинности на основе утверждений для веб-приложения с классическим режимом проверки подлинности.
Дополнительные сведения о миграции после обновления см. в статье Migrate from classic-mode to claims-based authentication in SharePoint Server.
Сведения о создании веб-приложений, использующих классическую проверку подлинности в SharePoint 2013, см. в статье Создание веб-приложений, использующих классическую проверку подлинности в SharePoint Server. Невозможно перенести веб-приложение, использующее проверку подлинности на основе утверждений, для использования проверки подлинности в классическом режиме.
Важно!
Office Online может работать только с веб-приложениями SharePoint 2013, применяющими проверку подлинности на основе утверждений. Визуализация и редактирование Office Online не будут работать для веб-приложений SharePoint 2013, использующих классический режим проверки подлинности. При переносе в SharePoint 2013 веб-приложений SharePoint 2010, использующих классический режим проверки подлинности, необходимо преобразовать их в приложения, которые используют проверку подлинности на основе утверждений, чтобы эти приложения могли работать с Office Online.
Поддерживаемые типы и методы проверки подлинности
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 для публикации содержимого, которое не требует безопасности и доступно для всех пользователей, например общедоступного веб-сайта в Интернете.
Помимо включения анонимной проверки подлинности необходимо также настроить анонимный доступ (разрешения) для сайтов и ресурсов сайта.
Примечание.
На веб-сайтах Службы IIS, созданных средой SharePoint для обслуживания веб-приложений, всегда должны быть включены анонимный доступ и проверка подлинности с помощью форм, даже если отключены соответствующие параметры SharePoint. Это сделано намеренно, и при отключении анонимного доступа или проверки подлинности с помощью форм непосредственно в параметрах IIS на сайте SharePoint возникнут ошибки.
Проверка подлинности на основе форм
Проверка подлинности на основе форм представляет собой систему управления удостоверениями, основанными на утверждениях, которая основана на членстве в ASP.NET и проверке подлинности поставщика ролей. Проверку подлинности на основе форм можно использовать для учетных данных, хранящихся в поставщике проверки подлинности, например:
Доменные службы Active Directory
база данных, например SQL Server;
хранилище данных (LDAP), например Novell eDirectory, Novell Directory Services (NDS) или Sun ONE.
При проверке подлинности на основе форм пользователи проверяются по учетным данным, которые те вводят в форму входа (обычно на веб-странице). Запросы без проверки подлинности перенаправляются на страницу входа, где пользователь должен предоставить действительные учетные данные и отправить форму. Для прошедших проверку подлинности запросов система создает cookie-файл с ключом для восстановления удостоверения при последующих запросах.
Посмотрите видео о проверке подлинности на основе форм в SharePoint 2013 и SharePoint Server 2016
Примечание.
При проверке подлинности на основе форм учетные данные учетной записи пользователя передаются в виде обычного текста. Поэтому не следует использовать проверку подлинности на основе форм, если не используется протокол SSL для шифрования трафика на веб-сайте.
Дополнительные сведения см. в разделе Планирование проверки подлинности на основе форм.
Проверка подлинности на основе маркеров 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.
Настройте проверку подлинности Kerberos для соединений SQL Server, создав имена участников-служб в службах AD DS для учетной записи службы SQL Server.
Создайте имена участников-служб для веб-приложений, которые будут использовать проверку подлинности Kerberos.
Установите ферму SharePoint Server.
Укажите для конкретных служб в ферме, какие учетные записи они должны использовать.
Создайте веб-приложения, которые будут использовать проверку подлинности Kerberos.
Дайджест-проверка подлинности и обычная проверка подлинности
При дайджест-проверке подлинности учетные данные учетной записи пользователя передаются в виде дайджест-сообщения MD5 службе Службы IIS на веб-сервере, на котором размещается веб-приложение или зона. При обычной проверке подлинности учетные данные учетной записи пользователя передаются в виде обычного текста. Поэтому не следует использовать метод обычной проверки подлинности, если вы также не используете SSL для шифрования трафика веб-сайта.
Может потребоваться использовать эти устаревшие методы проверки подлинности, если в среде используются веб-браузеры или службы, поддерживающие только дайджест-проверку подлинности или обычную проверку подлинности для веб-сайтов.
В отличие от NTLM, анонимной проверки подлинности и проверки подлинности Kerberos, дайджест-проверка подлинности и обычная проверка подлинности настраиваются в свойствах веб-сайта, соответствующего веб-приложению или зоне, в оснастке IIS.
Если вы используете проверку подлинности на основе утверждений, см. следующие статьи:
Настройка дайджест-проверки подлинности на основе утверждений для веб-приложения в SharePoint Server
Настройка обычной проверки подлинности на основе утверждений веб-приложения в SharePoint Server
Планирование проверки подлинности на основе форм
Чтобы использовать проверку подлинности на основе форм для проверки подлинности пользователей в системе управления удостоверениями, которая не основана на Windows или не является внешней, необходимо зарегистрировать поставщика членства и диспетчера ролей в файле Web.config. SharePoint Server использует стандартный интерфейс диспетчера ролей ASP.NET для сбора сведений о группе текущего пользователя. Каждая роль ASP.NET обрабатывается процессом авторизации SharePoint Server как доменная группа. Диспетчеры ролей в файле Web.config регистрируются так же, как регистрируются поставщики членства для проверки подлинности.
При необходимости управлять авторизованными пользователями или ролями через веб-сайт центра Центр администрирования нужно зарегистрировать поставщик членства и диспетчер ролей для центра Центр администрирования в файле Web.config. Зарегистрируйте поставщика членства и диспетчера ролей в файле Web.config для веб-приложения, в котором размещается содержимое.
Подробные указания по настройке проверки подлинности на основе форм см. в этой статье.
Планирование проверки подлинности на основе маркеров SAML
Архитектура для реализации поставщиков проверки подлинности на основе маркеров SAML включает следующие компоненты:
Служба маркеров безопасности SharePoint Эта служба создает маркеры SAML, которые использует ферма. Служба автоматически создается и запускается на всех серверах в ферме серверов. Служба используется для обмена данными между фермами, так как вся связь между фермами использует проверку подлинности на основе утверждений. Эта служба также используется для методов проверки подлинности, реализованных для веб-приложений, использующих проверку подлинности на основе утверждений. Эти методы включают проверка подлинности Windows, проверку подлинности на основе форм и проверку подлинности на основе токена SAML.
Сертификат подписи маркера (ImportTrustCertificate) Этот сертификат экспортируется из IP-STS, а затем копируется на один сервер фермы и добавляется в список доверенных корневых центров фермы. После использования этого сертификата для создания 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.
Служба маркеров безопасности проверяющей стороны (RP-STS) В SharePoint Server каждое веб-приложение, настроенное для использования поставщика SAML, добавляется на сервер IP-STS в качестве записи RP-STS. Ферма SharePoint Server может содержать несколько записей проверяющей стороны службы токенов безопасности.
Служба маркеров безопасности поставщика удостоверений (IP-STS) Эта служба является маркером безопасности в среде утверждений, которая выдает маркеры SAML от имени пользователей, включенных в связанный каталог пользователей.
На следующей схеме показана архитектура утверждений SharePoint Server на основе токенов SAML.
Архитектура утверждений на основе маркеров SAML
Объект SPTrustedIdentityTokenIssuer создается с несколькими параметрами, которые включают:
Одно утверждение удостоверения.
Один параметр SignInURL .
Параметр SignInURL указывает URL-адрес для перенаправления запроса пользователя для проверки подлинности в IP-STS.
Один параметр Wreply .
Для некоторых серверов IP-STS требуется параметр Wreply , для которого задано значение true или false. Значение по умолчанию: false. Используйте параметр Wreply только в том случае, если он требуется для IP-STS.
Несколько областей.
Несколько сопоставлений утверждений.
Чтобы реализовать проверку подлинности на основе токена SAML в SharePoint Server, выполните следующие действия, которые требуют предварительного планирования:
Экспортируйте сертификат для подписи токена из службы токенов безопасности поставщика удостоверений. Скопируйте сертификат на сервер в ферме SharePoint Server.
Определите утверждение, которое будет использоваться в качестве уникального идентификатора пользователя. Это утверждение называется утверждением удостоверения. В качестве идентификатора пользователя часто используется имя участника-пользователя или его адрес электронной почты. Для определения правильного идентификатора свяжитесь с администратором службы маркеров безопасности поставщика удостоверений, поскольку только владелец этой службы знает, какое значение в маркере является уникальным для каждого пользователя. Определение уникального идентификатора для пользователя является частью процесса сопоставления утверждений. Для создания сопоставлений утверждений используется Microsoft PowerShell.
Определение дополнительных сопоставлений утверждений. Определите дополнительные утверждения из входящего маркера, который будет использовать ферма SharePoint Server. Роли пользователя являются примером утверждения, которое можно использовать для предоставления разрешений на ресурсы в ферме SharePoint Server. Все утверждения из входящего маркера, не имеющие сопоставления, будут отменены.
Используйте PowerShell для создания нового поставщика проверки подлинности для импорта сертификата подписи маркера. Этот процесс создает SPTrustedIdentityTokenIssuer. В ходе этого процесса необходимо указать утверждение удостоверения и дополнительные утверждения, которые вы сопоставили. Создайте и укажите область, связанную с первыми веб-приложениями SharePoint, которые настраиваются для проверки подлинности на основе маркеров SAML. После создания SPTrustedIdentityTokenIssuer можно создать и добавить дополнительные области для дополнительных веб-приложений SharePoint. Эта процедура позволяет настроить несколько веб-приложений для использования одного и того же SPTrustedIdentityTokenIssuer.
Для каждой области, добавляемой в SPTrustedIdentityTokenIssuer, необходимо создать запись RP-STS в IP-STS. Эту запись можно создать до появления веб-приложения SharePoint. Независимо от этого, запланировать URL-адрес необходимо до создания веб-приложений.
Для существующего или нового веб-приложения SharePoint настройте в нем использование только что созданного поставщика проверки подлинности. Поставщик проверки подлинности отображается в виде доверенного поставщика удостоверений в центре Центр администрирования при создании веб-приложения.
Можно настроить несколько поставщиков проверки подлинности на основе маркеров SAML. Однако использовать сертификат для подписи маркера в ферме можно только один раз. Все настроенные поставщики появятся в качестве вариантов в центре Центр администрирования. Утверждения из разных доверенных сред STS не будут конфликтовать.
Если проверка подлинности на основе маркеров SAML реализуется совместно с партнерской компанией и используемая среда включает службу маркеров безопасности поставщика удостоверений, рекомендуется связаться с администратором внутренней среды проверки подлинности на основе утверждений, чтобы установить одностороннее доверенное отношение между внутренней службой маркеров безопасности поставщика удостоверений и службой маркеров безопасности партнера. Этот подход не требует добавления поставщика проверки подлинности в ферму SharePoint Server. Он также позволяет администраторам среды утверждений управлять всей средой.
Важно!
При использовании проверки подлинности на основе утверждений в SharePoint Server больше не нужно переводить балансировку сетевой нагрузки в режим с одиночным сходством.
Примечание.
Если веб-приложение настроено для использования проверки подлинности на основе токенов SAML, класс SPTrustedClaimProvider не предоставляет возможности поиска для элемента управления средства выбора людей. Любой введенный в элементе управления средства выбора людей текст будет автоматически отображаться, как будто он допустим, независимо от того, является ли он действительным пользователем, группой или утверждением. Если решение SharePoint Server использует проверку подлинности на основе токенов SAML, запланируйте создание поставщика утверждений для осуществления пользовательского поиска и разрешения имен.
Подробные инструкции по настройке проверки подлинности на основе маркеров SAML с использованием служб AD FS см. в этой статье.
Планирование зон для веб-приложений
Зоны представляют собой разные логические пути для получения доступа к одним сайтам в веб-приложении. Каждое веб-приложение может включать до пяти зон. При создании веб-приложения центр Центр администрирования создает зону с именем default. Дополнительные зоны создаются путем расширения веб-приложения и выбора одной из оставшихся зон: интрасеть, экстрасеть, Интернет или другая.
План создания зон зависит от следующих аспектов:
- Проверка подлинности на основе утверждений (рекомендуется) в одной зоне реализуется несколько поставщиков проверки подлинности. Также можно использовать несколько зон.
Реализация нескольких типов проверки подлинности в одной зоне
Если при использовании проверки подлинности на основе утверждений реализуется несколько методов проверки подлинности, рекомендуется реализовать несколько методов проверки подлинности в зоне по умолчанию. Это позволяет предоставлять один URL-адрес для всех пользователей.
При реализации нескольких методов проверки подлинности в одной зоне применяются следующие ограничения.
В одной зоне можно реализовать только один экземпляр проверки подлинности на основе форм.
Центр Центр администрирования позволяет одновременно использовать встроенную и обычную проверку подлинности Windows. В противном случае в зоне невозможно реализовать более одного типа проверка подлинности Windows.
Если для фермы задано несколько поставщиков проверки подлинности на основе маркеров SAML, при создании веб-приложения или новой зоны можно выбрать одну из них. В одной зоне можно настроить несколько поставщиков SAML.
На следующей схеме показано несколько типов проверки подлинности, реализованных в зоне по умолчанию для партнерского сайта совместной работы.
Несколько типов проверки подлинности, реализованных в зоне по умолчанию
На схеме пользователи из разных хранилищ службы каталогов обращаются к партнерскому веб-сайту с помощью одного URL-адреса. Штриховая рамка вокруг партнерских компаний показывает отношение между каталогом пользователя и типом проверки подлинности, заданным для зоны по умолчанию.
Планирование обхода контента
Компоненту обхода для доступа к контенту требуется проверка подлинности NTLM. По крайней мере для одной зоны должна быть настроена проверка подлинности NTLM. Если проверка подлинности NTLM не настроена в зоне по умолчанию, компонент обхода может использовать другую зону, настроенную для проверки подлинности NTLM.
Реализация нескольких зон
Если в веб-приложении планируется реализация нескольких зон, придерживайтесь следующих рекомендаций.
Для реализации проверки подлинности с наиболее безопасными параметрами используйте зону по умолчанию. Если запрос не может быть связан с определенной зоной, применяются параметры проверки подлинности и другие политики безопасности зоны по умолчанию. Зона по умолчанию это зона, созданная при создании веб-приложения. Обычно наиболее безопасные параметры проверки подлинности предназначены для доступа конечных пользователей. Таким образом, конечные пользователи, скорее всего, будут получать доступ к зоне по умолчанию.
Используйте минимальное число зон, которые требуются для обеспечения доступа пользователей. Каждая зона связана с новым сайтом и доменом IIS для доступа к веб-приложению. Добавляйте новые точки доступа только при необходимости.
Убедитесь, что хотя бы в одной зоне для компонента обхода контента настроено использование проверки подлинности NTLM. Не создавайте выделенную зону для компонента индекса, если это не требуется.
На следующей схеме показано несколько зон, реализованных с использованием разных типов проверки подлинности для партнерского сайта совместной работы.
Одна зона для каждого типа проверки подлинности
На схеме зона по умолчанию используется для удаленных сотрудников. У каждой зоны имеется свой связанный с ней URL-адрес. Сотрудники используют другую зону в зависимости от того, работают ли они в офисе или удаленно.