Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1035494
Description of problem: Unable to add a krbtgt/OLD-REALM@IPA-REALM via kadmin(.local) to IPA v3. Also seems some functionality such as listpols doesnt work .. Version-Release number of selected component (if applicable): ipa-server-3.0.0-26.el6_4.4.x86_64 How reproducible: Very .. seems to happen all the time ... Steps to Reproduce: 1. kadmin.local 2. add_principal -pw XXXXXXXXX krbtgt/OLD-REALM@IPA-REALM 3. listpols Actual results: for add_pinciple WARNING: no policy specified for krbtgt/OLD-RELAM@IPA-REALM; defaulting to no policy add_principal: Invalid argument while creating "krbtgt/OLD-REALM@IPA-REALM". for listpols kadmin.local: listpols get_policies: Plugin does not support the operation while retrieving list. Expected results: The principle should be added to the kerberos database and be able to be retrieved or listed Additional info: listprincs / getprincs seem to work ok though. Basically trying to add a principle to see if we can set up a trust between IPA kerberos realm and older kerberos realm.
Alternative is to create a command to create principals for an external Kerberos realm.
Please allow me to register my interest in this feature as well.
As a workaround, is there a means of creating a cross-realm principal via the web interface or command line tools? (i.e., does the ui actually filter out the creation of principals that start with krbtgt?)
The UI only allows user, host and hosts' services principal objects to be added. It does not even count with cross-realm principals. Maybe you would get some luck with ldapadd and well crafted LDIF adding this as a service to cn=services,..., but this is a long shot.
ldapadd
cn=services,...
Alternatively, I wonder if kadmin.local override flag used during FreeIPA server installation could be (mis)used here:
# kadmin.local -q 'addprinc -randkey krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST' -x ipa-setup-override-restrictions Authenticating as principal root/admin@MKOSEK-FEDORA20.TEST with password. WARNING: no policy specified for krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST; defaulting to no policy Principal "krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST" created. # kadmin.local -q 'ktadd -k /tmp/realm.keytab krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST' -x ipa-setup-override-restrictions Authenticating as principal root/admin@MKOSEK-FEDORA20.TEST with password. Entry for principal krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/realm.keytab. Entry for principal krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/realm.keytab. Entry for principal krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/tmp/realm.keytab. Entry for principal krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/tmp/realm.keytab. # klist -kt /tmp/realm.keytab Keytab name: FILE:/tmp/realm.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 07/21/2014 09:50:10 krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST 2 07/21/2014 09:50:10 krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST 2 07/21/2014 09:50:10 krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST 2 07/21/2014 09:50:10 krbtgt/OTHER-REALM.TEST@MKOSEK-FEDORA20.TEST
Simo or Nathaniel - could this work as a workaround? I assume that this would only work against one FreeIPA server though as the record is not in LDAP database, correct?
The workaround is to use the special option in kadmin.local to bypass kdb restrictions and allow to create an object for this in the cn=Kerberos subtree, and leave IPA completely oblivious until we properly support trusts.
I discussed this ticket with Simo and Alexander. To have this working, until we have proper IPA-IPA or IPA-Kerberos realm trusts is to create the principals as proposed in comment:5 and set up CA paths in krb5.conf.
Note that CA paths will work correctly only with FreeIPA 4.1.3 (related fixed - #4788, #4791).
Note that I opened proper RFE for the FreeIPA-Kerberos realm trusts - #4917.
Metadata Update from @mkosek: - Issue assigned to someone - Issue set to the milestone: FreeIPA 4.1.3
Login to comment on this ticket.