HOWTO: Accessing Network Files from IIS Applications

ID: Q207671

The information in this article applies to:

Microsoft Internet Information Server versions 3.0, 4.0

SUMMARY

Accessing files on a computer other than your Internet Information Server (IIS) server from an Internet Server API (ISAPI) extension, Active Server Pages (ASP) page, or Common Gateway Interface (CGI) application can be problematic. This article lists the issues involved and some possible ways for getting this to work.

MORE INFORMATION

Although this article is written mainly in the context of accessing files on network shares, the same concepts apply to named pipe connections as well. Named pipes are often used for SQL Server connections as well as for remote procedure call (RPC) and distributed component object model (DCOM) communications. In particular, if you connect to a SQL Server across the network that is configured to use Windows NT Integrated Security, you will often not be able to connect because of the issues outlined in this article. RPC and DCOM may also use other communication mechanisms that have similar network authentication schemes. Therefore the concepts in this article can apply to a wide variety of network communications mechanisms that might be used from your IIS applications.

When IIS services an HTTP request it performs impersonation so that access to resources to handle the request is limited appropriately. The impersonated security context is based on the kind of authentication performed for the request. The five different types of authentication available from IIS 4.0 are:

Authentication Type Impersonation Type

Anonymous Access (no authentication)
Auto Password Synchronization is ON (ON=default) Network

Anonymous Access (no authentication)
Auto Password Synchronization is OFF IIS Clear Text

Basic Authentication IIS Clear Text

NT Challenge/Response Authentication Network

Client SSL Certificate Mapping Interactive

Whether or not access to network resources is allowed is dependent on the kind of impersonation token under which the request is being processed. Network tokens are NOT allowed to access network resources (it is called a "Network" token because this kind of token is traditionally created by a server when authenticating a user across the network, to allow the server to use a network token to act as a network client and access another server is called "delegation" and is considered a possible security hole).

Interactive tokens are traditionally used when authenticating a local user on the computer. Interactive tokens are allowed to access resources across the network.

A third type of token that IIS can support is a Batch token. This is designed to provide a security context under which batch jobs run. Batch tokens have network access.

IIS has the concept of a Clear Text logon. The name is due to the fact that IIS has access to both the username and password in clear text. You can control whether a Clear Text logon creates a Network, Interactive, or Batch token by setting the LogonMethod property in the metabase. By default, Clear Text logons get an Interactive token and have access to network resources. The LogonMethod can be configured at the server, site, virtual directory, directory, or file level.

Anonymous access impersonates the account configured as the anonymous user for the request. By default, IIS has a single anonymous user account called IUSR_<machinename> which is impersonated when handling a non- authenticated request. By default IIS 4.0 has a configurable feature called "Enable Automatic Password Synchronization" which uses a security sub-authority to create the token. Tokens created in this manner are network tokens which will NOT have access to other computers on the network. If you disable Automatic Password Synchronization, IIS creates the token in the same manner as the Clear Text logon mentioned previously. Automatic Password Synchronization is only available for accounts that are located on the same computer as IIS. Therefore, if you change your anonymous account to a domain account, you will not be able to use Automatic Password Synchronization and you will get a clear text logon. The exception is if you install IIS on your Primary Domain Controller, in which case, the domain accounts are on the local computer. The anonymous account and the Automatic Password Synchronization option can be configured at the server, site, virtual directory, directory, or file level.

Having the proper type of token is the first step in accessing a resource on the network. You must also be impersonating an account that has access to the resource across the network. The IUSR_<machinename> account that IIS creates for anonymous requests exists only on the local computer by default. Even if you disable Automatic Password Synchronization so that you can get an Interactive token capable of accessing network resources, the IUSR_<machinename> account typically will not have access to most network resources because it will be an account that is unrecognized on other computers. If you wish to access network resources with anonymous requests, it is suggested that you replace the default account with an account in a domain on your network that can be recognized by all computers. If you happened to have installed IIS on a Domain Controller then the IUSR_<machinename> account is a domain account and should be recognized by other computers on the network without taking further action.

Following are ways to avoid problems when accessing network resources from your IIS application:

Keep files on the local computer.

Some network communication methods do not require a security check, such as using Windows sockets.

You can provide direct access to a computer's network resources by configuring a virtual directory to be:

