Rozwiązywanie problemów z błędami protokołu Kerberos w programie Internet Explorer

Ten artykuł ułatwia izolowanie i naprawianie przyczyn różnych błędów podczas uzyskiwania dostępu do witryn internetowych skonfigurowanych do korzystania z uwierzytelniania Kerberos w programie Internet Explorer. Liczba potencjalnych problemów jest prawie tak duża, jak liczba dostępnych narzędzi do ich rozwiązania.

Typowy objaw, gdy kerberos kończy się niepowodzeniem

Próbujesz uzyskać dostęp do witryny internetowej, w której skonfigurowano zintegrowane uwierzytelnienie systemu Windows i oczekujesz, że używasz protokołu uwierzytelniania Kerberos. W takiej sytuacji przeglądarka natychmiast wyświetli monit o podanie poświadczeń w następujący sposób:

Mimo że wprowadzasz prawidłową nazwę użytkownika i hasło, zostanie wyświetlony monit ponownie (łącznie trzy monity). Następnie zostanie wyświetlony ekran wskazujący, że nie możesz uzyskać dostępu do żądanego zasobu. Na ekranie zostanie wyświetlony kod stanu HTTP 401 podobny do następującego błędu:

Brak autoryzacji
Błąd HTTP 401. Żądany zasób wymaga uwierzytelnienia użytkownika.

Na serwerze usług Microsoft Internet Information Services (IIS) dzienniki witryny sieci Web zawierają żądania kończące się kodem stanu 401.2, takim jak następujący dziennik:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

Na ekranie jest wyświetlany kod stanu 401.1, taki jak następujący dziennik:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

Określanie, czy jest używany protokół Kerberos

Podczas rozwiązywania problemów z błędem uwierzytelniania Kerberos zalecamy uproszczenie konfiguracji do minimum. Oznacza to, że jeden klient, jeden serwer i jedna lokacja usług IIS uruchomiona na domyślnym porcie. Ponadto możesz wykonać kilka podstawowych kroków rozwiązywania problemów. Na przykład użyj strony testowej, aby zweryfikować użytą metodę uwierzytelniania. Jeśli używasz ASP.NET, możesz utworzyć tę stronę testu uwierzytelniania ASP.NET.

Jeśli używasz klasycznej platformy ASP, możesz użyć następującej strony Testkerb.asp:

<%
    authType=UCase(Request.ServerVariables("AUTH_TYPE"))
    authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
    response.write " Authentication Method : " & authType & "<BR>"
    LenAuthHeader = len(authHeader)
    response.write " Protocol : "
    if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write  "NTLM"
%>

Możesz również użyć następujących narzędzi, aby określić, czy jest używany protokół Kerberos:

• Fiddler
• HttpWatch
• Microsoft Network Monitor
• Narzędzia deweloperskie w przeglądarce

Aby uzyskać więcej informacji na temat sposobu generowania takich śladów, zobacz śledzenie po stronie klienta.

W przypadku użycia protokołu Kerberos żądanie wysyłane przez klienta jest duże (ponad 2000 bajtów), ponieważ HTTP_AUTHORIZATION nagłówek zawiera bilet Protokołu Kerberos. Poniższe żądanie dotyczy strony korzystającej z uwierzytelniania systemu Windows opartego na protokole Kerberos w celu uwierzytelniania przychodzących użytkowników. Rozmiar żądania GET wynosi ponad 4000 bajtów.

Jeśli jest używany uzgadnianie NTLM, żądanie będzie znacznie mniejsze. Następujące przechwytywanie po stronie klienta pokazuje żądanie uwierzytelniania NTLM. Żądanie GET jest znacznie mniejsze (mniej niż 1400 bajtów).

Po ustaleniu, że uwierzytelnianie Kerberos kończy się niepowodzeniem, sprawdź każdy z następujących elementów w podanej kolejności.

Kwestie do sprawdzenia, czy uwierzytelnianie Kerberos kończy się niepowodzeniem

W poniższych sekcjach opisano elementy, których można użyć do sprawdzenia, czy uwierzytelnianie Kerberos kończy się niepowodzeniem.

Czy klient i serwer znajdują się w tej samej domenie

Korzystanie z protokołu Kerberos wymaga domeny, ponieważ bilet Protokołu Kerberos jest dostarczany przez kontroler domeny (DC). Scenariusze zaawansowane są również możliwe w następujących przypadkach:

