ipa upgrade fails after established trust with ad.
ipa
ipa 4.9.14
ipa-4-9
ipactl restart
ipactl restart fails with:
Job for ipa.service failed because the control process exited with error code. See "systemctl status ipa.service" and "journalctl -xeu ipa.service" for details.
ipaupgrade.log:
ipaupgrade.log
2024-12-04T14:26:03Z DEBUG Executing upgrade plugin: update_tdo_to_new_layout 2024-12-04T14:26:03Z DEBUG raw: update_tdo_to_new_layout 2024-12-04T14:26:03Z DEBUG raw: adtrust_is_enabled(version='2.251') 2024-12-04T14:26:03Z DEBUG adtrust_is_enabled(version='2.251') 2024-12-04T14:26:03Z DEBUG raw: trustconfig_show(version='2.251') 2024-12-04T14:26:03Z DEBUG trustconfig_show(rights=False, trust_type='ad', all=False, raw=False, version='2.251') 2024-12-04T14:26:03Z DEBUG Processing trust domain object cn=trustd.trustdomain,cn=ad, cn=trusts,dc=freeipa,dc=testdomain 2024-12-04T14:26:03Z DEBUG Updating Kerberos principal entry for krbtgt/TRUSTD.TRUSTDO MAIN@FREEIPA.TESTDOMAIN 2024-12-04T14:26:03Z DEBUG No update was required for Kerberos principal krbtgt/TRUSTD .TRUSTDOMAIN@FREEIPA.TESTDOMAIN 2024-12-04T14:26:03Z DEBUG No need to update Kerberos keys for existing Kerberos princ ipal krbtgt/TRUSTD.TRUSTDOMAIN@FREEIPA.TESTDOMAIN 2024-12-04T14:26:03Z DEBUG Adding Kerberos principal entry for krbtgt/TRUSTD@FREEIPA.T ESTDOMAIN 2024-12-04T14:26:03Z DEBUG Destroyed connection context.ldap2_140061374847008 2024-12-04T14:26:03Z ERROR Upgrade failed with attribute "ipaAllowedToPerform;read_key s" not allowed
dirsrv access log:
dirsrv
access
[04/Dec/2024:17:26:03.776162223 +0300] conn=4 op=462 SRCH base="krbprincipalname=krbtgt/TRUSTD.TRUSTDOMAIN@FREEIPA.TESTDOMAIN,cn=trustd.trustdomain,cn=ad,cn=trusts,dc=freeipa,dc=testdomain" scope=0 filter="(objectClass=*)" attrs=ALL [04/Dec/2024:17:26:03.776540334 +0300] conn=4 op=462 RESULT err=0 tag=101 nentries=1 wtime=0.000897883 optime=0.000379332 etime=0.001274678 [04/Dec/2024:17:26:03.777233023 +0300] conn=4 op=463 SRCH base="krbprincipalname=krbtgt/TRUSTD@FREEIPA.TESTDOMAIN,cn=trustd.trustdomain,cn=ad,cn=trusts,dc=freeipa,dc=testdomain" scope=0 filter="(objectClass=*)" attrs=ALL [04/Dec/2024:17:26:03.777452817 +0300] conn=4 op=463 RESULT err=32 tag=101 nentries=0 wtime=0.000669302 optime=0.000221026 etime=0.000887813 [04/Dec/2024:17:26:03.777659765 +0300] conn=4 op=464 SRCH base="krbprincipalname=TRUSTD$@FREEIPA.TESTDOMAIN,cn=trustd.trustdomain,cn=ad,cn=trusts,dc=freeipa,dc=testdomain" scope=0 filter="(objectClass=*)" attrs=ALL [04/Dec/2024:17:26:03.778043269 +0300] conn=4 op=464 RESULT err=0 tag=101 nentries=1 wtime=0.000181995 optime=0.000383983 etime=0.000563519 [04/Dec/2024:17:26:03.778320457 +0300] conn=4 op=465 DEL dn="krbPrincipalName=TRUSTD$@FREEIPA.TESTDOMAIN,cn=trustd.trustdomain,cn=ad,cn=trusts,dc=freeipa,dc=testdomain" [04/Dec/2024:17:26:03.787218288 +0300] conn=4 op=465 RESULT err=0 tag=107 nentries=0 wtime=0.000248254 optime=0.008902561 etime=0.009146789 [04/Dec/2024:17:26:03.788080996 +0300] conn=4 op=466 ADD dn="krbprincipalname=krbtgt/TRUSTD@FREEIPA.TESTDOMAIN,cn=trustd.trustdomain,cn=ad,cn=trusts,dc=freeipa,dc=testdomain" [04/Dec/2024:17:26:03.789528942 +0300] conn=4 op=466 RESULT err=65 tag=105 nentries=0 wtime=0.000596456 optime=0.001453382 etime=0.002046431 - attribute "ipaAllowedToPerform;read_keys" not allowed
No error.
https://pagure.io/freeipa/c/90eeb04e6973aae1ffb47813c65473b93f3da3a0 triggers the issue.
Didn't check on today's master, it may be affected too.
master
2024-12-04T14:26:03Z ERROR Upgrade failed with attribute "ipaAllowedToPerform;read_keys" not allowed 2024-12-04T14:26:03Z DEBUG Traceback (most recent call last): File "/usr/lib64/python3/site-packages/ipapython/ipaldap.py", line 1093, in error_handler yield File "/usr/lib64/python3/site-packages/ipapython/ipaldap.py", line 1669, in add_entry self.conn.add_s(str(entry.dn), list(attrs.items())) File "/usr/lib64/python3/site-packages/ldap/ldapobject.py", line 236, in add_s return self.add_ext_s(dn,modlist,None,None) File "/usr/lib64/python3/site-packages/ldap/ldapobject.py", line 222, in add_ext_s resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout) File "/usr/lib64/python3/site-packages/ldap/ldapobject.py", line 543, in result3 resp_type, resp_data, resp_msgid, decoded_resp_ctrls, retoid, retval = self.result4( File "/usr/lib64/python3/site-packages/ldap/ldapobject.py", line 553, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/usr/lib64/python3/site-packages/ldap/ldapobject.py", line 128, in _ldap_call result = func(*args,**kwargs) ldap.OBJECT_CLASS_VIOLATION: {'msgtype': 105, 'msgid': 467, 'result': 65, 'desc': 'Object class violation', 'ctrls': [], 'info': 'attribute "ipaAllowedToPerform;read_keys" not allowed\n'}
So we practically need to extend a list of objectclasses on the object where we add ipaAllowedToPerform;read_keys
ipaAllowedToPerform;read_keys
objectclass: ipaAllowedOperations
Looking through the code, we already do that if self.KRB_PRINC_CREATE_AGENT_PERMISSION flag is present in set_krb5_principal() call. I guess we just need to add one in
self.KRB_PRINC_CREATE_AGENT_PERMISSION
set_krb5_principal()
--- a/ipaserver/install/plugins/adtrust.py +++ b/ipaserver/install/plugins/adtrust.py @@ -702,7 +702,7 @@ class update_tdo_to_new_layout(Updater): nbt=nbt_name, realm=self.api.env.realm) tgt_principal = self.tgt_principal_template.format( remote=nbt_name, local=self.api.env.realm) - self.set_krb_principal([nbt_principal, tgt_principal], + self.set_krb_principal([tgt_principal, nbt_principal], passwd_incoming, t_dn, flags=self.KRB_PRINC_CREATE_DEFAULT)
(e.g. do flags=.. | self.KRB_PRINC_CREATE_AGENT_PERMISSION)
flags=.. | self.KRB_PRINC_CREATE_AGENT_PERMISSION
@slev can you try that?
Looking through the code, we already do that if self.KRB_PRINC_CREATE_AGENT_PERMISSION flag is present in set_krb5_principal() call. I guess we just need to add one in --- a/ipaserver/install/plugins/adtrust.py +++ b/ipaserver/install/plugins/adtrust.py @@ -702,7 +702,7 @@ class update_tdo_to_new_layout(Updater): nbt=nbt_name, realm=self.api.env.realm) tgt_principal = self.tgt_principal_template.format( remote=nbt_name, local=self.api.env.realm) - self.set_krb_principal([nbt_principal, tgt_principal], + self.set_krb_principal([tgt_principal, nbt_principal], passwd_incoming, t_dn, flags=self.KRB_PRINC_CREATE_DEFAULT) (e.g. do flags=.. | self.KRB_PRINC_CREATE_AGENT_PERMISSION) @slev can you try that?
yeah, adding self.KRB_PRINC_CREATE_AGENT_PERMISSION helped.
thank you for confirmation. Will you open a PR with this fix?
Thank you.
Fair to say I would need more time to understand what I'm actually 'fixing' to describe it and I would not dare to steal your fix.
When expected Kerberos principal names for this object were flipped to follow requirements for cross-realm krbtgt objects expected by Active Directory, trusted object changed its canonical Kerberos principal name. The keytab for this Kerberos principal name is fetched by SSSD and it needs to be permitted to read the key. We added the virtual permission to allow the keytab retrieval but didn't add the objectclass that actually allows adding an LDAP attribute to express the permission. When an attribute is added to an LDAP object, objectclasses of the object must allow presence of that attribute.
Great and detailed explanation, thank you. https://github.com/freeipa/freeipa/pull/7621
master:
ipa-4-12:
Metadata Update from @frenaud: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
ipa-4-11:
ipa-4-10:
ipa-4-9:
Metadata Update from @frenaud: - Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/7621 - Custom field rhbz adjusted to https://issues.redhat.com/browse/RHEL-70477, https://issues.redhat.com/browse/RHEL-70481, https://issues.redhat.com/browse/RHEL-70482
Metadata Update from @frenaud: - Issue assigned to slev