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