Plan de nommage des groupes de sécurité SharePoint

Dans une organisation, la sécurité des informations stockées dans SharePoint est assurée uniquement à travers les groupes de sécurité SharePoint.

Il est interdit de donner un autorisation en utilisant directement un groupe de l’annuaire central. Par contre, un groupe de l’annuaire central peut appartenir à un groupe de sécurité SharePoint.

L’objectif est de disposer d’un plan de nommage des groupes de sécurité qui soit :

  • structuré de manière identique quelque soit le groupe, l’objet à sécuriser ou l’autorisation,
  • adapté au modèle de sécurité SharePoint.

Structuré de manière identique quelque soit le groupe, l’objet à sécuriser ou l’autorisation

Afin de normaliser la codification pour nommer le groupe de sécurité, il est proposé le format suivant:

CODESITE _ AAAAAAAA

où :

  • CODESITE: Nom court du site des Directions / Départements / Services,
  • AAAAAAAA: Niveaux d’autorisations SharePoint accordées avec les libellés suivants: Contrôle total, Lecture, Collaboration, Conception, etc.

Pour des raisons de lisibilité et de compréhension, il a été préféré d’afficher directement le niveau d’autorisations (Contrôle total) plutôt que les noms classiques des groupes SharePoint: Approbateurs, Concepteurs, Gestionnaires de hiérarchies, Lecteurs de ressources de style, Membres, Propriétaires, Visiteurs.

Les espaces entre les valeurs doivent être respectés.

Le nom court du site correspond à une nomenclature interne sur 3 ou 4 caractères. Par exemple, le site du Service de Support aux Fournisseurs étrangers de langue française a le code: SFEF, celui de la Direction des Ressources Humaines est: DRH.

Ceux qui donne les noms de groupes suivants pour le site de la Direction des Ressources Humaines:

  • DRH _ Collaboration
  • DRH _ Lecture
  • etc.

La présence de l’underscore (« _ ») permettra de ne pas mélanger ces autorisations avec celles des niveaux inférieurs (cf. ci-dessous).

Adapté au modèle de sécurité SharePoint

Vue de l’utilisateur, les objets sécurisables dans SharePoint sont la Collection de sites, les sites, les listes (ou les bibliothèques), les dossiers des bibliothèques et les éléments (ou les documents).

Compte-tenu de l’héritage des autorisations, le besoin de disposer d’un groupe de sécurité au niveau d’un objet enfant (par exemple une bibliothèque d’un site) se justifie par la nécessité de personnaliser les autorisations.

Pour répondre à cette contrainte, il a été proposé que la valeur du code T varie en fonction de l’objet et du nom interne de l’objet.

Liste ou bibliothèque

Dans le cas d’une liste, le nom interne est généré automatiquement par SharePoint à partir du nom. Le nom interne ne varie jamais, même en cas de renommage de la liste. Par ailleurs, il n’est pas possible d’avoir deux noms internes identiques dans un site.

Afin d’avoir des noms internes courts et lisibles, les listes sont systématiquement créées avec le nom interne désiré puis ensuite elles sont renommées.

Par exemple, si vous désirez avoir une bibliothèque nommée Rapports d’activités, vous la créez avec le nom RAPACT puis ensuite vous la renommez en Rapports d’activités.

Le format de normalisation du nom des listes devient:

CODESITE CODELISTE _ _ AAAAAAAA

où :

  • CODELISTE: Nom interne de la liste.

CODESITE et AAAAAAAA sont inchangés par rapport à la codification du site.

La présence des underscores en double est obligatoire à cause des dossiers et des éléments (cf. ci-dessous).

Donc, s’il est nécessaire d’avoir des groupes spécifiques à la bibliothèque Rapports d’activités du site DRH, cela donnerait:

  • DRH RAPACT _ _ Collaboration
  • DRH RAPACT _ _ Lecture
  • etc.

Dossier

Il n’est pas facile d’interdire à un utilisateur de créer un dossier dans une bibliothèque SharePoint.

Vous savez bien qu’il ne suffit pas de cacher l’option Nouveau dossier. par exemple, l’utilisateur peut contourner ce paramétrage grâce au lien Ouvrir avec l’Explorateur du ruban Bibliothèque ce qui lui permet de créer des dossiers.

Malgré tout, il existe des méthodes pour l’interdire complètement. Elles seront détaillées dans un autre article.

Dans notre cas, les utilisateurs pouvaient créer eux-mêmes les dossiers grâce au navigateur. Il n’était donc pas possible d’imposer un nom unique pour tous les dossiers d’un site. Il est donc possible d’avoir deux bibliothèques distinctes avec chacune un dossier qui porte le même nom.

La solution a consisté à modifier la codification pour les dossiers, de la façon suivante:

CODESITE CODELISTE _ CODEDOS AAAAAAAA

où :

  • CODEDOS: Nom court du dossier.

Dans un souci de simplicité, il n’a pas été imposé une codification stricte du nom court du dossier. La seule contrainte est d’être significatif, de ne pas dépasser 6 caractères et d’être unique.

Donc, s’il est nécessaire d’avoir des groupes spécifiques au dossier Audits internes de la bibliothèque Rapports d’activités du site DRH, cela donnerait par exemple:

  • DRH RAPACT _ AUDINT Lecture
  • DRH RAPACT _ AUDINT Collaboration
  • etc.

Élément ou Document

Pour des raisons liées au caractère sensible des données de l’organisation (Laboratoire pharmaceutique) et pour des raisons historiques (ancien système basé sur Lotus Domino), les autorisations sont fréquemment données au niveau du document…

Pour s’adapter à cette contrainte forte, la codification des groupes de sécurité SharePoint liés à un élément dans une liste ou un document d’une bibliothèque est à la suivante:

