HTTP 401-fout herstellen met de provider wordt gehost invoegtoepassingen en problemen met de workflow en cross farm trust scenario's in SharePoint

Van toepassing: SharePoint Server 2013SharePoint Server 2016

Symptomen


Neem het volgende scenario. Hebt u bestaande, geïmplementeerd als host van een provider invoegtoepassingen (PHA) die zijn geregistreerd als <RegisteredIssuerName> en bevat de oorspronkelijke farm RealmID waarde voor uw SharePoint 2013 of SharePoint 2016 farm, en/of u de koppeling van een Workflow Manager gemaakt in uw farm.

In dit scenario, wanneer u deze PHAs na het configureren van SharePoint-functies voor hybride in uw farm, de PHAs niet meer werkt. Wordt bovendien een foutbericht HTTP 401 wanneer u worden doorgestuurd naar de invoegtoepassingen.

Oorzaak


Configureren van SharePoint-functies voor hybride voor SharePoint 2013 of SharePoint 2016 verstoord server naar server (S2S) vertrouwensrelaties die zijn gemaakt voordat u hybride functies configureren. Wanneer u een S2S-vertrouwensrelatie tot stand brengen probeert met behulp van het script BVS wolk op de aanhouding of de datumkiezer hybride, wordt verificatie-realm van de farm in ruimten bijgewerkt naar de Office 365 huurder context-ID. Het script stelt de verificatie-realm met behulp van de cmdlet Set -SPAuthenticationRealm . Nadat de verificatie-realm is gewijzigd, worden bestaande SharePoint-invoegtoepassingen kunnen niet worden geverifieerd.

Deze verificatiefout treedt op omdat de provider gehost hoe invoegtoepassingen zijn die toegang hebben tot SharePoint. SharePoint-invoegtoepassingen zijn gekoppeld aan de SPTrustedSecurityTokenIssuers door de waarde IssuerId . Op verzoek probeert een invoegtoepassing een token ophalen van de emittent Secure Token Service (STS). De token emittenten zijn gekoppeld aan de verificatie-realm. Nadat de realm is gewijzigd, de SharePoint-invoegtoepassingen niet meer kunnen verifiëren met succes. De vertrouwde tokenuitgever met de juiste uitgever-ID bestaat nog steeds in de farm. Het is echter gekoppeld aan het vorige verificatie-realm. De werkelijke waarde van <RegisteredIssuerName> is IssuerId@OldAuthRealmGuid, waarin de waarde oldAuthRealmGuid niet meer gelijk is aan de huidige waarde van AuthRealmGuid . De invoegtoepassing niet worden geverifieerd omdat de STS een overeenkomende token uitgever niet kunnen vinden.

Het volgende foutbericht wordt vastgelegd in Logboeken ULS en duidelijk aangeeft dat de tokenuitgever niet langer vertrouwd omdat de waarde RealmID niet meer overeen met de farm:
SPApplicationAuthenticationModule: Onbekende fout verzoek verificatie mislukt. Details van uitzondering: System.IdenitytModel.Tokens.SecurityTokenException: de problemen van het token is niet afkomstig van een vertrouwde uitgever.

Oplossing


Bij het configureren van hybride RealmID gewijzigd zodat deze overeenkomt met de ID van de huurder van uw abonnement op Office365. Hierdoor worden invoegtoepassingen niet meer reageert, zoals wordt beschreven in de sectie 'Symptomen'. SharePoint-in om functionaliteit te herstellen, opnieuw de provider wordt gehost-invoegtoepassingen registreren met behulp van de <RegisteredIssuerName>-waarde die de nieuwe realm-id bevat. Vervolgens passen de machtigingen toevoegen in voor elke instantie toevoegen in.

Ga als volgt te werk om te herstellen van problemen met verificatie die gekoppeld aan de provider wordt gehost invoegtoepassingen en hybride functies zijn:

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

    In het volgende script in uw webtoepassing vervangen {0}. De uitvoer van het script zijn app titel, de client-ID app en doel Web van alle gehoste provider-invoegtoepassingen. Deze waarden worden gebruikt als input in stap 3.
    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. SPTrustedSecurityTokenIssuers bijwerken 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. FIX elke provider gehost-invoegtoepassing die is gevonden in stap 1 door het volgende script uit te voeren:

    In het script vervangen door {0}, {1} en {2} de waarden die u in stap 1 hebt opgehaald.
    $appTitle = '{0}'
    $clientID = '{1}'
    $targetWeb = Get-SPWeb '{2}'
    $Scope = 'Site'
    $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
Het verificatiebereik voor Workflowbeheer, werkt de volgende 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
Gebruik de methoden in de volgende TechNet-onderwerpen als u cross-farm trust scenario's geïmplementeerd voordat u geconfigureerd hybride functies, handmatig corrigeren van de scenario's:

Meer informatie


 In het scenario waar het configureren van hybride werklast die S2S voordat u vereisen de invoegtoepassingen provider wordt gehost of Workflowbeheer implementeren, invoegtoepassingen wordt geregistreerd nadat de cmdlet SPAuthenticationRealm is bijgewerkt zodat deze overeenkomen met de Office 365 huurder context-ID. Ze werkt altijd omdat de waarde RealmID niet opnieuw worden gewijzigd. Als hybride werklasten worden toegevoegd of aangepast, blijft de realm-ID hetzelfde als de id van de Office 365 huurder context.

Een server naar server om vertrouwensrelatie te maken tussen uw SharePoint op ruimten omgeving en Office 365, voert u de cmdlet Set-SPAuthenticationRealm.

Zie SharePoint-provider wordt gehost invoegtoepassingen maken aan de slag maken van SharePoint-invoegtoepassingen provider wordt gehost.