[OpenAFS] Re: aklog claims it can't contact KDC, but KDC is issuing tickets
Adam Megacz
megacz@cs.berkeley.edu
Wed, 08 Mar 2006 00:03:29 -0800
Jeffrey Altman <jaltman@secure-endpoints.com> writes:
> Diagnosis: Firewall configuration blocks in bound UDP traffic from
> YOUR-REALM KDC
>
> Now this could be a broken NAT. It would be a NAT that is incapable
> of opening a port to allow traffic from two source addresses at the
> same time. If this was the case, then you can perform the following
> experiment:
>
> * kinit *****@EECS.BERKELEY.EDU
> * kvno krbtgt/RESEARCH.CS.BERKELEY.EDU@EECS.BERKELEY.EDU
> * aklog -d -c research.cs.berkeley.edu
> and see if that works. What this will do is force the acquisition
> of the cross-realm TGT to use a different port on the client machine
> than the one that is used for the afs service ticket request. If this
> does not work, then the problem is a firewall rule or a routing issue.
> ...
> Each time you bind a socket your are assigned a new port.
> If the socket is used to send two packets, they will both have
> the same source port.
Fascinating; before he was getting:
Kerberos error code returned by get_cred: -1765328228
Now, using 'kvno', he gets:
About to resolve name johnw@EECS.BERKELEY.EDU to id in cell research.cs.berkeley.edu.
Id ******
Set username to AFS ID ******
Setting tokens. AFS ID ****** / @ EECS.BERKELEY.EDU
aklog: unable to obtain tokens for cell research.cs.berkeley.edu (status: 11862790).
> Have the user traceroute (or tracert on Windows) to the KDC and see
> what happens.
It goes through (on MacOS, using UDP packets).
- a
--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380