添加新组 - 拒绝访问错误

Question

我们有一个非常奇怪的问题。

我的用户ID是一个服务器场管理员，它是相关网站上的网站集管理员。

如果我添加一个新组（以管理权限），一旦我点击创建组页面上的确定按钮，我就会被抛到错误：拒绝访问页面。

这是奇怪的部分， 组被创建 。

如果我尝试将用户添加到该组，我会收到拒绝访问权限的页面，但该用户未被放入该组。

如果我尝试删除该组，我会收到一个错误页面，上面写着无法完成此操作。请再试一次。

它似乎只发生在这一个网站（及其子网站）上。

任何共享点日志或事件日志中都没有任何内容。

它必须是一个许可问题，但我不知道是什么。

编辑------------------------------------编辑

经过一些研究后，我发现了this BLOG post。它声明了一个.NET 2.0 修补程序是问题的罪魁祸首，并指出删除它将解决问题。

我无法删除此修补程序，因为它未安装。

我们注定要遇到这个问题吗？

结束编辑

Answer 1

听起来好像_layouts中的一个系统页面上有一个古怪的权限。在尝试添加/删除组时，在IIS日志（不是SharePoint日志）中查找用户的401,403或407（或实际上任何高于400的HTTP代码）错误。这可能指向出现问题的页面，这将为您提供一些内容。

Answer 2

如果您将共享点Web应用程序托管在IIS / SP使用的默认位置以外的某个位置;检查以确保Users组已读取受影响的应用程序的Bin目录。出于某种原因，在创建此特定应用程序时，无法将User组添加到Bin目录中，而正常情况下通常会使用Read。这很容易测试并且失败并且一致性成功。我唯一注意到它受影响的是通过Sharepoint站点GUI将新用户添加到站点的问题。

这是挖掘我的SP日志时收到的错误：

访问/_layouts/aclinv.aspx时出现应用程序错误，错误=拒绝访问路径'D：\ ProdSites \ SP-ProdSites ***** \ bin'。在System.IO。上的System.IO .__ Error.WinIOError（Int32 errorCode，String maybeFullPath）System.IO.DirectoryInfo.GetFiles的System.IO.Directory.InternalGetFileDirectoryNames（String path，String userPathOriginal，String searchPattern，Boolean includeFiles，Boolean includeDirs，SearchOption searchOption） （String searchPattern，SearchOption searchOption）位于System.Web上的System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory（）中的System.IO.DirectoryInfo.GetFiles（String searchPattern），位于System.Web的System.Web.Configuration.CompilationSection.LoadAssembly（AssemblyInfo ai）。 Configuration.AssemblyInfo.get_AssemblyInternal（）at ...

这是我在IIS日志中显示的错误：

2009-09-09 13:48:19 W3SVC1237373898 IP GET /OOD/_layouts/aclinv.aspx GroupId = 9＆amp; Source = http％INFO2Fpeople％2Easpx％3FMembershipGroupId％3D9 80 domain \ user IP Mozilla / 4.0 +（兼容+ MSIE + 7.0 +的Windows NT + 5.1 + +三叉戟/ 4.0; + NET + CLR 2.0.50727 +; + NET + CLR + 1.1.4322 + NET + CLR + 3.0.04506.30; +。 NET + CLR + 3.0.04506.648; + OfficeLiveConnector.1.4; + OfficeLivePatch.1.3; + 86e）403 0 0

也许人们已经检查了这个，但它花了我一点。我找了补丁​​KB928365并且它不存在（很多其他帖子建议删除此补丁来解决此问题）。 此外，QA和Production中的行为不同，因为我在QA中将新用户添加到站点时所使用的acct由于包含在WSS_admin_wpg组中而具有更高的特权（可能是因为它在QA中是一个农场管理员的事实？ ）