Framework v1.1 & LogonUser workaround

Discussion in 'ASP .Net Security' started by Bill Belliveau, Jan 26, 2004.

  1. 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
    Bill Belliveau, Jan 26, 2004
    #1
    1. Advertising

  2. 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:...
    > 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\), Jan 27, 2004
    #2
    1. Advertising

  3. 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.
    Bill Belliveau, Jan 27, 2004
    #3
  4. 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.

    "Bill Belliveau" <> wrote in message
    news:...
    > 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.
    Joe Kaplan \(MVP - ADSI\), Jan 27, 2004
    #4
  5. 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.
    Bill Belliveau, Jan 27, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mary Chipman

    Re: Impersonation in ASPNET and LogonUser

    Mary Chipman, Sep 3, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    451
    Mary Chipman
    Sep 3, 2003
  2. Jason

    impersonating and LogonUser

    Jason, Dec 30, 2003, in forum: ASP .Net
    Replies:
    7
    Views:
    437
    Jim Cheshire [MSFT]
    Jan 5, 2004
  3. Nimi

    LogonUser failed error

    Nimi, Oct 14, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    2,398
    Martin Dechev
    Oct 14, 2004
  4. Rich
    Replies:
    1
    Views:
    8,054
    Scott Allen
    Nov 2, 2004
  5. Darrell

    win32security.LogonUser

    Darrell, Jul 8, 2003, in forum: Python
    Replies:
    1
    Views:
    1,332
    John Abel
    Jul 8, 2003
Loading...

Share This Page