Simple thread issue?

[Brian]

I have an file based asp.net application the creates a thread to do some
background printing. It works fine but when the application is deployed on a
web server, the following error occurs in the thread when it accesses SQL:

Login failed for user ''. The user is not associated with a trusted SQL
Server connection.

Note the blank user. It seems that the new thread does not have the
credentials but looking at "Thread.CurrentPrincipal", there is a valid user
(me).

Is there something I am missing? Does the application need some assembly
permissions? I wonder if there are any settings under IIS? Is there any way
of telling why SQL cannot access the thread credentials?

Brian

 

[Tim Mackey]

hi brian,
can you try it without using any threading code? also, verify that the code
is using a valid connection string. is it set to use integrated/windows
account logon? you've probably already tested that but no harm to check the
obvious things first.

tim

 

[bruce barker]

when you create a thread, its identity is the process identity, not the
starting threads identity, so it will not match the pool account or
impersonation account. the the case of asp.net, its the id of the worker
process usually a network service account.

you need to pass the desired identity to the new thread and have the new
thread impersonate it.

-- bruce (sqlwork.com)

 

[Brian]

Hi Tim,

Yes it works fine without the threading code so the connection string is
valid which uses integrated/windows security account.

Brian

 

[Brian]

Hi Bruce,

Thanks for your comment - it sounds like you are right on the mark!
I tried adding the following line of code to the new thread. Note that
"this.Context.User" seems to return the correct security principle - the
impersonation account. It is also identical to Thread.CurrentPrincipal
before the statement. Is there something I have missed setting the thread
identity to impersonate the asp.net account?

Thread.CurrentPrincipal = this.Context.User;

I also tried adding the following statement because the app.domain principal
policy in the new thread (only under asp.net) defaulted to
"unauthenticated".

Thread.GetDomain().SetPrincipalPolicy(System.Security.Principal.PrincipalPolicy.WindowsPrincipal);

This too didn't make any difference - the error was the same when the code
is run in a thread under asp.net (otherwise it works fine).

I note that "this.Context.Request.LogonUserIdentity" normally returns the
same as "this.Context.User.WindowsIdentity", except when running under the
thread account in which case it returns, "Invalid token for impersonation -
it cannot be duplicated." Is this the problem? Is there any way around this?

Thanks very much for your help in this. By the way do you know if there any
documentation on all this? Is there any other way of setting the thread
identity?

Brian

 

[Brian]

Hi Bruce,

I found another post under microsoft.public.dotnet.framework.aspnet.security
called "Exception when use asp.net with .net remoting". This suggested
looking at:

System.Security.Principal.WindowsIdentity.GetCurrent();

This seems to be empty in the child thread so I added the following code to
the thread (either of these lines work):
((WindowsIdentity)this.Context.User.Identity).Impersonate();
((WindowsIdentity)Thread.CurrentPrincipal.Identity).Impersonate();

This fixes the problem when running on Windows XP but on windows 2003 it
returns printing (system.drawing error) which I'll have to look into.

Thanks again,
Brian