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

108

У меня есть приложение .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.

Кейси
источник
4
Между аутентификацией и режимом должен быть пробел, например: <authentication mode="Windows" />Надеюсь, это была опечатка в вашем вопросе?
Шон Хэнли
3
Вы используете iis 7 на сервере 2003, вы уверены, что я почти уверен, что это невозможно.
Anicho

Ответы:

86

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

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

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

приглашение для входа

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

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

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

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

Разрешение ASP.NET

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

Возможности аутентификации

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

Анонимная аутентификация

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

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

Проверка подлинности Windows

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

Расширенные настройки

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

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

jp2code
источник
1
Спасибо, Суджай. Я заметил, что у большинства этих техник на ТАК не хватает изображений, чтобы показать, о чем они говорят, поэтому я хотел показать все шаги, которые я использовал. Если это не сработает для кого-то, по крайней мере, они могут увидеть все шаги, которые они предприняли, и какие еще варианты можно попробовать.
jp2code
1
Это потрясающе! Я схожу с ума из-за этого. И фотографии сделали это НАСТОЛЬКО проще. СПАСИБО!!
KratosMafia,
1
У меня это тоже сработало, но в конце мне пришлось перезапустить свой экземпляр Windows 2008 r2. Думаю, стоит упомянуть об этом.
Алексей Мялкин
6
не работает для Windows Server 2012 с IIS 8.5
Мин Нгуен
3
Разве это не просто обеспечивает анонимную аутентификацию, позволяя игнорировать аутентификацию Windows? Подлинный вопрос, однако, вот как мне кажется вышесказанное.
Пол Ходжсон
50

Просто ради блага других людей. Если ошибка - 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 и новее?) Также требуют этого параметра конфигурации для локальной аутентификации.

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

Камраникус
источник
3
Вы, сэр, мой гребаный герой! Я прошел через так много «решений», чтобы добраться до этого. Спасибо!
dewd
1
Святая корова! два дня пытались заставить эту штуку работать, и наконец ты дал мне ответ! Спасибо!
BernieSF
1
После того, как мы просмотрели несколько ответов и увидели, что конфигурация идентична моей, это был ответ!
Sietse
1
Вы легенда! Это сработало для меня. Я долго это искал.
Энди Веннеллс
2
@PTD Обновлено новой статьей и добавлено резюме для потомков, чтобы не потеряться. Так много для поддержки постоянных ссылок MS!
kamranicus
26

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

Дауди

Дауди
источник
1
Вот и все, спасибо! Мне удалось подобрать пользователя Windows при локальном доступе, но запрос учетных данных появится с любого другого компьютера в домене.
JSancho
1
@Daudi Как установить личность для каждого метода аутентификации?
Роб Белл
18

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

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

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

Slo
источник
1
Это исправило это для меня.
Bigwave
9
Если, конечно, вы не хотите, чтобы NTLM был первым в вашем списке ... у этого действия есть последствия, любой, кто вносит такое изменение, должен понимать разницу между NTLM и Negotiate (на самом базовом уровне Negotiate первые попытки аутентификации Kerberos и падение вернуться к NTLM, если это не удается). Если вам нужен Kerberos (а многие его хотят), это не лучшее решение. Некоторые подробности здесь: msdn.microsoft.com/en-us/library/aa480475.aspx
TCC
8

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

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

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

введите описание изображения здесь

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

введите описание изображения здесь

введите описание изображения здесь

введите описание изображения здесь

Боб Хорн
источник
1
Мы используем Windows Server 2012, и это единственное решение, которое сработало для нас. Большое спасибо!
ashilon
5

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

<identity impersonate="true" />

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

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

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

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

Шон Хэнли
источник
+1 за упоминание о требовании SPN. Фактически, большинство проблем, с которыми я столкнулся со всплывающими окнами входа, были связаны с отсутствием имени участника-службы в среде Kerberos.
SBS
5

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

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

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

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

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

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

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

Хосе Арун
источник
2
Для 1) я фактически включил олицетворение и аутентификацию Windows, и все было в порядке. Ключевым моментом для меня было 2) где вы добавляете адрес удаленного сайта в зону локальной интрасети.
SideFX
4

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

Данте
источник
4

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

Мне пришлось

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

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

    удалить правило запрета
johnecon
источник
3

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

Свойства обозревателя IE

мошеб
источник
2

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

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

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

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

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

Матье
источник
Клонирование - отстой, когда вы пытаетесь настроить ограниченное делегирование.
SideFX
2

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

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

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

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

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

Саураб
источник
4
О каких вариантах разрешений вы говорите? Можете ли вы более подробно рассказать о том, что вы сделали?
Дрю Чапин
1

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

халомический
источник
1

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

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

Майк М
источник
0

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

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

Крис ван де виджвер
источник
3
Неправильно. Перезагрузите ваш сервер. Обратите внимание, что теперь это работает. Примените исправление KB2545850.
Амит Найду,
Вот это да. Перезагрузка только что исправила это для меня. Теперь нужно проверить, как долго. Любые идеи? Пока не исследовал Hotfix.
mplwork
у нас был абсолютно такой же случай - Negotiate не работал с ApplicationPoolIdentity до перезагрузки.
SergeyT
0

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

user3731689
источник
0

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

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

уки
источник
0

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

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

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

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

Као
источник
0

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

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

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

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

Евгений
источник
-1

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

Сайед
источник