Приложение IIS, использующее идентификатор пула приложений, теряет первичный токен?
(Это вопрос о неясной проблеме. Я стараюсь представить все соответствующие данные, в надежде, что у кого-то есть полезная информация; извиняюсь за длинное описание.)
Наше веб-приложение
У нас есть веб-приложение.NET 4, работающее в IIS 7.5, которое обращается к Active Directory и базе данных SQL Server.
Это веб-приложение работает под виртуальным «идентификатором пула приложений», установив для идентификатора пула приложений значение ApplicationPoolIdentity . Краткое описание виртуальных удостоверений можно найти в ответе StackOverflow , а сообщение в блоге, к которому оно относится :удостоверение пула приложений — это просто дополнительная группа, которая добавляется к рабочим процессам веб-приложения, которые работает как «сетевая служба». Тем не менее, один источник расплывчато предполагает, что «Network Service и ApplicationPoolIdentity действительно имеют различия, которые не публикуются в документах сайта IIS.net». Таким образом, виртуальная личность может быть больше, чем просто дополнительная группа.
Мы решили использовать ApplicationPoolIdentity, а не NetworkService, поскольку он стал использоваться по умолчанию в IIS 7.5 (, см., например, здесь), и в соответствии с рекомендацией Microsoft :«Это удостоверение позволяет администраторам указывать разрешения, относящиеся только к удостоверению, под которым работает пул приложений, тем самым повышая безопасность сервера». (из Элемент processModel для добавления для applicationPools [Схема настроек IIS 7])«Удостоверения пула приложений — это новая мощная функция изоляции», которая «делает работающие приложения IIS еще более безопасными и надежными». (из статьи IIS.net «Удостоверения пула приложений»)
Приложение использует встроенную проверку подлинности Windows, но с
Это приложение запрашивает 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, то снова работает. (Обратите внимание, что доступ к AD необходим для Kerberos, но не для 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? При каких обстоятельствах происходит эта первичная потеря токена?