> On 26 Aug 2019, at 17:36, Miljan Žugić <Miljan.Zugic@xxxxxxxxx> wrote: > > First, i really wanna say big thanks for super fast answer. Above all, concise and technical, concrete with facts.. > Second, i did home work and read it link (which i did before also, but..maybe i miss something 😊 and read again) > Third, i already did what you write: deny on specific lvl for anonymous (anyone), and allow (whatever) for specific user..But this dosnt work. Looks "deny" is stronger..which is strange for me, your explanation sound perfectly fine. > Is it possible to get functionality on 389DS like targetbase = sub, onelevel, base..? > Forth, " using onelevel rules or labeling with filters instead" sound really great. Where i can get some example of this? Deny is "stronger" yes, but it has interactions that may be "unforseen". It's better to say "you have allow to these limited things" than "you are allowed to lots and we deny little bits we don't want". The deny way leaves room for mistakes if you add a subtree later and forget the deny, or the deny could be too broad, etc. https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ The documentation here is what is used by Directory Server. Mark already linked the access control chapter. In that section have a look at: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/defining_targets You can use this rule on ou=people for example dn: ou=People,dc=example,dc=com ou: People aci: (target = "ldap:///uid=*,ou=people,dc=example,dc=com";)(targetattr = "uid || cn || displayname")(version 3.0; acl "example"; allow (read, search, compare)(userdn = "ldap:///anyone";);) This would allow "anonymous" and all other accounts to read uid, cn and displayname, where the rdn starts with "uid=" under ou=people. Does that help? It's always a good idea to try these things out of course :) > > And you don’t need to answer. I'm already happy, because i work with Apache ldap till now and ... always some strange behavior and 0 help..and yes, on site on advanced features you can read only " TO DO ...".. We are always happy to answer, and we hope that we can help you to learn and make your LDAP install be the best possible. If you have any other questions or comments, please always contact us! > > Really Best Regards and have nice day! > > > > Miljan Žugić > Sistemski inženjer | Systems engineer > Sistemska podrška | Corporate IT > > T +381 11 3306514 > M +381 62 250 523 > E Miljan.Zugic@xxxxxxxxx > > Halcom a.d. > Beogradska 39 | 11000 Beograd | Srbija > > www.halcom.rs > -----Original Message----- > From: William Brown <wbrown@xxxxxxx> > Sent: Monday, August 26, 2019 1:09 AM > To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx > Cc: Miljan Žugić <Miljan.Zugic@xxxxxxxxx> > Subject: Re: [389-users] Re: A bit help about ACI? > > > >> On 24 Aug 2019, at 01:48, Mark Reynolds <mreynolds@xxxxxxxxxx> wrote: >> >> >> On 8/23/19 11:34 AM, Mark Reynolds wrote: >>> Moving to the correct list (389-users)... >>> >>> On 8/23/19 9:05 AM, Miljan Žugić wrote: >>>> I apologize in advance if this is wrong address 😊 >>>> I build up 2 389 DS server, make replication and up till now, all looks fine. >>>> But I have some issue about ACI. Where I can find good forum or site to get some real examples of ACI ? >>>> >>>> Or if you can help me…I want something like this, to make “anonymous” can do read, search and compare for levels B and D, but deny to A and E (actually I have problem with level E, I can do deny to anyone to level E or deeper, but I need some specific accounts to access level E or deeper, so…I stuck how to do that) : >> First you should really read the access control docs: >> >> https://access.redhat.com/documentation/en-us/red_hat_directory_server >> /10/html/administration_guide/managing_access_control >> >> In order to do what you want you need two kinds of aci, allow and deny. You need deny rules because when you set an aci on a subtree it applies to all its children. So as you noted you can deny level E, but it denies everyone even if they previously had access. So you need to add new aci's on level E that open up access to the users/groups you want to have access. So you might end up with "duplicate" aci's at different levels in your tree. >> >> So on level B you have your anonymous access aci's - this will apply to all lower branches. On Level E must have a deny "anonymous/anyone" rule, and then you add new acis to level E that open it back up for those you want to have access. > > Another way to tackle this is a costemplate that adds a security label to the "onelevels" you want accessible, then have an allow anonymous rule to filter on the security label that is added. Of course, you need to ensure people can't write that label type ... > > Deny rules always make aci's messy - they really do make it confusing to audit and "see" what's going on. > > So I think here, you should probably reconsider your tree layout and if it's the correct structure, or consider using onelevel rules or labeling with filters instead, to keep it to "allow only" rules. > >> >> HTH, >> >> Mark >> >> >> >>>> >>>> <image003.png> >>>> >>>> Anyhow, BR 😃 >>>> >>>> >>>> Miljan Žugić >>>> Sistemski inženjer | Systems engineer >>>> Sistemska podrška | Corporate IT >>>> >>>> T +381 11 3306514 >>>> M +381 62 250 523 >>>> E Miljan.Zugic@xxxxxxxxx >>>> >>>> >>>> >>>> >>>> >>>> Halcom a.d. >>>> Beogradska 39 | 11000 Beograd | Srbija >>>> >>>> www.halcom.rs >>>> >>>> >>> -- >>> >>> 389 Directory Server Development Team >>> >>> >>> >>> _______________________________________________ >>> 389-users mailing list -- >>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>> >>> To unsubscribe send an email to >>> 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx >>> >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> >>> List Guidelines: >>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>> >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorap >>> roject.org >> -- >> >> 389 Directory Server Development Team >> >> _______________________________________________ >> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To >> unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorapr >> oject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server SUSE Labs > — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
