HOWTO: Accessing Network Files from IIS
Applications |
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.
- Add the component being called from the ASP page to a
Microsoft Transaction Server (MTS) Server package or COM+ Server
application, and specify a specific user as the identity of the
package. Note that the component will run in a separate .exe file
outside of IIS.
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 :
Issue type : kbhowto
Technology : |
|
.gif) |
|
Send to a friend