CODESITE CODELISTE CODEDOC AAAAAAAA

où :

  • CODEDOC: Nom court du document ou de l’élément.

Le nom court du document est généré comme un nom court de fichiers (nom 8dot3 http://technet.microsoft.com/en-us/library/ff621566(v=ws.10).aspx). Dans une invite de commande, les noms courts sont visibles grâce à l’instruction DIR /X.

Volontairement, il n’est pas tenu compte de la présence ou de dossiers dans la bibliothèque.

Si le document qui s’intitule Produit XYZ.docx a comme nom court PRODUI~1.DOC (par exemple).

Donc, s’il est nécessaire d’avoir des groupes spécifiques à ce document, cela donne:

  • DRH RAPACT PRODUI~1.DOC Lecture
  • DRH RAPACT PRODUI~1.DOC Collaboration
  • etc.

En images

Plan de nommage des groupes de sécurité SharePoint

Sécurité des accès dans SharePoint 2010

La sécurité des accès dans SharePoint 2010 est un sujet vaste, où il est aisé de s’y perdre. En plus des aspects sécuritaires, l’enjeu de la sécurité des accès dans SharePoint 2010 est son administrabilité à long terme.

Mettre en place des droits dans SharePoint 2010 est simple et même rapide. La difficulté vient avec le temps: évolution des sites (contenu, structure), mutation du personnel, changement de fonctions, etc.

Cette difficulté s’accroît aussi avec, globalement, la taille de l’entreprise et le nombre de documents à gérer, la dispersion géographique du personnel, le nombre d’utilisateurs, les fonctionnalités activées et l’usage.

Il n’est pas rare – c’est un doux euphémisme – qu’un audit de sécurité révèle des brèches béantes. Celles-ci sont dues à une méconnaissance du fonctionnement des mécanismes de sécurité dans SharePoint 2010.

Cet article essaye d’éclaircir ces fameux mécanismes.

Administrateurs de la ferme

Lors de l’installation, SharePoint Server crée au niveau de l’administration centrale le groupe SharePoint Administrateurs de la batterie (« Farm Administrators »).

Ce groupe a un contrôle total sur les serveurs de la ferme. Il sert à l’administration  technique de SharePoint : Gérer les serveurs, Gérer les services, Gérer les fonctionnalités des batteries de serveurs, Gérer les applications Web, Créer des collections de sites, Gérer les applications de service, Gérer les bases de données de contenu, Sauvegarder / restaurer, Analyser le fonctionnement, etc.

Par défaut, les membres de ce groupe n’ont pas accès aux collections de sites. Autrement dit, un administrateur de la ferme peut créer une collection de sites mais il ne peut pas la gérer, à moins qu’il se soit désigné comme administrateur de la collection de sites.

Microsoft a donc bien distingué l’administration « technique » de l’administration « fonctionnelle ».

Même si l’administrateur de la ferme n’est pas administrateur de la collection de sites, il peut décider des niveaux d’autorisations administrables par l’administrateur de la collection de sites. En particulier, l’administrateur de la ferme peut restreindre la liste des autorisations de l’application web qui porte les collections de sites.

Ainsi, seuls un nombre restreint d’autorisations seront accordés aux utilisateurs des collections de site de l’application web. Comme ces restrictions s’appliquent aussi aux administrateurs de la collection de sites, il est plus efficace que le compte d’administration de la ferme soit différent du compte d’administration de la collection de site.

Par exemple, l’administrateur de la ferme peut désactiver l’autorisation de supprimer des éléments. Dans ce cas, l’administrateur de la collection de sites et les utilisateurs ne pourront plus supprimer un élément d’une liste ou d’une bibliothèque. En revanche, ils pourront toujours à ajouter ou modifier les éléments sous réserve de disposer des droits ad’hoc.

En fonction de la zone de provenance d’un utilisateur (« intranet », « internet », etc.), l’administrateur de la ferme peut lui attribuer des autorisations différentes grâce à une stratégie de sécurité sur l’application web. La stratégie de sécurité concerne les demandes effectuées à travers la zone spécifiée.

Par exemple, si Alice se connecte en interne (zone « par défaut »), elle dispose d’un accès de collaborateur. Par contre, si elle se connecte via Internet, elle ne dispose plus que d’un accès en lecture seule.

Les permissions issues d’une stratégie de sécurité l’emportent toujours sur les autres autorisations.

Administrateurs de la collection de sites

Lors de la création d’une collection de site, l’administrateur de la ferme doit obligatoirement désigner au moins un administrateur de la collection.

Bien qu’au moment de créer une collection de sites, l’interface de l’Administration centrale de SharePoint 2010 ne propose la saisie que de deux administrateurs de la collection (« principal », « secondaire »), il sera possible par la suite d’en rajouter d’autres.

Il n’existe pas de différences entre un administrateur « Principal » et « Secondaire ». Il s’agit d’une simple aide pédagogique.

L’administrateur d’une collection de sites dispose du contrôle total sur tous les sites web de la collection de sites. L’inverse n’est pas vrai, si vous disposez du contrôle total « uniquement », cela ne fait pas de vous un administrateur de la collection de sites.

Dans ce cas, vous ne pourrez pas :

  • modifier les administrateurs de la collection de site,
  • avoir accès aux paramètres de la collection de sites: Paramètres de recherche, Étendues de recherche, Mots clés de recherche, Mots clés FAST Search, Promotion et rétrogradation du site FAST Search, Contexte utilisateur FAST Search, Corbeille, Fonctionnalités de la collection de sites, Hiérarchie des sites, Navigation dans la collection de sites, Paramètres d’audit des collections de sites, Rapports du journal d’audit, Connexion au site portail, Stratégies de collections de sites, Profils de cache de la collection de sites, Cache d’objets de la collection de sites, Cache de sortie de la collection de sites, Publication de type de contenu, Variantes, Étiquettes de variante, Colonnes à traduire, Journaux de variante, Emplacements de navigateur de contenu suggérés, Paramètres de SharePoint Designer, Mise à niveau visuelle, Paramètres de l’aide,
  • avoir accès à certains paramètres de site: Flux de travail, Paramètres d’étendue des liens connexes, Contenu et structure, Journaux Contenu et structure.

L’administrateur de la collection de sites gère aussi les demandes d’accès à la collection de sites.

Autorisations et niveaux d’autorisations

En matière d’autorisations, il existe deux notions qu’il ne faut pas confondre:

  • Autorisations
  • Niveaux d’autorisations

Une autorisation est la particule la plus élémentaire en matière de droits.

Exemples d’autorisations de site : Gérer les autorisations, Créer des sous-sites, Ajouter et personnaliser des pages, Appliquer des thèmes, Appliquer des feuilles de styles, Gérer les alertes, Utiliser les interfaces WebDav, Etc.

Exemples d’autorisations pour une liste : Gérer les listes, Remplacer l’extraction, Ajouter des éléments, Modifier des éléments, Supprimer des éléments, Afficher des éléments, Approuver des éléments, Ouvrir des éléments, Afficher les versions, Supprimer les versions, Créer des alertes, Etc.

Toutefois, et malgré ce que l’interface graphique présente, vous n’attribuez pas directement une autorisation. Dans SharePoint, vous accordez les autorisations à travers les niveaux d’autorisation.

Un niveau d’autorisation est une combinaison d’autorisations.

Vous trouverez ci-dessous les niveaux d’autorisation fournis par défaut, avec une illustration de qu’il est possible de faire:

  • Contrôle total : gérer les droits,
  • Conception : modifier les pages,
  • Collaboration : déposer un document dans une bibliothèque,
  • Lecture : lire un document sans pouvoir l’enregistrer dans la bibliothèque d’origine,
  • Vue seule : afficher la liste des documents sans pouvoir les lire.

Dans le détail, un niveau d’autorisation donné correspond à une liste précise d’autorisations accordées. Par exemple, il existe un niveau d’autorisation par défaut intitulé Lecture. Pour une liste, il correspond aux autorisations : afficher les éléments, ouvrir les éléments, afficher les versions, créer des alertes et afficher les pages des applications. Le niveau d’autorisation Vue seule a les mêmes autorisations que Lecture sauf ouvrir les éléments.

Vous pouvez personnaliser les niveaux d’autorisation par défaut. Vous pouvez modifier les autorisations rattachées au niveau ou créer des niveaux supplémentaires.

En termes de bonnes pratiques, je vous recommande vivement de ne pas modifier les autorisations accordées aux niveaux d’autorisation par défaut. Si besoin est, créez vos propres niveaux d’autorisations. Ce cas de figure se présente dans les organisations importantes.

Un niveau d’autorisation peut être accordé à un compte utilisateur. Ce n’est pas recommandé. Il est préférable de rattacher cet utilisateur à un groupe puis d’accorder un niveau d’autorisation au groupe.

Reconnaissez que vous accordez un droit à une fonction ou un rôle de l’utilisateur dans l’organisation, et non à un utilisateur qui changera de fonction, un jour ou l’autre.

La question qui va surgir concerne l’utilisation de groupes SharePoint ou ceux de l’annuaire, comme Active Directory. Avant de donner des éléments de réponse à cette question épineuse, examinons le fonctionnement des groupes dans SharePoint.

Groupes SharePoint

Une collection de site SharePoint comprend au moins 4 groupes par défaut (entre crochets figure le niveau d’autorisations accordé):

  • Groupe Propriétaires [Contrôle total]
  • Groupe Membres [Collaboration]
  • Groupe Visiteurs [Lecture]
  • Groupe Visualiseurs [Vue seule]

Selon les fonctionnalités activées sur votre collection de site, vous pouvez obtenir d’autres groupes: Approbateurs, Concepteurs, etc.

Lorsqu’un nouvel utilisateur est ajouté à un groupe, il hérite automatiquement des autorisations accordées au groupe.

Tous ces groupes se personnalisent. Vous pouvez modifier les niveaux d’autorisation attachés aux groupes par défaut ou créer des groupes supplémentaires.

Les groupes SharePoint ont une particularité un peu perturbante au départ. Lorsque vous créez un groupe, il est disponible pour tous les sites de la collection de sites, quel que soit l’endroit à partir duquel vous le créez. Même si vous créez le groupe dans un site adjacent ou dans une sous-arborescence, il est visible par tous les sites. Même si dans le site où vous créez le groupe, l’héritage est rompu.

Une fois que ce comportement est assimilé, il reste à définir les critères qui président au choix d’un groupe SharePoint ou d’un groupe Active Directory (AD).

Souvent les administrateurs de l’AD ne veulent pas que les applications viennent « polluer » l’AD. Autrement dit, ils ne veulent pas créer de groupes spécifiques dans l’AD pour SharePoint.  Dans certaines organisations, la situation est bloquée et les utilisateurs n’ont pas d’autres choix que d’utiliser des groupes SharePoint.

Pourtant la gestion des droits à l’aide de groupes AD présente un intérêt certain et à ma préférence.

Le rôle de l’AD est de définir un référentiel unique et commun des identités de l’entreprise. Hors, l’utilisation des groupes SharePoint entraine une surcharge administrative supplémentaire qui est parfois importante. Notamment, si cette administration est déléguée aux utilisateurs. Dans ce cas, non seulement il n’y a pas d’automatismes, mais les risques liées à la sécurité d’accès sont élevés car il n’y a pas de contrôles à posteriori.

En outre, si vous utilisez des groupes AD, vous pourrez nativement utiliser l’outil de requête de l’AD qui permet de faire des recherches personnalisées avec la norme Lightweight Directory Access Protocol (LDAP). De plus, ces recherches sont facilitées grâce à l’assistant intégré.

Toutes ces raisons militent pour privilégier l’utilisation des groupes de l’AD.

Sécurité des rôles

La sécurité dans SharePoint n’est pas monolithique. Au contraire, vous accordez un droit (un niveau d’autorisations) à un utilisateur (à travers un groupe) sur un objet.

Les objets sécurisables sont:

  • Site,
  • Liste ou bibliothèque,
  • Dossier d’une bibliothèque
  • Elément d’une liste ou document d’une bibliothèque.

Autrement dit, un utilisateur peut avoir des droits différents sur un même site.

Par exemple, Alice peut avoir le droit d’accéder en lecture à un site. Sur le même site, elle pourra accéder en mise à jour sur la bibliothèque ‘Documents partagés’. Notez que c’est possible malgré le fait qu’un droit de mise à jour est « plus important » qu’un droit de lecture.

C’est ce qu’on appelle la sécurité des rôles. SharePoint utilise la sécurité des rôles pour vérifier la permission d’un groupe ou d’un utilisateur par rapport à un objet.

La liste des objets sécurisables est limitée.

En particulier, il n’est pas possible actuellement de donner des droits différents sur une partie d’une page SharePoint, ni même sur un composant de WebPart.

Les audiences seront traitées dans un autre article mais, en aucun cas, ils ne sont un élément pour gérer les droits.

Héritage

Par défaut, un nouveau site dans une collection de site hérite des autorisations du site parent. Un sous-site d’un site hérite donc des droits du site parent.

Les objets héritent aussi par défaut des sécurités de l’objet parent. Par exemple, une liste par rapport à son site.

Tant que l’héritage n’est pas rompu, il maintient un lien dynamique avec les droits du parent direct. Si l’héritage est cassé, les droits du parent sont recopiés sur l’enfant sans lien dynamique. Les droits de l’enfant deviennent alors modifiables.

Cela peut être aussi une source de confusion au début. Si vous n’y prenez pas garde, vous risquez de modifier les droits du parent. En effet, avant de modifier les droits d’un enfant, il faut casser l’héritage. Si vous oubliez de rompre cet héritage, vous modifierez les droits du parent.

La bonne nouvelle c’est qu’un héritage rompu peut être rétabli à chaque instant. Dans ce cas, tous les droits modifiés de l’enfant sont perdus.

Autorisations des listes ou des bibliothèques

Tout comme les droits sur les sites, vous avez la possibilité de restreindre l’accès à des listes ou des bibliothèques.

Pour la gestion des droits d’une liste, affichez les paramètres de celle-ci. Dans les paramètres, cliquez sur « Autorisations pour le composant : liste ».

Pour la gestion des droits d’une bibliothèque, affichez les paramètres de celle-ci. Dans les paramètres, cliquez sur « Autorisations pour le composant : bibliothèque de documents ».

Si vous voulez aller plus loin, dans une bibliothèque ou une liste, vous avez la possibilité de donner des droits différents à des objets qui en font partie. Par exemple, donner des droits à un fichier Word d’une bibliothèque de documents.

Droits sur les documents

Pour donner des droits sur n’importe quel document, afficher le contenu de la liste ou de la bibliothèque et cliquez sur le menu d’édition du document pour en afficher le menu contextuel.

Bonnes pratiques de sécurité

Dans la pratique, l’expérience m’a montré que la gestion des droits est structurante sur le design des sites. Ce qui signifie que vous devez tenir compte du modèle de droits SharePoint pour votre conception: si, par exemple, vous aviez prévu de donner des droits différents au milieu d’une page.

En termes de méthode, il n’est évidemment pas possible de donner un algorithme systématique pour réussir la mise en oeuvre de la sécurité des accès dans SharePoint 2010.

D’autant que la sécurité des accès n’est qu’une partie de la sécurité globale:

Pour configurer les paramètres antivirus ou gérer les types de fichiers bloqués, reportez-vous au site de Microsoft.

Vous trouverez ci-dessous quelques pistes pour avancer.

Pour chaque site: 1) Listez les futurs utilisateurs par fonction dans chaque service ; 2) Distinguez les utilisateurs selon leurs droits : auteurs, lecteurs, autres.

