On Mon, 2006-05-22 at 17:07 -0600, John Hanks wrote:
> Since I don't have effective control of my clients I modified your
> suggestion and removed authentication methods from the server. Removing
> public-key made it so that I now get a password prompt but it still
> times out after entering the password. Removing public-key and setting
> usePAM to no makes for password failure (even with a good password.)
> 
> I'm now focused on PAM or some connecting bit as the problem. I've
> enabled debug for pam_krb5 and comparing a successful login to a broken
> attempt, I don't see any difference in kerberos messages for the two. In
> fact, watching debug messages for su'ing ot a "good" user and a "bad"
> user doesn't show any differences other that the "bad" users always have
> a long wait for *something* to time out or happen.

Pleas make sure that you have enabled syslogging of "*.debug"-type
messages - pam_krb5 is rather silent otherwise.
Some guesses:
* Could it be that your pam_krb5 is trying to get Krb4 or AFS
credentials, and that your KDC no longer provides these for newer
accounts?
* Or that your AD tries to send the reply as TCP (since the packet size
is too great, e.g. because you enabled additional enctypes), and you
block that in your client firewall?


> Other things I've noticed:
> 
> [root@edna ssh]# useradd -d /tmp/testing testing
> 
> hangs.

Interesting but could be unrelated. You should be able to "strace" that
one, I believe it is a single process. And (AFAIK) it does not use PAM.
But it might run pwconv/grpconv, which can block in case of "corrupt"
password/groups files.

> Getent works perfectly fine for "bad" accounts.
> 
> [root@edna log]# getent passwd baduser
> baduser:ABCD!efgh12345$67890:10057:10000:Bad User:/home/baduser:/bin/bash

So the LDAP/NSSwitch side is probably out of this.