Framework v1.1 & LogonUser workaround

[Bill Belliveau]

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 Kaplan \(MVP - ADSI\)]

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" <anonymous@discussions.microsoft.com> wrote in message
news:24E1DCFE-F4F1-479E-BC13-95B2507E376E@microsoft.com...

> 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

[Bill Belliveau]

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.

[Joe Kaplan \(MVP - ADSI\)]

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:

[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemSecurityPrincipalWindowsImpersonationCo ntextClassTopic.asp?frame=true[/url]

Good luck,

Joe K.

"Bill Belliveau" <anonymous@discussions.microsoft.com> wrote in message
news:ADEB1A74-56A1-46DC-995F-4EC005F56C44@microsoft.com...

> 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.

[Bill Belliveau]

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:

[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemSecurityPrincipalWindowsImpersonationCo ntextClassTopic.asp?frame=true[/url]

Good luck,

Joe K.