[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Very long pam_acct_mgmt times on Suse SLES9 with heimdal 0.6.1rc3,w2k3 kdc and Openssh-3.8p1
I have also captured the trafiic on port 88. In the attached file Frame 20
is the AS-REQ which contains some strange BER errors (assuming the ethereal
0.10.3 disector is correct) at the end of the packet. The reply from the
w2k3 kdc to this AS-REQ is Frame 21 with Kerberos record of length 0.
A simple kinit command has instead of the BER error the lifetime, renewable
time, nonce, encryption types and addresses.
Is this a problem in heimdals implementation or in pam_krb5 ?
Thanks
Markus
"Markus Moeller" <huaraz@moeller.plus.com> wrote in message
devg74$qda$1@sea.gmane.org">news:devg74$qda$1@sea.gmane.org...
> Hi,
>
> I see on my SLES9 system with ssh a long waiting time during login. I have
> a setup with a Windows 2003 kdc and in my krb5.conf I have the following
> entries:
>
> DOMAIN.COM = {
> kdc = tcp/kdc1.domain.com:88
> kdc = tcp/kdc2.domian.com:88
> kdc = tcp/kdc3.domain.com:88
> kdc = tcp/kdc4.domian.com:88
> kdc = tcp/kdc5.domain.com:88
> kdc = tcp/kdc6.domain.com:88
> kdc = tcp/kdc7.domain.com:88
> }
>
> and /etc/security/pam_unix2.conf
>
> auth: use_krb5
> account: use_krb5
> password:
> session: none
>
>
> when I now login with ssh it takes up to a minute to login. I traced it
> back to pam_sm_acct_mgmt calling
>
> krc = krb5_get_in_tkt(context,
> 0,
> NULL,
> NULL,
> NULL,
> (krb5_key_proc) fail,
> NULL,
> (krb5_decrypt_proc) fail,
> NULL,
> &increds,
> NULL,
> rep);
>
>
> which calls at the end krb5_sendto, send_recv_tcp and recv_loop.
> krb5_sendto loops over the 7 kdc each 3 times.
> I think it should have left the loop already after the first kdc at the
> following point:
> if(ret == 0 && receive->length != 0)
> goto out;
>
> In my case receive->length is 0 why the loop continued. But if I look
> into send_recv_tcp I see two calls to recv_loop. The first gets 4 bytes,
> which get decoded to a length of 0, so the next recv_loop call returns
> correctly 0 bytes, but the above statement doesn't allow for this case. Is
> this a bug in krb5_sendto ?
>
> Thanks
> Markus
>
> Attached is send_to_kdc.c with the print statements.
>
> send_recv_tcp: rep_len=4
> recv_loop: timeout 3
> recv_loop: after while ret=0,limit=4,rep->length=4
> send_recv_tcp: rep_len=0
> recv_loop: timeout 3
> recv_loop: select ret=0,limit=0,time=0
> krb5_sendto: Loop=1, ret=0,receive->length=0
>
> send_recv_tcp: rep_len=4
> recv_loop: timeout 3
> recv_loop: after while ret=0,limit=4,rep->length=4
> send_recv_tcp: rep_len=0
> recv_loop: timeout 3
> recv_loop: select ret=0,limit=0,time=0
> krb5_sendto: Loop=2, ret=0,receive->length=0
>
> send_recv_tcp: rep_len=4
> recv_loop: timeout 3
> recv_loop: after while ret=0,limit=4,rep->length=4
> send_recv_tcp: rep_len=0
> recv_loop: timeout 3
> recv_loop: select ret=0,limit=0,time=0
> krb5_sendto: Loop=3, ret=0,receive->length=0
>
> send_recv_tcp: rep_len=4
> recv_loop: timeout 3
> recv_loop: after while ret=0,limit=4,rep->length=4
> send_recv_tcp: rep_len=0
> recv_loop: timeout 3
> recv_loop: select ret=0,limit=0,time=0
> krb5_sendto: Loop=4, ret=0,receive->length=0
> ..
>
>
--------------------------------------------------------------------------------
>
>
>