TGT forwarding when cross-realm auth?

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

TGT forwarding when cross-realm auth?

Vadim-8
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.

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.

--
vadim <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Vadim-8
Hallo Saber,

I though that by introducing two different principals user1@A and
user2@B I can better protect realm A from what my happen in realm B. My
probelm is following one,

imagine user userX@A has logged in from realm A into realm B via SSH and
he has frowarded his TGT like this:

ssh -l userY somebox-in-realm-B

Credentials cache of userY on somebox-in-realm-B will contain TGT
krbtgt/A@A for principal userX@A. Now, since in realm B people have
access to root password, they may do

1) su
2) su - userY

from now on to my understanding they can ssh into realm A from a unix
box in realm B as userX.

I though also that may be it is possible to configure kerberos in such
way, that when userX from realm A logs into realm B using

ssh -l userY somebox-in-realm-B

than credential cache of UNIX userY will be populated with krbtgt/B@B
for principal userY@B.

Do you think it is possible to get this thing working?

Thanx a lot and best regards, vadim tarassov.

On Sat, 2005-06-04 at 23:27 +0900, Saber Zrelli wrote:

> Hi  Vadim ,
>
>
> In order to do cross-realm auth, I dont see why do you have two
> principals in each realm, you only need one.
>
> second, the credentials that you store in the remore unix box, are
> not critic, and there is no risk for realm A if these credentials
> are stolen.
>
> You should not forward tickets from realm A to realm B. Forwarding
> means that you want credentials that you obtained in A to be brought
> to your account in B also.
>
>
>
>
>
> * On 12:13, Sat 04 Jun 05, vadim wrote:
> > Hallo Saber,
> >
> > Presize scenario is:
> >
> > in realm A I am principal user1@A
> > in realm B I am principal user2@B
> >
> > when ssh from unix box in realm A to unix box in realm B I get TGT
> >
> > krbtgt/A@A
>
> This is because you forwarded it.
> >
> > in credentials cache of the user2, although I have expected to have TGT
> >
> > krbtgt/B@B instead.
>
> You are right you should have this inorder to be in cross-realm
> auth.
>
>
> I would conclude that your cross-realm authentication is  not
> working correcely.
>
> you should have :
>
> 1. principal me@A registered in realm A
> 2. krbtgt/A@A registered as a principal in realm B
> 3. krbtgt/B@B registered as principal in realm A
> 4. Disable forwarding because you don't need it here
>
> Step 3 is obligatory. you cannot just make realm B trust realm A
> while realm A dont trust B.
>
> int step 2 and 3  , you have to use the same password.
>
> if you have the above setup. when you try to login into a remote
> box in B. box@B , the authentication layer used by sshd as box@B
> will require a service ticket from you.
>
> so your ssh client will check your cache in box@A for service
> ticket to be used with sshd in box@B or TGT to be used @B.
>
> if none is there, your ssh client will ask the local KDC for TGT@B.
>
> and obtain it without typing any password.
> after, the ssh client uses this TGT@B to obtain a service ticket.
> once this service ticket obtained from TGT@B il will be cached in
> box@A. and used to access box@B.
>
> once you login in your ssh-session you dont have keys.
>
> key forwarding is not to be used in cross-realm operations. You can
> not use keys delivered in A to get some service in B.
> So you should not do forwarding because it is not useful at all
> in your situation.
>
>
> Hope it helps,
> ---Saber
>
> >
> > Reason why I want to avoid to have credentails related to realm A
> > in filesystem of servers from the B realm, is that in our
> > organization realm A is "secure" and realm B is "developement",
> > and people have access to root password on the B's servers. It is
> > also the reason why I have defined one-way trust, where B trusts A
> > and not otherwise. I though that, users from realm A will ssh into
> > realm B  and will get TGT for realm B in the credentials cache
> > (when asking SSH to forward creds), they however still get TGTs
> > for realm A in the cache.
> >
> > Do you know if it is possible to get TGT krbtgt/B@B when logging
> > into B realm from A silently? Of course, we can just make kinit on
> > realm B box, but that would not be single sign-on ...
> >
> > Thanx a lot in advance and best regards, vadim tarassov
> >
> > On Sat, 2005-06-04 at 17:55 +0900, Saber Zrelli wrote:
> > > Hi Vadim ,
> > >
> > > * On 09:46, Sat 04 Jun 05, 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.
> > >
> > > semanticaly speaking, me@B is not correct, because the "@" mark
> > > is used to tell your origin ( where are you registered or where
> > > you belong to) and not your location. as you are regisered in A
> > > only(I supose) then you can not say that my principal name is
> > > me@B even though you are logged in a box located in B.
> > >
> > > >
> > > > 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.
> > >
> > > when logging into a box in realm B, you will just save the TGT
> > > for realm B saved in the remote box. this TGT was obtained from
> > > your realm A.
> > >
> > > what are the risks that can threat your system at A ?
> > >
> > > The TGT for realm B is encrypted using a session key. and any
> > > further communications with KDC at realm B does not require your
> > > personal password anyway, these exchanges to aquire service
> > > tickets will use the session key accompaining the TGT.
> > >
> > > On the other hand if you want to have creentials to be used in B
> > > that are not issued by A, then these credentials must be issued
> > > by KDC of B. Hence you need to be registered in realm B. And
> > > this would be simple kerebros operations and not cross-realm
> > > auth.
> > >
> > >
> > > Regards.
> > >
> > -- vadim <[hidden email]>
>
--
vadim <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Douglas E. Engert
In reply to this post by Vadim-8
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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Douglas E. Engert