Pour ‘Mon Site’: Utilisez des groupes de sécurité pour gérer les autorisations des sites Mon site.

Niveaux d’autorisations: 1) Créez des niveaux supplémentaires afin de tenir compte des dérogations ; 2) Définissez un niveau d’autorisation par combinaison des autorisations.

Ciblage d’audiences: 1) L’audience n’est pas un droit ; 2) Utilisez les audiences pour masquer un objet (WebPart, etc.).

Utilisateurs: 1) Ne donnez pas des droits à un utilisateur ; 2) Donnez un droit à un groupe de l’AD ou à un groupe SharePoint.

Groupes: 1) Créez des groupes pour factoriser les droits ; 2) Assignez un niveau d’autorisation aux groupes ; 3) Attachez le groupe SharePoint à un des quatre objets à sécuriser: Site, Liste / Bibliothèque, Dossier, Elément / Document

Pour aller plus loin

Gérer les utilisateurs et les autorisations avec Microsoft. Vous saurez donner des autorisations et niveaux d’autorisation puis gérer les autorisations par le biais d’une stratégie et gérer les autorisations pour une application Web. Vous apprendrez aussi comment prendre possession d’une collection de sites et gérer les administrateurs de collection de sites.

Pour apprendre à Configurer les fournisseurs d’authentification avec Microsoft.

