Compartir a través de


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.

Número de KB original: 327825

Síntomas

Un usuario que pertenece a un gran número de grupos de seguridad tiene problemas al 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 Solicitudes incorrectas (encabezado de solicitud demasiado largo) respuestas a solicitudes HTTP.

Nota:

En condiciones similares, la autenticación NTLM de Windows funciona según lo previsto. 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 directiva de grupo.

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

Causa

El usuario no se puede autenticar 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 que se almacenan 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 obtención de vales (TGT) de Kerberos. 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 si hay muchas notificaciones para el usuario o el dispositivo que se está usando, estos campos pueden ocupar una gran cantidad de 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 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 compile 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 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 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

Pueden producirse problemas graves si modifica el Registro de manera incorrecta. Antes de modificarlo, realice una copia de seguridad del registro para la 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 deben 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 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 de SQL Server de back-end. En este caso, tendría que configurar la entrada del MaxTokenSize Registro en cada uno de los equipos siguientes:

  • Equipo cliente que ejecuta Internet Explorer
  • El servidor web que se ejecuta que ejecuta IIS
  • Equipo cliente de SQL Server
  • Equipo de base de datos de 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 la configuración de directiva de grupo Configuración del equipo\Plantillas administrativas\System\KDC\Warning 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 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 valores siguientes:
    • Número de pertenencias a grupos universales que están fuera del dominio de cuenta del usuario.
    • Número de SID almacenados en el atributo de sIDHistory la cuenta. Este valor cuenta las pertenencias a grupos y los SID de usuario.
  • s. La suma de los valores siguientes:
    • Número de pertenencias en grupos universales que están dentro del dominio de 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), puede almacenar en búfer aproximadamente 1600 SID de clase d o aproximadamente 8000 SID de clase s. Sin embargo, varios otros factores influyen en el valor que 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 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 de SID:

    • Hay un nuevo esquema para comprimir los SID en el PAC. Para obtener más información, consulte Compresión de SID de recursos de 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 eliminar gradualmente un número significativo de grupos que controlan el acceso a archivos. Esta reducción puede reducir a su vez el tamaño necesario en el vale. Para obtener más información, consulte Control de acceso dinámico: Información general sobre escenarios.
  • 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 delegación sin restricciones para Kerberos a deshabilitada. Para obtener más información, vea Actualizaciones de la delegación de TGT en las confianzas entrantes en Windows Server.

    Dado que la compresión de SID de recursos se usa ampliamente y la delegación sin restricciones está en desuso, MaxTokenSize de 48000 o mayor 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 se puede autenticar, 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 Iniciar sesión en una cuenta de usuario que sea miembro de más de 1010 grupos puede producir un error en un equipo basado en Windows Server.

  • Problema conocido al usar valores de MaxTokenSize mayores de 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 solicitud HTTP limitado de 64 KB. Un vale kerberos que forma parte de una solicitud HTTP se codifica como Base64 (6 bits expandidos a 8 bits). Por lo tanto, el vale kerberos usa el 133 % 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 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 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 trataron los valores de hasta 100 000 bytes para MaxTokenSize. Sin embargo, hemos encontrado que las versiones del administrador de SMS tienen problemas cuando es MaxTokenSize de 100 000 bytes o superior.

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