On Tue, 2006-05-23 at 08:44 +0200, Jan Iven wrote:
> 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?
In the case of su, there is no ticket. The messages that result are the
same for both "good" and "bad" accounts, good accounts work and bad
accounts hang and wait for something for a long time.
> * 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?
I can't see anything getting blocked at the firewall and I don't think
any of my firewall setup would be user specific in any way.
>
> > 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.
Good idea. When I tried to strace "su - baduser' it forked and did too
much to keep track of. An strace of adduser hangs at some type of LDAP
lookup (tail of 'strace adduser tester' is:
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
[those two lines are repeated many times...]
select(1024, [5], [], NULL, NULL
[hangs there for a long time...]
read(5, "", 5) = 0
brk(0x6b6000) = 0x6b6000
[more stuff happens that I've snipped...]
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
write(2, "adduser: ../../../libraries/libl"...,
113adduser: ../../../libraries/liblber/io.c:171: ber_free_buf: Assertion
`((ber)->ber_opts.lbo_valid==0x2)' failed.
) = 113
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(8875, 8875, SIGABRT) = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++
During the time that the process hangs netstat shows:
tcp 0 0 129.123.x.x:49545 129.123.y.y:636
ESTABLISHED 8875/adduser
So it is apparantly waiting for an LDAP response from one of my DCs.
> > 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.
Looks like I'll be switching back to non-SSL LDAP to try to find out for sure.
jbh
|
