[16624] in Kerberos_V5_Development
Re: KDC query client performance
daemon@ATHENA.MIT.EDU (Henry B. Hotz)
Mon Feb 14 14:10:23 2011
Mime-Version: 1.0 (Apple Message framework v1082)
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
In-Reply-To: <1297708583.5931.55.camel@t410>
Date: Mon, 14 Feb 2011 11:10:17 -0800
Message-Id: <CFA2FBCF-42D0-4B33-A440-E8EEE9093155@jpl.nasa.gov>
To: Greg Hudson <ghudson@mit.edu>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Thanks for the clarification, especially of the client/KDC overlap. That reduces my discomfort considerably.
On Feb 14, 2011, at 10:36 AM, Greg Hudson wrote:
> 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.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
