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
