Kerberos referrals

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Kerberos referrals

Josh Howlett
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.

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.

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.

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 :-)

Many thanks, josh.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Douglas E. Engert


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


> 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           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Josh Howlett
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Kevin Coffman
In reply to this post by Douglas E. Engert
We started with a patch that assumed all referrals would go to one place.

We had a need to send referrals to either a test Windows forest or a
production forest.  That is where the [domain_referral] stuff came
from.  Then we found that some requests were coming in without
fully-qualified names, and therefore we could not determine the
"right" place for the referral.  For those requests, we send the
referral to the default place, which in our case is to the production
forest.

Our patches are here: http://www.citi.umich.edu/u/kwc/krb5stuff/referrals.html

The page will be updated soon with a patch for 1.4.2, but the 1.3.4
patch applied rather cleanly last night while doing the cvs merge to
1.4.2.


On 11/9/05, Douglas E. Engert <[hidden email]> 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
>
>
> > 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           [hidden email]
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
>
> --
>
>   Douglas E. Engert  <[hidden email]>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Mike Friedman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 9 Nov 2005 at 15:36 (-0500), Kevin Coffman wrote:

> Our patches are here: http://www.citi.umich.edu/u/kwc/krb5stuff/referrals.html
>
> The page will be updated soon with a patch for 1.4.2, but the 1.3.4
> patch applied rather cleanly last night while doing the cvs merge to
> 1.4.2.

Kevin,

I've been using your referrals patch for about 4 years now and last August
I updated our KDC to 1.4.2.  So, I had to update the patch as well. Aside
from line number changes, I found at least one place where a substantive
(though very small) change was required.

In krb5/src/lib/krb5/os/hst_realm.c, in the krbt_get_host_referral_realm
function, I changed

     char local_host[MAX_DNS_NAMELEN+1];

to

     char local_host[MAXDNAME];

because, I believe (this is based on my memory now) MAX_DNS_NAMELEN was
not defined in this module.  I figured that MAXDNAME was large enough to
incorporate the size of MAX_DNS_NAMELEN+1, at least to avoid a buffer
overflow condition.  Of course, I might be wrong and there may very well
be a better way to handle this change.

My 1.4.2 KDC has been running (continuously) since early September with no
problems.

I didn't sent you my patch updates because initially I was going to 1.4.1
and I needed to incorporate MIT patches SA-2005-002 and SA-2005-003 that
came out before 1.4.2 was released and which hit one of the modules that
your patch does.  So I had to incorporate all 3 patches in that particular
module (kdc/do_tgs_req.c, I believe).

But then I decided to go with 1.4.2, so I guess my referrals patch stands
on its own.  If you like, I can send it to you if you haven't already done
your own update.

Mike

_____________________________________________________________________
Mike Friedman                   System and Network Security
[hidden email]          2484 Shattuck Avenue
1-510-642-1410                  University of California at Berkeley
http://ack.Berkeley.EDU/~mikef  http://security.berkeley.edu
_____________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBQ3Jifq0bf1iNr4mCEQJkNwCgtkvuK6HeEHja+XtcMOdZIVdCvDkAn3R2
t+8a08k3SQspExm7Bb1HFMiN
=dn26
-----END PGP SIGNATURE-----
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Josh Howlett
In reply to this post by Kevin Coffman
Kevin Coffman wrote:
> We started with a patch that assumed all referrals would go to one place.
>
> We had a need to send referrals to either a test Windows forest or a
> production forest.  That is where the [domain_referral] stuff came
> from.  Then we found that some requests were coming in without
> fully-qualified names, and therefore we could not determine the
> "right" place for the referral.  For those requests, we send the
> referral to the default place, which in our case is to the production
> forest.

Kevin,

Do you think it would be possible to introduce an MIT KDC into an
existing AD environment, such that W2K clients in the AD realm (if
making a request for an unknown principal) can get referred to the MIT
KDC's "default" place?