Annexes

Les informations ci-dessous sont issues de la documentation Microsoft.

Autorisations des listes ou bibliothèques

Gérer les listes  –  Créer et supprimer des listes, ajouter des colonnes à une liste ou en supprimer, et ajouter des affichages publics à une liste ou en supprimer.

Remplacer l’extraction  –  Ignorer ou archiver un document qui est extrait pour un autre utilisateur.

Ajouter des éléments  –  Ajouter des éléments à des listes, et des documents à des bibliothèques de documents.

Modifier des éléments  –  Modifier des éléments dans des listes, des documents dans des bibliothèques de documents, et personnaliser des pages de composants WebPart dans des bibliothèques de documents.

Supprimer des éléments  –  Supprimer des éléments d’une liste, et des documents d’une bibliothèque de documents.

Afficher les éléments  –  Afficher des éléments dans des listes et des documents dans des bibliothèques de documents.

Approuver des éléments  –  Approuver une version secondaire d’un élément de liste ou d’un document.

Ouvrir les éléments  –  Afficher la source des documents avec des gestionnaires de fichiers côté serveur.

Afficher les versions  –  Afficher les versions antérieures d’un élément de liste ou d’un document.

Supprimer les versions  –  Supprimer les versions antérieures d’un élément de liste ou d’un document.

