Making an Asynchronous Call using the Impersonation Identity

If you try to make an asynchronous call, you will notice that the thread that executes the call doesn’t run under the same account as the thread that called it, assuming you are using impersonation.

There are a number of ways to change this if you would like to have it use the same identity.

Method 1

The Thread used by BeginInvoke doesn’t copy the windowsIdentity from the calling thread. You have to impersonate the new thread manually:
Before calling BeginInvoke save the current identity into a variable:

Dim identity as WindowsIdentity
identity = System.Security.Principal.WindowsIdentity.GetCurrent()

Inside the asynchronously called method use this variable and execute:


From that point on the asynchronous call uses the same privileges than the calling thread and it should not be a problem to execute the callback.

Method 2

If the thread making the asynchronous call creates the thread being used, and you are using .NET 2.0 or later, you can set the following in the config file.  For ASP.NET, use the aspnet.config file:

<alwaysFlowImpersonationPolicy enabled="true"/>
<legacyImpersonationPolicy enabled="false"/>

Method 3

Another way to handle this is if you have an account that you want the asynchronous call to run under, you can impersonate that account, run what you need to, and then undo the impersonation.  The following code will do that:

using System.Security.Principal;
WindowsIdentity wi = new WindowsIdentity(userName@fullyqualifieddomainName);
WindowsImpersonationContext ctx = null;
  ctx = wi.Impersonate();
  // Thread is now impersonating
  // Prevent exceptions propagating.
  // Ensure impersonation is reverted

Additional Information

For more information, you can check out these links

kick it on

Comments (5)

  1. You’ve been kicked (a good thing) – Trackback from

  2. Have you ever wanted to make an asynchronous call but use the credentials of the user that is browsing

  3. Hey,

    method 3 uses protocol transition – thats ony available on Server 2003+ in 2003+ level AD domains.

    Also the impersonation token you get from this technique cannot be used to access local resources (unless you run as SYSTEM). Remote resources can only be accessed using constrained delegation (with the ‘any authentication protocol’ option). fyi.

  4. tomchris says:


    Thanks for this info.  If you require these limitations to be lifted, you can use the LogonUser API from the first link referenced in the Additional Information.

  5. Hi,

    it was just a fyi. Method 3 will not work for the most cases.

    …and LogonUser would require a password 😉