Rozwiązywanie problemów z konfiguracjami delegowania ograniczonego protokołu Kerberos (KCD) przy użyciu serwera proxy aplikacji Firmy Microsoft Entra

Metody logowania jednokrotnego różnią się od jednej aplikacji do innej. Serwer proxy aplikacji Entra firmy Microsoft domyślnie udostępnia ograniczone delegowanie protokołu Kerberos (KCD). Użytkownicy uwierzytelniają się w aplikacjach prywatnych przy użyciu protokołu Kerberos.

Ten artykuł zawiera pojedynczy punkt odniesienia do rozwiązywania najczęstszych problemów. Opisano w nim także diagnostykę bardziej złożonych problemów z implementacją.

W tym artykule przyjęto następujące założenia.

• Wdrożenie serwera proxy aplikacji Firmy Microsoft Entra i ogólny dostęp do aplikacji innych niż KCD. Aby uzyskać więcej informacji, zobacz Wprowadzenie do serwera proxy aplikacji.
• Opublikowana aplikacja jest oparta na usługach Internet Information Services (IIS) i implementacji protokołu Kerberos przez firmę Microsoft.
• Hosty serwerów i aplikacji znajdują się w jednej domenie firmy Microsoft Entra. Aby uzyskać więcej informacji na temat scenariuszy między domenami i lasami, zobacz oficjalny dokument KCD.
• Aplikacja jest publikowana w dzierżawie identyfikatora Entra firmy Microsoft z włączonym uwierzytelnianiem wstępnym. Oczekuje się, że użytkownicy będą uwierzytelniać się przy użyciu uwierzytelniania opartego na formularzach. Rozbudowane scenariusze uwierzytelniania klienta nie są omówione w tym artykule.

Wymagania wstępne

Proste błędy konfiguracji lub ogólne błędy powodują większość problemów. Przed rozwiązaniem problemów sprawdź wszystkie wymagania wstępne w temacie Using KCD single sign-on with the application proxy (Korzystanie z logowania jednokrotnego KCD z serwerem proxy aplikacji).

hosty Połączenie or nie są ograniczone do komunikacji tylko z określonym kontrolerem domeny lokacji lokalnej (DC). Sprawdź używany kontroler domeny, ponieważ może ulec zmianie.

Scenariusze obejmujące wiele domen opierają się na odwołaniach, które kierują hosta łącznika do kontrolerów domeny, które mogą znajdować się poza obwodem sieci lokalnej. W takich przypadkach równie ważne jest również wysyłanie ruchu do kontrolerów domeny reprezentujących inne odpowiednie domeny. Jeśli nie, delegowanie zakończy się niepowodzeniem.

Unikaj aktywnego systemu zapobiegania włamaniom (IPS) lub urządzeń systemu wykrywania włamań (IDS) między hostami łącznika i kontrolerami domeny. Te urządzenia są zbyt uciążliwe i zakłócają ruch zdalnego wywołania procedury (RPC).

Testowanie delegowania w prostych scenariuszach. Tym więcej zmiennych wprowadzasz, tym więcej może być konieczne. Aby zaoszczędzić czas, ogranicz testowanie do jednego łącznika. Dodaj więcej łączników po rozwiązaniu problemu.

Niektóre czynniki środowiskowe mogą również przyczynić się do problemu. Aby uniknąć tych czynników, zminimalizuj architekturę jak najwięcej podczas testowania. Na przykład błędnie skonfigurowane wewnętrzne listy kontroli dostępu zapory (ACL) są typowe. Jeśli to możliwe, wyślij cały ruch z łącznika bezpośrednio do kontrolerów domeny i aplikacji zaplecza.

Najlepsze miejsce do pozycjonowania łączników jest jak najbardziej zbliżone do ich celów. Zapora, która znajduje się w tekście podczas testowania, dodaje niepotrzebną złożoność i może przedłużyć badania.

Co pokazuje problem Z KCD? Istnieje kilka typowych wskazówek, że logowanie jednokrotne KCD kończy się niepowodzeniem. Pierwsze oznaki problemu są wyświetlane w przeglądarce.