Créer des alertes  –  Créer des alertes.

Afficher les pages des applications  –  Afficher les formulaires, les affichages et les pages des applications. Énumérer les listes.

Autorisations des sites

Gérer les autorisations  –  Créer et modifier des niveaux d’autorisation sur le site Web, et affecter des autorisations à des utilisateurs et à des groupes.

Afficher les données Web Analytics  –  Afficher les rapports sur l’utilisation du site Web.

Créer des sous-sites  –  Créer des sous-sites, tels que des sites d’équipes, des sites Espace de travail de réunion et Espace de travail de document.

Gérer le site Web  –  Donner la capacité d’effectuer toutes les tâches d’administration sur ce site Web et de gérer le contenu.

Ajouter et personnaliser des pages  –  Ajouter, modifier ou supprimer des pages HTML ou de composants WebPart, et modifier le site Web à l’aide d’un éditeur compatible avec Microsoft SharePoint Foundation.

Appliquer des thèmes et des bordures  –  Appliquer un thème ou des bordures à l’ensemble du site Web.

Appliquer des feuilles de style  –  Appliquer une feuille de style (fichier .CSS) au site Web.

Créer des groupes  –  Créer un groupe d’utilisateurs pouvant être utilisé partout dans la collection de sites.

Parcourir les répertoires  –  Énumérer les fichiers et les dossiers d’un site Web à l’aide des interfaces SharePoint Designer et Web DAV.

Utiliser la création de sites libre-service  –  Créer un site Web à l’aide de la fonctionnalité de création de sites libre-service.

Afficher les pages  –  Afficher les pages d’un site Web.

Énumérer les autorisations  –  Énumérer les autorisations pour ce site Web (liste, dossier, document ou élément de liste).

Parcourir les informations utilisateur  –  Afficher les informations sur les utilisateurs du site Web.

Gérer les alertes  –  Gérer les alertes pour tous les utilisateurs de ce site Web.

Utiliser les interfaces distantes  –  Utiliser l’interface SOAP, Web DAV, SharePoint Designer ou du modèle objet client pour accéder au site Web.

Utiliser les fonctionnalités d’intégration des clients  –  Utilise des fonctionnalités qui permettent de lancer des applications clientes. Sans ce droit, l’utilisateur doit utiliser les documents en local et télécharger ses modifications.

Ouvrir  –  Autorise les utilisateurs à ouvrir un site Web, une liste ou un dossier pour accéder aux éléments de ce conteneur.

Modifier les informations personnelles de l’utilisateur  –  Autorise un utilisateur à modifier ses informations d’utilisateur, notamment ajouter une photo

Autorisations personnelles

Gérer les affichages personnels  –  Créer, modifier et supprimer des affichages personnels de listes.

Ajouter/Supprimer des composants WebPart personnels  –  Ajouter ou supprimer des composants WebPart personnels sur une page de composants WebPart.

Mettre à jour des composants WebPart personnels  –  Mettre à jour les composants WebPart pour qu’ils affichent des informations personnalisées.

SharePoint: Utiliser les métadonnées pour la sécurité

Une organisation rencontrait un problème de diffusion de documents assez classique. Cette organisation assure le rôle de diffuseur de contenu auprès d’autres organismes officiels, via un site extranet SharePoint. Une fois qu’un utilisateur d’un organisme étranger s’est identifié, il accède à ses documents.

Les métadonnées sont souvent utilisées pour faciliter la recherche ou pour catégoriser des documents afin d’opérer des filtres.

Un autre usage méconnu (ou peu utilisé) concerne la sécurité.

Modèle de sécurité standard de SharePoint

En effet, l’organisation mettait à disposition des documents qui sont communs à certains organismes et qui ne doivent pas être accessibles à tous. Afin de répondre à ce problème, le responsable de l’organisation avait décidé de s’appuyer sur le modèle de sécurité standard de SharePoint.

Pour cela, il avait mis en place différentes bibliothèques SharePoint pour les différents utilisateurs avec des droits spécifiques.

La gestion de plusieurs bibliothèques de documents devenait complexe et la maintenance des autorisations de niveau était difficile. De plus, certains documents furent volontairement dupliqués dans plusieurs bibliothèques pour résoudre rapidement des cas complexes.

