On 17 Feb 2020, at 12:19, Grant Byers <Grant.Byers(a)aarnet.edu.au&gt; wrote: Hi, In an effort to tighten search and read permissions on our internal directory server, we've limited accounts to read certain attributes of "self". They have search on the entire tree, but otherwise no read perms. This is all well and good for clients that utilize the memberOf attribute of self, but not so good for applications that utilize memberUid, or insist on searching for groupOfUniqueNames or groupOfNames then enumerating them programmatically to determine which groups the user belongs to after binding as the user. So. I've been reading docs and haven't been able to find anything, but I was wanting to do something like this; dn: ou=groups,dc=example,dc=com aci: (targetattr = "*") (targetfilter = "(&(objectClass=groupOfUniqueNames)(uniqueMember={{rdn of self}})") (version 3.0; acl "Allow authenticated users to read own group membership"; allow (read,compare,search) (userdn="ldap:///all");) where the target filter limits results to only those that match uniqueMember={{rdn of self}} Is this possible?

Thanks, Grant _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 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.fedoraproje...

On 17 Feb 2020, at 14:02, Grant Byers <Grant.Byers(a)aarnet.edu.au&gt; wrote: On 17/2/20 1:24 pm, William Brown wrote: > >> On 17 Feb 2020, at 12:19, Grant Byers <Grant.Byers(a)aarnet.edu.au&gt; wrote: >> >> Hi, >> >> In an effort to tighten search and read permissions on our internal >> directory server, we've limited accounts to read certain attributes of >> "self". They have search on the entire tree, but otherwise no read >> perms. This is all well and good for clients that utilize the memberOf >> attribute of self, but not so good for applications that utilize >> memberUid, or insist on searching for groupOfUniqueNames or >> groupOfNames then enumerating them programmatically to determine which >> groups the user belongs to after binding as the user. >> >> So. I've been reading docs and haven't been able to find anything, but I >> was wanting to do something like this; >> >> >> dn: ou=groups,dc=example,dc=com >> aci: (targetattr = "*") >> (targetfilter = "(&(objectClass=groupOfUniqueNames)(uniqueMember={{rdn >> of self}})") >> (version 3.0; acl "Allow authenticated users to read own group >> membership"; allow (read,compare,search) >> (userdn="ldap:///all");) >> >> >> where the target filter limits results to only those that match >> uniqueMember={{rdn of self}} >> >> >> Is this possible? > Yes, but I'd suggest you tighten it up a bit. targetattr = * is really dangerous, it really means everything, including internal system attributes. > > You probably want "(targetattr = "objectClass || uniquemember || cn || memberUid || member || memberOf")(targetfilter = "....") > > There is a section in the redhat ds guide that may help a lot > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10... > > In general, keep your aci's as targeted and as specific as possible. > > I'm very happy to review these further if you need :) For sure, I'll definitely be restricting attributes (as I have done with other targeted ACIs). I'm working toward least privilege. I've reviewed that doco multiple times now, but still don't see how this is possible. I must be missing something! I assume it has to be targetfilter. Am I to do something like this? (targetfilter = "(&(objectClass=groupOfUniqueNames)(uniqueMember=ldap:///self?dn)")

Thanks, Grant >> >> Thanks, >> Grant >> _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> 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.fedoraproje... > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > 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.fedoraproje... _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 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.fedoraproje...

Got it.. (userattr = "uniqueMember#USERDN")

Thanks! On 17/2/20 2:02 pm, Grant Byers wrote: > On 17/2/20 1:24 pm, William Brown wrote: >>> On 17 Feb 2020, at 12:19, Grant Byers <Grant.Byers(a)aarnet.edu.au&gt; wrote: >>> >>> Hi, >>> >>> In an effort to tighten search and read permissions on our internal >>> directory server, we've limited accounts to read certain attributes of >>> "self". They have search on the entire tree, but otherwise no read >>> perms. This is all well and good for clients that utilize the memberOf >>> attribute of self, but not so good for applications that utilize >>> memberUid, or insist on searching for groupOfUniqueNames or >>> groupOfNames then enumerating them programmatically to determine which >>> groups the user belongs to after binding as the user. >>> >>> So. I've been reading docs and haven't been able to find anything, but I >>> was wanting to do something like this; >>> >>> >>> dn: ou=groups,dc=example,dc=com >>> aci: (targetattr = "*") >>> (targetfilter = "(&(objectClass=groupOfUniqueNames)(uniqueMember={{rdn >>> of self}})") >>> (version 3.0; acl "Allow authenticated users to read own group >>> membership"; allow (read,compare,search) >>> (userdn="ldap:///all");) >>> >>> >>> where the target filter limits results to only those that match >>> uniqueMember={{rdn of self}} >>> >>> >>> Is this possible? >> Yes, but I'd suggest you tighten it up a bit. targetattr = * is really dangerous, it really means everything, including internal system attributes. >> >> You probably want "(targetattr = "objectClass || uniquemember || cn || memberUid || member || memberOf")(targetfilter = "....") >> >> There is a section in the redhat ds guide that may help a lot >> >> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10... >> >> In general, keep your aci's as targeted and as specific as possible. >> >> I'm very happy to review these further if you need :) > For sure, I'll definitely be restricting attributes (as I have done with > other targeted ACIs).  I'm working toward least privilege. > > > I've reviewed that doco multiple times now, but still don't see how this > is possible. I must be missing something! I assume it has to be > targetfilter. Am I to do something like this? > > > (targetfilter = "(&(objectClass=groupOfUniqueNames)(uniqueMember=ldap:///self?dn)") > > > Thanks, > > Grant > > >>> Thanks, >>> Grant >>> _______________________________________________ >>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >>> 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.fedoraproje... >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> 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.fedoraproje... > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > 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.fedoraproje... _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 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.fedoraproje...

> On 17 Feb 2020, at 19:25, thierry bordaz <tbordaz(a)redhat.com&gt; wrote: > > > > On 2/17/20 5:26 AM, Grant Byers wrote: >> Got it.. >> >> >> (userattr = "uniqueMember#USERDN") > It allows a member of a groupofUniqueName to read/search that group. If you are also supporting GroupofName groups you may want to add the bind rule (userasttr="member#userDN"). > With this rule, targetfilter is useless and you may remove it as it is quite expensive to evaluate. I'm still not 100% on what Grant's goal is here Thierry. I don't know if it's "anyone can read groups" or "can only read groups you are a member of". I'd also say what's your threat/risk model. Knowledge of group membership is not a security risk, so a simple rule like what I proposed (all read member/memberUid) for anyone is probably fine ... Anyway, if you want more advice Grant, I think we need to know exactly what you want to achieve :) Thanks

> best regards > thierry >> >> Thanks! >> >> On 17/2/20 2:02 pm, Grant Byers wrote: >>> On 17/2/20 1:24 pm, William Brown wrote: >>>>> On 17 Feb 2020, at 12:19, Grant Byers <Grant.Byers(a)aarnet.edu.au&gt; wrote: >>>>> >>>>> Hi, >>>>> >>>>> In an effort to tighten search and read permissions on our internal >>>>> directory server, we've limited accounts to read certain attributes of >>>>> "self". They have search on the entire tree, but otherwise no read >>>>> perms. This is all well and good for clients that utilize the memberOf >>>>> attribute of self, but not so good for applications that utilize >>>>> memberUid, or insist on searching for groupOfUniqueNames or >>>>> groupOfNames then enumerating them programmatically to determine which >>>>> groups the user belongs to after binding as the user. >>>>> >>>>> So. I've been reading docs and haven't been able to find anything, but I >>>>> was wanting to do something like this; >>>>> >>>>> >>>>> dn: ou=groups,dc=example,dc=com >>>>> aci: (targetattr = "*") >>>>> (targetfilter = "(&(objectClass=groupOfUniqueNames)(uniqueMember={{rdn >>>>> of self}})") >>>>> (version 3.0; acl "Allow authenticated users to read own group >>>>> membership"; allow (read,compare,search) >>>>> (userdn="ldap:///all");) >>>>> >>>>> >>>>> where the target filter limits results to only those that match >>>>> uniqueMember={{rdn of self}} >>>>> >>>>> >>>>> Is this possible? >>>> Yes, but I'd suggest you tighten it up a bit. targetattr = * is really dangerous, it really means everything, including internal system attributes. >>>> >>>> You probably want "(targetattr = "objectClass || uniquemember || cn || memberUid || member || memberOf")(targetfilter = "....") >>>> >>>> There is a section in the redhat ds guide that may help a lot >>>> >>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10... >>>> >>>> In general, keep your aci's as targeted and as specific as possible. >>>> >>>> I'm very happy to review these further if you need :) >>> For sure, I'll definitely be restricting attributes (as I have done with >>> other targeted ACIs). I'm working toward least privilege. >>> >>> >>> I've reviewed that doco multiple times now, but still don't see how this >>> is possible. I must be missing something! I assume it has to be >>> targetfilter. Am I to do something like this? >>> >>> >>> (targetfilter = "(&(objectClass=groupOfUniqueNames)(uniqueMember=ldap:///self?dn)") >>> >>> >>> Thanks, >>> >>> Grant >>> >>> >>>>> Thanks, >>>>> Grant >>>>> _______________________________________________ >>>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >>>>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >>>>> 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.fedoraproje... >>>> — >>>> Sincerely, >>>> >>>> William Brown >>>> >>>> Senior Software Engineer, 389 Directory Server >>>> SUSE Labs >>>> _______________________________________________ >>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >>>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >>>> 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.fedoraproje... >>> _______________________________________________ >>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >>> 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.fedoraproje... >> _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> 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.fedoraproje... > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > 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.fedoraproje... — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 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.fedoraproje...