Избегание ответа 401 для каждого запроса с использованием NTLM

У нас есть приложение asp.net 3.5, использующее проверку подлинности Windows на основе NTLM. Система работает в частной сети, которая фактически распространяется по разным географическим местам (подключается через VPN).

Сейчас мы пытаемся оптимизировать производительность сайта. Поскольку NTLM работает, каждый новый запрос к IIS состоит из 3 разных запросов, а первые 2 - 401 ответа. Мы пытаемся минимизировать количество этих запросов только в начале сессии. Мы нашли это решение. К сожалению, это ничего не изменило, и мы продолжаем получать этот ответ 401 (который потребляет время).

Чтобы увидеть трафик, я впервые использовал приложение Fiddler. Так или иначе, когда я использую Fiddler, в начале сеанса есть только 1 процесс аутентификации (точно так, как я хочу), но когда я закрываю Fiddler и проверяю трафик через WireShark, я вижу, что у меня все еще есть этот ответ 401 для каждого запроса.

Используемыми клиентами являются IE6, IIS версии 6.

Может ли кто-нибудь посоветовать?

Ответ 1

NTLM/Negotiate, в отличие от всех других схем проверки подлинности HTTP, являются протоколами, ориентированными на соединение.

В IIS существуют различные параметры, которые определяют, будет ли требоваться проверка подлинности для всех запросов в ранее аутентифицированном соединении (например, AuthPersistSingleRequest). Независимо от этого параметра, я считаю, что IIS автоматически потребует повторной аутентификации при выполнении запроса POST.

Если ваш сервер нарушает повторное использование соединения (например, посылая заголовок Connection: close в ответах), вы должны исправить это, потому что в противном случае произойдет повторная аутентификация. Вы можете легко проверить наличие таких файлов с повторной загрузкой с использованием Fiddler.

Ответ 2

Единственный способ - использовать NTLM только на странице входа и использовать cookie, например здесь

Ответ 3

Это могут быть ваши настройки безопасности для IE6 для сайта. Попробуйте перейти на локальный intranett или доверенный сайт.

Ответ 4

по теме; если вы используете аутентификацию IIS7.0 и Kerberos, появляется AuthPersistNonNTLM = true, чтобы избежать 401 раундов для каждого запроса.

http://msdn.microsoft.com/en-us/library/aa347548(VS.90).aspx

http://blogs.technet.com/b/configurationmgr/archive/2010/06/03/solution-you-may-experience-slow-performance-when-using-bits-and-kerberos-authentication-on-configmgr-2007-distribution-points.aspx

Ответ 5

Вы пробовали это в своем домене?

setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount

Он позволяет пулу приложений обслуживать запросы NTLM auth.

Ответ 6

У меня такая же проблема! Я использую ту же среду, что и вы. За исключением того, что я вижу 2 401 даже в Fiddler. Я потратил пару дней на эту проблему, а потом просто сдался. Для меня также не работало AuthPersistence. Но вот ссылки, которые я нашел, возможно, они будут работать в вашем случае.

http://msdn.microsoft.com/en-us/library/ms525244.aspx

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/b0b4ec5c-74f8-43e9-ac64-d8b852568341.mspx? MFR = истинные

http://technet.microsoft.com/en-us/library/cc786094.aspx

http://technet.microsoft.com/en-us/library/cc781339 (WS.10).aspx

Я попытался установить флаг как в виртуальном каталоге, так и на уровне веб-сайта, но это не помогло. Вы используете IIS Metabase Explorer для редактирования этих свойств? Его более чистый способ редактировать свойства и может помочь больше, чем непосредственно редактировать XML файл.

Один из способов обойти эту проблему - вставить заголовок Cache-Control Header в ответе HTTP для ресурсов, которые не будут часто меняться на любой странице. В моем случае я кэшировал css (как можно больше использовать внешний CSS, чтобы оптимизировать это), js и img файлы. Поскольку у меня около 60 файлов этих типов, загружаемых на нашу домашнюю страницу, мы смогли устранить около 120 ошибок 401!

Убедитесь, что вы используете заголовок Cache-Control, а не кеширование if-modified или e-tag, где 401 и 304 все равно будут созданы даже при кэшировании файлов.

Ответ 7

У меня была эта проблема, кроме того, для меня это были в основном файлы JS и CSS, которые вызвали это. Мой сайт (как и большинство сайтов) хранит JS и CSS файлы в собственных каталогах. Поэтому решение для меня состояло в том, чтобы просто пойти в эти справочники в IIS и включить Anon Auth (я говорю просто, но мне потребовалось более двух лет, чтобы я мог это исправить, благодаря этому сообщению). Теперь сайту по-прежнему требуется Windows auth, но подкаталоги для файлов JS и CSS этого не делают. IOW, похоже, что он работает отлично.

Я также никогда не ставил бы конфиденциальную информацию в JS файл (или файл CSS, если на то пошло), и предположил бы, что вы тоже этого не делаете. Если вы это сделаете, вы, очевидно, захотите переместить конфиденциальную информацию из этих файлов из этих каталогов.