Nouveau modèle de sécurité basé sur les métadonnées

Cette solution étant inacceptable, un nouveau modèle de sécurité basé sur l’utilisation de métadonnées a été proposé.

En utilisant ce nouveau modèle, il peut déposer de nouveaux documents dans SharePoint avec des métadonnées qui spécifie simplement les organismes qui peuvent y accéder: les niveaux de permissions accordés au document sont déduits des métadonnées des documents. Ce qui permet de réduire aussi le nombre de bibliothèque de documents à gérer.

Dans de nombreux cas, les métadonnées du document permettent d’indiquer qui peut y avoir accès. Toutefois, si vous avez l’intention d’utiliser les métadonnées pour la sécurité, vous devez planifier avec soin le type de métadonnées à collecter.

Vulnérabilité dans Microsoft SharePoint Server

Une vulnérabilité a été corrigée dans Microsoft SharePoint Server

Elle permet à un attaquant de provoquer une élévation de privilèges.

Il s’agit d’une vulnérabilité d’élévation de privilèges, celle-ci est causée lorsque SharePoint Server est abusée par une application spécialement conçue dans ce but et qui utilise le modèle d’extensibilité de SharePoint pour exécuter du code JavaScript arbitraire avec les droits de l’utilisateur authentifié courant.

Le danger réside dans le fait qu’un attaquant pourrait créer une application spécialement conçue pour exploiter cette vulnérabilité, puis convaincre les utilisateurs de l’installer afin d’exploiter la faille si elle n’est pas corrigée.

L’application peut contourner la gestion des autorisations et exécuter du code arbitraire dans le contexte de sécurité de l’utilisateur connecté.

Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait utiliser une application spécialement conçue pour exécuter du script arbitraire dans le contexte de sécurité de l’utilisateur connecté. Par exemple, le script pourrait agir sur le site SharePoint affecté avec les mêmes autorisations que l’utilisateur connecté.

Cette vulnérabilité concerne:

  • Microsoft SharePoint Server 2013 avec ou sans SP1
  • SharePoint Foundation 2013 avec ou sans SP1

Le bulletin de sécurité de Microsoft: Microsoft Security Bulletin MS14-050.

Désactiver l’accès anonyme aux pages Allitems.aspx et EditForm.aspx

En fait, il s’agit d’une question posée lors de l’examen 70-667 – TS: Microsoft SharePoint 2010, Configuring.

Vous pouvez vous préparer à cette certification, qui conduit à la certification Microsoft Certified IT Professional (MCITP), avec le livre de Dan Holme, Alastair Matthews, Bob Castle et Orin Thomas: MCTS Self-Paced Training Kit (Exam 70-667): Configuring Microsoft Sharepoint 2010.

Pour revenir à la question de départ: si vous ne prenez pas garde, les utilisateurs anonymes d’Internet peuvent demander d’afficher la page http://www.mw41.ff/(…)/AllItems.aspx, qui affiche tout le contenu du site SharePoint.

Afin d’éviter que les utilisateurs anonymes accèdent à la page Allitems.aspx, ainsi qu’EditForm.aspx, il existe la fonctionnalité ViewFormsPagesLockdown. Si vous voulez faire en sorte que les utilisateurs anonymes ne puissent pas accéder à ces pages, exécutez la commande stsadm suivante:
stsadm.exe –o activatefeature –url http://www.mw41.ff/ -filename ViewFormPagesLockdownfeature.xml

Si vous préférez utiliser PowerShell, vous déterminerez si la fonctionnalité est activée avec la cmdlet usuelle: get-spfeature -site http://www.mw41.ff/. Si la fonctionnalité ViewFormPagesLockDown n’apparaît pas, c’est qu’elle n’est pas activée.

Pour l’activer en PowerShell:
$lockdown = get-spfeature ViewFormPagesLockdown
enable-spfeature $lockdown -url http://www.mw41.ff/

Que ce soit avec stsadm ou PowerShell, si l’accès anonyme est activé, vous aurez besoin de le désactiver, puis de l’activer à nouveau.

Dans SharePoint 2010, la fonctionnalité ViewFormPagesLockDown est activée par défaut sur les portails de publication.

Activer l’accès anonyme dans SharePoint 2010

Lors d’une formation récente, un stagiaire n’arrivait plus à se rappeler comment activer l’accès anonyme dans SharePoint 2010 alors qu’il était censé le savoir…

