Problemas con la autenticación Kerberos cuando un usuario pertenece a varios 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 KB original:   327825

Síntomas

Un usuario que pertenece a un gran número de grupos de seguridad tiene problemas para autenticarse. Al autenticar, el usuario puede ver un mensaje como HTTP 400 - Bad Request (Request Header too long). El usuario también tiene problemas para obtener acceso a los recursos y es posible que la configuración de la 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.

Nota

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

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

Causa

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

Como parte del servicio de autenticación 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 atributo de privilegios (PAC) en el vale de Ticket-Getting Kerberos (TGT). A partir Windows Server 2012, Kerberos también almacena el token en la estructura de datos de información de notificaciones de Active Directory (control de acceso dinámico) en el vale 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 está utilizando, 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, dependen del valor cuando asignan búferes para MaxTokenSize las operaciones de autenticación. MaxTokenSizetiene el siguiente valor predeterminado, según 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 versiones posteriores y Windows 8 versiones posteriores: 48 000 bytes

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

Nota

Otros factores también afectan al número máximo de grupos. Por ejemplo, los SID para grupos globales y de dominio local tienen requisitos de espacio más pequeños. Windows Server 2012 y versiones posteriores agregan información de notificación al vale 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 participa en el proceso de autenticación Kerberos, incluidos los equipos cliente. Se recomienda actualizar todos los sistemas basados 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, haga una copia de seguridad del Registro para surestauración, en caso de que se produzcan problemas.

En cada uno de estos equipos, establezca la entrada MaxTokenSize del 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 acerca de cómo determinar un nuevo valor para , vea la sección MaxTokenSize Calcular el tamaño máximo de token de este artículo.

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

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

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

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

Use la siguiente fórmula 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. El valor de sobrecarga estimado para un vale 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. La suma de los siguientes valores:
    • Número de pertenencias en grupos universales que están fuera del dominio de 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. La suma de los siguientes valores:
    • Número de pertenencias en grupos universales que están dentro del dominio de cuenta del usuario.
    • Número de pertenencias en grupos locales de dominio.
    • Número de pertenencias en 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 valor de MaxTokenSize 0x0000FFFF (64 K), puede almacenar en búfer aproximadamente 1600 SID de clase d o aproximadamente 8000 s-class SID. Sin embargo, varios otros factores influyen en el valor para el que se puede usar de forma MaxTokenSize segura, incluidos los siguientes:

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

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

  • Si está usando Windows Server 2012 una versión posterior, los siguientes factores también afectan a los requisitos de espacio sid:

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

    Importante

    En 2019, Microsoft envió actualizaciones a Windows que cambiaron la configuración predeterminada de delegación sin restricciones para Kerberos a deshabilitada. Para obtener más información, vea Updates to TGT delegation across incoming trusts in Windows Server.

    Como la compresión SID de recursos se usa ampliamente y la delegación sin restricciones está en desuso, de 48000 o más debería ser suficiente para todos MaxTokenSize 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 versiones posteriores. Sin embargo, si decide usar un valor mayor, revise los problemas conocidos de esta sección.

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

    Este problema es similar en el sentido de que un usuario que tiene demasiadas pertenencias a grupos no puede autenticarse, pero los cálculos y las condiciones que rigen el problema son diferentes. Por ejemplo, el usuario puede encontrar este problema mientras usa la autenticación Kerberos o Windows autenticación NTLM. Para obtener más información, vea Logging on a user account that is a member of more than 1,010 groups may fail on a Windows Server-based computer.

  • Problema conocido al usar valores de MaxTokenSize superiores a 48 000

    Para mitigar un vector de ataque de denegación de servicio, Internet Information Server (IIS) usa un tamaño de búfer de solicitud HTTP limitado de 64 KB. Un vale Kerberos que forma parte de una solicitud HTTP se codifica como Base64 (6 bits expandido a 8 bits). Por lo tanto, el vale 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 Kerberos puede usar 48 000 bytes.

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

    Para obtener más información acerca de los tamaños de búfer de IIS, vea How to limit the header size of the HTTP transmission that IIS accepts from a client in Windows 2000.

  • Problemas conocidos al usar valores de MaxTokenSize superiores a 65 535

    Las versiones anteriores de este artículo deba de valores de hasta 100 000 bytes para MaxTokenSize . Sin embargo, hemos encontrado que las versiones del administrador de SMS tienen problemas cuando el tamaño es MaxTokenSize de 100 000 bytes o mayor.

    También hemos identificado que el protocolo IPSEC IKE no permite que un BLOB de seguridad sea mayor que 66.536 bytes, y también produciría un error cuando se establece en un valor MaxTokenSize mayor.