"A share located on another computer."
All access to the computer sharing the network resources will be done in the context of the person specified under the "Connect As.." dialog box no matter what kind of authentication is configured for the virtual directory. Using this option means all files on the network share will be available from browsers accessing the IIS computer.

*** Use basic authentication or anonymous authentication without Automatic Password Synchronization. The impersonation that Internet Information Server does for basic authentication by default provides a token that is capable of accessing network resources (unlike Windows NT Challenge/Response, which provides a token that is incapable of accessing network resources). For anonymous authentication, the token will only be capable of accessing a network resource if Automatic Password Synchronization is disabled. By default, Automatic Password Synchronization is enabled when Internet Information Server is first installed. In such a default configuration, the anonymous user token will not be able to access network resources.

*** Configure the anonymous account as a domain account. This allows anonymous requests to potentially access resources across the network. To prevent all anonymous requests from having network access, you might only make the anonymous account a domain account on the virtual directories which specifically require access.

*** Configure the anonymous account with the same username and password on the computer that is sharing the network resources and disable Automatic Password Synchronization. If you do this you will need to make sure that the passwords match exactly. This method should only be used when method 5 is not an option for some reason.

NullSessionShares and NullSessionPipes can be used to allow access to a specific network share or a named pipe when your request is being handled with a network token. If you have a network token and you attempt to establish a connection to a network resource, the operating system attempts to establish a connection as a non-authenticated connection (referred to as a "NULL Session"). This registry setting needs to be made on the computer sharing the network resource, not the IIS computer. If you attempt to access a NullSessionShare or NullSessionPipe with a non-network token, normal Windows authentication will be used and access to the resource will be based on the impersonated user's account privileges.

You can potentially perform your own impersonation in order to create a thread token that does have network access. The LogonUser and ImpersonateLoggedOnUser functions can be used to impersonate a different account. This requires that you have the clear text username and password of another account available to your code. LogonUser also requires that the account that calls it has the "Act as part of the operating system" privilege in User Manager. Most users that IIS will impersonate while handling an HTTP request will not have this privilege by default, however for In Process Applications there are a number of ways to cause your current security context to change to the LocalSystem account which does have the "Act as part of the operating system" privilege. For ISAPI dlls running in-process probably the easiest way to change the security context that IIS has created to the LocalSystem account is to call the RevertToSelf function. If you are running your IIS application Out of Process, this mechanism will not work by default because the process is running under the IWAM_<machinename> account and not the LocalSystem account. The IWAM_<machinename> does *NOT* have the "Act as part of the operating system" privilege by default.

NOTE*** Do not forget that you can prevent network access for anonymous requests where password synchronization is disabled and requests authenticated using basic authentication (clear text logons) by setting the LogonMethod metabase property to 2 (indicating that a network logon will be used to create the impersonation token). With this setting the only way possible for requests to get around the network token limitation would be to connect to NullSessionShares or NullSessionPipes.

Make sure that you do not use drive letters mapped to network shares. Not only are there only 26 potential driver letters to choose from, but trying to use a drive letter that was mapped in a different security context can cause problems. Instead you should always use Universal Naming Convention (UNC) names to access resources. The format should look something like the following:

\\MyServer\filesharename\directoryname\filename

The information in this article pertains only to Internet Information Server 4.0. In Internet Information Server 5.0 (shipping with Windows 2000) there will be significant changes in regards to new authentication types and capabilities. Although most of the concepts in this article still apply to IIS 5.0, the details on the sorts of impersonation tokens generated with certain authentication schemes in this article apply strictly to IIS 4.0.

If you are having problems trying to determine what sort of logon is occurring on your IIS server to handle requests, you can turn on auditing for Logons and Logoffs to help you do this. In the User Manager navigate to Policies, point to Audit, choose the Audit These Events option and then select the Logon and Logoff options. Event Log entries will be added under the Security Log. You can determine the kind of logon by looking at the event details under the Logon Type:

2=Interactive
3=Network
4=Batch
5=Service

REFERENCES

For additional information about network security, please see the following article(s) in the Microsoft Knowledge Base:

Q124184 Service Running as System Account Fails Accessing Network

Q180362 INFO: Services and Redirected Drives

Q158229 INFO: Security Ramifications for IIS Applications

Additional query words: kbdse

Keywords : iissecurity iisapi
Version : winnt:3.0,4.0
Platform : winnt
Issue type : kbhowto