ASP.NET и IIS выдают себя за работу [дубликат]

Если ваш URL-адрес имеет точки в доменном имени, IE будет обрабатывать его так, как будто это интернет-адрес, а не локальный. У вас есть как минимум два варианта:

1. Получите псевдоним, который будет использоваться в URL-адресе для замены server.domain. Например, myapp.
2. Выполните следующие действия на вашем компьютере.

Перейдите на сайт и отмените диалог входа в систему. Пусть это произойдет:

В настройках IE:

Вы пробовали войти в систему с префиксом домена, например. Домен \ Имя пользователя? IIS 6 по умолчанию использует хост-компьютер как домен по умолчанию, поэтому определение домена при входе в систему может решить проблему.

Проверка подлинности Windows в IIS7.0 или IIS7.5 не работает с kerberos (provider = Negotiate), когда идентификатор пула приложений является ApplicationPoolIdentity. Необходимо использовать Network Service или другую учетную запись. Другая возможность - использовать NTLM для работы Windows Authenticatio (в Windows Authentication, Providers, поставить NTLM сверху или удалить переговоры)

chris van de vijver

Может быть связано с браузером. Если вы используете IE, вы можете перейти в «Дополнительные параметры» и установить флажок «Включить встроенную проверку подлинности Windows».

У меня была аналогичная проблема, в которой я хотел защитить только определенную часть моего веб-сайта. Все работало хорошо, за исключением IE. У меня есть анонимная и Windows Authentication. Для анонимных пользователей Identity устанавливается на идентификатор пула приложений. Проблема была в Windows Authentication. После некоторого копания я запустил скрипача и обнаружил, что он использует Kerberos в качестве провайдера (на самом деле он настроен на Negotiate по умолчанию). Я переключил его на NTLM и исправил его. HTH

Daudi

Добавить разрешение [Domain Users] к вашей безопасности в Интернете.

• Щелкните правой кнопкой мыши на своем сайте в IIS в папке «Сайты»
• Нажмите «Редактировать разрешения» ...
• Выберите вкладку «Безопасность»
• В разделе «Группа» или «Пользовательские имена» нажмите кнопку «Изменить»
• . В окне «Разрешения» под именами групп или пользователей нажмите «Добавить». ...
• Введите [имена пользователей домена] в именах объектов, чтобы выбрать текстовую область, и нажмите «ОК», чтобы применить изменение
• Нажмите «ОК», чтобы закрыть разрешение.
• Нажмите «ОК», чтобы закрыть окно «Свойства» и применить новые настройки

У меня была эта проблема на .net core 2 и после прохождения большинства предложений отсюда кажется, что мы пропустили настройку на web.config

<aspNetCore processPath="dotnet" arguments=".\app.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Правильная настройка была forwardWindowsAuthToken = "true «это кажется очевидным сейчас, но когда есть так много ситуаций для одной и той же проблемы, сложнее определить

Edit: я также нашел полезной следующую статью Msdn , которая проходит через устранение проблемы.

В моем случае настройки авторизации были неправильно настроены.

Мне пришлось

1. открыть правила авторизации .NET в IIS Менеджер [/g3]
2. и удалите правило Deny [/g4]

У меня есть сервер Windows 2008, над которым я работаю, поэтому мой ответ не совсем такой же, как у OP на сервере Windows 2003.

Вот что я сделал (запись этого здесь я могу найти его позже).

У меня была такая же проблема:

[/g0]

В моем файле Web.config , У меня был этот раздел:

<system.web>
    <authentication mode="Windows" />
    <authorization>
        <allow users="*" />
        <deny users="?" />
    </authorization>
</system.web>

В IIS все они, похоже, решаются под значком «Идентификация».

1. Изменить разрешения: убедитесь, что ваш ASP.NET У учетной записи есть разрешение.

[/g1]

Теперь перейдите к функциям аутентификации:

[/g2]

Включить анонимную аутентификацию с помощью IUSR:

[/g3]

Включить проверку подлинности Windows, затем нажмите правой кнопкой мыши, чтобы установить Провайдеры.

NTLM должен быть FIRST!

[/g4]

Затем проверьте, что в разделе Дополнительные настройки ... Расширенная защита является Accept и Enabled. Проверка подлинности в режиме ядра проверена:

[/g5]

Как только я это сделал, я вернулся к своему веб-приложению, нажал ссылку «Обзор», и вошел в систему без необходимости повторять мои учетные данные.

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

