是否使用Windows身份验证的IIS 7.5 Web应用程序要求最终用户有文件权限？ [英] Does an IIS 7.5 web app with windows authentication require end users to have file permissions?

问题描述

短版：

有关IIS使用Windows身份验证的Web 7.5应用程序确实结束
  用户需要具有读取文件访问？

For IIS 7.5 web applications with Windows Authentication does the end user need to have Read file access?

长版：

我有一个使用Windows身份验证的Intranet ASP.NET Web应用程序。它安装在几十个不同的公司，通常认证工作正常：用户导航到该网站如的http：//应用服务器/ MyApp的，应用程序可以识别他们作为，并显示相应页面登录谁。我刚安装了它在新的客户端，并遇到一个问题：

I have an intranet ASP.NET web app that uses windows authentication. It's installed at dozens of different companies and normally the authentication works fine: users navigate to the site e.g. http://appserver/MyApp, the app recognizes who they're logged in as and displays pages accordingly. I just installed it at a new client and encountered a problem:

在连接如到的http：//应用服务器/ MyApp的我提示输入Windows凭据，但他们进入后，我反复提示。经过多次重新输入凭据，我出的401错误页面，指出401 - 未经授权：访问被拒绝由于凭据无效。因此，不仅是它不经过我的身份，但输入用户名和放大器即使;密码它仍然拒绝访问。

When connecting e.g. to http://appserver/MyApp I'm prompted for windows credentials but after entering them I'm repeatedly prompted. After several re-entering credentials I'm shown a 401 error page saying "401 - Unauthorized: Access is denied due to invalid credentials.". So not only is it not passing through my identity but even when entering the username & password it's still denying access.

捐赠读取和放大器;执行权限的应用程序的最终用户解决了这个问题，但我不认为这应该是必要的。

Giving Read & Execute permissions to the end users of the app solves this problem, but I don't think this should be necessary at all.

在Windows应用程序事件日志有一个消息文件授权失败的请求与线程帐户名一起：NT AUTHORITY \\ NETWORK SERVICE和用户： [正确的工作站用户的域帐户] 的。这表明，目前正在与网络服务的用户的身份，而不是程序池的身份执行文件访问。果然，如果我给予最终用户读取和放大器;执行权限（我没有尝试只读）应用程序的目录，然后一切正常：当用户浏览到它们会自动进行身份验证的网站，而不是提示，并且该网站的正确识别他们的身份！因此，我的解决方法解决方案是给读取和放大器;执行权限的应用程序目录每个人......但是这不是一个理想的解决方案。

In the windows Application Event Log there's a message "File authorization failed for the request" along with Thread account name: NT AUTHORITY\NETWORK SERVICE and User: [the correct workstation users's domain account]. This suggests that the file access is being performed with the User's identity, not the AppPool identity of Network Service. Sure enough if I grant the end user Read & Execute permission (I didn't try Read only) to the application's directory then everything works correctly: when the user browses to the site they're authenticated automatically, not prompted, and the web site correctly recognizes their identity! Therefore my workaround solution is to give Read & Execute permission to Everybody on the application directory...but this is not an ideal solution.

这似乎很奇怪。我从来没有需要做这个之前在IIS 7.5，只要我还记得，绝对从来不需要在IIS 6或IIS 7，这是一个新的IIS7.5的事情吗？该文件说，模拟是默认关闭的。我添加了一个元素到web.config比网络服务等肯定的是，删除的文件的权限，但问题依然存在。

This seems very strange. I've never needed to do this before in IIS 7.5, so far as I recall, and definitely never needed to in IIS 6 or IIS 7. Is this a new IIS7.5 thing? The documentation says that Impersonation is turned off by default. I added a element to the web.config to be sure, removed file permissions other than Network Service, but the problem remained.

有什么想法？这是正常的在IIS 7.5的Windows身份验证的网站为最终用户需要在Web服务器上文件的文件权限？

Any thoughts? Is it normal for Windows Authenticated sites on IIS 7.5 for end users to need file permissions on the web server files?

一些相关的细节：

• 网络服务
  具有完全控制文件权限的app文件夹。


