(Это вопрос о неопределенной проблеме. Я пытаюсь представить все релевантные данные в надежде, что у кого-то есть полезная информация, извинения за длинное описание.)
Наше веб-приложение
У нас есть веб-приложение .NET 4, работающее в IIS 7.5, доступ к Active Directory и базе данных SQL Server.
Это веб-приложение работает под виртуальным "идентификатором пула приложений", установив для Identity пула приложений приложение ApplicationPoolIdentity. Краткое описание виртуальных идентификаторов можно найти в qaru.site/info/19841/... и в сообщении блога, на которое оно ссылается: идентификатор пула приложений - это дополнительная группа, которая добавляется к рабочие процессы веб-приложения, работающие как "сетевые службы". Тем не менее, один источник смутно предлагает, что "Network Service и ApplicationPoolIdentity имеют различия в том, что документы сайта IIS.net не публикуются". Таким образом, виртуальная идентификация может быть не просто дополнительной группой.
Мы решили использовать ApplicationPoolIdentity, в отличие от NetworkService, поскольку он стал стандартным для IIS 7.5 (см., например, здесь) и по рекомендации Microsoft: "Это удостоверение позволяет администраторам указывать разрешения, относящиеся только к идентификатору, в котором работает пул приложений, тем самым повышая безопасность сервера". (из processModel Element для добавления для applicationPools [Схема настроек IIS 7]) "Идентификаторы пула приложений - это мощная новая функция изоляции", которая "работает" Приложения IIS еще более безопасны и надежны ". (Из Статья IIS.net" Идентификаторы пула приложений")
Приложение использует встроенную проверку подлинности Windows, но с <identity impersonate="false"/>, так что не идентичность конечного пользователя, а идентификатор пула виртуальных приложений используется для запуска нашего кода.
Это приложение запрашивает Active Directory, используя классы System.DirectoryServices, то есть API ADSI. В большинстве случаев это делается без указания дополнительного имени пользователя/пароля или других учетных данных.
Это приложение также подключается к базе данных SQL Server с помощью Integrated Security=true в строке подключения. Если база данных является локальной, мы видим, что IIS APPPOOL\OurAppPoolName используется для подключения к базе данных; если база данных удаленная, то используется учетная запись машины OURDOMAIN\ourwebserver$.
Наши проблемы
У нас регулярно возникают проблемы, когда рабочая установка начинает сбой одним из следующих способов.
-
Когда база данных находится в удаленной системе, соединение с базой данных начинает сбой: "Ошибка входа для пользователя" NT AUTHORITY\ANONYMOUS LOGON ". Причина: проверка доступа к серверу на основе токена завершилась неудачей с ошибкой инфраструктуры. Проверьте предыдущие ошибки." Предыдущая ошибка: "Ошибка: 18456, серьезность: 14, состояние: 11." Похоже, теперь
OURDOMAIN\ourwebserver$больше не используется, но вместо этого выполняется попытка анонимного доступа. (У нас есть неопровержимые доказательства того, что эта проблема возникла, когда UAC был отключен, и что он ушел после включения UAC. Но обратите внимание, что изменение UAC требует перезагрузки...) Аналогичная проблема возникает в поток IIS.net "использует ApplicationPoolIdentity для подключения к SQL" , в частности, один ответ. -
Операции Active Directory через ADSI (System.DirectoryServices) начинают сбой с ошибкой 0x8000500C ( "Неизвестная ошибка" ), 0x80072020 ( "Произошла операционная ошибка" ) или 0x200B ( "Указанный атрибут службы каталогов или значение не существует" ).
-
Вход в приложение из Internet Explorer начинает работать с ошибкой HTTP 401. Но если в IIS мы помещаем NTLM до Negotiate, тогда он работает снова. (Обратите внимание, что для Kerberos необходим доступ к AD, но не для NTLM.) Аналогичная проблема приведена в поток IIS.net "Аутентификация окна, не выполняющая идентификатор AppPool" .
Наша гипотеза и обход
По крайней мере, проблемы AD и входа всегда исчезают при переключении пула приложений из ApplicationPoolIdentity в NetworkService. (Мы обнаружили один отчет, подтверждающий это.)
Страница "Устранение проблем аутентификации на страницах ASP" содержит некоторые предложения, касающиеся первичных или вторичных токенов, и то, что я считаю обнадеживающим, заключается в том, что он связывает первые две наши ошибки: он упоминает NT AUTHORITY\ANONYMOUS LOGON доступ и ошибки AD 0x8000500C и "Указанный атрибут или значение службы каталогов не существует".
(На той же странице также упоминаются проблемы кэша схемы ADSI, но все, что мы можем найти в этой теме, устарело. Пока мы считаем, что это не связано.)
Исходя из вышесказанного, наша текущая рабочая гипотеза заключается в том, что только при запуске под идентификатором виртуального приложения, наше веб-приложение (рабочий процесс IIS?) внезапно теряет свой основной токен, так что IIS имеет только вторичный токен, так что весь доступ к Active Directory и SQL Server выполняется анонимно, что приводит ко всем вышеперечисленным ошибкам.
Теперь мы намерены перейти от ApplicationPoolIdentity к NetworkService. Надеюсь, это уберет все вышеуказанные проблемы. Но мы не уверены; и мы хотели бы вернуться, если это возможно.
Наш вопрос
Является ли приведенная выше гипотеза правильной, и если да, это ошибка в IIS/Windows/.NET? При каких обстоятельствах происходит эта первичная потеря токенов?