«

Greetings
I am working on a project that can be configured to use Windows or Forms authentication. Occasionally the process may need to impersonate the calling user

Using Windows Authentication was fairly easy
-- ms code snippet -
System.Security.Principal.WindowsImpersonationCont ext impersonationContext
impersonationContext = ((System.Security.Principal.WindowsIdentity)User.I dentity).Impersonate()
---

To handle a forms logon
-- code snippet -
IntPtr token = IntPtr.Zero
if(LogonUser(txtUserName.Text, txtDomainName.Text, txtPassword.Text
LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, ref token) != 0)

System.Security.Principal.WindowsImpersonationCont ext impersonationContext
impersonationContext = System.Security.Principal.WindowsIdentity.Imperson ate(token)


Of course LogonUser requires that the process have “Act as part of the operating system” permissions, which by default the ASPNET process does not. My confusion comes from reading Microsoft’s patterns and practices, “Building Secure Microsoft ASP.NET Application”. LogonUser is mentioned many times and usually has a warning block stating the above issue and that the .NET Framework v1.1 will work around the issue by having the IIS process perform the logon instead. That doesn’t appear to be the case however. Can anyone confirm if a workaround was in fact implemented

Thanks
Bill

In many ways, this is an OS issue. Win2K generally only lets the SYSTEM
account call LogonUser, as that is the only account by default with the
SE_TCB_NAME privilege (act as part of the OS), and that is a good thing. In
WinXP and 2003, LogonUser no longer requires SE_TCB_NAME, so many more
accounts may call it.

Framework 1.1 helps with this situation in that there is a nice overload on
the WindowsIdentity constructor that creates a new WindowsIdentity from
username/password, but it still doesn't defeat OS security rules.

The best thing you could do from a security perspective is move to 2K3
server so that you can call LogonUser without any real issues. On 2000, you
must run as SYSTEM (or given another account SE_TCB_NAME, essentially making
it SYSTEM if it wants to be) to do what you want. ASP.NET and IIS let you
do this, but it is better to avoid it.

The other thing to do would be to move away from Forms auth. so that you can
let IIS do the authentication for you, but that doesn't sound like what you
want.

I'm not sure if I helped, but hopefully this was useful.

Joe K.

"Bill Belliveau" <> wrote in message
news:24E1DCFE-F4F1-479E-BC13-...
> Greetings.
> I am working on a project that can be configured to use Windows or Forms
authentication. Occasionally the process may need to impersonate the
calling user.
>
> Using Windows Authentication was fairly easy:
> -- ms code snippet --
> System.Security.Principal.WindowsImpersonationCont ext
impersonationContext;
> impersonationContext =
((System.Security.Principal.WindowsIdentity)User.I dentity).Impersonate();
> ----
>
> To handle a forms logon:
> -- code snippet --
> IntPtr token = IntPtr.Zero;
> if(LogonUser(txtUserName.Text, txtDomainName.Text, txtPassword.Text,
> LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, ref token) != 0)
> {
> System.Security.Principal.WindowsImpersonationCont ext
impersonationContext;
> impersonationContext =
System.Security.Principal.WindowsIdentity.Imperson ate(token);
> }
>
> Of course LogonUser requires that the process have "Act as part of the
operating system" permissions, which by default the ASPNET process does not.
My confusion comes from reading Microsoft's patterns and practices,
"Building Secure Microsoft ASP.NET Application". LogonUser is mentioned
many times and usually has a warning block stating the above issue and that
the .NET Framework v1.1 will work around the issue by having the IIS process
perform the logon instead. That doesn't appear to be the case however. Can
anyone confirm if a workaround was in fact implemented?
>
> Thanks,
> Bill

Joe, thanks for the info it does help, mostly to let me know I'm on the right track
I am curious though, which WindowsIdentity constructor takes a username/password? I didn’t see any constructors or examples. Even though we are targeting 2003, that would seem like a better method rather than calling unmanaged code (even though the same thing happens behind the curtain)

Bil

----- Joe Kaplan (MVP - ADSI) wrote: ----

In many ways, this is an OS issue. Win2K generally only lets the SYSTE
account call LogonUser, as that is the only account by default with th
SE_TCB_NAME privilege (act as part of the OS), and that is a good thing. I
WinXP and 2003, LogonUser no longer requires SE_TCB_NAME, so many mor
accounts may call it

Framework 1.1 helps with this situation in that there is a nice overload o
the WindowsIdentity constructor that creates a new WindowsIdentity fro
username/password, but it still doesn't defeat OS security rules

The best thing you could do from a security perspective is move to 2K
server so that you can call LogonUser without any real issues. On 2000, yo
must run as SYSTEM (or given another account SE_TCB_NAME, essentially makin
it SYSTEM if it wants to be) to do what you want. ASP.NET and IIS let yo
do this, but it is better to avoid it

The other thing to do would be to move away from Forms auth. so that you ca
let IIS do the authentication for you, but that doesn't sound like what yo
want

I'm not sure if I helped, but hopefully this was useful

Joe K.

My apologies, but you are right, there is no constructor like that. For
some reason I remembered seeing that in the reference, but it is fact not
there at all. I claim temporary insanity!

I guess it is back to LogonUser. Sorry about that.

FWIW, there is a nice sample of calling LogonUser via P/Invoke in VB.NET and
C# here. It is much better than the sample they published for Framework
1.0:

http://msdn.microsoft.com/library/de...asp?frame=true

Good luck,

Joe K.

"Bill Belliveau" <> wrote in message
news:ADEB1A74-56A1-46DC-995F-...
> Joe, thanks for the info it does help, mostly to let me know I'm on the
right track.
> I am curious though, which WindowsIdentity constructor takes a
username/password? I didn't see any constructors or examples. Even though
we are targeting 2003, that would seem like a better method rather than
calling unmanaged code (even though the same thing happens behind the
curtain).
>
> Bill
>
> ----- Joe Kaplan (MVP - ADSI) wrote: -----
>
> In many ways, this is an OS issue. Win2K generally only lets the
SYSTEM
> account call LogonUser, as that is the only account by default with
the
> SE_TCB_NAME privilege (act as part of the OS), and that is a good
thing. In
> WinXP and 2003, LogonUser no longer requires SE_TCB_NAME, so many
more
> accounts may call it.
>
> Framework 1.1 helps with this situation in that there is a nice
overload on
> the WindowsIdentity constructor that creates a new WindowsIdentity
from
> username/password, but it still doesn't defeat OS security rules.
>
> The best thing you could do from a security perspective is move to
2K3
> server so that you can call LogonUser without any real issues. On
2000, you
> must run as SYSTEM (or given another account SE_TCB_NAME, essentially
making
> it SYSTEM if it wants to be) to do what you want. ASP.NET and IIS
let you
> do this, but it is better to avoid it.
>
> The other thing to do would be to move away from Forms auth. so that
you can
> let IIS do the authentication for you, but that doesn't sound like
what you
> want.
>
> I'm not sure if I helped, but hopefully this was useful.
>
> Joe K.

Thanks again
Bill

----- Joe Kaplan (MVP - ADSI) wrote: -----

My apologies, but you are right, there is no constructor like that. For
some reason I remembered seeing that in the reference, but it is fact not
there at all. I claim temporary insanity!

I guess it is back to LogonUser. Sorry about that.

FWIW, there is a nice sample of calling LogonUser via P/Invoke in VB.NET and
C# here. It is much better than the sample they published for Framework
1.0:

http://msdn.microsoft.com/library/de...asp?frame=true

Good luck,

Joe K.