Назад | Перейти на главную страницу

Запрос учетных данных для проверки подлинности Windows

У меня есть приложение ASP.NET (классический режим Framework 4), работающее с проверкой подлинности Windows - это интрасеть. Выдача себя за другое лицо включено. Аноним отключен.

Аутентификация отлично работает на ПК любого пользователя, кроме одного. У этого одного пользователя запрашиваются учетные данные, ввод и отправка приводит к очистке вводимых данных и повторному запросу. После 3 попыток появляется сообщение об отказе в доступе.

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

На сервере IIS есть еще 3 сайта. Один из них имеет такие же настройки, два других находятся в режиме интегрированного конвейера. Все работают, в том числе и идентичный. Права доступа к каталогу (NTFS) одинаковы для всех 4 сайтов.

Пользователь входит в те же группы AD, что и все остальные. Я воссоздавал ее 3 раза, используя как консоль SBS, так и пользователи и группы AD, и пробовал использовать другое имя пользователя. Нет эффекта.

Интранет находится в списке надежных сайтов в IE. Журналы событий сервера упоминают необработанное исключение, но не содержат подробностей.

У кого-нибудь есть другие идеи?

Такого рода поломку довольно легко отследить.

  • Открыть программу просмотра событий
  • Выберите Журналы Windows -> Безопасность.
  • На левой панели выберите «Фильтровать текущий журнал ...»
  • Отметьте «Ошибка аутентификации» в разделе «Ключевые слова» и введите 4625 в качестве идентификатора события.

Если на сервере включен аудит сбоев, это должно показать вам событие сбоя аудита, соответствующее каждой неудачной попытке входа в систему, с указанием причины сбоя.

Чтобы изменить политику аудита на сервере, вы можете использовать auditpol инструмент командной строки, отредактируйте локальную политику безопасности или в домене Active Directory, как в вашем случае, предпочтительно групповые политики