Many thanks, josh.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Kevin Coffman
In reply to this post by Mike Friedman
On 11/9/05, Mike Friedman <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 9 Nov 2005 at 15:36 (-0500), Kevin Coffman wrote:
>
> > Our patches are here: http://www.citi.umich.edu/u/kwc/krb5stuff/referrals.html
> >
> > The page will be updated soon with a patch for 1.4.2, but the 1.3.4
> > patch applied rather cleanly last night while doing the cvs merge to
> > 1.4.2.
>
> Kevin,
>
> I've been using your referrals patch for about 4 years now and last August
> I updated our KDC to 1.4.2.  So, I had to update the patch as well. Aside
> from line number changes, I found at least one place where a substantive
> (though very small) change was required.
>
> In krb5/src/lib/krb5/os/hst_realm.c, in the krbt_get_host_referral_realm
> function, I changed
>
>      char local_host[MAX_DNS_NAMELEN+1];
>
> to
>
>      char local_host[MAXDNAME];
>
> because, I believe (this is based on my memory now) MAX_DNS_NAMELEN was
> not defined in this module.  I figured that MAXDNAME was large enough to
> incorporate the size of MAX_DNS_NAMELEN+1, at least to avoid a buffer
> overflow condition.  Of course, I might be wrong and there may very well
> be a better way to handle this change.
>
> My 1.4.2 KDC has been running (continuously) since early September with no
> problems.
>
> I didn't sent you my patch updates because initially I was going to 1.4.1
> and I needed to incorporate MIT patches SA-2005-002 and SA-2005-003 that
> came out before 1.4.2 was released and which hit one of the modules that
> your patch does.  So I had to incorporate all 3 patches in that particular
> module (kdc/do_tgs_req.c, I believe).
>
> But then I decided to go with 1.4.2, so I guess my referrals patch stands
> on its own.  If you like, I can send it to you if you haven't already done
> your own update.
>
> Mike

Thanks Mike,
I remembered that one-line change after I sent my previous message.  I
made the same change (except from "MAX_DNS_NAMELEN+1" to
"MAXDNAME+1").

I have a script somewhere to generate the patch, so now that I've done
the merge it should be easy enough to generate a new patch.  But if
you have a clean referrals patch, it would be nice to compare.  We
have other local mods that I try to keep out of those patches.

K.C.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Kevin Coffman
In reply to this post by Josh Howlett
On 11/9/05, Josh Howlett <[hidden email]> wrote:

> Kevin Coffman wrote:
> > We started with a patch that assumed all referrals would go to one place.
> >
> > We had a need to send referrals to either a test Windows forest or a
> > production forest.  That is where the [domain_referral] stuff came
> > from.  Then we found that some requests were coming in without
> > fully-qualified names, and therefore we could not determine the
> > "right" place for the referral.  For those requests, we send the
> > referral to the default place, which in our case is to the production
> > forest.
>
> Kevin,
>
> Do you think it would be possible to introduce an MIT KDC into an
> existing AD environment, such that W2K clients in the AD realm (if
> making a request for an unknown principal) can get referred to the MIT
> KDC's "default" place?

I think you're asking if an AD KDC can send a client a referral to an
MIT KDC.  If that is correct, then I don't know the answer.  If it
isn't correct, could you restate the question?

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Mike Friedman
In reply to this post by Kevin Coffman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 9 Nov 2005 at 16:20 (-0500), Kevin Coffman wrote:

> I remembered that one-line change after I sent my previous message.  I
> made the same change (except from "MAX_DNS_NAMELEN+1" to "MAXDNAME+1").

Kevin,

I believe I looked at the definition of MAXDNAME and decided it was at
least 1 byte larger than MAX_DNS_NAMELEN had been, which is why I didn't
bother adding the 1.

> I have a script somewhere to generate the patch, so now that I've done
> the merge it should be easy enough to generate a new patch.  But if you
> have a clean referrals patch, it would be nice to compare.  We have
> other local mods that I try to keep out of those patches.

OK, you can download my version of the patch from here:

   https://webfiles.berkeley.edu/mikef/shared/MIT-K5/UMich-referrals-patch-1.4.2

You'll notice I include an update to include/krb5/stock/osconf.h, where I
insert a '$define UMICH' to enable the patch.

