Проблемы

Рассмотрим следующий сценарий.

  • В веб-приложении Microsoft SharePoint Server 2013 вы используете проверку подлинности Windows (с помощью запроса или ответа Windows [NTLM] или Kerberos).

  • Вы решили переключиться на утверждения доверенного поставщика с помощью поставщика, основанного на на использовании языка разметки приложений (на основе SAML), например служб федерации Active Directory (AD FS).

  • Вы просматриваете шаги, описанные в статье Миграция проверки подлинности утверждений Windows на проверку подлинности с помощью SAML в SharePoint Server 2013 на веб-сайте Microsoft Developer Network (MSDN).

  • Вы запускаете следующую команду:

    Convert-SPWebApplication-ID $wa-to CLAIMs-TRUSTed-DEFAULT-from CLAIMs-WINDOWS-TrustedProvider $tp-SourceSkipList $csv-RetainPermissions

В этом случае появляется следующее сообщение об ошибке:

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

Причина

Эта проблема возникает из-за того, что доверенный поставщик маркера удостоверения не был создан с помощью конфигурации по умолчанию. Для правильной работы команды Convert-SPWebApplication необходимо использовать конфигурацию по умолчанию. Для использования команды Convert-SPWebApplication требуется определенная конфигурация доверенного поставщика для совместимости с преобразованием из Windows утверждений в SAML или наоборот. В частности, для создания доверенного маркера идентификации необходимо использовать параметры UseDefaultConfiguration и IdentifierClaimIs . Вы можете проверить, создан ли доверенный поставщик маркеров идентификации с помощью параметра UseDefaultConfiguration , выполнив следующие сценарии Windows PowerShell.Примечание. В этих сценариях предполагается, что у вас есть только один доверенный поставщик удостоверений, созданный в текущей ферме.

$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes 

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

  • http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname

  • http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid

  • http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

#Get the Identity claim:$tp = Get-SPTrustedIdentityTokenIssuer$tp.IdentityClaimTypeInformation 

Заявка на идентификацию должна иметь одно из следующих значений:

  • WindowAccountName

  • EmailAddress

  • ИДЕНТИФИКАЦИОН

Пример выходных данных для $tp. IdentityClaimTypeInformation: DisplayName: email InputClaimType: http://schemas.xmlsoap.org/WS/2005/05/Identity/Claims/EmailAddressMappedClaimType: http://schemas.xmlsoap.org/WS/2005/05/Identity/Claims/EmailAddress#IsIdentityClaim : true, должен быть настраиваемый поставщик запросов с тем же именем, что и у поставщика маркера, а также тип SPTrustedBackedByActiveDirectoryClaimProvider. Запустите этот элемент, чтобы узнать, есть ли у поставщика утверждений и он совместимый:

 $tp = Get-SPTrustedIdentityTokenIssuer$name = $tp.name$cp = Get-SPClaimProvider $nameif($cp.typename -match "SPTrustedBackedByActiveDirectoryClaimProvider"){write-host "Claim provider is present and has TypeName of " $cp.typename " it should be valid"}else{write-host "Claim provider is not present. Trusted Identity Token Issuer" $tp.name " is not compatible with convert-spwebapplication"}

Решение

Чтобы устранить эту проблему, удалите и повторно создайте доверенный поставщик маркеров идентификации. Для этого выполните следующие действия:

  1. Выполните следующий сценарий:

    $tp = Get-SPTrustedIdentityTokenIssuer$tp | fl$tp.name$tp.IdentityClaimTypeInformation

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

  2. Удалите текущий доверенный поставщик удостоверений из служб проверки подлинности для любого веб-приложения, которое сейчас использует его.

  3. Удалите поставщика маркера, выполнив следующую команду:

    Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"
  4. Повторно создайте поставщика маркера. Для этого выполните действия, описанные в разделе Реализация проверки подлинности на основе SAML в SharePoint Server 2013 на веб-сайте Microsoft TechNet, чтобы получить дополнительные сведения.Важно! При выполнении команды New-SPTrustedIdentityTokenIssuer необходимо использовать параметры UseDefaultConfiguration и IdentifierClaimIs . Параметр UseDefaultConfiguration является всего лишь переключателем. Для параметра IdentifierClaimIs возможны следующие значения:

    • ИМЯ УЧЕТНОЙ ЗАПИСИ

    • Отправить по электронной почте

    • ИМЯ УЧАСТНИКА-ПОЛЬЗОВАТЕЛЯ

    Пример сценария:

    $ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
  5. В центре администрирования добавьте новый доверенный поставщик маркера удостоверения в список поставщиков проверки подлинности для веб-приложения, которое вы пытаетесь преобразовать. Для веб-приложения должны быть выбраны проверка подлинности Windows и целевой доверенный поставщик удостоверений.

Дополнительная информация

Дополнительные советы по успешному преобразованию: Если значение электронной почты используется для утверждения идентификатора (то есть для параметра IdentifierClaimIs ), будут преобразованы только те пользователи, чьи адреса электронной почты были заполнены в службе каталогов Active Directory. Все учетные записи пользователей, которые указаны в CSV-файле, определенном в параметре SourceSkipList , не будут преобразованы в SAML. Для преобразования из Windows утверждений в SAML имена учетных записей пользователей могут быть указаны с использованием нотации утверждений или без нее. Например, "contoso\user1" или "i:0 #. w | contoso\user1" является приемлемым вариантом. Добавьте в этот CSV-файл все учетные записи пользователей, которые не нужно преобразовывать. Они должны включать учетные записи служб и учетные записи администраторов.

Нужна дополнительная помощь?

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединение к программе предварительной оценки Майкрософт

Были ли сведения полезными?

Насколько вы удовлетворены качеством перевода?
Что повлияло на вашу оценку?

Спасибо за ваш отзыв!

×