MISE À JOUR 11/03/08: N'oubliez pas de lire le commentaire excellent et détaillé du Dessie Lunsford à ce poste.

J'ai travaillé sur un projet de montage tech secret pour un livre à venir et qu'il référence Cette entrée de blog par Tyler Butler sur le blog MSDN ECM. Il s'agit de la première fois que j'ai personnellement lu une définition claire de la signification de l'accès limité. Voici la viande de la définition:

Dans SharePoint, utilisateurs anonymes’ les droits sont déterminés par le niveau d'autorisation accès limité. Accès limité est un niveau d'autorisation spéciale qui ne peut pas être assigné à un utilisateur ou un groupe directement. La raison qu'il existe est que si vous avez une bibliothèque ou un sous-site qui a brisé d'héritage des autorisations, et vous donner un accès utilisateur ou groupe à seulement cette bibliothèque/sous-site, afin d'afficher son contenu, l'utilisateur ou le groupe doit avoir un accès au web racine. Sinon l'utilisateur/groupe sera incapable de parcourir la bibliothèque/sous-site, même s'ils ont des droits y, parce qu'il y a dans le site web racine des choses qui sont nécessaires pour rendre le site ou une bibliothèque. Donc, Lorsque vous accordez des autorisations de groupe uniquement pour un sous-site ou la bibliothèque qui est casser l'héritage des autorisations, SharePoint donnera automatiquement un accès limité à ce groupe ou un utilisateur sur le site web racine.

Cette question revient de temps en temps sur les forums MSDN et j'ai toujours été curieux (mais pas assez curieux pour elle figure out avant aujourd'hui :)).

</fin>

S'abonner à mon blog.

Me suivre sur Twitter à http://www.twitter.com/pagalvin

Dans un signe que le Social Computing commence à décoller avec SharePoint, Je vois un nombre croissant de questions de type de sites Mon Site. Une question commune va quelque chose comme ça:

"Je suis administrateur et j'ai besoin de pouvoir accéder à tout mon Site. Comment je fais que?"

L'astuce ici est que chaque Site My est sa propre collection de sites. Sécurité de SharePoint est normalement administrée au niveau collection de sites et cela déclenche un grand nombre un administrateur SharePoint. Normalement, Elle a déjà accès à configurer la sécurité à la main »" collections du site et ne peuvent pas se rendre compte que cela ne fonctionne pas automatiquement pour mes Sites.

Collections de sites vivent collectivement à l'intérieur d'un contenant plus grand, qui est l'application web. Administrateurs de batterie de serveurs peut peut configurer la sécurité au niveau de l'application web et c'est comment admins peuvent s'accorder l'accès à toute collection de sites dans l'application web. Ce blog décrit l'un des mes expériences personnelles avec les stratégies d'application web. J'ai défini une stratégie d'application web par hasard: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Stratégies d'application Web peuvent être dangereux, et je suggère qu'ils être utilisés avec parcimonie. Si j'étais un admin (et Dieu merci je ne suis pas), Je créerais un compte AD distinct nommé quelque chose comme « SharePoint Web application administrateur" et donner qu'un seul compte le rôle de sécurité application web qu'il a besoin. Je ne serait pas configurer ce genre de chose pour l'admin ferme ordinaire ou les administrateurs de collection de sites individuels. Il aura tendance à masquer les problèmes potentiels, car le rôle de web app substitue les paramètres de sécurité de niveau inférieurs.

</fin>

S'abonner à mon blog.

Me suivre sur Twitter à http://www.twitter.com/pagalvin

MISE À JOUR (02/29/08): Ce nouveau projet codeplex semble fournir une méthode de fixation des colonnes individuelles: http://www.codeplex.com/SPListDisplaySetting. Si vous avez aucune expérience de travail avec elle, Veuillez laisser un commentaire.

Affiches Forum souvent poser une question comme ça: "J'ai une vision gestionnaire et et un affichage personnel d'une liste. Comment est-ce que j'ai sécuriser la vue gestionnaire afin que le personnel ne peut pas l'utiliser?"

Ils demandent aussi souvent une question connexe: "Je veux obtenir une colonne de métadonnées spécifiques afin que seuls les gestionnaires peuvent modifier cette colonne tandis que d'autres ne peuvent même pas le voir."

Ces réponses s'appliquent à ces deux WSS 3.0 et point de riz:

