Os suplementos hospedados pelo provedor param de funcionar e o erro HTTP 401 depois de configurar os recursos híbridos do farm do SharePoint

Artigo
07/22/2022
5 minutos para o fim da leitura
Aplica-se a:

SharePoint Server 2016, SharePoint Server 2013

Sintomas

Considere o seguinte cenário. Você tem suplementos existentes e implantados hospedados pelo provedor (PHA) RegisteredIssuerName que estão registrados como e que contêm o valor original do farm RealmID do SharePoint 2013 ou sharePoint 2016 e/ou criou uma associação de Gerenciador de Fluxos de Trabalho em seu farm.

Nesse cenário, quando você acessa essas PHAs depois de configurar recursos híbridos do SharePoint em seu farm, as PHAs param de funcionar. Além disso, você recebe uma mensagem de erro HTTP 401 quando é direcionado para os suplementos.

Observação

As PHAs podem incluir um aplicativo Web hospedado externamente, um serviço, um banco de dados ou um componente do SharePoint. Esse problema não existirá se você configurar os recursos híbridos primeiro e, em seguida, implantar suplementos hospedados pelo provedor e/ou Gerenciador de Fluxos de Trabalho em um farm do SharePoint 2013 ou do SharePoint 2016.

Motivo

Configurar recursos híbridos do SharePoint para SharePoint 2013 ou SharePoint 2016 interrompe relações de confiança de servidor para servidor (S2S) criadas antes de configurar recursos híbridos. Quando você tenta estabelecer uma relação de confiança S2S usando o script de integração do SSA na Nuvem ou o Seletor Híbrido, o realm de autenticação do farm local é atualizado para corresponder à ID de contexto de locatário do Microsoft 365. O script define o realm de autenticação usando o cmdlet Set-SPAuthenticationRealm . Depois que o realm de autenticação é alterado, os suplementos existentes do SharePoint não são autenticados.

Essa falha de autenticação ocorre devido a como os suplementos hospedados pelo provedor estão autorizados a acessar o SharePoint. Os suplementos do SharePoint são associados SPTrustedSecurityTokenIssuers usando o IssuerId valor. Na solicitação, um suplemento tenta obter um token do STS (Emissor do Serviço de Token Seguro). Os emissores de token estão vinculados ao realm de autenticação. Depois que o realm é alterado, os suplementos do SharePoint não podem mais ser autenticados com êxito. O emissor de token confiável que tem a ID do emissor correta ainda existe no farm. No entanto, ele está associado ao realm de autenticação anterior. O valor RegisteredIssuerName real é IssuerId@OldAuthRealmGuid, no qual o oldAuthRealmGuid valor não corresponde mais ao valor AuthRealmGuid atual. O suplemento não é autenticado porque o STS não consegue encontrar um emissor de token correspondente.

A seguinte mensagem de erro é registrada em logs uls e indica claramente que o emissor do token RealmID não é mais confiável porque seu valor não corresponde mais ao farm:

SPApplicationAuthenticationModule: falha ao autenticar a solicitação, erro desconhecido. Detalhes da exceção: System.IdenitytModel.Tokens.SecurityTokenException: os problemas do token não são um emissor confiável.

Solução

Quando você configura o híbrido, RealmID é alterado para corresponder à ID de locatário da sua assinatura do Office365. Isso faz com que os suplementos parem de funcionar, conforme explicado na seção "Sintomas". Para restaurar a funcionalidade do suplemento do SharePoint, registre os suplementos hospedados RegisteredIssuerName pelo provedor usando o valor que contém a nova ID de realm. Em seguida, reaplique as permissões de suplemento para cada instância de suplemento.

Para reparar problemas relacionados à autenticação associados a suplementos hospedados pelo provedor e recursos híbridos, siga estas etapas:

Execute o script a seguir para descobrir todas as instâncias de aplicativo implantadas em um aplicativo Web:

No script a seguir, substitua {0} pelo aplicativo Web. As saídas do script são o título do aplicativo, a ID do cliente do aplicativo e a Web de destino de todos os suplementos hospedados pelo provedor. Esses valores serão usados como entradas na etapa 3.

 Add-PsSnapin Microsoft.SharePoint.PowerShell
 Add-PsSnapin Microsoft.SharePoint.PowerShell
 $webApp = Get-SPWebApplication "{0}"
 foreach($site in $webApp.Sites){
 foreach($web in $site.AllWebs)
 {
 $appInstance = Get-SPAppInstance -Web $web.Url | ? {$_.LaunchUrl -notlike "~appWebUrl*"} | select Title, AppPrincipalId
 if($appInstance -ne $null)
 {
 foreach ($instance in $appInstance)
 {
 $tmp = $instance.AppPrincipalId.Split('|@',[System.StringSplitOptions]::RemoveEmptyEntries)
 $appInfo = $instance.Title + " - " + $tmp[$tmp.Count - 2] + " - " + $web.Url
 Write-Output $appInfo
 }
 }
 }
 }

