Re: ACI limiting read to groups a user is member of

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

 




> On 17 Feb 2020, at 14:02, Grant Byers <Grant.Byers@xxxxxxxxxxxxx> wrote:
> 
> On 17/2/20 1:24 pm, William Brown wrote:
>> 
>>> On 17 Feb 2020, at 12:19, Grant Byers <Grant.Byers@xxxxxxxxxxxxx> 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/html/administration_guide/managing_access_control
>> 
>> 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)")

Maybe I'm confused what you want to achieve? You want it so that people can only read groups they are members of? Or so that they can only read limited attributes of all groups? 

> 
> 
> Thanks,
> 
> Grant
> 
> 
>>> 
>>> Thanks,
>>> Grant
>>> _______________________________________________
>>> 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
>> —
>> 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
> 
> 
> _______________________________________________
> 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

—
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




[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