[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TGT forwarding when cross-realm auth?
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 <vadim.tarassov@swissonline.ch>