Crecimiento del token Kerberos: MaxTokenSize y grupos

¿Qué es el crecimiento del token Kerberos?

El diagnóstico del crecimiento del token Kerberos y de MaxTokenSize comienza con una distinción: el número de personas de un grupo es diferente del número de SID de grupos que se transportan para una persona. La proliferación de grupos puede convertirse en un problema de disponibilidad de la autenticación, pero un hallazgo de grupo grande por sí solo no permite diagnosticarlo. Una investigación útil conecta la identidad afectada, el servicio que falla, el contexto de autorización y los límites en la ruta de autenticación de ese servicio.

Una limpieza de emergencia introduce un segundo problema. Eliminar pertenencias hasta que una aplicación vuelva a funcionar cambia el acceso sin determinar qué permisos o restricciones se han retirado. Algunas eliminaciones reducen privilegios innecesarios; otras interrumpen trabajo necesario. Una eliminación también puede debilitar un control si la pertenencia aportaba una restricción. El resultado de seguridad depende de la función real del grupo, no de si la lista de pertenencias se ha acortado.

Esta guía trata el anidamiento circular y los grupos integrados modificados como señales que deben revisarse en esa investigación. No presenta una interrupción observada ni un incidente de seguridad medido. El objetivo es una reparación que restablezca el flujo de trabajo afectado y preserve los accesos y las denegaciones aprobados.

Cómo funciona: PAC, MaxTokenSize y límites independientes

El TGT de Kerberos transporta datos de autorización en su Privilege Attribute Certificate (PAC): SID del usuario, de los grupos y de sIDHistory. Las notificaciones y la compresión de SID también afectan al espacio necesario. Importan los bytes resultantes; el número de miembros directos es una medida diferente. Microsoft KB327825 explica este mecanismo.

KB837361 documenta la configuración del Registro MaxTokenSize:

La sección de problemas conocidos de KB327825 identifica por separado un límite del token de acceso LSA de 1 010 SID de grupos, que afecta a Kerberos o NTLM. Aumentar MaxTokenSize no elimina este límite independiente. KB327825, problemas conocidos.

KB938118 indica 65 535 bytes como valor máximo permitido, pero desaconseja valores superiores a 48 000 porque la codificación HTTP Base64 amplía los datos de autenticación. Trate el máximo permitido y una configuración operativa adecuada como decisiones separadas. Aumentar un valor del Registro no elimina todas las restricciones posteriores.

El anidamiento circular es un problema de grafos

Suponga que el grupo A contiene al grupo B y el grupo B contiene al grupo A. Un recorrido personalizado que vuelve a visitar nodos sin registrarlos puede entrar en un bucle o contar visitas repetidas. Esta es una consecuencia algorítmica, no una afirmación sobre un comportamiento observado del KDC o de PowerShell. Volver al mismo grupo no crea un nuevo SID único en cada visita.

Conserve las relaciones directas entre grupos al investigar un ciclo. Un componente fuertemente conexo (SCC) identifica un conjunto de grupos que pueden alcanzarse entre sí; la topología ayuda al revisor a elegir la relación que debe eliminarse. Un hallazgo de ciclo no demuestra que el PAC de un usuario supere MaxTokenSize. El ciclo y las pertenencias efectivas excesivas pueden coexistir, pero necesitan pruebas independientes.

El anidamiento peligroso de grupos en Active Directory explica cómo la herencia oculta crea una ruta hacia Tier 0 y por qué la remediación debe identificar la relación de grupo que concede ese privilegio. Aplique esa revisión de rutas al simplificar las pertenencias, para que una reparación de disponibilidad también preserve la frontera de privilegios prevista.

Síntomas por servicio y escenario de cambio de emergencia

Microsoft documenta HTTP 400 con un encabezado de solicitud demasiado grande, fallos de acceso a recursos y problemas de actualización de la directiva de grupo del usuario. Su ejemplo cliente/IIS/SQL muestra la relevancia de las máquinas participantes para el diagnóstico. KB327825, síntomas y resolución.

