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

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.

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.

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.

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

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.

For additional information about using impersonation in ASP.NET applications and using integrated security when you connect to SQL Server, click the following article numbers to view the articles in the Microsoft Knowledge Base: For more information about hotfixes and other related updates for ASP.NET and the .NET Framework, visit the following Microsoft Web sites: