Strony diagnostyczne dotyczące rozwiązywania problemów ze zintegrowanym uwierzytelnianiem systemu Windows

Rozwiązywanie problemów ze scenariuszami niepowodzenia zintegrowanego uwierzytelniania systemu Windows może być trudne, szczególnie w przypadku delegowania poświadczeń Protokołu Kerberos. Chociaż istnieje szczegółowa lista kontrolna dotycząca sposobu zapewniania prawidłowej konfiguracji usług Internet Information Services (IIS) do pracy z uwierzytelnianiem zintegrowanym z systemem Windows i opcjonalnie używania delegowania poświadczeń, w tym artykule opisano w szczególności następujące scenariusze:

• Możesz zalogować się do docelowej witryny internetowej z komputera klienckiego, ale nie masz pewności, czy używasz protokołu NTLM , czy Kerberos jako mechanizmu uwierzytelniania.
• Możesz zalogować się do docelowej witryny internetowej, ale zostanie wyświetlony monit o zalogowanie się dopiero po wprowadzeniu kombinacji nazwy użytkownika i hasła.
• Dostęp do docelowej witryny internetowej można uzyskać na serwerze frontonu, ale kończy się niepowodzeniem po zainicjowaniu akcji wymagającej od serwera frontonu wywołania punktu końcowego HTTP zaplecza przy użyciu poświadczeń uwierzytelnionego użytkownika.

Na potrzeby tego artykułu należy wziąć pod uwagę następujący układ:

• Klient 1 to stacja robocza lub laptop przyłączony do domeny, z której hipotetyczny użytkownik zainicjuje wszystkie próby połączenia.

• Web-serv1 to serwer usług IIS frontonu hostujący witrynę internetową ASP.NET (na platformie .NET Framework), która używa zintegrowanego uwierzytelniania systemu Windows i działa przy użyciu tożsamości konta usługi: domain\serviceaccount.

• Web-serv2 to serwer internetowy zaplecza, który hostuje również witrynę ASP.NET (w programie .NET Framework), która uwidacznia punkty końcowe interfejsu API dla aplikacji frontonu. Jest ona również skonfigurowana do zezwalania na żądania używające zintegrowanego uwierzytelniania systemu Windows i wykonywania w puli aplikacji, która używa domeny\serviceapiaccount jako tożsamości puli aplikacji.

Aby ułatwić zbieranie danych w tych scenariuszach i nie polegać na zewnętrznych narzędziach do zbierania danych, takich jak Fiddler lub WireShark (ponieważ połączenia między trzema komputerami mogą używać protokołu HTTPS i dlatego wszystkie wymiany między nimi będą szyfrowane), użyj dwóch samodzielnie zawartych stron diagnostycznych w ASP.NET strony samodzielne do rozwiązywania problemów ze zintegrowanym uwierzytelnianiem systemu Windows w usługach IIS.

Strony rozwiązywania problemów

Dwie strony są kodowane w ASP.NET Web Forms. Są one przeznaczone do tworzenia pakietów kodu i znaczników dla strony w jednym pliku, który można skopiować do katalogu głównego aplikacji internetowej, którą próbujesz rozwiązać, bez konieczności kompilowania lub wdrażania. Strony to:

• WhoAmI.aspx — ta strona umożliwia zrzucenie informacji związanych z uwierzytelnianiem, takich jak:

  • Metoda uwierzytelniania używana do uzyskiwania dostępu do witryny docelowej. Jeśli metoda jest oparta na dostawcy Negotiate dla zintegrowanego uwierzytelniania systemu Windows, strona pokazuje, czy protokół Kerberos lub NTLM jest używany do uwierzytelniania użytkownika.

  • Tożsamość konta, na których działa pula aplikacji hostująca witrynę.

  • Poziom personifikacji dla uwierzytelnioowanego użytkownika. Jeśli protokół Kerberos jest używany do uwierzytelniania i delegowanie poświadczeń bez ograniczeń jest dozwolone, poziom personifikacji jest oznaczony jako delegat. Jeśli nie, zostanie ona oznaczona jako personifikowana w przypadku ograniczonego delegowania lub prostego personifikacji.

  • Tożsamość uwierzytelnionego użytkownika i grupy, do których należy użytkownik.

  • Tożsamość konta wykonującego kod strony (może to być uwierzytelniony użytkownik lub użytkownik puli aplikacji, w zależności od ustawień personifikacji ).

  • Wszystkie wartości nagłówków żądań dla żądań, które wchodzą na stronę WhoAmI.aspx w miarę odzyskiwania ze zmiennych serwera usług IIS.

    

