Problemen met Kerberos-verificatie wanneer een gebruiker tot veel groepen behoort

Dit artikel helpt u bij het oplossen van problemen met kerberos-verificatiefouten wanneer een gebruiker tot veel groepen behoort.

Van toepassing op: Windows 10 - alle edities, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Origineel KB-nummer: 327825

Symptomen

Een gebruiker die tot een groot aantal beveiligingsgroepen behoort, heeft problemen met de verificatie. Tijdens het verifiëren ziet de gebruiker mogelijk een bericht zoals HTTP 400 - Ongeldige aanvraag (aanvraagheader te lang). De gebruiker heeft ook problemen bij het openen van resources en de groepsbeleid-instellingen van de gebruiker worden mogelijk niet correct bijgewerkt.

Zie HTTP 400 Ongeldige aanvraag (aanvraagheader te lang) voor meer informatie over de context van de fout.

Dit gedrag treedt op in een van de momenteel ondersteunde Windows-versies. Zie informatieblad over de levenscyclus van Windows voor informatie over de momenteel ondersteunde versies van Windows.

Oorzaak

De gebruiker kan zich niet verifiëren omdat het ticket dat Kerberos bouwt om de gebruiker te vertegenwoordigen, niet groot genoeg is om alle groepslidmaatschappen van de gebruiker te bevatten.

Als onderdeel van de Authentication Service Exchange maakt Windows een token dat de gebruiker vertegenwoordigt voor autorisatiedoeleinden. Dit token (ook wel een autorisatiecontext genoemd) bevat de beveiligings-id's (SID's) van de gebruiker en de SID's van alle groepen waartoe de gebruiker behoort. Het bevat ook eventuele SID's die zijn opgeslagen in het kenmerk van sIDHistory het gebruikersaccount. Kerberos slaat dit token op in de gegevensstructuur Privilege Attribute Certificate (PAC) in de Kerberos Ticket-Getting Ticket (TGT). Vanaf Windows Server 2012 slaat Kerberos het token ook op in de gegevensstructuur Active Directory Claims information (Dynamic Access Control) in het Kerberos-ticket. Als de gebruiker lid is van een groot aantal groepen en er veel claims zijn voor de gebruiker of het apparaat dat wordt gebruikt, kunnen deze velden veel spaties in het ticket in beslag nemen.

Het token heeft een vaste maximale grootte (MaxTokenSize). Transportprotocollen zoals RPC (Remote Procedure Call) en HTTP zijn afhankelijk van de MaxTokenSize waarde wanneer ze buffers toewijzen voor verificatiebewerkingen. MaxTokenSize heeft de volgende standaardwaarde, afhankelijk van de versie van Windows waarmee het token wordt gebouwd:

• Windows Server 2008 R2 en eerdere versies, en Windows 7 en eerdere versies: 12.000 bytes
• Windows Server 2012 en latere versies, en Windows 8 en latere versies: 48.000 bytes

Als de gebruiker tot meer dan 120 universele groepen behoort, maakt de standaardwaarde MaxTokenSize over het algemeen geen buffer die groot genoeg is om de informatie op te slaan. De gebruiker kan zich niet verifiëren en ontvangt mogelijk een bericht over onvoldoende geheugen . Bovendien kan Windows mogelijk geen groepsbeleid-instellingen voor de gebruiker toepassen.

Oplossing

U kunt dit probleem oplossen door het register bij te werken op elke computer die deelneemt aan het Kerberos-verificatieproces, inclusief de clientcomputers. We raden u aan al uw Windows-systemen bij te werken, met name als uw gebruikers zich moeten aanmelden in meerdere domeinen of forests.

Stel op elk van deze computers de MaxTokenSize registervermelding in op een hogere waarde. U vindt deze vermelding in de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters subsleutel. De computers moeten opnieuw worden opgestart nadat u deze wijziging hebt aangebracht.

Zie de sectie De maximale tokengrootte berekenen van dit artikel voor meer informatie over het bepalen van een nieuwe waarde voorMaxTokenSize.

Denk bijvoorbeeld aan een gebruiker die een webtoepassing gebruikt die afhankelijk is van een SQL Server-client. Als onderdeel van het verificatieproces geeft de SQL Server-client het token van de gebruiker door aan een back-end-SQL Server-database. In dit geval moet u de MaxTokenSize registervermelding configureren op elk van de volgende computers:

• De clientcomputer waarop Internet Explorer wordt uitgevoerd
• De webserver waarop IIS wordt uitgevoerd
• De SQL Server clientcomputer
• De SQL Server databasecomputer

In Windows Server 2012 (en latere versies) kan Windows een gebeurtenis (gebeurtenis-id 31) registreren als de tokengrootte een bepaalde drempelwaarde overschrijdt. Als u dit gedrag wilt inschakelen, moet u de groepsbeleid instelling Computerconfiguratie\Beheersjablonen\System\KDC\Warning configureren voor grote Kerberos-tickets.

De maximale tokengrootte berekenen

Gebruik de volgende formule om de grootte te berekenen van het token dat Windows voor een bepaalde gebruiker genereert. Met deze berekening kunt u bepalen of u moet wijzigen MaxTokenSize.

TokenSize = 1200 + 40d + 8s

Voor Windows Server 2012 (en latere versies) definieert deze formule de onderdelen als volgt:

• 1200. De geschatte overheadwaarde voor een Kerberos-ticket. Deze waarde kan variëren, afhankelijk van factoren zoals de lengte van de DNS-domeinnaam en de lengte van de clientnaam.
• d. De som van de volgende waarden:
  • Het aantal lidmaatschappen in universele groepen dat zich buiten het accountdomein van de gebruiker bevindt.
  • Het aantal SID's dat is opgeslagen in het kenmerk van sIDHistory het account. Met deze waarde worden groepslidmaatschappen en gebruikers-SID's geteld.
