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.WindowsImpersonationContext impersonationContext
impersonationContext = ((System.Security.Principal.WindowsIdentity)User.Identity).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.WindowsImpersonationContext impersonationContext
impersonationContext = System.Security.Principal.WindowsIdentity.Impersonate(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.

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.WindowsImpersonationContext impersonationContext;
impersonationContext = ((System.Security.Principal.WindowsIdentity)User.Identity).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.WindowsImpersonationContext impersonationContext;
impersonationContext = System.Security.Principal.WindowsIdentity.Impersonate(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?

 

[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:

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

Good luck,

Joe K.

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

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

Good luck,

Joe K.