Otrzymywanie monitu o logowanie przy użyciu zintegrowanego uwierzytelniania systemu Windows

Mam aplikację .NET 3.5 działającą w ramach usług IIS 7 na serwerze z systemem Windows 2003 i nie mogę uzyskać prawidłowego działania zintegrowanego uwierzytelniania systemu Windows, ponieważ w dalszym ciągu otrzymuję monit o zalogowanie się. Ustawiłem uwierzytelnianie systemu Windows na włączone w usługach IIS z wyłączonymi wszystkimi innymi typami zabezpieczeń, a uwierzytelnianie / autoryzacja pliku web.config mojej aplikacji jest skonfigurowana jako:

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

W tej konfiguracji oczekuję, że za kulisami weryfikacja użytkownika systemu Windows zezwoli na dostęp i odmówi anonimowym użytkownikom. Jednak to, co otrzymuję, to wyskakujące okienko logowania do systemu Windows, gdy próbuję uzyskać dostęp do witryny.

Od kilku dni rozwiązuję ten problem i nie mogę go rozwiązać. Na podstawie postów z podobnymi problemami potwierdziłem, że mój adres URL nie zawiera żadnych kropek, dwukrotnie sprawdziłem, czy moje ustawienia IE są ustawione na Włącz zintegrowane uwierzytelnianie systemu Windows, a także dodałem mój adres URL do moich witryn intranetowych, ale nadal pojawia się wyskakujące okienko.

Aby dalej rozwiązać ten problem, włączyłem uwierzytelnianie anonimowe w usługach IIS i zmodyfikowałem plik web.config, do którego mogę bezpośrednio wejść, a następnie dodać Response.Write (System.Security.Principal.WindowsIdentifity.getcurrent (). User.name.toString () ), aby spróbować zobaczyć, który użytkownik jest używany podczas uwierzytelniania. Wynik, jaki otrzymuję, to IIS APPPOOL \ myapp, który jest oczywiście pulą aplikacji IIS dla mojej aplikacji.

Naprawdę doceniam każdą pomoc, jakiej ktokolwiek może udzielić, więc nadal używam tylko uwierzytelniania systemu Windows, ale nie otrzymuję wyskakującego okienka, a uwierzytelnianie systemu Windows jest wykonywane na rzeczywistym użytkowniku systemu Windows.

Dzięki.

Dodatkowa uwaga po dalszym rozwiązywaniu problemów:

Właśnie zauważyłem, że gdy logowanie nie powiedzie się i monit logowania do systemu Windows wyświetla się ponownie, pokazuje nazwę użytkownika, który próbował zalogować się jako „NAZWA SERWERA” \ „NAZWA UŻYTKOWNIKA”, co doprowadziło mnie do przekonania, że ​​próbuje zweryfikować użytkownika na serwerze w porównaniu z domena. Aby to potwierdzić, utworzyłem konto użytkownika lokalnego bezpośrednio na serwerze aplikacji z tą samą nazwą użytkownika i hasłem co użytkownik domeny sieciowej i spróbowałem zalogować się ponownie. W rezultacie ponownie otrzymałem monit o logowanie, ale kiedy tym razem wprowadziłem nazwę użytkownika i hasło, udało mi się pomyślnie zalogować. Użytkownik sieci i serwer aplikacji znajdują się w tej samej domenie, więc naprawdę nie jestem pewien, dlaczego uwierzytelnianie usług IIS wskazuje na konta lokalnego serwera aplikacji, a nie na konta domeny. Zdaję sobie sprawę, że w tym momencie jest to pytanie dotyczące IIS, więc publikuję na forums.iis.

Mam serwer Windows 2008, na którym pracuję, więc moja odpowiedź nie jest taka sama, jak to, co ma OP na serwerze Windows 2003.

Oto, co zrobiłem (nagrałem to tutaj, aby móc to później znaleźć).

Miałem ten sam problem:

W moim pliku Web.config miałem tę sekcję:

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

