[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