Door provider gehoste invoegtoepassingen werken niet meer en HTTP 401-fout nadat u hybride functies van SharePoint-farm hebt geconfigureerd

  • Artikel
  • Van toepassing op:
    SharePoint Server Subscription Edition, SharePoint Server 2019, SharePoint Server 2016, SharePoint Server 2013

Symptomen

Neem het volgende scenario: U hebt bestaande, door de provider gehoste invoegtoepassingen (PHA) die zijn geregistreerd als RegisteredIssuerName en die de oorspronkelijke farmwaarde RealmID voor uw SharePoint 2013- of SharePoint 2016-farm bevatten, en/of u hebt een Werkstroombeheer-koppeling gemaakt in uw farm.

Wanneer u in dit scenario deze PHA's opent nadat u hybride SharePoint-functies in uw farm hebt geconfigureerd, werken de PHA's niet meer. Bovendien ontvangt u een HTTP 401-foutbericht wanneer u wordt omgeleid naar de invoegtoepassingen.

Opmerking

PHA's kunnen een extern gehoste webtoepassing, service, database of SharePoint-onderdeel bevatten. Dit probleem doet zich niet voor als u eerst hybride functies configureert en vervolgens door de provider gehoste invoegtoepassingen en/of Werkstroombeheer implementeert in een SharePoint 2013- of SharePoint 2016-farm.

Oorzaak

Het configureren van hybride SharePoint-functies voor SharePoint 2013 of SharePoint 2016 verstoort S2S-vertrouwensrelaties (server-to-server) die worden gemaakt voordat u hybride functies configureert. Wanneer u probeert een S2S-vertrouwensrelatie tot stand te brengen met behulp van het cloud-SSA-onboardingscript of de hybride kiezer, wordt het verificatiedomein van de on-premises farm bijgewerkt zodat deze overeenkomt met de context-id van de Microsoft 365-tenant. Het script stelt het verificatiedomein in met behulp van de cmdlet Set-SPAuthenticationRealm . Nadat het verificatiedomein is gewijzigd, kunnen bestaande SharePoint-invoegtoepassingen niet worden geverifieerd.

Deze verificatiefout treedt op vanwege de wijze waarop door de provider gehoste invoegtoepassingen toegang hebben tot SharePoint. SharePoint-invoegtoepassingen worden gekoppeld aan SPTrustedSecurityTokenIssuers door de IssuerId waarde te gebruiken. Op verzoek probeert een invoegtoepassing een token op te halen van de Secure Token Service-uitgever (STS). De tokenverleners zijn gekoppeld aan het verificatiedomein. Nadat de realm is gewijzigd, kunnen de SharePoint-invoegtoepassingen niet meer worden geverifieerd. De vertrouwde tokenverlener met de juiste verlener-id bestaat nog steeds in de farm. Deze is echter gekoppeld aan het vorige verificatiedomein. De werkelijke RegisteredIssuerName waarde is IssuerId@OldAuthRealmGuid, waarbij de oldAuthRealmGuid waarde niet meer overeenkomt met de huidige AuthRealmGuid waarde. De invoegtoepassing kan niet worden geverifieerd omdat de STS geen overeenkomende tokenverlener kan vinden.

Het volgende foutbericht wordt vastgelegd in ULS-logboeken en geeft duidelijk aan dat de tokenverlener niet meer wordt vertrouwd omdat de RealmID waarde niet meer overeenkomt met de farm:

SPApplicationAuthenticationModule: kan aanvraag niet verifiëren, onbekende fout. Uitzonderingsdetails: System.IdenitytModel.Tokens.SecurityTokenException: De problemen van het token zijn geen vertrouwde verlener.

Oplossing

Wanneer u hybride configureert, RealmID wordt deze gewijzigd in overeenstemming met de tenant-id van uw Office365-abonnement. Dit zorgt ervoor dat invoegtoepassingen niet meer werken, zoals uitgelegd in de sectie Symptomen. Als u de functionaliteit van de SharePoint-invoegtoepassing wilt herstellen, registreert u de door de provider gehoste invoegtoepassingen met behulp van de RegisteredIssuerName waarde die de nieuwe realm-id bevat. Pas vervolgens de invoegtoepassingsmachtigingen voor elk invoegtoepassingsexemplaren opnieuw toe.

Voer de volgende stappen uit om verificatiegerelateerde problemen te herstellen die zijn gekoppeld aan door provider gehoste invoegtoepassingen en hybride functies:

  1. Voer het volgende script uit om alle app-exemplaren te detecteren die zijn geïmplementeerd in een webtoepassing:

    Vervang in het volgende script door {0} uw webtoepassing. De uitvoer van het script is de titel van de app, de client-id van de app en het doelweb van alle door de provider gehoste invoegtoepassingen. Deze waarden worden gebruikt als invoer in stap 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
 }
 }
 }
 }

  2. Werk SPTrustedSecurityTokenIssuers bij met behulp van het volgende 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. Los elke door de provider gehoste invoegtoepassing op die in stap 1 is gevonden door het volgende script uit te voeren:

    Vervang in het script , {1} en {2} door {0}de waarden die u in stap 1 hebt verkregen.

     $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

    Voer de volgende cmdlet uit om het verificatiedomein voor Werkstroombeheer bij te werken:

     $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

    Als u vertrouwensscenario's voor meerdere farms hebt geïmplementeerd voordat u hybride functies hebt geconfigureerd, gebruikt u de methoden in de volgende TechNet-onderwerpen om de scenario's handmatig op te lossen:

Meer informatie

In het scenario waarin u hybride workloads configureert waarvoor S2S is vereist voordat u de door de provider gehoste invoegtoepassingen of Werkstroombeheer implementeert, worden de invoegtoepassingen geregistreerd nadat de SPAuthenticationRealm cmdlet is bijgewerkt zodat deze overeenkomt met de context-id van de Microsoft 365-tenant. Ze werken altijd omdat de RealmID-waarde niet opnieuw wordt gewijzigd. Als hybride workloads worden toegevoegd of opnieuw worden geconfigureerd, blijft de realm-id hetzelfde als de context-id van de Microsoft 365-tenant.

Als u een server-naar-serververtrouwensrelatie wilt maken tussen uw on-premises SharePoint-omgeving en Microsoft 365, voert u set-SPAuthenticationRealm uit.

Belangrijk

Het onderwerp bevat een sectie 'Waarschuwing' waarin wordt gewaarschuwd dat toegangstokens die zijn gemaakt voor een specifieke realm niet werken nadat u de SPAuthenticationRealm waarde hebt gewijzigd.

Zie Aan de slag met het maken van door de provider gehoste SharePoint-invoegtoepassingen voor informatie over het maken van door de provider gehoste invoegtoepassingen.

Meer hulp nodig? Ga naar SharePoint-community.