Invoegtoepassing van de provider werkt niet meer en http 401-fout nadat u hybridefuncties van SharePoint-farm hebt geconfigureerd

Symptomen

Denk aan het volgende scenario. U hebt bestaande, geïmplementeerde providergehoste invoegtoepassing (PHA) die zijn geregistreerd als <RegisteredIssuerName> en die de oorspronkelijke RealmID-waarde voor uw SharePoint 2013- of SharePoint 2016-farm bevatten en/of u een koppeling naar Werkstroombeheerbeheer in uw farm hebt gemaakt.

In dit scenario werken de PHA's niet meer wanneer u deze PHA's hebt geopend nadat u hybridefuncties van SharePoint in uw farm hebt geconfigureerd. Bovendien ontvangt u een HTTP 401-foutbericht wanneer u naar de invoegingen wordt geleid.

Notitie

PHA's kunnen een extern gehoste webtoepassing, service, database of SharePoint-component bevatten.
Dit probleem bestaat niet als u hybride functies eerst configureert en vervolgens door de provider gehoste invoeg- en/of werkstroombeheer implementeert in een SharePoint 2013- of SharePoint 2016-farm.

Oorzaak

Door hybride functies voor SharePoint 2013 of SharePoint 2016 te configureren, worden vertrouwensrelaties (Server-to-Server) verstoord die zijn gemaakt voordat u hybride functies configureert. Wanneer u een S2S-vertrouwensrelatie probeert op te stellen met behulp van het cloud ssa-on-boardingscript of de hybride kiezer, wordt de verificatierealm van de on-premises farm bijgewerkt om te voldoen aan de context-id van de Office 365-tenant. Het script stelt de verificatierealm in met behulp van de cmdletSet- SPAuthenticationRealm. Nadat de verificatierealm is gewijzigd, kunnen bestaande SharePoint-invoegitems niet meer worden geverifieerd.

Deze verificatiefout treedt op vanwege de manier waarop door de provider gehoste invoegingen zijn geautoriseerd om toegang te krijgen tot SharePoint. SharePoint-invoegingen zijn gekoppeld aan SPTrustedSecurityTokenIssuers met behulp van de waarde IssuerId. Op verzoek probeert een add-in een token te krijgen van de Secure Token Service issuer (STS). De token-uitgevers zijn gekoppeld aan de verificatierealm. Nadat de realm is gewijzigd, kunnen de SharePoint-invoegitems niet langer verifiëren. De vertrouwde tokenuitgever met de juiste emittent-id bestaat nog steeds in de farm. Het is echter gekoppeld aan de vorige verificatierealm. De <werkelijke RegisteredIssuerName IssuerId@OldAuthRealmGuid> waarde is , waarin de oldAuthRealmGuid waarde niet langer overeenkomt met de huidige AuthRealmGuid waarde. De invoegtoepassing kan niet worden geverifieerd omdat de STS geen overeenkomende token-uitgever kan vinden.

Het volgende foutbericht wordt geregistreerd bij ULS-logboeken en geeft duidelijk aan dat de tokenuitgever niet langer wordt vertrouwd omdat de RealmID-waarde niet meer overeenkomt met de farm: SPApplicationAuthentication: Kan geen aanvraag verifiëren, onbekende fout. Uitzonderingsdetails: System.IdenitytModel.Tokens.SecurityTokenException: De uitgiften van het token zijn geen vertrouwde uitgever.

Oplossing

Wanneer u hybride configureert, wordt RealmID gewijzigd om overeen te komen met de tenant-id van uw Office365-abonnement. Dit zorgt ervoor dat invoegingen niet meer werken, zoals uitgelegd in de sectie "Symptomen". Als u de functionaliteit voor SharePoint-invoegtoepassing wilt herstellen, <registreert u de door de provider gehoste invoegingen met behulp van de waarde RegisteredIssuerName> die de nieuwe realm-id bevat. Pas vervolgens de invoegmachtigingen opnieuw toe voor elke invoeginstantie.

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

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

    Vervang in {0} het volgende script door uw webtoepassing. De uitvoer van het script zijn de app-titel, app-client-id en doelweb van alle door de provider gehoste invoegtoepassingen. Deze waarden worden gebruikt als ingangen in stap 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. Update SPTrustedSecurityTokenIssuers 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. Repareer elke door provider gehoste invoegtoepassing die in stap 1 is gevonden door het volgende script uit te voeren:

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

    $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
    

    Voer de volgende cmdlet uit als u de verificatierealm voor Workflowbeheer wilt bijwerken:

    $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
    

    Als u vertrouwensscenario's voor crossfarmhebt 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 nodig is voordat u de door de provider gehoste invoegtoepassing of workflowbeheer implementeert, worden de invoegingen geregistreerd nadat de SPAuthenticationRealm-cmdlet is bijgewerkt zodat deze overeenkomt met de office 365-tenantcontext-id. Ze werken altijd omdat de RealmID-waarde niet meer zal veranderen. Als hybride workloads worden toegevoegd of opnieuw worden geconfigureerd, blijft de realm-id hetzelfde als de context-id van de Office 365-tenant. Als u een server-to-server-vertrouwensrelatie wilt maken tussen uw on-premises SharePoint-omgeving en Office 365, voert u de cmdlet Set-SPAuthenticationRealmuit.

Belangrijk

Het onderwerp bevat een sectie 'Voorzichtigheid' 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 sharepoint-invoegins voor een door de leverancier gehoste SharePoint-invoegtoepassing.

Nog steeds hulp nodig? Ga naar SharePoint-community.