Spurious tickets when using DNS realm configuration (and cross realm TGT)

Sun Jul 28 17:08:13 EDT 2019

On 2019-07-24 12:28, Greg Hudson wrote:
> On 7/24/19 2:13 AM, David Cross wrote:
>> Specifically if I auth as user at REALM and klist I see my tgt as 
>> expected. If i then ssh to a host and klist I get 2 tickets:
>> host/foo@
>> host/foo at REALM
> 
> This is expected, and results from not having a [domain_realm] map 
> entry
> for the server host.  (Using DNS realm configuration shouldn't affect
> this one way or another.)  Because the realm of the server is not 
> known,
> the initial principal we request credentials for is host/foo@, and we
> don't find out that the actual name is host/foo at REALM until we get the
> ticket.  We need to cache the result under host/foo@ or we would make a
> repeat query the next time around.
> 

Ok, I have definitely confirmed that adding a domain_map entry alters 
this behavior (no 'blank' realm entries), but it *should* be able to 
determine the host in question, and this set from KRB5_TRACE suggests it 
does, but then promptly forgets?:

[12050] 1564341061.206976: TXT record _kerberos.host.net.example.com. 
not found
[12050] 1564341061.206977: TXT record _kerberos.net.example.com. not 
found
[12050] 1564341061.206978: TXT record _kerberos.example.com. found: 
EXAMPLE.COM
[12050] 1564341061.206979: ccselect module realm chose cache 
FILE:/tmp/krb5cc_1001 with client principal user at EXAMPLE.COM for server 
principal host/host.net.example.com at EXAMPLE.COM
[12050] 1564341061.206980: Getting credentials user at EXAMPLE.COM -> 
host/host.net.example.com@ using ccache FILE:/tmp/krb5cc_1001

^^^^^^^^^^^^^^^^^^^^^^^^^^^      ????

Additionally, in investigating this I noticed something weird (I have 3 
realms setup, with a fully connected graph between them), when doing 
cross-realm authentication I notice I sometimes get cross-realm TGTs.. 
and other times I don't (but it works in all cases).  If I do or do not 
is deterministic based on the relationship requested.

Given the realms:
   EXAMPLE.COM
   EXAMPLE.NET
   EXAMPLE.ORG

If I am authenticated to EXAMPLE.COM and request a host key for a host 
in  EXAMPLE.NET I get a cross realm TGT *and* the host key:
07/28/2019 16:10:41  07/29/2019 16:04:49  krbtgt/EXAMPLE.NET at EXAMPLE.COM
07/28/2019 16:10:41  07/29/2019 16:04:49  
host/host.net.example.net at EXAMPLE.NET

If I request a host key for a host in EXAMPLE.ORG I do *NOT* get a cross 
realm TGT, just the host key (and it works):
07/28/2019 16:05:07  07/29/2019 16:04:49  
host/host.net.example.org at EXAMPLE.ORG

The logs on the kdc (this is a single KDC process serving all 3 realms, 
it is configured with 3 separate principal databases, and 3 distinct 
kadmin/kpasswd processes) show the following:

For the first case (cross realm TGT issued):  (this is what I would 
expect)

Jul 28 19:48:39 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.1.7.155: LOOKING_UP_SERVER: authtime 0,  
user at EXAMPLE.COM for host/host.net.example.net at EXAMPLE.COM, Server not 
found in Kerberos database
Jul 28 19:48:39 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.1.7.155: ISSUE: authtime 1564343215, etypes {rep=19 
tkt=19 ses=19}, user at EXAMPLE.COM for krbtgt/EXAMPLE.NET at EXAMPLE.COM
Jul 28 19:48:39 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.1.7.155: ISSUE: authtime 1564343215, etypes {rep=19 
tkt=19 ses=19}, user at EXAMPLE.COM for 
host/host.net.exaple.net at EXAMPLE.NET

For the second case I see:

Jul 28 19:47:31 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.1.7.155: ISSUE: authtime 1564343215, etypes {rep=19 
tkt=19 ses=19}, user at EXAMPLE.COM for krbtgt/EXAMPLE.ORG at EXAMPLE.COM
Jul 28 19:47:31 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.1.7.155: ISSUE: authtime 1564343215, etypes {rep=19 
tkt=19 ses=19}, user at EXAMPLE.COM for 
host/host.net.example.org at EXAMPLE.ORG