Oba obrazy pokazują ten sam objaw: niepowodzenie logowania jednokrotnego. Odmowa dostępu użytkownika do aplikacji.

Rozwiązywanie problemów

Rozdziel rozwiązywanie problemów na trzy etapy.

Uwierzytelnianie wstępne klienta

Użytkownik zewnętrzny uwierzytelniający się za pośrednictwem przeglądarki. Możliwość wstępnego uwierzytelniania w usłudze Microsoft Entra ID jest niezbędna, aby logowanie jednokrotne KCD działało. Przetestuj tę możliwość i rozwiąż ten problem, jeśli występują jakieś problemy. Etap uwierzytelniania wstępnego nie jest związany z KCD ani opublikowaną aplikacją. Łatwo jest skorygować wszelkie rozbieżności, sprawdzając, czy konto podmiotu istnieje w identyfikatorze Microsoft Entra. Sprawdź, czy aplikacja nie jest wyłączona lub zablokowana. Odpowiedź o błędzie w przeglądarce jest wystarczająco opisowa, aby wyjaśnić przyczynę.

Usługa delegowania

Łącznik sieci prywatnej, który pobiera bilet usługi Kerberos dla użytkowników z centrum dystrybucji kluczy Protokołu Kerberos (KCD).

Komunikacja zewnętrzna między klientem a frontonem platformy Azure nie ma wpływu na KCD. Te komunikaty zapewniają tylko działanie KCD. Usługa serwera proxy aplikacji jest dostarczana prawidłowy identyfikator użytkownika używany do uzyskiwania biletu protokołu Kerberos. Bez tego identyfikatora KCD nie jest możliwe i kończy się niepowodzeniem.

Komunikaty o błędach przeglądarki zawierają kilka dobrych wskazówek dotyczących przyczyn awarii. activity ID Zapisz pola i timestamp w odpowiedzi. Informacje pomagają skorelować zachowanie z rzeczywistymi zdarzeniami w dzienniku zdarzeń serwera proxy aplikacji.

Odpowiednie wpisy widoczne w dzienniku zdarzeń są wyświetlane jako zdarzenia 13019 lub 12027. Znajdź dzienniki zdarzeń łącznika w obszarze Dzienniki>>aplikacji i usług Microsoft Entra private network> Połączenie or> Administracja.

1. Użyj rekordu A w wewnętrznym systemie nazw domen (DNS) dla adresu aplikacji, a nie CName.
2. Potwierdź ponownie, że host łącznika ma prawo delegować do wyznaczonej głównej nazwy usługi konta docelowego (SPN). Ponownie potwierdź, że wybrano opcję Użyj dowolnego protokołu uwierzytelniania. Aby uzyskać więcej informacji, zobacz artykuł SSO configuration (Konfiguracja logowania jednokrotnego).
3. Sprawdź, czy istnieje tylko jedno wystąpienie głównej nazwy usługi w identyfikatorze Entra firmy Microsoft. Problem setspn -x z wiersza polecenia na dowolnym hoście elementu członkowskiego domeny.
4. Sprawdź, czy zasady domeny są wymuszane, aby ograniczyć maksymalny rozmiar wystawionych tokenów Protokołu Kerberos. Zasady uniemożliwiają łącznikowi uzyskanie tokenu, jeśli jest on nadmierny.

Ślad sieciowy, który przechwytuje wymiany między hostem łącznika a domeną Delegowanie ograniczone protokołu Kerberos (KDC) jest następnym najlepszym krokiem, aby uzyskać bardziej szczegółowe informacje na temat problemów. Aby uzyskać więcej informacji, zobacz artykuł Dotyczący szczegółowego rozwiązywania problemów.

Jeśli bilet wygląda dobrze, w dziennikach zostanie wyświetlone zdarzenie z informacją, że uwierzytelnianie nie powiodło się, ponieważ aplikacja zwróciła błąd 401. To zdarzenie wskazuje, że aplikacja docelowa odrzuciła bilet. Przejdź do następnego etapu.

Aplikacja docelowa

Użytkownik biletu protokołu Kerberos udostępniony przez łącznik. Na tym etapie spodziewaj się, że łącznik wysłał bilet usługi Kerberos do zaplecza. Bilet jest nagłówkiem pierwszego żądania aplikacji.

