On 17 Feb 2020, at 19:25, thierry bordaz <tbordaz(a)redhat.com>
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>
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