Microsoft KB Archive/326606

= BUG: Impersonation May Not Work When You Use ASP.NET SQL Server Session State with Integrated Security =

Article ID: 326606

Article Last Modified on 3/22/2007

-

APPLIES TO


 * Microsoft ASP.NET 1.1
 * Microsoft ASP.NET 1.0
 * Microsoft SQL Server 1.1 Standard Edition

-



This article was previously published under Q326606



SYMPTOMS
When impersonation is enabled for an ASP.NET application that uses SQL Server mode session state management with integrated security, you may see issues that occur when session state is lost or locked for a long time.



CAUSE
ASP.NET may not use impersonation in the following scenarios:
 * When you write session state back to SQL Server.
 * When you use polling to acquire session state because another user is seen as holding on the same session state data.



WORKAROUND
To work around this problem, use one of the following methods:
 * Do not use impersonation.
 * If you must use impersonation, do not use integrated security with SQL Server session mode state management.
 * If you must use both impersonation and integrated security with SQL Server session mode state management, grant access to the account that is specified in the userName setting of the processModel element. This is located in the Machine.config file on the computer that is running SQL Server.



STATUS
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.



MORE INFORMATION
SQL Server session state implements its own connection pooling for open SqlConnection objects. When SQL Server session state saves the data back to the SQL Server database, it uses a background thread. The background thread runs under the ASP.NET worker process (Aspnet_wp.exe in the default ASP.NET installation on Microsoft Windows 2000 and on Microsoft Windows XP, and W3wp.exe in the default ASP.NET installation in Microsoft Windows Server 2003) account. The SQL Server connection attempt is successful if an open SqlConnection object can be found in the pool. However, if no open SqlConnection object can be found in the pool, a SqlConnection object is created through the ASP.NET worker process account. If this account does not have permission to connect to the computer that is running SQL Server, the connection is not successful, and this also results in an unsuccessful attempt to write the session data back to the computer that is running SQL Server. By default, a writer lock is used for a session when the session is accessed. Because of this, the session remains locked until a timeout occurs.

