Выдача себя за другое лицо в IIS 7.0

У меня есть веб-сайт, который правильно работает в IIS 6.0: он аутентифицирует пользователей с учетными данными Windows, а затем при разговоре со службой, которая обращается к БД, она передает учетные данные.

В IIS 7.0 одни и те же настройки конфигурации не передают учетные данные, и БД получает сообщение NT AUTHORITY \ ANONYMOUS.

Что-то мне не хватает? Я отключил АНОНИМНЫЙ доступ на своем веб-сайте IIS 7.0, но не могу заставить его работать.

Это настройки, которые я использую как в IIS 6.0, так и в 7.0:

<authentication mode="Windows">
<identity impersonate="true">

Что изменилось с 6.0 на 7.0?

Ответов (4)

Решение

Между IIS7 и IIS6.0 произошли изменения. Я нашел для вас одно сообщение в блоге, которое действительно может вам помочь ( щелкните здесь, чтобы увидеть его ).

Вы запускаете свое приложение в интегрированном режиме или в классическом режиме? Из того, что я видел, установка для атрибута Impersonate значения true должна отображать ошибку 500 со следующим сообщением об ошибке:

Внутренняя Ошибка Сервера. Это ошибка HTTP 500.19: запрошенная страница недоступна, поскольку соответствующие данные конфигурации для страницы недействительны.

Вот предлагаемый обходной путь:

Обходной путь:

1) Если ваше приложение не полагается на олицетворение запрашивающего пользователя на этапах BeginRequest и AuthenticateRequest (единственные этапы, на которых олицетворение невозможно в интегрированном режиме), игнорируйте эту ошибку, добавив следующее в файл web.config вашего приложения:

<validation validateIntegratedModeConfiguration="false"

/>

2) Если ваше приложение полагается на олицетворение в BeginRequest и AuthenticateRequest или вы не уверены, перейдите в классический режим.

Я надеялся, что это было полезно для понимания того, как теперь работает IIS 7.0.

Интересно ... У меня есть проблема противоположной - не будучи в состоянии получить аутентификацию передаются от клиентского браузера, через веб - сервер и на базу в большой корпоративной сеть через межсетевые экраны.

Я также считаю, что "сквозная пользовательская" аутентификация в базе данных - плохая идея и потенциальный риск для безопасности. Нет ничего, что могло бы помешать конечному пользователю загрузить SQL-запрос и напрямую подключиться к вашей базе данных, поэтому вам лучше заблокировать вашу схему!

@Esteban - Разъяснил мою не очень полезную помощь в ответе.

Обычно, если вы выполняете двойную аутентификацию таким образом, обычно задействуется Kerberos, если первая аутентификация не является базовой.

Я бы проверил аутентификацию на серверах IIS 6 и убедился, что на IIS 7 она такая же.

Если в поле IIS 6 установлено значение Windows Integrated, вам необходимо проверить настройки Kerberos - SPN, делегирование и т. Д.

Настроен ли ваш сервер IIS для делегирования SQLServer доверенным? Я сталкивался с этим раньше с WebDAV, где нам приходилось иметь сервер, на котором запущен IIS, которому файловый сервер доверяет для аутентификации от имени файлового сервера.