D’où, l’idée de ce petit mémo sous forme d’une procédure:

  1. Cliquez sur Démarrer puis Tous les programmes : la liste des programmes installés apparaît.
  2. Sous Microsoft SharePoint 2010 Products, cliquez sur Administration centrale de SharePoint 2010: patientez plusieurs secondes pour que la page d’accueil de l’Administration centrale s’ouvre.
  3. Sous Gestion des applications, cliquez sur Gérer les applications Web: la liste des applications Web s’affiche.
  4. Cliquez sur l’application Web dont l’accès sera anonyme pour la sélectionner.
  5. Ensuite sur le ruban, dans le groupe Sécurité, cliquez sur Fournisseurs d’authentification: la boîte de dialogue Fournisseurs d’authentification s’ouvre.
  6. Dans cette boîte, cliquez sur la zone Par défaut : la boîte de dialogue Modifier l’authentification s’ouvre.
  7. Dans la boîte de dialogue Modifier l’authentification, cochez la case Activer l’accès anonyme puis cliquez sur le bouton Enregistrer pour sauvegarder vos modifications.
  8. Fermez la boîte de dialogue Fournisseurs d’authentification: la page Gestion des applications Web apparaît donc à nouveau.
  9. L’accès anonyme a été ouvert mais il peut être nécessaire de préciser les éventuelles restrictions d’accès sur le site. Pour cela, sur le ruban de cet écran, dans le groupe Stratégie, cliquez sur  Stratégie anonyme : la boîte de dialogue Restrictions d’accès anonyme s’ouvre.
  10. Éventuellement, spécifiez  une stratégie de l’utilisateur anonyme à mettre en place :  Aucun – Aucune stratégie, Refuser l’écriture – Pas d’accès en écriture ou Refuser tout – Aucun accès. Cliquez sur Aucun – Aucune stratégie, qui est la proposition par défaut, puis cliquez sur le bouton Enregistrer. Ainsi les utilisateurs anonymes pourront aussi bien lire qu’écrire sur le site web.
  11. Bien que l’accès anonyme ait été ouvert au niveau de l’application web, il vous reste à spécifier les sites autorisés aux utilisateurs anonymes. En effet, vous pourriez souhaiter que seuls certains sites soient ouverts à l’accès anonyme mais pas tous. Aussi, sur un site dont vous voulez rendre l’accès anonyme, cliquez sur Actions du site puis Autorisations de site: la page Autorisations du site s’ouvre.
  12. Sur cette page, cliquez sur le bouton du ruban Accès anonyme: la boîte de dialogue Accès anonyme apparaît.
  13. Dans la boîte de dialogue Accès anonyme, sous Les utilisateurs anonymes peuvent accéder à, cliquez sur Tout le site Web puis cliquez sur le bouton OK: une entrée intitulée Utilisateurs anonymes s’affiche sur la page Autorisations.
  14. Il ne vous reste plus qu’à vérifier votre manipulation : accédez au site sans vous identifier afin de vous assurer que l’accès anonyme a été activé avec succès.

Maintenant, le stagiaire n’a plus d’excuses 🙂

SharePoint: Héritage des autorisations

Le modèle de sécurité de SharePoint est basé sur la notion d’héritage. A chaque fois qu’un nouvel objet est créé, il hérite par défaut des autorisations de son parent.

Par exemple, un nouveau site dans une collection de site hérite par défaut des autorisations du site parent. Un sous-site d’un site hérite par défaut des autorisations du site parent. De même, si vous créez une nouvelle bibliothèque dans un site, elle héritera par défaut des autorisations du site.

Un héritage par défaut à tous niveaux

L’héritage est proposé par défaut. Toutefois, à la création d’un objet, vous pouvez demander des autorisations uniques pour que l’objet n’hérite pas des autorisations de son parent.

L’héritage fonctionne en cascade. Les autorisations données sur un site s’appliquent aux sites enfants et aux objets qu’ils contiennent (bibliothèques, listes), ainsi qu’aux enfants des sites enfants, etc. Autrement dit, chaque enfant hérite de son parent, qui hérite lui-même de son parent, etc.

Tant que l’héritage n’est pas rompu, il maintient un lien dynamique avec les autorisations de l’objet du parent. Ce qui signifie que toute modification d’une autorisation du site parent, par exemple, est automatiquement appliquée à tous les objets enfants qui héritent des autorisations.

Si vous voulez modifier des autorisations existants d’un objet enfant, ci celui-ci hérite des autorisations de l’objet parent, il suffit de rompre l’héritage. Lorsque que l’héritage est rompu, les autorisations de l’objet parent sont recopiés sur l’objet enfant sans lien dynamique et les autorisations de l’objet enfant deviennent modifiables.

Un héritage rompu peut être rétabli à chaque instant. Dans ce cas, tous les autorisations existants de l’objet enfant sont perdus.

Différences avec les ACL de NTFS

Ce modèle ressemble à celui mis en oeuvre par Microsoft avec le système de fichiers NTFS (New Technology File System) de Windows. Cependant, il s’en écarte sur de nombreux aspects.

En particulier, dans le modèle de sécurité de SharePoint, il n’est pas possible de rajouter une autorisation lorsque les autorisations sont héritées du parent. Il faut impérativement rompre l’héritage. Au contraire, dans NTFS, il est possible de rajouter une ACE (Access Control Entries) à une ACL (Access Control List) héritée.

Rapidité dans les cas simples

Le principal avantage de ce modèle d’héritage est sa simplicité et sa rapidité, car aucune configuration particulière de sécurité n’est nécessaire. C’est sa force dans les implémentations de SharePoint où la sécurité n’est pas une grande préoccupation.

Les changements à appliquer sont centralisés. Par exemple, vous modifiez les autorisations d’une collection de sites et ils s’appliquent automatiquement à tous les sites enfant.

Ce modèle de sécurité n’est pas toujours maîtrisé par les administrateurs. Les audits de sécurité révèlent deux écueils principaux: trop de droits et pas assez de droits.

Difficultés réelles aussi

Certains administrateurs n’ont pas toujours à l’esprit les conséquences de certaines décisions qui semblent anodines. Cela peut conduire à des situations où certaines informations sensibles enregistrées sur SharePoint peuvent être compromises par inadvertance.

C’est par exemple le cas, lorsque des autorisations de lecture ont été accordées au niveau le plus élevé à un groupe trop large d’utilisateurs.

A l’inverse une politique trop restrictive, ou mal pensée, peut exclure à tort certaines catégories d’utilisateurs (par exemple, les utilisateurs de l’organisation qui se trouvent dans les filiales).

Pour diverses raisons, ils ne voudront pas ou ils ne pourront pas se manifester et ils créeront de toutes pièces un gisement de données « pirate », qui échappera à l’administration générale.

Outils d’administration de la sécurité

