BUG: Impersonation May Not Work When You Use ASP.NET SQL Server Session State with Integrated Security (326606)
The information in this article applies to:
- Microsoft ASP.NET (included with the .NET Framework 1.1)
- Microsoft ASP.NET (included with the .NET Framework) 1.0
- Microsoft SQL Server
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.
STATUSMicrosoft has confirmed that this is a bug in the Microsoft
products that are listed at the beginning of this article.
MORE INFORMATIONSQL 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.REFERENCES 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: 306158
INFO: Implementing Impersonation in an ASP.NET Application
316989 PRB: "Login
Failed" Error Message When You Create a Trusted Data Connection from ASP.NET to
SQL Server
For more information about hotfixes and other
related updates for ASP.NET and the .NET Framework, visit the following
Microsoft Web sites:
| Modification Type: | Minor | Last Reviewed: | 7/8/2005 |
|---|
| Keywords: | kbbug kbHttpRuntime kbSecurity kbState KB326606 |
|---|
|