Re: Limiting access to same ou

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
_______________________________________________
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




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux