> On 19 Jan 2021, at 03:40, Gary Windham <windhamg@xxxxxxxxxxx> wrote: > > Thanks for the reply, WIlliam. We are using Internet2's Grouper (which synchronizes group memberships to our 389 DS) to create a "chain" of groups that are being used to implement a COVID-19 testing compliance policy at the University of Arizona. One of these groups contains users who have had a test with a positive result in the last 90 days. Since that is personal health information, we didn't want the "isMemberOf" value containing that group to be visible, except to a particular set of users. You may find it's safer in this case to sync any PHI to either an isolated or seperate directory, or to use a seperate attribute indicating the test positivity that can have strict access controls placed upon it. > > However, since sending my original email, we found a workaround -- fortunately, the end group in this "chain" is the only one we really need to sync to 389 DS, so we were able to omit the other groups (including the PHI one) from the sync process. I'm glad you found a solution still, Hope I was able to help, > > Thanks again, > ---Gary > > -- > Gary Windham > Principal Enterprise Systems Architect > University Information Technology Services > The University of Arizona > > Email: windhamg@xxxxxxxxxxx > Office: +1 520 626 5981 > > > On Sun, Jan 17, 2021 at 5:11 PM William Brown <wbrown@xxxxxxx> wrote: > External Email > > > > On 16 Jan 2021, at 05:17, Gary Windham <windhamg@xxxxxxxxxxxxxxxxx> wrote: > > > > Hi all, > > > > We're running 389-Directory/1.3.9.0 B2018.304.1940. > > > > Is it possible via ACIs to restrict read/search permission on attributes with a particular value? > > > > My use case is that we have an "isMemberOf" attribute in our directory, and we have some group memberships that are of a sensitive nature. I would like to have all "isMemberOf" attribute values *except* for these sensitive ones readable/searchable to all authenticated user DNs, and the "sensitive" ones only readable/searchable by a particular user DN. > > > > Any ideas? From reading the Red Hat directory server ACI documentation, I can't find a way to do this. > > No, I don't think it's possible. Access controls are based on "which attributes you can/can't see", rather than "you can see these attributes except these values within them". > > I think that in this case, the possible solutions would be to have a isMemberOfSensitive seperate to the isMemberOf, but that may break many other integrations. > > An important question of course, is why are some group memberships sensitive? What is it you are trying to achieve? > > > > > Thanks in advance, > > --Gary > > -- > > Gary Windham > > Principal Enterprise Systems Architect > > University Information Technology Services > > The University of Arizona > > > > Email: windhamg@xxxxxxxxxxx > > Office: +1 520 626 5981 > > > > _______________________________________________ > > 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, Australia > — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia _______________________________________________ 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
