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 [email protected] from IPv4:141.34.15.17 for host/[email protected] [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/[email protected]: 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 [email protected] from IPv4:141.34.15.17 for afs/[email protected] [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/[email protected]: 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 [email protected] from IPv4:141.34.15.17 for host/[email protected] [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/[email protected]: 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/[email protected] 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 [email protected], 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: [email protected] | DESY Zeuthen | WWW: http://www-zeuthen.desy.de/~ahaupt | Platanenallee 6 | Phone: +49/33762/7-7359 | D-15738 Zeuthen | Fax: +49/33762/7-7216
smime.p7s
Description: S/MIME cryptographic signature
