On 30/11/2018 00:00, Ludwig Krispenz wrote:
On 11/29/2018 12:12 PM, Alistair Cunningham wrote:
On 29/11/2018 20:12, Ludwig Krispenz wrote:> On 11/29/2018 12:32 AM,
Alistair Cunningham wrote:
Is there a neat way to replace the ACL below that needs to be added
once for each ou with one single ACL that works for every ou?
Perhaps some way of saying that the "ou=2,dc=example,dc=com" in the
target part must match the same string in the userdn part?
aci: (target="ldap:///ou=2,dc=example,dc=com";)(targetattr=*)(version
3.0;acl "aci2";allow (read,search)
userdn="ldap:///cn=*,ou=2,dc=example,dc=com";;)
you should look into Macro ACIs, cahp 18.16
soemthing like:
aci:
(target="ldap:///*($dn*),dc=example,dc=com")(targetattr=*)(version
3.0;acl "aci2";allow (read,search)
userdn="ldap:///cn=*,*($dn)*,dc=example,dc=com";
or maybe [$dn] in the userdn to be able to target subentries.
Now it is question if you should use this. If your tree is very
dynamic and you add or remove subtrees and don't want to change the
acis each time macro acis are the right approach, but if you have a
few subtrees which are stable, macroacis can be a bit of overhead in
evaluating and adding indiuvidual acis is only a bit tedious in the
beginning
The tree design will be simple and stable, with one ou for each tenant
directly under the base. However, there may be a very large number of
them - potentially hundreds of thousands. Would you recommend Macro
ACIs in this case?
yes, if they work for you.
There is always two phases in aci evaluation:
1] find all the acis applying to the target, this is negatively impacted
by a high number of acis and the complexity, eg macros or wildcards,
targetfilterss ....
2] applying the aci, which means evaluating the bind rules, also
negatively affected by complexity, eg macros, targetattrs,...... and/or
clauses ....
In your case I think it is more efficient to match and apply one macro
aci than finding the one simple aci in thousands of acis
Thanks!
--
Alistair Cunningham
+1 888 468 3111
+44 20 799 39 799
https://enswitch.com/
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
