A possible workaround is to add the following aci, that grant add right to CA administrator on CAS container

    dn: cn=cas,cn=ca,<suffix>
    aci: (target = "ldap:///cn=cas,cn=ca,<suffix>")
         (version 3.0;acl "permission:System: Add CA in CAS container"; allow (add) 
         groupdn = "ldap:///cn=System: Add CA,cn=permissions,cn=pbac,<suffix>";)


    [13/Jan/2017:16:12:35.592083904 +0100] conn=3784 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
    [13/Jan/2017:16:12:35.593725273 +0100] conn=3784 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=foobar,cn=users,cn=accounts,<suffix>"
    ...
    [13/Jan/2017:16:12:35.623318891 +0100] conn=3784 op=7 SRCH base="cn=cas,cn=ca,<suffix>" scope=0 filter="(objectClass=*)" attrs="* aci"
    [13/Jan/2017:16:12:35.625949457 +0100] conn=3784 op=7 RESULT err=0 tag=101 nentries=1 etime=0 - entryLevelRights: a
    ..
    [13/Jan/2017:16:12:36.305454105 +0100] conn=3784 op=14 ADD dn="cn=Foobar CA,cn=cas,cn=ca,<suffix>"
    [13/Jan/2017:16:12:36.313870641 +0100] conn=3784 op=14 RESULT err=0 tag=105 nentries=0 etime=0

    /usr/lib64/mozldap/ldapsearch -D "cn=directory manager" -w Secret123 -b "cn=cas,cn=ca,<suffix>" -J "1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=foobar,cn=users,cn=accounts,<suffix>" -s base "(objectclass=*)"                                                               
    version: 1
    dn: cn=cas,cn=ca,<suffix>
    objectClass: nsContainer
    objectClass: top
    cn: cas
    entryLevelRights: a
    attributeLevelRights: objectClass:rsc, cn:rsc

OK, this is caused by the ldap.can_add check in ipaserver.plugins.ca which
uses the LDAP GetEffectiveRights control.

The required ACI is present:

aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl "permission:System
 : Add CA";allow (add) groupdn = "ldap:///cn=System: Add CA,cn=permissions,cn=
 pbac,dc=ipa,dc=local";)

BUT the GetEffectiveRights system doesn't know how to interpret the FILTER
in this ACI. tl;dr GER only shows that the right exists when the user has the
right to add ANY object. If there are filters, it shows that the right DOES NOT
exist.

Getting around this is complicated. We were using the can_add check
as a gate BEFORE creating the CA in Dogtag. It seems we cannot do that.
What we really need is an LDAP "no-op" control that can test a complete
operation but does not commit it, and will indicate whether the operation
succeeded or failed.

hey @ftweedal

There is no way to do an add-then-abort with LDAP. There is a draft RFC for this, but we don't support it (and really, I don't want to, but that's a diff matter ;) )

So in this case, the issue is squarely in the realm of DS and GER not operating effectively.

I think your options are:

• Try and add and just hope / handle the exception
• Get us to fix GER and do the check before you write

TBH we should fix this anyway, but there in no hard in trying the add and then handling the exception (unless you are adding multiple objects.

Remember, in ldap a modify is atomic within a single entry IE:

mod object:
a: x
b: y

If a: x fails, then so will b: y, but if you mod TWO objects:

mod object A:
a: x
b: y

mod object B:
a: x
b: y

And objectA suceeds, but object B does not, the results of objectA will persist.

Hope that helps.

PS: is there an open issue on DS about GER? We have talked about this previously.

A bit of "thinking out loud" about how to work around this.

1. Add new ACIs to allow users with System: Add CA permission both to modify the ipaCaId attribute, and to delete CAs. This is necessary for cleanup.
2. Add ipaca object with dummy ipaCaId attribute (it is a MUST attribute). If this fails, it is due to lack of 'add' permission, so fail hard.
3. Add CA in Dogtag.
4. If (2) succeeded, update the ipaCaId attribute. We have permission to do this due to (0).
5. If (2) failed, remove the ipaca object. We have permission to do this due to (0).

Bit of any ugly hack but at least ensures that we clean up when something has gone wrong, and makes sure we don't try to create the CA in Dogtag unless the user definitely has Add CA permission.

I can't comment on the correctness of that solution as I don't know enough about the internals of the problem you describe.

At the least, we should open this issue on DS, because we should have a workeing GER in this case, regardless of any workaround you may implement on the IPA side,

I have a commit for this in the works. Just needs testing.

PR: https://github.com/freeipa/freeipa/pull/837

389-ds-base ticket to fix the GetEffectiveRights control:
https://pagure.io/389-ds-base/issue/49278

FreeIPA 4.6.3 has been released, moving to FreeIPA 4.6.4 milestone

New pull request: https://github.com/freeipa/freeipa/pull/1520

Just waiting on the 389-ds update upon which it depends to hit
f27 stable, before the tests can pass.

@ftweedal Your PR looks good.

I'd like to see a positive and negative function test for the feature, too. The bug was hard to fix and required changes on both our side and 389-DS. I'm worried that the patch won't stick to the punch card. I'll merge your PR but leave the bug open as a reminder.

master:

• 4daac52 ipaldap: allow GetEffectiveRights on individual operations
• b466172 ldap2: fix implementation of can_add

ipa-4-6:

• ac9efdc ipaldap: allow GetEffectiveRights on individual operations
• dee3255 ldap2: fix implementation of can_add