• 当从服务器本身的连接，我提示输入凭据
  但进入后他们我是经过身份验证和应用程序的工作
  正确包括显示我的Windows登录名和连接和
  从数据库中检索数据。后来我才确定，这是提示
  为凭据，因为的http：//本地主机在受信任站点
  因此，不能认定为Intranet区域，因此不会
  通过身份通过。我也决定了它工作作为
  该用户的身份，因为它是谁拥有文件的管理员用户
  权限。


• Web服务器正在运行Windows Server 2008 R2 / IIS
  7.5。它没有IIS它，直到我安装了它。我安装的默认功能，以及Windows身份验证，ASP.NET和
  可能是一对夫妇的其他项目。一个单独的WCF应用程序，我安装的
  使用IIS，匿名身份验证和放大器; .NET 2.0工作正常上
  该Web服务器。


• 该应用程序的安装过程是文件的手动复制，
  创建IIS应用程序池和放大器; Web应用程序，更新连接字符串，
  等等。


• 我查了一下IE的安全设置。它被承认
  服务器在Intranet区域，不得不选择自动登录
  只在Intranet区域进行选择。同样在高级设置
  启用集成Windows身份验证选项被选中。


• 之后
  安装IIS我跑为aspnet_regiis -i 用于.NET 2.0和
  为aspnet_regiis -iru 为.NET 4.0。


• 匿名身份验证
  我的应用程序禁用和启用Windows身份验证。


• 的应用程序是
  在ASP.NET运行V4，但还有另外一个应用程序，我安装
  遇到运行ASP.NET V2同样的问题。


• 的应用程序正在运行
  与Identity =网络服务，并在32位模式。


• 数据库
  连接字符串包括信任连接= TRUE 和数据库
  权限授予Web服务器帐户 [域] \\ [服务器] $
  例如 DGM \\ $的MyServer 。


• 在IIS>认证> Windows身份验证>供应商名单是先协商再NTLM。我试图重新排序，以便NTLM第一。


• 在Windows的安全事件日志有
  进行了一系列的Microsoft Windows安全审计事件：登录
  和注销。他们指出，登录成功，是
  显示工作站用户的用户ID。这是从当
  我是从其他工作站连接，并获得401
  经过几次尝试未经授权。

• Network Service has Full Control file permissions to the app folder.
• When connecting from the server itself I was prompted for credentials but after entering them i'm authenticated and the application works correctly including displaying my windows login and connecting and retrieving data from the db. I later determined that it was prompting for credentials because http://localhost was in the trusted sites and therefore not recognised as the Intranet Zone and thus not passing identity through. I also determined that it was working as this user identity because it's an admin user who has file permissions.
• The web server is running Windows Server 2008 R2 / IIS 7.5. It didn't have IIS on it until I installed it. I installed the default features as well as Windows Authentication, ASP.NET, and possibly a couple of other items. A separate WCF app I installed that uses IIS, anonymous authentication & .net 2.0 is working fine on that web server.
• The app install process is a manual copy of files, creation of IIS App Pools & web apps, updating connection strings, etc.
• I checked the IE security settings. It was recognizing the server as in the Intranet zone and had the option 'Automatic logon only in Intranet zone' selected. Also on Advanced Settings the 'Enable Integrated Windows Authentication' option was checked.
• After installing IIS I ran aspnet_regiis -i for .net 2.0 and aspnet_regiis -iru for .net 4.0.
• Anonymous authentication is disabled for my app and Windows Authentication enabled.
• The app is running on ASP.NET v4 but there's another app I installed experiencing the same issue running ASP.NET v2.
• The app is running with Identity = Network Service and in 32-bit mode.
• Database connection string includes Trusted Connection=True and database permissions are granted to the web server account [domain]\[server]$ e.g. DGM\MyServer$.
• In IIS > Authentication > Windows Authentication > Providers the list was Negotiate first then NTLM. I tried reordering so NTLM is first.
• In the Windows Security Event Log there were a series of Microsoft Windows security auditing events: Logon and Logoff. They indicated that the Logon was successful and was displaying the User Id of the workstation user. This are from when I'm connecting from another workstation and receive a 401 Unauthorized after several attempts.