1. Korzystając z wewnętrznego adresu URL aplikacji zdefiniowanego w portalu, sprawdź, czy aplikacja jest dostępna bezpośrednio z przeglądarki na hoście łącznika. Następnie możesz się zalogować pomyślnie. Szczegóły można znaleźć na stronie Rozwiązywanie problemów z łącznikiem.

2. Upewnij się, że uwierzytelnianie między przeglądarką a aplikacją używa protokołu Kerberos.

3. Uruchom narzędzie DevTools (F12) w programie Internet Explorer lub użyj programu Fiddler na hoście łącznika. Przejdź do aplikacji przy użyciu wewnętrznego adresu URL. Aby upewnić się, że istnieją negocjacja lub kerberos, sprawdź oferowane nagłówki autoryzacji internetowej zwrócone w odpowiedzi z aplikacji.

   • Następny obiekt blob Kerberos zwrócony w odpowiedzi z przeglądarki do aplikacji rozpoczyna się od YII. Te litery informują o tym, że protokół Kerberos jest uruchomiony. Z drugiej strony program Microsoft NT LAN Manager (NTLM) zawsze rozpoczyna się od tlRMTVNTUAAB, który odczytuje dostawcę obsługi zabezpieczeń NTLM (NTLMSSP) podczas dekodowania z bazy Base64. Jeśli na początku obiektu blob zobaczysz wartość TlRMTVNTUAAB , protokół Kerberos nie jest dostępny. Jeśli nie widzisz protokołu TlRMTVNTUAAB, protokół Kerberos jest prawdopodobnie dostępny.

     Uwaga

     Jeśli używasz programu Fiddler, ta metoda wymaga tymczasowego wyłączenia rozszerzonej ochrony w konfiguracji aplikacji w usługach IIS.

     

   • Obiekt blob na tej ilustracji nie zaczyna się od TIRMTVNTUAAB. W tym przykładzie protokół Kerberos jest dostępny, a obiekt blob Kerberos nie zaczyna się od yiI.

4. Tymczasowo usuń protokół NTLM z listy dostawców w witrynie usług IIS. Uzyskaj dostęp do aplikacji bezpośrednio z programu Internet Explorer na hoście łącznika. Protokół NTLM nie znajduje się już na liście dostawców. Dostęp do aplikacji można uzyskać tylko przy użyciu protokołu Kerberos. Jeśli dostęp nie powiedzie się, może wystąpić problem z konfiguracją aplikacji. Uwierzytelnianie Kerberos nie działa.

   • Jeśli protokół Kerberos nie jest dostępny, sprawdź ustawienia uwierzytelniania aplikacji w usługach IIS. Upewnij się, że element Negotiate znajduje się na liście u góry, a protokół NTLM znajduje się tuż pod nim. Jeśli widzisz wartość Not Negotiate, Kerberos lub Negotiate lub PKU2U, kontynuuj tylko wtedy, gdy protokół Kerberos jest funkcjonalny.

     

   • W przypadku stosowania protokołu Kerberos i NTLM tymczasowo wyłącz wstępne uwierzytelnianie aplikacji w portalu. Spróbuj uzyskać dostęp do niego z Internetu przy użyciu zewnętrznego adresu URL. Zostanie wyświetlony monit o uwierzytelnienie. Możesz to zrobić przy użyciu tego samego konta użytego w poprzednim kroku. Jeśli nie, występuje problem z aplikacją zaplecza, a nie z KCD.

   • Ponownie włącz wstępne uwierzytelnianie w portalu. Uwierzytelnianie za pośrednictwem platformy Azure przez próbę nawiązania połączenia z aplikacją za pośrednictwem zewnętrznego adresu URL. Jeśli logowanie jednokrotne nie powiedzie się, w dzienniku zostanie wyświetlony komunikat o błędzie Zabronione i zdarzenie 13022:

     Łącznik sieci prywatnej firmy Microsoft Entra nie może uwierzytelnić użytkownika, ponieważ serwer zaplecza reaguje na próby uwierzytelniania Kerberos z powodu błędu HTTP 401.

     

   • Sprawdź aplikację usług IIS. Upewnij się, że skonfigurowano skonfigurowaną pulę aplikacji i nazwę SPN do używania tego samego konta w identyfikatorze Microsoft Entra ID. Nawiguj w usługach IIS, jak pokazano na poniższej ilustracji.

     

     Po zapoznaniu się z tożsamością upewnij się, że to konto jest skonfigurowane przy użyciu danej nazwy SPN. Może to być na przykład setspn –q http/spn.wacketywack.com. Wprowadź następujący tekst w wierszu polecenia.

     

   • Sprawdź nazwę SPN zdefiniowaną względem ustawień aplikacji w portalu. Upewnij się, że ta sama nazwa SPN skonfigurowana względem docelowego konta Microsoft Entra jest używana przez pulę aplikacji.

   • Przejdź do usług IIS i wybierz opcję Edytor konfiguracji dla aplikacji. Przejdź do pliku system.webServer/security/authentication/windowsAuthentication. Upewnij się, że wartość UseAppPoolCredentials ma wartość True.

     

     Zmień wartość na True. Usuń wszystkie buforowane bilety Kerberos z serwera zaplecza, uruchamiając polecenie .

     Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
     

