Estoy viendo la cosa más rara aquí. Tengo un par de máquinas RHEL3, 4 y 5 que validan las credenciales de usuario a través de Kerberos con un controlador de dominio Active Directory como KDC.
Esto funciona para todos mis usuarios, excepto uno. Hayunocuenta que no puede iniciar sesión en máquinas RHEL3 Linux y genera los siguientes errores allí:
May 31 13:53:19 mybox sshd(pam_unix)[7186]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.1 user=user
May 31 13:53:20 mybox sshd[7186]: pam_krb5: TGT verification failed for `user'
May 31 13:53:20 mybox sshd[7186]: pam_krb5: authentication fails for `user'
Otras cuentas, como la mía, están bien:
May 31 17:25:30 mybox sshd(pam_unix)[12913]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.1 user=myuser
May 31 17:25:31 mybox sshd[12913]: pam_krb5: TGT for myuser successfully verified
May 31 17:25:31 mybox sshd[12913]: pam_krb5: authentication succeeds for `myuser'
May 31 17:25:31 mybox sshd(pam_unix)[12915]: session opened for user myuser by (uid=0)
Como puede ver, la validación de TGT falla. Esto sólo ocurre para esta cuenta específica, no para ninguna otra.
La contraseña de la cuenta de usuario fallida se restableció. Inspeccioné ambos objetos de usuario en Active Directory, pero no veo nada fuera de lo común.
Si tengo la cuenta de usuario defectuosa iniciando sesión en un cuadro RHEL4 o 5, no hay problema, por lo que debe ser específico de RHEL3, pero el hecho de que solo una cuenta sufre esto, me alude. ¿Quizás alguien haya visto esto antes?
Respuesta1
¿Puede usted, kinitcomo usuario que trabaja y no, desde la caja de Unix? Si es así, ¿qué klistdice para cada uno?
Una vez que haya hecho eso, intente usar uno de los boletos y vea qué muestra klist para cada uno.
Si kinitfunciona y los boletos que recibe funcionan (intente volver a ingresar a la caja, por ejemplo), entonces algo es realmente extraño y no estoy seguro de adónde ir a continuación sin poder tocar la caja.
Respuesta2
Responderé descaradamente a mi propia pregunta, porque encontramos la respuesta. El objeto de usuario que no pudo autenticarse tenía algún tipo de certificado, lo que hacía que ese objeto fuera bastante grande en comparación con otros objetos de usuario.
Kerberos, que es un componente de Active Directory, tiene una propiedad llamada 'MaxTokenSize'. Por defecto está configurado en 12.000 bytes. En versiones anteriores de Active Directory es de 8.000 bytes. La mayoría de las veces que ves que las personas tienen problemas con esto es cuando colocan a los usuarios en demasiados grupos (entre 70 y 100 grupos). Tener objetos de usuario tan grandes hace que MaxTokenSize sea demasiado pequeño para el búfer necesario para la autenticación, segúneste artículo de TechNet.
No pude localizar ninguna fuente que hablara sobre este problema en relación con clientes que ejecutan Linux, pero encontréeste sitiosobre OpenAFS (que usa Kerberos), que habla de tickets que son demasiado grandes cuando se usa Kerberos de AD.
Para resumir, el usuario con el que tuve problemas no estaba en muchos grupos, pero como dije, tenía un certificado enorme en su objeto LDAP, lo que lo hacía bastante grande.
La eliminación del certificado redujo el objeto de usuario lo suficiente como para volver a habilitar la autenticación Kerberos en RHEL3.