Les add-ins hébergés par un fournisseur cessent de fonctionner et une erreur HTTP 401 après avoir configuré SharePoint fonctionnalités hybrides de batterie de serveurs
Symptômes
Prenons le cas de figure suivant. Vous avez des add-ins hébergés par un fournisseur existants et déployés qui sont enregistrés en tant que batterie de serveurs et qui contiennent la valeur de batterie de serveurs d’origine pour votre batterie de serveurs RegisteredIssuerName SharePoint 2013 ou SharePoint 2016, et/ou vous avez créé une association Gestionnaire de flux de travail dans votre batterie RealmID de serveurs.
Dans ce scénario, lorsque vous accédez à ces phas après avoir configuré SharePoint fonctionnalités hybrides dans votre batterie de serveurs, les phas ne fonctionnent plus. En outre, vous recevez un message d’erreur HTTP 401 lorsque vous êtes dirigé vers les compléments.
Notes
Les phas peuvent inclure une application web hébergée en externe, un service, une base de données ou un SharePoint externe. Ce problème n’existe pas si vous configurez d’abord des fonctionnalités hybrides, puis déployez des Gestionnaire de flux de travail et/ou des add-ins hébergés par un fournisseur dans une batterie de serveurs SharePoint 2013 ou SharePoint 2016.
Cause
La configuration SharePoint des fonctionnalités hybrides pour SharePoint 2013 ou SharePoint 2016 interrompt les confiances de serveur à serveur (S2S) créées avant la configuration des fonctionnalités hybrides. Lorsque vous tentez d’établir une confiance S2S à l’aide du script d’embarquement de la SSA cloud ou du s picker hybride, le domaine d’authentification de la batterie de serveurs sur site est mis à jour pour correspondre à l’ID de contexte du client Office 365. Le script définit le domaine d’authentification à l’aide de l’cmdlet Set-SPAuthenticationRealm. Une fois le domaine d’authentification modifié, les compléments SharePoint existants ne sont pas authentifiés.
Cet échec d’authentification se produit en raison de la façon dont les applications hébergées par un fournisseur sont autorisées à accéder SharePoint. SharePoint sont associés à SPTrustedSecurityTokenIssuers l’aide de la IssuerId valeur. Sur demande, un add-in tente d’obtenir un jeton auprès de l’émetteur du service d’émission de jeton sécurisé (STS). Les émetteurs de jeton sont liés au domaine d’authentification. Une fois le domaine modifié, les SharePoint ne peuvent plus s’authentifier correctement. L’émetteur de jeton approuvé qui possède l’ID d’émetteur correct existe toujours dans la batterie de serveurs. Toutefois, il est associé au domaine d’authentification précédent. La valeur RegisteredIssuerName réelle est , dans laquelle la valeur ne correspond plus à la valeur IssuerId@OldAuthRealmGuid oldAuthRealmGuid AuthRealmGuid actuelle. Le add-in ne parvient pas à s’authentifier car le STS ne trouve pas d’émetteur de jeton correspondant.
Le message d’erreur suivant est consigné dans les journaux ULS et indique clairement que l’émetteur de jeton n’est plus approuvé, car sa valeur ne correspond plus à la batterie RealmID de serveurs :
SPApplicationAuthenticationModule : échec de l’authentification de la demande, erreur inconnue. Détails de l’exception : System.IdenitytModel.Tokens.SecurityTokenException : les problèmes du jeton ne sont pas un émetteur approuvé.
Résolution
Lorsque vous configurez un abonnement hybride, il est modifié pour correspondre à l’ID de client RealmID de votre abonnement Office365. Cela entraîne l’arrêt du fonctionnement des add-ins, comme expliqué dans la section « Symptômes ». Pour restaurer SharePoint la fonctionnalité du nouveau domaine, inscrivez les modules hébergés par un fournisseur à l’aide de la valeur qui contient le RegisteredIssuerName nouvel ID de domaine. Ensuite, réappliquez les autorisations de chaque instance de add-in.
Pour réparer les problèmes liés à l’authentification associés aux applications hébergées par un fournisseur et aux fonctionnalités hybrides, suivez les étapes suivantes :
Exécutez le script suivant pour découvrir toutes les instances d’application déployées sur une application web :
Dans le script suivant, {0} remplacez-le par votre application web. Les sorties du script sont le titre de l’application, l’ID client de l’application et le site web cible de tous les applications hébergées par un fournisseur. Ces valeurs seront utilisées comme entrées à l’étape 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 } } } }Mettez à jour SPTrustedSecurityTokenIssuers à l’aide du script suivant :
$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() } }Corrigez chaque add-in hébergé par un fournisseur trouvé à l’étape 1 en exécutant le script suivant :
Dans le script, {0} remplacez et {1} par les {2} valeurs obtenues à l’étape 1.
$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 $RightPour mettre à jour le domaine d’authentification Gestionnaire de flux de travail, exécutez l’cmdlet suivante :
$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 -ForceSi vous avez déployé des scénarios d’confiance entre batteries de serveurs avant de configurer des fonctionnalités hybrides, utilisez les méthodes des rubriques TechNet suivantes pour résoudre les scénarios manuellement :
Informations supplémentaires
Dans le scénario où vous configurez des charges de travail hybrides qui nécessitent S2S avant d’implémenter les Gestionnaire de flux de travail ou les add-ins hébergés par un fournisseur, les modules sont enregistrés une fois que la cmdlet est mise à jour pour correspondre à l’ID de contexte du client SPAuthenticationRealm Office 365. Ils fonctionnent toujours, car la valeur RealmID ne change pas à nouveau. Si des charges de travail hybrides sont ajoutées ou reconfigurées, l’ID de domaine reste le même que l’ID de contexte Office 365 client.
Pour créer une relation d’confiance de serveur à serveur entre SharePoint environnement local et Office 365, exécutez Set-SPAuthenticationRealm.
Important
Cette rubrique contient une section « Attention » qui vous avertit que les jetons d’accès créés pour un domaine spécifique ne fonctionneront pas après la modification de la SPAuthenticationRealm valeur.
Pour créer des SharePoint hébergés par un fournisseur, voir Commencer à créer des SharePoint hébergés par un fournisseur.
Encore besoin d’aide ? Accédez au site de la Communauté SharePoint.