can realms get "aliased" when there is a one-way trust? or, what is going on here?

Thu Aug 4 13:18:56 EDT 2022

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 at FOO.CORNELL.EDU (which doesn't exist), he will
wind up with two tickets, one for
afs/mit.foo.cornell.edu at FOO.CORNELL.EDU and one for
afs/mit.foo.cornell.edu at MIT.FOO.CORNELL.EDU. But this is odd, because
afs/mit.foo.cornell.edu at 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 at MIT.FOO.CORNELL.EDU and
jes59 at FOO.CORNELL.EDU are probably different people.)

More succinctly:
  $ kinit user at FOO.CORNELL.EDU
  $ kvno afs/mit.foo.cornell.edu at 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 at FOO.CORNELL.EDU
  08/03/2022 15:46:28  08/03/2022 22:26:13
krbtgt/MIT.FOO.CORNELL.EDU at FOO.CORNELL.EDU
  08/03/2022 15:46:28  08/03/2022 22:26:13
afs/mit.foo.cornell.edu at 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 at MIT.FOO.CORNELL.EDU

A priori I would expect that my
  $ kvno afs/mit.foo.cornell.edu at 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 at MIT.FOO.CORNELL.EDU exist).

If I get the trace like:
  $ KRB5_TRACE=/users/jes59/trace.txt kvno
afs/mit.foo.cornell.edu at FOO.CORNELL.EDU
It says:
  [13699] 1659556399.495222: Getting credentials user at FOO.CORNELL.EDU
-> afs/mit.foo.cornell.edu at FOO.CORNELL.EDU using ccache
FILE:/tmp/krb5cc_10811
  [13699] 1659556399.495223: Retrieving user at FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu at FOO.CORNELL.EDU from FILE:/tmp/krb5cc_10811
with result: -1765328243/Matching credential not found (filename:
/tmp/krb5cc_10811)
  [13699] 1659556399.495224: Retrieving user at FOO.CORNELL.EDU ->
krbtgt/FOO.CORNELL.EDU at FOO.CORNELL.EDU from FILE:/tmp/krb5cc_10811
with result: 0/Success
  [13699] 1659556399.495225: Starting with TGT for client realm:
user at FOO.CORNELL.EDU -> krbtgt/FOO.CORNELL.EDU at FOO.CORNELL.EDU
  [13699] 1659556399.495226: Requesting tickets for
afs/mit.foo.cornell.edu at 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 at FOO.CORNELL.EDU differs from requested
afs/mit.foo.cornell.edu at FOO.CORNELL.EDU
  [13699] 1659556399.495257: TGS reply is for user at FOO.CORNELL.EDU ->
krbtgt/MIT.FOO.CORNELL.EDU at FOO.CORNELL.EDU with session key
aes256-cts/3CE3
  [13699] 1659556399.495258: TGS request result: 0/Success
  [13699] 1659556399.495259: Storing user at FOO.CORNELL.EDU ->
krbtgt/MIT.FOO.CORNELL.EDU at FOO.CORNELL.EDU in FILE:/tmp/krb5cc_10811
  [13699] 1659556399.495257: TGS reply is for user at FOO.CORNELL.EDU ->
krbtgt/MIT.FOO.CORNELL.EDU at FOO.CORNELL.EDU with session key
aes256-cts/3CE3
  [13699] 1659556399.495258: TGS request result: 0/Success
  [13699] 1659556399.495259: Storing user at FOO.CORNELL.EDU ->
krbtgt/MIT.FOO.CORNELL.EDU at FOO.CORNELL.EDU in FILE:/tmp/krb5cc_10811
  [13699] 1659556399.495260: Following referral TGT
krbtgt/MIT.FOO.CORNELL.EDU at FOO.CORNELL.EDU
  [13699] 1659556399.495261: Requesting tickets for
afs/mit.foo.cornell.edu at 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 at FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu at 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 at MIT.FOO.CORNELL.EDU
  [13699] 1659556399.495278: Storing user at FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu at FOO.CORNELL.EDU in FILE:/tmp/krb5cc_10811
  [13699] 1659556399.495279: Also storing user at FOOCORNELL.EDU ->
afs/mit.foo.cornell.edu at MIT.FOO.CORNELL.EDU based on ticket
  [13699] 1659556399.495280: Removing user at FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu at 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 at FOO.CORNELL.EDU differs from requested
afs/mit.foo.cornell.edu at FOO.CORNELL.EDU
  [...]
  [13699] 1659556399.495277: Received creds for desired service
afs/mit.foo.cornell.edu at MIT.FOO.CORNELL.EDU
  [13699] 1659556399.495278: Storing user at FOO.CORNELL.EDU ->
afs/mit.foo.cornell.edu at FOO.CORNELL.EDU in FILE:/tmp/krb5cc_10811
  [13699] 1659556399.495279: Also storing user at FOOCORNELL.EDU ->
afs/mit.foo.cornell.edu at 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 at 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 at MIT.FOO.CORNELL.EDU exist).

If I instead do
  $ kvno afs/mit.foo.cornell.edu at 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 at FOO.CORNELL.EDU
  08/03/2022 16:10:45  08/03/2022 22:50:33
krbtgt/MIT.FOO.CORNELL.EDU at FOO.CORNELL.EDU
  08/03/2022 16:10:45  08/03/2022 22:50:33
afs/mit.foo.cornell.edu at MIT.FOO.CORNELL.EDU
That makes sense to me.

It seems like maybe AD is aliasing
afs/mit.foo.cornell.edu at MIT.FOO.CORNELL.EDU to
afs/mit.foo.cornell.edu at 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 at MIT.FOO.CORNELL.EDU and
bar at 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