Hallo Saber, I though that by introducing two different principals [EMAIL PROTECTED] and [EMAIL PROTECTED] I can better protect realm A from what my happen in realm B. My probelm is following one,
imagine user [EMAIL PROTECTED] 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/[EMAIL PROTECTED] for principal [EMAIL PROTECTED] 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/[EMAIL PROTECTED] for principal [EMAIL PROTECTED] 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 [EMAIL PROTECTED] > > in realm B I am principal [EMAIL PROTECTED] > > > > when ssh from unix box in realm A to unix box in realm B I get TGT > > > > krbtgt/[EMAIL PROTECTED] > > This is because you forwarded it. > > > > in credentials cache of the user2, although I have expected to have TGT > > > > krbtgt/[EMAIL PROTECTED] 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 [EMAIL PROTECTED] registered in realm A > 2. krbtgt/[EMAIL PROTECTED] registered as a principal in realm B > 3. krbtgt/[EMAIL PROTECTED] 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. [EMAIL PROTECTED] , the authentication layer used by sshd as [EMAIL > PROTECTED] > will require a service ticket from you. > > so your ssh client will check your cache in [EMAIL PROTECTED] for service > ticket to be used with sshd in [EMAIL PROTECTED] or TGT to be used @B. > > if none is there, your ssh client will ask the local KDC for [EMAIL PROTECTED] > > and obtain it without typing any password. > after, the ssh client uses this [EMAIL PROTECTED] to obtain a service ticket. > once this service ticket obtained from [EMAIL PROTECTED] il will be cached in > [EMAIL PROTECTED] and used to access [EMAIL PROTECTED] > > 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/[EMAIL PROTECTED] 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 [EMAIL PROTECTED] > > > > > > > > This is however not the functionality I am looking for. > > > > Instead of forwarding krbtgt/[EMAIL PROTECTED], I would like to get > > > > krbtgt/[EMAIL PROTECTED] 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 [EMAIL PROTECTED] instead of [EMAIL PROTECTED] > > > > > > semanticaly speaking, [EMAIL PROTECTED] 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 > > > [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > -- vadim <[EMAIL PROTECTED]> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
