IN THIS TASK
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.
Authentication Type Impersonation Type
Anonymous Access (no authentication) Network
Auto Password Synchronization is
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
- 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.
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.
- 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."All access to the computer that shares the network resources is performed in the context of the person specified under the Connect As.. dialog box. This occurs no matter what kind of authentication is configured for the virtual directory. By using this option, all files on the network share are available from browsers that access the IIS 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.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
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:
- 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: