I am working on an ASP.NET page that we, in code, impersonate as the requesting user. We use the following code to start impersonating it.
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 that, we confirmed that the application works under the appropriate context by calling:
System.Security.Principal.WindowsIdentity.GetCurrent().Name
This returns the correct user identity, and file access and other items seem to be using their account. However, when using the SqlHelper Application Application Application Block class to call to the database using authentication with a reliable connection for the user "NT AUTHORITY \ ANONYMOUS LOGON".
We can reaffirm after a failure that the current authentication is still our desired account, NOT a ANONYMOUS LOGIN account.
Does anyone have an idea why this is so? Or, more precisely, how can we get around this?
Edit Some additional information on how calls from these pages work.
We make a personifying call from the .aspx page.
After we personalize ourselves, we turn to the assembly "business logic", which is abstracted.
We know that context identity is still true.
After that, the Business Logic assembly calls another assembly that actually makes a trusted connection call. We cannot modify this "data access" assembly, and this assembly also reports an authentication exception.