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

Symptomen

Neem het volgende scenario: U hebt bestaande, geïmplementeerde 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 in uw farm gemaakt.

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

Notitie

PHA's kunnen een extern gehoste webtoepassing, service, database of SharePoint-onderdeel bevatten. Dit probleem bestaat niet 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-naar-server) die zijn 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 de verificatierealm van de on-premises farm bijgewerkt zodat deze overeenkomt met de context-id van de Microsoft 365-tenant. Het script stelt de verificatierealm in met behulp van de cmdlet Set-SPAuthenticationRealm . Nadat de verificatierealm is gewijzigd, kunnen bestaande SharePoint-invoegtoepassingen niet worden geverifieerd.

Deze verificatiefout treedt op vanwege de wijze waarop door de provider gehoste invoegtoepassingen zijn gemachtigd voor toegang tot SharePoint. SharePoint-invoegtoepassingen worden gekoppeld met SPTrustedSecurityTokenIssuers behulp van de IssuerId waarde. Op aanvraag probeert een invoegtoepassing een token op te halen van de Secure Token Service-verlener (STS). De tokenverleners zijn gekoppeld aan de verificatierealm. 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 de vorige verificatierealm. De werkelijke RegisteredIssuerName waarde is IssuerId@OldAuthRealmGuid, waarin 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 zodat deze overeenkomt met de tenant-id van uw Office365-abonnement. Dit zorgt ervoor dat invoegtoepassingen niet meer werken, zoals wordt 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 exemplaar van de invoegtoepassing opnieuw toe.

Voer de volgende stappen uit om problemen met betrekking tot verificatie te herstellen die zijn gekoppeld aan door de 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 {0} in het volgende script door uw webtoepassing. De uitvoer van het script zijn de app-titel, 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. Corrigeer elke door de provider gehoste invoegtoepassing die is gevonden in stap 1 door het volgende script uit te voeren:

    Vervang {0}{1} in het script en {2} door 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 de verificatierealm 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 meer verandert. 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-server-vertrouwensrelatie tussen uw on-premises SharePoint-omgeving en Microsoft 365 wilt maken, 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 om door een SharePoint-provider gehoste invoegtoepassingen te maken.

Meer hulp nodig? Ga naar SharePoint-community.