Does an IIS 7.5 web app with windows authentication require end users to have file permissions?

Question

Short version:

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

Long version:

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:

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.

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.

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.

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?

Some relevant details:

• 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.

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.

Update: This msdn article says

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.

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.

Solution 1

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.

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.

http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk

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).

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

Solution 2

Are authenticated users allowed to the app folder?

Solution 3

We were also fighting with this issue, and started setting up security groups so we could give our users file level permissions. Then one of our server admins stumbled across a couple of new properties that allow the app to authenticate to the file system under set credentials, and resolved the need for the users to have access. Here is what he came up with…

There are two IIS settings that control this:

Physical Path Credentials Physical Path Credentials Logon type

By default, Physical Path Credentials is set to Application User (Pass-through authentication). This means that IIS doesn’t do any impersonation when handling Windows Authentication requests. This can, however, be set to a specific user (though not, unfortunately, the application pool identity, which would be ideal). Physical Path Credentials Logon Type is set by default to Clear-Text. For my testing I set this to Interactive (though this may not be the correct value). Possible values are Clear-Text, Batch, Interactive, and Network.

To set this up I did the following:

1. Created a local account (IIS-AccessUser)
2. Granted IIS-AccessUser read and execute access to the /home directory of the site.
3. Added IIS-AccessUser to IIS_IUSRS group (necessary for accessing .NET temporary files)
4. Set IIS-AccessUser as the Physical Path Credentials
5. Set Physical Path Credentials Logon Type to Interactive

Doing the above allowed me to log in to the application directly, without having to allow Authenticated Users, or me having to be a member of any of the groups in the /home folder. It also still preserved .NET Authorization roles, so I still could not access parts of the site that I was not allowed to.

Comments

[Wiktor Zychla]

Two questions: 1. is the appserver connected to the domain so that NTLM is able to resolve credentials in the domain controller? 2. Does the problem remain if you create a local appserver account and switch the app pool to this local account (rather than the network service)?

[irag10]

1) Yes the appserver is able to connect to the domain. 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, using NTLM or Kerberos depending on which was at the top of the Providers list.

[irag10]

2) Do you mean creating a new user on the local machine and using that, rather than say using an AppPool identity? I can give it a try ... any reason you think this might work?

[Wiktor Zychla]

2) Yep, just to try a specific app pool user account rather than the Network Service.

[jazzy]

I am having exactly the same issue, and only one some machines. It's very confusing.

[irag10]

I've never seen that group before, nor needed to give it permissions! Isn't that basically the same as giving permissions to Everyone?

[erichste]

In short "No", you might like to read this article windowsitpro.com/article/user-management-and-profiles/…

[irag10]

Ok, it's not the same as Everyone, since Everyone includes Guest and null sessions such as computer-to-computer connections. But Authenticated Users is almost Everyone, so you're still having to give file access permissions to end users which is what I was trying to avoid. windowsitpro.com/article/file-systems/… has a bit more discussion on Authenticated Users.

[erichste]

Aren't you using Active Directory? And don't you want to give access to your active directory users? Maybe I got it completely wrong...

[irag10]

Yes, using Active Directory, but why do I need to give end users access to the files themselves? I'm sure I've never needed to do this before and it just seems weird that an end user should be able to view , for example, the web.config file on a server.

[erichste]

@Rory if things worked the way you are telling here then all the world would see every asp.net web site's web.config file... Isn't that true? (For a person to see a web.config file you'll have to SHARE the folder! Not only give permission) Just give the permission. Authenticated users mean active directory users can access this "web site" that's all!!! My efforts end here...

[irag10]

Sure, I understand that they can't access the web.config via http, but they potentially could via windows explorer. Anyway, I appreciate the responses. I'll update the question if I find a definitive statement that end users need file permissions and/or determine why I thought this hasn't been required at dozens of other implementations.

[erichste]

OK last comment :) Can you check this out: msdn.microsoft.com/en-us/library/ms180890(v=vs.90).aspx, maybe the only problem is that you do not have <identity impersonate="true"/> in your web.config

[irag10]

That article is about using forms authentication to present a login form to a user and then authenticate to a domain. I want to use Windows Authentication to automatically authenticate the user. I'm not using impersonation so I don't have impersonate="true"; I want the app pool to run as network service, not as the authenticated end user.

[irag10]

Thanks, this is good. Too much setup for me so I now ensure AuthenticatedUsers have access, but if one really cared about ensuring users couldn't access the files via windows explorer this would be the way forward.

[DZx]

Why couldn't it be set up as the app pool identity? That seems to be working for me.

[Rozwel]

@DZx I have never seen the config screen myself, but I suspect that our admin was lamenting that there was no simple option to say "use app pool identity". However, I am not aware of anything to keep you from keying the same credential into both places.

[Paul Syfrett]

@DZx I tried, in IIS 7.5, to set the app pool identity for the "Physical Path Credentials", but it only gives two options: "Specific User" and "Application user (pass-through authentication)". I tried to use "Specific User" option with my "IIS AppPOOL\<poolName>" with a blank password (because it is an IIS bult-in account). IIS errors with "The specified password is invalid[...]". I think this is why IIS-AccessUser was created for Rozwel. How where you able to make this work?

[Rozwel]

@Paul We entered a legitimate domain account for each credential, not the built in IIS accounts.

[DZx]

@Paul Same here, we used a domain account with a password, not the built in accounts.

[De Shan Baptiste]

Here's a better set of options: weblogs.asp.net/owscott/…

[Gyum Fox]

That's the only thing that worked for me. Both server and client are connected to the domain via a VPN.