SharePoint - groupes AD perdus dans les utilisateurs Shp après migration

Question

Bonjour,

J'ai migré un SharePoint Foundation 2010 vers un Foundation 2013.

La collection s'est bien récupérée et mise à niveau, sauf les utilisateurs SharePoint qui sont des groupes AD. Ces utilisateurs Shp sont là, avec leurs autorisations, mais Shp ne sait plus faire le lien avec l'objet AD d'origine, donc plus personne ne peut se connecter.

Si j'ajoute un groupe AD qui existe déjà, il crée un nouvel utilisateur SharePoint ; ça prouve bien qu'il ne fait plus le lien entre objet shp et objet AD. Encore un problème de cohabitation entre de magnifiques outils ?

Le contrôleur AD est en version 2003, mais d'après la doc c'est supporté.
A tout hasard, j'ai tenté un stsadmin -migrateuser mais ça échoue parce que ça ne correspond pas à l'environnement actuel.

Quelqu'un aurait-il une piste ? Merci

Answer 1

Bonjour JF Fustec,

Si je comprend bien vous avez changé de domain ( AD ) ?

---

My Technical Blog on Wordpress

Answer 2

Bonjour

effectivement quelques informations supplémentaires sont nécessaire pour bien comprendre votre soucis :

1. avez vous changer de domaine ? ou bien vous utilisez le même
2. quel est le provider d'authentification coté 2010 ? claims (revendication) ou pas ? 

---

Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

Answer 3

Bonjour,

Je suis dans le même domaine.

Etapes suivies :

• export des bases SQL S.
• suppression de l'application web et nettoyage IIS
• désinstall de SHP
• création d'une nouvelle instance SQL
• install Foundation 2013
• config de la nouvelle ferme sur la nouvelle instance SQL
• création d'une appli web (même port et nom d'hôte que l'ancienne) (1)
  
• restauration de la base content
• montage de la base sur l'appli web
• ajout des administrateurs dans la collection de site

(1) j'ai pris les options par défaut, donc NTLM, en mode revendication. J'ignore les conséquences... sur l'identification des utilisateurs, mais ça en a peut-être une.

Merci

Answer 4

d'accord, mais la source (la version 2010) vous etiez en mode revendication ou pas?  (ça à clairement un impact !)

---

Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

Answer 5

Non, je ne crois pas.

Si c'est la cause, que dois-je faire pour régler le problème ?

Answer 6

Bonjour,

J'ai fais une install de sharepoint 2013 et en créant une application, revendication par formulaire était coché par défaut. Lorsque vous regardez les nom user est-ce : domain\user ou i:0#.w|Domain\User.

Si c'est le cas 2, c'est que vous êtes en authentification par formulaire, sauf erreur de ma part...

http://technet.microsoft.com/fr-fr/library/gg251985.aspx

Microsoft recommande d'utiliser plutôt le PowerShell. Néanmoins, j'ai aussi remarqué que SharePoint supporte mal sur certaines fermes les groupes AD.
Sur 2010 j'utilise cette commande en powershell SharePoint (lancer en tatn q'admin) après avoir mis en place l'authentification par formulaire.

$WebAppName = "xxxx"

$wa = get-SPWebApplication $WebAppName

$wa.MigrateUsers($true)

Cordialement

Answer 7

Bonjour

Oui c'est un pbm car le format de login est différent (comme le signale Loic)

En principe vous auriez dû au préalable migrer votre application web 2010 vers un provider Claims (en restant sur du 2010) avant de migrer la WebApp sur un serveur 2013. Pour cela la commande powershell migrateuser aurait été effectivement nécessaire après l'utilisation de la commande permettant de changer de provider d'auth

Maintenant c'est un peu tard si j'ai bien compris votre contexte...

Donc pour résumer la situation,

• SharePoint stocke dans la base de contenu la liste des users (SPUser) ayant accès à ces contenus.
• Les utilisateurs sont identifiés par leur login
• une même personne physique ayant accès par 2 canaux d'authentification au même contenu (possible via claims justement) est enregistrée par SharePoint avec 2 logins et donc du point de vue SharePoint 2 entrées dans sa liste de users
• Vous etes dans la situation où tous les login enregistrés ds SP sont au format 'classic' : domain\username  mais avec un point d'entrée claims, donc les utilisateurs qui se connectent arrive avec un login au format claims i:0#.w|domain\, donc sharepoint dit "pas accès" car ça ne match pas !

De mon expérience pas la peine de batailler avec la commande migrateuser (mais ça n'engage que moi) autant faire votre propre batch (powershell ou C#) qui va parcourir l'ensemble des permissions de votre sharepoint, chercher les user dont le login est au format windows, détecter les permissions accordées, enlever ce user, remettre l'equivalent au format claims avec les même permissions.

pour parser/ecrire le login au bon format le SDK de sharepoint fourni des methodes helpers:
http://blog.mastykarz.nl/programmatically-converting-login-name-claim/

bon courage !

---

Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

Answer 8

Bonjour Loic

pour information le format claims ne signifie pas forcement accès par formulaire :)

par exemple le login fourni concerne un compte Windows (w avant le pipe)

i:0#.w|Domain\User 

pour u formulaire on aurait plutoti:0#.f|Domain\User 

:)

---

Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

Answer 9

Bonjour Lionel,

merci pour cette précision, j'aurai du argumenter d'avantage :(

Pour ma défense (j'espère que ça va passer ^^) je n'active la revendication que lorsque je mets en place l'authentification par formulaire. D'où mon amalgame dans ce cas présent.

Lors de mes prochains commentaires, j'essaierai d'être plus détaillé.

Cordialement

Answer 10

pas de soucis Loic :)

tu as raison, aujourd'hui le claims est principalement utilisé pour activer l'auth via du formulaire....

mais permet aussi d'utiliser des fournisseurs d'auth tiers se basant sur AD LDS par exemple, voir intégrer de l'auth via facebook, live, google, etc.... du OAuth en somme....

---

Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

Answer 11

Je reprends après quelques recherches, et j'explique ce que j'ai compris, pour les suivants :

• dans les versions anciennes, lle mode classique était proposé par défaut, maintenant il n'est plus disponible du tout dans l'admin centrale ;
  
• j'aurais pu garder le mode classique, à condition de créer mon appli web en powershell avec le bon paramètre, avant de remonter ma collection par dessus ;
  
• le plus propre aurait été, en version 2010, migrer du mode classique au mode revendication, avant de passer à 2013 ;
  
• le billet ci-dessus propose de corriger les comptes SharePoint actuels, mais c'est un peu pointu
  

Au final, comme il s'agit d'un petit site, on va reprendre nos groupes a la mano, en profitant pour faire du propre.

Merci.