• SharePoint ne fournit pas de soutien d'out-of-the-box pour obtenir des vues.
• SharePoint ne fournit pas de soutien d'out-of-the-box pour les colonnes de sécurité.

Il existe plusieurs techniques un peuvent suivre pour répondre à ce genre d'exigences de sécurité. Voici ce que je peux penser:

• Utilisez la sécurité au niveau élément out-of-the-box. Vues honorent toujours la configuration de la sécurité au niveau élément. Récepteurs d'événements ou de flux de travail peut automatiser la cession de sécurité.
• L'utilisation de vues personnelles pour « le privilège" Affichage. Celles-ci sont assez faciles à mettre en place. Cependant, en raison de leur personnel"" nature, ceux-ci doivent être configurés pour chaque utilisateur. Utilisez la configuration de sécurité standard pour empêcher quiconque de créer une vision personnelle.
• Utiliser un composant WebPart Affichage de données et de mettre en place une sorte de solution de sécurité AJAXy parage.
• Rouler vos propres fonctionnalités d'affichage de liste et incorporer l'ajustement de la sécurité au niveau de la colonne.
• Modifier les formulaires de saisie de données et utiliser JavaScript avec le modèle de sécurité à mettre en œuvre de la suppression de la sécurité au niveau des colonnes.
• Utiliser un formulaire InfoPath pour saisie de données. Mise en œuvre de la suppression de la sécurité au niveau des colonnes via des appels de service web SharePoint et conditionnellement masquer champs selon les besoins.
• Rouler votre propre fonction d'entrée de données ASP.NET qui implémente le filtrage de sécurité niveau de colonne.

Aucune de ces options sont vraiment terrible, mais il n'y a au moins une voie à suivre si vous devez, même si c'est dur.

NOTE: Si vous descendez un de ces chemins, n'oubliez pas "Actions-> Ouvrir avec l'Explorateur Windows". Vous voulez être sûr que vous testiez avec cette fonctionnalité pour vous assurer que cela ne fonctionne pas comme une « porte dérobée" et vaincre votre régime de sécurité.

Si vous avez d'autres idées ou expériences avec sécurisation des colonnes ou des vues, s'il vous plaît Ecrivez-moi ou laissez un commentaire et je vais mettre à jour de cette annonce, le cas échéant.

</fin>

S'abonner à mon blog.

MISE À JOUR: J'ai posté cette question à MSDN ici (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) et Michael Washam de Microsoft a répondu avec une réponse concise.

J'ai créé un service web d'agir comme un Façade de la BDC-facile vers une liste SharePoint. Quand j'ai utilisé cela de mon environnement de développement, il fonctionnait bien. Quand j'ai migré ce vers un nouveau serveur, J'ai rencontré cette erreur:

Voici la ligne 69:

à l'aide de (Site SPSite = nouveau SPSite("http://localhost/sandbox"))

J'ai essayé différentes variations sur l'URL, y compris en utilisant le nom réel du serveur, son adresse IP, les barres obliques sur l'URL, etc.. J'ai toujours eu cette erreur.

J'ai utilisé Le Google pour une recherche. Beaucoup de gens font face à ce problème, ou des variantes de celui-ci, mais personne ne semblait avoir résolu.

MOSS tricksy fourni une telle détaillée erreur qu'il n'a pas lieu pour moi de vérifier la 12 journaux de la ruche. Par la suite, sur 24 heures après mon collègue Je le fais a recommandé, J'ai vérifié la 12 Journal de la ruche et trouvé ceci:

Une exception s'est produite alors qu'il tentait d'acquérir la batterie locale:
System.Security.SecurityException: Accès au Registre demandé n'est pas autorisé.
à System.ThrowHelper.ThrowSecurityException(Ressources ExceptionResource) à Microsoft.Win32.RegistryKey.OpenSubKey(Nom de chaîne, Boolean en écriture) à Microsoft.Win32.RegistryKey.OpenSubKey(Nom de chaîne) à Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() à Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() à Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& ferme, Boolean& isJoined)
La Zone de l'assembly qui a échoué était:  Poste de travail

Cela ouvre de nouvelles pistes de recherche, il était donc retour de The Google. Cela m'a conduit à cette post sur le Forum: http://forums.CodeCharge.com/posts.php?post_id = 67135. Qui n'a pas vraiment m'aider mais il n'a démarré me fait penser qu'il y avait un problème de base de données et/ou de sécurité. J'ai persévéré et De Andrew Connell poster finalement déclenchée la pensée que je devrais faire en sorte que le compte d'identité du pool d'applications avait accès à la base de données. J'ai pensé que c'était déjà le cas. Cependant, mon collègue est allé et a donné l'app pool identité compte un accès complet à SQL.

Dès qu'elle a fait ce changement, tout a commencé à travailler.

Ce que ce fut le cas suivant est le mieux exprimé comme un haïku poème:

Problèmes lèvent leurs mains.
Vous swing et miss. Réessayez.
Succès! Mais comment? Pourquoi?

Elle ne voulait pas laisser les choses tranquilles comme ça, préférant se donner la permission requise minimale (et sans doute dans une optique d'écrire une entrée de blog; J'ai battue pour le punch, muhahahahaha!).

Elle enlève les autorisations successives sur le compte d'identité de pool app jusqu'en … Il n'existait plus aucune autorisation explicite pour le compte d'identité du pool application à tous les. Le service web a continué à fonctionner parfaitement.

Nous sommes allés et redémarré les serveurs. Tout a continué à fonctionner correctement.

Si, pour récapituler: Nous avons donné l'accès complet de l'identité app pool et puis il a enlevé. Le service web a commencé à travailler et jamais cessé de travailler. Bizarre.

Si quelqu'un sait pourquoi qui ont travaillé, Veuillez laisser un commentaire.

</fin>

J'avais besoin de satisfaire à une exigence de sécurité pour un formulaire InfoPath aujourd'hui. Dans cette situation de l'entreprise, un nombre relativement restreint d'individus est autorisé à créer un formulaire InfoPath et un plus large public sont autorisés à le modifier. (C'est nouveau-location on-boarding forme utilisée par les ressources humaines qui lance un flux de travail).

Pour atteindre cet objectif, J'ai créé créé deux nouveaux niveaux d'autorisation ("créer et mettre à jour" et « mettre à jour uniquement »), a brisé l'héritage pour la bibliothèque de formulaires et autorisations à un « créer, mise à jour" utilisateur et une "mise à jour séparée seulement" utilisateur. Les mécaniciens ont travaillé, mais il s'est avéré pour être un peu plus impliquant que je m'attendais. (Si vous vous sentez un peu Tremblant sur les autorisations SharePoint, Découvrez ce post de blog). La configuration de sécurité requise pour le niveau d'autorisation n'était pas le jeu évident d'autorisations granulaires. Pour créer un niveau d'autorisation de mise à jour uniquement pour un formulaire InfoPath, J'ai fait ce qui suit:

1. Créer un nouveau niveau d'autorisation.
2. Nettoient toutes options.
3. Sélectionné uniquement les éléments suivants de « Autorisations de liste »:

• Modifier les éléments
• Afficher les éléments
• Voir les Pages d'Application

Sélection de ces options vous permet de mettre à jour un formulaire, mais pas le créer.

Le truc était de permettre à la « vue les Pages d'Application ». Il n'est pas n'importe quel verbage sur le niveau d'autorisation qui indique qu'il faut pour la seule mise à jour des formulaires InfoPath, mais s'il est.

Créer-et-mise à jour a été encore plus étrange. J'ai suivi les mêmes étapes, 1 par le biais 3 au-dessus de. J'ai dû ajouter expressément une autorisation de Site"" option: « Utiliser les fonctionnalités d'intégration du client ». Encore une fois, la description il n'en fait pas semble pas comme il devrait être obligatoire pour un formulaire InfoPath, mais là c'est.

</fin>

MISE À JOUR 01/28/08: Ce projet codeplex aborde cette question: http://www.codeplex.com/AccessChecker. Je le n'ai pas utilisé, mais il semble prometteur, il s'agit d'une question, que vous avez besoin de l'adresse dans votre environnement.

MISE À JOUR 11/13/08: Joel Oleson a écrit un très bon poste sur la plus grande sécurité gestion question ici: http://www.sharepointjoel.com/lists/posts/post.aspx?Liste = 0cd1a63d % 2D183c % 2D4fc2 % 2 D 8320 % 2Dba5369008acb&ID = 113. Liens vers un certain nombre d'autres ressources utiles.

Les clients et les utilisateurs du forum demandent souvent une question dans ce sens: "Comment générer une liste de tous les utilisateurs ayant accès à un site" ou "Comment peux j'ai alerter automatiquement tous les utilisateurs ayant accès à la liste sur les modifications apportées à la liste?"

Il n'y a aucune sortie de la solution de la boîte pour cela. Si vous y réfléchissez un instant, Il n'est pas difficile de comprendre pourquoi.

Sécurité de SharePoint est très flexible. Il y a au moins quatre grandes catégories d'utilisateurs:

• Utilisateurs anonymes.
• Groupes et des utilisateurs SharePoint.
• Utilisateurs Active Directory.
• L'authentification basée sur les formulaires (FBA) utilisateurs.

La flexibilité signifie que dans une perspective de sécurité, n'importe quel site SharePoint donné sera très différent de l'autre. Afin de générer un rapport de liste d'accès, On a besoin déterminer comment le site est sécurisé, interroger plusieurs référentiels de profil utilisateur différent et présentez-le ensuite de manière utile. C'est un problème difficile à résoudre de manière générique.

Comment les organisations sont face à cela? Je serais ravi de vous entendre dans les commentaires ou Messagerie.

</fin>

MISE À JOUR 12/18/07: Voir l'article de Paul Liebrand pour certaines conséquences techniques de supprimer ou de modifier les noms de groupe par défaut (voir son commentaire ci-dessous ainsi).

Vue d'ensemble:

Sécurité de SharePoint est facile à configurer et à gérer. Cependant, Il s'est avéré difficile pour les nouveaux administrateurs à vraiment envelopper les mains autour d'elle. Non seulement cela, J'ai vu certains administrateurs de parvenir à une compréhension parfaite lundi seulement pour avoir perdu en vendredi parce qu'ils n'ont pas à faire n'importe quelle configuration dans l'intervalle. (J'avoue avoir ce problème moi-même). Cette entrée de blog, j'espère que fournit une amorce de sécurité SharePoint utile et est orientée vers des meilleures pratiques de configuration de sécurité.

