Cross realm special question

[Sonja Benz]

Hi Jeremy,

yes this works. I did test it. The nice thing about the solution I was 
thinking about was, that this solution only needs to allow communication 
between the two servers KDC A and KDC B via a firewall, thus using KDC A 
as a proxy or gateway to KDC B. Actually the KDCs are AD servers which 
already did implement a trust used by Windows hosts. 

And it is definitely not wrong to rethink learned aspects of things like 
Kerberos :-)

Thanks to all who answered!

Sonja



From:
Jeremy Hunt <jeremyh at optimation.com.au>
To:
Sonja Benz/Germany/IBM at IBMDE
Cc:
kerberos at mit.edu
Date:
10/26/2011 02:31 AM
Subject:
Re: Cross realm special question



Hi Sonja,

I am not too sure I understand what you are getting at here.

Why can't the user access the KDC for realm B? Is there a network access 
issue?

If there is network access then you can certainly use the KDC from realm 
B.

The rest of this email assumes there is network access to realm B.

If you are using kinit, then you will have to set up your kerberos 
configuration files to define the KDC for realm B. This is trivial if the 
system you wish to run kinit on does not use kerberos. In which case after 
setting up the configuration files you can just use kinit on this system 
as you would for any system using realm B to authenticate.

If  you have configuration files that exist and define realm A, it is more 
complicated but you could try experimenting.  You can define realm B 
separately in the configuration files. I have done this for use with 
kadmin quite recently.  Many years ago, before adopting the MIT version of 
kerberos, I used to use kinit in to authenticate in differing remote 
realms regularly. Try it with a simple test, here are the steps to follow:
1. In your configuration files you need a separate realm paragraph 
defining the kdc for the remote realm and you possibly need the admin 
server of realm B defined for changes of password. Duplicate the paragraph 
defining realm A, in this duplicate paragraph change all references from 
realm A to realm B and references from realm A's servers to realm B's 
servers. For argument's sake:
         REALMA.COM = {
                 kdc = realmAadminsrv
                 admin_server = realmAadminsrv
                 kpasswd_server = realmAadminsrv:750
                 kadmind_port = 749
                 kpasswd_port = 750
        }
         REALMB.COM = {
                 kdc = realmBadminsrv
                 admin_server = realmBadminsrv
                 kpasswd_server = realmBadminsrv:750
                 kadmind_port = 749
                 kpasswd_port = 750
        }
    Don't worry if your realm definitions are different, it is an adaption 
of a quite ancient configuration, it is merely an illustration of what I 
said in the previous paragraph.
2. Then use kinit with a valid principal name for realm B. Remember you 
must define your principal name fully to include the domain name of realm 
B. That is:
     kinit <validPrincipal>@REALMB.COM

Good luck,

Jeremy



Sonja Benz wrote:
> Hello,
>
> my example may be uncommon, but imagine an application which is not
> kerberized
> wants to use the passwords of a  KDC for user authentication.
> To make the situation even more special, assume the principal is stored 
in
>
> a KDC which only can be accessed via cross realm trust.
>
>     ------------                               ------------
>     KDC A                                  KDC B
>     Realm: A.COM<---trust --->   Realm: B.COM
>     ------------                               ------------
>
>     --------------
>     host.other.com
>     --------------
>
> Let the application be kinit, for example:
>
> Now, assume the user's password is stored in realm B.COM and the user at
> host.other.com is only able to access KDC A. Is it possible to get
>
>          host.other.com: $ kinit principal at B.COM
>
> working?
>
> Sonja
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>