Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

The Mit's Blog

En plus d'intégrer et skier, il sait même écrire !
(Blog de Renaud Comte)

Actualités


  • Ancien MVP SharePoint 8 ans ...
    Des projets .Net, SharePoint 2013 ou Office 365 ??

    Contactez-nous :

Archives

SharePoint 2010 : Création des groupes de sécurité à posteriori et gestion de l’héritage des permissions

C’est un constat : on créé souvent des sites SharePoint plus rapidement qu’on le pense. En pratique, on oublie de casser l’héritage des droits

image

Ce n’est pas vraiment gênant mais que ce soit via l’admin, le code ou Powershell, il faut cependant faire attention à quelques détails .

A) Rappel sur la gestion des droits

Les permissions sous SP fonctionnent sur le principe d’assignation de sécurité entre un niveau de droit et une identité.

ACL et WSS

http://blogs.developpeur.org/themit/archive/2008/06/23/sharepoint-et-la-s-curit-en-d-veloppement-sproleassignment-spbasepermissions-et-leurs-amis.aspx 

http://blogs.msdn.com/b/joelo/archive/2007/06/29/sharepoint-groups-permissions-site-security-and-depreciated-site-groups.aspx

Ce qui se traduit en pratique par:

  • je donne un niveau lecteur à une personne ou un groupe
  • je place une personne ou un groupe dans un groupe SharePoint qui possède déjà une assignation sur un niveau

Par défaut, SharePoint crée 3 groupes SharePoint auxquels sont associés 3 assignations de sécurité :

    • Visiteur de “”
    • Membre de “”
    • Propriétaire de “”

Comme vous le réalisez, il n’y a pas à proprement dire de vrais groupes de sécurité : il faut des groupes et des assignations

==> et c’est exactement de là que viennent souvent les soucis d’admin ou d’incompréhension des powerusers au début

B ) Depuis l’interface

Quand vous créez un site avec des permissions uniques, SharePoint vous propose un écran de création automatique de ces 3 groupes par défaut (et des assignations associées)

image

Petit souci :  si vous créez le site avec héritage et que vous cassiez l’héritage depuis l’interface, vous n’avez plus aucun moyen de créer rapidement ces 3 groupes ! Pour une raison un peu obscure, Microsoft a retiré de l’admin le lien vers la page de création de ces groupes

http://sharepointdevsolutions.blogspot.com/2010/11/missing-set-up-groups-page-in.html

Mais ce n’est pas bloquant, il suffit de recréer les groupes et les assignations … perte de temps plus qu’autre chose
Bien souvent, on rajoute juste des membres et on garde les visiteurs et admin du site père.

Heureusement, on peut contourner le souci aisément en tapant directement l’adresse de la page : <URL du site>/_layouts/permsetup.aspx

C) Depuis le code

Créer des sites de manières automatisés par code n’est absolument pas à négliger

  • Pour des tests d’industrialisation (bonjour Phil)
  • Pour respecter un plan de gouvernance (bonjour Christian)
  • Pour déployer plus rapidement une nouvelle demande en Shell (Bonjour Fabrice)
  • Pour éviter de donner les droits à des power users un peu jeunes (Bonjour François )
  • Parce qu'on aime le code aussi (bonjour Laurent)

Certes, le processus est connu, largement utilisé et réutilisé mais il est bon de mettre en lumière certains petit points qu’on pourrait qualifier de gênants à bloquants à

Casser l’héritage

2 façons de faire :

Je préfère de loin utiliser le second car je peux au moins choisir de copier ou non les permissions du site père, ainsi que conserver les “uniques permissions” (on ne sait jamais)

>>> Attention, SPWeb.BreakRoleInheritance(true) signifie que vous cassez l’héritage et que vous copiez les permissions du père aussi. donc même si vous créez un nouveau groupe auteur, les auteurs du père ont encore accès !!! 
http://moustafa-arafa.blogspot.com/2010/06/breakroleinheritance-common-mistake-tip.html

Mais voila, ce n’est pas tout !!! Attention aux problèmes de performance !!!

Ce genre de code fonctionne sans soucis mais avez vous déjà fait un test de charge sur vos VM SharePoint de Dev avec plus que 3 listes, 4 dossiers et 2 sites ? hum hum, rarement hein ? Je ne vous blâme pas mais si jamais vous faites cette opération sur un grand nombre de sites, sous sites et listes, vous allez constater de fort ralentissements !

