Suplementos hospedados pelo provedor param de funcionar e erro HTTP 401 após a configuração dos recursos híbridos do farm do SharePoint

Sintomas

Considere o seguinte cenário. Você tem suplementos hospedados por provedor (PHA) existentes, que são registrados como <nomedoemissorregistrado> e que contêm o valor de Realm de farm original para seu farm do SharePoint 2013 ou do SharePoint 2016 e/ou você criou uma associação de Gerenciador de fluxo de trabalho no farm.

Neste cenário, quando você acessar esses PHAs depois de configurar os recursos híbridos do SharePoint no farm, o PHAs parará de funcionar. Além disso, uma mensagem de erro HTTP 401 é exibida quando você é direcionado para os suplementos.

Observação

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

Causa

Configurando os recursos híbridos do SharePoint para o SharePoint 2013 ou o SharePoint 2016 interrompe as relações de confiança de servidor para servidor (S2S) criadas antes da configuração dos recursos híbridos. Quando você tenta estabelecer uma confiança S2S usando o script SSA de placa de nuvem ou o seletor híbrido, o realm de autenticação do farm local é atualizado para corresponder à ID de contexto do locatário do Office 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 falham ao autenticar.

Essa falha de autenticação ocorre por causa de como suplementos hospedados pelo provedor estão autorizados a acessar o SharePoint. Os suplementos do SharePoint são associados ao SPTrustedSecurityTokenIssuers usando o valor IssuerId . Na solicitação, um suplemento tenta obter um token do emissor do serviço de token seguro (STS). Os emissores de token estão ligados ao realm de autenticação. Após a alteração do Realm, os suplementos do SharePoint não poderão mais ser autenticados com êxito. O emissor de token confiável que tem a ID de emissor correto ainda existe no farm. No entanto, ela é associada ao realm de autenticação anterior. O valor <de> nomedoemissorregistrado real IssuerId@OldAuthRealmGuidé, no qual o valor de oldAuthRealmGuid não corresponde mais ao valor de AuthRealmGuid atual. O suplemento falha ao autenticar porque o STS não consegue encontrar um emissor de token correspondente.

A seguinte mensagem de erro é registrada nos logs ULS e claramente indica que o emissor do token não é mais confiável porque seu valor de território não corresponde mais ao farm: SPApplicationAuthenticationModule: falha ao autenticar solicitação, erro desconhecido. Detalhes da exceção: System. IdenitytModel. Tokens. SecurityTokenexception: os problemas do token não são um emissor confiável.

Resolução

Quando você configura o híbrido, o territórioid é alterado para corresponder à ID do locatário de 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 pelo provedor usando o valor <de> nomedoemissorregistrado 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:

  1. Execute o seguinte script para descobrir todas as instâncias do 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
    $webApp = Get-SPWebApplication -identity "webapplication"
    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
    }
    }
    }
    }
    
  2. Atualize o 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()
    }
    }
    
  3. Correção de cada suplemento hospedado pelo provedor encontrado na etapa 1 executando o seguinte script:

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

    $appTitle = '{0}'
    $clientID = '{1}'
    $targetWeb = Get-SPWeb '{2}'
    $Scope = 'Taxonomy'
    $Right = 'FullControl'
    $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 para o Gerenciador de fluxos de trabalho, execute o seguinte cmdlet:

    $workflowproxy = Get-SPWorkflowServiceApplicationProxy
    $webapp = get-spwebapplication -identity "webapplication"
    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:

Mais informações

No cenário em que você configura cargas de trabalho híbridas que requerem S2S antes de implementar os suplementos hospedados pelo provedor ou o Gerenciador de fluxos de trabalho, os suplementos serão registrados depois que o cmdlet SPAuthenticationRealm for atualizado para corresponder à ID de contexto do locatário do Office 365. Eles sempre funcionarão porque o valor de Realms não mudará 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 Office 365. Para criar uma relação de confiança de servidor para servidor entre seu ambiente local do SharePoint e o Office 365, execute o cmdlet Set-SPAuthenticationRealm.

Importante

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

Para criar suplementos hospedados pelo provedor do SharePoint, confira introdução à criação de suplementos do SharePoint hospedados pelo provedor.

Ainda precisa de ajuda? Vá para a comunidade do SharePoint.