Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
Is the name of the user possibly conflicting with some system account? –  Janne Pikkarainen Aug 26 '10 at 7:13

2 Answers 2

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.

share|improve this answer
up vote 0 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.