To establish a connection to the specified target share, you must click Connect As to open the Network Directory Security Credentials dialog box, in which you must supply a valid username and password. You can supply these credentials in one of two ways. When both the Web server and the target machine are members of the same domain or a trusted domain, you can supply domain credentials in the domain\username format; so long as the specified user account has access to the target machine, the connection will succeed. When the machines don't operate within the same domain or a trusted domain, you need to establish a connection in the context of a user with access to the target machine. To do so, you can create two identical accounts on both machines and supply identical passwords for both accounts. For example, I created an account named IISRemote on the target machine (i.e., Leonbrpridotnet) and created another account named IISRemote on the Web server (i.e., Altoid), then specified the same password for both accounts.
If you supply credentials that don't have access to the target machine, the Error icon appears beside the virtual directory in the Internet Information Services console and the System log displays a warning message explaining the cause of the problem (e.g., the account is disabled, the account doesn't exist on the target machine). The sample event in Figure 3 shows that the account I'm using to try to connect (i.e., IISRemote) is disabled. (If the target machine is configured to audit logon and logoff events, a logon failure event also appears in the Security log on that system.)
Keep in mind that all access to the target share occurs according to the user account you specify through the Connect As setting, but the Internet Information Services console lists the contents of the share in the security context of the user who opens the MMC snap-in. Therefore, if you open the snap-in as a local IIS machine user who doesn't have access to the target share, don't be surprised to see an Access Denied error when you try to enumerate files in the virtual directory. Although not being able to see a list of target-directory files is certainly inconvenient, IIS can still serve the files because file access relies on the Connect As account's security context.
Staying Secure
An important step in restricting general access to a target resource is to disable anonymous access to the target directory so that access will depend on a user's credentials. Furthermore, when you configure a virtual directory to use a local directory and the local system uses NTFS, you can take advantage of NTFS's granular access-control settings (i.e., access control entries—ACEs—and ACLs) to permit or deny specific user account access to HTML files, Active Server Pages (ASP) pages, and other resources. (For more information about ACEs and ACLs, see Tim Huckaby, "ACL-Based Security Tips for IIS," http://windowswebsolutions.com, InstantDoc ID 22444.) If you've given an authenticated user permission to access a resource, IIS will grant the client request.
As for virtual directories that you configure to access network shares, the process is a bit more complicated. IIS is a process (inetinfo.exe) that runs under the Local System account. IIS has a thread pool that manages incoming connections. For each request, IIS uses a thread from the pool to access files and send results back to the client. Because the Local System account has too many rights on the local system to safely handle client requests, IIS impersonates the user, temporarily changing the thread's identity to access the required resource in the correct security context. To impersonate the user, IIS uses credentials that the Web client supplies. If a client doesn't supply credentials and you haven't disabled anonymous access, the thread impersonates the IUSR_machinename account, which IIS creates during installation and uses for anonymous access. To explore the security context of an IIS thread, you can call a Win32 function—for example, the GetUserNameEx() call—that returns the username of the account under which the thread is running. Because you can't call an API directly from ASP, I've written an ActiveX DLL that calls such a function. You can use the script that Listing 1 shows to create an .asp file that uses this DLL to analyze the security context used to access a virtual directory that resolves to a remote share through UNC. (To use this script as is, however, you also need to install and register the files in the ComGetUserName.zip file at http://windowswebsolutions.com, InstantDoc ID 25930.) This simple script not only reveals a thread's security context but also shows the Windows account that IIS impersonated to access the virtual directory's specific physical path. The script creates an instance of the COM object on the IIS machine. ASP then invokes a method from the COM object and gets the username that the GetUserNameEx() API returns. From the IIS process, ASP directly obtains the PATH_TRANSLATED server variable, which shows the physical path of the .asp file, and the LOGON_USER server variable, which shows the logon credentials of the user who invoked the script.
Figure 4 shows the results for an anonymous request when the sample .asp file getusername.asp resides in the local Scripts virtual directory on the Altoid server. In this example, I haven't disabled anonymous access to the target directory. The test results show that the LOGON_USER variable is empty, which indicates an anonymous request; for a nonanonymous request, this line would show the same name as the IIS thread runs under variable. The IIS thread runs under the local account IUSR_ALTOID.
Figure 5 shows the results for an anonymous request when the .asp file is in the RemoteScripts virtual directory, which maps to a UNC share. The LOGON_USER variable is still empty, but the thread now runs under the IISRemote user account, which is the account that I entered in the virtual directory's Connect As option. Remember, all access to UNC shares occurs in the context of the user you configured under the Connect As option. This rule is true even when you've disabled anonymous access and the user is authenticated.