#6609 A CA administrator fails to add CA for Insufficient 'add' privilege
Closed: fixed 8 months ago by tbordaz. Opened 2 years ago by tbordaz.

ipa 4.4, DS 1.3.5.14

The steps to reproduce

kinit admin                                                                                                                         
ipa user-add foobar --first=foo --last=bar --password
ipa role-add-privilege "Fake CA Administration" --privileges='CA Administrator'
ipa role-add-member    "Fake CA Administration" --users=foobar

ipa privilege-show 'CA Administrator'
  Privilege name: CA Administrator
  Description: CA Administrator
  Permissions: System: Add CA, System: Delete CA, System: Modify CA, System: Add CA ACL, System: Delete CA ACL, System: Manage CA
               ACL Membership, System: Modify CA ACL, System: Delete Certificate Profile, System: Import Certificate Profile,
               System: Modify Certificate Profile
  Granting privilege to roles: Fake CA Administration

kinit foobar
ipa ca-add 'Foobar CA' '--subject=CN=Foobar Certificate Authority,O=<domain>' --desc='Foobar CA' 
ipa: ERROR: Insufficient access: Insufficient 'add' privilege for entry 'cn=Foobar CA,cn=cas,cn=ca,<suffix>'

The reason of the failure is that Geteffectiverights, does not get the ADD right

[13/Jan/2017:11:07:26.802295069 +0100] conn=3748 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[13/Jan/2017:11:07:26.803916915 +0100] conn=3748 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=foobar,cn=users,cn=accounts,dc=<suffix>"
...
[13/Jan/2017:11:07:30.663590051 +0100] conn=3748 op=7 SRCH base="cn=cas,cn=ca,dc=<suffix>" scope=0 filter="(objectClass=*)" attrs="* aci"
[13/Jan/2017:11:07:31.869972848 +0100] conn=3748 op=7 RESULT err=0 tag=101 nentries=1 etime=2 - entryLevelRights: none
[13/Jan/2017:11:07:31.878341903 +0100] conn=3748 op=8 UNBIND

/usr/lib64/mozldap/ldapsearch -D "cn=directory manager" -w xxx -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: none
attributeLevelRights: objectClass:rsc, cn:rsc

This although foobar is member of 'Add CA'

ldapsearch -LLL -D "cn=directory manager" -W - -b "<suffix>" -o ldif-wrap=no uid=foobar memberof
dn: uid=foobar,cn=users,cn=accounts,<suffix>
memberof: cn=ipausers,cn=groups,cn=accounts,<suffix>
memberof: cn=Fake CA Administration,cn=roles,cn=accounts,<suffix>
memberof: cn=CA Administrator,cn=privileges,cn=pbac,<suffix>
memberof: cn=System: Add CA,cn=permissions,cn=pbac,<suffix>
memberof: cn=System: Delete CA,cn=permissions,cn=pbac,<suffix>
memberof: cn=System: Modify CA,cn=permissions,cn=pbac,<suffix>
memberof: cn=System: Add CA ACL,cn=permissions,cn=pbac,<suffix>
memberof: cn=System: Delete CA ACL,cn=permissions,cn=pbac,<suffix>
memberof: cn=System: Manage CA ACL Membership,cn=permissions,cn=pbac,<suffix>
memberof: cn=System: Modify CA ACL,cn=permissions,cn=pbac,<suffix>
memberof: cn=System: Delete Certificate Profile,cn=permissions,cn=pbac,<suffix>
memberof: cn=System: Import Certificate Profile,cn=permissions,cn=pbac,<suffix>
memberof: cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,<suffix>

The reason is that targetfilter 'Add CA' aci does not match the CAS container entry

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

ldapsearch -D "cn=directory manager" -w Secret123 -b "cn=cas,cn=ca,<suffix>" -s base
dn: cn=cas,cn=ca,<suffix>
objectClass: nsContainer
objectClass: top
cn: cas

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

Metadata Update from @tbordaz:
- Issue assigned to someone
- Issue set to the milestone: FreeIPA 4.5

2 years ago

Metadata Update from @mbasti:
- Issue close_status updated to: None
- Issue set to the milestone: FreeIPA 4.5.1 (was: FreeIPA 4.5)

2 years ago

Metadata Update from @tdudlak:
- Custom field component reset (from IPA)
- Custom field rhbz reset (from 0)
- Custom field type reset (from defect)

2 years ago

Metadata Update from @pvoborni:
- Issue set to the milestone: FreeIPA 4.7 (was: FreeIPA 4.5.1)

2 years ago

Metadata Update from @tdudlak:
- Issue assigned to tdudlak (was: someone)

2 years ago

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,

Metadata Update from @tdudlak:
- Assignee reset

2 years ago

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

Metadata Update from @ftweedal:
- Issue assigned to tdudlak

2 years ago

Metadata Update from @ftweedal:
- Issue assigned to ftweedal (was: tdudlak)

2 years ago

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

Metadata Update from @ftweedal:
- Issue set to the milestone: FreeIPA 4.6 (was: FreeIPA 4.7)

2 years ago

Metadata Update from @tkrizek:
- Issue set to the milestone: FreeIPA 4.6.1 (was: FreeIPA 4.6)

a year ago

Metadata Update from @tkrizek:
- Issue set to the milestone: FreeIPA 4.6.2 (was: FreeIPA 4.6.1)

a year ago

Metadata Update from @tdudlak:
- Issue set to the milestone: FreeIPA 4.6.3 (was: FreeIPA 4.6.2)

a year ago

Metadata Update from @rcritten:
- Issue set to the milestone: FreeIPA 4.6.4 (was: FreeIPA 4.6.3)

11 months ago

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.

Metadata Update from @ftweedal:
- Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/1520

10 months ago

@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

Metadata Update from @rcritten:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

8 months ago

Login to comment on this ticket.

Metadata