• ScrapperTest.aspx — ta strona jest wysyłana do pracy ze stroną WhoAmI.aspx, umożliwiając kierowanie żądań z serwera frontonu do dowolnych adresów URL na serwerze zaplecza. Strona przedstawia interfejs użytkownika, który umożliwia użytkownikowi:

  • Wprowadź żądany adres URL zasobu serwera zaplecza, który strona powinna podjąć próbę załadowania.

  • Ustal, czy są one uwierzytelniane podczas ładowania strony ScrapperTest.aspx i czy są uwierzytelnione, których użytkowników są uwierzytelniani jako.

  • W scenariuszu, w którym użytkownik jest rzeczywiście uwierzytelniony, pole wyboru umożliwia próbę ponownego użycia poświadczeń użytkownika podczas próby załadowania zasobu zaplecza wskazanego w polu tekstowym ADRES URL.

    

Jak wdrożyć

Ponieważ obie strony są samodzielne, jedyną rzeczą wymaganą jest:

1. Pobierz strony z repozytorium GitHub.
2. Skopiuj stronę WhoAmI.aspx lub obie strony do katalogu głównego docelowych aplikacji internetowych działających wewnątrz usług IIS.
3. Prześlij żądanie do adresu URL witryny dołączającej /WhoAmI.aspx lub /ScrapperTest.aspx, w zależności od strony, do której chcesz uzyskać dostęp.

Użycie

Pierwszy scenariusz użycia próbuje określić, jaka metoda uwierzytelniania jest używana do uzyskiwania dostępu do danej witryny internetowej lub aplikacji internetowej hostowanej w usługach IIS. W tym przypadku możesz wysyłać żądania do strony WhoAmI.aspx , która została wcześniej wdrożona w witrynie.

• Na pierwszym żądaniu na stronie zostaną wyświetlone informacje dotyczące uwierzytelniania. Jeśli jest używany dostawca negocjowania dla zintegrowanego uwierzytelniania systemu Windows, zostanie również wyświetlony protokół uwierzytelniania, który jest używany: Kerberos lub NTLM.

• Kolejne żądania w scenariuszu, w którym negocjacja jest używana jako dostawca zintegrowanego uwierzytelniania systemu Windows, wyświetla tylko etykietę Oparta na sesji obok typu uwierzytelniania. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie Kerberos oparte na żądaniach i oparte na sesji (lub parametr AuthPersistNonNTLM).

• Wszystkie inne informacje o uwierzytelnianiu, takie jak użytkownik puli aplikacji, uwierzytelniony użytkownik, szczegóły wykonania użytkownika i nagłówki żądania przychodzącego, będą wyświetlane w każdym żądaniu.

Strona WhoAmI.aspx wyświetla również mały formularz u dołu. Ten formularz umożliwia wysyłanie POST żądań do serwera w celu przetestowania zachowania przeglądarki podczas wydawania tego typu żądań. Jeśli strona jest bezczynna przez ponad 60 sekund, połączenie protokołu TCP (Transmission Control Protocol) używane do pobierania strony do przeglądarki i uwierzytelnione przez serwer zostanie zerwane z powodu braku aktywności. W związku z tym po wysłaniu POST żądania zostanie otwarte nowe połączenie TCP i musisz ponownie uwierzytelnić się. Istnieje subtelność żądań POST :

