Symptômes
Prenons l’exemple du scénario suivant :
-
Vous utilisez l’authentification Windows-Claims (via stimulation/réponse Windows) dans une application Web Microsoft SharePoint Server 2013.
-
Vous décidez de basculer vers les revendications de fournisseur approuvé à l’aide d’un fournisseur basé sur le protocole SAML (Secure Application Markup Language), tel que les services ADFS (Active Directory Federation Services).
-
Vous pouvez passer en revue les étapes décrites dans la rubrique migration de l’authentification Windows Claims vers authentification de revendications SAML dans SharePoint Server 2013 sur le site Web de Microsoft Developer Network (MSDN).
-
Exécutez la commande suivante :
Conversion-SPWebApplication-ID $wa-à CLAIMs-approuvé-par défaut-à partir de plaintes-WINDOWS-TrustedProvider $tp-SourceSkipList $csv-RetainPermissions
Dans ce scénario, le message d'erreur suivant s'affiche :
L’authentification de revendication basée sur SAML n’est pas compatible.
Cause
Ce problème se produit car l’émetteur du jeton d’identité approuvé n’a pas été créé à l’aide de la configuration par défaut. La configuration par défaut doit être utilisée pour que la commande Convert-SPWebApplication fonctionne correctement. Pour que le fournisseur de confiance puisse être compatible avec la conversion à partir d’une revendication Windows vers le SAML ou inversement, la commande Convert-SPWebApplication nécessite une configuration spécifique du fournisseur de confiance. Plus précisément, l’émetteur du jeton d’identité approuvé doit être créé à l’aide des paramètres UseDefaultConfiguration et IdentifierClaimIs . Vous pouvez vérifier si votre émetteur de jeton d’identité approuvé a été créé à l’aide du paramètre UseDefaultConfiguration en exécutant les scripts Windows PowerShell suivants.Remarque : Ces scripts partent du principe que vous n’avez qu’un seul fournisseur d’identité approuvé créé dans la batterie actuelle.
$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes
Les types de revendication que ce script doit générer sont les suivants :
-
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
-
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid
-
http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
-
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
-
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
#Get the Identity claim:$tp = Get-SPTrustedIdentityTokenIssuer$tp.IdentityClaimTypeInformation
La revendication d’identité doit être l’un des éléments suivants :
-
WindowAccountName
-
EmailAddress
-
UPN
Exemple de sortie pour $tp. IdentityClaimTypeInformation : DisplayName : email InputClaimType : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/EmailAddressMappedClaimType : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/EmailAddress#IsIdentityClaim : true il devrait exister un fournisseur de revendications personnalisé portant le même nom que l’émetteur du jeton, et il doit être de type SPTrustedBackedByActiveDirectoryClaimProvider. Pour savoir si le fournisseur de revendications est présent et compatible, procédez comme suit :
$tp = Get-SPTrustedIdentityTokenIssuer$name = $tp.name$cp = Get-SPClaimProvider $nameif($cp.typename -match "SPTrustedBackedByActiveDirectoryClaimProvider"){write-host "Claim provider is present and has TypeName of " $cp.typename " it should be valid"}else{write-host "Claim provider is not present. Trusted Identity Token Issuer" $tp.name " is not compatible with convert-spwebapplication"}Résolution
Pour résoudre ce problème, supprimez puis recréez l’émetteur de jeton d’identité approuvés. Pour cela, procédez comme suit :
-
Exécutez le script suivant :
$tp = Get-SPTrustedIdentityTokenIssuer$tp | fl$tp.name$tp.IdentityClaimTypeInformation
Effectuez une copie de la sortie de ce script pour référence ultérieure. En particulier, nous avons besoin de la valeur de la propriété Name afin que le nouvel émetteur de jeton puisse être créé à l’aide du même nom et nous avons besoin de la revendication d’identité afin que le nouveau fournisseur de revendications puisse être créé à l’aide de la même revendication d’identité. Tant que le même nom est utilisé pour l’émetteur du jeton et que la même revendication est utilisée comme revendication d’identité, tous les utilisateurs conservent leurs autorisations au sein de l’application Web après la création de l’émetteur de jeton.
-
Supprimez le fournisseur d’identité approuvé actuel des fournisseurs d’authentification pour toute application Web actuellement utilisée.
-
Supprimez l’émetteur du jeton en exécutant la commande suivante :
Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"
-
Recréez l’émetteur du jeton. Pour cela, suivez les étapes décrites dans la rubrique implémenter l’authentification basée sur SAML dans SharePoint Server 2013 sur le site Web Microsoft TechNet pour plus d’informations.Important Lorsque vous exécutez la commande New-SPTrustedIdentityTokenIssuer , vous devez utiliser les paramètres UseDefaultConfiguration et IdentifierClaimIs . Le paramètre UseDefaultConfiguration n’est qu’un commutateur. Les valeurs possibles du paramètre IdentifierClaimIs sont les suivantes :
-
NOM DU COMPTE
-
Messagerie
-
NOM D’UTILISATEUR PRINCIPAL
Exemple de script :
$ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
-
-
Dans administration centrale, ajoutez votre nouveau jeton d’identité approuvé aux fournisseurs d’authentification pour l’application Web que vous tentez de convertir. L’application Web doit disposer de l’authentification Windows et du fournisseur d’identité approuvé cible sélectionné.
Informations supplémentaires
Conseils supplémentaires pour une conversion réussie : si la valeur de l’adresse de messagerie est utilisée pour la revendication d’identificateur (c’est-à-dire pour le paramètre IdentifierClaimIs ), seuls les utilisateurs dont les adresses de messagerie sont renseignées dans Active Directory seront converties. Les comptes d’utilisateurs répertoriés dans le fichier. csv qui sont définis dans le paramètre SourceSkipList ne seront pas convertis en SAML. Dans le cas d’une conversion de Windows Claims vers SAML, les noms de comptes d’utilisateur peuvent être répertoriés avec ou sans la notation claims. Par exemple, « CONTOSO\User1 » ou « i :0 #. w | CONTOSO\User1 » est un bon choix. Ajoutez au fichier. csv les comptes d’utilisateurs que vous ne souhaitez pas convertir. Il doit s’agir d’un compte de service ou d’un compte d’administrateur.
