471,595 Members | 1,735 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,595 software developers and data experts.

non-reproducable problems with impersonationin asp.net: login failed for user 'null' after impersonation

Hello

On our asp.net 2.0 website we impersonate every request to the identity of
the user logged in. This works this way:
1. user logs in, providing username, password
2. user is authenticated against an active directory and the windows
identity is retrieved (and stored in the session!!)
3. user is impersonated using the windows identity (thread is now
running under the identity of the user)

Now for every request that is incomming, the windows identity is
retrieved and the user is impersonated. By impersonating the thread in this
way we can access the sql server 2000 using windows authentication
(connectino string:
<add key="DBConnectionString"
value="Server=servername;Database=databaseToUse;Tr usted_Connection=yes;"/>

) We have to live with this implementation as it is.

This works fine in 99.99 % of all cases. Unforuntately, sometimes we get the
follwowing error coming from the sql-server: "login failed for user null"
This suggest that the windows authentication failed because impersonation
was flawed. After this happened access to the sql server is no longer
possible, one has to log out and relogin to make db access work again. We
are quite at loss concerning this problem. We got a few theories:

- The Connection string or how we use the ADO.NET data access classes are
missing something

- The kerberos ticket is obselet. Maybe some other action on the active
directory made ticket obselet!

- the impersonation failed because server (active directory) was not
available or overloaded

- Session is lost and the windows identity token can no longer be used for
impersonisation

If the way we are using impersonation and asp.net is somehow flawed, i would
be very glad if someone could help us. (however we cannot change the entire
process on how we handle access to the db as we got no time/money for this)
Escpecially if there are some settings to the connection string or the
handlling of the ado.net classes. Of course i would welcome any other idea..

Thanks in advance

Greetings

Daniel

By the way, impersonation is done the following way (no big deal):

System.Security.Principal.WindowsIdentity wi;

wi = ((Page)pEnvironment).Session["Identity"] as WindowsIdentity;

wi.Impersonate();



Dec 19 '06 #1
0 1425

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by lothar | last post: by
3 posts views Thread by Mario | last post: by
25 posts views Thread by Yves Glodt | last post: by
32 posts views Thread by Adrian Herscu | last post: by
22 posts views Thread by Steve - DND | last post: by
399 posts views Thread by =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= | last post: by
12 posts views Thread by puzzlecracker | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by Anwar ali | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.