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 <[email protected]> To: Sonja Benz/Germany/IBM@IBMDE Cc: [email protected] 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 [email protected] > > working? > > Sonja > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
