Мне было поручено перенести и переместить старое приложение ASP с сервера Windows 2003 (x86) на сервер Windows 2008R2 под управлением IIS 7.5.
Необходимо было изменить ряд вещей (в основном, связанных с доступом к реестру), но я наткнулся на одну проблему, которую не смог решить удовлетворительным образом.
Приложение использует внешний COM-объект (внутрипроцессную dll). Он создаст экземпляр этого объекта на этапе входа в систему и сохранит его как переменную сеанса.
Раньше это работало довольно хорошо и хорошо работало в моем тесте, но когда я развернул его на первом производственном сервере, у меня начали появляться случайные ошибки «500», когда пользователи пытались войти в систему. Ошибка была действительно непоследовательной, поэтому я использовал Прокмон чтобы отследить источник проблемы и получил следующее: когда пользователь пытается получить доступ к веб-сайту, рабочий процесс IIS пытается открыть Dll, на котором размещен COM-объект, но терпит неудачу из-за ошибки отказа в доступе.
Я этого не понимаю: веб-приложение использует учетную запись службы для доступа к локальным ресурсам. У этой учетной записи службы есть явные права на каталог, в котором расположена эта библиотека COM. Тем не менее, доступ к этому файлу по-прежнему запрещен.
Я «исправил» проблему, предоставив «всем» явный доступ на чтение и выполнение к dll, и это (кажется) решило проблему.
Но не знаю почему.
Самым странным является то, что я использую учетную запись локального администратора для подключения к веб-странице один раз (и только один раз), затем проблема была устранена до тех пор, пока приложение не было переработано.
Буду признателен, если кто-нибудь сможет пролить свет на эту проблему. Я могу жить с исправлением, но мне очень хотелось бы понять.
редактировать Для пояснения: веб-сайт НЕ настроен на олицетворение подключающегося пользователя. Фактически, единственная включенная схема аутентификации - это «Анонимная аутентификация». Однако основные настройки настроены на использование учетной записи службы.
редактировать Идентификатор, о котором сообщает procmon во время отказа в доступе, - «IIS APPPOOL \ (имя приложения)»
Думаю, вы ответили на свой вопрос.
Ваше веб-приложение настроено на выдачу себя за аутентифицированного пользователя.
Когда запрос принят, потоку, обрабатывающему запрос, выдается токен пользователя, который прошел проверку подлинности, и затем этот идентификатор используется для всех операций этого потока, пока запрос не завершится.
COM-объект необходимо загрузить только один раз, и администраторы могут читать практически любой файл, поэтому первый запрос в качестве администратора может а) прочитать файл и б) загрузить его в адресное пространство процесса. Обычно это не должно происходить повторно: как только DLL находится в памяти, она там.
Если обычный пользователь (или анонимный пользователь) аутентифицируется и олицетворяется, значит, у него изначально не было разрешения на открытие файла, и ProcMon должен показать вам это вместе с идентификатором, который использовался. (По умолчанию: IUSR для анонимных запросов).
Бит «служебной учетной записи», который вы описали, звучит как идентификатор рабочего процесса. Они используются только для запуска пула приложений, чтения конфигурации, а затем для того, чтобы сидеть и делать вещи, которые напрямую не связаны с запросом *.
* если вы не используете учетную запись пула приложений в качестве учетной записи анонимного пользователя, и если поток, олицетворяющий пользователя, не может выйти за пределы поля (т.е. ему необходимо делегировать), в этом случае будет использоваться учетная запись пула приложений.