Question

I am working on an ASP.NET page that we, in code impersonate the requesting user. We are using the following code to start impersonating.

Dim impersonationContext As System.Security.Principal.WindowsImpersonationContext Dim currentWindowsIdentity As System.Security.Principal.WindowsIdentity currentWindowsIdentity = CType(User.Identity, System.Security.Principal.WindowsIdentity) impersonationContext = currentWindowsIdentity.Impersonate() 

After this we have validated that the application is running under the proper context by calling:

System.Security.Principal.WindowsIdentity.GetCurrent().Name 

This returns the proper identity of the user, and file access and other items appear to be using their account. However when using the Microsoft Application Data Application Block SqlHelper class to call out to a database using a trusted connection authentication fails for the ‘NT AUTHORITY\ANONYMOUS LOGON’ user.

We can re-validate after the failure that the current identity is still our desired account and NOT the ANONYMOUS LOGIN account.

Does anyone have an idea why this is? Or more specifically how we can get around it?

Edit Some additional information about how the calls from these pages work.

We do the impersonate call from the .aspx page.

After we impersonate we call out to a ‘business logic’ assembly that is referecned.

We know that the context identity is still correct here.

After that, the ‘business logic’ assembly calls another assembly that actually executes the trusted connection call. We cannot modify this ‘data access’ assembly, the authentication exception is reported by this assembly as well.

Answer 1

I think @John Sonmez is right, you’re hitting the Double Hop issue. Impersonation is only half of the story, you also need to look at Delegation (assuming your network is using Kerberos authentication). The articles below were the most useful in helping me through the same issue

Impersonation and Delegation

ASP.NET Delegation