Josh Howlett wrote:
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.
This may be the real problem. If there was a way to update the GC to go
to the default realm. Hey its LDAP. I asked around, and it looks like it
could be possible but no one knows how to do it.
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.
So you want the proxy to trap all AD ticket requests! The proxy would also
have to know the TGT keys used for the realm. I don't think that would be
very easy either technically or politically.
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.
See above comments on updating GC.
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
Kevin sent me a note on this as well.
A quick glance of the patch show only the KDC side. What I was
hoping for was the client side code. What I would like to see is the MIT
or Heimdal client libraries be able to request a server referral rather
then using the [domain_realm] (or if not found in the domain realm try
referrals.)
We use AD for all the users and many services, but still have an MIT KDC
for some unix services. Conversion is going to be a problem and we are
seeing some services in the same DNS domain but in different Kerberos
realms.
If we get rid of the MIT KDC, then we don't have a GC problem,
as all services are in the AD forest, and thus can be found by the GC.
But we have the problem of clients using MIT or Heimdal libs that don't
know how to do a referral. That is more of a problem to us then the
KDC side.
best regards, josh.
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
