#4059 [RFE] Unable to add Kerberos principal via kadmin.local
Closed: Fixed None Opened 5 years ago by mkosek.

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.

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

2 years ago

Login to comment on this ticket.

Metadata