Home / server / Questions / 146881
Accepted
wzzrd
Asked: 2010-06-01 07:47:01 +0800 CST

TGT validation fails, but only for one user

  • 772

I'm seeing the weirdest thing here. I have a couple of RHEL3, 4 and 5 machines that validate user credentials through Kerberos with an Active Directoy domain controller as their KDC.

This works for all of my users, save one. There is one account that is unable to log into RHEL3 Linux machines and generates the following errors there:

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'

Other accounts, like my own, are fine:

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)

As you can see, TGT validation fails. This only happens for this specific account, not for any other.

The failing useraccount's password has been reset, I inspected both user objects in Active Directory, but I see nothing out of the ordinary.

If I have the failing useraccount log into a RHEL4 or 5 box, there is not problem, so it must be RHEL3 specific, but the fact that only one account suffers from this, alludes me. Maybe someone has seen this before?

linux redhat active-directory kerberos

2 Answers

  1. Can you kinit as a working and non-working user, from the Unix box? If so, what does klist say for each?

    Once you have done that, try to use one of the tickets and see what klist shows for each then.

    If kinit works, and the tickets you get work (try ssh'ing back into the box again for instance) then something is indeed strange, and I'm not certain where to go next without being able to touch the box.

    • 0
  2. Best Answer

    I'll shamelessly answer my own question, because we found the answer. The user object that failed to authenticate had some sort of certificate in it, which made that object rather large in comparison to other user objects.

    Kerberos, which is a component of Active Directory, has a property called 'MaxTokenSize'. By default it is set to 12.000 bytes. In older versions of Active Directory it is 8.000 bytes. Most of the time you see people bumping into trouble with this, is when they put users in too many groups (somewhere in the range of 70 to 100 groups). Having user objects this big causes the MaxTokenSize to be too small for the buffer that is needed for authentication, according to this TechNet article.

    I was unable to track down any sources that talk about this problem in relation to clients running Linux, but I did find this site about OpenAFS (which uses Kerberos), that talks about tickets that are too large when using AD's Kerberos.

    To make a long story short, the user I had trouble with was not in a whole many groups, but as said, he did have a huge ass certificate in his LDAP object, which made it pretty big.

    Removing the certificate shrunk the user object enough to re-enable Kerberos authentication on RHEL3.

    • 0