La recopie des permissions du père peut s’accompagner de dizaines de création de permission “limited access” ce qui peut se cumuler avec les items, les listes et le site du fait que vous avez toujours accès “à la racine”

>>> Soit le problème de la bibliothèque avec des dossiers uniques par utilisateurs. Imaginez une bibliothèque avec 4000 dossiers à sécuriser, vous risquez de créer jusqu’à 4000 dossiers * 4000 accès restreint à la racine (à recopier) = 16 millions de permissions pas vraiment utiles …

Je ne saurais trop vous conseiller de lire ce post de Chakkaradeep Chandran [MCS]
http://www.chakkaradeep.com/post/SharePoint-ndash3b-Setting-Item-level-permission.aspx

Ainsi que celui ci de Jason Ruthkoski
http://www.sharepointbriefing.com/spcode/article.php/3816551/Solve-ItemLevel-Permission-Performance-Problems-in-SharePoint.htm

Soit un simple code à connaitre  :

if (!item.HasUniqueRoleAssignments)
{
  item.BreakRoleInheritance(false);
}

Mais revenons sur le sujet des groupes de sécurité par défaut Sourire

Donc, nous sommes sur un site SharePoint dont nous avons cassé l’héritage avec ou sans copy des permissions. Comment recréer ces groupes de sécurité ? Et surtout pouvoir les exploiter ensuite?

Certes, vous pouvez manipuler les roleassignements et refaire tout le travail tel que ce bon exemple

Ou sinon, vous utilisez la méthode SPWeb.CreateDefaultAssociatedGroups
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spweb.createdefaultassociatedgroups.aspx

Seulement voila, la vie n’est pas toujours aisée … Votre site peut être créé depuis un template ou un site definition particulier et bizarrement vos groupes n’apparaissent pas en gestion …

Bug or not ? Plus ou moins …

Un petit tour avec Reflector (ou ses variantes gratuites) nous donne quelques informations intéressantes qu’on recoupe aisément avec les données du MSDN

CreateDefaultAssociatedGroups créé effectivement les groupes par défaut si et seulement si les propriétés des groupes associés du SPWeb sont nulles. Soit :

  • Web.AssociatedVisitorGroup = null;
  • Web.AssociatedMemberGroup = null;
  • Web.AssociatedOwnerGroup = null;

Seulement, il ne faut pas oublier ensuite de les associer au SPWeb pour que l’administration de SharePoint en tienne compte dans le menu des groupes par exemple.

Et là on (peut) tomber dans un vieux piège historique de SharePoint : Bien souvent, l’OM de SharePoint utilise des clés en propertybags de ces objets comme référence plutôt que les propriétés en direct. Certainement pour des raisons de cache. C’était souvent un des points gênants en migration ou à cause de référence ancienne différente des nouveaux serveurs que les injecteurs se plantaient littéralement

il faut donc renseigner aussi ces fameuses clés que sont :

  • Web.Properties["vti_associatevisitorgroup"]
  • Web.Properties["vti_associateownergroup"]
  • Web.Properties["vti_associatemembergroup"]

Ce qui donne le code complet que voici !

Web.AssociatedVisitorGroup = null;
Web.AssociatedMemberGroup = null;
Web.AssociatedOwnerGroup = null;

Web.BreakRoleInheritance(true);
Web.Update();

Web.CreateDefaultAssociatedGroups(SPContext.Current.Web.CurrentUser.LoginName, SPContext.Current.Web.CurrentUser.LoginName, Web.Name);

Web.Properties["vti_associatevisitorgroup"] = Web.AssociatedVisitorGroup.ID.ToString();
Web.Properties["vti_associateownergroup"] = Web.AssociatedOwnerGroup.ID.ToString();
Web.Properties["vti_associatemembergroup"] = Web.AssociatedMemberGroup.ID.ToString();
Web.Properties.Update();
Web.Update();

Je pense que tout a été dit, je complèterai le post selon les commentaires évidemment

Et Powershell ? pas de soucis : http://secretsofsharepoint.com/cs/blogs/tips/archive/2011/09/05/associate-custom-groups-using-powershell.aspx

A bientôt et bon coding

Renaud Comte aka TheMit (Félicitations à Mr Delaporte pour son fils Armand né dans la nuit d’Halloween )
Member of WygTeam
http://www.wygwam.com

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: mardi 1 novembre 2011 14:56 par themit

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01

- SharePoint Online: Script PowerShell pour supprimer une colonne dans tous les sites d’une collection par Blog Technique de Romelard Fabrice le 11-27-2018, 18:01