[19958] in Kerberos_V5_Development
Re: Spurious tickets when using DNS realm configuration (and cross
daemon@ATHENA.MIT.EDU (david@crossfamilyweb.com)
Sun Jul 28 17:08:39 2019
MIME-Version: 1.0
Date: Sun, 28 Jul 2019 17:08:13 -0400
From: <david@crossfamilyweb.com>
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <15e967bb-bae0-11e2-2c38-1b7df8c2f25c@mit.edu>
Message-ID: <13a838fe4e4216e598957705ace3af82@crossfamilyweb.com>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@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@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@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@EXAMPLE.COM for server
principal host/host.net.example.com@EXAMPLE.COM
[12050] 1564341061.206980: Getting credentials user@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@EXAMPLE.COM
07/28/2019 16:10:41 07/29/2019 16:04:49
host/host.net.example.net@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@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@EXAMPLE.COM for host/host.net.example.net@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@EXAMPLE.COM for krbtgt/EXAMPLE.NET@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@EXAMPLE.COM for
host/host.net.exaple.net@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@EXAMPLE.COM for krbtgt/EXAMPLE.ORG@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@EXAMPLE.COM for
host/host.net.example.org@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@EXAMPLE.COM
[12118] 1564342598.335092: Retrieving user@EXAMPLE.COM ->
krbtgt/EXAMPLE.COM@EXAMPLE.COM from FILE:/tmp/krb5cc_1001 with result:
0/Success
[12118] 1564342598.335093: Starting with TGT for client realm:
user@EXAMPLE.COM -> krbtgt/EXAMPLE.COM@EXAMPLE.COM
[12118] 1564342598.335094: Requesting tickets for
host/host.net.example.net@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@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@EXAMPLE.COM
[12119] 1564342613.678760: Retrieving user@EXAMPLE.COM ->
krbtgt/EXAMPLE.COM@EXAMPLE.COM from FILE:/tmp/krb5cc_1001 with result:
0/Success
[12119] 1564342613.678761: Starting with TGT for client realm:
user@EXAMPLE.COM -> krbtgt/EXAMPLE.COM@EXAMPLE.COM
[12119] 1564342613.678762: Requesting tickets for
host/host.net.example.org@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@EXAMPLE.COM differs from requested
host/host.net.example.org@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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
