Consider the following scenario:
- A computer is running Microsoft Internet Information Services (IIS) 7.0.
- The physical path for a Web site is set to a Universal Naming Convention (UNC) directory.
- The Web site uses pass-through authentication.
- You try to view a Web page from the Web site.
In this scenario, you receive the following error message in the Web browser:
HTTP Error 500.19 - Internal Server Error
Description: The requested page cannot be accessed because the related configuration data for the page is invalid.
Error Code: 0x8007052e
Module: IIS Web Core
Requested URL: URL
Physical Path: Physical_Path
Logon User: Not yet determined
Logon Method: Not yet determined
Handler: Not yet determined
Config Error: Cannot read configuration file
Config File: \\?\UNC\Configuration_File_Path
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.
To resolve this behavior and to make sure that pass-through authentication works correctly, follow these steps:
- 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.
- 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.
- 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.
- 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.
To work around this behavior, configure the Web site to connect to the UNC directory by using a specific user account. When the Web site uses a specific user account, the worker process impersonates the specified user identity.
This behavior is by design.