Приложение IIS, использующее удостоверение пула приложений, теряет основной токен?
(Это вопрос о неясной проблеме. Я пытаюсь представить все соответствующие данные в надежде, что кто-то получит полезную информацию; извиняюсь за длинное описание.)
Наше веб-приложение
У нас есть веб-приложение.NET 4, работающее в IIS 7.5 для доступа к Active Directory и базе данных SQL Server.
Это веб-приложение выполняется под виртуальным "идентификатором пула приложений", для которого для параметра "Идентификация пула приложений" установлено значение " ApplicationPoolIdentity". Краткое описание виртуальных удостоверений можно найти в ответе Stackru и посте в блоге, на который он ссылается: удостоверение пула приложений - это просто дополнительная группа, которая добавляется к рабочим процессам веб-приложения, работающим как "сетевая служба". Однако один источник смутно предполагает, что "сетевая служба и ApplicationPoolIdentity действительно имеют различия, которые не публикуются документами сайта IIS.net". Таким образом, виртуальная личность может быть больше, чем просто дополнительная группа.
Мы решили использовать ApplicationPoolIdentity, а не Network Service, потому что он стал значением по умолчанию в 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 на Network Service. Надеюсь, это устранит все вышеперечисленные проблемы. Но мы не уверены; и мы хотели бы вернуться обратно, если это возможно.
Наш вопрос
Верна ли приведенная выше гипотеза, и если да, то это ошибка в IIS/Windows/.NET? При каких обстоятельствах происходит эта первичная потеря токена?
3 ответа
Благодаря поддержке Microsoft я обнаружил, что мы столкнулись с проблемой, описанной в статье базы знаний Майкрософт KB2545850. Это происходит только при использовании ApplicationPoolIdentity. Это происходит очень легко, а именно, после изменения пароля учетной записи компьютера (что по умолчанию происходит автоматически каждые 30 дней), а затем IIS перезапускается (например, через iisreset). Обратите внимание, что проблема исчезает после перезагрузки, согласно Microsoft и нашим наблюдениям.
Согласно Microsoft, невозможно проверить, попала ли ваша Windows / IIS в это состояние.
Microsoft имеет исправление, прилагаемое к этой статье базы знаний. Нет никаких указаний, когда это исправление будет включено в официальную поставку, а исправлению уже 10 месяцев. В нашем конкретном случае мы решили вместо этого переключиться на NetworkService.
См. /questions/8385732/silverlight-bezopasen/8385760#8385760 для моих комментариев по той же проблеме / решению.
Использование исправления, на которое вы ссылались, позволило мне заставить ApplicationPoolIdentity работать так, как говорят документы. Это исправление не описывает конкретно решение для доступа к сетевым ресурсам как NT AUTHORITY\ANONYMOUS LOGON, но оно связано с изменением пароля компьютера. Суть в том, что это сработало для меня, по крайней мере, до сих пор.
Это также актуально для Umbraco, использующего аутентификацию Active Directory. Время от времени вы можете получить это исключение:
Ошибка конфигурации
Указанный атрибут службы каталогов или значение не существует
По-видимому, это связано с проблемой, изложенной здесь. Перезагрузка неизменно исправляет это.