[39125] in Kerberos
can realms get "aliased" when there is a one-way trust? or, what is
daemon@ATHENA.MIT.EDU (Jerry Shipman)
Thu Aug 4 13:23:15 2022
MIME-Version: 1.0
From: Jerry Shipman <jes59@cornell.edu>
Date: Thu, 4 Aug 2022 13:18:56 -0400
Message-ID: <CAOVr6ae2H024BopGyZxktCWwvcx5Ltj05OkBciahEZUSjnMJ-Q@mail.gmail.com>
To: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hello,
This might just be a microsoft implementation thing -- sorry.
But I am scratching my head and wonder if somebody can help me
understand what is going on.
We have several different realms (both MIT KDCs and AD DCs) run by
various departments. There are sometimes cross-realm trusts in one or
both directions.
There is an MIT realm (let's say MIT.FOO.CORNELL.EDU) and an AD realm
(let's say FOO.CORNELL.EDU).
MIT.FOO.CORNELL.EDU trusts FOO.CORNELL.EDU, but not vice-versa.
The users are mostly in FOO.CORNELL.EDU and the service in question
has a principal in MIT.FOO.CORNELL.EDU but not in FOO.CORNELL.EDU.
It seems that when a user tries to get a service ticket for the
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU (which doesn't exist), he will
wind up with two tickets, one for
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU and one for
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU. But this is odd, because
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU doesn't exist. I would think
that the AD KDC there would just tell the client that the principal
doesn't exist? (It seems like it is aliasing it somehow maybe? But
that seems dangerous because e.g. jes59@MIT.FOO.CORNELL.EDU and
jes59@FOO.CORNELL.EDU are probably different people.)
More succinctly:
$ kinit user@FOO.CORNELL.EDU
$ kvno afs/mit.foo.cornell.edu@FOO.CORNELL.EDU
$ klist
[...]
Valid starting Expires Service principal
08/03/2022 15:46:18 08/03/2022 22:26:13
krbtgt/FOO.CORNELL.EDU@FOO.CORNELL.EDU
08/03/2022 15:46:28 08/03/2022 22:26:13
krbtgt/MIT.FOO.CORNELL.EDU@FOO.CORNELL.EDU
08/03/2022 15:46:28 08/03/2022 22:26:13
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU # <-- this doesn't exist! why
is it here?
08/03/2022 15:46:28 08/03/2022 22:26:13
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU
A priori I would expect that my
$ kvno afs/mit.foo.cornell.edu@FOO.CORNELL.EDU
would just get a "not found in kerberos database" kind of error, since
that principal doesn't exist in that realm (only
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU exist).
If I get the trace like:
$ KRB5_TRACE=/users/jes59/trace.txt kvno
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU
It says:
[13699] 1659556399.495222: Getting credentials user@FOO.CORNELL.EDU
-> afs/mit.foo.cornell.edu@FOO.CORNELL.EDU using ccache
FILE:/tmp/krb5cc_10811
[13699] 1659556399.495223: Retrieving user@FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU from FILE:/tmp/krb5cc_10811
with result: -1765328243/Matching credential not found (filename:
/tmp/krb5cc_10811)
[13699] 1659556399.495224: Retrieving user@FOO.CORNELL.EDU ->
krbtgt/FOO.CORNELL.EDU@FOO.CORNELL.EDU from FILE:/tmp/krb5cc_10811
with result: 0/Success
[13699] 1659556399.495225: Starting with TGT for client realm:
user@FOO.CORNELL.EDU -> krbtgt/FOO.CORNELL.EDU@FOO.CORNELL.EDU
[13699] 1659556399.495226: Requesting tickets for
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU, referrals on
[13699] 1659556399.495227: Generated subkey for TGS request: aes256-cts/2FD6
[13699] 1659556399.495230: Encoding request body and padata into FAST request
[13699] 1659556399.495231: Sending request (4086 bytes) to FOO.CORNELL.EDU
[13699] 1659556399.495232: Resolving hostname [...]
[13699] 1659556399.495253: Response was not from master KDC
[13699] 1659556399.495254: Decoding FAST response
[13699] 1659556399.495255: FAST reply key: aes256-cts/13D4
[13699] 1659556399.495256: Reply server
krbtgt/MIT.FOO.CORNELL.EDU@FOO.CORNELL.EDU differs from requested
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU
[13699] 1659556399.495257: TGS reply is for user@FOO.CORNELL.EDU ->
krbtgt/MIT.FOO.CORNELL.EDU@FOO.CORNELL.EDU with session key
aes256-cts/3CE3
[13699] 1659556399.495258: TGS request result: 0/Success
[13699] 1659556399.495259: Storing user@FOO.CORNELL.EDU ->
krbtgt/MIT.FOO.CORNELL.EDU@FOO.CORNELL.EDU in FILE:/tmp/krb5cc_10811
[13699] 1659556399.495257: TGS reply is for user@FOO.CORNELL.EDU ->
krbtgt/MIT.FOO.CORNELL.EDU@FOO.CORNELL.EDU with session key
aes256-cts/3CE3
[13699] 1659556399.495258: TGS request result: 0/Success
[13699] 1659556399.495259: Storing user@FOO.CORNELL.EDU ->
krbtgt/MIT.FOO.CORNELL.EDU@FOO.CORNELL.EDU in FILE:/tmp/krb5cc_10811
[13699] 1659556399.495260: Following referral TGT
krbtgt/MIT.FOO.CORNELL.EDU@FOO.CORNELL.EDU
[13699] 1659556399.495261: Requesting tickets for
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU, referrals on
[13699] 1659556399.495265: Encoding request body and padata into FAST request
[13699] 1659556399.495266: Sending request (4085 bytes) to SERVICE
[13699] 1659556399.495267: Resolving hostname [...]
[13699] 1659556399.495270: Sending initial UDP request to dgram [...]
[13699] 1659556399.495271: Received answer (879 bytes) from dgram [...]
[13699] 1659556399.495272: Response was not from master KDC
[13699] 1659556399.495273: Decoding FAST response
[13699] 1659556399.495274: FAST reply key: aes256-cts/66E3
[13699] 1659556399.495275: TGS reply is for user@FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU with session key
aes256-cts/72F0
[13699] 1659556399.495276: TGS request result: 0/Success
[13699] 1659556399.495277: Received creds for desired service
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU
[13699] 1659556399.495278: Storing user@FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU in FILE:/tmp/krb5cc_10811
[13699] 1659556399.495279: Also storing user@FOOCORNELL.EDU ->
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU based on ticket
[13699] 1659556399.495280: Removing user@FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU from
FILE:/tmp/krb5cc_10811
[...]
I'm not sure how to read it. It got a referral, followed that. Got a
krbtgt/ to do the cross-realm trust stuff. That makes sense.
These lines seem important:
[13699] 1659556399.495256: Reply server
krbtgt/MIT.FOO.CORNELL.EDU@FOO.CORNELL.EDU differs from requested
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU
[...]
[13699] 1659556399.495277: Received creds for desired service
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU
[13699] 1659556399.495278: Storing user@FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU in FILE:/tmp/krb5cc_10811
[13699] 1659556399.495279: Also storing user@FOOCORNELL.EDU ->
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU based on ticket
But I don't know why it would think it's OK to do that?
A priori I would expect that my
$ kvno afs/mit.foo.cornell.edu@FOO.CORNELL.EDU
would just get a "not found in kerberos database" kind of error, since
that principal doesn't exist in that realm (only
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU exist).
If I instead do
$ kvno afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU
then I wind up with just:
$ klist
Valid starting Expires Service principal
08/03/2022 16:10:38 08/03/2022 22:50:33
krbtgt/FOO.CORNELL.EDU@FOO.CORNELL.EDU
08/03/2022 16:10:45 08/03/2022 22:50:33
krbtgt/MIT.FOO.CORNELL.EDU@FOO.CORNELL.EDU
08/03/2022 16:10:45 08/03/2022 22:50:33
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU
That makes sense to me.
It seems like maybe AD is aliasing
afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU to
afs/mit.foo.cornell.edu@FOO.CORNELL.EDU because I asked for it and it
didn't find it locally, and then giving me both tickets? Maybe as some
kind of misguided compatibility thing?
But isn't that dangerous, because bar@MIT.FOO.CORNELL.EDU and
bar@FOO.CORNELL.EDU are totally different entities! Why would it do
that? Is there a way to turn that off?
Or, more generally... can you help me understand what is going on there?
Thank you!
Jerry
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
