[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems finding KDC

Thank you for the response.

> Well it sure sounds like some OS problem. It does work for us with
> 5.0A. What I know differs is that they finally integrated IPv6 in 5.1,
> so it might have something to do with that.

I used "--without-ipv6" configure option, too. There is no change in

I actually really do not understand what's happening there. I made another
try to connect with heimdal kinit against krb4 kerberos daemon:

./kinit komanek
komanek@NATUR.CUNI.CZ's Password:
kinit: krb5_get_init_creds: Initial Ticket response appears to be Version 4

So it means communication goes out of my box and reaches the destination
server. But using heimdal server instead:

./kinit komanek
komanek@NATUR.CUNI.CZ's Password:
kinit: krb5_get_init_creds: unable to reach any KDC in realm NATUR.CUNI.CZ

In the latter case, "par" is showing no activity on the "kdc" process
(except timing loops, of course). But by connecting from non-tru64unix
box, "par" shows significant activity.

> Did you try tcpdump?

Good advice, thanks. Here are the results from the target (server) side

08:46:55.015457 lib-eth.natur.cuni.cz.1682 > pteryx.natur.cuni.cz.kerberos-iv:v5 (DF)
08:46:55.019045 lib-eth.natur.cuni.cz.1683 > pteryx.natur.cuni.cz.kerberos-iv:v5 (DF)
08:46:55.021411 lib-eth.natur.cuni.cz.1684 > pteryx.natur.cuni.cz.kerberos-iv:v5 (DF)

The number of packets if 3 and it is the same as the number of connect()
calls on the client side. The ":v5" in the name of the protocol is
apparently taken from inside of tcpdump, because in /etc/services I have

kerberos        88/tcp                          # Kerberos V
kerberos        88/udp                          # Kerberos V
kerberos-iv     750/udp         kdc     # Kerberos IV (server) udp

But, when using kinit from working SUSE Linux workstation, there is a big

# tcpdump -l udp | grep fis
tcpdump: listening on ef0
09:05:44.777187 fis.natur.cuni.cz.1359 > pteryx.natur.cuni.cz.kerberos:  v5 (DF)
09:05:44.787575 pteryx.natur.cuni.cz.kerberos > fis.natur.cuni.cz.1359:  v5
09:06:42.869531 fis.natur.cuni.cz.16001 > udp 76 (DF)

So my opinion is:

tru64unix box uses udp/750 for communication and it fails
working clients use udp/88 for communication and it works

Is it right according to results listed above ? I think so:

# tcpdump -l -n | grep 250
tcpdump: listening on ef0
09:27:52.768159 >  v5 (DF)
09:27:52.768335 > icmp: udp port 750 unreachable (DF)
09:27:52.771899 >  v5 (DF)
09:27:52.772051 > icmp: udp port 750 unreachable (DF)
09:27:52.773497 >  v5 (DF)
09:27:52.773570 > icmp: udp port 750 unreachable (DF)

# tcpdump -l -n | grep 36
tcpdump: listening on ef0
09:29:51.614529 >  v5 (DF)
09:29:51.627638 >  v5

Now my question is, what causes this difference ? I browsed heimdal code
and saw it makes decision on how to communicate (ports, udp vs. tcp) but I
do not understand it much deeply. It seems to me the decission is made in
krb5_krbhst_init(), but I do not see anythig there what could force the
client to use port udp/750. On the other way, kdc/connect.c forces kdc to
use port 750 only if krb4 support is enabled, so I do not understand why
should kinit try to connect there if also compiled with no krb4 support.
Since I am trying to use kinit from machine where are no krb4 libraries, I
am pretty sure it does not support krb4 at all.

Do you have some ideas what could be wrong ?

With best regards,

  David Komanek