none
Gestion de droits RRS feed

  • Question

  • Bonjour,

    Je suis entrain de configurer une collection de site avec un ensemble de sites, sous sites. Cet ensemble correspond à l'organigramme de la société.

    J'aimerai donner un accès  au niveau de l'arborescence à tous les utilisateurs authentifiés sur le domaine. De sorte que quelque soit l'utilisateur il puisse voir l'intégralité des sites et sous sites.

    Par contre je ne souhaite pas qu'il puisse voir les documents qui ne sont pas propres à son service.

    Exemple :

    Je fais parti du service Support. J'ai donc les droits collaborateur ou approbateur sur ce site et ses sous sites. Je peux aussi voir tous les autres services (sites) et leur sous site. Par contre je ne peux pas voir leur document.

    - J'ai donc créé un groupe de sécurité en vue seule. Mais rien n'y fait cet utilisateur peut aussi voir les documents des autres services.
    - J'ai alors voulu modifier les niveaux d'authorisation pour aller encore plus bas. Mais tout ce que ca fait, c'est me mettre le message "Accès refusé" au niveau de la collection de site.

    Je cherche donc comment faire pour configurer un groupe de sécurité SharePoint avec les autorisations les plus basses (groupe qui sera hérité sur tous les sites et sous sites de la collection de sites) afin que tous le monde puissent se connecter à la collection de site et voir tous les sites ; et ensuite les utilisateurs auront plus d'accès en se connectant au site correspondant à leur service.

    J'espère avoir été clair.

    Merci à vous,
    lundi 27 avril 2009 14:59

Toutes les réponses

  • Bonjour,

    Vous pourriez, au niveau des bibliothèques de documents qui contiennent les documents à sécuriser, casser l'héritage des droits pour les redéfinir.

    Pour ce faire, allez sur les paramètres de la liste, "Autorisations pour : nom_de_la_liste", "Actions", "Modifier les autorisations". Vous pourrez alors supprimer les droits pour le groupe qui contient authenticated users.

    Il faudra effectuer cette modification pour chaque bibliothèque comportant des documents à sécuriser.

    Est-ce que cette solution vous conviendrait ?


    http://blogs.developpeur.org/anouvel
    lundi 27 avril 2009 15:49
  • Bonjour,

    J'ai appliqué cette solution sur une de mes collections de site. Une fois en production nous avons constaté sur les Workflow (WF par défaut en Approbation) rencontraient des problèmes.

    Après quelques analyses avec notre prestataire et un envoi de la base de donnée au support Microsoft, le message de Microsoft fut clair :

    - Si vous cassez les droits au niveau des bibliothèques, la liste qui reçoit les tâches de flux de travail n'héritera plus des droits de la bibliothèque. La conséquence est que si une personne avec les droits d'approbateur reçoit une demande de validation, elle va voir un beau accès refusé, sur la tâche présente dans la liste des flux de travail.

    Je suis d'accord c'est illogique mais c'est MS qui l'a dit ...

    Donc depuis je ne casse plus les droits sur les bibliothèques ...

    Sinon votre solution était très plaisante :)

    Merci quand même
    lundi 27 avril 2009 15:55
  • La liste des tâches hérite des droits définis au niveau du site, pas des droits définis sur une autre bibliothèque..

    Effectivement c'est illogique. Ca vaudrait peut-être le coup d'essayer quand même et de regarder ce qu'il se passe si on branche un workflow ?

    En tous cas je n'ai jamais constaté ce problème, surtout que l'approbateur est sensé avoir des droits élevés.
    http://blogs.developpeur.org/anouvel
    lundi 27 avril 2009 16:06
  • je comprends bien, nous avions été mal conseillé par notre prestataire et nous sommes parti dans une gestion de droits trop spécifique.

    Bref, je vais essayer votre méthode.

    Je reviens vers vous demain.

    Merci

    lundi 27 avril 2009 16:12
  • Bonjour,

    Alors après avoir vu ce que cela offre, c'est ok dans la visibilité ou non des documents.

    Par contre ça ne me va pas dans mon cas. Car les bibliothèques seront créés par des Designer désignés pour chaque service.

    Donc si je met à disposition un modèle de bibliothèque avec l'héritage cassé, quand les designers vont utilisés ce modèle pour leur site, les droits ne vont pas s'hériter et donc la bibliothèque restera invisible même pour le service ayant les droits.

    Mais merci quand même.

    Une atre idée ?
    mardi 28 avril 2009 07:56
  • Bonjour,

    Un développement est-il envisageable ?
    http://blogs.developpeur.org/anouvel
    mardi 28 avril 2009 08:34
  • Non, nous voulons éviter tout développement additionnel.

    Pour le moment la seule solution que j'ai c'est d'appliquer votre solution mais sur les sites. L'inconvénient est qu'un utilisateur ne pourra pas constater de la présencen des autres services. Il ne verra que son site.

    Si vous n'avez pas de solutions je partirai du principe que votre 1er post était le bon :)
    mardi 28 avril 2009 09:43
  • Sans code, effectivement je ne vois pas comment automatiser ça :s

    Peut-être serait-il possible d'éduquer les utilisateurs pour qu'ils connaissent cette problématique et puissent supprimer les droits aux visiteurs sur les listes contenant des documents ?

    Autre option, utiliser le site du service comme un site de publication pur, et créer pour chaque site de service un sous-site d'équipe qui serait privé et contiendrait les documents.
    http://blogs.developpeur.org/anouvel
    mardi 28 avril 2009 09:47
  • Il faudrait vraiment considérer une solution via du code, celà me paraît plus propre.


    L'idée :

    Déveloper un Job SharePoint quotidien parcours l'aborescence (en utilisant un compte privilégié pour accéder aux données de la colletion). Le Job a pour rôle de noter l'arborescence parcourue dans un fichier XML. Le Job sauvegarde ce fichier dans une biliothèque SharePoint au niveau du site racine. Tous les utilisateurs ont accès en lecture à cette bibliothèque.

    Utiliser la WebPart XML pour accéder aux fichier et indiquer une transformation XSL pour reproduire graphiquement l'organigramme.


    Atouts de la solution :

    Propre
    Performante (pas de données à agréger ni de site à parcourir; le rendu de la transformation XSL peut être mis en cache)
    Paramétrable (Périodicité du Job variable, exécution aux heures creuses si nécessaire, XSL stocké dans une liste, changement de rendu possible sans effectuer de déploiement de composants, ...)

    Je vous encourage vraiment à développer une solution SharePoint réalisant ce genre de choses.


    http://blogs.developpeur.org/gribouillon/
    mercredi 29 avril 2009 22:45
    Modérateur