(Это вопрос о расплывчатой ​​проблеме. Я стараюсь представить все соответствующие данные в надежде, что у кого-то есть полезная информация; извиняюсь за длинное описание.)

Наше веб-приложение

У нас есть веб-приложение .NET 4, работающее в IIS 7.5, имеющее доступ к Active Directory и базе данных SQL Server.

Это веб-приложение работает под виртуальным «удостоверением пула приложений», для которого для параметра «Удостоверение пула приложений» установлено значение ApplicationPoolIdentity. Краткое описание виртуальных удостоверений можно найти в ответе на StackOverflow и в сообщении блога, на которое он ссылается: удостоверение пула приложений просто дополнительная группа, которая добавляется к рабочим процессам веб-приложения, работающим как «сетевая служба». Однако один источник неопределенно предполагает, что «Network Service и ApplicationPoolIdentity имеют различия, которые не публикуются в документах сайта IIS.net ". Таким образом, виртуальная личность может быть чем-то большим, чем просто дополнительной группой.

Мы решили использовать ApplicationPoolIdentity, а не NetworkService, потому что он стал по умолчанию в IIS 7.5 (см., Например, здесь), и по рекомендации Microsoft:« Это удостоверение позволяет администраторам указывать разрешения, относящиеся только к удостоверению, под которым работает пул приложений, тем самым повышая безопасность сервера ». (из Элемент processModel для добавления для пулов приложений [Схема настроек 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, он снова заработает. (Обратите внимание, что доступ к AD необходим для Kerberos, но не для NTLM.) Об аналогичной проблеме сообщается в Тема IIS.net «Ошибка аутентификации окна с идентификацией AppPool».

Наша гипотеза и обходной путь

По крайней мере, проблемы с AD и входом в систему всегда исчезают при переключении пула приложений с ApplicationPoolIdentity на NetworkService. (Мы нашли один отчет, подтверждающий это.)

На странице «Устранение проблем аутентификации на страницах ASP» есть некоторые предложения, связанные с первичные и вторичные токены, и что меня обнадеживает, так это то, что он связывает первые две из наших ошибок: упоминается NT AUTHORITY\ANONYMOUS LOGON доступ, а также ошибки AD 0x8000500C и «Указанный атрибут или значение службы каталогов не существует».

(На той же странице также упоминаются проблемы с кешем схемы ADSI, но все, что мы можем найти по этой теме, устарело. На данный момент мы считаем это несвязанным.)

Основываясь на вышеизложенном, наша текущая рабочая гипотеза заключается в том, что только при работе с идентификатором пула виртуальных приложений наше веб-приложение (рабочий процесс IIS?) Внезапно теряет свой основной токен , так что у IIS есть только вторичный токен, так что весь доступ к Active Directory и SQL Server осуществляется анонимно, что приводит ко всем вышеперечисленным ошибкам.