[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
behavior.
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
difference:
# 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 > 195.113.46.63.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:
NOT WORJKING CLIENT:
# tcpdump -l -n | grep 250
tcpdump: listening on ef0
09:27:52.768159 195.113.56.250.3503 > 195.113.56.251.750: v5 (DF)
09:27:52.768335 195.113.56.251 > 195.113.56.250: icmp: 195.113.56.251 udp port 750 unreachable (DF)
09:27:52.771899 195.113.56.250.3504 > 195.113.56.251.750: v5 (DF)
09:27:52.772051 195.113.56.251 > 195.113.56.250: icmp: 195.113.56.251 udp port 750 unreachable (DF)
09:27:52.773497 195.113.56.250.3505 > 195.113.56.251.750: v5 (DF)
09:27:52.773570 195.113.56.251 > 195.113.56.250: icmp: 195.113.56.251 udp port 750 unreachable (DF)
WORKING CLIENT:
# tcpdump -l -n | grep 36
tcpdump: listening on ef0
09:29:51.614529 195.113.46.36.1359 > 195.113.56.251.88: v5 (DF)
09:29:51.627638 195.113.56.251.88 > 195.113.46.36.1359: 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