Accessing and Executing Remote Content (IIS 6.0)
When IIS accesses content stored on a remote file server, user delegation becomes a factor because IIS uses the clients credentials to access content on the file server. In effect, the Web client passes the users credentials to IIS, which then delegates them to the file server for the authorization check. In IIS 6.0, user delegation is easier because, by default, IIS uses the credentials of the request user (the anonymous user identity for anonymous requests and the authenticated users identity for authenticated requests) to access the content on the remote file server. So, by default, IIS does pass-through authentication, which means that IIS passes the user credentials through to the remote file server. If you want IIS to use a specific user when accessing remote content, set the UNCUsername and UNCPassword properties in the IIS metabase. For information about setting these properties, see the UNCUserName Metabase Property and the UNCPassword Metabase Property.
Logging On
In Figure 11.3 IIS 6.0 UNC Authentication, the request user is the identity of the request coming into the Web server, such as a GET request for http://www.contoso.com/staticfile.txt. If anonymous access is enabled, this request uses the identity of the anonymous user as specified in the metabase (typically, IUSR_ComputerName). If anonymous access is disabled and a valid authenticated request comes in, IIS uses that users account to log on. However, in the case of UNC content, at this stage, IIS checks if UNCUserName is specified in the metabase. If so, IIS logs on as that user. If UNCUserName is not specified in the metabase or if it is set to an empty string, then IIS logs on as the user who originally made the request (that is, as an anonymous user or as an authenticated user).
Note
The UNCPassthroughAuthentication metabase property has been removed from IIS 6.0. In IIS 6.0, pass-through authentication is enabled by default. To disable pass-through authentication, use the UNCUserName and UNCPassword properties.
Accessing the Remote Server
After IIS has a user identity, it must access the remote file server. The type of authentication (Anonymous, Basic, NTLM, Kerberos) enabled on the server can significantly affect how successful this step is. In almost all cases, Basic authentication enables IIS to access a remote file server (although you must always use SSL with Basic authentication since user names and passwords are sent in plain text). Using Basic authentication can help you verify that everything else is working properly.
Executing the Remote Content
So far, we have discussed how remote content is accessed. Remote content must also be executed in the context of this user account. In other words, if UNCUserName and UNCUserPassword are set, then all remote content will be accessed and executed in the context of UNCUserName. This might not be desirable for most applications, because with this approach you lose the identity of the originating Internet/Intranet user. If pass-through authentication is being used, then the request is processed under the identity of the request user.
The process illustrated in Figure 11.3 IIS 6.0 UNC Authentication applies to all content that is executed or retrieved by the server. Consequently, static content, such as Graphics Interchange Format (GIF) and Hypertext Markup Language(HTML) pages, Script-Mapped files, CGI executables, and ISAPI Extension DLLs (like ASP, ASP.Net, and so on) runs under this user context. (ISAPI filters run under the context of the worker process identity. By default, the worker process runs as NetworkService, which is a local account.)
Working in a Domain Environment
In most cases, you will want to run your Web servers and file server in a domain environment because it is much simpler to use a domain environment in which you can control one set of users and groups from the domain controller. Furthermore, if you want to use Windows Integrated Authentication in this scenario, then you need to use a domain environment to take advantage of the new constrained delegation feature of Windows Server 2003. Instructions on setting up constrained delegation follow. For more information about constrained delegation, see Delegating authentication in Help and Support Center for Windows Server 2003.
Working in a Workgroup Environment
Web servers and a file server used in a workgroup environment are difficult to manage and maintain. In a workgroup environment, because one user account has access to another computer only if that computer has a user with the same user name and password, you have added administrative overhead. To add a new user to your environment, you have to add the user to both servers and you need to ensure that both accounts have the same password.
For an detailed explanation of using remote content on a UNC share, see Deploying and Configuring Internet Information Services (IIS) 6.0 with Remotely Stored Content on UNC Servers and NAS Devices.