On Tue, Apr 12, 2016 at 12:55:50PM +0200, Jan Cholasta wrote: > Hi, > > On 12.4.2016 09:03, Fraser Tweedale wrote: > >Hi Simo and Honza et al, > > > >I have a design challenge pertaining to DNs for Custodia keys. > >DNs for Custodia keys for host principals currently take the form: > > > > cn={sig,enc}/$HOSTNAME,cn=custodia,cn=ipa,cn=etc,$SUFFIX > > > >This prevents the creation of Custodia keys for service principals > >(pursuant to another recent design decision[1] the service principal > >'dogtag-ipa-custodia/$HOSTNAME@$REALM' shall be used as a Custodia > >client for Dogtag lightweight CA key replication). > > This naming scheme is relevant only to IPA server keys, otherwise the cn can > be anything, as long as it does not conflict with existing keys. > > > > >[1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00044.html > > > >Searches for custodia keys use a filter on 'ipaKeyUsage' and > >'memberPrincipal' attributes, so the CN is unimportant except for > >a) uniqueness, and b) ACIs (see below). > > > >Based on this, my first attempt to resolve the conflict was to use > >the service name and host name instead of the just the hostname: > > > > > > cn=sig/host/f23-5.ipa.local@IPA.LOCAL,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local > > > >However, this fails during replica install: > > > > [2/5]: Generating ipa-custodia keys > > {'info': "Insufficient 'add' privilege to add the entry > > > > 'cn=sig/host/f23-5.ipa.local,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local'.\n", > > 'desc': 'Insufficient access'} > > > >due to the ACI: > > > > dn: cn=ipa,cn=etc,$SUFFIX > > 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 = > > "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > > and userdn = > > "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > > > >The wildcard '*' in the target is not greedy and stops at the first > >slash '/', so the value captured by the ($dn) macro does not match > >the bind DN. > > Again, this is relevant only to IPA server keys, you should add your own ACI > for lightweight CAs. > > > > > > >Proposed solution > >----------------- > > > >Use a delimiter other than '/' between the key type and service > >name, e.g. > > > > cn={sig,enc}+$SERVICENAME/$HOSTNAME (rule) > > cn=sig+dogtag-ipa-custodia/f23-3.ipa.local (example) > > > >Pros: should work with existing ACIs. > > > >Cons: continues with an arguably suboptimal design choice. > > > > > >Alternative solution > >-------------------- > > > >Add an 'ipaCustodiaKey' object class, which has 'managedBy' > >attribute for linking the key to the host that manages it, and > >'ipaUniqueId'. > > > >Create key entries with autogenerated ipaUniqueId as RDN. > > > >Add ACIs: > > > > dn: cn=ipa,cn=etc,$SUFFIX > > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") > > (version 3.0; acl "IPA server hosts can create own Custodia > > secrets"; > > allow(add) groupdn = > > "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > > and userattr = "managedby#USERDN";) > > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") > > (targetattr = "ipaPublicKey") > > (version 3.0; acl "IPA server hosts can manage own Custodia > > secrets"; > > allow(write) groupdn = > > "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > > and userattr = "managedby#USERDN";) > > > >(Retain existing ACIs for backwards compatiblity.) > > Actually this has been discussed before: > <https://www.redhat.com/archives/freeipa-devel/2015-November/msg00547.html> > Thanks for the link and feedback.
Something like the following ACI should do the trick, I think? add:aci: (target = "ldap:///cn=*/dogtag-ipa-custodia/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") (version 3.0; acl "IPA server hosts can manage Custodia secrets for the dogtag-ipa-custodia service on same host"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) Host Custodia keys would keep the existing CN schema and existing ACLs will apply only to them. Cheers, Fraser > > > > > >Let me know what you think! > > I think that all you have to do is add a new ACI for your purposes, you > don't need to change anything. > > Honza > > -- > Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code