Figure 6 shows the results for the next test, in which I disabled anonymous access and enabled Basic authentication on the virtual directory that maps to the UNC share. I supplied the credentials (i.e., altoid\LocalAltoid) for a user account that exists only on the IIS machine. Although the LOGON_USER variable now shows the authenticated user (i.e., altoid\LocalAltoid), the IIS thread still runs under the ALTOID\IISRemote account, which exists on both machines, using the same password on both.
You can, however, change this default behavior and pass through client credentials directly to the remote machine. This method employs a security delegation, in which the Web server delegates the client's credentials to a third machine that exposes the UNC share. To enable pass-through delegation, disable anonymous access for the remote share (or for the file on the remote share) and use either Basic or Kerberos authentication. (Both of these schemes support delegation, which is a requirement for pass-through access. However, Basic authentication sends the initial credentials from the client to the server in clear text—something you should take care to avoid, for example, by requiring a Secure Sockets Layer—SSL—connection.) You also need to enable pass-through access in the IIS metabase. To do so, run the following command, which you need to enter on one line:
C:\Inetput\AdminScripts> adsutil set w3svc/1/Root/RemoteScripts/UNCAuthenticationPassThrough True
After you run this command, restart IIS—by running the IISReset command, for example—to make sure that no security tokens are cached. As Figure 7 shows, when I enter domain credentials (i.e., REDMOND\leonbr) to request getusername.asp after enabling pass-through delegation, the IIS thread runs under the same credentials as the LOGON_USER variable.
Preventing pass-through authentication is as simple as enabling it. Run the same command, but change the final parameter to False instead of True.
When you don't enable pass-through delegation, all access occurs in the security context of the configured Connect As user account. However, when you enable pass-through authentication, you can use network-access permissions to control access to remote content in a fashion similar to using NTFS file permissions. This process lets you control user access regardless of file system. In Windows Explorer, open the Properties dialog box for the directory that you want to share. Go to the Sharing tab and click Permissions, then add and delete users to configure network access to the share. (Don't confuse this process with adding users on the Security tab, which controls access through the file system.)
Potential Problems
Not everything is perfect with directory redirection. One bug in IIS 5.0 and IIS 4.0 relates to loss of File Change Notifications. As a performance optimization measure, IIS caches static files and ASP pages. When a cached file changes, IIS receives a File Change Notification and deletes the file from the internal cache. If a notification is lost—and this can be the case when you use UNC paths—IIS continues to serve the old version of the file. To remedy this problem, disable caching of static files. To do so, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Inetinfo\parameters registry subkey and set the DisableMemoryCache value (of type REG_DWORD) to 1. Alternatively, you can edit the WWW Service Master properties. Open the WWW Service Master Properties dialog box and go to the Home Directory tab. Click Configuration, then go to the Process Options tab and select the Do not cache ASP files option. The Microsoft article "File Change Notifications Are Lost When Content Is on a UNC Share" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q281253) contains more information about this bug and the workaround. (Note that disabling caching negatively affects IIS performance. Of course, serving files from UNC shares isn't the fastest operation, either. Test thoroughly to determine whether these solutions provide acceptable performance.)
Another problem related to servicing files from a UNC share manifests itself as a Web server hang and occurs when multiple IIS machines use the same UNC share as a common file repository—a situation that can arise in a Web farm. The problem is rooted in the limited number of connections that can be established from client machines to the server that exposes the UNC shares. To remedy the problem, modify the registry on the Web servers and the file server. Under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstationParameters subkey on the IIS machines, set the MaxCmds value (of type REG_DWORD) to 0x00000800. Under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters subkey on the file server, set the MaxMpxCT value (of type REG_DWORD) to 0x00000800 and the MaxWorkItems value (of type REG_DWORD) to 0x0000FFFF. The Microsoft article "IIS Runs Out of Work Items and Causes RPC Failures When Connecting to a Remote UNC Path" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q221790) includes more information about resolving this problem. The Microsoft article "ASP Returns Continuous 'Include File Not Found' Errors" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q288270) contains information about a fix for one other problem with opening include files on the UNC directory.
Another Direction
Directories on the local file system or remote network shares are the most common targets for IIS virtual directories; network shares let you leverage IIS's ability to store content on machines that don't even run IIS. In my next article, I'll examine the third option—URL redirection.