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

Greg Hudson ghudson at mit.edu
Thu Aug 4 15:27:10 EDT 2022


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 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.

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 at 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 at KRBTEST1.COM
    	Ticket server: a/x.d at REFREALM

> 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?

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.


More information about the Kerberos mailing list