• Klient i serwer nie należą do tej samej domeny, ale w dwóch domenach tego samego lasu.
• Klient i serwer znajdują się w dwóch różnych lasach.

Te możliwe scenariusze zostały omówione w artykule Dlaczego delegowanie protokołu Kerberos kończy się niepowodzeniem między dwoma lasami, chociaż użyto go do pracy w tej sekcji artykułu.

Czy usługi IIS są skonfigurowane do używania zintegrowanego uwierzytelniania

Jest włączone zintegrowane uwierzytelnianie w programie Internet Explorer

Czy adres URL, który jest używany do rozpoznawania strefy zabezpieczeń, dla której można wysłać poświadczenia

Zawsze uruchamiaj to sprawdzanie pod kątem następujących witryn:

• Witryny dopasowane do strefy Lokalny intranet przeglądarki.
• Witryny w strefie Zaufane witryny.

Możesz sprawdzić, w której strefie przeglądarka zdecyduje się uwzględnić witrynę. W tym celu otwórz menu Plik programu Internet Explorer, a następnie wybierz pozycję Właściwości. W oknie Właściwości zostanie wyświetlona strefa, w której przeglądarka zdecydowała się uwzględnić przeglądaną witrynę.

Możesz sprawdzić, czy strefa, w której znajduje się witryna, zezwala na automatyczne logowanie. W tym celu otwórz menu Opcje internetowe programu Internet Explorer i wybierz kartę Zabezpieczenia . Po wybraniu żądanej strefy wybierz przycisk Poziom niestandardowy, aby wyświetlić ustawienia i upewnij się, że wybrano opcję Automatyczne logowanie . (Zazwyczaj ta funkcja jest domyślnie włączona dla stref intranet i witryn zaufanych).

Czy serwer usług IIS jest skonfigurowany do wysyłania nagłówka WWW-Authentication: Negotiate

Jeśli usługi IIS nie wysyłają tego nagłówka, użyj konsoli Menedżera usług IIS, aby ustawić nagłówek Negotiate za pomocą właściwości konfiguracji NTAuthenticationProviders . Aby uzyskać więcej informacji, zobacz Dostawcy <>uwierzytelniania systemu Windows. Dostęp do konsoli można uzyskać za pośrednictwem ustawienia Dostawcy szczegółów uwierzytelniania systemu Windows w Menedżerze usług IIS.

Czy klient i serwer są zainstalowane na tym samym komputerze

Domyślnie protokół Kerberos nie jest włączony w tej konfiguracji. Aby zmienić to zachowanie, należy ustawić DisableLoopBackCheck klucz rejestru. Aby uzyskać więcej informacji, zobacz kb 926642.

Czy klient może uzyskać bilet protokołu Kerberos

Możesz użyć narzędzia Listy Kerberos (KLIST), aby sprawdzić, czy komputer kliencki może uzyskać bilet Protokołu Kerberos dla danej nazwy głównej usługi. W tym przykładzie główna nazwa usługi (SPN) to http/web-server.

Gdy żądanie biletu Kerberos zakończy się niepowodzeniem, uwierzytelnianie Kerberos nie jest używane. Może wystąpić rezerwowa nazwa NTLM, ponieważ żądana nazwa SPN jest nieznana kontrolerowi domeny. Jeśli kontroler domeny jest niemożliwy do osiągnięcia, nie wystąpi powrót NTLM.

Aby zadeklarować nazwę SPN, zobacz następujący artykuł:

Jak używać nazw SPN podczas konfigurowania aplikacji internetowych hostowanych w internetowych usługach informacyjnych.

Czy serwer internetowy używa portu innego niż domyślny (80)

Domyślnie program Internet Explorer nie zawiera informacji o numerze portu w głównej nazwie usługi używanej do żądania biletu protokołu Kerberos. Może to być problem, jeśli używasz usług IIS do hostowania wielu witryn w różnych portach i tożsamościach. W tej konfiguracji uwierzytelnianie Kerberos może działać tylko dla określonych lokacji, nawet jeśli wszystkie nazwy SPN zostały poprawnie zadeklarowane w usłudze Active Directory. Aby rozwiązać ten problem, należy ustawić FEATURE_INCLUDE_PORT_IN_SPN_KB908209 wartość rejestru. (Zobacz Sekcja kluczy funkcji programu Internet Explorer zawiera informacje na temat sposobu deklarowania klucza). To ustawienie wymusza, aby program Internet Explorer uwzględniał numer portu w głównej liczbie usług używanej do żądania biletu protokołu Kerberos.