Utilice la tabla siguiente como plan de investigación. Son preguntas que deben comprobarse, no firmas de error adicionales ni pruebas de que Kerberos falle aleatoriamente.

Si el mismo usuario tiene éxito en un servicio y falla en otro, conserve ambos casos. Compare sus rutas reales antes de cambiar los grupos. El caso exitoso es una prueba diagnóstica útil, pero no identifica qué límite se aplica al caso fallido. Evite sustituir esa comparación por una afirmación genérica de crecimiento intermitente del token.

Cómo eliminar un grupo puede eliminar una restricción

Considere un ejemplo condicional en una estación de trabajo Windows 10/11 cubierta por la documentación de Microsoft sobre denegar el acceso a este equipo desde la red. Un grupo de seguridad dedicado aporta SeDenyNetworkLogonRight. La configuración se encuentra en Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Microsoft documenta que esta denegación Deny prevalece sobre el permiso Allow correspondiente de acceso a la red y que los cambios de asignación se aplican en el siguiente inicio de sesión.

Suponga ahora que un operador elimina al usuario de ese grupo únicamente para reducir sus pertenencias. Si esta era la única ruta del usuario hacia Deny y sigue existiendo un Allow, el siguiente contexto de autorización pierde esa restricción. Es una inferencia condicional a partir del comportamiento documentado de la directiva, no un informe de incidente. No demuestra que todos los recursos compartidos o archivos sean ahora accesibles: todavía deben comprobarse otras ACL y denegaciones. Verifique la aplicabilidad antes de extender este ejemplo de estación de trabajo a otros sistemas.

La documentación de Microsoft sobre grupos de seguridad explica que los grupos pueden aportar derechos de usuario y permisos sobre recursos. Antes de eliminar una relación o un miembro, registre ambas funciones. El nombre de un grupo por sí solo no basta para decidir si la eliminación reduce privilegios, rompe un acceso necesario o elimina una restricción.

La deriva del acceso privilegiado en Active Directory explica cómo las excepciones temporales sin responsables, vencimiento y revalidación pueden recrear derechos mediante grupos y ACL. Utilice la misma disciplina de referencia para las reparaciones urgentes, especialmente cuando un flujo de trabajo fallido motive una concesión de acceso compensatoria.

Detección: recopilar pertenencias, rutas y contexto de advertencias

Paso 1: crear un registro para cada servicio afectado

Registre el usuario, las versiones de cliente y servidor, el servicio/SPN, el MaxTokenSize efectivo de cada participante, la población de grupos/SID, sIDHistory, las notificaciones o el contexto de delegación, el fallo exacto y cualquier advertencia pertinente. Preserve las pruebas antes de editar. Distinga un fallo observado de una estimación, un hallazgo de postura del directorio y una nueva prueba exitosa.

El Event ID 31 puede advertir sobre un umbral configurado de tickets grandes en Windows Server 2012 y posteriores. Actívelo mediante Computer Configuration\Administrative Templates\System\KDC\Warning for large Kerberos tickets. No demuestra que se haya superado MaxTokenSize; correlaciónelo con el servicio que falla. KB327825, resolución.

Registre el umbral real de advertencia y si esa directiva está habilitada. El pasaje de la fuente no proporciona un umbral numérico universal. La ausencia de la advertencia no es un resultado de validación de la cuenta.

Paso 2: inventariar los grupos de la entidad de seguridad

La siguiente es la instrucción del ejemplo 2 de Get-ADPrincipalGroupMembership, citada como comando documentado. Estos comandos no se ejecutaron en un entorno AD para este artículo; sustituya la identidad de ejemplo por una cuenta resuelta dentro de su ámbito.

Get-ADPrincipalGroupMembership -Identity Administrator

