IIS 7, интегрированный пул приложений, для идентификации задано значение NetworkService
Недавно мы переместили asp.net MVC 3 в нашу производственную среду. Приложение использует проверку подлинности Windows. Производственная среда настроена на веб-ферме на IIS 7 под управлением Win 2008 (не уверен, что R2). Для запуска веб-приложения настроены два сервера.
У нас было два случая (с разницей примерно в 1 неделю), когда пользователи аутентифицировались как другие пользователи, чем они сами. При проверке журналов IIS кажется, что через какой-то момент все запросы аутентифицируются как один конкретный пользователь. В журнале также есть записи с X-ARR-LOG, который, по-видимому, является модулем маршрутизации запросов приложений (не уверен, связан ли он, но дополнительная информация может быть полезна ..). У меня не очень хороший опыт работы в сети, но нашим сетевым ресурсам не удалось найти проблему.
Есть ли какие-либо средства диагностики, которые мы можем запустить, чтобы узнать, откуда может взяться проблема? Вероятно, что-то неправильно настроено на веб-ферме, что может вызвать эту проблему?
Одним из важных факторов является то, что в журнале IIS есть запросы на простую страницу html, которая не проходит через конвейер asp.net, а в журнале эта запись запрашивается от имени пользователя, упомянутого выше. Таким образом, похоже, что после того, как проблема возникла, все запросы, похоже, аутентифицируются под одной и той же учетной записью.
Ценю любую помощь, подсказки, которые вы можете предоставить
Обновить:
Прорабатываем то, как мы определяем, что разные пользователи проходят аутентификацию как один пользователь ...
В журнале IIS мы смотрим на столбец cs-username, который, согласно документации, установлен IIS. Мы можем видеть разные запросы с разных IP-адресов, в разных местах с одинаковым именем пользователя cs. В журнале все запросы имеют разное имя пользователя cs, пока вдруг все запросы не поступают от одного имени пользователя cs. Мы смогли решить эту проблему, вынув серверы из фермы и перезапустив пул приложений. Не уверен, какой именно из этих двоих помог нам «сбросить» проблему. Также упоминалось, что некоторые запросы относятся к простой странице html, которая не проходит через конвейер asp.net (полагаю, что он используется инструментом мониторинга, так как он называется sitecheck.html), и эти запросы внезапно имеют то же имя пользователя cs. Кроме того, само приложение использует WindowsIdentity для отображения пользовательских данных, что побудило нас немного глубже изучить проблему ...
http://xprog.blogspot.com/2011/03/iis7-sessions-getting-crossed-mixed-up.html
Проблема сеанса с IIS7
http://forums.iis.net/t/1154347.aspx
Сессии IIS7 пересекаются / смешиваются / копируются
http://lionsden.co.il/codeden/?p=446
Симптом
Пользователи сообщали, что видели данные, которые им не принадлежали, когда они входили в свои учетные записи. Журналы показали, что почти 10% наших пользователей получали копии сеансов других пользователей. Был скопирован весь объект сеанса, включая переменные сеанса и идентификатор сеанса. После дублирования отдельные сеансы можно было изменить, не затрагивая другие (то есть отказ от одного не убивал другой).
Чтобы обнаружить экземпляры проблемы, я сохранил Request.RemoteHost (IP-адрес компьютера, отправляющего запрос) в переменной сеанса. В начале каждого запроса я проверял, совпадает ли IP-адрес сеанса с IP-адресом текущего запроса.
Что не было
Возможно, что IP-адрес изменится естественным образом, проще всего, если пользователь перезагрузит свой маршрутизатор / модем. Этого не было, потому что это происходило слишком часто. Кроме того, были подтвержденные случаи пересечения данных одного пользователя с данными другого. Наконец, некоторые пары IP-адресов были не просто на разных компьютерах, а в разных странах.
Также возможно, и это часто предполагалось, что переменные сеанса могут перестать быть уникальными, если они используются со статическими / общими переменными в WebApp. Это было не так, потому что IP-адрес, который я хранил в сеансе, был записан только один раз, из запроса, а затем был прочитан только для сравнения с запросом. Это также было исключено, потому что SessionID также был дублирован и является значением только для чтения.
Что было
Это особенность / ошибка в IIS7. Эта последняя версия IIS представила некоторые новые функции кэширования.
IIS7 автоматически кэширует статическое содержимое, такое как HTML-страницы, изображения и таблицы стилей.
IIS7 теперь также может кэшировать динамический контент.
Кэширование динамического контента отлично подходит, если это страница, например, динамически созданная галерея изображений, или страница, которая создается динамически на основе культуры браузера. Однако в этой ветке http://forums.iis.net/t/1154347.aspxАнил Руиа, старший инженер по разработке программного обеспечения IIS Core, объясняет: «Вы не должны включать кэширование вывода для любого ответа, который зависит от состояния сеанса».
Если страница, генерирующая контент, зависит от состояния сеанса, она кэширует объект сеанса вместе с остальной частью страницы. Следующий пользователь, который должен пройти, вытаскивает кэшированный сеанс вместо того, чтобы получить новый. Когда я проверил наши настройки, я обнаружил, что он был настроен на кеширование всех страниц .aspx в течение трех минут, включая многие страницы, которые обращаются к сеансу.
Решение
Изменить правило кеширования
В IIS7 отключите кеширование для страниц .aspx в любом каталоге со страницей asp.net, которая зависит от состояния сеанса. Сделать это:
Run the Server Management console.
Navigate to Roles -> Web Server (IIS) -> Internet Information Services.
Select the site you wish to modify.
Select the folder that contains the .aspx pages you need to turn caching off for.
In the Feature View, double-click “Output Caching”.
If there is a rule there already for the .aspx extension double click it. Otherwise right click and select “Add…”
Enter .aspx for the “File name extension”
Check “User-mode caching”
Select “Prevent all caching”
Check “Kernel-mode caching”
Select “Prevent all caching”
Click OK
Close the Server management Console