Hi Jeffrey,

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?

No, the KDC does not log more than that in this case - looks it the client
retries 7 times:

Jul 10 10:40:07 fred-vm1 kdc[12044]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for krbtgt/cern...@ifh.de [renewable, forwardable]
Jul 10 10:40:07 fred-vm1 kdc[12044]: Server not found in database: 
krbtgt/cern...@ifh.de: Success
Jul 10 10:40:08 fred-vm1 kdc[13458]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for krbtgt/cern...@ifh.de [renewable, forwardable]
Jul 10 10:40:08 fred-vm1 kdc[13458]: Server not found in database: 
krbtgt/cern...@ifh.de: Success
Jul 10 10:40:09 fred-vm1 kdc[13458]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for krbtgt/cern...@ifh.de [renewable, forwardable]
Jul 10 10:40:09 fred-vm1 kdc[13458]: Server not found in database: 
krbtgt/cern...@ifh.de: Success
Jul 10 10:40:12 fred-vm1 kdc[12044]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for krbtgt/cern...@ifh.de [renewable, forwardable]
Jul 10 10:40:12 fred-vm1 kdc[12044]: Server not found in database: 
krbtgt/cern...@ifh.de: Success
Jul 10 10:40:13 fred-vm1 kdc[12047]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for krbtgt/cern...@ifh.de [renewable, forwardable]
Jul 10 10:40:13 fred-vm1 kdc[12047]: Server not found in database: 
krbtgt/cern...@ifh.de: Success
Jul 10 10:40:18 fred-vm1 kdc[12047]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for krbtgt/cern...@ifh.de [renewable, forwardable]
Jul 10 10:40:18 fred-vm1 kdc[12047]: Server not found in database: 
krbtgt/cern...@ifh.de: Success
Jul 10 10:40:19 fred-vm1 kdc[12047]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for krbtgt/cern...@ifh.de [renewable, forwardable]
Jul 10 10:40:19 fred-vm1 kdc[12047]: Server not found in database: 
krbtgt/cern...@ifh.de: Success


> > This answer seems to make the client think the KDC is somehow
> > malfunctioning
> > and repeats the request with any KDC combination (all KDCs it finds in
> > /etc/krb5.conf on ports 88 and 750 here). Of course, it causes long
> > timeouts
> > before the ssh client gives up and asks for a password.
> > 
> > Any idea to restore the old "Heimdal-1.2-style" behaviour? Is this
> > considered a bug or misconfiguration?
> I can't tell you since I don't have enough information.
> 
> What is MYREALM?

IFH.DE

> What is the client?

lx64.zeuthen.desy.de (an SL7 system). It's the system's ssh client, so
linked to MIT kerberos version krb5-libs-1.14.1-26.el7.x86_64

> What is the configuration of the client?

Broke it down to a one-kdc setup on the client to illustrate the problem:

---
[libdefaults]
        default_realm = IFH.DE
        ticket_lifetime = 25h
        renew_lifetime = 30d
        forwardable = true
        noaddresses = true
        krb4_convert = false
        allow_weak_crypto = true

[realms]
        IFH.DE = {
                kdc = kdc1.zeuthen.desy.de
                admin_server = kdc1.zeuthen.desy.de
        }

[domain_realm]
        .ifh.de = IFH.DE
        .zeuthen.desy.de = IFH.DE
        .desy.de = DESY.DE
        .cern.ch = CERN.CH
---

> What is the configuration of the KDC?

---
[libdefaults]
        default_realm = IFH.DE
        ticket_lifetime = 25h
        renew_lifetime = 30d
        forwardable = true
        allow_weak_crypto = true

[realms]
        IFH.DE = {
                kdc = kdc1.zeuthen.desy.de
                admin_server = kdc1.zeuthen.desy.de
        }

[domain_realm]
        .ifh.de  = IFH.DE
        .zeuthen.desy.de = IFH.DE
        .desy.de = DESY.DE
        .cern.ch = CERN.CH

[kadmin]
        default_keys = v5

[kdc]
        require-preauth = true
---

> My guess is the difference in behavior is related to Kerberos Referrals
> and/or implicit hierarchical  capaths both of which are not present in
> 1.2.

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.

Jul 10 10:32:42 fred-vm1 kdc[13458]: AS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for krbtgt/ifh...@ifh.de
Jul 10 10:32:42 fred-vm1 kdc[13458]: Client sent patypes: REQ-ENC-PA-REP
Jul 10 10:32:42 fred-vm1 kdc[13458]: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ
Jul 10 10:32:42 fred-vm1 kdc[12047]: AS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for krbtgt/ifh...@ifh.de
Jul 10 10:32:42 fred-vm1 kdc[12047]: Client sent patypes: ENC-TS, REQ-ENC-PA-REP
Jul 10 10:32:42 fred-vm1 kdc[12047]: ENC-TS pre-authentication succeeded -- 
aha...@ifh.de
Jul 10 10:32:42 fred-vm1 kdc[12047]: Client supported enctypes: 
aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha384-192, 
aes128-cts-hmac-sha256-128, des3-cbc-sha1, des3-cbc-md5, arcfour-hmac-md5, 
des-cbc-md5, des-cbc-md4, des-cbc-crc, using 
aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96
Jul 10 10:32:42 fred-vm1 kdc[12047]: Requested flags: renewable, forwardable
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 [renewable, forwardable]
Jul 10 10:32:42 fred-vm1 kdc[13458]: Server not found in database: 
afs/ifh...@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
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
Jul 10 10:32:42 fred-vm1 kdc[12047]: TGS-REQ aha...@ifh.de from 
IPv4:141.34.15.17 for a...@ifh.de [renewable, forwardable]


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.

Thanks,
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