D
Daniel Knöpfel
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;Trusted_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();
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;Trusted_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();