ASPNET and Impersonation

[Shel Blauman [MSFT]]

Maybe someone the aspnet.security group has some other suggestions.

Shel

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
[url]http://www.microsoft.com/info/cpyright.htm[/url]


"Charles Leonard" <elmsdn13@hotmail.com> wrote in message
news:125001c372fe$50b429f0$a101280a@phx.gbl...

> In case anyone is interested, the solution to the above
> problem appears to be that there is no solution-at least
> not through any additional configuration using the
> Web.config file.
>
> There is some hint of achieving such authorization
> programmatically using "advapi32.dll" and the LogonUser()
> API. However, there is a suggestion that any such code
> may not work on all platforms.
>
> In any event, I took another approach to solve the
> problem. By modifying the Machine.config file (in the
> directory C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
> \CONFIG) and changing the <processModel> contents of
> userName and password from the default settings to the
> userName and password references I had previously defined
> for the <identity> tag of my Web.config file, the identity
> problem with thread creation is resolved and access to
> the "shared drive" is achieved by both threads without
> further incident.
>
> The unfortunate drawback in this approach is that the
> process identity for all .Net applications installed on
> the machine will be the one defined in the Machine.config
> file (instead of being localized to the single Web Service
> being configured by the Web.config file).
>
> If anyone does find away to achieve Impersonation that
> actually can be applied to all threads created by the
> target web service (and/or configured by the Web.config
> file), let me know. And for that matter, if anyone has a
> better suggestion on how to access a shared drive without
> using Impersonation or changing the process identity, I'd
> be very interested in this as well.
>
> Thanks.
>
> --Charles Leonard
>
> References:
>
> [url]http://www.15seconds.com/Issue/030115.htm?voteresult=5[/url]
> [url]http://support.microsoft.com/default.aspx?[/url]
> scid=http://support.microsoft.com:80/support/kb/articles/q3
> 17/0/12.asp&NoWebContent=1
> [url]http://msdn.microsoft.com/library/default.asp?[/url]
> url=/library/en-us/vsent7/html/vxconimpersonation.asp
> [url]http://www.msdnaa.net/Resources/Display.aspx?ResID=641[/url]
> [url]http://support.microsoft.com/default.aspx?[/url]
> scid=http://support.microsoft.com:80/support/kb/articles/q3
> 06/1/58.asp&NoWebContent=1
> [url]http://www.codeproject.com/csharp/cpimpersonation1.asp[/url]
> [url]http://www.codeproject.com/csharp/lsadotnet.asp[/url]
>
>

> >-----Original Message-----
> >OK. So just when I think I am making progress, 2 steps
> >forward, I am thrown another curve ball, one step
> >backwards. I am employing impersonation for my Web
> >Service. Impersonation is being used because of a
> >requirement that we have to access a "shared drive."
> >
> >Here is what I have done:
> >
> >1. aspnet_setreg.exe has been used to encrypt my
> > credentials.
> >2. Web.config has been edited to include:
> >
> ><identity impersonate="true"
> >
> >userName="registry:HKLM\SOFTWARE\MySoftware\ident ity\ASPNE

> T

> >_SETREG,userName"
> >
> >password="registry:HKLM\SOFTWARE\MySoftware\ident ity\ASPNE

> T

> >_SETREG,password"
> > />
> >
> >So far, so good. When I run my web service, the
> >impersonation happens. Which is great-except for one
> >thing. My web service creates a thread. The thread must
> >also access the same network share. Unfortunately, the
> >thread is reverting back to the "ASPNET" user despite the
> >Web.config settings.
> >
> >Does anyone know how to correct this problem?

> Preferably,

> >I'd like to correct it through configuration settings, if
> >possible, rather than programmatically. But, I will
> >welcome all suggestions.
> >
> >Thanks.
> >
> >--Charles Leonard
> >
> >.
> >

[Lior Amar]

Well sounds to me like this should be easy...but then again, I can't see all
the messages of this thread. Try the following, grab the Token from your
current thread and call the API ImpersonateLoggedOnUser from the new thread.
I've recently done this for a similar problem and it works well. My
suggestion is for you to read up on how .NET in general handles security and
it will clarify things for you...at least it did for me. The CLR is a
mystical little piece of technology ;)

You should also follow my last post, I asked the ASPNET team if this will
cause some major bad stuff to occur in their process. My current tests seem
good.

Token -> System.Security.Principal.WindowsIdentity.GetCurre nt.Token.ToInt32

