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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
