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 <[email protected]> > > 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. :) >> >> [email protected] 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 <[email protected] <mailto: >>> jeremyh@optimation.**com.au <[email protected]>>> >>> >>> >>> >>> 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 [email protected] <mailto:[email protected]> >>> >>> >>> https://mailman.mit.edu/**mailman/listinfo/kerberos<https://mailman.mit.edu/mailman/listinfo/kerberos> >>> >>> >>> >>> >> > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