• s. De som van de volgende waarden:
  • Het aantal lidmaatschappen in universele groepen dat zich binnen het accountdomein van de gebruiker bevindt.
  • Het aantal lidmaatschappen in domein-lokale groepen.
  • Het aantal lidmaatschappen in globale groepen.

Windows Server 2008 R2 en eerdere versies gebruiken dezelfde formule. In deze versies wordt echter het aantal domein-lokale groepslidmaatschappen beschouwd als onderdeel van de d-waarde in plaats van de s-waarde .

Als u een MaxTokenSize waarde van 0x0000FFFF (64K) hebt, kunt u mogelijk ongeveer 1600 d-klasse SID's of ongeveer 8000 s-klasse SID's bufferen. Een aantal andere factoren is echter van invloed op de waarde die u veilig kunt gebruiken voor MaxTokenSize, waaronder de volgende:

• Als u vertrouwd gebruikt voor delegatieaccounts , heeft elke SID twee keer zoveel ruimte nodig.

• Als u meerdere vertrouwensrelaties hebt, configureert u de vertrouwensrelaties om SID's te filteren. Deze configuratie vermindert de impact van de Grootte van het Kerberos-ticket.

• Als u Windows Server 2012 of een latere versie gebruikt, zijn de volgende factoren ook van invloed op de vereisten voor SID-ruimte:

  • Er is een nieuw schema voor het comprimeren van de SID's in het PAC. Zie KDC Resource SID-compressie voor meer informatie. Deze functie vermindert de benodigde grootte voor SID's in het ticket.
  • Dynamische Access Control voegt Active Directory-claims toe aan het ticket, waardoor de vereisten voor de grootte toenemen. Nadat u echter claims met Windows Server 2012 bestandsservers hebt geïmplementeerd, kunt u verwachten dat een aanzienlijk aantal groepen dat de toegang tot bestanden controleert, geleidelijk wordt uitgeschakeld. Deze vermindering kan op zijn beurt de benodigde grootte in het ticket verminderen. Zie Dynamische Access Control: Scenariooverzicht voor meer informatie.

• Als u Kerberos hebt geconfigureerd voor het gebruik van onbeperkte delegering, moet u de waarde van de TokenSize formule verdubbelen om een geldige schatting van MaxTokenSizete verkrijgen.

  Belangrijk

  In 2019 heeft Microsoft updates naar Windows verzonden die de standaardconfiguratie van niet-beperkte delegering voor Kerberos heeft gewijzigd in uitgeschakeld. Zie Updates TGT-delegering tussen binnenkomende vertrouwensrelaties in Windows Server voor meer informatie.

  Omdat bron-SID-compressie veel wordt gebruikt en onbeperkte delegering wordt afgeschaft, MaxTokenSize moet 48000 of groter voldoende zijn voor alle scenario's.

Bekende problemen die van invloed zijn op MaxTokenSize

Een MaxTokenSize waarde van 48.000 bytes moet voldoende zijn voor de meeste implementaties. Dit is de standaardwaarde in Windows Server 2012 en latere versies. Als u echter een grotere waarde wilt gebruiken, bekijkt u de bekende problemen in deze sectie.

• Groottelimiet van 1010 groeps-SID's voor het LSA-toegangstoken

  Dit probleem is vergelijkbaar omdat een gebruiker met te veel groepslidmaatschappen niet kan verifiëren, maar de berekeningen en voorwaarden die het probleem bepalen, verschillen. De gebruiker kan dit probleem bijvoorbeeld tegenkomen tijdens het gebruik van Kerberos-verificatie of Windows NTLM-verificatie. Zie Logboekregistratie voor een gebruikersaccount dat lid is van meer dan 1010 groepen kan mislukken op een Computer met Windows Server voor meer informatie.

• Bekend probleem bij het gebruik van waarden van MaxTokenSize groter dan 48.000

  Internet Information Server (IIS) gebruikt een beperkte HTTP-aanvraagbuffergrootte van 64 kB om een Denial of Service-aanvalsvector te beperken. Een Kerberos-ticket dat deel uitmaakt van een HTTP-aanvraag, wordt gecodeerd als Base64 (6 bits uitgebreid tot 8 bits). Daarom gebruikt het Kerberos-ticket 133 procent van de oorspronkelijke grootte. Als de maximale buffergrootte in IIS 64 kB is, kan het Kerberos-ticket dus 48.000 bytes gebruiken.

  Als u de MaxTokenSize registervermelding instelt op een waarde die groter is dan 48000 bytes en de bufferruimte wordt gebruikt voor SID's, kan er een IIS-fout optreden. Als u de MaxTokenSize registervermelding echter instelt op 48.000 bytes en u de ruimte voor SID's en claims gebruikt, treedt er een Kerberos-fout op.

  Zie How to limit the header size of the HTTP transmission that IIS accepts from a client in Windows 2000 (De headergrootte beperken van de HTTP-overdracht die IIS accepteert van een client in Windows 2000) voor meer informatie over IIS-buffergrootten.

• Bekende problemen bij het gebruik van waarden van MaxTokenSize groter dan 65.535

  In eerdere versies van dit artikel zijn waarden van maximaal 100.000 bytes voor MaxTokenSizebesproken. We hebben echter vastgesteld dat versies van SMS Administrator problemen hebben wanneer de MaxTokenSize 100.000 bytes of groter is.

  We hebben ook vastgesteld dat het IPSEC IKE-protocol niet toestaat dat een beveiligings-BLOB groter wordt dan 66.536 bytes en dat deze ook mislukt wanneer MaxTokenSize deze is ingesteld op een grotere waarde.