Remarque importante:

Cette description est issue hors de la zone de sécurité de SharePoint. Mon expérience personnelle est orienté autour de MOSS donc il peut y avoir des trucs spécifiques MOSS ici, mais je crois que c'est exact pour WSS. J'espère que quelqu'un voyant toute erreur ou omission sera signaler dans les commentaires ou Ecrivez-moi. Je vais faire des corrections post hâte.

Principes de base:

Aux fins de cette vue d'ensemble, Il y a quatre aspects fondamentaux de la sécurité: utilisateurs/groupes, objets sécurisables, héritage et niveaux d'autorisation.

Utilisateurs et groupes break down to:

• Utilisateurs individuels: Tiré d'active directory ou créés directement dans SharePoint.
• Groupes: Directement mappé d'active directory ou créé dans SharePoint. Les groupes sont une collection d'utilisateurs. Les groupes sont mondiaux dans une collection de sites. Ils sont jamais "liés" pour un objet sécurisable spécifique.

Objets sécurisables pause au moins:

• Sites
• Bibliothèques de documents
• Éléments individuels dans les listes et les bibliothèques de documents
• Dossiers
• Divers paramètres de BDC.

Il autres objets sécurisables, mais vous obtenez l'image.

Niveaux d'autorisation: Un faisceau de granulaire / droits d'accès de bas niveau qui incluent des choses comme créer/lire/effacer les entrées dans les listes.

Héritage: Par défaut des entités héritent des paramètres de sécurité de leur objet conteneur. Sous-sites héritent de l'autorisation de leur parent. Bibliothèques de documents héritent de leur site. Ainsi de suite, etc..

Les utilisateurs et les groupes se rapportent à des objets sécurisables via les niveaux d'autorisation et d'héritage.

Règles de sécurité les plus importantes à comprendre, Jamais 🙂 :

1. Les groupes sont tout simplement des collections d'utilisateurs.
2. Les groupes sont globales au sein d'une collection de sites (i.e. Il n'y a rien de tel qu'un groupe défini à un niveau de site).
3. Nom du groupe ne pas résister, groupes ne, dans et d'eux-mêmes, avoir un niveau particulier de sécurité.
4. Les groupes ont la sécurité dans le contexte d'un objet sécurisable spécifique.
5. Vous peut attribuer des niveaux d'autorisation différents pour le même groupe pour chaque objet sécurisable.
6. Stratégies d'application Web l'emporte sur tout cela (voir ci-dessous).

