Re: Weird cross-realm behaviour after upgrade to Heimdal 7.3

[Jeffrey Altman]

On 7/10/2017 4:49 AM, Andreas Haupt wrote:
> 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?

A packet capture from the client would be fine.

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

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.

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?

>>> 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.

What is the relationship of the afs/ifh...@ifh.de request to the
cross-realm request?
> 
> 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.

There is no cross-realm principal for CERN.CH therefore there is no
cross-realm configuration.

Jeffrey Altman

smime.p7s
Description: S/MIME Cryptographic Signature