Let me know when you've got it.  I'll probably remove it at some point
thereafter.  I figure people who want the patch should get the 'official'
version from your site when it's available.

Thanks.

Mike

_____________________________________________________________________
Mike Friedman                   System and Network Security
[hidden email]          2484 Shattuck Avenue
1-510-642-1410                  University of California at Berkeley
http://ack.Berkeley.EDU/~mikef  http://security.berkeley.edu
_____________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBQ3Jsy60bf1iNr4mCEQJXvgCdF+zq8qwyi/ZVat9qUXku5SSEY4cAn3wG
JQYcAclAP1jHexL3n/t6WAOF
=lhNy
-----END PGP SIGNATURE-----
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Josh Howlett
In reply to this post by Kevin Coffman
Kevin Coffman wrote:

> On 11/9/05, Josh Howlett <[hidden email]> wrote:
>
>>Kevin Coffman wrote:
>>
>>>We started with a patch that assumed all referrals would go to one place.
>>>
>>>We had a need to send referrals to either a test Windows forest or a
>>>production forest.  That is where the [domain_referral] stuff came
>>>from.  Then we found that some requests were coming in without
>>>fully-qualified names, and therefore we could not determine the
>>>"right" place for the referral.  For those requests, we send the
>>>referral to the default place, which in our case is to the production
>>>forest.
>>
>>Kevin,
>>
>>Do you think it would be possible to introduce an MIT KDC into an
>>existing AD environment, such that W2K clients in the AD realm (if
>>making a request for an unknown principal) can get referred to the MIT
>>KDC's "default" place?
>
>
> I think you're asking if an AD KDC can send a client a referral to an
> MIT KDC.  If that is correct, then I don't know the answer.  If it
> isn't correct, could you restate the question?

We have an existing AD KDC which contains all of our user principals.

We would like to enable these users to access applications in other
remote realms, but because these realms are very numerous we don't want
to establish cross-realm relationship with each of them.

Instead, would it be possible to implement a MIT KDC that acted *purely*
(ie. no user principals) as a "referral realm". The referral agent would
know (and have a trust relationship with) each other remote realm.

           Referral realm
             /    |    \
            /     |     \
      Realm A   Realm B  Realm C   (actually many more of these)
        /                  \
      User                Application

Assuming Realm A is an AD, there is the additional problem that Windows
doesn't provide referrals to realms it doesn't explicitly know about.

Hence, it seems necessary to have a "shim" between the User and the
realm's AD KDC that can catch the requests for remote principals, and
refer the User to the Referral realm. Would it be possible to implement
this using the MIT referral system, without making significant changes
to the existing AD?

   Referral realm
         |
     ------- Realm A ---
        |
  User--MIT--Windows KDC & AD

Does that help?

josh.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Douglas E. Engert
In reply to this post by Josh Howlett


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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Kevin Coffman
In reply to this post by Mike Friedman
Thanks Mike!  I got your patch, and generated mine.  They were
identical except for the "+1" and your addition to #define UMICH in
osconf.h, which I have added to the "official" patch.  The referrals
page is now updated with the 1.4.2 patch.

K.C.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

KDC has no support for encryption type (14) After Set DES Accout

david.turing
In reply to this post by Douglas E. Engert
hi, I have dealing the problem for long time and no response in bea forum.
I feel very exhausted when checking mit's kerberos mailist and sun
security forum.
The problem is "KDC has no support for encryption type (14)"  when i
doing the SSO between MS domain and Weblogic.

I had set Account to use DES Encryption type for the host but have
nothing change .

My Steps are as below :
1)
first Generate the DES Encryption Type User Account for the weblogic
server, namely "weblogic" on Windows AD.


2)
then, I generate the keytab using w2k's ktpass on the AD SERVER:
c:\>ktpass -princ HTTP/[hidden email] -mapuser weblogic
-pass weblogic -out dlsvr_keytab -crypto des-cbc-crc

and it turn out to be successful.

c:\>ktab -k dlsvr_keytab -a HTTP/[hidden email]

