Re: Simple thread issue?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

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

"bruce barker" <nospam@xxxxxxxxxx> wrote in message
news:u9aySqUSHHA.2256@xxxxxxxxxxxxxxxxxxxxxxx
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


.

Relevant Pages

  • Re: SetPassword access denied
    ... safely invoke SetPassword etc..... ... impersonation or using the process token without impersonation) is NOT ... account that is used for performing remote activities in the directory. ... Co-author of "The .NET Developer's Guide to Directory Services ...
    (microsoft.public.windows.server.active_directory)
  • Re: VS.NET 2005 and the "allowDefinition=MachineToApplication" error
    ... Your description of impersonation is great. ... If you want to use the default configured account, eliminate that entry, or configure it as: ... The easiest way to assign correct permissions to all required directories is to run: ... I re-started IIS and tried to access my ASPX page again -- same ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Simple thread issue?
    ... impersonation account. ... impersonation - it cannot be duplicated." ... SQL Server connection. ... way of telling why SQL cannot access the thread credentials? ...
    (microsoft.public.dotnet.framework.aspnet)
  • [Full-disclosure] Maybe nothing so shady; depends on the motive.
    ... There may be no impersonation going on. ... attempted use of a disabled account would produce messages about "account foo login fail" ... SecureWorks was still reading email addressed to David Maynor. ...
    (Full-Disclosure)
  • Re: ASP.NET IIS6 Impersonation - Explanation needed for this situa
    ... the impersonation setting does matter and the reason why is because ... the User isn't logging in with the SQL account which would be passed to SQL, ... Impersonation would not be a factor if the User's ...
    (microsoft.public.dotnet.security)