我看到有人有这个问题，<一个href=\"http://stackoverflow.com/questions/9383695/asp-net-mvc-3-intranet-site-on-iis7-5-w-windows-authentication-gives-401-3-and-f\">reported这里但没有解决方案。本来我张贴在 ASP ，然后的 IIS 论坛迄今没有答案。

I see someone has had this problem reported here but with no solution. Originally I posted in the ASP and then the IIS forums with no answers so far.

更新：
此MSDN文章说

在Windows身份验证已启用，但模仿是禁用，ASP.NET中的文件授权模块的使用从浏览器发送的证书 （我的重点）的。模拟并不需要被使能，因为FileAuthorizationModule模块确保所述请求用户被允许读取访问或根据请求动词写访问资源，（例如，GET或POST）执行请求之前。此行为适用于进入管理code的任何请求。在早期版本的ASP.NET，访问文件的基于URI的，如Default.aspx的触发访问检查。在ASP.NET MVC应用中，使用无扩展名的URL通常执行的对资源的访问，此检查一般不适用，因为没有一个物理文件来检查。在这种情况下，FileAuthorizationModule类回落到检查访问控制列表（ACL）的文件夹。

When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser (my emphasis). Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request. This behavior applies to any requests that enter managed code. In earlier versions of ASP.NET, accessing files based on URIs such as "Default.aspx" triggered the access check. In ASP.NET MVC applications, where access to resources is typically performed using extensionless URLs, this check typically does not apply, because there is not a physical file to check. In that case, the FileAuthorizationModule class falls back to checking access-control lists (ACLs) for the folder.

这确实表明，最终用户需要权限的文件（的.aspx的情况下）或文件夹（MVC）......虽然还是这个略显局促和不明确的。 这篇文章的应用程序池说，他们已经习惯作为标识用于保护资源，这与需要授予权限给最终用户的想法。除非规则是应用程序池和网络服务，这可能是这样，但会让人感到意外一样。

This does suggest that the end user needs permissions to the files (in the case of .aspx) or the folder (for MVC) ... although still this seems slightly tucked away and non-definitive. This article about App Pools says they're used as the identity for securing resources, which contradicts the idea of needing to grant privileges to end users. Unless the rules are different for App Pools and NETWORK SERVICE, which could be the case but would be surprising.

推荐答案

简短的回答是否定的。你是不是需要在IIS 7.0和IIS 7.5中使用Windows身份验证时授予文件访问权限。

The short answer is NO. You are not required to grant file access permissions when using Windows Authentication in IIS 7.0 and IIS 7.5.

我们只能够发现这一点，因为我们的服务器管理员闻到了采取授予用户和组的文件级访问的路径出现的安全问题和管理问题。

We were only able to discover this because our server admin smelled the security and management issues that arise from taking the route of granting file level access to users and groups.

对于任何处理这个问题，或者您正在设立一个新的IIS7 / IIS7.5服务器和/或IIS 6移动，这里是为您提供所有的需要是Windows身份验证选项和配置的文章修改，以避免个人或团体授予的文件级别的访问。

For anyone dealing with this issue or if you are setting up a new IIS7/IIS7.5 server and/or moving from IIS 6, here is an article that gives you all of the Windows Authentication options and configurations that need to be modified to avoid granting file level access to individuals or groups.

请在文章的这篇文章中所使用的方法的一些有效的批评到底读了两点意见。

Please read the two comments in at the end of the POST for some valid critiques of the methods used in this article.

<一个href=\"http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk\" rel=\"nofollow\">http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk

除了本文中的信息，请即IIS 7.5是不使用的System.Web Web配置标签（至少在我的MVC应用4）要注意。

In addition to the information in the article, please be aware that IIS 7.5 is not using the web configuration tags for system.web (at least not in my MVC 4 application).

这是在寻找授权配置system.webserver标签（在这里您将需要列出Windows域\\组的用户需要在访问你的应用程序）。

It is looking in the system.webserver tags for authorization configuration (where you will need to list the windows domain\groups a user needs to be in to access your application).

- DSB

这篇关于是否使用Windows身份验证的IIS 7.5 Web应用程序要求最终用户有文件权限？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！