更新 11/03/08: 请务必阅读优秀和详细的评论 德西埃 Lunsford 这一职位.

我一直秘密科技编辑项目即将书和它引用 这篇博客泰勒巴特勒在 MSDN ECM 的博客. 这是含义的我读过的有限访问权限的明确定义的第一次. 这里是定义的肉:

在 SharePoint 中, 匿名用户’ 由受限访问权限级别确定的权利. 有限的访问权限是不能分配给用户或组直接的特殊权限级别. 它存在的原因是因为如果您的库或子网站，打破了权限继承, 用户/组的访问给库/子, 若要查看其内容, 用户/组必须有一些对根网站的访问. 否则，用户/组将无法浏览库/子网站, 即使他们那儿有权利, 因为有在根网站呈现的站点或库所需的东西. 因此, 当你给只向子网站或打破权限继承的库中的组权限, SharePoint 会自动向向该组或用户的根站点上提供有限的访问.

这一问题出现现在和以后在 MSDN 论坛上，我总是好奇 (但不是好奇，在今天之前出图 :)).

</结束>

订阅我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

在一个社会计算开始起飞与 SharePoint 的标志, 我看到我的网站类型问题的增加的数目. 一个常见的问题是这样:

"我是管理员，我需要能够访问每个我的网站. 我是如何做的?"

这里的窍门是，每个我的网站是其自身的网站集合. 在网站集级别通常管理 SharePoint 安全和这旅行了许多 SharePoint 管理员. 通常, 她已访问"main 中的进行安全配置" 网站集和可能没有意识到这并不会自动工作我的网站.

站点集合集体住在一个大容器内, 这是 web 应用程序. 农场管理员可以可以在 web 应用程序级别配置安全，这是如何访问到任何 web 应用程序中的网站集管理员可以授予自己. 此博客条目描述了一个我个人的经验与 web 应用程序策略. 我由事故定义 web 应用程序策略: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Web 应用程序策略可以是危险的我建议他们要慎用. 如果我是管理员 (谢天谢地我不), 我将创建一个单独的 AD 帐户命名为类似"SharePoint Web 应用程序管理员" 它需要的 web 应用程序安全角色的那一个交代. 我不会配置这种事情经常农场管理员或单个站点集合管理员. 它将倾向于隐瞒潜在的问题，因为 web 应用程序角色将覆盖任何较低级别的安全设置.

</结束>

订阅我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

更新 (02/29/08): 这个新的 codeplex 项目似乎要提供一种方法确保单个列: http://www.codeplex.com/SPListDisplaySetting. 如果您有任何与它合作的经验, 请留下评论.

论坛海报经常问这样的问题: "我有一个管理器视图和工作人员的列表的视图. 如何，工作人员不能使用它安全的管理器视图?"

他们还经常问的一个相关的问题: "我想要保护的特定元数据的列，以便只有经理可以编辑该列，虽然其他人可能不甚至看到它。"

这些答案适用于这两个 WSS 3.0 和苔藓:

• SharePoint 不提供出框支持争取意见.
• SharePoint 不安全列提供出框支持.

有几种技术一可以按照满足这些类的安全要求. 这里是我能想到的:

• 使用预置的项目级安全. 意见总是荣誉项目级安全配置. 事件接收器和/或工作流可以自动执行安全任务.
• 使用的个人视图为"特权" 视图. 这些都是容易设置. 不过, 由于其"个人" 性质, 这些需要为每个用户配置. 使用标准安全配置，以防止别人从创建个人视图.
• 使用数据视图 web 部件并实现某种 AJAXy 安全修整解决方案.
• 卷您自己的列表显示功能和纳入列级安全修整.
• 修改数据输入窗体并使用 JavaScript 安全模型结合实现列级安全修整.
• 使用 InfoPath 窗体输入数据. 实现通过 web 服务调用到 SharePoint 和有条件地隐藏字段所需的列级安全修整.
• 卷自己的 ASP.NET 数据条目函数实现列级安全修整.

这些选项均没那么好, 但有至少一条路径，如果您需要遵循, 即使很难.

请注意: 如果你去这些路径的任何, 别忘了"行动-> 打开 Windows 资源管理器". 你要确保你使用该功能以确保它不会作为一个"后门工作测试" 和击败你的安全计划.

如果你有其他的想法或者经验与确保列或视图, 请 电子邮件通知我 或请留言，我会更新此作为适当的过帐.

</结束>

订阅我的博客.

更新: 我发布这一问题到 MSDN 在这里 (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) Michael Washam 的微软用一个简明的答案进行了回击.

创建 web 服务，以作为 BDC 便利门面 到 SharePoint 列表. 当我用这个从我的开发环境, 它能正常工作. 当我这迁移到新的服务器, 我遇到这个错误:

这里是行 69:

使用 (SPSite 站点 = 新 SPSite("http://localhost/sandbox"))

尝试了不同的 url 的变异, 包括使用服务器的真实姓名, 它的 IP 地址, 在 URL 上斜线结尾, 等. 我总是得到该错误.

