У меня есть приложение, опубликованное через IIS 8.5 на Windows Server 2012, которое может использовать интегрированные в Windows учетные данные для единого входа. Пользователи могут успешно войти в приложение и перейти к подавляющему большинству страниц aspx. Однако, когда пользователи пытаются войти на определенную страницу aspx, они получают запрос проверки подлинности Windows, в котором они должны ввести свои учетные данные домена 10 буквальных раз, прежде чем это позволит им получить доступ к странице.
С точки зрения IIS для виртуального каталога приложения указана ТОЛЬКО проверка подлинности Windows. Я могу обойти проблему, если включу анонимную проверку подлинности (пользователям не предлагается запрос проверки подлинности Windows, когда они пытаются перейти на страницу aspx), но это, очевидно, мешает конечным пользователям входить в систему с использованием учетных данных, интегрированных в Windows. - что для них неприемлемо. Таким образом, я подозревал, что это какая-то проблема с разрешениями NTFS / share на одну из страниц ASPX или библиотеки DLL приложения. Однако я до тошноты проверил все соответствующие разрешения для плоских файлов, но безрезультатно.
Я сделал следующее: -Я проверил разрешения для страницы aspx, к которой пользователи пытаются получить доступ, и с точки зрения AD все в порядке. Похоже, что у пользователей есть правильные разрешения. -Проблема не возникает при прямом входе на сервер приложений. -Администраторы домена также сталкиваются с проблемой при входе в приложение через клиентскую рабочую станцию. -Запустите трассировку Fiddler и Wireshark, и, как и ожидалось, я обнаружил ошибку 401. -Проблема не возникает для пользователей, которые интегрируются в приложение с учетными данными, отличными от Windows.
У меня закончились идеи относительно того, что я могу проверить - есть ли у кого-нибудь еще какие-нибудь мысли?
Окончательное решение этой проблемы было найдено в настройках IE. Когда мы отметили возможность проверять наличие более новых версий сохраненных страниц при каждом посещении, проблема исчезла. При повторном включении проблема появилась снова.
Итак, описание ошибки гласит:
Ошибка HTTP 401.2 - Несанкционированный: доступ запрещен из-за конфигурации сервера.
По сути, ваши клиенты ожидают один тип аутентификации, а сервер не настроен для его предоставления, поэтому аутентификация не выполняется во время первоначального взаимодействия клиент-сервер, когда они пытаются согласовать метод аутентификации.
По моему опыту, это обычно проблема, связанная с Kerberos, если только по той причине, что настройки по умолчанию, похоже, включают аутентификацию Kerberos в нефункциональном состоянии ... так что это то, куда я бы посмотрел в первую очередь. В частности, убедитесь, что если IIS работает под учетной записью службы домена, у вас зарегистрировано SPN (имя участника-службы), которое ваше описание заставляет меня думать, что это не так.
Конечно, это также могло быть проблема делегирования, для которых есть пара КБ, или даже проблема проверки подлинности без Kerberos.
Веселые времена, а? И на всякий случай ничто из этого не поможет, вот вкуснятина, которая датируется 2003 годом, но все же применяется для устранения неполадок базовой аутентификации. По крайней мере, это должно помочь вам сузить проблему или, возможно, решить ее, применив более простой метод аутентификации для всех.