Re: [Freeipa-devel] DNs of Custodia keys
On Tue, 2016-04-12 at 21:26 +1000, Fraser Tweedale wrote:
> 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:
> >
> >
> 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.
You may also think of adding a subtree specific to subCA keys perhaps.
Simo.
--
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
Re: [Freeipa-devel] DNs of Custodia keys
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:
>
>
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
Re: [Freeipa-devel] DNs of Custodia keys
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:
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
Re: [Freeipa-devel] DNs of Custodia keys
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).
>
> [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.
The question is if the * behaves as expected. CCing Ludwig ...
Petr^2 Spacek
>
>
> 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
>
--
Petr^2 Spacek
--
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