Les administrateurs de sécurité perdus dans une mer de listes d'utilisateurs et de groupes peuvent toujours compter sur ces axiomes de gérer et de comprendre leur configuration de la sécurité.

Pièges:

• Noms de groupe impliquent faussement la permission: Out of the box, SharePoint définit un ensemble de groupes dont les noms impliquent un niveau inhérent de sécurité. Considérons le groupe « Contributeur ». Un peu familier avec sécurité SharePoint peut bien regarder ce nom et supposer que n'importe quel membre de ce groupe peut "contribuer" à n'importe quel site/liste/bibliothèque dans le portail. C'est peut-être vrai mais pas parce que le nom du groupe se trouve être « contributeur ». Ceci n'est vrai out of the box parce que le groupe a bénéficié d'un niveau d'autorisation qui leur permet d'ajouter/modifier/supprimer des contenus à la racine du site. Par héritage, les contributeurs »" groupe peut également ajouter/modifier/supprimer contenu à chaque sous-site. On peut "casser" la chaîne d'héritage et le changement du niveau d'autorisation d'un sous-site que les membres de la soi-disant « contributeur" groupe ne peuvent pas contribuer à tous les, mais seulement lire (par exemple). Ce ne serait pas une bonne idée, de toute évidence, car il serait très confuse.
• Les groupes ne sont pas définis à un niveau de site. Il est facile de confondre par l'interface utilisateur. Microsoft fournit un lien pratique vers gestion utilisateur/groupe par l'intermédiaire "de personnes et de groupes de chaque site" lien. Il est facile de croire que quand je suis au site "xyzzy" et j'ai créer un groupe par le biais personnes de xyzzy et groupes lien que je viens de créer un groupe qui existe seulement à xyzzy. Ce n'est pas le cas. J'ai effectivement créé un groupe pour la collecte de l'ensemble du site.
• Appartenance à des groupes ne varie pas par site (i.e. C'est le même partout où que le groupe est utilisé): Considérons le groupe propriétaire »" et deux sites, « HR" et « Logistique ». Il serait normal de penser que deux personnes différentes détiendrait ces sites — un propriétaire de HR et propriétaire d'une logistique. L'interface utilisateur, il est facile pour un administrateur de sécurité à altérer ce scénario. Si je ne savais pas mieux, Je pourrais accéder les personnes et les groupes liens via le site RH, Sélectionnez les propriétaires"" groupe et ajouter mon propriétaire HR à ce groupe. Un mois plus tard, Logistique est en ligne. J'ai accéder des personnes et des groupes depuis le site de logistique, ajouter pull up les propriétaires"" Groupe. Je vois le propriétaire HR là et lui enlever, pensant que je suis lui retirer propriétaires sur le site de logistique. En fait, Je suis lui retirer le groupe global des propriétaires. Hilarité s'ensuit.
• Négliger de nom basé sur le rôle spécifique des groupes: Les approbateurs"" groupe est un parfait exemple. Ce qui peut les membres de cette approbation de groupe? Où est-ce qu'ils peuvent approuver il? Ai-je vraiment envie département logistique personnes pour pouvoir approuver des documents RH? Bien sûr que non. Toujours nommer des groupes fondées sur leur rôle au sein de l'Organisation. Cela permettra de réduire le risque que le groupe est assigné un niveau d'autorisation inappropriés pour un objet sécurisable particulier. Nommer des groupes fondées sur leur rôle. Dans le scénario précédent de HR/logistique, Je devrais avoir créé deux nouveaux groupes: « Les propriétaires des ressources humaines" « les propriétaires de logistique et" et attribuer des niveaux d'autorisation raisonnable pour chacun et le montant minimal requis pour les utilisateurs de faire leur travail.

Autres références utiles:

• Web application politique piège n: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Centre d'information pour la sécurité de SharePoint: http://www.sharepointsecurity.com/
• Liens de Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Si vous avez fait il ce bien:

S'il vous plaît laissez-moi savoir votre opinion via les commentaires ou à m'envoyer un email. Si vous connaissez d'autres bonnes références, Veuillez faire de même!