Имперсонация в IIS 7.0
У меня есть веб-сайт, который корректно работает под IIS 6.0: Он аутентифицирует пользователей с помощью учетных данных windows, а затем при обращении к службе, которая обращается к БД, он передает учетные данные.
В IIS 7.0 те же настройки конфигурации не передают учетные данные, и в БД попадает NT AUTHORITY\ANONYMOUS.
Может быть, я что-то упускаю? Я отключил доступ ANONYMOUS на моем сайте IIS 7.0, но я не могу заставить его работать.
Вот настройки, которые я использую в IIS 6.0 и 7.0:
<authentication mode="Windows">
<identity impersonate="true">Что изменилось с 6.0 на 7.0?
Произошли изменения между и iis6 и IIS7.0. Я нашел для вас одну запись в блоге, которая может реально помочь вам (нажать здесь, чтобы увидеть это).
Вы запускаете приложение в режиме интеграции или в классическом режиме? Из того, что я увидел, поставив олицетворение атрибута в true должен отображать вас 500 ошибка со следующим сообщением об ошибке:
Внутренняя ошибка сервера. Это HTTP ошибка 500.19: запрашиваемая страница невозможен, так как связанные Данные конфигурации для этой страницы признано недействительным.
Вот временное решение, предложил:
решение:
- Если ваше приложение не полагаться на олицетворении запрашивающего пользователя в BeginRequest и этапы AuthenticateRequest (только этапы, где олицетворение не можно в режиме интеграции), игнорировать эту ошибку путем добавления следующих веб-приложения.конфиг: <система.вебсервер>
<validateIntegratedModeConfiguration проверка=на"ложные"и />
</система.вебсервер>
- Если ваше приложение не полагаться на олицетворения в BeginRequest и AuthenticateRequest, или вы не конечно, перейти в классический режим.
Я надеялся, что это было полезно понять, как службы IIS 7.0 теперь работает.
Настроен ли ваш сервер IIS так, чтобы ему доверялось делегирование SQLServer? Я уже сталкивался с этим при работе с WebDAV, когда нам приходилось доверять серверу, на котором работает IIS, доверять файловому серверу для аутентификации от имени файлового сервера.
Интересно... У меня противоположная проблема - Невозможность заставить аутентификацию проходить от браузера клиента, через веб-сервер и в базу данных в большой корпоративной сети через брандмауэры.
Я также считаю, что "сквозная" аутентификация конечного пользователя в базе данных - плохая идея и потенциальный риск безопасности. Ничто не помешает конечному пользователю загрузить SQL Query и подключиться непосредственно к вашей базе данных, так что вам лучше иметь заблокированную схему!
@Esteban - Уточнил мой не очень полезный для вас ответ.
Обычно, если вы выполняете аутентификацию в два прыжка, как в этом случае, обычно задействуется Kerberos, если только первая аутентификация не является базовой.
Я бы проверил аутентификацию на серверах IIS 6 и убедился, что она такая же на IIS 7.
Если IIS 6 настроен на Windows Integrated, то вам нужно проверить настройки kerberos - SPN, делегирование и т.д.
