Получение запроса на вход с использованием встроенной проверки подлинности Windows

У меня есть приложение .NET 3.5, работающее под IIS 7 на сервере Windows 2003, и я не могу заставить интегрированную проверку подлинности Windows работать должным образом, так как я продолжаю получать запросы на вход в систему. Я включил проверку подлинности Windows в IIS, а все остальные типы безопасности отключены, а проверка подлинности / авторизация файла web.config моего приложения настроена как:

<system.web>
    <compilation debug="true" strict="false" explicit="true" targetFramework="3.5" />
    <authenticationmode="Windows"/>
    <authorization>
    <deny users = "?" />
    </authorization>
</system.web>

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

Я занимаюсь устранением этой проблемы в течение нескольких дней и не могу понять проблему. Основываясь на сообщениях с аналогичными проблемами, я подтвердил, что мой URL-адрес не содержит точек, дважды проверил, что в настройках моего IE задано значение «Включить встроенную проверку подлинности Windows», а также добавил свой URL-адрес на мои сайты интрасети, но все еще получаю всплывающее окно.

Для дальнейшего устранения неполадок я включил анонимную аутентификацию в IIS и изменил свой файл web.config, который позволяет мне войти, а затем добавил Response.Write (System.Security.Principal.WindowsIdentifity.getcurrent (). User.name.toString () ), чтобы попытаться увидеть, какой пользователь используется при аутентификации. В результате я получаю IIS APPPOOL \ myapp, который, очевидно, является пулом приложений IIS для моего приложения.

Я очень ценю любую помощь, которую может предоставить кто-либо, поэтому я все еще использую только проверку подлинности Windows, но не получаю всплывающее окно, а проверка подлинности Windows выполняется против фактического пользователя Windows.

Спасибо.

Дополнительное примечание после дальнейшего устранения неполадок:

Только что заметил, что когда вход в систему не удается и приглашение входа в Windows отображается снова, он показывает имя пользователя, который пытался войти в систему как «ИМЯ СЕРВЕРА» \ «ИМЯ ПОЛЬЗОВАТЕЛЯ», что заставило меня поверить, что он пытался проверить пользователя на сервере, а не на домен. Чтобы подтвердить это, я создал локальную учетную запись пользователя непосредственно на сервере приложений с тем же именем пользователя и паролем, что и пользователь сетевого домена, и попытался войти снова. В результате я снова получил приглашение для входа в систему, но когда на этот раз я ввел имя пользователя и пароль, я смог успешно войти в систему. Сетевой пользователь и сервер приложений находятся в одном домене, поэтому действительно не уверен, почему проверка подлинности IIS указывает на учетные записи локального сервера приложений, а не на учетные записи домена. Я понимаю, что на данный момент это вопрос IIS, поэтому отправляйте его на forum.iis.

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

Вот что я сделал (записал это здесь, чтобы потом найти).

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

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

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

В IIS все эти проблемы решаются с помощью значка аутентификации .

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

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

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

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

NTLM должен быть ПЕРВЫМ!

Затем проверьте , что в Advanced Settings ... Расширенная защита является Accept и включить проверку подлинности в режиме ядра Выдана:

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

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

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

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

https://webconnection.west-wind.com/docs/_4gi0ql5jb.htm (исходный, ныне несуществующий: http://support.microsoft.com/kb/896861 )

Из статьи поддержки, чтобы не потеряться:

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

Чтобы выполнить эту настройку вручную, найдите этот ключ в реестре на сервере:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

и отредактируйте или добавьте новый ключ:

DisableLoopbackCheck (DWORD)

затем отправил значение 1, чтобы отключить проверку обратной связи (локальная аутентификация работает), или 0 (локальная аутентификация не разрешена).

Или, что проще, вы можете использовать Powershell:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword

Похоже, что последние сборки Windows 10 (1803 и новее?) Также требуют этого параметра конфигурации для локальной аутентификации.

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

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

Дауди

Добавьте разрешение [Пользователи домена] для вашей веб-безопасности.

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