W usługach IIS wydaje się, że wszystkie te problemy można rozwiązać za pomocą ikony uwierzytelniania .

1. Uprawnienia do edycji: upewnij się, że Twoje konto ASP.NET ma uprawnienia. Mój nie został pierwotnie dodany.

Teraz przejdź do funkcji uwierzytelniania :

Włącz uwierzytelnianie anonimowe za pomocą IUSR:

Włącz uwierzytelnianie systemu Windows , a następnie kliknij prawym przyciskiem myszy, aby ustawić dostawców .

NTLM musi być PIERWSZE!

Następnie sprawdź, czy pod Advanced Settings ... Ochrona rozszerzona jest Zebrane i włączyć uwierzytelnianie w trybie jądra jest zaznaczone:

Gdy to zrobiłem, wróciłem do mojej aplikacji internetowej, kliknąłem łącze Przeglądaj i zalogowałem się bez konieczności ponownego podawania poświadczeń.

Mam nadzieję, że okaże się to korzystne dla wielu z was i mam nadzieję, że później mi się przyda.

Tylko dla dobra innych ludzi. Jeśli błąd to a, 401.1 Unauthorizeda kod błędu jest zgodny 0xc000006d, oznacza to, że w rzeczywistości korzystasz z „funkcji” zabezpieczeń, która blokuje żądania do FQDN lub niestandardowych nagłówków hosta, które nie są zgodne z nazwą komputera lokalnego:

Postępuj zgodnie z tym artykułem pomocy, aby rozwiązać problem:

https://webconnection.west-wind.com/docs/_4gi0ql5jb.htm (oryginał, obecnie nieistniejący: http://support.microsoft.com/kb/896861 )

Z artykułu pomocy, aby upewnić się, że się nie zgubi:

Obejściem jest włamanie do rejestru, które wyraźnie wyłącza tę zasadę.

Aby ręcznie wykonać tę konfigurację, znajdź ten klucz w rejestrze na serwerze:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

i edytuj lub dodaj nowy klucz:

DisableLoopbackCheck (DWORD)

następnie wysłał wartość 1, aby wyłączyć kontrolę sprzężenia zwrotnego (działa uwierzytelnianie lokalne) lub 0 (uwierzytelnianie lokalne jest niedozwolone).

Lub łatwiej możesz użyć Powershell:

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

Wygląda na to, że najnowsze wersje systemu Windows 10 (1803 i nowsze?) Również wymagają tego ustawienia konfiguracji w celu uwierzytelniania lokalnego.

Zajęło mi to trochę czasu, ponieważ komentarze innych tutaj nie pomogły mi. Znalazłem ten artykuł i naprawiłem to!

Miałem podobny problem, w którym chciałem chronić tylko określoną część mojej witryny. Wszystko działało dobrze z wyjątkiem IE. Mam włączone zarówno uwierzytelnianie anonimowe, jak i uwierzytelnianie systemu Windows. W przypadku anonimowych tożsamość jest ustawiona na tożsamość puli aplikacji. Problem dotyczył uwierzytelniania systemu Windows. Po pewnym przeszukaniu uruchomiłem skrzypce i stwierdziłem, że używa Kerberos jako dostawcy (w rzeczywistości jest domyślnie ustawiony na Negocjuj). Zmieniłem go na NTLM i to naprawiło. HTH

Daudi

Dodaj uprawnienia [Użytkownicy domeny] do swoich zabezpieczeń internetowych.

• Kliknij prawym przyciskiem myszy witrynę w usługach IIS w folderze Witryny
• Kliknij Edytuj uprawnienia ...
• Wybierz kartę Zabezpieczenia
• W sekcji Grupa lub nazwy użytkownika kliknij przycisk Edytuj ...
• W wyskakującym okienku Uprawnienia w obszarze Nazwy grupy lub użytkownika kliknij Dodaj ...
• Wprowadź [Użytkownicy domeny] w nazwach obiektów, aby zaznaczyć pole tekstowe i kliknij OK, aby zastosować zmianę
• Kliknij OK, aby zamknąć wyskakujące okienko Uprawnienia
• Kliknij OK, aby zamknąć okienko Właściwości i zastosować nowe ustawienia

Nie twórz błędów na serwerze, zmieniając wszystko. Jeśli w systemie Windows pojawi się monit o zalogowanie się podczas korzystania z uwierzytelniania systemu Windows w wersji 2008 R2, po prostu przejdź do Providersi przesuń W GÓRĘ NTLMdla każdej aplikacji. Gdy Negotiateznajduje się na pierwszym miejscu na liście, uwierzytelnianie systemu Windows może przestać działać jako właściwość dla określonej aplikacji w wersji 2008 R2 i może zostać wyświetlony monit o wprowadzenie nazwy użytkownika i hasła, niż nigdy. Dzieje się tak czasami, gdy aktualizujesz swoją aplikację. Tylko upewnij się, że NTLMjest to pierwsze na liście i nigdy więcej nie zobaczysz tego problemu.

Jeśli Twój adres URL ma kropki w nazwie domeny, IE potraktuje go jako adres internetowy, a nie lokalny. Masz co najmniej dwie możliwości:

1. Uzyskaj alias do użycia w adresie URL, aby zastąpić server.domain. Na przykład myapp.
2. Wykonaj poniższe czynności na swoim komputerze.

Przejdź do witryny i anuluj okno logowania. Niech to się stanie:

W ustawieniach IE:

WindowsIdentity.GetCurrentjest poprawne: powinieneś pobrać użytkownika APPPOOL. Dzieje się tak, ponieważ proces ASP.NET, który wykonuje kod, jest bieżącą tożsamością. Jeśli chcesz, aby zwracał on użytkownika uderzającego w tożsamość witryny, musisz dodać następujący wiersz w swoim pliku web.config:

<identity impersonate="true" />

Powoduje to, że proces przyjmuje tożsamość użytkownika żądającego strony. Wszystkie działania będą wykonywane w ich imieniu, więc wszelkie próby odczytu folderów w sieci lub dostępu do zasobów bazy danych itp. Będą oznaczać, że bieżący użytkownik będzie potrzebował uprawnień do tych rzeczy. Więcej informacji o podszywaniu się znajdziesz tutaj . Należy pamiętać, że w zależności od konfiguracji topologii serwera WWW / bazy danych mogą wystąpić problemy z delegowaniem przy włączonej personifikacji.

Ale Twoim pierwotnym problemem jest to, że wygląda na to, że nie można określić tożsamości i pojawia się wyskakujące okienko logowania. Zwrócę uwagę, że <deny>blokada nie jest potrzebna , jeśli wyłączyłeś uwierzytelnianie anonimowe w usługach IIS. Nigdy go nie dołączamy (z wyjątkiem specjalnych <location>bloków i tym podobnych), więc powiedziałbym, że możesz spróbować go usunąć i spróbować ponownie. Jednak wszystko inne brzmi dobrze.

Nie określono, który użytkownik uruchamia pulę aplikacji w usługach IIS. Czy jest to konto niestandardowe, czy domyślne? Jeśli jest niestandardowy, czy jest to konto domeny czy konto lokalne na serwerze internetowym? Konta niestandardowe mogą czasami wymagać wykonania kilku dodatkowych czynności, takich jak rejestracja nazwy SPN. Może również występować problem z kontem niestandardowym, które nie ma uprawnień w usłudze AD do rozpoznawania konta użytkownika przychodzącego.

Możesz również sprawdzić dzienniki usług IIS, aby zobaczyć, jaka odpowiedź jest zwracana. Najprawdopodobniej będzie to 401, ale po nim powinien znajdować się numer podrzędny, np. 401.2 lub coś w tym rodzaju. Ta liczba podrzędna może czasami pomóc w określeniu problemu głównego. W artykule z bazy wiedzy wymieniono pięć.

