[24916] in Kerberos
Re: Kerberos referrals
daemon@ATHENA.MIT.EDU (Josh Howlett)
Thu Nov 10 02:04:40 2005
Message-ID: <43725AAB.2030002@bristol.ac.uk>
Date: Wed, 09 Nov 2005 20:23:07 +0000
From: Josh Howlett <josh.howlett@bristol.ac.uk>
MIME-Version: 1.0
To: "Douglas E. Engert" <deengert@anl.gov>
In-Reply-To: <43724D05.3090703@anl.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
Douglas E. Engert wrote:
> First of all see:
> http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-06.txt
I've already seen that. FWIW, see also
http://www.cs.washington.edu/homes/mikesw/papers/xrealm.pdf, which I
found a bit more digestable.
>> Of particular interest to me is that the MIT implementation permits
>> referral of requests for unknown realms to a "default" KDC, with the
>> assumption that this other KDC knows what to do with the request. I
>> believe that the purpose of this is to enable the construction of a
>> multiple-level hierarchy of KDCs, with a root KDC at the top from
>> which all realms are reachable.
>>
>> This is well and good, but in a typical environment the clients (W2K
>> clients) will only talk in the first instance to a W2K KDC, and these
>> KDCs do not permit the configuration referral to a "default" KDC in
>> the event that the realm of the server principal is unknown.
>>
>
> I was under the impressions that the referral is to the KDC of the
> user principal. AD would then use its Global Catalog to look up
> the realm of the service.
That's correct. If the GC doesn't know the realm, I assume the Windows
KDC returns an error.
> So the Umich mods, (that I have not seen and did not know existed
> but am interested in) may have intended the default realm to be an AD
> forest.
Yes, this looks likely given the documentation available.
> So if the user principal realm does not support referrals, it would try
> try the default realm. For example user realm is using an MIT KDC,
> but the service is in AD. These two have cross realm trust setup.
>
>> Therefore, in order to permit referral of clients to a "default" KDC
>> and the construction of an arbitrary multi-level hierarchy, it would
>> appear necessary to intercept and service the application ticket
>> request from the client *before* it reaches the Windows KDC (because
>> it will simply return an error). This implies a "kerberos proxy"
>> agent, which is transparent for local realm requests, but catches
>> non-local realm requests and forwards them to the KDC which handles
>> these remote realms.
>
> No, client tries KDC of user's realm. If it gives a referral then its done.
> If not it tries the default realm,using cross realm TGT andit works.
Yes, *if* the user's realm KDC is MIT because it can generate a
"default" referral. If the user's KDC is Windows, it doesn't have the
concept of a "default" referral. Hence, the idea of an "MIT referral
KDC" shim between the user and the user's Windows KDC.
> Use cross realm so you don't need a proxy agent.
I hope I've explained that I don't think this is possible in the
scenario I've outlined above...
> Where are the UMich mods?
http://www.citi.umich.edu/u/kwc/krb5stuff/referrals.html
best regards, josh.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
