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