Олицетворение IIS не работает, когда пул приложений работает с учетной записью домена - PullRequest
Новая
       99

Олицетворение IIS не работает, когда пул приложений работает с учетной записью домена

1 голос
/ 09 января 2020

У меня есть приложение ASP. net, работающее в среде windows intr anet. У меня есть требование для выполнения определенных обновлений базы данных, как текущий зарегистрированный пользователь .

IIS / информация о сервере:

  • IIS версия 10
  • Windows сервер 2019
  • ASP. net приложение веб-форм
  • . NET 4.7
  • Windows аутентификация включена
  • олицетворение и анонимная аутентификация отключены
  • Пул приложений использует интегрированный конвейер
  • Пул приложений запускается с учетной записью службы домена для идентификации, которая имеет права доступа другие ресурсы по мере необходимости.

Прочие сведения:

  • Все строки подключения к моей базе данных установлены так, что встроенная защита = true
  • в активном каталоге , настроили ограниченное делегирование между веб-сервером и SQL сервером, разрешив MSSQLSv c: 1433 и MSSQLSv c (без порта)
  • учетная запись службы домена является членом группы локальных администраторов на веб-сервере (только для целей тестирования)

Когда я выполняю обновления базы данных, которые необходимо выполнить как в настоящее время вошли в систему пользователя, я имитировать их таким образом: 

 var windowsIdentity = User.Identity as WindowsIdentity;
 WindowsIdentity.RunImpersonated(windowsIdentity.AccessToken, () =>
 {
     // perform database update
 });

Это вызывает исключение - System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

Если я изменяю удостоверение пула приложений для использования AppPoolIdentity (удостоверение пула приложений по умолчанию) олицетворение работает правильно.

Почему это олицетворение работает с AppPoolIdentity , но не с моей учетной записью службы домена ?

1 Ответ

0 голосов
/ 10 января 2020

У меня были подобные проблемы раньше, я вижу, что вы используете Kerberos, как только вы его получите, все будет в порядке!

Что-то, что сработало для меня в сценарии, похожем на ваш, - это открыть IIS. , go на ваш сайт, щелкните значок Редактор конфигурации. В верхних двух заголовках сначала нажмите раскрывающийся список «от» и выберите «ApplicationHost.config», а в заголовке «раздел» слева от «От» щелкните раскрывающийся список и разверните папки:

system.WebServer-> security-> authentication-> windowsAuthentication,

Из опций здесь вы можете выбрать «useAppPoolCredentials» и установить для него значение TRUE, в вашем случае.

enter image description here

Когда для «useAppPoolCredentials» установлено значение true, вы сообщаете IIS, что ему необходимо использовать идентификатор пула приложений, который вы определяете как учетную запись службы домена для дешифрования билета авторизации, который В профиле пользователя обычно нет условий для этого.

Еще одна вещь, которую нужно попробовать, если это не сработает, это переключить настройку «Загрузить профиль пользователя» в дополнительных настройках приложения. я не уверен, что True или False исправят вашу проблему, но это помогло решить подобные проблемы раньше. Сначала я попробую описать выше, и я Если это не работает, попробуйте следующее:

loaduserprofile

Я не видел ничего упомянутого о SPN, вы их используете? Они могут потребоваться при запуске учетной записи домена в качестве идентификатора пула приложений. Приведенная ниже статья описывает этот шаг, а также многие другие для того, чтобы заставить это работать:

https://techcommunity.microsoft.com/t5/iis-support-blog/setting-up-kerberos-authentication-for-a-website-in-iis/ba-p/324644

Кроме того, вот несколько статей, которые очень помогли мне, чтобы все это работало на моей работе.

https://docs.microsoft.com/en-us/archive/blogs/chiranth/setting-up-kerberos-authentication-for-a-website-in-iis

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc961723 (v = te chnet .10 )? redirectedfrom = MSDN

Надеюсь, это поможет.

ОБНОВЛЕНИЕ: Для тех, кто все еще ищет помощи в этой проблеме, мы нашли обходной путь для нашей системы, который не требовал олицетворения / делегирования:

Вместо этого мы создали другую конечную точку API - «среднюю точку», которая получает запрос от начальной конечной точки без олицетворения. В этом сценарии мы смогли создать промежуточную учетную запись Sys для запуска в качестве идентификатора пула приложений средней точки, который затем является идентификатором, используемым для запроса базы данных, и это единственный доступ, который имеет учетная запись sys, и этого было достаточно для обеспечения безопасности. команда, чтобы быть в порядке с этим. Мы поняли, что регистрация абонента, выполняющего вызов, не потребуется, если мы используем специальную привилегированную системную учетную запись, основанную на наших протоколах.

...