1. Przeglądarka najpierw wysyła nagłówki żądania HTTP POST .
2. Następnie wystawia treść POST żądania, która zawiera informacje przechwycone z różnych pól wejściowych w formularzu HTTP wyświetlanym na stronie.

Jeśli przeglądarka nie czeka po wysłaniu POST nagłówków żądania, ale zamiast tego wysyła treść bezpośrednio w nieuwierzytelnionym połączeniu, mogą wystąpić następujące problemy:

• Serwer odbiera POST nagłówki żądań, a ponieważ połączenie nie jest uwierzytelnione (przy założeniu, że jest używane zintegrowane uwierzytelnianie systemu Windows lub inne uwierzytelnianie oparte na wyzwaniach), wystawia odpowiedź 401 z odpowiednim nagłówkiem HTTP odpowiedzi uwierzytelniania (WWW-Authenticate).
• W tym czasie przeglądarka wysłała POST już treść żądania przed otrzymaniem odpowiedzi 401 z serwera.
• Następnie serwer odbiera nieuwierzytelnione POST żądanie w połączeniu, które wcześniej wskazywało klientowi, że wymagane jest uwierzytelnianie.
• Powoduje to zerwanie bazowego połączenia TCP przez serwer, a przeglądarka potencjalnie wyświetla komunikat "Strona internetowa jest niedostępna".

Strona ScrapperTest.aspx służy do testowania delegowania scenariuszy poświadczeń z serwera frontonu do punktu końcowego serwera zaplecza. Po zażądaniu strony w przeglądarce klienta zostanie wyświetlony interfejs użytkownika, który umożliwia:

• Wprowadź adres URL punktu końcowego zaplecza, z którym serwer frontonu powinien nawiązać połączenie.
• Sprawdzanie, czy użytkownik jest uwierzytelniany na frontonie i jaka nazwa użytkownika jest używana do nawiązywania połączenia z serwerem frontonu.
• Podjęcie decyzji (jeśli uwierzytelnianie jest używane do uzyskiwania dostępu do strony ScrapperTest.aspx ), jeśli poświadczenia uwierzytelnionego użytkownika powinny zostać przekazane z żądaniem do serwera zaplecza (jeśli jest możliwe personifikacja i delegowanie).

Po wybraniu przycisku Strona złomowania kod strony ScrapperTest.aspx będzie wysyłać GET żądanie dotyczące wskazanego docelowego adresu URL. Jeśli pole wyboru Użyj poświadczeń jest zaznaczone, a uwierzytelnianie jest wymagane do uzyskania dostępu do określonego punktu końcowego zaplecza, uwierzytelnione poświadczenia użytkownika są również używane do tworzenia żądania. Jeśli żądanie zakończy się pomyślnie, wynik zostanie wyświetlony w kontrolce obszaru tekstowego strony jako nieprzetworzone dane wyjściowe HTTP odebranej odpowiedzi.

Scenariusz użycia, który przewidujemy, to umieszczenie strony ScrapperTest.aspx i strony WhoAmI.aspx wewnątrz aplikacji ASP.NET, która zostanie skontaktowana na serwerze zaplecza. W związku z tym odpowiedź HTTP odzyskana przez stronę ScrapperTest.aspx będzie danymi wyjściowymi HTML strony WhoAmI.aspx po wykonaniu na zapleczu. Te dane wyjściowe można następnie ocenić, aby zrozumieć, w jaki sposób żądanie zostało uwierzytelnione na zapleczu i które konta zostały użyte.

Więcej informacji

Aby lepiej zrozumieć konfigurację zintegrowanego uwierzytelniania systemu Windows przy użyciu protokołu Kerberos, zobacz:

• Rozwiązywanie problemów z błędami protokołu Kerberos w programie Internet Explorer
• Uwierzytelnianie bez ograniczeń protokołu Kerberos przy użyciu przeglądarki Microsoft Edge (Chromium)
• Uwierzytelnianie Kerberos oparte na żądaniach a oparte na sesji (lub parametr AuthPersistNonNTLM)