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 b3c2197 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 ba4df64 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:
ipa-4-9:
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.