7

I have an ASP.NET app that requires users to sign in with their domain accounts using Basic Authentication. The user can make a selection, then press a button.

At some point after pressing the button is this code: WindowsIdentity.Impersonate(userIdentity.Token). userIdentity is of type WindowsIdentity, and it was previously set to (WindowsIdentity)User.Identity.

userIdentity is stored as a session variable, and I think that's because, after the button is pressed, the page containing this code is called via AJAX.

When I hit this code, it works about 2/3 of the time, but 1/3 of the time, I get this exception: Invalid token for impersonation - it cannot be duplicated. I think the biggest head scratcher for me is why does it work sometimes but not other times? On some sessions, it works several times before failing. On others, it fails right away.

Here's the stack trace:

at System.Security.Principal.WindowsIdentity.CreateFromToken(IntPtr userToken)

at System.Security.Principal.WindowsIdentity..ctor(IntPtr userToken, String authType, Int32 isAuthenticated)

at System.Security.Principal.WindowsIdentity.Impersonate(IntPtr userToken)

at Resource_Booker.BLL.ReservationAgent.SubmitReservationRequest(Reservation reservation, Patron patron) in C:\dev\RoomRes\Resource Booker\BLL\ReservationAgent.cs:line 101

at Resource_Booker.Reserve.reserve_Click(Object sender, EventArgs e) in C:\dev\RoomRes\Resource Booker\Reserve.aspx.cs:line 474

at System.EventHandler.Invoke(Object sender, EventArgs e)

at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)

at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Here's a confounding factor: I cannot reproduce this problem on my local Windows 7 x64 workstation--albeit my authentication is passed implicitly here since I am using localhost--or on a Windows 2003 32-bit IIS 6.0 environment. It only happens on a pretty vanilla Windows 2008 R2 environment. All these environments are domain members.

Community
  • 1
  • 1
Aren Cambre
  • 6,540
  • 9
  • 30
  • 36
  • This problem would scare me because it looks like an invalid handle was used internally by the .NET Framework. This is potentially security critical. – usr Jan 24 '12 at 21:30

1 Answers1

11

Basically what you are seeing is not a security problem as the logon session is cached by IIS for the lifetime of the TCP connection, but HTTP will occasionally cut the TCP connection requiring re-authentication. This will happen seamlessly and invisibly (handled by the browser) but it will invalidate the token, as the logon session will be destroyed when the TCP connection ends.

I.e. for the benefit of @usr, it only works sometimes because the logon session is the same so the token is the same, so the token stored in the session works because it happens to be the same actual token as User.Identity. It's not a way of avoiding the security check it is an implementation detail of the security check.

You shouldn't be storing the identity in the session - it is unnecessary since it is an authenticated connection.

Just use (WindowsIdentity)User.Identity every single time and your problem should go away.

Ben
  • 34,935
  • 6
  • 74
  • 113
  • 1
    That appears to be the problem. For a quick fix, I found where **userIdentity** was being pulled out of the session variable and forced the program to re-instantiate it. Thanks! – Aren Cambre Jan 31 '12 at 17:20
  • @Ben: Thanks for the very good explanation. I am asking me if (WindowsIdentity)User.Identity will work with windows authentication and manyToOneCertificateMapping enabled? I don't think so, unfortunately i cannot test this right now. – Kr15 Oct 28 '15 at 14:17
  • @Kr15, If the user is successfully authenticated with Windows Authentication, then `(WindowsIdentity)User.Identity` will work. – Ben Nov 01 '15 at 16:44