ImpersonateLoggedOnUser -> Look it up in MSDN...really simple to
call...Don't forget to RevertToSelf.


Hope this helps,

Lior

"Shel Blauman [MSFT]" <sheldonb@online.microsoft.com> wrote in message
news:#D#vPuwcDHA.1744@TK2MSFTNGP12.phx.gbl...

> Maybe someone the aspnet.security group has some other suggestions.
>
> Shel
>
> --
> This posting is provided "AS IS" with no warranties, and confers no

rights.

> Use of included script samples are subject to the terms specified at
> [url]http://www.microsoft.com/info/cpyright.htm[/url]
>
>
> "Charles Leonard" <elmsdn13@hotmail.com> wrote in message
> news:125001c372fe$50b429f0$a101280a@phx.gbl...

> > In case anyone is interested, the solution to the above
> > problem appears to be that there is no solution-at least
> > not through any additional configuration using the
> > Web.config file.
> >
> > There is some hint of achieving such authorization
> > programmatically using "advapi32.dll" and the LogonUser()
> > API. However, there is a suggestion that any such code
> > may not work on all platforms.
> >
> > In any event, I took another approach to solve the
> > problem. By modifying the Machine.config file (in the
> > directory C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
> > \CONFIG) and changing the <processModel> contents of
> > userName and password from the default settings to the
> > userName and password references I had previously defined
> > for the <identity> tag of my Web.config file, the identity
> > problem with thread creation is resolved and access to
> > the "shared drive" is achieved by both threads without
> > further incident.
> >
> > The unfortunate drawback in this approach is that the
> > process identity for all .Net applications installed on
> > the machine will be the one defined in the Machine.config
> > file (instead of being localized to the single Web Service
> > being configured by the Web.config file).
> >
> > If anyone does find away to achieve Impersonation that
> > actually can be applied to all threads created by the
> > target web service (and/or configured by the Web.config
> > file), let me know. And for that matter, if anyone has a
> > better suggestion on how to access a shared drive without
> > using Impersonation or changing the process identity, I'd
> > be very interested in this as well.
> >
> > Thanks.
> >
> > --Charles Leonard
> >
> > References:
> >
> > [url]http://www.15seconds.com/Issue/030115.htm?voteresult=5[/url]
> > [url]http://support.microsoft.com/default.aspx?[/url]
> > scid=http://support.microsoft.com:80/support/kb/articles/q3
> > 17/0/12.asp&NoWebContent=1
> > [url]http://msdn.microsoft.com/library/default.asp?[/url]
> > url=/library/en-us/vsent7/html/vxconimpersonation.asp
> > [url]http://www.msdnaa.net/Resources/Display.aspx?ResID=641[/url]
> > [url]http://support.microsoft.com/default.aspx?[/url]
> > scid=http://support.microsoft.com:80/support/kb/articles/q3
> > 06/1/58.asp&NoWebContent=1
> > [url]http://www.codeproject.com/csharp/cpimpersonation1.asp[/url]
> > [url]http://www.codeproject.com/csharp/lsadotnet.asp[/url]
> >
> >

> > >-----Original Message-----
> > >OK. So just when I think I am making progress, 2 steps
> > >forward, I am thrown another curve ball, one step
> > >backwards. I am employing impersonation for my Web
> > >Service. Impersonation is being used because of a
> > >requirement that we have to access a "shared drive."
> > >
> > >Here is what I have done:
> > >
> > >1. aspnet_setreg.exe has been used to encrypt my
> > > credentials.
> > >2. Web.config has been edited to include:
> > >
> > ><identity impersonate="true"
> > >
> > >userName="registry:HKLM\SOFTWARE\MySoftware\ident ity\ASPNE

> > T

> > >_SETREG,userName"
> > >
> > >password="registry:HKLM\SOFTWARE\MySoftware\ident ity\ASPNE

> > T

> > >_SETREG,password"
> > > />
> > >
> > >So far, so good. When I run my web service, the
> > >impersonation happens. Which is great-except for one
> > >thing. My web service creates a thread. The thread must
> > >also access the same network share. Unfortunately, the
> > >thread is reverting back to the "ASPNET" user despite the
> > >Web.config settings.
> > >
> > >Does anyone know how to correct this problem?

> > Preferably,

> > >I'd like to correct it through configuration settings, if
> > >possible, rather than programmatically. But, I will
> > >welcome all suggestions.
> > >
> > >Thanks.
> > >
> > >--Charles Leonard
> > >
> > >.
> > >

>
>