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>



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

Reply via email to