Writing secure aci's for delegation is hard. Basically, unless your aci is:

aci: (target = "ldap:///cn=*,ou=custom,ou=groups,dc=example,dc=com")
     (targetfilter="(&(objectClass=top)(objectClass=groupOfUniqueNames))")
     (targetattr="cn || uniqueMember || objectclass")
     (version 3.0; acl "example"; allow (read, search, write, add)
        (userdn = "ldap:///uid=test,ou=People,dc=example,dc=com");
     )

It's exploitable. You need to set the objectClasses to allow the delegate user/group to create, and the limited set of attributes that can exist on that objectClass.

I think we should add a new aci target type which helps this issue.

I propose a syntax like:

(targetobjectclass = " top || groupofuniquenames ")

The behaviour of this is:

Write operations:

• Only allows writing to attributes that exist in the listed objectClasses MAY and MUST syntax.
• Only allows the value of ObjectClass to be set to these values during add. IE the created object's objectClass must be a subset of the set listed in targetobjectclass.

Read operations:

• The value being read must contain one of the objectClasses (IE or) listed in the target.
• The attributes allowed to read, are from the MAY and MUST of these objectClasses.

This would allow the above aci to be securely written as:

aci: (target = "ldap:///cn=*,ou=custom,ou=groups,dc=example,dc=com")
     (targetobjectclass = "top || groupofuniquenames")
     (version 3.0; acl "example"; allow (read, search, write, add)
        (userdn = "ldap:///uid=test,ou=People,dc=example,dc=com");
     )

This is much simpler for directory administrators to use and reason about.