У меня есть веб-сайт, работающий в IIS и использующий проверку подлинности Windows. Все пользователи, настроенные для получения доступа к сайту, являются доменом AD (а не локальными пользователями). В свойствах веб-сайта я установил использование домена AD в качестве области.
Теперь при использовании Firefox, Safari или Chrome - все нормально. Когда пользователь пытается открыть сайт, он получает поле входа в систему. он вводит просто «имя пользователя» и «пароль» (представим, что это настоящий логин и пароль: P), и он попадает на сайт.
Однако при использовании IE все становится неприятно. Когда пользователь пытается открыть сайт - он получает логин. Пользователь снова вводит «имя пользователя» и «пароль», но они отклоняются! И когда появляется окно входа во второй раз - в нем имя пользователя заполнено как "web-server-domain-name \ username", что неверно, потому что web-server-domain-name не является доменом, в котором находятся все пользователи (это "рекламный домен"). Я потратил несколько дней, пытаясь понять, что происходит ... Обратите внимание, что если я вручную введу "ad-domain \ username" - меня без проблем примут на сайт. Итак, я предполагаю, что IE отправляет неправильное имя пользователя, если домен не указан.
В любом случае, IE - единственный браузер, который вызывает такое поведение!
Можно ли исправить на стороне сервера? Может быть, можно как-то автоматически сопоставить пользователей с пользователями AD?
Если это не решается на стороне сервера - есть ли для этого исправление на стороне клиента?
Спасибо.
PS: Я больше программист, чем системный администратор, поэтому настройка серверов - не моя сильная сторона ...: P
ОБНОВИТЬ:
@Evan: Да, "дайджест-проверка подлинности для серверов домена Windows" также включена.
@Eric: Версия IIS - 6.0. Включены следующие методы аутентификации: Интегрированный и дайджест - все остальные методы отключены. Что касается журнала безопасности. Я смотрел на это, когда выполнял "логин" и "пароль" в Chrome / Firefox и когда делал логин "ad-domain \ username" и "пароль" из IE - сгенерированные сообщения журнала совпадают (я не вижу разницы, тем не мение). При вводе «имени пользователя» и «пароля» я не вижу ошибок в журнале безопасности (или любом другом), поэтому не могу сказать, какой метод он пытается использовать.
ОБНОВЛЕНИЕ 2:
Как предложил Эрик в комментариях - я поигрался со Fiddler ... Играя с ним, я заметил, что когда "имя пользователя" и "пароль" вводятся в FF и IE - значение заголовка "Авторизация" (зашифрованное) отправляется IE длиннее (почти в два раза), чем отправленный FF.
Я попытался отключить встроенную проверку подлинности Windows и оставить включенным только дайджест - это устранило проблему (то есть IE использовал правильную область, как и другие браузеры), но это вызвало миллионы других проблем с моим сайтом, потому что с дайджестом - олицетворение пользователя на сервер не работает (что вызывает проблемы при подключении к базе данных и т. д.).
Любые идеи?
Это может произойти, если сервер Windows (на котором работает IIS 6.0) и клиенты Windows (использующие IE для доступа к вашему веб-сайту) являются частью локальной сети (LAN).
Также важно то, что у вас включена «встроенная проверка подлинности Windows», поскольку вам необходимо использовать и проверять пользователей из домена AD.
Назовем имя этого домена AD ad_domain_name.
В этом сценарии (LAN + встроенная аутентификация) процесс аутентификации между клиентами Windows и сервером использует безопасность домена AD по умолчанию.
Вы можете проверить, так ли это, попробовав это (в клиенте Windows):
ad_domain_name\usernameЭта процедура должна разрешить вход с первой попытки.
Я наблюдал за этим много раз, и обычно все это рассматривается специалистами Microsoft как «желаемая функция безопасности» в случае локальной сети. И обычно это рассматривалось как не проблема, поскольку процедура входа в систему может быть выполнена в любом случае.
Я не знаю, существует ли конфигурация IIS (и / или сервера Windows), которая может избежать всего этого беспорядка, но мне так же любопытно, как и вам.
Обычно я решаю эту проблему, проверяя, что сайт попадает в зону интрасети в IE, которая будет выполнять аутентификацию без запроса.