L’outil SPMigrateUsers pour modifier les identités de compte dans SharePoint 2010

Article d’origine publié le dimanche 3 juin 2012

Parfois dans SharePoint, vous voulez ou vous devez changer l’identité d’un compte. Le meilleur exemple concerne les revendications SAML. Dans pratiquement tous mes exemples j’utilise une adresse e-mail comme revendication d’identité pour les utilisateurs. Pour deux raisons : a) la plupart des gens ont une adresse e-mail et b) l’adresse e-mail est comprise par la majorité des utilisateurs. Pourtant, je me fais reprendre de temps sur le fait d’utiliser des adresses e-mail parce que les utilisateurs en changent. Quand vous changez votre adresse e-mail, a fortiori toutes les autorisations dont vous disposiez sont annulées. Honnêtement, ça n’arrive pas souvent, sinon je n’utiliserais pas l’adresse e-mail. Mais je vous accorde que ça peut arriver parfois, donc que faut-il faire quand tout votre SharePoint est sécurisé avec votre adresse e-mail ?

La solution est dans un billet de blog que j’ai publié sur l’interface IMigrateUserCallback : https://blogs.msdn.com/b/sharepoint_fr/archive/2011/03/08/migration-des-comptes-d-utilisateur-du-mode-revendications-windows-vers-le-mode-revendications-saml.aspx. Dans ce billet, j’ai décrit comment transférer des identités à l’aide de cette interface en m’appuyant sur un exemple de conversion de l’identité basée sur les revendications Windows en identité basée sur les revendications SAML. J’ai simplement écrit une petite application Windows qui vous laisse entrer les informations d’identification que vous voulez changer et qui fait le changement à votre place. Son but premier est de servir uniquement à faire ces modifications, mais vous pouvez facilement récupérer le code source (inclus dans ce billet) et le modifier pour en faire un outil plus créatif, comme lire une liste d’utilisateurs dans un fichier ou une base de données et faire des comparaisons.

L’autre intérêt de cet outil, c’est qu’il peut être utilisé dans plusieurs scénarios. Vous pouvez donc non seulement l’utiliser pour remplacer une adresse e-mail par une autre, mais vous pouvez aussi l’utiliser pour remplacer un nom de groupe par un autre. Dans ce dernier cas, certaines personnes m’ont dit : tu devrais utiliser les SID pour les noms de groupe (c.-à-d. revendications de rôle dans SAML) parce que si tu renommes le groupe, le SID reste le même. Même si c'est vrai, encore une fois, a) ça n’arrive pas à tout bout de champ, b) combien d’entre vous voudrait commencer à taper des noms SID de groupe et les ajouter aux groupes SharePoint (si la réponse est oui, vous devriez consulter) et c) les SID ne signifient rien en dehors de votre Active Directory local : dès que vous serez passé à un service dans le nuage comme Azure, Google, Yahoo, Facebook, etc. votre SID sera aussi inutile que ... [je vous laisse choisir !].

Un autre avantage de cet outil : il ne se limite pas à vous permettre de faire des modifications dans un seul type de fournisseur. Vous voulez changer un groupe Windows en revendication de rôle SAML ? Vous pouvez le faire. Vous voulez changer une revendication d’identité SAML en utilisateur d’appartenance FBA ? Vous pouvez le faire. Vous voulez changer un rôle FBA en groupe AD ? Vous pouvez le faire. Vous avez compris l’idée, j’ai essayé presque toutes les combinaisons d’« utilisateurs » et de « groupes » entre différents fournisseurs et jusqu’à présent toutes les conversions dans les deux sens ont parfaitement fonctionné.

L’outil lui-même est assez simple à utiliser, en voici une capture :

