To: kerberos@mit.edu

On 8/4/22 13:18, Jerry Shipman wrote:

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.

Kerberos has the concept of "referrals" for TGS requests, which are
defined in RFC 6806. If the FOO.CORNELL.EDU KDC finds that afs/mit.foo.cornell.edu doesn't exist in its database, but can determine
that it should be in MIT.FOO.CORNELL.EDU, then instead of issuing a
service ticket, it may issue a cross-realm TGT for MIT.FOO.CORNELL.EDU.
The client will then follow the referral to MIT.FOO.CORNELL.EDU and get
a afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU ticket.

How the result is cached depends on the client software. For MIT krb5,
prior to 1.18 the resulting ticket is cached under both the requested
name and the final ticket service name. In 1.18 and later the ticket is
only cached under the requested name, but klist shows the ticket service
name if it differs, like this:

08/04/22 14:52:52 08/05/22 14:50:28 a/x.d@KRBTEST1.COM
Ticket server: a/x.d@REFREALM

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?

The theory behind referrals is that service principal names are
generally unique across realms, because they incorporate FQDNs. So a
client looking for a ticket for afs/mit.foo.cornell.edu generally
doesn't need to know which realm takes responsibility for authenticating
that name; its KDC can make that decision.

Client names are of course much less likely to be unique across realms;
"fred" may refer to a completely different user in different realms even
if they have cross-realm relationships.

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