remote kadmin fails

[tartarapoint@gmail.com]

Hi Jeremy (and all others),

thank you for your answer.

I need cross-domain authentication in the same way I would use cross-realm
authentication to access to remote kerberised LDAP server (with GSSAPI).

I mean, using something like

kadmin -kt /etc/keytabs/admin.fqdn2.keytab -p admin/fqdn2 -r REALM2

makes me create one specific keytab on *all* remote servers and then copy
(scp) them on each other, which works but is very complicated, considering
that kerberos allows cross platform authentications.

Therefore, I would appreciate being able to do something like

kadmin -kt /etc/keytabs/admin.fqdn1.keytab -p admin/fqdn1 -r REALM2

and let kadmin negotiate the cross-realm TGT and then connect to REALM2
automatically.

But it seems to be impossible, which is very surprising!


2011/6/27 Jeremy Hunt <jeremyh at optimation.com.au>

>
> Hi again,
>
> I did a quick test, and you do need the the remote domain and its admin
> server defined in your kerberos conf file for kadmin to work. So the '-s'
> option appears to be redundant :( .
>
> Moral, get your kerberos configuration right.
>
> Jeremy
>
>
>
> Jeremy Hunt wrote:
>
>>
>> Hi people (I am not too sure who I am talking to, probably Matt),
>>
>> I don't think what I described was cross-realm authentication. It is more
>> like running a client program to connect to a remote server.
>>
>> kadmin is a client program. With my suggested arguments you are telling
>> the kadmin program to use a kerberos domain (or realm if you prefer), and
>> you are telling it to use a kerberos principal and a specific key table
>> file. As a client program it will read your krb5.conf file and lookup the
>> admin server for that realm (or domain if you prefer that term) and it will
>> look for the named principal's key in the specified key table file. If all
>> is correctly configured it should connect to the port kadmind is using on
>> the remote machine, using the realm the remote machine administers and using
>> the correct key with a matching principal name to authenticate itself.
>>
>> Under those conditions you could use the kadmin client program on a
>> machine that did not otherwise have kerberos installed. I see it as using a
>> mail client like 'seabird' to connect to a gmail.com account, most people
>> can do that whatever internet domain they are running the mail client on.
>>
>> I think cross-realm authentication is a little trickier than what I
>> describe and what I thought you were attempting. Do you need cross-realm
>> authentication and if so why? If all you want to do is administer a remote
>> system then I do not think it is worth the trouble. If you have to link the
>> two realms for some reason other than you want to administer them from the
>> same machine, then you would consider it.
>>
>> I hope this clarifies things,
>>
>> Jeremy Hunt
>>
>> PS: Note that in my first reply I purposefully used a different keytab
>> file for the remote realm because I don't think there is a way to export the
>> key into a file without generating a new version number. Without looking at
>> the code or more simply testing I cannot guarantee that joining two keytab
>> files with something like 'cat' will work.
>>
>> PPS: I also note there is a '-s' argument to the kadmin program. This
>> defines both the remote server machine and the kadmind port. so you might
>> not even need your configuration file set up correctly for it to work. Try
>> it. :)
>>
>> tartarapoint at gmail.com wrote:
>>
>>> Hi Jeremy,
>>>
>>> Thank you for your answer.
>>> From your point 4 ('If the entry for admin/fqdn2 is not in the keytab
>>> admin.fqdn1, then copy the keytab admin.fqdn2 to your local system'), I
>>> deduce that we can do cross realm authentication with kadmin. Is it right?
>>>
>>>
>>> 2011/6/24 Jeremy Hunt <jeremyh at optimation.com.au <mailto:
>>> jeremyh at optimation.**com.au <jeremyh at optimation.com.au>>>
>>>
>>>
>>>
>>>    Hi Matt or Vivien,
>>>
>>>    There is not enough information here, however I did notice:
>>>
>>>    1. REALM2 would have to be defined with its servers in your
>>> configuration files on the machine you are running kadmin on. This is so the
>>> kadmin program knows which remote system the kadmin daemon is running on and
>>> so can attempt a connection.
>>>    2. If the configuration files are correct then the kadmin logs on the
>>> remote system may have some useful information. Your local machine would not
>>> be expected to log errors from a remote machine.
>>>    3. I am assuming admin/fqdn1 is the administration principal in
>>> REALM1. On the remote system I would expect the administration principal for
>>> REALM2 to be admin/fqdn2.
>>>    4. If the entry for admin/fqdn2 is not in the keytab admin.fqdn1, then
>>> copy the keytab admin.fqdn2 to your local system.
>>>    5. If there is a authentication failure, you might find an error in
>>> the kdc logs rather than the kadmin logs.
>>>
>>>    So:
>>>    1. Check your configuration files are set up properly, you have to
>>> define both realms in them.
>>>    2. Check the kdc logs and the kadmin logs on your local and your
>>> remote masters.
>>>    3. Make sure you have the correct keytab files and entries.
>>>    4. Try this command after your configuration files and keytabs are
>>> correct:
>>>
>>>    kadmin -kt /etc/keytabs/admin.fqdn2.**keytab -p admin/fqdn2 -r REALM2
>>>
>>>    Good Luck,
>>>
>>>    Jeremy
>>>
>>>     V wrote:
>>>
>>>        Hello,
>>>
>>>        we are running kerberos v1.8.1 and trying to run kadmin from
>>> REALM1 to
>>>        REALM2 by:
>>>
>>>        *kadmin -kt /etc/keytabs/admin.fqdn1.**keytab -p admin/fqdn1 -r
>>> REALM2*
>>>
>>>        but it doesn't work. The message in the console is:
>>>        *
>>>        kadmin: GSS-API (or Kerberos) error while initializing kadmin
>>> interface*
>>>
>>>        and there is no error in the kdc/kadmin log.
>>>        If we change "-r REALM2" by "-r REALM1", it works and we can
>>> administrate
>>>        local kdc.
>>>
>>>        Can you help us please?
>>>
>>>        Thank you,
>>>
>>>        Matt
>>>        ______________________________**__________________
>>>        Kerberos mailing list Kerberos at mit.edu <mailto:Kerberos at mit.edu>
>>>
>>>        https://mailman.mit.edu/**mailman/listinfo/kerberos<https://mailman.mit.edu/mailman/listinfo/kerberos>
>>>
>>>
>>>
>>>
>>
>