TGT forwarding when cross-realm auth? - Kerberos

This is a discussion on TGT forwarding when cross-realm auth? - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: TGT forwarding when cross-realm auth?

  1. TGT forwarding when cross-realm auth?

    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

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: TGT forwarding when cross-realm auth?

    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

    >

    --
    vadim

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: TGT forwarding when cross-realm auth?



    On Saturday, June 04, 2005 09:46:42 AM +0200 vadim
    wrote:


    > 1) we (realm A) do not trust realm B and do not want credentials from
    > realm A to be saved on that filesystem.


    Then you need to configure your ssh client not to forward credentials to
    hosts in realm B, or else be careful not to ssh to hosts in realm B when
    you have credentials you don't want to forward there.

    Ideally, you'd be able to set your ssh client so it would not forward
    credentials from realm A, but would be willing to forward credentials from
    realm B. However, I am not aware of any ssh client that offers such a
    feature -- usually, the decision is made based solely on the name of the
    server host.


    > 2) we however still want users to login from A to B without entering
    > passwords.


    That's fine; you do not need to forward credentials in order to get a
    Kerberos-authenticated SSH connection. GSSAPI authentication and
    credential delegation (forwarding) are generally configured separately for
    just this reason.



    However, the only way to get a krbtgt/B@B TGT is either to forward one you
    already have, or to obtain one from the realm B KDC either by typing a
    password or by using a keytab file containing your key.

    -- Jeffrey T. Hutzelman (N3NHS)
    Sr. Research Systems Programmer
    School of Computer Science - Research Computing Facility
    Carnegie Mellon University - Pittsburgh, PA

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread