Rozwiązywanie problemów z uwierzytelnianiem systemu Windows (bez problemu) w IIS 7.5?


21

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?


Nie masz nic przeciwko uchwyceniu zwykłego tekstu Wireshark próby uwierzytelnienia (zmień swoje hasło na coś, co najpierw jest wyrzucane - nie chcemy, aby twoje prawdziwe hasła były haszowane w sieci)? Około 18 miesięcy wstecz łatka systemu Windows wprowadziła pewne zmiany w negocjacjach HTTP NTLM (nawiasem mówiąc, czy systemy są załatane aż do góry?), Które wysadziły aplikację dostawcy i dały mi znacznie więcej doświadczenia, niż chciałbym przyznać analizując rozmowy negocjacyjne.
Shane Madden

@ShaneMadden: Trochę mi to przeszkadza z powodu różnych informacji, które chciałbym ujawnić, ale mogę zrobić sesję Fiddlera, która powinna być prawie taka sama, a następnie mogę przynajmniej anonimizować adresy IP i tak dalej - i w rzeczywistości już to zrobiłem, wyniki powinny być dość oczywiste (klient nie wyświetla monitu o poświadczenia, ponieważ serwer nie prosi o żadne).
Aaronaught,


@Aaronaught W jaki sposób uzyskałeś inną nazwę użytkownika tutaj niż w Cooking? Kiedy po raz pierwszy zobaczyłem to pytanie, pomyślałem, że to ktoś cię fałszuje.
Totem - Przywróć Monikę

@Ward: Każdy może edytować swoją nazwę użytkownika, jest to część profilu. To był mój oryginalny, używaj innych tylko na stronach nietechnicznych.
Aaronaught,

Odpowiedzi:


14

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:

Lista modułów

Na serwerze WindowsAuthenticationbył moduł zarządzany , ale nie natywny WindowsAuthenticationModulepodś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.


Zarządzany moduł uwierzytelniania systemu Windows nie wygląda tak. Obsługuje on tożsamości Windows w ASP.Net i jest zawsze instalowany (gdy ASP.Net jest zainstalowany). Ale natywny moduł uwierzytelniania systemu Windows jest instalowany po zaznaczeniu komponentu uwierzytelniania systemu Windows w Menedżerze serwera, i to jest potrzebne, aby ta opcja uwierzytelniania była widoczna w interfejsie GUI uwierzytelniania.
TristanK,

@TristanK: W tym przypadku ten komponent został zaznaczony, ale moduł nie został zainstalowany. (Ta opcja była jednak widoczna w GUI Uwierzytelniania - więc jestem pewien, że ekran zależy od modułu zarządzanego, a nie natywnego.)
Aaronaught,

Myślę, że tak się stało z powodu pewnych modyfikacji plików konfiguracyjnych (prawdopodobnie ApplicationHost.config). Ale myślę, że nie ma znaczenia, jak to wszystko się skończyło; to zrobiło.
Aaronaught,

Jasne. Autoryzacja Windows nie działa, chyba że coś się zepsuje; w tym przypadku, chociaż pytanie stwierdza, że ​​konfiguracja jest identyczna, okazuje się to nieprawdą; więc to nie działało tak samo. CO BYŁO DO OKAZANIA.
TristanK,

1
Ten brakujący moduł właśnie mnie ugryzł w systemie Windows Server 2012 R2. To niewiarygodne, że nie ma wskazania, kiedy ten stan wystąpi. W każdym razie bardzo dziękuję za tę odpowiedź; Dosłownie odrywałem włosy!
Rob Davis,

4

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ć


Zauważyłem, że mogę przełączać między DisableLoopbackCheck jako 1 i 0, a zmiana zacznie obowiązywać natychmiast. Ponadto w dzienniku zdarzeń można zobaczyć identyfikator zdarzenia 4625 z komunikatem „Logowanie do konta nie powiodło się”.
alastairtree

Dziękuję Ci! 2 dni grzebania przy uwierzytelnianiu IIS i wersjach .Net tylko po to, by to znaleźć, ponieważ użyłem mojego pliku hosts do stworzenia fałszywego wpisu DNS podczas testowania migracji witryny.
JohnLBevan,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.