Я работаю над страницей ASP.NET, в которой мы в коде выдаем себя за запрашивающего пользователя. Мы используем следующий код, чтобы начать олицетворение.
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()
После этого мы проверили, что приложение работает в правильном контексте, вызвав:
System.Security.Principal.WindowsIdentity.GetCurrent().Name
Возвращает правильную личность пользователя, и доступ к файлам и другим элементам, похоже, используют их учетную запись. Однако при использовании класса SqlHelper блока данных приложения Microsoft для вызова базы данных с использованием аутентификации доверенного соединения происходит сбой для пользователя «NT AUTHORITY \ ANONYMOUS LOGON».
После сбоя мы можем подтвердить, что текущая личность по-прежнему является нашей желаемой учетной записью, а НЕ АНОНИМНОЙ учетной записью.
У кого-нибудь есть идея, почему это так? Или, более конкретно, как мы можем обойти это?
Редактировать
Некоторая дополнительная информация о том, как работают звонки с этих страниц.
Мы делаем олицетворение вызова со страницы .aspx.
После того, как мы олицетворяем себя, мы обращаемся к сборке «бизнес-логики», на которую ссылаются.
Мы знаем, что контекстная идентичность здесь все еще верна.
После этого сборка «бизнес-логики» вызывает другую сборку, которая фактически выполняет вызов доверенного соединения. Мы не можем изменить эту сборку «доступа к данным», об этой аутентификации также сообщается об этой аутентификации.