Problem med Kerberos-autentisering när en användare tillhör många grupper

Den här artikeln hjälper dig att lösa problemen med Kerberos-autentiseringsfel när en användare tillhör många grupper.

Gäller för: Windows 10 – alla utgåvor, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Ursprungligt KB-nummer: 327825

Symptom

En användare som tillhör ett stort antal säkerhetsgrupper har problem med att autentisera. Vid autentisering kan användaren se ett meddelande, till exempel HTTP 400 – Felaktig begäran (begärandehuvudet är för långt). Användaren har också problem med att komma åt resurser och användarens grupprincip inställningar kanske inte uppdateras korrekt.

Mer information om kontexten för felet finns i HTTP 400 Bad Request (Request Header too long) responses to HTTP requests (HTTP 400 Bad Request (Begärandehuvud för lång) för HTTP-begäranden.

Det här beteendet inträffar i någon av de Windows-versioner som stöds för närvarande. Information om de versioner av Windows som stöds för närvarande finns i faktabladet för Windows livscykel.

Orsak

Användaren kan inte autentisera eftersom den biljett som Kerberos skapar för att representera användaren inte är tillräckligt stor för att innehålla alla användarens gruppmedlemskap.

Som en del av autentiseringstjänsten Exchange skapar Windows en token som representerar användaren i auktoriseringssyfte. Denna token (kallas även en auktoriseringskontext) innehåller användarens säkerhetsidentifierare (SID) och SID för alla grupper som användaren tillhör. Den innehåller även alla sidnumreringar som lagras i användarkontots sIDHistory attribut. Kerberos lagrar denna token i PAC-datastrukturen (Privilege Attribute Certificate) i Kerberos Ticket-Getting Ticket (TGT). Från och med Windows Server 2012 lagrar Kerberos även token i datastrukturen för Active Directory-anspråksinformation (dynamisk Access Control) i Kerberos-biljetten. Om användaren är medlem i ett stort antal grupper, och om det finns många anspråk för användaren eller enheten som används, kan dessa fält uppta många blanksteg i biljetten.

Token har en fast maximal storlek (MaxTokenSize). Transportprotokoll som RPC (Remote Procedure Call) och HTTP förlitar sig på MaxTokenSize värdet när de allokerar buffertar för autentiseringsåtgärder. MaxTokenSize har följande standardvärde, beroende på vilken version av Windows som skapar token:

• Windows Server 2008 R2 och tidigare versioner samt Windows 7 och tidigare versioner: 12 000 byte
• Windows Server 2012 och senare versioner och Windows 8 och senare versioner: 48 000 byte

Om användaren tillhör fler än 120 universella grupper skapar standardvärdet MaxTokenSize vanligtvis inte en tillräckligt stor buffert för att lagra informationen. Användaren kan inte autentisera och kan få ett meddelande om slut på minne . Dessutom kanske Windows inte kan tillämpa grupprincip inställningar för användaren.

Åtgärd

Lös problemet genom att uppdatera registret på varje dator som deltar i Kerberos-autentiseringsprocessen, inklusive klientdatorerna. Vi rekommenderar att du uppdaterar alla dina Windows-baserade system, särskilt om användarna måste logga in på flera domäner eller skogar.

På var och en av dessa datorer anger du MaxTokenSize registerposten till ett större värde. Du hittar den här posten i undernyckeln HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters . Datorerna måste startas om när du har gjort den här ändringen.

Mer information om hur du fastställer ett nytt värde för MaxTokenSizefinns i avsnittet Beräkna maximal tokenstorlek i den här artikeln.

Tänk dig till exempel en användare som använder ett webbprogram som förlitar sig på en SQL Server-klient. Som en del av autentiseringsprocessen skickar SQL Server-klienten användarens token till en serverdelsdatabas SQL Server. I det här fallet måste du konfigurera MaxTokenSize registerposten på var och en av följande datorer:

• Klientdatorn som kör Internet Explorer
• Webbservern som kör IIS
• SQL Server-klientdatorn
• Den SQL Server databasdatorn

I Windows Server 2012 (och senare versioner) kan Windows logga en händelse (händelse-ID 31) om tokenstorleken överskrider ett visst tröskelvärde. Om du vill aktivera det här beteendet måste du konfigurera grupprincip inställningen Datorkonfiguration\Administrativa mallar\System\KDC\Varning för stora Kerberos-biljetter.

Beräkna den maximala tokenstorleken

Använd följande formel för att beräkna storleken på den token som Windows genererar för en viss användare. Den här beräkningen hjälper dig att avgöra om du behöver ändra MaxTokenSize.

TokenSize = 1200 + 40d + 8s

För Windows Server 2012 (och senare versioner) definierar den här formeln dess komponenter på följande sätt:

• 1200. Det uppskattade overheadvärdet för en Kerberos-biljett. Det här värdet kan variera beroende på faktorer som längden på DNS-domännamnet och längden på klientnamnet.
• d. Summan av följande värden:
  • Antalet medlemskap i universella grupper som ligger utanför användarens kontodomän.
  • Antalet SID:ar som lagras i kontots sIDHistory attribut. Det här värdet räknar gruppmedlemskap och användar-SID.
• s. Summan av följande värden:
  • Antalet medlemskap i universella grupper som finns i användarens kontodomän.
  • Antalet medlemskap i domänlokala grupper.
  • Antalet medlemskap i globala grupper.

Windows Server 2008 R2 och tidigare versioner använder samma formel. Dessa versioner anser dock att antalet domänlokala gruppmedlemskap är en del av d-värdet i stället för värdet s .

Om du har värdet MaxTokenSize0x0000FFFF (64K) kan du kanske buffras cirka 1 600 D-klass-SID eller cirka 8 000 S-klass-SID.ar. Ett antal andra faktorer påverkar dock det värde som du kan använda på ett säkert sätt för MaxTokenSize, inklusive följande:

• Om du använder betrodda för delegeringskonton kräver varje SID dubbelt så mycket utrymme.

• Om du har flera förtroenden konfigurerar du förtroenden så att de filtrerar SID.ar. Den här konfigurationen minskar effekten av Kerberos-biljettstorleken.

• Om du använder Windows Server 2012 eller en senare version påverkar följande faktorer även kraven på SID-utrymme:

  • Det finns ett nytt schema för att komprimera SID i PAC. Mer information finns i Komprimering av KDC-resurs-SID. Den här funktionen minskar storleken som behövs för SID i biljetten.
  • Dynamisk Access Control lägger till Active Directory-anspråk i biljetten, vilket ökar storlekskraven. Men när du har distribuerat anspråk med Windows Server 2012 filservrar kan du förvänta dig att fasa ut ett stort antal grupper som styr filåtkomsten. Den här minskningen kan i sin tur minska storleken som behövs i biljetten. Mer information finns i Dynamisk Access Control: Scenarioöversikt.

• Om du har konfigurerat Kerberos för att använda obegränsad delegering måste du fördubbla TokenSize värdet från formeln för att få en giltig uppskattning av MaxTokenSize.

  Viktigt

  Under 2019 levererade Microsoft uppdateringar till Windows som ändrade standardkonfigurationen för obegränsad delegering för Kerberos till inaktiverad. Mer information finns i Uppdateringar till TGT-delegering över inkommande förtroenden i Windows Server.

  Eftersom resurs-SID-komprimering används ofta och obegränsad delegering är inaktuell MaxTokenSize , bör 48000 eller större bli tillräckligt för alla scenarier.

Kända problem som påverkar MaxTokenSize

Ett MaxTokenSize värde på 48 000 byte bör vara tillräckligt för de flesta implementeringar. Detta är standardvärdet i Windows Server 2012 och senare versioner. Men om du bestämmer dig för att använda ett större värde läser du de kända problemen i det här avsnittet.

• Storleksgräns på 1 010 grupp-SID för LSA-åtkomsttoken

  Det här problemet liknar det faktum att en användare som har för många gruppmedlemskap inte kan autentisera, men de beräkningar och villkor som styr problemet skiljer sig åt. Användaren kan till exempel stöta på det här problemet när han eller hon använder Antingen Kerberos-autentisering eller Windows NTLM-autentisering. Mer information finns i Logga in på ett användarkonto som är medlem i fler än 1 010 grupper kan misslyckas på en Windows Server-baserad dator.

• Känt problem när du använder värden för MaxTokenSize som är större än 48 000

  Internet Information Server (IIS) använder en begränsad buffertstorlek på 64 kB för att undvika överbelastningsattacker. En Kerberos-biljett som ingår i en HTTP-begäran kodas som Base64 (6 bitar expanderas till 8 bitar). Därför använder Kerberos-biljetten 133 procent av sin ursprungliga storlek. När den maximala buffertstorleken är 64 kB i IIS kan Kerberos-biljetten därför använda 48 000 byte.

  Om du anger MaxTokenSize registerposten till ett värde som är större än 48 000 byte och buffertutrymmet används för SID-nummer kan ett IIS-fel uppstå. Men om du anger MaxTokenSize registerposten till 48 000 byte och du använder utrymmet för SID och anspråk uppstår ett Kerberos-fel.

  Mer information om IIS-buffertstorlekar finns i Så här begränsar du huvudstorleken för DEN HTTP-överföring som IIS accepterar från en klient i Windows 2000.

• Kända problem när du använder värden för MaxTokenSize som är större än 65 535

  Tidigare versioner av den här artikeln diskuterade värden på upp till 100 000 byte för MaxTokenSize. Vi har dock upptäckt att versioner av SMS Administrator har problem när är MaxTokenSize 100 000 byte eller större.

  Vi har också identifierat att IPSEC IKE-protokollet inte tillåter att en säkerhetsblob blir större än 66 536 byte, och att det också misslyckas när MaxTokenSize är inställt på ett större värde.