Czy program Internet Explorer używa oczekiwanej nazwy SPN

Jeśli dostęp do witryny internetowej jest uzyskiwany przy użyciu nazwy aliasu (CNAME), program Internet Explorer najpierw używa rozpoznawania nazw DNS do rozpoznawania nazwy aliasu na nazwę komputera (ANAME). Nazwa komputera jest następnie używana do kompilowania nazwy SPN i żądania biletu protokołu Kerberos. Nawet jeśli adres URL wprowadzony na pasku adresu programu Internet Explorer to http://MYWEBSITE, program Internet Explorer żąda nazwy SPN dla protokołu HTTP/MYSERVER, jeśli MYWEBSITE jest aliasem (CNAME) MYSERVER (ANAME). To zachowanie można zmienić przy użyciu FEATURE_USE_CNAME_FOR_SPN_KB911149 klucza rejestru. (Zobacz Klucze funkcji programu Internet Explorer w celu uzyskania informacji o sposobie deklarowania klucza).

Śledzenie monitora sieciowego to dobra metoda sprawdzania nazwy SPN skojarzonej z biletem protokołu Kerberos, jak w poniższym przykładzie:

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

Czy tożsamość puli aplikacji jest zgodna z kontem skojarzonym z nazwą SPN

Gdy bilet Protokołu Kerberos jest wysyłany z programu Internet Explorer do serwera usług IIS, bilet jest szyfrowany przy użyciu klucza prywatnego. Klucz prywatny to skrót hasła używanego dla konta użytkownika skojarzonego z nazwą SPN. W związku z tym tylko aplikacja uruchomiona na tym koncie może dekodować bilet.

Poniższa procedura to podsumowanie algorytmu uwierzytelniania Kerberos:

1. Program Internet Explorer określa nazwę SPN przy użyciu adresu URL wprowadzonego na pasku adresu.

