Problemy z uwierzytelnianiem Kerberos, gdy użytkownik należy do wielu grup
Ten artykuł ułatwia rozwiązywanie problemów związanych z niepowodzeniem uwierzytelniania Kerberos, gdy użytkownik należy do wielu grup.
Dotyczy systemów: Windows 10 — wszystkie wersje, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Oryginalny numer KB: 327825
Symptomy
Użytkownik należący do dużej liczby grup zabezpieczeń ma problemy z uwierzytelnianiem. Podczas uwierzytelniania użytkownik może zobaczyć komunikat, taki jak HTTP 400 — nieprawidłowe żądanie (zbyt długi nagłówek żądania). Użytkownik ma również problemy z dostępem do zasobów, a ustawienia zasady grupy użytkownika mogą nie zostać poprawnie zaktualizowane.
Aby uzyskać więcej informacji na temat kontekstu błędu, zobacz Http 400 Bad Request (Request Header too long) responses to HTTP requests (Zbyt długie żądania żądania) na żądania HTTP.
Uwaga
W podobnych warunkach uwierzytelnianie NTLM systemu Windows działa zgodnie z oczekiwaniami. Problem z uwierzytelnianiem Kerberos może nie zostać wyświetlony, chyba że przeanalizujesz zachowanie systemu Windows. Jednak w takich scenariuszach system Windows może nie być w stanie zaktualizować ustawień zasady grupy.
To zachowanie występuje w dowolnej z obecnie obsługiwanych wersji systemu Windows. Aby uzyskać informacje o aktualnie obsługiwanych wersjach systemu Windows, zobacz arkusz informacyjny cyklu życia systemu Windows.
Przyczyna
Użytkownik nie może uwierzytelnić się, ponieważ bilet, który jest kompilowany przez protokół Kerberos w celu reprezentowania użytkownika, nie jest wystarczająco duży, aby zawierał wszystkie członkostwa w grupach użytkownika.
W ramach programu Authentication Service Exchange system Windows tworzy token reprezentujący użytkownika na potrzeby autoryzacji. Ten token (nazywany również kontekstem autoryzacji) zawiera identyfikatory zabezpieczeń (SID) użytkownika oraz identyfikatory SID wszystkich grup, do których należy użytkownik. Zawiera również wszystkie identyfikatory SID, które są przechowywane w atrybucie konta sIDHistory
użytkownika. Protokół Kerberos przechowuje ten token w strukturze danych certyfikatu atrybutu uprawnień (PAC) w bilecie protokołu Kerberos Ticket-Getting (TGT). Począwszy od Windows Server 2012, protokół Kerberos przechowuje również token w strukturze danych informacji o oświadczeniach usługi Active Directory (dynamic Access Control) w bilecie Protokołu Kerberos. Jeśli użytkownik jest członkiem dużej liczby grup i jeśli istnieje wiele oświadczeń dla użytkownika lub używanego urządzenia, te pola mogą zajmować wiele miejsc w bilecie.
Token ma stały maksymalny rozmiar (MaxTokenSize
). Protokoły transportu, takie jak zdalne wywołanie procedury (RPC) i HTTP, zależą MaxTokenSize
od wartości podczas przydzielania buforów dla operacji uwierzytelniania. MaxTokenSize
Ma następującą wartość domyślną, w zależności od wersji systemu Windows, która tworzy token:
- Windows Server 2008 R2 i starsze wersje oraz Windows 7 i starsze wersje: 12 000 bajtów
- Windows Server 2012 i nowszych wersjach oraz Windows 8 i nowszych wersjach: 48 000 bajtów
Ogólnie rzecz biorąc, jeśli użytkownik należy do ponad 120 grup uniwersalnych, wartość domyślna MaxTokenSize
nie tworzy wystarczająco dużego buforu do przechowywania informacji. Użytkownik nie może uwierzytelnić się i może otrzymać komunikat o braku pamięci . Ponadto system Windows może nie być w stanie zastosować ustawień zasady grupy dla użytkownika.
Uwaga
Inne czynniki mają również wpływ na maksymalną liczbę grup. Na przykład identyfikatory SID dla grup globalnych i lokalnych mają mniejsze wymagania dotyczące miejsca. Windows Server 2012 i nowszych wersjach dodają informacje o roszczeniach do biletu Protokołu Kerberos, a także kompresują identyfikatory SID zasobów. Obie funkcje zmieniają wymagania dotyczące miejsca.
Rozwiązanie
Aby rozwiązać ten problem, zaktualizuj rejestr na każdym komputerze, który uczestniczy w procesie uwierzytelniania Kerberos, w tym na komputerach klienckich. Zalecamy zaktualizowanie wszystkich systemów opartych na systemie Windows, zwłaszcza jeśli użytkownicy muszą logować się w wielu domenach lub lasach.
Ważna
Niepoprawne zmodyfikowanie rejestru może być przyczyną poważnych problemów. Zanim go zmodyfikujesz, utwórz kopię zapasową rejestru w celu przywrócenia, jeśli wystąpią problemy.
Na każdym z tych komputerów ustaw MaxTokenSize
wpis rejestru na większą wartość. Ten wpis można znaleźć w podkluczu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
. Komputery muszą zostać ponownie uruchomione po wprowadzeniu tej zmiany.
Aby uzyskać więcej informacji na temat określania nowej wartości dla MaxTokenSize
programu , zobacz sekcję Obliczanie maksymalnego rozmiaru tokenu w tym artykule.
Rozważmy na przykład użytkownika, który korzysta z aplikacji internetowej, która opiera się na kliencie SQL Server. W ramach procesu uwierzytelniania klient SQL Server przekazuje token użytkownika do bazy danych SQL Server zaplecza. W takim przypadku należy skonfigurować MaxTokenSize
wpis rejestru na każdym z następujących komputerów:
- Komputer kliencki z uruchomionym programem Internet Explorer
- Serwer internetowy z uruchomionymi usługami IIS
- Komputer kliencki SQL Server
- Komputer bazy danych SQL Server
W Windows Server 2012 (i nowszych wersjach) system Windows może rejestrować zdarzenie (identyfikator zdarzenia 31), jeśli rozmiar tokenu przekroczy określony próg. Aby włączyć to zachowanie, należy skonfigurować ustawienie zasady grupy Konfiguracja komputera\Szablony administracyjne\System\Centrum dystrybucji kluczy\Ostrzeżenie dla dużych biletów Protokołu Kerberos.
Obliczanie maksymalnego rozmiaru tokenu
Użyj poniższej formuły, aby obliczyć rozmiar tokenu wygenerowanego przez system Windows dla określonego użytkownika. To obliczenie pomaga określić, czy należy zmienić MaxTokenSize
wartość .
TokenSize = 1200 + 40d + 8s
W przypadku Windows Server 2012 (i nowszych wersji) ta formuła definiuje składniki w następujący sposób:
- 1200. Szacowana wartość narzutu dla biletu Kerberos. Ta wartość może się różnić w zależności od czynników, takich jak długość nazwy domeny DNS i długość nazwy klienta.
- d. Suma następujących wartości:
- Liczba członkostw w grupach uniwersalnych, które znajdują się poza domeną konta użytkownika.
- Liczba identyfikatorów SID przechowywanych w atrybucie konta
sIDHistory
. Ta wartość zlicza członkostwa w grupach i identyfikatory SID użytkowników.
- s. Suma następujących wartości:
- Liczba członkostw w grupach uniwersalnych, które znajdują się w domenie konta użytkownika.
- Liczba członkostw w grupach domeny lokalnej.
- Liczba członkostw w grupach globalnych.
System Windows Server 2008 R2 i starsze wersje używają tej samej formuły. Jednak te wersje uważają, że liczba członkostw w grupach domeny lokalnej jest częścią wartości d zamiast wartości s .
Jeśli masz MaxTokenSize
wartość 0x0000FFFF (64K), możesz buforować około 1600 identyfikatorów SID klasy d lub około 8000 identyfikatorów SID klasy S. Jednak wiele innych czynników ma wpływ na wartość, która może być bezpiecznie używana dla MaxTokenSize
programu , w tym następujące elementy:
Jeśli używasz zaufanych kont delegowania , każdy identyfikator SID wymaga dwa razy więcej miejsca.
Jeśli masz wiele relacji zaufania, skonfiguruj relacje zaufania do filtrowania identyfikatorów SID. Ta konfiguracja zmniejsza wpływ rozmiaru biletu Kerberos.
Jeśli używasz Windows Server 2012 lub nowszej wersji, następujące czynniki mają również wpływ na wymagania dotyczące przestrzeni identyfikatorów SID:
- Istnieje nowy schemat kompresowania identyfikatorów SID w interfejsie PAC. Aby uzyskać więcej informacji, zobacz Kompresja identyfikatora SID zasobu centrum dystrybucji kluczy. Ta funkcja zmniejsza rozmiar wymagany dla identyfikatorów SID w bilecie.
- Dynamiczne Access Control dodaje oświadczenia usługi Active Directory do biletu, zwiększając wymagania dotyczące rozmiaru. Jednak po wdrożeniu oświadczeń z serwerami plików Windows Server 2012 można oczekiwać stopniowego wycofywania znacznej liczby grup, które kontrolują dostęp do plików. To zmniejszenie może z kolei zmniejszyć rozmiar wymagany w bilecie. Aby uzyskać więcej informacji, zobacz Dynamic Access Control: Scenario Overview (Dynamiczne Access Control: omówienie scenariusza).
Jeśli skonfigurowano protokół Kerberos do używania nieograniczonego delegowania, musisz podwoić
TokenSize
wartość z formuły, aby uzyskać prawidłowe oszacowanie wartościMaxTokenSize
.Ważna
W 2019 roku firma Microsoft wysłała aktualizacje systemu Windows, które zmieniły domyślną konfigurację nieograniczonego delegowania protokołu Kerberos na wyłączoną. Aby uzyskać więcej informacji, zobacz Aktualizacje delegowania TGT między przychodzącymi relacjami zaufania w systemie Windows Server.
Ponieważ kompresja identyfikatorów SID zasobów jest powszechnie używana, a delegowanie niewprawne jest przestarzałe,
MaxTokenSize
wartość 48000 lub większa powinna stać się wystarczająca dla wszystkich scenariuszy.
Znane problemy, które mają wpływ na maxTokenSize
Dla MaxTokenSize
większości implementacji powinna być wystarczająca wartość 48 000 bajtów. Jest to wartość domyślna w Windows Server 2012 i nowszych wersjach. Jeśli jednak zdecydujesz się na użycie większej wartości, zapoznaj się ze znanymi problemami w tej sekcji.
Limit rozmiaru 1010 identyfikatorów SID grupy dla tokenu dostępu LSA
Ten problem jest podobny do tego, że użytkownik, który ma zbyt wiele członkostw w grupach, nie może uwierzytelnić się, ale obliczenia i warunki, które regulują problem, są różne. Na przykład użytkownik może napotkać ten problem podczas korzystania z uwierzytelniania Kerberos lub uwierzytelniania NTLM systemu Windows. Aby uzyskać więcej informacji, zobacz Rejestrowanie konta użytkownika należącego do ponad 1010 grup może zakończyć się niepowodzeniem na komputerze z systemem Windows Server.
Znany problem podczas korzystania z wartości MaxTokenSize większych niż 48 000
Aby wyeliminować wektor ataków typu "odmowa usługi", serwer Internet Information Server (IIS) używa ograniczonego rozmiaru buforu żądania HTTP wynoszącego 64 KB. Bilet Protokołu Kerberos, który jest częścią żądania HTTP, jest kodowany jako Base64 (6 bitów zostało rozszerzonych do 8 bitów). W związku z tym bilet Kerberos używa 133 procent swojego pierwotnego rozmiaru. W związku z tym, gdy maksymalny rozmiar buforu wynosi 64 KB w usługach IIS, bilet Kerberos może używać 48 000 bajtów.
Jeśli ustawisz
MaxTokenSize
wpis rejestru na wartość większą niż 48000 bajtów, a miejsce buforu jest używane dla identyfikatorów SID, może wystąpić błąd usług IIS. Jeśli jednak ustawiszMaxTokenSize
wpis rejestru na 48 000 bajtów i użyjesz miejsca dla identyfikatorów SID i oświadczeń, wystąpi błąd Kerberos.Aby uzyskać więcej informacji na temat rozmiarów buforów usług IIS, zobacz How to limit the header size of the HTTP transmission that IIS accepts from a client in Windows 2000 (Jak ograniczyć rozmiar nagłówka transmisji HTTP akceptowanej przez usługi IIS od klienta w systemie Windows 2000).
Znane problemy podczas korzystania z wartości MaxTokenSize większych niż 65 535
W poprzednich wersjach tego artykułu omówiono wartości do 100 000 bajtów dla
MaxTokenSize
programu . Okazało się jednak, że wersje administratora programu SMS mają problemy, gdyMaxTokenSize
jest to 100 000 bajtów lub więcej.Ustaliliśmy również, że protokół IPSEC IKE nie zezwala na to, aby obiekt BLOB zabezpieczeń był większy niż 66 536 bajtów, a także kończył się niepowodzeniem, gdy
MaxTokenSize
ustawiono większą wartość.
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla