Problemas con la autenticación Kerberos cuando un usuario pertenece a muchos grupos

Este artículo le ayuda a resolver los problemas de error de autenticación Kerberos cuando un usuario pertenece a muchos grupos.

Se aplica a: Windows 10: todas las ediciones, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Número de KB original: 327825

Síntomas

Un usuario que pertenece a un gran número de grupos de seguridad tiene problemas para autenticarse. Al autenticarse, el usuario puede ver un mensaje como HTTP 400 : solicitud incorrecta (encabezado de solicitud demasiado largo). El usuario también tiene problemas para acceder a los recursos y es posible que la configuración de directiva de grupo del usuario no se actualice correctamente.

Para obtener más información sobre el contexto del error, vea Http 400 Bad Request (Request Header too long) responses to HTTP requests (Http 400 Bad Request (Request Header too long) responses to HTTP requests(HTTP 400 Bad Request (Http 400 Bad Request [Http 400 Bad Request (Encabezado de solicitud demasiado largo]) responses to HTTP requests (Http 400 Bad

Nota:

En condiciones similares, la autenticación NTLM de Windows funciona según lo esperado. Es posible que no vea el problema de autenticación Kerberos a menos que analice el comportamiento de Windows. Sin embargo, en estos escenarios, Es posible que Windows no pueda actualizar directiva de grupo configuración.

Este comportamiento se produce en cualquiera de las versiones de Windows compatibles actualmente. Para obtener información sobre las versiones compatibles actualmente de Windows, vea Hoja de hechos del ciclo de vida de Windows.

Causa

El usuario no puede autenticarse porque el vale que Kerberos compila para representar al usuario no es lo suficientemente grande como para contener todas las pertenencias a grupos del usuario.

Como parte de Authentication Service Exchange, Windows crea un token para representar al usuario con fines de autorización. Este token (también denominado contexto de autorización) incluye los identificadores de seguridad (SID) del usuario y los SID de todos los grupos a los que pertenece el usuario. También incluye los SID almacenados en el atributo de la cuenta de sIDHistory usuario. Kerberos almacena este token en la estructura de datos del certificado de atributos de privilegios (PAC) en el vale de Ticket-Getting kerberos (TGT). A partir de Windows Server 2012, Kerberos también almacena el token en la estructura de datos de información de notificaciones de Active Directory (Access Control dinámica) en el vale de Kerberos. Si el usuario es miembro de un gran número de grupos y hay muchas notificaciones para el usuario o el dispositivo que se usa, estos campos pueden ocupar muchos espacios en el vale.

El token tiene un tamaño máximo fijo (MaxTokenSize). Los protocolos de transporte, como la llamada a procedimiento remoto (RPC) y HTTP, se basan en el MaxTokenSize valor cuando asignan búferes para las operaciones de autenticación. MaxTokenSize tiene el siguiente valor predeterminado, en función de la versión de Windows que compila el token:

  • Windows Server 2008 R2 y versiones anteriores, y Windows 7 y versiones anteriores: 12 000 bytes
  • Windows Server 2012 y versiones posteriores, y Windows 8 y versiones posteriores: 48 000 bytes

Por lo general, si el usuario pertenece a más de 120 grupos universales, el valor predeterminado MaxTokenSize no crea un búfer lo suficientemente grande como para contener la información. El usuario no puede autenticarse y puede recibir un mensaje de memoria insuficiente . Además, es posible que Windows no pueda aplicar directiva de grupo configuración para el usuario.

Nota:

Otros factores también afectan al número máximo de grupos. Por ejemplo, los SID para grupos globales y locales de dominio tienen requisitos de espacio más pequeños. Windows Server 2012 y versiones posteriores agregan información de notificación al vale de Kerberos y también comprimen los SID de recursos. Ambas características cambian los requisitos de espacio.

Solución

Para resolver este problema, actualice el Registro en cada equipo que participe en el proceso de autenticación Kerberos, incluidos los equipos cliente. Se recomienda actualizar todos los sistemas basados en Windows, especialmente si los usuarios tienen que iniciar sesión en varios dominios o bosques.

Importante

La modificación incorrecta del Registro puede producir graves problemas. Antes de modificarlo, realice una copia de seguridad del registro para su restauración, en caso de que se produzcan problemas.

En cada uno de estos equipos, establezca la entrada del MaxTokenSize Registro en un valor mayor. Puede encontrar esta entrada en la HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters subclave. Los equipos tienen que reiniciarse después de realizar este cambio.

Para obtener más información sobre cómo determinar un nuevo valor para MaxTokenSize, consulte la sección Cálculo del tamaño máximo del token de este artículo.

Por ejemplo, considere la posibilidad de un usuario que usa una aplicación web que se basa en un cliente de SQL Server. Como parte del proceso de autenticación, el cliente de SQL Server pasa el token del usuario a una base de datos SQL Server back-end. En este caso, tendría que configurar la entrada del MaxTokenSize Registro en cada uno de los siguientes equipos:

  • Equipo cliente que ejecuta Internet Explorer
  • Servidor web que ejecuta IIS
  • El equipo cliente SQL Server
  • Equipo de base de datos SQL Server

En Windows Server 2012 (y versiones posteriores), Windows puede registrar un evento (id. de evento 31) si el tamaño del token supera un umbral determinado. Para habilitar este comportamiento, debe configurar el directiva de grupo configuración configuración del equipo\Plantillas administrativas\System\KDC\Advertencia para vales kerberos grandes.

Cálculo del tamaño máximo del token

Use la fórmula siguiente para calcular el tamaño del token que Windows genera para un usuario determinado. Este cálculo le ayuda a determinar si necesita cambiar MaxTokenSize.

TokenSize = 1200 + 40d + 8s

Para Windows Server 2012 (y versiones posteriores), esta fórmula define sus componentes de la siguiente manera:

  • 1200. Valor de sobrecarga estimado para un vale de Kerberos. Este valor puede variar, en función de factores como la longitud del nombre de dominio DNS y la longitud del nombre de cliente.
  • d. Suma de los siguientes valores:
    • Número de pertenencias a grupos universales que están fuera del dominio de la cuenta del usuario.
    • Número de SID almacenados en el atributo de la sIDHistory cuenta. Este valor cuenta las pertenencias a grupos y los SID de usuario.
  • s. Suma de los siguientes valores:
    • Número de pertenencias a grupos universales que se encuentran dentro del dominio de la cuenta del usuario.
    • Número de pertenencias a grupos locales de dominio.
    • Número de pertenencias a grupos globales.

Windows Server 2008 R2 y versiones anteriores usan la misma fórmula. Sin embargo, estas versiones consideran que el número de pertenencias a grupos locales de dominio forma parte del valor d en lugar del valor s .

Si tiene un MaxTokenSize valor de 0x0000FFFF (64K), es posible que pueda almacenar en búfer aproximadamente 1600 SID de clase D o aproximadamente 8000 SID de clase S. Sin embargo, otros factores influyen en el valor que se puede usar de forma segura para MaxTokenSize, incluidos los siguientes:

  • Si usa confianza para las cuentas de delegación , cada SID requiere el doble de espacio.

  • Si tiene varias confianzas, configure las confianzas para filtrar los SID. Esta configuración reduce el impacto del tamaño del vale de Kerberos.

  • Si usa Windows Server 2012 o una versión posterior, los siguientes factores también afectan a los requisitos de espacio del SID:

    • Hay un nuevo esquema para comprimir los SID en el PAC. Para obtener más información, vea Compresión de SID de recursos de KDC. Esta característica reduce el tamaño necesario para los SID en el vale.
    • El Access Control dinámico agrega notificaciones de Active Directory al vale, lo que aumenta los requisitos de tamaño. Sin embargo, después de implementar notificaciones con Windows Server 2012 servidores de archivos, puede esperar eliminar gradualmente un número significativo de grupos que controlan el acceso a archivos. Esta reducción puede a su vez reducir el tamaño necesario en el vale. Para obtener más información, vea Access Control dinámica: Introducción al escenario.
  • Si ha configurado Kerberos para usar la delegación sin restricciones, debe duplicar el TokenSize valor de la fórmula para obtener una estimación válida de MaxTokenSize.

    Importante

    En 2019, Microsoft envió actualizaciones a Windows que cambiaron la configuración predeterminada de la delegación sin restricciones de Kerberos a deshabilitada. Para obtener más información, vea Novedades a la delegación de TGT entre las confianzas entrantes en Windows Server.

    Como la compresión del SID de recursos se usa ampliamente y la delegación sin restricciones está en desuso, MaxTokenSize de 48000 o más debe ser suficiente para todos los escenarios.

Problemas conocidos que afectan a MaxTokenSize

Un MaxTokenSize valor de 48 000 bytes debe ser suficiente para la mayoría de las implementaciones. Este es el valor predeterminado en Windows Server 2012 y versiones posteriores. Sin embargo, si decide usar un valor mayor, revise los problemas conocidos de esta sección.

  • Límite de tamaño de 1010 SID de grupo para el token de acceso de LSA

    Este problema es similar en que un usuario que tiene demasiadas pertenencias a grupos no puede autenticarse, pero los cálculos y condiciones que rigen el problema son diferentes. Por ejemplo, el usuario puede encontrar este problema al usar la autenticación Kerberos o la autenticación NTLM de Windows. Para obtener más información, vea Registro en una cuenta de usuario que es miembro de más de 1010 grupos que pueden producir errores en un equipo basado en Windows Server.

  • Problema conocido al usar valores de MaxTokenSize mayores que 48 000

    Para mitigar un vector de ataque por denegación de servicio, Internet Information Server (IIS) usa un tamaño limitado del búfer de solicitudes HTTP de 64 KB. Un vale de Kerberos que forma parte de una solicitud HTTP se codifica como Base64 (6 bits expandidos a 8 bits). Por lo tanto, el vale de Kerberos usa el 133 por ciento de su tamaño original. Por lo tanto, cuando el tamaño máximo del búfer es de 64 KB en IIS, el vale de Kerberos puede usar 48 000 bytes.

    Si establece la entrada del MaxTokenSize Registro en un valor superior a 48000 bytes y el espacio de búfer se usa para los SID, puede producirse un error de IIS. Sin embargo, si establece la entrada del MaxTokenSize Registro en 48 000 bytes y usa el espacio para SID y notificaciones, se produce un error de Kerberos.

    Para obtener más información sobre los tamaños de búfer de IIS, vea Cómo limitar el tamaño del encabezado de la transmisión HTTP que IIS acepta de un cliente en Windows 2000.

  • Problemas conocidos al usar valores de MaxTokenSize mayores que 65 535

    En versiones anteriores de este artículo se describen valores de hasta 100 000 bytes para MaxTokenSize. Sin embargo, hemos detectado que las versiones del administrador de SMS tienen problemas cuando es MaxTokenSize de 100 000 bytes o más.

    También hemos identificado que el protocolo IPSEC IKE no permite que un BLOB de seguridad supere los 66 536 bytes y también produciría un error cuando MaxTokenSize se establezca en un valor mayor.