El cmdlet requiere un catálogo global. Microsoft documenta ResourceContextServer para buscar grupos locales en otro dominio. Compruebe el contexto del recurso en lugar de suponer que el dominio de la propia cuenta explica toda la ruta del servicio. Los objetos de grupo devueltos sirven para un inventario; no miden los bytes del ticket.

Paso 3: preservar las relaciones directas antes de aplanar los resultados

Esta consulta de pertenencia directa utiliza los parámetros documentados de Get-ADGroupMember:

Get-ADGroupMember -Identity "Enterprise Admins"

Como comparación, el ejemplo 4 de Microsoft incluye miembros alcanzados a través de grupos secundarios:

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive

Microsoft describe la salida recursiva como los miembros terminales de la jerarquía. Conserve las relaciones directas por separado para explicar una ruta o un ciclo. Una salida aplanada no puede explicar por sí sola qué relación proporciona un derecho. La documentación también identifica una limitación para los miembros de otro bosque sin Active Directory Web Service.

Para una vista transitiva de SID dirigida, Microsoft documenta el atributo calculado tokenGroups (atributo Token-Groups), recuperado con una consulta LDAP de ámbito BASE sobre la entidad de seguridad y con un catálogo global disponible. Es una operación costosa para los controladores de dominio. Empiece por las cuentas afectadas en lugar de realizar consultas amplias y repetidas. Su población de SID es una prueba útil, pero sigue sin ser un contador de bytes del PAC.

Remediación: simplificar grupos sin perder controles aprobados (Remediation)

Paso 1: establecer la referencia y la reversión

Guarde las pertenencias directas, las relaciones entre grupos y la población transitiva de las cuentas afectadas. Registre los responsables de grupos, los usos de recursos, los derechos de usuario, las restricciones aprobadas, la configuración de búferes y las aplicaciones afectadas. Documente el cambio previsto y una reversión antes de eliminar pertenencias. Los comandos anteriores de solo lectura ayudan a realizar este inventario; no autorizan una eliminación.

Revise los grupos integrados frente a una referencia organizativa mantenida. Microsoft documenta funciones legítimas para grupos como Event Log Readers incluso cuando su pertenencia predeterminada está vacía. Un miembro nuevo puede ser intencionado. Sin una referencia mantenida, revise la justificación del responsable en lugar de considerar maliciosa la adición en sí.

Paso 2: eliminar dependencias innecesarias y romper ciclos erróneos

Identifique la relación exacta que crea un ciclo o una dependencia obsoleta. Confirme sus usos con el responsable, elimine solo la relación aprobada y preserve los permisos y las denegaciones necesarios. Aplanar significa simplificar la arquitectura de grupos; no significa asignar cada usuario directamente en la ACL de cada recurso.

Separe los roles de negocio de los grupos de recursos y asigne a ambos responsables y fechas de revisión. Compruebe si el nuevo diseño realmente reduce las pertenencias efectivas innecesarias. Reorganizar nombres de grupos o anidamientos sin reducir la población de SID pertinente no demuestra que el contexto de autenticación sea menor.

Paso 3: utilizar MaxTokenSize como medida provisional acotada

Si la investigación demuestra un límite de búfer, considere un cambio controlado de configuración junto con la limpieza estructural. KB938118 documenta la directiva en Computer Configuration\Policies\Administrative Templates\System\Kerberos, denominada Set maximum Kerberos SSPI context token buffer size. Especifica habilitar la directiva e introducir 48000. Para su procedimiento de preferencia del Registro, elija REG_DWORD y entrada decimal.

Compare primero ese valor con la configuración efectiva. Establecer 48 000 en una máquina que ya utiliza 48 000 no aumenta la capacidad. Siga los requisitos documentados de reinicio tras la aplicación, conserve una reversión y revise las restricciones HTTP. No trate 65 535 como la recomendación predeterminada ni suponga que un cambio solo en el controlador de dominio resuelve una ruta con varios participantes.

