Re: TGT forwarding when cross-realm auth?

["Douglas E. Engert" <deengert@anl.gov>]

vadim wrote:
> Hi Douglas,
> 
> Thanx a lot again for your help. As it looks like I have to apply the
> modification to the client code, which you have mentioned. It will help
> me however a lot, if you will give a hint of where I'll have to start to
> dig ...

In the Heimdal code it looks like it would be in lib/krb5/get_for_creds.c
at around line 130. The krb5_build_principal is called.


    130      ret = krb5_build_principal(context,
    131                     &creds.server,
    132                     strlen(client_realm),
    133                     client_realm,
    134                     KRB5_TGS_NAME,
    135                     client_realm,
    136                     NULL);

In its simpilist form it would be something like this
to get a krbtgt/<server.realm>@<client.realm>  but see below.

    130      ret = krb5_build_principal(context,
    131                     &creds.server,
    132                     strlen(client_realm),
    133                     client_realm,
    134                     KRB5_TGS_NAME,
    135                     krb5_principal_get_realm(context,server),
    136                     NULL);

A better mod  would test the krb5.conf for something like:
[realms]
REALM = {
  ...
  limited_trust = 1
  }

Then in the krb5.conf file in the user's machine, list the realms
you don't trust sending a full tgt too.

*BUT* If there are more then 2 realms then this will not work, as what
you really want is to get the a tgt from one of the realms along
the path for the next realm on the path to the server.

If you had four realms in a path,  A, B, C, D where the user
is in A and the server is in D, these tickets would be used:

  krbtgt/A@A   (kinit or what is usually forwarded)
  krbtgt/B@A    first cross realm tgt, good at B issued by A.
  krbtgt/C@B    Second good at C issued by B
  krbtgt/D@C    Third good at D issued by C
  host/server@D isued by D.

Note that there is no krbtgt/D@A i.e. krbtgt/<server.realm>@<user.realm>
to forward. But krbtgt/B@A , krbtgt/C@B or krbtgt/D@C could be.









> 
> Thanx a lot in advance and best regards, vadim tarassov.
> 
> On Mon, 2005-06-06 at 10:30 -0500, Douglas E. Engert wrote:
> 
>>Thats not the way it works, as others have pointed out. Currently delegation
>>is an an all or nothing thing. The user's full TGT is delegated with no
>>restrictions.
>>
>>
>>This is one of the areas where Kerberos needs improvement as it becomes
>>more and more popular, some way to limit the damage of a stolen
>>delegate ticket is needed, as I pointed out in a presentation in the
>>last ietf-krb-wg that I co-chaired.
>>
>>
>>vadim wrote:
>>
>>
>>>Hallo everybody,
>>>
>>>First time in my life I managed to establish trust between two realms,
>>>realm A and realm B. Trust is one-way, where B trusts A. 
>>>
>>>Now when I do ssh from unix box from realm A to unix box in realm B, my
>>>TGT from realm A gets forwarded to box in realm B. My principal remains
>>>me@A.
>>>
>>>This is however not the functionality I am looking for. Instead of
>>>forwarding krbtgt/A@A, I would like to get krbtgt/B@B in my credential
>>>cache on unix box in realm B once ssh'ed in it from unix box in realm A.
>>>And I would my principal to become me@B instead of me@A.
>>>
>>
>>You don't have to go as far as to get krbtgt/B@B, but could forward a
>>krbtgt/B@A while still keeping the user as me@A.
>>
>>If you are willing you could make some modifications to the
>>client side that would forward the krbtgt/B@A ticket rather then what
>>it does now forwarding a krbtgt/A@A.  The krbtgt/B@A is good only for
>>services in realm B and any other realms that trust A via B.
>>
>>Even if you had trust setup both ways it would not be allow a
>>a krbtgt/A@B to be issued using the krtgt/B@A this as it would violate
>>the cross-realm trust assumptions because the user is still me@A.
>>Realm A expects the user@A to use the krbtgt/A@A for services in in A.
>>
>>
>>
>>
>>
>>>Reason one I am looking for such functionality is 
>>>
>>>1) we (realm A) do not trust realm B and do not want credentials from
>>>realm A to be saved on that filesystem.
>>>
>>>2) we however still want users to login from A to B without entering
>>>passwords.
>>>
>>>Could you please tell me how I could get such functionality?
>>>
>>>thanx a lot and best regards, vadim tarassov.
>>>
>>

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444