and I place the dlsvr_keytab to the weblogic server[weblogic]
I use the kinit to check the keytab
kinit -k -t dlsvr_keytab  HTTP/[hidden email]

output is :New ticket is store in cache file C:\Documents and Setting ........

3) I modify the KDC Config file in c:\winnt

My W2KSP4 KDC Config is:
c:\winnt\krb5.ini-----------------------------

[libdefaults]

default_realm = DLSVR.COM
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
ticket_lifetime = 600

[realms]

DLSVR.COM = {
kdc = 192.168.2.231
admin_server = dlserver
default_domain = DLSVR.COM
}

[domain_realm]
.dlsvr.com= DLSVR.COM

[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true


The Log is shown in Weblogic, it told me that KDC has no support for
encryption type (14)
I try to modify the regstry entry as SUN mention in JGSS, changing the
allowtgtsessionkey
which locate in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
set allowtgtsessionkey=1, but nothing help to prevent the KDC has no
support for encryption type (14)

The Log in weblogic is as below:
------------------------------------

<2005-11-8 ....... CST> <Debug> <SecurityDebug> <000000> <Found
Negotiate with SPNEGO token>

>>> KeyTab: load() entry length: 50
>>> KeyTabInputStream, readName(): DLSVR.COM
>>> KeyTabInputStream, readName(): host
>>> KeyTabInputStream, readName(): weblogic
>>> KeyTab: load() entry length: 44
>>> KeyTabInputStream, readName(): dlsvr.com
>>> KeyTabInputStream, readName(): weblogic
>>> EType: sun.security.krb5.internal.crypto.DesCbcCrcEType
>>>crc32: e9889c7a
>>>crc32: 11101001100010001001110001111010
>>> KrbAsReq calling createMessage
>>> KrbAsReq in createMessage
>>> KrbAsReq etypes are: 1
>>> KrbKdcReq send: kdc=192.168.2.231 UDP:88, timeout=30000, number of
retries =3, #bytes=216
>>> KDCCommunication: kdc=192.168.2.231 UDP:88, timeout=30000,Attempt
=1, #bytes=216
>>> KrbKdcReq send: #bytes read=1217
>>> KrbKdcReq send: #bytes read=1217
>>> EType: sun.security.krb5.internal.crypto.DesCbcCrcEType
>>>crc32: 54c176ae
>>>crc32: 1010100110000010111011010101110
>>> KrbAsRep cons in KrbAsReq.getReply host/weblogic
Found key for host/[hidden email]
Entered Krb5Context.acceptSecContext with state=STATE_NEW
<2005-11-8 ........ CST> <Debug> <SecurityDebug> <000000> <GSS
exception GSSException: Failure unspecified at GSS-API level
(Mechanism level: KDC has no support for encryption type (14))
GSSException: Failure unspecified at GSS-API level (Mechanism level:
KDC has no support for encryption type (14))
at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:734)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:300)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:246)
at weblogic.security.providers.utils.SPNEGONegotiateToken.getUsername(SPNEGONegotiateToken.java:371)
at weblogic.security.providers.authentication.SinglePassNegotiateIdentityAsserterProviderImpl.assertIdentity(SinglePassNegotiateIdentityAsserterProvider
Impl.java:201)
at weblogic.security.service.PrincipalAuthenticator .assertIdentity(PrincipalAuthenticator.java:553)
at weblogic.servlet.security.internal.CertSecurityModule.checkUserPerm(CertSecurityModule.java:104)
at weblogic.servlet.security.internal.SecurityModule.beginCheck(SecurityModule.java:199)
at weblogic.servlet.security.internal.CertSecurityModule.checkA(CertSecurityModule.java:86)
at weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(ServletSecurityManager.java:145)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3685)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2644)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)


Any Help or Advice woud be highly appreciated!

david.turing


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Saber Zrelli
In reply to this post by Douglas E. Engert

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           [hidden email]
> >https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
>
> --
>
>  Douglas E. Engert  <[hidden email]>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