Paso 4: probar los accesos y las denegaciones necesarios

Vuelva a conectar las cuentas piloto y pruebe de nuevo cada servicio afectado. Verifique las acciones de negocio aprobadas, las restricciones que deben permanecer y cualquier concesión compensatoria introducida durante la interrupción. Compare las pertenencias y las relaciones directas antes y después. Observe de nuevo el fallo real y el contexto de advertencia.

La desaparición de un hallazgo de tamaño o de ciclo es una prueba útil de postura, pero no una prueba completa de aceptación del servicio. Cierre la reparación cuando tanto el flujo de trabajo afectado como el modelo de acceso coincidan con el objetivo documentado. Preserve las excepciones con responsables y fechas de revisión para comparar los cambios posteriores con la misma referencia.

Cómo detecta EtcSec este problema

El etc-collector de EtcSec ofrece seis comprobaciones pertinentes de postura del directorio. Sus predicados exactos se muestran a continuación. Las cuatro comprobaciones de tamaño cuentan miembros directos, no el tamaño del token. Ninguna de las seis comprobaciones cuenta los SID de grupos transitivos de un usuario, mide los bytes del PAC, lee MaxTokenSize o demuestra un fallo de autenticación.

El sufijo CRITICAL corresponde a la gravedad real High, y HIGH corresponde a la gravedad real Medium. Estos umbrales de miembros directos son políticas del colector, no límites de autenticación de Microsoft. Los predicados de tamaño no filtran explícitamente entre grupos de seguridad y de distribución.

Sus poblaciones se solapan: GROUP_EXCESSIVE_MEMBERS cubre tanto las poblaciones de 101–500 como las de >500 miembros; OVERSIZED_GROUP_HIGH es un subconjunto de OVERSIZED_GROUP. No sume sus recuentos como grupos distintos ni describa cuatro riesgos de crecimiento del token probados independientemente. Mostrar solo los cinco grupos más grandes en los detalles de miembros excesivos no limita el recuento total de hallazgos.

La comprobación circular cuenta los grupos implicados, no los ciclos ni los usuarios con fallos. Su grafo conserva solo los grupos conocidos recopilados y normaliza los nombres distinguidos. Puede omitir un ciclo que pase por un dominio no recopilado. El resultado localiza relaciones que deben revisarse, no la causa de un fallo de Kerberos.

Qué significa realmente la referencia de grupos integrados

BUILTIN_MODIFIED utiliza búsquedas exactas del sAMAccountName en inglés. Sus listas no vacías aceptan Administrator, Domain Admins y Enterprise Admins para Administrators; Domain Users, Authenticated Users e INTERACTIVE para Users; y Guest y Domain Guests para Guests.

Sus nueve listas vacías abarcan Remote Desktop Users, Network Configuration Operators, Performance Monitor Users, Performance Log Users, Distributed COM Users, IIS_IUSRS, Cryptographic Operators, Event Log Readers y Certificate Service DCOM Access. Un CN extraído de uno de estos grupos puede activar la comprobación aunque la adición respalde trabajo legítimo.

La comparación acepta una igualdad sin distinguir mayúsculas y minúsculas o una coincidencia de subcadena con un nombre esperado. Omite los DN de miembros sin CN extraído y no verifica el SID ni el contenedor del grupo. Los nombres localizados, los cambios de nombre, los grupos homónimos y los CN que contienen un nombre esperado limitan la interpretación. No detecta miembros esperados ausentes, inspecciona cambios de ACL ni compara el historial de cambios de una organización.

Utilice este hallazgo para solicitar un responsable, una justificación y una comparación con la referencia local. La respuesta correcta es una decisión de pertenencia revisada, no una purga automática. Combine los seis hallazgos con las pruebas de servicio recopiladas anteriormente para decidir qué cambiar y cómo validarlo.