SUMMARY
This article provides information about problems with 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. This article lists some of the issues that are involved and some possible methods to make this work.
Although this article is written primarily in the context of accessing files
on network shares, the same concepts apply to named-pipe connections as
well. Named pipes are frequently used for SQL Server connections and also for
remote procedure call (RPC) and Component Object Model (COM) communications. In particular, if you connect to a SQL Server across the
network that is configured to use Microsoft Windows NT Integrated Security, you cannot connect because of the issues that are outlined in this article. RPC and COM 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 communication
mechanisms that may be used from your IIS applications.
back to the top
Authentication and impersonation types
When IIS services an HTTP request, IIS 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) Network
Auto Password Synchronization is
ON (ON=default)
Anonymous Access (no authentication) IIS Clear Text
Auto Password Synchronization is OFF
Basic Authentication IIS Clear Text
NT Challenge/Response Authentication Network
Client SSL Certificate Mapping Interactive
back to the top
Token types
Whether or not access to network resources is permitted is dependent on the
kind of impersonation token under which the request is being processed.
- Network tokens are "NOT" permitted to access network resources. (Network tokens are named so because this kind of token is traditionally
created by a server when a user is authenticated 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 permitted to access resources across the network.
- Batch tokens are 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.
Clear Text logon is named so because of the
fact that IIS has access to both the username and the password in clear text.
You can control whether a
Clear Text logon creates a Network token,
an Interactive token, or a Batch token by setting the
LogonMethod property in the
metabase. By default,
Clear Text logons receive an Interactive token
and have access to network resources. The
LogonMethod can be configured at
the server, the site, the virtual directory, the directory, or the 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> that is impersonated when handling a non-authenticated request. By default IIS 4.0 has a configurable feature
called "Enable Automatic Password Synchronization" that uses a security
sub-authority to create the token. Tokens that are created in this manner are
network tokens which do "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 earlier.
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 cannot use
Automatic Password Synchronization and you receive a
Clear Text logon.
The exception is if you install IIS on your Primary Domain Controller. In
this case, the domain accounts are on the local computer. The anonymous
account and the Automatic Password Synchronization option can be
configured at the server, the site, the virtual directory, the directory, or
the file level.
You must have the correct type of token as the first step in accessing a resource
on the network. You must also impersonate an account that has access
to the resource across the network. By default, the IUSR_<machinename> account
that IIS creates for anonymous requests exists only on the local computer. Even if you disable Automatic Password Synchronization so that
you can get an Interactive token that can access network resources,
the IUSR_<machinename> account typically does not have access to
most network resources because this is an account that is unrecognized
on other computers. If you want to access network resources with anonymous
requests, you must replace the default account with an
account in a domain on your network that can be recognized by all
computers. If you install IIS on a Domain Controller,
the IUSR_<machinename> account is a domain account and must
be recognized by other computers on the network without taking additional
action.
back to the top
Problem avoidance
Following are ways to avoid problems when you access network resources
from your IIS application:
- Keep files on the local computer.
- Some network communication methods do not require a security check. An example is using Windows sockets.
- You can provide direct access to the network resources of the computer by
configuring a virtual directory to be:
"A share located on another computer."
- Use basic authentication or anonymous authentication without Automatic Password Synchronization.
By default, the impersonation that Internet Information Server does for basic authentication provides a token that can access network resources (unlike Windows NT Challenge/Response, which provides a token that cannot access network resources). For anonymous authentication, the token can only access 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 cannot access network resources.
For more information about Automatic Password Synchronization in IIS, click the following article numbers to view the articles in the Microsoft Knowledge Base:
190005
A site set up for anonymous access prompts users for password
259353 Must enter password manually after you toggle password sync
- Configure the anonymous account as a domain account.
This permits anonymous requests from potential access to resources across the
network. To prevent all anonymous requests from having network access, you
must only make the anonymous account a domain account on the virtual
directories that specifically require access.
- Configure the anonymous account with the same username and password on the computer that is sharing the network resources and
then disable Automatic Password Synchronization.
If you do this you must make sure that the passwords match exactly. This approach must only be
used when the "Configure the anonymous account as a domain account" mentioned earlier is not an option for some reason.
- NullSessionShares and NullSessionPipes can be used to allow access
to a specific network share or to a named pipe when your request is handled with a network token.
If you have a network token and you try to establish a connection to a network resource, the operating system
tries to establish a connection as a non-authenticated connection (referred to as a "NULL Session"). This registry setting must be made
on the computer that is sharing the network resource, not on the IIS computer. If you
try to access a NullSessionShare or NullSessionPipe with a non-network
token, typical Microsoft Windows authentication is used and access to the
resource is based on the account
user rights of the impersonated user.
- You can potentially perform your own impersonation to
create a Thread token that does have network access.
The LogonUser function and
the ImpersonateLoggedOnUser function 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 LogonUser has the "Act as part of the operating system"
privilege in User Manager. By default, most users who IIS impersonates while
it handles an HTTP request do not have this user right. 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" administrative credentials. For ISAPI DLLs
that run in-process, the best 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 does not work by default because the process is
running under the IWAM_<machinename> account and not the Local System
account. By default, the IWAM_<machinename> does "NOT" have the "Act as part of
the operating system" administrative credentials.
- Add the component that is called from the ASP page to a Microsoft Transaction Server (MTS) Server package or COM+ Server application, and then specify a specific user as the identity of the package.
Note The component runs in a separate .exe file that is outside of IIS.
- With basic/clear text authentication, we recommend that you encrypt the data by using SSL because it is extremely easy to obtain credentials from a network trace.
For more information about how to install SSL, click the following article number to view the article in the Microsoft Knowledge Base:
228991
How to create and install an SSL certificate in Internet Information Server 4.0
Note Do not forget that you can prevent network access for anonymous requests where password synchronization is disabled and requests are authenticated by using basic authentication (
Clear Text logons) if you set the
LogonMethod metabase property to "2" (indicating that a network logon is used to create the impersonation token). With this setting, the only way for requests to avoid the network token limitation is to connect to NullSessionShares or NullSessionPipes.
Do not use drive letters mapped to network shares. Not
only are there only 26 potential driver letters to select from, but if you try
to use a drive letter that is mapped in a different security context, problems can occur. Instead, you must always use Universal Naming Convention
(UNC) names to access resources. The format must look similar to the
following:
\\MyServer\filesharename\directoryname\filename
For more information about using UNC, click the following article number to view the article in the Microsoft Knowledge Base:
280383
IIS Security recommendations when you use a UNC share
The information in this article pertains only to Internet Information
Server 4.0. In Internet Information Server 5.0 (that is included with Windows
2000), there are significant changes to new authentication
types and capabilities. Although most of the concepts in this article
still apply to IIS 5.0, the details on the kinds of impersonation tokens that are generated with certain authentication schemes in this article apply
strictly to IIS 4.0.
319067 How to run applications not in the context of the system account
If you cannot determine what kind of logon is
occurring on your IIS server to handle requests, you can turn on auditing
for Logons and Logoffs. Follow these steps:
- Click Start, click Settings, click Control Panel, click Administrative Tools, and then click Local Security Policy.
- After you open Local Security Policy, in the left Tree View pane, click Security Settings, click Local Policies, and then click Audit Policy.
- Double-click Audit Logon Event and then click Success and Failure.
Event Log entries are
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