To naprawiło to dla mnie.

Mój serwer i komputer kliencki to Windows 7 i znajdują się w tej samej domenie

1. w iis7.5 - włącz uwierzytelnianie systemu Windows dla swojego Intranetu (wyłącz wszystkie inne uwierzytelnianie .. również Nie trzeba wspominać o uwierzytelnianiu systemu Windows w pliku web.config

2. następnie przejdź do komputera klienckiego. IE8 lub 9- Narzędzia-Opcje internetowe-Zabezpieczenia-Lokalny intranet-Witryny-zaawansowane-Dodaj swoją witrynę (usuń znacznik „Wymagaj serwera verfi ...” - nie ma potrzeby

3. IE8 lub 9 - Narzędzia - Opcje internetowe - Bezpieczeństwo - Lokalny intranet - Niestandardowy poziom - uwierzytelnianie użytkownika - logowanie - wybierz automatyczne logowanie z bieżącą nazwą użytkownika i hasłem

4. zapisz te ustawienia… gotowe… Koniec z pytaniem o nazwę użytkownika i hasło.

5. Upewnij się, że ponieważ twój komputer kliencki jest częścią domeny, musisz mieć obiekt zasad grupy dla tych ustawień ... lub to ustawienie zostanie przywrócone, gdy następnym razem użytkownik zaloguje się do systemu Windows

Może być związane z przeglądarką. Jeśli używasz IE, możesz przejść do Ustawień zaawansowanych i zaznaczyć pole wyboru „Włącz zintegrowane uwierzytelnianie systemu Windows”.

W moim przypadku ustawienia autoryzacji nie zostały poprawnie skonfigurowane.

musiałem

1. Otwórz reguły autoryzacji .NET w Menedżerze usług IIS

   

2. i usunąć Deny Rule

   

W naszym intranecie problem został rozwiązany po stronie klienta poprzez zmianę ustawień zabezpieczeń, jak pokazano tutaj. Każde z pól wyboru po prawej stronie zadziałało dla nas.

Właśnie rozwiązałem podobny problem z aplikacją ASP.Net.

Objawy: Mogłem zalogować się do mojej aplikacji przy użyciu użytkownika lokalnego, ale nie użytkownika domeny, nawet jeśli komputer został poprawnie przyłączony do domeny (jak powiesz w swojej dodatkowej uwadze). W przeglądarce zdarzeń zabezpieczeń wystąpiło zdarzenie o identyfikatorze = 4625 „Niespójny identyfikator domeny”.

Rozwiązanie: znalazłem tutaj rozwiązanie . Problem polegał na tym, że na moich testowych maszynach były sklonowane maszyny wirtualne (Windows Server 2008 R2; jeden kontroler domeny i jeden serwer WWW). Oba miały ten sam identyfikator SID maszyny, co najwyraźniej powodowało problemy. Oto co zrobiłem:

1. Usuń serwer WWW z domeny.
2. Uruchom c: \ Windows \ System32 \ Sysprep \ Sysprep.exe na maszynie wirtualnej.
3. Uruchom ponownie maszynę wirtualną.
4. Dołącz do serwera WWW do domeny.

Tracisz niektóre ustawienia w procesie (preferencje użytkownika, statyczny adres IP, odtworzenie certyfikatu z podpisem własnym), ale teraz, gdy je odtworzyłem, wszystko działa poprawnie.

Miałem też ten sam problem. Wypróbowałem większość rzeczy znalezionych na tym i innych forach.

W końcu odniósł sukces po zrobieniu małego własnego RnD.

Poszedłem do ustawień IIS, a następnie do opcji uprawnień mojej witryny internetowej dodałem grupę użytkowników domeny organizacji.

Ponieważ wszyscy użytkownicy mojej domeny otrzymali dostęp do tej witryny, nie napotkałem tego problemu.

Mam nadzieję że to pomoże

Czy próbowałeś zalogować się przy użyciu prefiksu swojej domeny, np. DOMENA \ Nazwa użytkownika? Usługi IIS 6 domyślnie używają komputera hosta jako domeny domyślnej, więc określenie domeny podczas logowania może rozwiązać problem.

Wypróbowałem powyższe sztuczki konfiguracyjne IIS i hack do rejestru sprzężenia zwrotnego, przejrzałem i odtworzyłem uprawnienia do puli aplikacji oraz kilkanaście innych rzeczy i nadal nie byłem w stanie pozbyć się pętli uwierzytelniania działającej na mojej deweloperskiej stacji roboczej z IIS Express lub IIS 7.5, z lokalnej lub zdalnej sesji przeglądania. Otrzymałem cztery odpowiedzi o statusie 401.2 i pustą stronę. Dokładnie ta sama witryna wdrożona na moim serwerze pomostowym IIS 8.5 działa bez zarzutu.

W końcu zauważyłem, że znaczniki w treści odpowiedzi, które były puste przez przeglądarkę, zawierały domyślną stronę do pomyślnego logowania. Ustaliłem, że obsługa błędów niestandardowych dla ASP.NET i HTTP dla błędu 401 uniemożliwia / zakłóca uwierzytelnianie systemu Windows na mojej stacji roboczej ale nie serwer pomostowy. Spędziłem kilka godzin, bawiąc się tym, ale gdy tylko usunąłem niestandardową obsługę tylko błędu 401, stacja robocza wróciła do normy. Przedstawiam to jako kolejny sposób na strzelenie sobie stopy.

Uwierzytelnianie systemu Windows w IIS7.0 lub IIS7.5 nie działa z kerberos (provider = Negotiate), gdy tożsamość puli aplikacji to ApplicationPoolIdentity Należy użyć usługi sieciowej lub innego wbudowanego konta. Inną możliwością jest użycie NTLM, aby uruchomić Windows Authenticatio (w Uwierzytelnianiu Windows, Dostawcy, umieść NTLM na wierzchu lub usuń negocjację)

chris van de vijver

Miałem ten sam problem, ponieważ użytkownik (tożsamość), którego użyłem w puli aplikacji, nie należał do grupy IIS_IUSRS. Dodano użytkownika do grupy i wszystko działa

W moim przypadku rozwiązaniem było (poza poprawkami sugerowanymi powyżej) ponowne uruchomienie lokalnego komputera programistycznego / IIS (serwer hostingowy) mojego / użytkowników. Mój użytkownik został właśnie dodany do nowo utworzonej grupy zabezpieczeń usługi AD - a zasady nie miały zastosowania do konta użytkownika usługi AD, dopóki nie wylogowałem się / ponownie uruchomiłem komputer.

Mam nadzieję, że to komuś pomoże.

Napotkałem ten sam problem z pytaniem o poświadczenia i przeprowadziłem szybkie wyszukiwanie i nic w Internecie go nie naprawiło. Znalezienie głupiego problemu zajęło trochę czasu.

W usługach IIS -> Ustawienia zaawansowane -> Poświadczenia ścieżki fizycznej (jest puste)

Jak tylko dodałem identyfikator komputera (domeny / użytkownika), który ma dostęp do maszyny wirtualnej / serwera, pytanie o hasło przestało być wyświetlane.

Mam nadzieję że to pomoże

Miałem ten problem na .net core 2 i po przejrzeniu większości sugestii stąd wydaje się, że przegapiliśmy ustawienie w web.config

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

Prawidłowe ustawienie to forwardWindowsAuthToken = "true", co wydaje się teraz oczywiste, ale gdy jest tak wiele sytuacji dotyczących tego samego problemu, trudniej jest określić

Edycja: pomocny okazał się również następujący artykuł Msdn, w którym opisano rozwiązanie problemu.

Mam ten sam problem i został on rozwiązany przez zmianę tożsamości puli aplikacji, w której działa aplikacja internetowa, na NetworkService