Wiem, że istnieją tysiące doniesień o problemach ze zintegrowanym uwierzytelnianiem systemu Windows do pracy z IIS, ale wszystkie wydają się prowadzić do stron internetowych, które nie mają zastosowania lub rozwiązań, które już wypróbowałem. Wcześniej wdrożyłem dziesiątki takich witryn, więc albo dzieje się coś dziwnego z serwerem / konfiguracją, albo patrzyłem na to zbyt długo i nie dostrzegałem oczywistości.
Krótko mówiąc, wszystko działa idealnie na moim komputerze lokalnym, ale rozpada się na serwerze produkcyjnym, który, o ile wiem, ma dokładnie taką samą konfigurację .
Na komputerze lokalnym:
- Na komputerze działa system Windows 7 Ultimate, Service Pack 1, IIS 7.5.
- Witryna została pomyślnie przetestowana przy użyciu zarówno IIS, jak i VS Web Development Server.
- Konfiguracja witryny IIS ma wyłączone wszystkie metody uwierzytelniania oprócz uwierzytelniania systemu Windows.
- Komputer lokalny nie znajduje się w żadnej domenie.
- Dostawcami są Negotiate i NTLM (nie Negotiate: Kerberos).
- Rozszerzona ochrona jest wyłączona.
- Wszystkie przetestowane przeglądarki (IE, Firefox, Chrome) wyświetlają monit z prośbą o wyzwanie i pozwalają mi zalogować się do domeny localhost przy użyciu mojego (lokalnego) konta Windows.
- Wszystkie testowane przeglądarki działają również przy użyciu nieprzezroczystego lokalnego adresu IP - więc same przeglądarki nie dbają o to, czy witryna jest wyświetlana jako „lokalna” czy „zdalna”.
- Dodałem wiersz wyświetlania do strony internetowej, który pokazuje aktualnie zalogowanego użytkownika i pokazuje dokładnie to, czego bym się spodziewał (niezależnie od tego, z którego lokalnego użytkownika się zalogowałem).
Na zdalnym komputerze:
- Na serwerze działa system Windows Server 2008 R2, IIS 7.5.
- Ładowanie strony internetowej powoduje natychmiastowy błąd 401,2: Nie masz uprawnień do przeglądania tej strony z powodu nieprawidłowych nagłówków uwierzytelnienia. Nigdy nie pojawia się monit o wyzwanie.
- Konfiguracja witryny IIS ma wyłączone wszystkie metody uwierzytelniania oprócz uwierzytelniania systemu Windows.
- Zdalny komputer nie znajduje się w żadnej domenie.
- Dostawcami są Negotiate i NTLM (nie Negotiate: Kerberos).
- Rozszerzona ochrona jest wyłączona.
- Na zdalnym komputerze (sesja pulpitu zdalnego) ten sam błąd pojawia się w Internet Explorerze niezależnie od tego, czy domena to host lokalny, czy zewnętrzny adres IP.
- Jeśli próbuję wyświetlić zdalną stronę internetową z mojego komputera lokalnego , błąd nadal wynosi 401, ale jest nieco inny 401. Brak subkodu z tekstem: Odmowa dostępu z powodu nieprawidłowych danych uwierzytelniających.
- Funkcja roli Windows Authentication IIS jest zainstalowana.
- WindowsAuthentication moduł jest dodany (na poziomie serwera).
- Dokładnie ten sam błąd występuje, jeśli wyłączę uwierzytelnianie systemu Windows i włączę podstawowe uwierzytelnianie.
- Witryna ma ładunek jeśli mogę wyłączyć uwierzytelnianie systemu Windows i umożliwiają anonimowy (oczywiście).
- Wykonałem już wszystkie kroki rozwiązywania problemów w pomocy technicznej Microsoft: Rozwiązywanie problemów z błędami HTTP 401 w IIS
- Próbowałem już obejścia pokazanego na innej stronie pomocy technicznej Microsoft (podobno wymuszanie NTLM jako jedynej metody).
I na koniec, próbowałem włączyć FREB dla błędów 401,2, a wyniki nie wydają mi się przydatne, widzę tylko następujące ostrzeżenie:
MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName IIS Web Core
Notification 2
HttpStatus 401
HttpReason Nieautoryzowany
HttpSubStatus 2
ErrorCode 2147942405
ConfigExceptionInfo
Notification AUTHENTICATE_REQUEST
ErrorCode Odmowa dostępu. (0x80070005)
... wydaje się, że to po prostu mówi mi to, co już wiem (że po prostu odrzuca prośbę zamiast negocjować poświadczenia).
Śledzenie wskazuje, że moduł WindowsAuthentication jest poprawnie załadowany, ponieważ istnieje NOTIFY_MODULE_STARTwiersz z ModuleName= WindowsAuthentication(i różne inne zdarzenia kontrolne ASP.NET - [na szczęście], nie ma tutaj żadnych interesujących błędów lub ostrzeżeń).
Czy ktoś może mi powiedzieć, czego tu brakuje?
Szybka aktualizacja:
Jestem trochę niewygodny, wysyłając cały zrzut Wireshark, ponieważ ujawniałby adresy IP, adresy URL i inne rzeczy, ale zrobiłem porównanie obok siebie odpowiedzi HTTP z localhost i zdalnego serwera w Fiddler, i wydaje się dość samo - jasne, na czym polega problem:
Lokalny Gospodarz:
HTTP / 1.1 401 Nieautoryzowane Kontrola pamięci podręcznej: prywatna Content-Type: text / html; charset = utf-8 Serwer: Microsoft-IIS / 7.5 Uwierzytelnianie WWW: Negocjuj Uwierzytelnianie WWW: NTLM X-Powered-By: ASP.NET Data: sob., 17 grudnia 2011 23:42:34 GMT Długość treści: 6399 Obsługa proxy: Uwierzytelnianie oparte na sesji
Zdalny:
HTTP / 1.1 401 Nieautoryzowane Content-Type: text / html Serwer: Microsoft-IIS / 7.5 X-Powered-By: ASP.NET Data: sob., 17 grudnia 2011 23:43:13 GMT Długość treści: 1293
Oprócz kilku pozornie nieistotnych różnic, takich jak kontrola pamięci podręcznej, główna różnica polega na tym, że zdalny serwer nie wysyła nagłówków uwierzytelniania WWW z powrotem do klienta.
Wydaje mi się, że zawęża to pytanie do następujących kwestii: Dlaczego usługi IIS nie wysyłają nagłówków uwierzytelniania WWW, gdy wydaje się, że uwierzytelnianie systemu Windows jest zainstalowane, załadowane i włączone wyłącznie?
źródło
Odpowiedzi:
Problem rozwiązany. W końcu zdecydowałem się porównać listę modułów obok siebie i tak naprawdę nie było jednego. Okazuje się, że istnieją dwa moduły uwierzytelniania systemu Windows:
Na serwerze
WindowsAuthenticationbył moduł zarządzany , ale nie natywnyWindowsAuthenticationModulepodświetlony powyżej. Nikt nie zgaduje, dlaczego został skonfigurowany w ten sposób, ale najwyraźniej, jeśli moduł macierzysty nie jest załadowany, moduł zarządzany ładuje się i po cichu zawiesza.Tak więc dla przyszłych czytelników, którzy napotkają ten problem, upewnij się, że masz załadowane oba moduły , ponieważ IIS nie ostrzeże Cię, jeśli jednego z nich brakuje.
źródło
Odkryliśmy, że niekoniecznie rozwiązało to problem dla programistów pracujących lokalnie w witrynach ASP.NET działających pod kontrolą uwierzytelniania systemu Windows. Znaleźliśmy hack rejestru, który wyłącza sprawdzanie sprzężenia zwrotnego; to naprawiło:
klucz rejestru - HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa
Utwórz DWORD o wartości 1 o nazwie „DisableLoopbackCheck”
Będziesz musiał ponownie uruchomić komputer, aby ustawienie zaczęło obowiązywać
źródło