Отримання запиту на вхід за допомогою інтегрованої автентифікації 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, воно відображає ім'я користувача, яке намагалося увійти як "SERVERNAME" \ "USERNAME", що змусило мене повірити, що він намагався перевірити користувача проти сервера проти домен. Щоб підтвердити це, я створив локальний обліковий запис користувача безпосередньо на сервері додатків із тими ж ім’ям користувача та паролем, що і користувач мережевого домену, і спробував увійти знову. В результаті я отримав підказку для входу знову, але коли я цього разу ввів ім’я користувача та пароль, я зміг успішно увійти. Користувач мережі та сервер додатків знаходяться в одному домені, тому дійсно не впевнені, чому аутентифікація IIS вказує на облікові записи локальних серверів додатків, а не на облікові записи домену. Я розумію, що це питання IIS на даний момент, тому розміщую його на forums.iis.

У мене є сервер Windows 2008, над яким я працюю, тому моя відповідь не є повністю такою ж, як у ОП на сервері 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 і включити перевірку автентичності в режимі ядра Видана:

Як тільки я це зробив, я повернувся до своєї веб-програми, натиснув посилання Огляд і ввійшов, не вказуючи своїх даних ще раз.

Я сподіваюся, що це виявиться корисним для багатьох із вас, і я сподіваюся, що це стане в нагоді і для мене пізніше.

Просто на користь інших людей. Якщо помилка - це 401.1 Unauthorizedі ваш код помилки збігається 0xc000006d, ви фактично наштовхуєтесь на "функцію" безпеки, яка блокує запити до FQDN або власні заголовки хоста, які не відповідають імені вашої локальної машини:

Дотримуйтесь цієї статті підтримки, щоб вирішити проблему:

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. Увімкнено функцію автентичності Anonymous та Windows. Для анонімних ідентифікаторів встановлюється ідентичність пулу додатків. Проблема була з автентифікацією Windows. Після деякого копання я запустив фідлера і виявив, що він використовує Kerberos в якості постачальника (насправді він встановлений як «Переговори» за замовчуванням). Я переключив його на NTLM і це виправило. HTH

Дауді

Додайте дозвіл [Користувачі домену] у вашу веб-безпеку.

• Клацніть правою кнопкою миші на своєму сайті в IIS у папці Сайти
• Натисніть Редагувати дозволи ...
• Виберіть вкладку Безпека
• У розділі Групи або імена користувачів натисніть кнопку Змінити ...
• У спливаючому дозволі під іменами групи або користувачів натисніть Додати ...
• Введіть [Користувачі домену] у імена об’єктів, щоб вибрати область тексту, та натисніть кнопку ОК, щоб застосувати зміни
• Натисніть кнопку ОК, щоб закрити спливаючі дозволи
• Натисніть кнопку ОК, щоб закрити спливаючі властивості та застосувати нові налаштування

Не створюйте помилок на своєму сервері, змінюючи все. Якщо у вас є запит на Windows, щоб увійти під час використання автентифікації Windows на 2008 R2, просто перейдіть до Providersта перемістіть UP NTLMдля кожної програми. Коли Negotiateце перший у списку, автентифікація Windows може припинити роботу з властивостями для конкретного додатка на 2008 R2, і вам буде запропоновано ввести ім'я користувача та пароль, ніж ніколи не працювати. Це колись трапляється, коли ви оновлювали свою заявку. Просто будьте впевнені, що NTLMє першим у списку, і ви ніколи більше не побачите цієї проблеми.

Якщо у вашій URL-адресі є точки в доменному імені, IE трактуватиме її як Інтернет-адресу, а не локальну. У вас є як мінімум два варіанти:

1. Отримайте псевдонім для використання в URL-адресі для заміни server.domain. Наприклад, myapp.
2. Виконайте наведені нижче кроки на комп’ютері.

Зайдіть на сайт і скасуйте діалогове вікно входу. Нехай це станеться:

У налаштуваннях IE:

WindowsIdentity.GetCurrentправильно: ви повинні отримати користувача APPPOOL. Це тому, що процес ASP.NET, який виконує ваш код, є поточною ідентичністю. Якщо ви хочете, щоб він повернув користувача, що потрапляє на особу сайту, вам потрібно буде додати наступний рядок у веб-конфінг:

<identity impersonate="true" />

Це змушує процес припускати особу користувача, який запитує сторінку. Усі дії виконуватимуться від їх імені, тому будь-які спроби читання папок у мережі або доступу до ресурсів бази даних тощо можуть означати, що поточному користувачеві потрібні дозволи на ці речі. Більш детально про себе себе можна прочитати тут . Зауважте, що залежно від того, як налаштована топологія вашого веб-сервера / бази даних, ви можете зіткнутися з проблемами делегування з увімкненою особою.

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

