[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
> ..
>
>


--------------------------------------------------------------------------------


>
>
>