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.