Ви не вказали, який користувач виконує пул додатків у IIS. Це користувацький обліковий запис чи він за замовчуванням? Якщо це звичай, це доменний обліковий запис або локальний рахунок на веб-сервері? Для користувацьких облікових записів іноді можуть знадобитися ще кілька кроків, наприклад, реєстрація SPN. Також може виникнути проблема з користувацьким обліковим записом, який не має дозволу в AD для вирішення облікового запису вхідного користувача.

Ви також можете перевірити журнали IIS, щоб побачити, який відповідь повертається. Швидше за все, це буде 401, але він повинен мати після нього номер підрозділу, як 401.2 або щось подібне. Цей підрядний номер іноді може допомогти визначити основну проблему. У цій статті KB перелічено п'ять.

Це зафіксувало це для мене.

Мій ПК та клієнтський сервер - це Windows 7 і знаходяться в одному домені

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

2. потім перейдіть до клієнтського ПК. IE8 або 9- Інструменти-параметри Інтернету-Безпека-Локальний Інтранет-Сайти-розширений-Додайте свій сайт (зніміть мітку "вимагаю верфі ..."

3. IE8 або 9 - Інструменти-Інтернет-параметри-Безпека-Локальний Інтранет-Користувальницький рівень-використанняавторизація-вхід-автоматичний вхід з поточним ім'ям користувача та паролем

4. збережіть ці налаштування .. ви зробили .. Більше не вимагає ввести ім'я користувача та пароль.

5. Переконайтеся, що оскільки ваш клієнтський ПК є частиною домену, у вас повинен бути GPO для цих налаштувань, .. orelse це налаштування повернеться назад, коли користувач наступного разу увійде у Windows.

Може бути пов’язаний із браузером. Якщо ви використовуєте IE, ви можете перейти до розширених налаштувань і встановити прапорець "Увімкнути інтегровану автентифікацію Windows".

У моєму випадку налаштування авторизації не були налаштовані належним чином.

мені довелося

1. відкрийте Правила авторизації .NET в IIS Manager

   

2. і видалити правило відмови

   

У нашій Інтранеті цю проблему вирішили на стороні клієнта, змінивши налаштування безпеки, як показано тут. Будь-який із прапорців праворуч працював у нас.

Я просто вирішив подібну проблему з додатком ASP.Net.

Симптоми: я міг увійти в свій додаток за допомогою місцевого користувача, але не користувача домену, навіть якщо машина була правильно приєднана до домену (як ви говорите в додатковій примітці). У переглядачі подій безпеки відбулася подія з ідентифікатором = 4625 "Домен sid невідповідний".

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

1. Видаліть веб-сервер із домену.
2. Запустіть c: \ Windows \ System32 \ Sysprep \ Sysprep.exe у віртуальній машині.
3. Перезавантажте програму VM.
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 (провайдером = Переговори), коли ідентифікація пулу додатків - ApplicationPoolIdentity. Треба використовувати мережевий сервіс або інший вбудований обліковий запис. Інша можливість - використовувати NTLM, щоб змусити Windows Authenticatio працювати (у програмі «Автентифікація Windows», «Провайдери», поставити NTLM зверху або видалити узгодження)

Кріс ван де Віджвер

У мене була така ж проблема, тому що користувач (Identity), який я використовував у пулі додатків, був не нижче групи IIS_IUSRS. Додав користувача до групи і все працює

У моєму випадку рішення було (крім коригувань, запропонованих вище) перезапустити локальний комп'ютер розвитку / IIS (хостинг-сервер) мого / користувачів. Мій користувач щойно був доданий до новоствореної групи безпеки AD - і політика не застосовується до облікового запису AD користувача, поки я не вийшов / перезапустив комп’ютер.

Сподіваюся, що це комусь допоможе.

Я зіткнувся з тією ж проблемою, що спонукає довіритись, і здійснив швидкий пошук, і нічого в Інтернеті не виправить. Щоб знайти проблему, нерозумно пройшло певний час.

У IIS -> Попереднє налаштування -> Уповноважений фізичного шляху (порожній)

Як тільки я додав ідентифікатор машини (домен / користувач), який має доступ до VM / сервера, запит пароля припиниться.

Сподіваюся, це допомагає

У мене виникло це питання на .net core 2, і після перегляду більшості пропозицій звідси здається, що ми пропустили налаштування на web.config

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

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

Редагувати: Я також виявив корисною наступну статтю Msdn, яка проходить через усунення несправностей.

У мене виникла та сама проблема, і вона була вирішена шляхом зміни ідентичності пулу додатків пулу програм, під яким веб-додаток працює на NetworkService