Simple thread issue?

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

"Brian" <br**********@hotmail.comwrote in message
news:uL*************@TK2MSFTNGP05.phx.gbl...

>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

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 wrote:

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

Hi Tim,

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

Brian

"Tim Mackey" <ti********@community.nospamwrote in message
news:F9**********************************@microsof t.com...

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

"Brian" <br**********@hotmail.comwrote in message
news:uL*************@TK2MSFTNGP05.phx.gbl...

>>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

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.Secur ity.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

"bruce barker" <no****@nospam.comwrote in message
news:u9**************@TK2MSFTNGP02.phx.gbl...

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 wrote:

>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

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.GetCurre nt();

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).Impe rsonate();
((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

"Brian" <br**********@hotmail.comwrote in message
news:uP**************@TK2MSFTNGP06.phx.gbl...

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.Secur ity.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

"bruce barker" <no****@nospam.comwrote in message
news:u9**************@TK2MSFTNGP02.phx.gbl...

>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 wrote:

>>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