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.

Versión original del producto:   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, es posible que el usuario vea un mensaje como HTTP 400 - Solicitud mala (el encabezado de solicitud es 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 acerca del contexto del error, vea respuestas HTTP 400 Bad Request (Request Header too long) a solicitudes HTTP.

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 la configuración de la directiva de grupo.

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 la hoja de hechos del ciclo de vida de Windows.

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 a grupos del usuario.

Como parte del servicio de autenticación de 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 privilegio (PAC) en el vale 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 (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. MaxTokenSize tiene el siguiente valor predeterminado, dependiendo 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 no crea un búfer lo suficientemente grande como para MaxTokenSize contener la información. El usuario no puede autenticarse y puede recibir un mensaje sin memoria. Además, es posible que Windows no pueda aplicar la configuración de directiva de grupo al 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 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, haga una copia de seguridad del Registropara su restauració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 back-end SQL Server datos. 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 en ejecución que ejecuta IIS
  • El SQL Server cliente
  • El equipo SQL Server base de datos

En Windows Server 2012 (y versiones posteriores), Windows puede 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.

Calcular el tamaño máximo del token

Usa 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. Suma de los siguientes valores:
    • El número de pertenencias a grupos universales que están fuera del dominio de la cuenta del usuario.
    • El 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:
    • El número de pertenencias a grupos universales que están dentro del dominio de cuenta del usuario.
    • El número de pertenencias a grupos locales de dominio.
    • El 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.

Si tienes un valor de MaxTokenSize 0x0000FFFF (64K), es posible que puedas almacenar en búfer aproximadamente 1600 SID d -class o aproximadamente 8000 s-class SID. Sin embargo, hay otros factores que influyen en el valor que se puede usar de forma MaxTokenSize segura, incluidos los siguientes:

  • Si usa la 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 Kerberos.

  • Si usa Windows Server 2012 o 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 Compresión SID de recursos KDC. 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 con servidores de archivos de Windows Server 2012, puede esperar que se descontrole 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 Control de acceso dinámico: Información general sobre escenarios.
  • Si ha configurado Kerberos para usar la 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, consulta Actualizaciones de la delegación TGT en las confianzas entrantes en 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 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 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 encontrarse con este problema mientras usa la autenticación Kerberos o la autenticación NTLM de Windows. Para obtener más información, vea El registro en una cuenta de usuario que es miembro de más de 1.010grupos puede producir errores en un equipo basado en Windows Server.

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

    Para mitigar un vector de ataque por denegación de servicio, Internet Information Server (IIS) usa un tamaño de búfer de solicitudes 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 se usa el espacio de búfer para LOS SID, puede producirse un MaxTokenSize error de IIS. Sin embargo, si establece la entrada del Registro en 48.000 bytes y usa el espacio para SID y notificaciones, se produce un MaxTokenSize error de Kerberos.

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

  • Problemas conocidos al usar valores de MaxTokenSize superiores a 65.535

    En versiones anteriores de este artículo se deba a 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 más.

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