Kerberos es esencialmente solo para autenticación, no autorización; Sin embargo, la estructura de datos del ticket tiene un campo para información de autorización, en caso de que un implementador quiera codificar dicha información en una credencial. Las implementaciones de Unix de Kerberos casi nunca han dejado de usar este campo, pero Microsoft optó por usarlo e incorpora un "certificado de atributo de privilegio" (PAC) en los tickets que emite información de seguridad sobre la cuenta de AD a la que corresponde el cliente Kerberos principal: grupo membresías, etc. Esto va no solo en el TGT, sino en cualquier boleto emitido por AD. La ventaja de esto es que los servidores que reciben estos tickets conocen de inmediato estos atributos de usuario de manera confiable, y no tienen que consultar AD por separado para descubrirlos. Un aspecto negativo es que si las cosas como las membresías de un grupo cambian, un usuario necesita obtener un nuevo ticket para que se refleje (y generalmente se les dice que "cierre la sesión y vuelva a iniciar sesión" para lograrlo). Y, por supuesto, si elimina a alguien de un grupo, eso no es completamente efectivo hasta que todos los tickets del usuario hayan caducado.
Mi objetivo: ayudar a identificar al mayor infractor que está causando que el ticket TGT sea más grande que el límite máximo establecido en nuestro servidor de Apache.
Apache no tiene un "tamaño máximo de ticket". La autenticación Kerberos ocurre en los encabezados HTTP intercambiados por el cliente y el servidor, y el ticket del servicio está codificado en ellos y, por lo tanto, aumenta a medida que aumenta el número de miembros del grupo. Apache tiene un límite de tamaño predeterminado en los encabezados, que es bajo en comparación con los posibles tamaños de tickets AD (8K). Solo puede aumentarla con la directiva Apache LimitRequestFieldSize .