Atualize SPTrustedSecurityTokenIssuers usando o seguinte script:

 $NewRealm = Get-SPAuthenticationRealm
 $sts = Get-SPTrustedSecurityTokenIssuer | ? {$_.Name -ne 'EvoSTS-Trust' -and $_.Name -ne 'ACS_STS'} | Select RegisteredIssuerName
 $realm = $sts | ?{$_.RegisteredIssuerName -ne $null} | %{$($($_.RegisteredIssuerName).toString().split('@',2)[1]).toString()} | ?{$_ -ne '*' -and $_ -ne $newRealm}
 if($Realm.count -gt 0) {
 $TempRealm = '*@$($NewRealm)'
 $Issuers = Get-SPTrustedSecurityTokenIssuer | ?{$_.Name -ne 'EvoSTS-Trust' -and $_.Name -ne 'ACS_STS' -and $_.RegisteredIssuerName -ne $null -and $_.RegisteredIssuerName -notlike '*@`*' -and $_.RegisteredIssuerName -notlike $TempRealm}

 $Guid = [guid]::NewGuid()
 foreach ($Issuer in $Issuers)
 {
 $NameCopy = $Issuer.Name
 $NewIssuerName = $Guid
 $IssuerCertificate = $Issuer.SigningCertificate
 $OldRegisteredIssuerID = $Issuer.RegisteredIssuerName
 $IssuerID = $OldRegisteredIssuerID.Split('@')[0]
 $NewRegisteredIssuerName = $IssuerID + '@' + $NewRealm
 $NewIssuer = New-SPTrustedSecurityTokenIssuer -Name $NewIssuerName -Certificate $IssuerCertificate -RegisteredIssuerName $NewRegisteredIssuerName -IsTrustBroker
 Remove-SPTrustedSecurityTokenIssuer $Issuer -Confirm:$false
 $NewIssuer.Name = $NameCopy
 $NewIssuer.Update()
 }
 }

Corrija cada suplemento hospedado pelo provedor encontrado na etapa 1 executando o seguinte script:

No script, substitua {0}e {1} os {2} valores obtidos na etapa 1.

 $appTitle = '{0}'
 $clientID = '{1}'
 $targetWeb = Get-SPWeb '{2}'
 $Scope = 'Site'
 $Right = 'Full Control'
 $authRealm = Get-SPAuthenticationRealm -ServiceContext $targetWeb.Site
 $AppIdentifier = $clientID + '@' + $authRealm
 Register-SPAppPrincipal -NameIdentifier $AppIdentifier -Site $targetWeb -DisplayName $appTitle
 $appPrincipal = Get-SPAppPrincipal -Site $targetWeb -NameIdentifier $AppIdentifier
 Set-SPAppPrincipalPermission -Site $targetWeb -AppPrincipal $appPrincipal -Scope $Scope -Right $Right

Para atualizar o realm de autenticação Gerenciador de Fluxos de Trabalho, execute o seguinte cmdlet:

 $workflowproxy = Get-SPWorkflowServiceApplicationProxy
 $webapp = get-spwebapplication
 if ($webapp)
 {
 $webappurl = $webapp[0].url
 $Site=get-spsite $webappurl
 if ($site)
 {
 $workflowaddress = $workflowproxy.GetWorkflowServiceAddress($site)
 $workflowscopename = $workflowproxy.GetWorkflowScopeName($site)
 $TrimScope = '/'+$workflowscopename+'/'
 $wfmaddress = $workflowaddress.TrimEnd($Trimscope)
 }
 }
 $workflowproxy.delete()
 Register-SPWorkflowService -SPSite $Site -WorkflowHostUri $wfmaddress -Force

Se você implantou cenários de confiança entre farms antes de configurar recursos híbridos, use os métodos nos seguintes tópicos do TechNet para corrigir os cenários manualmente:

Compartilhar aplicativos de serviço entre farms no SharePoint Server

Informações adicionais

No cenário em que você configura cargas de trabalho híbridas que exigem S2S antes de implementar os suplementos hospedados pelo provedor ou o Gerenciador de Fluxos de Trabalho, os suplementos SPAuthenticationRealm serão registrados depois que o cmdlet for atualizado para corresponder à ID de contexto de locatário do Microsoft 365. Eles sempre funcionarão porque o valor realmID não será alterado novamente. Se as cargas de trabalho híbridas forem adicionadas ou reconfiguradas, a ID do realm permanecerá igual à ID de contexto do locatário do Microsoft 365.

Para criar uma relação de confiança de servidor para servidor entre seu ambiente local do SharePoint e o Microsoft 365, execute o Set-SPAuthenticationRealm.

Importante

O tópico contém uma seção "Cuidado" que avisa que todos os tokens de acesso criados para um realm específico não funcionarão depois que você alterar o SPAuthenticationRealm valor.

Para criar suplementos hospedados pelo provedor do SharePoint, consulte Introdução à criação de Suplementos do SharePoint hospedados pelo provedor.

Ainda precisa de ajuda? Acesse a Comunidade do SharePoint.

Os suplementos hospedados pelo provedor param de funcionar e o erro HTTP 401 depois de configurar os recursos híbridos do farm do SharePoint

Sintomas

Motivo

Solução

Informações adicionais

Comentários