Jeffrey Hutzelman wrote:

> On Monday, June 06, 2005 10:30:55 AM -0500 "Douglas E. Engert"
> <[hidden email]> wrote:
>
>> 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.
>
>
> Note that this protection does not live entirely in realm B.  A proper
> KDC for realm A will not honor a krbtgt/A@B ticket for me@A, even if the
> realm B KDC were to issue one.

Yes, That is what I thought I said.

>
>
>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

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

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.
> >
>
--
vadim <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Douglas E. Engert


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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Vadim-8
Hi Douglas,

I have tried you suggestion, without success however. Is that TGS from
realm B, who is ment to issue ticket krbtgt/B@A? If yes, then I've done
something wrong, because I don't see that this part of code is executed
in neither ssh client, nor ssh server, nor kdc server from realm B. As
about realm A, I can not apply this patch, because it is Active
Directory server. Could you please confirm if it is realm B (Heimdal in
my case) who will issue ticket krbtgt/B@A?

I was thinking a bit further and came to conclusion, that even if the
patch will be applied successfully I will probably run into ultimative
mess later. Even if file .k5login allows user user1@A to login as user2
on box from realm B, I will later get mess when trying to authenticate
to LDAP server or whatsoever with such principal. I mean, although I am
user2 from point of view of UNIX, I am still user1@A from point of view
of Kerberos.

It seems to me that I will have to apply bigger patch, which will allow
me to obtain ticket krbtgt/B@B for principal user2@B when login into
realm B from realm A being initially principal user1@A. One could even
make this identity switch secure enough if having both (1) trust
relaionships between realms A and B and (2) for principal user2@B a list
of principals (like user1@A) which are allowed to take its identity. It
seems to me, that such functionality could be useful also for other
people. What do you think?

Thanx a lot and best regards, vadim tarassov.

On Wed, 2005-06-08 at 10:58 -0500, Douglas E. Engert wrote:

>
> 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.
> >>>
> >>
>
--
vadim <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: TGT forwarding when cross-realm auth?

Douglas E. Engert


vadim wrote:

> Hi Douglas,
>
> I have tried you suggestion, without success however. Is that TGS from
> realm B, who is ment to issue ticket krbtgt/B@A?

No. In the krbtgt principal its krbtgt/<usable-at-realm>@<issuer-realm>

So user@A gets the inital ticket krbtgt/A@A from A.
The is then used to get krbtgt/B@A from A when the first need of a cross realm
ticket is detected. The krbtgt/B@A ticket is then used to KDC in B
to get service ticket host/fqdn@B

> If yes, then I've done
> something wrong, because I don't see that this part of code is executed
> in neither ssh client, nor ssh server, nor kdc server from realm B. As
> about realm A, I can not apply this patch, because it is Active
> Directory server. Could you please confirm if it is realm B (Heimdal in
> my case) who will issue ticket krbtgt/B@A?

The suggestion I made where all client side. This may be a misunderstanding
about  the principals. The code would be executed when a ssh needed to
get a forwardable ticket, after it has determined it has a service ticket
for the host in realm B. So rather then getting the krbtgt/A@A from A,
using the initial or forwarded krbtgt/A@A ticket, it it would forward
the krbtgt/B@A that it already. (There are some possible problems
here. For example if the ticket had addresses, the client would need a new
ticket, and I don't thing realm B would issue a krbtgt/B@B using the krbtgt/B@A.
This might require a KDC side change on realm B KDC code.)

>
> I was thinking a bit further and came to conclusion, that even if the
> patch will be applied successfully I will probably run into ultimative
> mess later. Even if file .k5login allows user user1@A to login as user2
> on box from realm B, I will later get mess when trying to authenticate
> to LDAP server or whatsoever with such principal.

Not sure here. If the ldap server is in realm B and willing to trust users
from realmA then the user would still request a ldap/host@B using the
krbtgt/B@A ticket which what was forwarded.

> I mean, although I am
> user2 from point of view of UNIX, I am still user1@A from point of view
> of Kerberos.
>
> It seems to me that I will have to apply bigger patch, which will allow
> me to obtain ticket krbtgt/B@B for principal user2@B when login into
> realm B from realm A being initially principal user1@A. One could even
> make this identity switch secure enough if having both (1) trust
> relaionships between realms A and B and (2) for principal user2@B a list
> of principals (like user1@A) which are allowed to take its identity. It
> seems to me, that such functionality could be useful also for other
> people. What do you think?

Yes this might be useful. But if there are many realms, and more then
one of these operations is used across realms it might be hard to determine
who was  originally authenticated.  With straight code, or the mods above,
the user till has the principal user@A.

>
> Thanx a lot and best regards, vadim tarassov.
>
> On Wed, 2005-06-08 at 10:58 -0500, Douglas E. Engert wrote:
>
>>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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444