Thread Unable to Impersonate (Workaround)

[Sam Page]

My ASP.NET aspx page can impersonate a userX and access a
UNC share just fine.

When I start a thread from the same aspx page, my real
intention, and try to impersonate in the thread method, I
fail with "Unable to Impersonate." The thread
successfully calls LogonUser, DuplicateTokens the
usertoken, creates a WindowsIdentity from the dupetoken,
then fails on the call to WindowsIdentity.Impersonate( ).
I have also tried ImpersonateLoggedOnUser.

Workaround:

If I change machine.config, processModel/@username
from 'machine' to 'system', everything works.

This is a workaround that leaves ASP.NET less secure. I'm
trying to find a way to assign the correct privileges and
associate the thread with the correct identity. No luck,
looking for ideas. Thanks.

[Lior Amar]

Your workaround is working cause the System account has extended privileges
and can act as part of the system. The LogonUser should give you a Token
that is imperonatable and should let you accomplish what you want (unless
your login on as a Sensitive account). That it doesn't is very strange. Your
ASPX page is impersonating a token that is coming from a client. What OS's
are running on the Client and Server? The only reason I ask, is that
LogonUser is a very bad API to use since it requires a cleartext password.
If both client and server are running on 2K or above and the network is
configured with ActiveDirectory then you should be able to utilize Kerberos
security and have the clients Token delegated to the next machine. When you
call DuplicateTokenEx, instead of passing it SecurityImpersonate..pass it
SecurityDelegation. If the token you received is coming in with the
Negotiate authentication then you should be ok to delegate the credentials
to the next machine. Multiple hops are a PAIN IN THE A** in windows but once
you get the configuration down, it's just a thing of beauty.

Read this article, it shows how to set this up:
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/ht[/url]
ml/SecNetHT05.asp

Now, for why it's not working under ASPNET but is under System. The ASPNET
account does not have the Act as part of System policy turned on. Pretty
sure that once you turn that on your problem will go away.

Give it a try and let me know...

Lior



"Sam Page" <pages2@removespamalot.wyeth.com> wrote in message
news:311c01c3749d$baa2ba20$a001280a@phx.gbl...

> My ASP.NET aspx page can impersonate a userX and access a
> UNC share just fine.
>
> When I start a thread from the same aspx page, my real
> intention, and try to impersonate in the thread method, I
> fail with "Unable to Impersonate." The thread
> successfully calls LogonUser, DuplicateTokens the
> usertoken, creates a WindowsIdentity from the dupetoken,
> then fails on the call to WindowsIdentity.Impersonate( ).
> I have also tried ImpersonateLoggedOnUser.
>
> Workaround:
>
> If I change machine.config, processModel/@username
> from 'machine' to 'system', everything works.
>
> This is a workaround that leaves ASP.NET less secure. I'm
> trying to find a way to assign the correct privileges and
> associate the thread with the correct identity. No luck,
> looking for ideas. Thanks.
>
>

[Slezak]

I agree, I'd rather know the appropriate way to perform this. I have
found a resource at
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconImpersonation.asp[/url]
that mentions this, but doesn't give a direct answer or example:

"Note Impersonation is local to a particular thread. When code
changes threads, such as when using thread pooling, the new thread
executes using the process identity by default. When impersonation is
required on the new thread, your application should save the security
token (WindowsIdentity.Token Property) from the original thread as
part of the state for the completion thread."

Even worse, this resource has some bad news:
[url]http://msdn.microsoft.com/msdnmag/issues/01/11/security/default.aspx[/url]

"However, impersonation in Windows was designed for use in trusted
server processes. If you make a call out to a random DLL, expecting it
to run with only the privileges afforded to IUSR_MACHINE, you may get
a big surprise. There is nothing stopping that DLL from simply
removing the thread token by calling RevertToSelf and running in the
security context of the process."

I'd still love to hear from someone that could explain passing
authentication to a child thread.

Brian


On Sat, 6 Sep 2003 10:38:48 -0700, "Sam Page"
<pages2@removespamalot.wyeth.com> wrote:

>My ASP.NET aspx page can impersonate a userX and access a
>UNC share just fine.
>
>When I start a thread from the same aspx page, my real
>intention, and try to impersonate in the thread method, I
>fail with "Unable to Impersonate." The thread
>successfully calls LogonUser, DuplicateTokens the
>usertoken, creates a WindowsIdentity from the dupetoken,
>then fails on the call to WindowsIdentity.Impersonate( ).
>I have also tried ImpersonateLoggedOnUser.
>
>Workaround:
>
>If I change machine.config, processModel/@username
>from 'machine' to 'system', everything works.
>
>This is a workaround that leaves ASP.NET less secure. I'm
>trying to find a way to assign the correct privileges and
>associate the thread with the correct identity. No luck,
>looking for ideas. Thanks.
>

[Tom Pester]

I am not that good in asp.net but I think I have this problem too.

I started a seperate thread in an asp.net page which creates a file in a
folder.
The procudure that does this works fine in an asp.net page but fails in the
thread.

Is this persmission related and how can I give the thread more rights.

Tank you,

Tom

"Sam Page" <pages2@removespamalot.wyeth.com> wrote in message
news:311c01c3749d$baa2ba20$a001280a@phx.gbl...

> My ASP.NET aspx page can impersonate a userX and access a
> UNC share just fine.
>
> When I start a thread from the same aspx page, my real
> intention, and try to impersonate in the thread method, I
> fail with "Unable to Impersonate." The thread
> successfully calls LogonUser, DuplicateTokens the
> usertoken, creates a WindowsIdentity from the dupetoken,
> then fails on the call to WindowsIdentity.Impersonate( ).
> I have also tried ImpersonateLoggedOnUser.
>
> Workaround:
>
> If I change machine.config, processModel/@username
> from 'machine' to 'system', everything works.
>
> This is a workaround that leaves ASP.NET less secure. I'm
> trying to find a way to assign the correct privileges and
> associate the thread with the correct identity. No luck,
> looking for ideas. Thanks.
>
>