A la décharge des administrateurs, il faut reconnaître qu’il n’était pas évident de connaître les autorisations accordées sur un objet d’un simple coup. Toutefois, la situation s’est améliorée avec SharePoint 2013.

Globalement, il y a un manque d’outils natifs pour les administrateurs pour planifier et maintenir les autorisations SharePoint.

Sans qu’il s’agisse d’une recommandation (!), j’ai apprécié des outils de sociétés commerciales comme ceux de Varonis qui permettent d’avoir des rapports d’une grande clarté sur les autorisations accordées.

Pour mémoire, AvePoint qui est un acteur historique de SharePoint propose aussi des outils de gouvernance. Toutefois, je n’ai pas trouvé l’équivalent de Varonis.

Avec une approche différente, TITUS propose une solution intéressante avec l’utilisation de métadonnées pour gérer la sécurité.

Enfin pour les adeptes de l’huile de coude, il y a toujours les scripts gratuits de Gary Lapointe: cmdlets PowerShell et commandes STSADM. Ils permettent de construire une solution complète et évolutive d’analyse de la configuration de sécurité. Cela m’a été utile pour construire un kit personnalisé d’audit de sécurité SharePoint.

Suppression de l’affichage du lien Tout le contenu du site

Le lien Tout le contenu du site s’affiche systématiquement sur toutes les pages des sites SharePoint.

Tout-le-contenu-du-site

Comme son nom l’indique, ce lien affiche le contenu du site. Cela peut entraîner une confusion dans l’esprit des utilisateurs. Il est demandé de le faire disparaître d’un site.

Cette action va être réalisée avec SharePoint Designer.

Lancez SharePoint Designer et ouvrez le site concerné. Vous pouvez aussi faire le contraire.

La première chose à faire est une sauvegarde de la page maître concernée. Dans notre cas, il s’agit de v4.master.
Pages master du site
Faites un clic droit sur v4.master, suivi d’un copier-coller: un fichier v4_copie(1).master est créé. Renommez-le en v4perso.master.

Faites un clic droit dessus: un menu s’ouvre. Dans le menu choisissez l’option Modifier le fichier en mode avancé.

Il y a deux façons pour supprimer l’affichage du lien. Soit l’affichage du lien est supprimé en surchargeant le CSS concerné, soit en supprimant simplement le lien.

Nous allons supprimer le lien. Pour cela, sélectionnez le lien avec la souris:
Sélection du lien Tout le contenu du site dans la master page
Vérifiez que vous avez bien sélectionné uniquement le lien Tout le contenu du site puis appuyez sur le bouton Suppr.

Si vous avez fait une erreur, vous pouvez essayer avec les touches Annulation:
CTRL + Z
Au pire, vous supprimez v4perso.master et vous recommencez sur une nouvelle copie de v4.master.

Si votre modification est faite sans erreur, enregistrez votre page avec les touches de sauvegarde:
CTRL + S
Une fenêtre d’avertissement apparaît. Cliquez sur le bouton Oui.

Pour que votre modification soit prise en compte, il faut indiquer à SharePoint qu’il doit utiliser la page maître v4perso.master par défaut.

Pour cela, allez dans l’onglet Pages maîtres:
Onglet Pages Maitres
Faites un clic droit sur v4perso.master: un menu s’ouvre. Dans le menu choisissez l’option Définir comme page maître par défaut.

Si le navigateur Internet Explorer est ouvert: fermez-le puis rouvrez-le. Allez sur le site modifié:
Lien Tout le contenu du site a disparu
Si tout va bien, fermez SharePoint Designer.

Dans un autre post, vous verrez comment surcharger un élément CSS de SharePoint pour le faire disparaître.

Perte des droits administrateur de la collection de sites

Depuis quelques temps, les utilisateurs se plaignaient de ne plus pouvoir modifier les documents des collections de site. Alors qu’ils travaillaient localement sur des documents extraits (« check-out »), ils n’arrivaient pas toujours à l’archiver (« check-in »).

De même, les administrateurs des collections de site SharePoint perdaient sporadiquement leurs droits. Plus exactement, leurs droits étaient très limités:

Droits administrateur de la ferme-partiels

Au bout de quelques minutes, tout redevenait normal. Toutes les collections de sites de toutes les fermes étaient concernées, y compris une ferme de portée mondiale.

L’audit a mis en évidence le blocage du site grâce à la commande stsadm.exe:
stsadm -o getsitelock -url http://urlsite
Celle-ci rapporta:
<SiteLock Lock= »readonly » />
Les raisons d’un blocage sont souvent liées aux verrouillages des bases de données à cause d’opérations concomitantes. Dans ce cas précis, le problème provenait de la mise en place de sauvegardes systématique des collections de site avec la commande Powershell:
Backup-SPSite
Cette commande était exécutée sans le paramètre -Nositelock. Ce dernier indique que la collection de sites continue d’être accessible en lecture et en écriture durant la sauvegarde. En son absence, selon le paramétrage de l’état de la collection de site, celle-ci est temporairement verrouillée en « lecture seule » durant la sauvegarde. Une fois la sauvegarde terminée, la collection de site revient à son état initial.

Afin de préserver l’intégrité de la sauvegarde, il est recommandé de ne pas utiliser le paramètre -Nositelock.

Le problème a été résolu en changeant l’heure de la sauvegarde. Celle-ci se déroule maintenant à une heure où les utilisateurs mondiaux ne sont pas impactés.

Les administrateurs de la collection de sites ont pu récupérer leurs droits:

Droits administrateur de la ferme-complets

Si vous avez besoin de débloquer en urgence une collection de site, vous pouvez utiliser la commande stsadm:
stsadm -o setsitelock -url http://urlsite -lock none