У меня есть разработанная копия сайта интрасети ASP.NET, проверенная и работающая на моем локальном компьютере. Мы используем дайджест-аутентификацию, чтобы пользователи могли входить в систему, используя свои учетные записи активного каталога.
Только в моей разрабатываемой копии Digest иногда повторно запрашивает информацию для входа, обычно ~ 9 раз на запрос страницы. После многократного входа в систему (или он также работает для отмены 8 из 9 запросов) я могу использовать сайт как обычно.
Я не могу точно определить, что вызывает проблему. Иногда эта проблема возникает при следующем запросе страницы, иногда после того, как я отредактировал / сохранил / обновил страницу, а иногда этого не происходит вообще.
Каждый запрос вызывает несколько событий безопасности входа в систему (идентификатор события 4624 и 4672) в средстве просмотра событий. Вскоре после каждой серии событий входа я буду видеть серию событий выхода (идентификатор события 4634).
Сотрудник с почти идентичной настройкой (Windows 7, IIS 7) не испытывает проблемы. Наша производственная копия (работающая на другом сервере) также не испытывает проблемы. Мы попытались сравнить наши настройки в IIS, но не обнаружили никаких различий.
Я использую Chrome, но у меня возникла проблема в других браузерах.
Если это приложение предназначено только для внутреннего использования, я бы рекомендовал использовать встроенную аутентификацию, а не дайджест. Для приложений без встроенной аутентификации веб-формы, как у вас, 99% интегрированы (сквозная аутентификация AD) или базовая аутентификация через SSL.
Кроме того, дайджест не всегда работает с AD и зависит от настроек в AD и каждого пользователя. Google такие вещи, как "digest auth active directory" или "digest reversible encryption", так что узнайте, какие проблемы с этим возникают у людей.
Также стоит обратить внимание на разрешения NTFS для файлов / папок, и если анонимный включен (этого не должно быть).
Есть ли у вас (кеширующий / не кеширующий) веб-прокси между вашим компьютером и сервером? Я видел ту же проблему с аутентификацией Sharepoint, решение, которое мы приняли, заключалось в том, чтобы избавиться от ISA Firewall / Proxy с помощью правила, позволяющего клиентам обходить его для сайта Sharepoint. Это решило проблему, но мы не исследовали основную причину.