Au premier démarrage de l’application, une liste de toutes les applications web est chargée. Pour chacune d’entre elles, l’outil renseigne deux zones de liste déroulante avec une liste de tous les fournisseurs utilisés sur cette application web. Si vous avez plusieurs fournisseurs SAML ou FBA, chacun sera répertorié dans la liste déroulante. Choisissez simplement les fournisseurs à partir desquels et vers lesquels vous effectuez la migration. Dans la section Claim Value, entrez la valeur que vous voulez transférer, et celle vers laquelle vous la transférez. Tapez simplement la valeur dans les champs d’édition Plain Text Value et cliquez sur le bouton de revendication d’identité (à gauche) ou le bouton de revendication de groupe (à droite). La description donne une explication complète du fonctionnement et le texte des boutons changent selon l’identité du fournisseur que vous utilisez.

Par exemple, supposons que vous utilisez seulement une authentification SAML et que vous voulez convertir l’adresse e-mail « steve@contoso.com » en « stevep@contoso.com ». Vous choisissez votre application web et le fournisseur d’authentification SAML sera choisi par défaut dans chaque liste déroulante. Ensuite, dans la section Before Values, tapez « steve@contoso.com » dans la zone d’édition Plain Text Value et cliquez sur le bouton ID Claim. La valeur de revendication codée correcte sera alors placée dans la zone d’édition Encoded Value. Puis, tapez « stevep@contoso.com » dans la section After Values, zone d’édition Plain Text Value. Recliquez sur le bouton ID Claim pour mettre la valeur correcte dans la zone d’édition Encoded Value (REMARQUE : dans l’image ci-dessus, le bouton de la section After Values affiche « User » au lieu de « ID Claim », car dans cet exemple les revendications SAML sont remplacées par des revendications Windows). Dès que vous avez toutes vos valeurs, cliquez sur le bouton Migrate pour terminer le processus, un message s’affiche vous indiquant que la migration est terminée.

Quand j’ai testé cet outil sur différentes applications web et différents types d’authentification, j’ai rencontré deux problèmes que je voudrais soulever ici au cas où cela vous arrive aussi. J’ai reçu une fois un message d’accès refusé alors que j’essayais de transférer les utilisateurs d’une application web en particulier. Je n’ai jamais réussi à comprendre d’où venait le problème, j’en ai donc conclu que c’était l’application web qui était bancale, mais je ne sais pas vraiment quoi car tout a bien fonctionné sur les quatre ou cinq autres applications web que j’ai testées dans ma batterie de serveurs web.

Le deuxième problème est apparu alors que la migration semblait avoir réussi, mais impossible de me connecter avec le nom de l’utilisateur transféré. En creusant le problème, j’ai découvert que le compte à partir duquel j’effectuais la migration n’était pas proposé à la fonction IMigrateUserCallback (c.-à-d. que c'est un problème de SharePoint et non un problème de code avec l’application). Si vous rencontrez ce problème, je vous conseille d’utiliser le code source et Visual Studio pour utiliser le débogueur et vous assurer que le compte à partir duquel vous effectuez la migration est bien appelé. Malheureusement, un de mes utilisateurs d'appartenance FBA s'est perdu dans cette jungle.

Enfin, une dernière chose à prendre en compte : ne paniquez pas si vous transférez un compte d’une valeur à une autre, connectez-vous sous le nouvel utilisateur et repérez l’ancien nom du compte, etc. dans les commandes d’accueil qui se trouvent dans l’angle supérieur droit de la page. La fonction de migration change simplement le nom du compte. Si les autres informations de l’utilisateur ont changé aussi, quand vous mettrez à jour les profils utilisateur, les informations correctes seront appliquées à toutes les collections de sites lors de la prochaine synchronisation avec le système de profils.

Voilà, j’espère que ça vous sera utile. Comme je l’ai dit plus haut, le code source complet est inclus donc n’hésitez pas à jouer avec et à le modifier selon les besoins de votre scénario.

Ce billet de blog a été traduit de l’anglais. La version d’origine est disponible à la page The SPMigrateUsers Tool for Changing Account Identities in SharePoint 2010