Только для других людей. Если ошибка является 401.1 Unauthorized, а ваш код ошибки соответствует 0xc000006d, то вы фактически выполняете функцию безопасности, которая блокирует запросы к FQDN или пользовательским заголовкам хоста, которые не соответствуют вашему локальному имени компьютера:

Следуйте этой статье поддержки, чтобы устранить проблему:

http://support.microsoft.com/kb/896861

Это один взял меня некоторое время, потому что комментарии остальных не помогли мне. Я нашел эту статью и исправил ее!

Я столкнулся с тем же вопросом, что и запрос, и сделал быстрый поиск, и ничто в Интернете не исправит его.

В IIS -> Предварительная настройка -> Учетные данные физического пути (пуст)

Как только я добавил идентификатор машины (домен / пользователь), который имеет доступ к VM / серверу, запрос пароля будет остановлен.

Надеюсь, что это поможет

Я просто решил аналогичную проблему с приложением ASP.Net.

Признаки: я мог войти в свое приложение с использованием локального пользователя, но не для пользователя домена, даже если машина была правильно соединена к домену (как вы говорите в своей дополнительной записке). В средстве просмотра событий безопасности произошло событие с ID = 4625 «Недопустимый sid sid».

Решение: здесь найдено решение здесь . Проблема заключалась в том, что мои тестовые машины, где клонировали виртуальные машины (Windows Server 2008 R2, один контроллер домена и один веб-сервер). Оба имеют одинаковый SID машины, что, по-видимому, вызвало проблемы. Вот что я сделал:

1. Удалите веб-сервер из домена.
2. Запустите c: \ Windows \ System32 \ Sysprep \ Sysprep.exe в виртуальной машине.
3. Перезагрузите виртуальную машину.
4. Присоедините веб-сервер к домену.

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

Это исправило это для меня.

Мой сервер и клиентский ПК - это Windows 7 и находятся в одном домене

1. в iis7.5 - включить проверку подлинности Windows для вашего Интранет (отключить всю другую аутентификацию .. также не нужно упоминать проверку подлинности Windows в файле web.config
2. , затем перейти на клиентский компьютер .. IE8 или 9-Tools-internet Options-Security-Local Intranet-Sites- advanced-Добавьте свой сайт (снимите флажок «require server verfi ...» ticketno.no need
3. IE8 или 9-Tools-internet Options-Security-Local Intranet-Custom level-userauthentication-logon- выберите автоматический вход в систему с текущим именем пользователя и паролем
4. сохраните эти настройки .. все готово .. Больше не запрашивается имя пользователя и пароль.
5. Убедитесь, что ваш клиентский ПК является частью домена, у вас должен быть объект групповой политики для этих настроек. .. orelse этот параметр вернется обратно, когда пользователь будет входить в Windows в следующий раз

Я пробовал описанные выше трюки конфигурации IIS и взлома реестра loopback, и я просмотрел и воссоздал разрешения пула приложений и еще дюжину других вещей и до сих пор не смог избавиться от цикла проверки подлинности на моей рабочей станции разработки с помощью IIS Express или IIS 7.5, с локального или удаленного сеанса просмотра. Я получил четыре ответа статуса 401.2 и пустую страницу. Точно такой же сайт, развернутый на моем промежуточном сервере IIS 8.5, работает безупречно.

Наконец, я заметил разметку в Body Response, которая была пуста браузером, содержала страницу по умолчанию для успешного входа в систему. Я определил, что Custom Обработка ошибок для ASP.NET и HTTP для ошибки 401 препятствовала / препятствовала аутентификации Windows моей рабочей станции, но не промежуточному серверу. Я провел несколько часов, играя с этим, но как только я удалил пользовательскую обработку только для ошибки 401, рабочая станция вернулась к норме. Я представляю это еще один способ снять вашу собственную ногу.

В нашей интрасети проблема была решена на стороне клиента, изменив настройки в безопасности, как показано здесь. Любой из флажков справа работал для нас.

У меня тоже была такая же проблема. Пробовал большинство вещей, найденных на этом и других форумах.

Наконец, это было успешным после выполнения небольшого собственного RnD.

Я зашел в настройки IIS, а затем в настройки моего веб-сайта добавил мои Группа пользователей домена домена.

Теперь, когда все пользователи моего домена получили доступ к этому сайту, я не сталкивался с этой проблемой.

Надеюсь, что это поможет