我用 谷歌 它的研究. 很多人面临着这个问题, 或它的变化, 但似乎没有人出钱解决.

恶作剧的; 苔藓提供详细错误，没想到我要检查 12 蜂巢日志. 最终, 关于 24 小时后 我的同事 建议我这样做, 我查了一下 12 蜂巢日志，发现了这个:

尝试获取本地农场时出现异常:
System.Security.SecurityException: 不允许请求的注册表访问.
在 System.ThrowHelper.ThrowSecurityException(ExceptionResource 资源) 在 Microsoft.Win32.RegistryKey.OpenSubKey(字符串名称, 布尔值可写) 在 Microsoft.Win32.RegistryKey.OpenSubKey(字符串名称) 在 Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() 在 Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() 在 Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& 农场, 布尔值& 种矛盾又掺杂)
失败的程序集的区域是:  我的电脑

这开辟了新途径的研究, 所以它又回到了谷歌. 我被引到这 论坛帖子: http://forums.codecharge.com/posts.php?post_id = 67135. 这真的帮不了我，但它确实开始让我觉得那里是一个数据库和/或安全的问题. 我受尽折磨和 安德鲁 · 康奈尔 最后触发后说我要确保应用程序池标识帐户有权访问数据库的思想. 我以为它已经打了. 不过, 我的同事去和给 SQL 应用程序池标识帐户完全访问.

为她做了这种变化, 一切都开始工作.

下面发生的事情是最好的表示为 俳句 诗:

问题举手.
你摆动和小姐. 再试一次.
成功! 但如何? 为什么?

她并不想这样独自一人离开的事情, 更倾向于给最低所需的权限 (可能着眼写博客条目; 毒打冲到, muhahahahaha!).

她从应用程序池标识帐户之前删除连续的权限 … 已不再有任何显式权限的应用程序池标识帐户在所有. Web 服务继续工作得很好.

我们去和重新启动服务器. 一切继续做工精细.

所以, 重述一遍: 我们给应用程序池标识完全访问权限，然后把它拿走了. Web 服务开始工作，永远不会停止工作. 奇怪.

如果有人知道为什么应该会起作用, 请留下评论.

</结束>

我需要满足今天为 InfoPath 表单的安全要求. 在这种业务情况, 大量相对较小的个人允许创建新的 InfoPath 表单和更广泛的受众允许对其进行编辑. (这是新员工上寄宿形式使用的人力资源，启动工作流).

为了达到这一目标, 我创建了创建两个新的权限级别 ("创建和更新" 和"只更新"), 打破了继承的窗体库和分配权限的一个"创建, 更新" 用户和一个单独的"仅更新" 用户. 力学所有工作, 但事实证明要比我预期的多一点涉及. (如果你感到势单力薄了 SharePoint 权限, 签出此博客文章). 所需的安全配置权限级别是不明显的细粒度的权限集. 若要创建 InfoPath 表单仅更新权限级别, 我做了以下:

1. 创建新的权限级别.
2. 清除所有选项.
3. 选择只有以下从"列表权限"权限:

• 编辑项目
• 查看项目
• 查看应用程序页面

选择这些选项允许用户更新窗体, 但不是会创造.

诀窍就是使"视图应用程序页". 在权限级别指示了所需的更新仅 InfoPath 表单上没有任何 verbage, 但轮出它是.

创建和更新了甚至陌生人. 同样的步骤, 1 通过 3 以上. 我不得不专门添加"网站权限" 选项: "使用客户端集成功能". 再次, 那里的描述并不使它看起来应该是需要为 InfoPath 表单, 但它在有.

</结束>

更新 01/28/08: 此 codeplex 项目解决了这个问题: http://www.codeplex.com/AccessChecker. 我没有用它, 但它看起来很有希望的如果这是您的环境中需要解决的问题.

更新 11/13/08: 乔尔 · 奥尔森在这里更大的安全管理问题上写了一个很好的职位: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?列表 = 0cd1a63d-183c-4fc2 %2 D 8320 -ba5369008acb&ID = 113. 它链接到其它有用的资源数目.

论坛用户和客户常常问沿这些线: "我如何生成具有访问站点的所有用户的列表" 或者"如何可以我自动警报与访问有关对列表的更改列表的所有用户?"

现成的解决方案为此没有出去. 如果你想一想了一会儿, 不难理解为什么.

SharePoint 安全是非常灵活. 有的用户至少四个主要类别:

• 匿名用户.
• SharePoint 用户和组.
• 活动目录用户.
• 基于表单的身份验证 (FBA) 用户.

灵活性意味着，从安全的角度, 任何给定的 SharePoint 站点将大大不同于另一个. 为了生成访问列表报告, 要确定如何保护该站点的安全, 查询多个不同的用户配置文件存储库，然后呈现一种有用的方式. 这是一个难的问题，要解决一般.

组织如何处理这? 我很乐意听到您的意见或 电子邮件.

</结束>

更新 12/18/07: 请参阅删除或修改默认的组名的一些技术的后果 Paul Liebrand 文章 (见他下面的评论以及).

概述:

