Error 500.19 - IIS 7.5 Site based on UNC - File Permissions Problem

Question

I'm trying to get a website in my IIS 7.5 (Win 7 Pro machine) to run via a UNC path to the code for one of the default website and an underlying App. This is the first time I've ever tried to set up a site/app in IIS 7.5 based off a UNC path: a folder on another server in the same domain.

I've tried various things to try to get this resolved. The app pool is running under ApplicationPoolIdentity on my Win 7 Pro PC where I have this site set up.

The runtime error I get when trying to run the app in the browser via http://localhost/TheAppName is:

Module: IIS Web Core
Notification: Unknown
Handler: Not Yet Determined
Error Code: 0x800700005
Config Error: Cannot read configuration file due to insufficient permissions
Config File: \\?\UNC\theServerName\www\TheAppName
Requested URL: http://localhost:80/TheAppName
Physical Path: (nothing showing up here)
Logon Method: Not yet determined
Logon User: Not yet determined

I put in fake names for the server and app name above for privacy for this post.

So it's having trouble reading the web.config found in that UNC path for this site.

I tried to add a local user on the target server and then then gave that user permissions to the web.config and then used that user RemoteServerName\LocalUserICreated as the app pool's Identity on my machine but it had no effect.

No clue what to do here and how to go about it.

Answer 1

I assume the UNC path is to a different server?

If so are both servers in the same domain? If so then IIS needs to run the website under a user account that has permissions to read the files.

If not you need to create identical user accounts (same username, same password) on the web server and the file storage server and then change IIS to run the website under this user account.

Hope this helps/works.

Answer 2

When you create a web application or virtual directory from a UNC path, you need to provide the credentials to IIS for the connection.

In the Add Application dialog, below the Physical path section is the "Connect as..." button - you can then choose either "Application user (pass-through authentication)" or "Specific user".

Which ever you choose, they have to be credentials that will be recognised by the remote server - "Pass-through" will try and use the current desktop (or browser) credentials to authenticate the user which (if you're connecting via a VPN as per your comments) almost certainly won't be valid. In this case you should use "Specific user" and provide (ideally) a domain user with suitable permissions to run the site.

When we've needed to do this in the past, we'd create an account on the domain that the local AppPools would run under, and then this could be used in these situations as well.

If you've already created the application, the dialog can be reached using the "Basic Settings..." action link.

Answer 3

I took me a few hours to finally solve the same issue for myself. Turned out I used the wrong slashes in my physical path. It should be \ these, not // these.

Answer 4

Zhaph and Alan both identify the work-around suggested by Microsoft. Here's the rest of the information from Microsoft's page on your problem:

Cause

IIS 6.0 uses the hosting worker-process identity to connect to a remote directory. Then, IIS 6.0 authenticates the user against the remote directory. However, IIS 7.0 introduces delegation scenarios. In IIS 7.0, you can delegate Web-site settings and application-level settings to a Web.config file.

For pass-through authentication, the Web.config file is stored in a UNC directory. Therefore, the default-process identity in IIS 7.0 must examine the Web.config file first to determine whether any security-related settings must be applied before the authentication process starts. The default-process identity in IIS 7.0 does not have sufficient permissions to open the Web.config file. Therefore, the Web request is rejected.

If there is no Web.config file in the UNC directory, IIS 7.0 uses the rules that are defined for the parent directory. For the Web content to be served in this scenario, the worker-process identity must have access to the whole content directory. Otherwise, the Web request is rejected.

Resolution

To resolve this behavior and to make sure that pass-through authentication works correctly, follow these steps:

1. Make sure that all the user accounts that access the UNC directory have at least the Read permission for the UNC directory.

   Note This behavior is the same as the behavior in IIS 6.0.

2. Make sure that the IIS worker-process identity is running under a domain account or under a workgroup account that also exists on the UNC file server. If it is necessary, create an account on the UNC file server that has the same user name and the same password as the IIS worker-process identity.

   Notes

   • This behavior differs from the behavior in IIS 6.0.
   • By default, the DefaultAppPool application pool runs under the Network Service account. This account is local to the computer, and this account does not exist on another computer. Therefore, make sure that you configure the DefaultAppPool application pool to use an account that is a domain user. Then, you can use the same account on the UNC file server. Alternatively, you can create a workgroup account on the UNC file server and on the computer that is running IIS 7.0.

3. If there is a Web.config file in the UNC directory, edit the discretionary access control list (DACL) for the Web.config file so that the DACL contains the account that you verified in step 2. Alternatively, edit the DACL for the Web.config file so that the DACL contains the account that you created in step 2.

   If there is no Web.config file in the UNC directory, edit the DACL for the UNC directory so that the DACL contains the account that you verified in step 2. Alternatively, edit the DACL for the UNC directory so that the DACL contains the account that you created in step 2.

   Note This behavior differs from the behavior in IIS 6.0.