Hi Jeffrey,

On Mon, 2017-07-10 at 07:23 -0400, Jeffrey Altman wrote:
> On 7/10/2017 4:49 AM, Andreas Haupt wrote:
> > On Fri, 2017-07-07 at 15:01 -0400, Jeffrey Altman wrote:
> > > 
> > > On 7/4/2017 3:05 AM, Andreas Haupt wrote:
> > > I would like to see more of the log entries that follow as well as a
> > > packet capture.  There is not enough detail here to say what is going
> > > on.
> > Do you mean a tcpdump capture or something else like wireshark? From the
> > client or from the KDC?
> A packet capture from the client would be fine.

OK, I do that later. Any preferences like wireshark or tcpdump with specific
options?

> The client is asking for a cross-realm ticket.  It is most likely doing
> so because the local configuration provides for [domain_realm] mappings
> and the ssh client (which you refer to later) is trying to connect to a
> host in .cern.ch.

Indeed, the behaviour changes, if one removes the [domain_realm] mapping. It
looks like this then:

Jul 10 13:27:36 fred-vm1 kdc[12044]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for host/lxplus040.cern...@ifh.de [canonicalize, renewable, 
forwardable]
Jul 10 13:27:36 fred-vm1 kdc[12044]: Searching referral for lxplus040.cern.ch
Jul 10 13:27:36 fred-vm1 kdc[12044]: Server not found in database: 
krbtgt/cern...@ifh.de: Success


Learned something new here: just thought, the domain_realm stuff only helps
the client find the correct realm for hosts located in a domain (e.g. when
this domain lacks the "_kerberos" TXT record in its zone definition).

> Heimdal is not finding a cross-realm ticket. Therefore it is failing the
> request.  The question is what is the response and why is the MIT
> Kerberos client concluding it must try again?

My general question is rather this one: The KDC tries some referral/cross-
realm stuff all the time. But whereas it gives back a real error in cases
like this ("no such entry found in hdb" which results in "Failed building
TGS-REP to IPv4:141.34.15.17"):

Jul 10 10:32:42 fred-vm1 kdc[13458]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for afs/ifh...@ifh.de [canonicalize, renewable, forwardable]
Jul 10 10:32:42 fred-vm1 kdc[13458]: Searching referral for ifh.de
Jul 10 10:32:42 fred-vm1 kdc[13458]: Server not found in database: 
krbtgt/d...@ifh.de: no such entry found in hdb
Jul 10 10:32:42 fred-vm1 kdc[13458]: Failed building TGS-REP to 
IPv4:141.34.15.17


... it "succeeds" in the CERN.CH case:

Jul 10 13:27:36 fred-vm1 kdc[12044]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for host/lxplus040.cern...@ifh.de [canonicalize, renewable, 
forwardable]
Jul 10 13:27:36 fred-vm1 kdc[12044]: Searching referral for lxplus040.cern.ch
Jul 10 13:27:36 fred-vm1 kdc[12044]: Server not found in database: 
krbtgt/cern...@ifh.de: Success

"Server not found" == "Success"? Is this really the expected answer? I would
guess, no - but not really sure ...

> > > > OK. But I just see that kind of logs during AS-REQ. We have an
> > integration
> > with AFS using a heimdal-7.3 client here.
> What is the relationship of the afs/ifh...@ifh.de request to the
> cross-realm request?

This client is located in the AFS cell "ifh.de". We still only have the
"old-style" principal named a...@ifh.de, whereas the client always asks for
the "new-style" principal afs/<cell>@REALM first. Was this what you asked
for?

> > In the end we only have a cross-realm trust with the realm DESY.DE here.
> > So,
> > if possible we could disable any cross-realm stuff for the rest of the
> > world. We nether had to care about that before, though.
> There is no cross-realm principal for CERN.CH therefore there is no
> cross-realm configuration.

Yes.

Cheers,
Andreas
-- 
| Andreas Haupt            | E-Mail: andreas.ha...@desy.de
|  DESY Zeuthen            | WWW:    http://www-zeuthen.desy.de/~ahaupt
|  Platanenallee 6         | Phone:  +49/33762/7-7359
|  D-15738 Zeuthen         | Fax:    +49/33762/7-7216


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to