Cross realm special question
Jeremy Hunt
jeremyh at optimation.com.au
Tue Oct 25 20:29:00 EDT 2011
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
>
More information about the Kerberos
mailing list