--
Saber ZRELLI <[hidden email]>
Japan Advanced Institute of Science and Technology
Center of Information Science
Shinoda Laboratory
url     : http://www.jaist.ac.jp/~zrelli
gpg-id  : 0x7119EA78
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Kenneth G Raeburn
On Nov 9, 2005, at 21:19, Saber Zrelli wrote:
> 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 ?

That's sort of the idea, yes.  Though Larry Zhu and I were discussing  
today what happens if the local KDC has no cross-realm key for the  
target realm, but can refer you to an intermediate realm which may  
not be able to do referrals; I think the draft is going to need some  
work to cover that case.

Ken

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Buck Huppmann
In reply to this post by Douglas E. Engert
> 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.

assuming you're talking about the default realm being a non-Windows-AD;

and if the client requests a ticket for a fully-qualified hostname in-
stance (seems to depend on whether they manage to resolve the host by DNS
or NetBIOS first);

and if you're talking Windows 2003 AD servers and you do that netdom.exe
/foresttransitive trust establishment stuff with the default realm;

and everything is in the right phase;

then you can netdom.exe /addtln:uk (as long as that doesn't conflict with
anything more specific already added to the namesuffixes list[s]) along
with all the other TLDs you care about, to that default-realm trustedDomain
object. (yeah, i can't seem to wildcard the root, in my experimenting)

see the tail end of

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/539c5381-db4f-445f-aac0-2df5448181c1.mspx

for this particular netdom [ab]usage

and, yes, i realize it's tedious and error-prone and maybe not at all the
tree you're barking up
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos referrals

Saber Zrelli
In reply to this post by Kenneth G Raeburn
Hi ,

* On 22:56, Wed 09 Nov 05, Ken Raeburn wrote:

> On Nov 9, 2005, at 21:19, Saber Zrelli wrote:
> >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 ?
>
> That's sort of the idea, yes.  Though Larry Zhu and I were discussing  
> today what happens if the local KDC has no cross-realm key for the  
> target realm, but can refer you to an intermediate realm which may  
> not be able to do referrals; I think the draft is going to need some  
> work to cover that case.

I think that there should be an inter-KDC protocol for referrals,
such a protocol would be something similar to the Internet Routing
Protocol (RIP). KDCs can exchange then their referral capabilities with
their direct connections (other KDCs with which they share keys).

Does it make no sense ?


--
Saber ZRELLI <[hidden email]>
Japan Advanced Institute of Science and Technology
Center of Information Science
Shinoda Laboratory
url     : http://www.jaist.ac.jp/~zrelli
gpg-id  : 0x7119EA78
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KDC has no support for encryption type (14) After Set DES Accout

david.turing
In reply to this post by david.turing
hah, I know what happens, the IE version.
I passed SSO test on XP sp1 ,  W2K professional with IE5(with sp4)
but not on IE6 with SP4

----- Original Message -----
From: "david.turing" <[hidden email]>
To: "Douglas E. Engert" <[hidden email]>
Cc: <[hidden email]>
Sent: Thursday, November 10, 2005 12:05 PM
Subject: KDC has no support for encryption type (14) After Set DES Accout


> hi, I have dealing the problem for long time and no response in bea forum.
> I feel very exhausted when checking mit's kerberos mailist and sun
> security forum.
> The problem is "KDC has no support for encryption type (14)"  when i
> doing the SSO between MS domain and Weblogic.
>
> I had set Account to use DES Encryption type for the host but have
> nothing change .
>
> My Steps are as below :
> 1)
> first Generate the DES Encryption Type User Account for the weblogic
> server, namely "weblogic" on Windows AD.
>
>
> 2)
> then, I generate the keytab using w2k's ktpass on the AD SERVER:
> c:\>ktpass -princ HTTP/[hidden email] -mapuser weblogic
> -pass weblogic -out dlsvr_keytab -crypto des-cbc-crc
>
> and it turn out to be successful.
>
> c:\>ktab -k dlsvr_keytab -a HTTP/[hidden email]
>
> and I place the dlsvr_keytab to the weblogic server[weblogic]
> I use the kinit to check the keytab
> kinit -k -t dlsvr_keytab  HTTP/[hidden email]
>
> output is :New ticket is store in cache file C:\Documents and Setting ........
>
> 3) I modify the KDC Config file in c:\winnt
>
> My W2KSP4 KDC Config is:
> c:\winnt\krb5.ini-----------------------------
>
> [libdefaults]
>
> default_realm = DLSVR.COM
> default_tkt_enctypes = des-cbc-crc
> default_tgs_enctypes = des-cbc-crc
> ticket_lifetime = 600
>
> [realms]
>
> DLSVR.COM = {
> kdc = 192.168.2.231
> admin_server = dlserver
> default_domain = DLSVR.COM
> }
>
> [domain_realm]
> .dlsvr.com= DLSVR.COM
>
> [appdefaults]
> autologin = true
> forward = true
> forwardable = true
> encrypt = true
>
>
> The Log is shown in Weblogic, it told me that KDC has no support for
> encryption type (14)
> I try to modify the regstry entry as SUN mention in JGSS, changing the
> allowtgtsessionkey
> which locate in
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
> set allowtgtsessionkey=1, but nothing help to prevent the KDC has no
> support for encryption type (14)
>
> The Log in weblogic is as below:
> ------------------------------------
>
> <2005-11-8 ....... CST> <Debug> <SecurityDebug> <000000> <Found
> Negotiate with SPNEGO token>
> >>> KeyTab: load() entry length: 50
> >>> KeyTabInputStream, readName(): DLSVR.COM
> >>> KeyTabInputStream, readName(): host
> >>> KeyTabInputStream, readName(): weblogic
> >>> KeyTab: load() entry length: 44
> >>> KeyTabInputStream, readName(): dlsvr.com
> >>> KeyTabInputStream, readName(): weblogic
> >>> EType: sun.security.krb5.internal.crypto.DesCbcCrcEType
> >>>crc32: e9889c7a
> >>>crc32: 11101001100010001001110001111010
> >>> KrbAsReq calling createMessage
> >>> KrbAsReq in createMessage
> >>> KrbAsReq etypes are: 1
> >>> KrbKdcReq send: kdc=192.168.2.231 UDP:88, timeout=30000, number of
> retries =3, #bytes=216
> >>> KDCCommunication: kdc=192.168.2.231 UDP:88, timeout=30000,Attempt
> =1, #bytes=216
> >>> KrbKdcReq send: #bytes read=1217
> >>> KrbKdcReq send: #bytes read=1217
> >>> EType: sun.security.krb5.internal.crypto.DesCbcCrcEType
> >>>crc32: 54c176ae
> >>>crc32: 1010100110000010111011010101110
> >>> KrbAsRep cons in KrbAsReq.getReply host/weblogic
> Found key for host/[hidden email]
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> <2005-11-8 ........ CST> <Debug> <SecurityDebug> <000000> <GSS
> exception GSSException: Failure unspecified at GSS-API level
> (Mechanism level: KDC has no support for encryption type (14))
> GSSException: Failure unspecified at GSS-API level (Mechanism level:
> KDC has no support for encryption type (14))
> at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:734)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:300)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:246)
> at weblogic.security.providers.utils.SPNEGONegotiateToken.getUsername(SPNEGONegotiateToken.java:371)
> at weblogic.security.providers.authentication.SinglePassNegotiateIdentityAsserterProviderImpl.assertIdentity(SinglePassNegotiateIdentityAsserterProvider
> Impl.java:201)
> at weblogic.security.service.PrincipalAuthenticator .assertIdentity(PrincipalAuthenticator.java:553)
> at weblogic.servlet.security.internal.CertSecurityModule.checkUserPerm(CertSecurityModule.java:104)
> at weblogic.servlet.security.internal.SecurityModule.beginCheck(SecurityModule.java:199)
> at weblogic.servlet.security.internal.CertSecurityModule.checkA(CertSecurityModule.java:86)
> at weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(ServletSecurityManager.java:145)
> at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3685)
> at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2644)
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
>
>
> Any Help or Advice woud be highly appreciated!
>
> david.turing
>
>
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos