Kerberos referrals

[Saber Zrelli]

Hello ,

* On 13:24, Wed 09 Nov 05, Douglas E. Engert wrote:
> 
> 
> Josh Howlett wrote:
> 
> >Kerberos referrals have been implemented in Heimdal and MIT (with a 
> >patch from UMich) and, of course, Windows.
> >
> 
> >My understanding is that Kerberos referrals are used to permit 
> >cross-realm authentication against remote realms that are not explicitly 
> >configured in the client's configuration.
> >
> 
> First of all see:
> http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-06.txt


I read this draft and I am trying to understand how referrals work.

In section 8. "Cross realm routingi", It is said that for server
referrals, the KDC takes in charge the optimization of the referral
path because it has more information about cross-realm routing.

Does this mean that the KDC will provide the client with a TGT and
the target realm (where the service is located) in the
PA-SERVER-REFERRAL of the reply ?

Regards,
Saber.
> 
> 
> >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.
> 
> 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.
> 
> 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.
> 
> 
> 
> >Does this make sense? Is it feasible? Or have I completely lost my marbles?
> >
> >I'm aware that there are some significant practical difficulties with 
> >this approach (ie. how does the proxy agent retrieve the user's secret 
> >from the Windows KDC to generate a valid referral?). If anyone can point 
> >out any more pitfalls, I would be very grateful so I can stop wasting my 
> >time on this :-)
> 
> Use cross realm  so you don't need a proxy agent.
> 
> Where are the UMich mods?
> 
> 
> >
> >Many thanks, josh.
> >________________________________________________
> >Kerberos mailing list           Kerberos at mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
> 
> -- 
> 
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

-- 
Saber ZRELLI <zrelli at jaist.ac.jp>
Japan Advanced Institute of Science and Technology
Center of Information Science
Shinoda Laboratory
url     : http://www.jaist.ac.jp/~zrelli
gpg-id  : 0x7119EA78