[16622] in Kerberos_V5_Development
Re: KDC query client performance
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Feb 14 13:36:28 2011
From: Greg Hudson <ghudson@mit.edu>
To: "Henry B. Hotz" <hotz@jpl.nasa.gov>
In-Reply-To: <C0518AC3-67A8-4826-B3E7-49865ED2AD53@jpl.nasa.gov>
Date: Mon, 14 Feb 2011 13:36:23 -0500
Message-ID: <1297708583.5931.55.camel@t410>
Mime-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Mon, 2011-02-14 at 13:14 -0500, Henry B. Hotz wrote:
> Agree with the eventual goal. Maybe it's just me, but I'm not yet
> comfortable with depending on referrals instead of the traditional
> realm/domain-walk. Wouldn't want it turned off by default until
> Solaris 10 clients support referral tickets by default (which I
> haven't checked).
We wouldn't be relying on service principal referrals. We'd be relying
on the behavior where if you ask a KDC for krbtgt/OTHERREALM@LOCALREALM,
the KDC performs the realm walk internally (or uses its own capaths
configuration) and responds with an intermediate TGT. That KDC logic
has been implemented since at least MIT krb5 1.1 and probably every
release of Heimdal and Active Directory.
I'm not sure how Solaris 10 client behavior would have an impact on this
anyway, since we're not talking about changing KDC logic.
To elaborate, let's say you're in the realm MY.HOME.REALM.COM and you
try to "ssh dialup.far.off.org", where far.off.org has never heard of
Kerberos and certainly has no mapping in your client's domain_realm
profile. Currently we will try referrals first (so we'll query
host/dialup.far.off.org@LOCALREALM with referrals).
When that comes up empty we'll guess that the machine might be in the
FAR.OFF.ORG realm and query for krbtgt/FAR.OFF.ORG@MY.HOME.REALM.COM.
That part's great and we'll keep doing it. What we don't want is for
the client to keep trying intermediate realm candidates:
krbtgt/OFF.ORG@MY.HOME.REALM.COM
krbtgt/ORG@MY.HOME.REALM.COM
krbtgt/COM@MY.HOME.REALM.COM
krbtgt/REALM.COM@MY.HOME.REALM.COM
krbtgt/HOME.REALM.COM@MY.HOME.REALM.COM
These queries are all pointless; we have high confidence that the KDC
already searched for those principals when the client made its initial
krbtgt query.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
