freeipa

#8930 IdM should call into Dogtag to dynamically update the security domain info
Closed: fixed by rcritten. Opened by rcritten.

Closed: fixed
Reopen Issue

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): Bug 1740702

Description of problem:
When an IdM system with CA/KRA role is removed from  IdM topology, IdM should
call into Dogtag to also remove this system from the security domain info.
At the moment there is an inconsistency between the output from 'pki' and 'ipa'
tools.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1740697
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:

Metadata Update from @rcritten:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1740702

Metadata Update from @rcritten:
- Issue assigned to rcritten

We can use the CA REST API to send a DELETE to:

https://ipa.example.test:443/ca/rest/securityDomain/hosts/CA%20replica.example.test%20443

This would delete the CA replica.example.test on port 443. The format is similar for the KRA.

From the CLI this looks like:

# pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C
/etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA
ipa.example.test 443'

This uses the subsystem cert because the IPA RA lacks permission to modify the security domain.

There is a Security Domain Administrators group but it too lacks permission to modify the domainxml.

@edewata do you have any suggestions on which group we should use, or should we modify the resourceACL?

It appears that the controlling ACL is:

resourceACLS: certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group" || group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise RA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators":Anybody is allowed to read domain.xml but only Subsystem group and Enterprise Administrators are allowed to modify the domain.xml

It seems like the Security Domain Admins group missing is an oversight. I'm not sure I want to poke this deeply into the CA config though.

I'd lean towards Enterprise RA but that group can create other RAs which seems like a bad idea. The other groups seem worse.

@edewata never mind, I got it worked out. IPA created that resourceACL so I can just update it on our side.

According to b3c2197b7e4ed18a7febe3efa6396c2272ebccca the update file install/updates/50-dogtag10-migration.update was added for dogtag 9 -> 10 migration. This defines a set of resourceACLS that grant the RA agent rights to modify certain parts of the CA.

Later commit ba4df6449aaa0843ab43a1a2b3cb1df8bb022c24 tweaked this to only apply the change on a replica, non-promotion installation. A pretty narrow case, purportedly to save a CA restart.

We need these resourceACLS and this update is applied currently while the CA is stopped so no extra restart is added.

https://github.com/freeipa/freeipa/pull/5915

master:

  • db6985564600fdd7778ab2d16d73cbab4df944db Clean up the PKI securitydomain when removing a server
  • c0d6c05d00f97d7a46a9e480d4c984eda22ec70c ipatests: Verify that securitydomain is updated on server-del

ipa-4-9:

  • be3a0f3201bbb060a9d53fb65cbbccf6c7bf9bb4 Clean up the PKI securitydomain when removing a server
  • a417810df5500b5780396ab88d53eaea74f74ccc ipatests: Verify that securitydomain is updated on server-del

Metadata Update from @rcritten:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.