Jeśli tryb jądra zostanie włączony, poprawi wydajność operacji Kerberos. Powoduje to jednak również odszyfrowywanie biletu żądanej usługi przy użyciu konta komputera. To konto jest również nazywane systemem lokalnym. Ustaw tę wartość na True , aby przerwać KCD, gdy aplikacja jest hostowana na więcej niż jednym serwerze w farmie.

• W ramach innego sprawdzania wyłącz też ochronę rozszerzoną . W niektórych scenariuszach rozszerzona ochrona złamała KCD, gdy została włączona w określonych konfiguracjach. W takich przypadkach aplikacja została opublikowana jako podfolder domyślnej witryny internetowej. Ta aplikacja jest skonfigurowana tylko do uwierzytelniania anonimowego. Wszystkie okna dialogowe są wyszarywane, co sugeruje, że obiekty podrzędne nie dziedziczą żadnych aktywnych ustawień. Zalecamy przetestowanie tej wartości, ale nie zapomnij przywrócić tej wartości do włączenia, jeśli to możliwe.

  Ta dodatkowa kontrola umożliwia śledzenie korzystania z opublikowanej aplikacji. Możesz uruchomić więcej łączników, które są również skonfigurowane do delegowania. Aby uzyskać więcej informacji, przeczytaj bardziej szczegółowy przewodnik techniczny rozwiązywania problemów z serwerem proxy aplikacji Firmy Microsoft Entra.

Jeśli nadal nie możesz poczynić postępów, pomoc techniczna firmy Microsoft może Ci pomóc. Utwórz bilet pomocy technicznej bezpośrednio w portalu.

Inne scenariusze

Serwer proxy aplikacji Microsoft Entra żąda biletu protokołu Kerberos przed wysłaniem żądania do aplikacji. Niektóre aplikacje nie lubią tej metody uwierzytelniania. Wnioski te oczekują, że odbędą się bardziej konwencjonalne negocjacje. Pierwsze żądanie jest anonimowe, co umożliwia aplikacji odpowiadanie za pomocą typów uwierzytelniania, które obsługuje za pośrednictwem 401. Ten typ negocjacji protokołu Kerberos można włączyć, wykonując kroki opisane w tym dokumencie: Ograniczone delegowanie protokołu Kerberos na potrzeby logowania jednokrotnego.

Uwierzytelnianie wieloskoku jest często używane w scenariuszach, w których aplikacja jest warstwowa. Warstwy obejmują zaplecze i fronton. Obie warstwy wymagają uwierzytelniania. Na przykład usługi SQL Server Reporting Services. Aby uzyskać więcej informacji, zobacz How to configure Kerberos Constrained Delegation for Web Enrollment proxy pages (Jak skonfigurować ograniczone delegowanie protokołu Kerberos dla stron serwera proxy rejestracji internetowej).

Następne kroki

Konfigurowanie KCD w domenie zarządzanej.