On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote:
> On 21.4.2016 05:30, Fraser Tweedale wrote:
> >On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote:
> >>Hi all,
> >>The attached patches configure lightweight CA key replication on IPA
> >>CAs, on upgrade and installation.
> >>Patches 0051..0052 from my other mail are also needed for the system
> >>to work, but this patchset does not depend on them and can be
> >>reviewed independently.
> >>There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1
> >>- it just puts the necessary principals/keys/configuration in place.
> >New patches attached; 0054-2 changes the service name from
> >'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the
> >principal to search server Custodia keys.
Honza, thanks for review. Comments inline.
> Patch 53:
> I'm not sure about this approach - the cn of custodia keys in LDAP is a
> free-form string, I would not tie it to service names, but rather try to
> keep it short.
> In the key replication section of the design page, you mention "ca/$NAME", I
> think this is a good template for the cn and that we should stick to it.
This scheme (or something like it, *without* '/' as the separator)
is needed to satisfy the ACI that allows host principals to manage
add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")
(version 3.0; acl "IPA server hosts can create own Custodia secrets";
allow(add) groupdn =
and userdn =
The CN must contain the hostname, and we must also disambiguate on
key type. The current scheme is:
The first separator cannot be '/' because the '*' wildcard in the
ACI is not greedy - the captured text would include the servicename
and fail to match any userdn.
If you do not like '~' feel free to suggest a different symbol :)
The alternative is to add more ACIs.
> Patch 54:
> 1) This belongs to CAInstance.configure_instance():
> + CA = cainstance.CAInstance(
> + api.env.realm, certs.NSS_DIR, host_name=api.env.host)
> + CA.setup_lightweight_ca_key_retrieval()
See comments for (5).
> 2) Any ACI changes should be in a separate patch. (What happened to patch
Patch 52 added an ACI that allowed any authenticated user to see the
keys. Simo wanted it limited it to the Dogtag principal so I
rescinded patch 52 and added the ACI in the same patch where the
principal was added.
Separate patch is no problem; I will resurrect number 52.
> 3) This is not a platform constant, just a constant:
> + PKI_GSSAPI_SERVICE_NAME = 'dogtag'
Thanks, will put it in `ipalib.constants'.
> 4) CAInstance.setup_lightweight_ca_key_retrieval() does too much. Please
> split it into a "setup keytab" and "setup custodia" parts.
Will extract methods for next patchset.
> 5) This also belongs to CAInstance.configure_instance():
> + if setup_ca:
> + # CA was configured before Kerberos;
> + # add Custodia client princ and keys now
> + ca_instance.setup_lightweight_ca_key_retrieval()
> In order for that to work, you need to move the ca.install_step_1() after
> krb.create_instance(), but that should be OK, since KrbInstance does not
> talk to the CA.
`setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which
fails if called before `krb.create_instance' due to missing
2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey
dogtag/f23-2.ipa.local@IPA.LOCAL -x ipa-setup-override-restrictions
2016-05-03T06:29:23Z DEBUG Process finished, return code=1
2016-05-03T06:29:23Z DEBUG stdout=
2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default realm
Moving `ca.install_step_1()' to after `krb.create_instance()' does
not help, because `CAInstance.configure_instance' is called from
However, calling `CAInstance.setup_lightweight_ca_key_retrieval()'
*directly* from `ca.install_step_1' would probably work. Are you
happy with putting it there, instead of `configure_instance()'?
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code