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).

[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.


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.)


Let me know what you think!

Cheers,
Fraser

-- 
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