[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TGT forwarding when cross-realm auth?
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 <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444