Не создавайте ошибок на своем сервере, все меняя. Если у вас есть окно с запросом на вход при использовании проверки подлинности Windows на 2008 R2, просто перейдите Providersи переместите ВВЕРХ NTLMдля каждого приложения. Когда он Negotiateстоит первым в списке, проверка подлинности Windows может перестать работать для определенного приложения в 2008 R2, и вам может быть предложено ввести имя пользователя и пароль, чем никогда. Иногда такое случается, когда вы обновляете свое приложение. Просто убедитесь, что NTLMэто первое в списке, и вы больше никогда не увидите эту проблему.

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

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

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

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

WindowsIdentity.GetCurrentправильно: вы должны получить пользователя APPPOOL. Это связано с тем, что текущим удостоверением является процесс ASP.NET, выполняющий ваш код. Если вы хотите, чтобы он возвращал пользователя, обращающегося к сайту, вам нужно добавить следующую строку в свой web.config:

<identity impersonate="true" />

Это заставляет процесс принять личность пользователя, запрашивающего страницу. Все действия будут выполняться от их имени, поэтому любые попытки чтения папок в сети или доступа к ресурсам базы данных и т.п. будут означать, что текущему пользователю потребуются разрешения на эти вещи. Вы можете узнать больше о выдаче себя за другое лицо здесь . Обратите внимание, что в зависимости от того, как настроена топология вашего веб-сервера или сервера базы данных, вы можете столкнуться с проблемами делегирования при включенном олицетворении.

Но ваша первоначальная проблема заключается в том, что, похоже, личность не может быть определена, и вы получаете всплывающее окно входа в систему. Замечу, что <deny>блокировка вам не понадобится, если вы отключили анонимную аутентификацию в IIS. Мы никогда не включаем его (кроме специальных <location>блоков и т. Д.), Поэтому я бы сказал, что вы можете попробовать удалить его и повторить попытку. Хотя все остальное звучит правильно.

Вы не указали, какой пользователь запускает пул приложений в IIS. Это индивидуальная учетная запись или учетная запись по умолчанию? Если это пользовательский, то это учетная запись домена или локальная учетная запись на веб-сервере? Для пользовательских учетных записей иногда может потребоваться еще несколько шагов, например, регистрация SPN. Кроме того, это может быть проблема с настраиваемой учетной записью, не имеющей разрешения в AD для разрешения учетной записи входящего пользователя.

Вы также можете проверить журналы IIS, чтобы узнать, какой ответ возвращается. Скорее всего, это будет 401, но после него должен быть дополнительный номер, например 401.2 или что-то в этом роде. Иногда этот дополнительный номер может помочь определить основную проблему. В этой статье базы знаний перечислены пять.

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

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

1. в iis7.5 - включите аутентификацию Windows для вашей интрасети (отключите все остальные аутентификации .. Также нет необходимости упоминать аутентификацию Windows в файле web.config

2. затем перейдите на клиентский компьютер .. IE8 или 9- Инструменты-Параметры Интернета-Безопасность-Локальная интрасеть-Сайты-расширенный-Добавьте свой сайт (снимите отметку «Требовать проверку сервера ...».

3. IE8 или 9 - Инструменты-Параметры Интернета-Безопасность-Локальная интрасеть-Пользовательский уровень-аутентификация-вход в систему-выбор автоматического входа в систему с текущим именем пользователя и паролем

4. сохраните эти настройки .. все готово .. Больше не нужно запрашивать имя пользователя и пароль.

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

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

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

Мне пришлось

1. откройте правила авторизации .NET в диспетчере IIS

   

2. и удалить правило отказа

   

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

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

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

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

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

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

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

Наконец-то добился успеха, сделав небольшой собственный RnD.

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

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

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

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

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

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

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

Крис Ван де Вийвер

У меня была такая же проблема, потому что пользователь (Identity), который я использовал в пуле приложений, не принадлежал группе IIS_IUSRS. Добавил пользователя в группу и все работает

В моем случае решением было (помимо настроек, предложенных выше) перезапустить мой / пользовательский локальный компьютер разработки / IIS (сервер хостинга). Мой пользователь только что был добавлен во вновь созданную группу безопасности AD - и политика не применялась к учетной записи пользователя AD, пока я не вышел из системы / не перезагрузил свой компьютер.

Надеюсь, это кому-то поможет.

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

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

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

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

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

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

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

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

У меня возникла та же проблема, и она была решена путем изменения идентификатора пула приложений пула приложений, в котором выполняется веб-приложение, на NetworkService.