This has apparently short-circuited the cross realm evaluation and not 
even returned it to the client just handing back the end ticket?  The 
KRB5_TRACE logs seem to confirm this (cross realm TGT in client cache):

[12118] 1564342598.335091: Server has referral realm; starting with 
host/host.net.example.net at EXAMPLE.COM
[12118] 1564342598.335092: Retrieving user at EXAMPLE.COM -> 
krbtgt/EXAMPLE.COM at EXAMPLE.COM from FILE:/tmp/krb5cc_1001 with result: 
0/Success
[12118] 1564342598.335093: Starting with TGT for client realm: 
user at EXAMPLE.COM -> krbtgt/EXAMPLE.COM at EXAMPLE.COM
[12118] 1564342598.335094: Requesting tickets for 
host/host.net.example.net at EXAMPLE.COM, referrals on
[12118] 1564342598.335095: Generated subkey for TGS request: 
aes128-sha2/FB2D
[12118] 1564342598.335096: etypes requested in TGS request: aes256-cts, 
aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, 
camellia128-cts, camellia256-cts
[12118] 1564342598.335098: Encoding request body and padata into FAST 
request
[12118] 1564342598.335099: Sending request (987 bytes) to EXAMPLE.COM
[12118] 1564342598.335100: Sending DNS URI query for 
_kerberos.EXAMPLE.COM.
[12118] 1564342598.335101: URI answer: 10 1 
"krb5srv:m:tcp:kerberos.example.com"
[12118] 1564342598.335102: Resolving hostname kerberos.example.com
[12118] 1564342598.335107: Response was from master KDC
[12118] 1564342598.335108: Decoding FAST response
***[12118] 1564342598.335109: TGS request result: -1765328377/Server 
host/host.net.example.net at EXAMPLE.COM not found in Kerberos database

No cross realm TGT:
[12119] 1564342613.678759: Server has referral realm; starting with 
host/host.net.example.org at EXAMPLE.COM
[12119] 1564342613.678760: Retrieving user at EXAMPLE.COM -> 
krbtgt/EXAMPLE.COM at EXAMPLE.COM from FILE:/tmp/krb5cc_1001 with result: 
0/Success
[12119] 1564342613.678761: Starting with TGT for client realm: 
user at EXAMPLE.COM -> krbtgt/EXAMPLE.COM at EXAMPLE.COM
[12119] 1564342613.678762: Requesting tickets for 
host/host.net.example.org at EXAMPLE.COM, referrals on
[12119] 1564342613.678763: Generated subkey for TGS request: 
aes128-sha2/C16E
[12119] 1564342613.678764: etypes requested in TGS request: aes256-cts, 
aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, 
camellia128-cts, camellia256-cts
[12119] 1564342613.678766: Encoding request body and padata into FAST 
request
[12119] 1564342613.678767: Sending request (993 bytes) to EXAMPLE.COM
[12119] 1564342613.678768: Sending DNS URI query for 
_kerberos.EXAMPLE.COM.
[12119] 1564342613.678769: URI answer: 10 1 
"krb5srv:m:tcp:kerberos.example.org"
[12119] 1564342613.678770: Resolving hostname kerberos.example.org
[12119] 1564342613.678775: Response was from master KDC
[12119] 1564342613.678776: Decoding FAST response
[12119] 1564342613.678777: FAST reply key: aes128-sha2/4277
***[12119] 1564342613.678778: Reply server 
krbtgt/EXAMPLE.ORG at EXAMPLE.COM differs from requested 
host/host.net.example.org at EXAMPLE.COM

So it gets the cross realm TGT, and then doesn't save it? after being 
short-circuit evaluated in the KDC?

I do not (that I remember, or can find) have any CAPATHS setup on either 
the client or the server.  The only thing that
seems unifying is that the 'home' realm for the KDC is EXAMPLE.ORG (it 
is kerberos.example.org).

Thank you for your time in helping me unravel this and ensure I am setup 
correctly; I had tried the normal googling of results and not come up 
with many hits.