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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)