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/[email protected] (which doesn't exist), he will
wind up with two tickets, one for
afs/[email protected] and one for afs/[email protected]. But this is odd, because afs/[email protected] 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. [email protected] and [email protected] are probably different people.)

More succinctly:
$ kinit [email protected]
$ kvno afs/[email protected]
$ klist
[...]
Valid starting Expires Service principal
08/03/2022 15:46:18 08/03/2022 22:26:13 krbtgt/[email protected]
08/03/2022 15:46:28 08/03/2022 22:26:13 krbtgt/[email protected]
08/03/2022 15:46:28 08/03/2022 22:26:13 afs/[email protected] # <-- this doesn't exist! why
is it here?
08/03/2022 15:46:28 08/03/2022 22:26:13 afs/[email protected]

A priori I would expect that my
$ kvno afs/[email protected]
would just get a "not found in kerberos database" kind of error, since
that principal doesn't exist in that realm (only afs/[email protected] exist).

If I get the trace like:
$ KRB5_TRACE=/users/jes59/trace.txt kvno afs/[email protected]
It says:
[13699] 1659556399.495222: Getting credentials [email protected]

afs/[email protected] using ccache

FILE:/tmp/krb5cc_10811
[13699] 1659556399.495223: Retrieving [email protected] -> afs/[email protected] from FILE:/tmp/krb5cc_10811
with result: -1765328243/Matching credential not found (filename: /tmp/krb5cc_10811)
[13699] 1659556399.495224: Retrieving [email protected] -> krbtgt/[email protected] from FILE:/tmp/krb5cc_10811
with result: 0/Success
[13699] 1659556399.495225: Starting with TGT for client realm: [email protected] -> krbtgt/[email protected]
[13699] 1659556399.495226: Requesting tickets for afs/[email protected], 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/[email protected] differs from requested afs/[email protected]
[13699] 1659556399.495257: TGS reply is for [email protected] -> krbtgt/[email protected] with session key
aes256-cts/3CE3
[13699] 1659556399.495258: TGS request result: 0/Success
[13699] 1659556399.495259: Storing [email protected] -> krbtgt/[email protected] in FILE:/tmp/krb5cc_10811
[13699] 1659556399.495257: TGS reply is for [email protected] -> krbtgt/[email protected] with session key
aes256-cts/3CE3
[13699] 1659556399.495258: TGS request result: 0/Success
[13699] 1659556399.495259: Storing [email protected] -> krbtgt/[email protected] in FILE:/tmp/krb5cc_10811
[13699] 1659556399.495260: Following referral TGT krbtgt/[email protected]
[13699] 1659556399.495261: Requesting tickets for afs/[email protected], 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 [email protected] -> afs/[email protected] with session key
aes256-cts/72F0
[13699] 1659556399.495276: TGS request result: 0/Success
[13699] 1659556399.495277: Received creds for desired service afs/[email protected]
[13699] 1659556399.495278: Storing [email protected] -> afs/[email protected] in FILE:/tmp/krb5cc_10811
[13699] 1659556399.495279: Also storing [email protected] -> afs/[email protected] based on ticket
[13699] 1659556399.495280: Removing [email protected] -> afs/[email protected] 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/[email protected] differs from requested afs/[email protected]
[...]
[13699] 1659556399.495277: Received creds for desired service afs/[email protected]
[13699] 1659556399.495278: Storing [email protected] -> afs/[email protected] in FILE:/tmp/krb5cc_10811
[13699] 1659556399.495279: Also storing [email protected] -> afs/[email protected] 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/[email protected]
would just get a "not found in kerberos database" kind of error, since
that principal doesn't exist in that realm (only afs/[email protected] exist).

If I instead do
$ kvno afs/[email protected]
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/[email protected]
08/03/2022 16:10:45 08/03/2022 22:50:33 krbtgt/[email protected]
08/03/2022 16:10:45 08/03/2022 22:50:33 afs/[email protected]
That makes sense to me.

It seems like maybe AD is aliasing
afs/[email protected] to afs/[email protected] 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 [email protected] and [email protected] 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)