2. Nazwa SPN jest przekazywana za pośrednictwem interfejsu API dostawcy obsługi zabezpieczeń (SSPI) (InitializeSecurityContext) do składnika systemu, który jest odpowiedzialny za zabezpieczenia systemu Windows (proces podsystemu lokalnego urzędu zabezpieczeń (LSASS). Na tym etapie widać, że kod programu Internet Explorer nie implementuje żadnego kodu do konstruowania biletu protokołu Kerberos. Program Internet Explorer wywołuje tylko interfejsy API SSPI.

3. Usługa LSASS używa nazwy SPN przekazanej do żądania biletu protokołu Kerberos do kontrolera domeny. Jeśli kontroler domeny może obsłużyć żądanie (znana nazwa SPN), tworzy bilet protokołu Kerberos. Następnie szyfruje bilet przy użyciu klucza skonstruowanego na podstawie skrótu hasła konta użytkownika dla konta skojarzonego z nazwą SPN. Usługa LSASS wysyła następnie bilet do klienta. Jeśli chodzi o program Internet Explorer, bilet jest nieprzezroczystym obiektem blob.

4. Program Internet Explorer hermetyzuje bilet protokołu Kerberos udostępniany przez usługę LSASS w nagłówku Authorization: Negotiate , a następnie wysyła bilet do serwera usług IIS.

5. Usługi IIS obsługują żądanie i kieruje je do właściwej puli aplikacji przy użyciu określonego nagłówka hosta.

6. Pula aplikacji próbuje odszyfrować bilet przy użyciu interfejsów API SSPI/LSASS i wykonując następujące warunki:

   • Jeśli bilet można odszyfrować, uwierzytelnianie Kerberos powiedzie się. Dostępne są wszystkie usługi skojarzone z biletem (personifikacja, delegowanie, jeśli zezwala na to bilet itd.).

   • Jeśli nie można odszyfrować biletu, zostanie zwrócony błąd protokołu Kerberos (KRB_AP_ERR_MODIFIED). Ten błąd jest ogólnym błędem wskazującym, że bilet został zmieniony w jakiś sposób podczas transportu. W związku z tym nie można odszyfrować biletu. Ten błąd jest również rejestrowany w dziennikach zdarzeń systemu Windows.

Jeśli nie deklarujesz jawnie nazwy SPN, uwierzytelnianie Kerberos działa tylko w ramach jednej z następujących tożsamości puli aplikacji:

• Usługa sieciowa
• ApplicationPoolIdentity
• Inne konto systemowe, takie jak LOCALSYSTEM lub LOCALSERVICE

Te tożsamości nie są jednak zalecane, ponieważ stanowią zagrożenie bezpieczeństwa. W takim przypadku bilet protokołu Kerberos jest kompilowany przy użyciu domyślnej nazwy SPN utworzonej w usłudze Active Directory, gdy komputer (w tym przypadku serwer, na którym działają usługi IIS) jest dodawany do domeny. Ta domyślna nazwa SPN jest skojarzona z kontem komputera. W obszarze IIS konto komputera mapuje na usługę sieciową lub aplikacjęPoolIdentity.

Jeśli pula aplikacji musi używać tożsamości innego niż wymienione tożsamości, zadeklaruj nazwę SPN (przy użyciu programu SETSPN). Następnie skojarz ją z kontem używanym na potrzeby tożsamości puli aplikacji. Typowym błędem jest utworzenie podobnych nazw SPN, które mają różne konta. Na przykład:

• SETSPN http/mywebsite UserAppPool1
• SETSPN http/mywebsite UserAppPool2

Ta konfiguracja nie będzie działać, ponieważ nie ma deterministycznego sposobu, aby wiedzieć, czy bilet Protokołu Kerberos dla nazwy SPN http/mywebsite zostanie zaszyfrowany przy użyciu hasła UserAppPool1 lub UserAppPool2. Ta konfiguracja zwykle generuje błędy KRB_AP_ERR_MODIFIED. Aby określić, czy jesteś w tym złym scenariuszu zduplikowanych nazw SPN, użyj narzędzi opisanych w następującym artykule:

Dlaczego nadal można mieć zduplikowane nazwy SPN w usługach AD 2012 R2 i AD 2016

W systemie Windows Server 2008 można również użyć zaktualizowanej wersji programu SETSPN dla systemu Windows, która umożliwia wykrywanie zduplikowanych nazw SPN przy użyciu setspn –X polecenia podczas deklarowania nowej nazwy SPN dla konta docelowego. Aby uzyskać więcej informacji, zobacz Setspn.

Zalecamy również zapoznanie się z następującymi artykułami:

• Problemy z uwierzytelnianiem kerberos — problemy z główną nazwą usługi (SPN) — część 1

• Problemy z uwierzytelnianiem kerberos — problemy z główną nazwą usługi (SPN) — część 2

• Problemy z uwierzytelnianiem kerberos — problemy z główną nazwą usługi (SPN) — część 3

Czy uwierzytelnianie Kerberos kończy się niepowodzeniem w usługach IIS 7 i nowszych wersjach, mimo że działa w usługach IIS 6

Uwierzytelnianie w trybie jądra to funkcja wprowadzona w usługach IIS 7. Zapewnia następujące korzyści:

• Wydajność jest zwiększana, ponieważ przejścia trybu jądra do użytkownika nie są już wykonywane.
• Dekodowanie biletów protokołu Kerberos odbywa się przy użyciu konta komputera, a nie tożsamości puli aplikacji. Ta zmiana umożliwia uruchamianie wielu pul aplikacji w ramach różnych tożsamości bez konieczności deklarowania nazw SPN.

Dlaczego delegowanie kończy się niepowodzeniem, chociaż uwierzytelnianie Kerberos działa

W tym scenariuszu sprawdź następujące elementy:

• Strefa programu Internet Explorer używana dla adresu URL. Delegowanie protokołu Kerberos jest dozwolone tylko dla stref intranetowych i zaufanych witryn. (Innymi słowy, program Internet Explorer ustawia flagę, gdy wywołuje metodę ISC_REQ_DELEGATE InitializeSecurityContext tylko wtedy, gdy określona strefa to Intranet lub Zaufane witryny).

• Konto użytkownika dla puli aplikacji usług IIS hostujących witrynę musi mieć flagę Zaufane dla delegowania ustawioną w usłudze Active Directory.

Jeśli delegowanie nadal kończy się niepowodzeniem, rozważ użycie programu Kerberos Configuration Manager dla usług IIS. To narzędzie umożliwia diagnozowanie i naprawianie konfiguracji usług IIS na potrzeby uwierzytelniania Kerberos oraz skojarzonych nazw SPN na kontach docelowych. Aby uzyskać więcej informacji, zobacz README.md. Narzędzie można pobrać z tego miejsca.

Dlaczego otrzymuję złą wydajność podczas korzystania z uwierzytelniania Kerberos

Kerberos to oparty na żądaniach protokół uwierzytelniania w starszych wersjach systemu Windows Server, takich jak Windows Server 2008 z dodatkiem SP2 i Windows Server 2008 R2. Oznacza to, że klient musi wysłać bilet protokołu Kerberos (może to być dość duży obiekt blob) przy użyciu każdego żądania wysłanego na serwer. Jest to sprzeczne z metodami uwierzytelniania, które korzystają z protokołu NTLM. Domyślnie protokół NTLM jest oparty na sesji. Oznacza to, że przeglądarka będzie uwierzytelniać tylko jedno żądanie po otwarciu połączenia TCP z serwerem. Każde kolejne żądanie w tym samym połączeniu TCP nie będzie już wymagać uwierzytelnienia w celu zaakceptowania żądania. W nowszych wersjach usług IIS z systemu Windows 2012 R2 nowszych protokół Kerberos jest również oparty na sesji. Serwer musi uwierzytelnić tylko pierwsze żądanie na nowym połączeniu TCP. Kolejne żądania nie muszą zawierać biletu protokołu Kerberos.

To zachowanie można zmienić przy użyciu właściwości authPersistNonNTLM , jeśli korzystasz z usług IIS 7 i nowszych wersji. Jeśli właściwość ma wartość true, kerberos stanie się oparta na sesji. W przeciwnym razie będzie on oparty na żądaniach. Będzie to miało gorsze wyniki, ponieważ za każdym razem musimy uwzględnić większą ilość danych do wysłania na serwer. Aby uzyskać więcej informacji, zobacz Request based versus Session based Kerberos Authentication (lub AuthPersistNonNTLM parametr).

Dlaczego delegowanie protokołu Kerberos kończy się niepowodzeniem między dwoma lasami, chociaż używane do pracy

Rozważmy następujący scenariusz:

• Użytkownicy aplikacji znajdują się w domenie w lesie A.
• Aplikacja znajduje się w domenie w lesie B.
• Istnieje relacja zaufania między lasami.

W tym scenariuszu delegowanie protokołu Kerberos może przestać działać, mimo że wcześniej działało i nie wprowadzono żadnych zmian w lasach lub domenach. Uwierzytelnianie Kerberos nadal działa w tym scenariuszu. Tylko delegowanie kończy się niepowodzeniem.

Ten problem może wystąpić z powodu aktualizacji zabezpieczeń systemu Windows Server, które zostały wydane przez firmę Microsoft w marcu 2019 r. i lipcu 2019 r. Te aktualizacje wyłączyły nieograniczone delegowanie protokołu Kerberos (możliwość delegowania tokenu Kerberos z aplikacji do usługi zaplecza) między granicami lasu dla wszystkich nowych i istniejących relacji zaufania. Aby uzyskać więcej informacji, zobacz Aktualizacje delegowania biletu TGT między przychodzącymi relacjami zaufania w systemie Windows Server.

Klucze funkcji programu Internet Explorer

Te klucze to klucze rejestru, które włączają lub wyłączają niektóre funkcje przeglądarki. Klucze znajdują się w następujących lokalizacjach rejestru:

• HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl — jeśli jest definiowana na poziomie użytkownika
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ — jeśli jest zdefiniowana na poziomie maszyny

Klucze funkcji powinny być tworzone w jednej z tych lokalizacji, w zależności od tego, czy chcesz włączyć, czy wyłączyć funkcję:

• dla wszystkich użytkowników na komputerze
• tylko dla określonego konta

Te klucze należy utworzyć w odpowiedniej ścieżce. Wewnątrz klucza należy zadeklarować wartość DWORD o nazwie iexplorer.exe . Wartość domyślna każdego klucza powinna mieć wartość true lub false, w zależności od żądanego ustawienia funkcji. Domyślnie wartość zarówno kluczy funkcji, FEATURE_INCLUDE_PORT_IN_SPN_KB908209 jak i FEATURE_USE_CNAME_FOR_SPN_KB911149, ma wartość false. Aby uzyskać kompletność, oto przykładowy eksport rejestru przez włączenie klucza funkcji w celu uwzględnienia numerów portów w bilecie protokołu Kerberos na wartość true:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

Więcej informacji

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