У меня проблема с приложением IIS 7 в нашей сети. Проблема в следующем:
Если пользователь заходит на сайт по IP-адресу (http://172.16.10.32/site) приложение загружается нормально, без ошибок и отлично работает.
Если тот же пользователь переходит на сайт по имени хоста (http://dms-live/site) отображается сообщение «Internet Explorer не может отобразить веб-страницу». Копание глубже приводит к фактическому коду ошибки 401.2 - Несанкционированный.
Дополнительная информация:
Это внутренний сайт без какого-либо внешнего доступа
Internet Explorer настроен групповой политикой для размещения сайта в зоне интрасети.
Приложение поддерживает «анонимную аутентификацию» (с использованием IUSR), «олицетворение ASP.NET» (для прошедшего проверку пользователя), «базовую аутентификацию» (домен или область по умолчанию не указаны) и «аутентификацию Windows» (с включенной аутентификацией в режиме ядра)
Пользователь может пинговать dms-live, который возвращает правильный IP-адрес 172.16.10.32.
Пользователь может просматривать как http://172.16.10.32 и http://dms-live без проблем и видит заставку IIS 7 по умолчанию
Имя хоста "dms-live" - это дополнительная запись A, указанная в DNS, указывающая на 172.16.10.32.
Фактическое имя хоста сервера - «accserver16». Использование этого вместо "dms-live" дает точно такой же результат (ошибка 401.2)
Использование FQDN вместо коротких имен хостов также дает тот же результат (ошибка 401.2)
На веб-сайте есть привязки к dms-live, accserver16 и 172.16.10.32, а также соответствующие FQDN.
Наша сеть состоит из двух доменов в двух лесах, домен A в лесу A и домен B в лесу B. Все пользователи и рабочие станции находятся в домене A, сервер IIS находится в домене B. Между доменом A и доменом настроено двустороннее доверие. Б.
Оба домена имеют собственные DNS-серверы.
Эта проблема возникла недавно, после того, как было внесено одно очень конкретное изменение DNS. Первоначально зона DNS для домена B размещалась на DNS-сервере домена B, а для пересылки запросов от DNS-серверов домена A была настроена запись «Условные пересылки». В интересах отказоустойчивости это было изменено, так что DNS-серверы домена A имели вторичные зоны прямого и обратного доступа, настроенные для зон домена B.
Вторичная зона загружается нормально, правильно реплицирует изменения и возвращает правильные записи DNS для запросов ping и nslookup.
Еще одна странная информация - некоторые ПК в сети могут загружать http://dms-live/site без проблем. Кажется, не так уж и много общего с тем, какие ПК работают, а какие нет.
Это не зависит от пользователя (один и тот же пользователь на двух разных ПК не обязательно получит одинаковый результат), браузера (это было протестировано с IE8 и IE9, и результаты не согласованы) или операционной системы (проблема кажется независимой от того, Windows XP или Windows 7).
Устранение неполадок пробовали до сих пор:
На ПК, который не может загрузить страницу, Fiddler показывает, что выполняется один запрос, который возвращает ошибку 401. На ПК, который успешно загружает страницу, Fiddler показывает ту же ошибку 401, за которой следует 302, а затем 200.
Если дополнительные зоны удалены, а запись «Условные серверы пересылки» добавлена, проблема исчезнет.
Кажется, что по какой-то причине при использовании вторичной зоны вместо условного перенаправителя для разрешения имени хоста в другом лесу аутентификация не выполняется для некоторых ПК, но не для всех, но почему это может быть так, я понятия не имею. Кто-нибудь может помочь?
После долгих поисков я наконец нашел причину проблемы.
Мы отследили его после того, как заметили пару других связанных проблем. При попытке перейти к общему ресурсу на accserver16 пользователю будет представлено поле учетных данных и следующее сообщение об ошибке:
Система обнаружила возможную попытку нарушения безопасности. Убедитесь, что вы можете связаться с сервером, который аутентифицировал вас.
Заполнение соответствующих учетных данных сработало, но в этом не должно было быть необходимости.
Кроме того, при попытке проверить доверие на контроллере домена из леса B отображалось следующее сообщение об ошибке:
Сброс безопасного канала (SC) на контроллере домена Active Directory \ accserver04.domainb.local из домена domainb.local в домен domaina.local завершился ошибкой: в настоящее время нет доступных серверов входа для обслуживания запроса входа.
Это указывало на неспособность найти контроллеры домена в другом лесу как на причину проблемы.
Внутри DNS под зоной прямого просмотра каждого домена находится зона делегирования с именем «_msdcs». Он должен содержать статические NS-записи, указывающие на серверы имен в этом домене.
Как в домене A, так и в домене B это было неправильно настроено. В домене A единственный указанный сервер имен с тех пор был понижен в должности, а в домене B он указывал на сервер, которого больше не существовало в сети.
По-видимому, это не вызывало проблем для внутренних DNS-запросов и не влияло на запросы между лесами, пока использовалась условная пересылка. Однако как только условная пересылка была заменена вторичными зонами, доверие между лесами рухнуло.
Исправление записей сервера имен в зонах делегирования _msdcs в каждом домене, чтобы они указывали на правильные серверы имен, решило проблему.
Я работал с кем-то по той же проблеме здесь: http://forums.iis.net/p/1175219/2023646.aspx. Однако мы еще не решили ее полностью и все еще пассивно работаем над ней. В их случае использование записи A вместо CNAME решило ее (временное исправление), но, поскольку вы уже используете запись A, это не сработает для вас.
Что делать, если вы создаете запись хостов для доменного имени? Это выведет AD в основном из уравнения. Кроме того, попробуйте поэкспериментировать с зоной интрасети IE, а также попробуйте зайти в другой браузер.
Проблема, вероятно, связана с SPN, хотя вы упомянули, что настраиваете записи.
И поскольку вы упомянули, что он работает с одних компьютеров, но не работает с другими, также проверьте настройки SPN компьютера и настройки доверия.
Я предполагаю, что сбойная страница защищена паролем? Если это не так, вы можете настроить Authentication / Anonymous так, чтобы он всегда выполнялся как удостоверение пула приложений. Тогда пользователь IIS_IUSRS не будет использоваться, и вам нужно будет только протестировать то, что вы используете для удостоверения пула приложений.