SharePoint 安全是易于配置和管理. 不过, 它已被证明是真的包装他们的手在它附近一些第一次管理员难以. 不只如此, 我见过一些管理员来到一个完美的理解，在周一只把它丢了周五因为他们没有做任何配置在这段时间. (我承认对这一问题我自己). 这篇博客希望提供一个有用的 SharePoint 安全引子和指向一些安全配置的最佳实践.

重要说明:

这种描述基于开箱即用 SharePoint 安全. 我个人的经验被面向各地苔藓，所以可能会有一些苔藓的具体东西在这里, 但我相信它是准确的 WSS. 我希望看到的任何错误或遗漏的任何人都将点，在评论中或 电子邮件通知我. 我会改正后匆忙.

基础知识:

为施行本概述, 有四个基本方面对安全: 用户/用户组, 安全对象, 权限级别和继承.

用户和组 打破降到:

• 个人用户: 从活动目录或创建在 SharePoint 中直接拉.
• 团体: 从 active directory 直接映射或在创建 SharePoint. 组是用户的集合. 组是全球化的站点集合中. 他们永远不会"绑" 到特定的安全对象.

安全对象 打破降到最少:

• 网站
• 文档库
• 列表和文档库中的各个项
• 文件夹
• 各种 BDC 设置.

那里其他安全对象, 但是你图片.

权限级别: 捆绑的颗粒 / 在列表中包含诸如创建/读取/删除条目的低级别的访问权限.

继承: 默认情况下从其包含的对象实体继承安全设置. 子网站从其父项继承权限. 继承他们网站的文档库. 等等等等等等.

涉及通过继承和权限级别的安全对象的用户和组.

最重要的安全规则，来理解, Ever 🙂 :

1. 组是简单的用户的集合.
2. 组是全球网站集内 (e 小节. 没有这种东西在站点级别上定义的一个组).
3. 不耐的组名称, 团体却不, 本身, 有任何特定的安全水平.
4. 组在某一特定的安全对象的上下文中具有安全.
5. 可将不同的权限级别分配给每个安全对象的同一组.
6. Web 应用程序策略胜过所有这一切 (请参阅下面的).

安全管理员迷失在海上的组和用户列表可以始终依靠这些公理来管理和了解他们的安全配置.

常见的陷阱:

• 组名虚假地暗示的权限: 开箱即用, SharePoint 定义一组组名字暗示了固有的安全级别. 考虑"参与者"组. 一个熟悉 SharePoint 安全性可能会看看那名字，假设，那组的任何成员可以"作出贡献" 对任何网站/列表/库在门户中. 这可能是真的，但并不是因为该集团的名字恰巧是"讨论参与者". 这是唯一真正开箱即用，因为该集团提供了权限级别，使它们能在根站点添加/编辑/删除内容. 通过继承, "参与者" 集团也可能在每个分站点添加/编辑/删除内容. 一个可以"打破" 继承链和更改权限级别的子站点这种所谓的"参与者的成员" 组不能作出贡献, 但只读取 (例如). 这不会是一个好主意, 很明显, 因为它将是非常令人困惑.
• 组不在站点级别定义. 它很容易被混淆的用户界面. Microsoft 提供了方便的链接到用户/组管理通过每个站点的"人和组" 链接. 很容易相信，当我在网站"xyzzy" 我创建一个组通过 xyzzy 的人和团体联系起来，我只是在 xyzzy 创建只存在一组. 这不是个案. 我实际上已经创造了一群为整个网站集.
• 组成员资格不会由站点不同 (e 小节. 它是一样到处都使用组): 考虑"所有者组" 和两个站点, "HR" 和"物流". 它会正常想两个独立的个体将会拥有这些网站 — HR 所有者和物流所有者. 用户界面轻松安全管理员责难这种情况下. 如果我不知道更好, 我可能会访问的用户和用户组的链接，通过人力资源网站, 选择"业主" 组并向该组添加我的 HR 主人. 一个月后, 物流上线. 访问从物流站点中的用户和用户组, 添加"业主拉起" 集团. 我看到那里 HR 所有者和删除她, 我在消除她从所有者在物流网站的思考. 事实上, 我在消除她从全球的所有者组. 接着而来的欢乐.
• 对基于特定的角色的名称组失败: "审批者" 组是一个完美的例子. 什么可以这组批准成员? 他们在那里能批准它? 我真的想人物流部门能够批准人事相关文件吗? 当然不是. 始终命名组基于其在组织内的角色. 这将减少风险的组分配特定的安全对象所需的权限级别. 基于其预期角色名称组. 在前面的 HR/物流场景, 我应创建两个新的组: "HR 业主" 与"物流业主" 和分配每个明智的权限级别和对这些用户做他们的工作所需的最低金额.

其他有用的引用:

• Web 应用程序的政策地方: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• SharePoint 安全信息中心: http://www.sharepointsecurity.com/
• 乔尔 · 奥尔森的链接: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

如果您做了它这远:

请让我知道你的想法通过评论或给我发电子邮件. 如果你知道其他有益的参考, 请这样做!